/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Oracle - Best preformanc
Fra : Torben Udengaard


Dato : 27-01-03 21:48

Er der nogen her i nyhedsgruppen der har kendskab til, hvordan HD
konfigurationen bør være for at få best preformanc på en Oracle DB?

Har prøvet Oracles hjemmeside! (minder om en rodebutik)

Med venlig hilsen

Torben Udengaard



 
 
Jesper Frank Nemholt (27-01-2003)
Kommentar
Fra : Jesper Frank Nemholt


Dato : 27-01-03 22:55

"Torben Udengaard" <tud@mail.tele.dk> wrote in message
news:3e359bde$0$71712$edfadb0f@dread11.news.tele.dk...
> Er der nogen her i nyhedsgruppen der har kendskab til, hvordan HD
> konfigurationen bør være for at få best preformanc på en Oracle DB?

Jeg ved ikke alverden om Oracle, men storage design til database maskiner
kender jeg en del til.
Jeg arbejder primært med unix, HP StorageWorks og EMC Symmetrix. Maskinerne
kører Oracle 8 & 9 blanded normal, parallel & 9i RAC clustered og SAP eller
Tuxedo/WebLogic.

Der er 4 overordnede faktorer rent diskmæssigt. Accesstid, throughput, I/Os
per sekund og disbtribueret performance (mange forskellige requests på samme
tid).

Ofte får du opfyldt de fleste af disse parametre bedst ved striped
mirrorsets, men kun til en vis grad. På et tidspunkt er et striped mirrorset
så hurtigt at du ikke vinder noget længere ved at gøre det større. Enten på
grund af limits på RAID controlleren eller limits i resten af vejen til
maskinen (controller, protokol standard etc.). Hvis du kører SAN kan du med
fordel benytte multipath og hvis det er et større miljø benytte fat tree
setup af dine switches.
Samtidig kan du ofte (forudsat at databasefilerne og selve databasedesignet
tillader det og udnytter det) vinde en del ved at distribuere rent fysisk,
d.v.s. istedet for få store striped mirrorsets kan du få bedre performance
ved flere mindre og så distribuere dine database filer over dem og huske
ikke at proppe filer der ofte har access på samme tid på samme unit, samt
sørge for at der ikke er konvergerende access til samme unit. Performance
falder markant hvis du propper archive, redo, control, log etc. filer samme
sted som en datafil eller index der typisk kun læses fra. Disse ting skal
separeres.

Jeg ser ofte på de maskiner jeg arbejder med at den primære flaskehals
ligger i placeringen af databasefilerne (og specielt index filerne) i
forhold til hvad der er af logiske diske. Dette skyldes ofte manglende info
eller manglende forståelse af hardware designet når databasen designes.
De 2 skal parres korrekt for at der kommer noget godt ud af det. Det giver
f.eks. en del at man tuner sin RAID performance så dens blok-størrelse
konsekvent går lige op med blokstørrelsen i operativsystemet og i Oracle.
Rammer man skævt et af stederne falder specielt sekventiel performance
markant.
Man bør også tænke i sit filsystem layout, og placering af database filer,
på at gøre det nemt at flytte rundt på disse. Når en flaskehals dukker op er
det fordelagtigt hvis man nemt kan flytte årsagen til en anden disk der er
mindre i brug (hvis altså flaskehalsen er ren I/O og ikke (som det typisk
er) et design problem).

Samtidig er problemet også den anden vej : For at få et optimalt disk design
er det nødvendigt at vide hvordan diskene vil blive brugt, d.v.s. den der
designer disk-konfigurationen er nødt til at snakke sammen med database
folkene og applikations-folkene for at få en ide om hvordan load vil være.
Der er meget stor forskel på hvordan Oracle bruger diske afhængig af hvordan
databasen er designet og/eller bliver brugt.
SAP/datawarehouse er ofte gode eksempler på markant I/O.

Man skal også i sit disk design tænke på fremtiden. Et af mine primære
problemer er såmænd ikke performance, men plads. Pladskravene stiger med en
hastighed hvor det er ganske svært at følge med og besværligt at
administrere hvis man ikke har tænkt på at det vil gå sådan mens man
designede sin storage.
Pt. har jeg en DW maskine der mens den blev implementeret blev sized til 2
TB, men i dag, 3 år efter, står den til opgradering fra 6 TB til 8 TB fordi
de 6 er brugt op. Det kræver en del planlægning at supportere den slags
udvidelser hele tiden. Nye FC kort, mere plads i computer rummet, flere
filsystemer, udvidelser af eksisterede o.s.v.

Det afhænger også af hvilket OS du vil køre på ??? Til unix, primært Tru64,
kender jeg et par bøger der er ganske gode.
Jeg er sikker på at Oracle også har noget om emnet, men kan ikke lige ryste
nogle titler ud af ærmet.

Der kan også tunes med Direct I/O og diverse operativsystem parametre.

Det bedste er hvis der er tale om en migration af noget eksisterende eller
implementation af noget som eksisterer andetsteds. I så fald mål på det
eksisterende og find ud af hvordan I/O mønstret er. Det gør det meget
nemmere at implementere det nye system korrekt.
Ofte er der højst en håndfuld, og meget isolerede, flaskehalse selv på en
stor maskine. Af disse er der typisk ikke alverden at hente i selve storage
designet da det ofte er database-designet, applikations-designet eller
ganske enkelt brugen der gør det til et hot-spot.

/Jesper



Torben Udengaard (27-01-2003)
Kommentar
Fra : Torben Udengaard


Dato : 27-01-03 23:34

Hej Jesper,

tusinde tak for svaret, imponerende svar! - nærmest beærede over du skrev så
meget!*S*

Men så stort er den foran stående implemtering ikke! (Desværre)

Idag køre Oraclen på en gammel NT 4, uden raid eller ligende! DB´erne er dog
spredt over to diske!

Oraclen bruges til opbevaring af meget stor grafik filer. Der er kun 10
brugere der har adgang pt. (stiger højest til 20). Fremtidige DB størrelse
regnes til 40Gb incl overload.

Planen er at investere i et par nye servere, som hhv. skal håntere Exchange
2000, Firewall, Terminal Server og sf. Oracle. Windows 2000 Server er valgt
som OS (Advanced hvis det er at fortrække)! Exchange 2000 og Oracle kommer
til at dele samme server (Samt andre nødvendige server funktionaliteter, så
som AD, DHCP, DNS, print og fildeling)!

Mit spg. (lidt mere uddybet):

Hvordan bør diskene være konfigureret og formateret, for at opnå best
preformanc? Tænker at mirrored diske best men....?

Er der andre parametre som kan indvirke på at Oraclen får optimalt "leve"
betingelser, så som ram, 2 processore eller 1Gb netkort?

Oracle DB er livsnerven, og derfor vigtigt at den får best mulige forhold,
dog skal de andre funktionaliteter også være der!

Håber der nogen der har et godt bud!

Mange hilsner

Torben



Jesper Frank Nemholt (28-01-2003)
Kommentar
Fra : Jesper Frank Nemholt


Dato : 28-01-03 08:57

"Torben Udengaard" <tud@mail.tele.dk> wrote in message
news:3e35b4e7$0$71612$edfadb0f@dread11.news.tele.dk...
> Hej Jesper,
>
> tusinde tak for svaret, imponerende svar! - nærmest beærede over du skrev

> meget!*S*
>
> Men så stort er den foran stående implemtering ikke! (Desværre)

OK.

> Idag køre Oraclen på en gammel NT 4, uden raid eller ligende! DB´erne er
dog
> spredt over to diske!
>
> Oraclen bruges til opbevaring af meget stor grafik filer. Der er kun 10
> brugere der har adgang pt. (stiger højest til 20). Fremtidige DB størrelse
> regnes til 40Gb incl overload.
>
> Planen er at investere i et par nye servere, som hhv. skal håntere
Exchange
> 2000, Firewall, Terminal Server og sf. Oracle. Windows 2000 Server er
valgt
> som OS (Advanced hvis det er at fortrække)! Exchange 2000 og Oracle kommer
> til at dele samme server (Samt andre nødvendige server funktionaliteter,

> som AD, DHCP, DNS, print og fildeling)!
>
> Mit spg. (lidt mere uddybet):
>
> Hvordan bør diskene være konfigureret og formateret, for at opnå best
> preformanc? Tænker at mirrored diske best men....?

Striped mirror er bedst til alt, men dyrt.
Mirror kan, afhængig af RAID controller give dig bedre læseperformance, mens
skrive performance typisk er lig med eller ringere end en enkelt disk.
RAID-3 eller 5 har god læseperformance men er som regel elendig til at
skrive. Nogle gange kombinerer man RAID-5 med striping for at få noget der
kommer tæt på striped mirror, men uden at skulle have dobbelt antal diske.
Personligt er jeg ikke meget for denne sidste metode da den ofte giver en
storage konfiguration der er uheldig den dag noget går galt eller skal laves
om.

> Er der andre parametre som kan indvirke på at Oraclen får optimalt "leve"
> betingelser, så som ram, 2 processore eller 1Gb netkort?

Afgjort. Rigeligt med RAM er guld værd or en database server, men der er
naturligvis en øvre grænse hvor det ikke længere kan betale sig at proppe
mere RAM i.
Det kan være svært at sige på forhånd hvor meget der er nødvendigt, men når
du har sat systemet op og har brugere på kan man følge normale regler m.h.t.
ORacle SGA tuning og komme frem til en SGA størrelser der giver tøt på 100%
hitrate og ikke forbedres nævneværdigt ved at forstørre SGA størrelsen.
Når du så har den SGA størrelse fastsat skal du bare have tilpas meget ram
derudover til operativsystem og andre applikationer.

2 processorer eller ej. Svært at sige, men jeg hælder til : Hellere færre og
hurtigere CPU'er end flere langsommere. Derfor, hvis det står mellem een
hurtig eller 2 mellemhurtige, så køb den hurtige. Samtidig, hvis økonomien
tillader så køb 2 hurtige fremfor 1
Ofte, selv med mange brugere, er der kun een langsom og CPU krævende SQL ad
gangen, og den vil afslutte hurtigere på en maskine med een hurtig CPU
fremfor 2 langsomme.
På den anden side gør det at du har 2 at en langsom og CPU krævende SQL ikke
genererer andre væsentligt da de typisk vil få CPU tid på den anden CPU.

Det er et svært valg når dt er mellem 1 eller 2 CPUer. 2 er som regel ikke
dobbelt så godt som 1. Ofte kun 1.5 -1.8.

På større maskiner er det lettere at vælge. Mine maskiner har typisk 8-32,
og her vælger jeg helst færre hurtigere fremfor flere langsommere. Sun folk
gør ofte det modsatte og bruger meget tid på at forklare at det er fordi det
giver bedre distribueret performance. Det er til en vis grad også korrekt,
men jeg tror nu reelt at humlen ligger i at SPARC generelt er en langsommere
CPU end f.eks. Power 4 eller EV6/EV7, så Sun er nødt til at have mange flere
CPU'er for at kunne følge med.
Set fra slutbrugere er min erfaring dog helt klart få hurtige er det bedste.
De fleste store maskiner jeg roder med har en forholdsvis lav runqueue og
vinder derfor intet ved at have et hav af CPUer, da der simpelthen ikke er
tilstrækkeligt med samtidige jobs til at udnytte dem. Det der tæller for
slutbrugeren er at de CPU'er der er får udført jobbet hurtigt.

Givet din databasetype så vurderer jeg at det er ganske god investering at
give maskinen gigabit ethernet og sørge for at resten af vejen til
klienterne også er velproportioneret, typisk switched fast ethernet. Du kan
evt. også kigge på gigabit ethernet helt til klienterne. Priserne på den
slags er faldet meget på det seneste.
Hvis klienterne henter disse grafikfiler ud til eres PC så vil det give
masser af netværkstrafik og masser af ren sekventiel I/O på databasen og
dens diske.

M.h.t. filsystem, blokstørrelse o.s.v., så kender jeg ikke NTFS godt nok til
at kunne sige noget konkret herom. Der skal du nok spørge en der kender
Oracle og NT, og Oracle på NT, indgående.

Iøvrigt et godt link at starte ud med : http://www.ixora.com.au/ . Det er
primært Oracle relateret, men siden kommer ind på mange aspekter, også
storage design.

/Jesper



Lars Dybdahl (27-01-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 27-01-03 23:02

Torben Udengaard wrote:
> Er der nogen her i nyhedsgruppen der har kendskab til, hvordan HD
> konfigurationen bør være for at få best preformanc på en Oracle DB?

Databasen på et disksystem, log'en på et andet og resten på et tredje.
Herudover bør du også tune mht. clusterstørrelser osv.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

Torben Udengaard (27-01-2003)
Kommentar
Fra : Torben Udengaard


Dato : 27-01-03 23:36

Hvad er så den anbefalede clusterstørrelse på W2K?

TU

"Lars Dybdahl" <lars@dybdahl.dk> skrev i en meddelelse
news:3e35ac4d$0$13191$edfadb0f@dread11.news.tele.dk...
> Torben Udengaard wrote:
> > Er der nogen her i nyhedsgruppen der har kendskab til, hvordan HD
> > konfigurationen bør være for at få best preformanc på en Oracle DB?
>
> Databasen på et disksystem, log'en på et andet og resten på et tredje.
> Herudover bør du også tune mht. clusterstørrelser osv.
>
> Lars.
>
> --
> Dybdahl Engineering
> http://dybdahl.dk/



Kjeld Flarup (01-02-2003)
Kommentar
Fra : Kjeld Flarup


Dato : 01-02-03 00:52

Torben Udengaard wrote:
> Har prøvet Oracles hjemmeside! (minder om en rodebutik)

Har du adgang til MetaLink (kræver support aftale), der er der alle de gode
dokumenter ligger.

--
------------------------- Med Liberalistiske Hilsner --------------------------
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Ådalen 8, Mogenstrup, 7800 Skive, Tlf: 40 29 41 49, Fax: 96 95 74 48
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


Olav M.J. Christians~ (08-02-2003)
Kommentar
Fra : Olav M.J. Christians~


Dato : 08-02-03 09:47

"Kjeld Flarup" <kjeld.flarup@liberalismen.dk> skrev i en meddelelse
news:3e3b0c2e$0$11077$edfadb0f@dread12.news.tele.dk...
> Har du adgang til MetaLink (kræver support
> aftale), der er der alle de gode dokumenter ligger.

Du kan signe dig op på OTN (Oracle Technology Network) gratis.

Ellers prøv at kigge her: http://tahiti.oracle.com/ hvis der er noget
konkret du leder efter.

--
M.v.h.
Olav M.J. Christiansen - OCP
http://www.experit.dk
Fjern intet for at skrive til mig



Søg
Reklame
Statistik
Spørgsmål : 177501
Tips : 31968
Nyheder : 719565
Indlæg : 6408522
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste