1 / 15

Databasetuning

Databasetuning. Progress brukermøte Huso 2003; Jan Kolstad. Progress og ProVentus. ProVentus er Progress sin samarbeids-partner innen tuning ProVentus har spesialister på tuning ProVentus bruker mye tid på tuning. Om tuning. Krever omfattende erfaring med Progress

yoshiko-emiko
Download Presentation

Databasetuning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Databasetuning Progress brukermøte Huso 2003; Jan Kolstad

  2. Progress og ProVentus • ProVentus er Progress sin samarbeids-partner innen tuning • ProVentus har spesialister på tuning • ProVentus bruker mye tid på tuning

  3. Om tuning • Krever omfattende erfaring med Progress • Involverer både drift og utvikling • Kan gjøres som skippertak eller som normalt vedlikehold

  4. Systemhelsesjekk • Samarbeidsprosjekt mellom Progress og ProVentus • Skal bidra til å avdekke og heve nivået på driftsmiljøene i Norge

  5. Erfaring fra helsesjekken • Databasen til Progress er megastabil • Kan kjøre med samme oppsett i mange år • Databasen krever ikke vedlikehold • ALLE har stort forbedringspotensiale

  6. Ønskemiljø • Progress versjon 9 • To eller flere prosessorer • Mye RAM • Mange harddisker, gjerne RAID • Databasemiljøet separert fra filserver

  7. Prioriterte områder • Harddisker • Memory • CPU • Database blocksize • Database storage areas • Serverprosesser • Checkpoints

  8. Harddisker • Bruk mange disker • RAID • Effektiv fordeling med RAID 0 • Raskt og sikkert med RAID 1/0 • Ikke bruk RAID 5 • BI fil på egen disk • Temp-directory på minst brukte disk

  9. Memory • -B settes høyest mulig • Langt mer effektiv enn OS cache • Ikke så høyt at swapping inntreffer • Les av buffer hits i Promon for å se effekten • Buffer hits • Bør være 95% • Påvirkes negativt av dårlig indeksbruk • Målinger forstyrres av online backup og høyt antall leste records • Start krevende rapportprosesser med private buffers (-Bp)

  10. CPU • Server bør ha mer enn én CPU • Flere prosessorer krever –spin for effektiv kjøring • Effektiv utnyttelse med bakgrunnsprosesser APW, BIW og AIW

  11. Database blocksize • Default størrelse er for lav • 8kb er et godt utgangspunkt • Ta hensyn til filsystemets blocksize (OS <= DB) • Husk å endre –B!

  12. Storage areas • Styrer måten data lagres på • Separate areas for data og indeks • Samle data med like egenskaper i samme area • Bruk ”dbanalys” for info • Tilgjengelig fra 9.1

  13. Serverprosesser • Serverprosesser reduserer skriving fra server og self-service klienter • Asyncronous Page Writer (APW) • Skriver for checkpoint før checkpoint inntreffer • Øk antall avhengig av checkpoints • Start BIW og AIW

  14. Checkpoints • Synkroniserer database i memory med database på disk • Inntreffer jevnlig • Ikke for ofte (< 1 per minutt) • Kan forårsake ”heng” i systemet • Kontrolleres med APW’er og BI-fil

  15. Databasetuning • Default oppsett er ikke best for noen • Hindrer ikke dårlig koding • Bruk spesialister for skippertak • Overvåk systemet • Belastning endres stadig • Dårlige programmer avsløres • Vurder Fathom!

More Related