Performance Tuning

Uge 24: Vedligeholdelse af databaser

Så er der gået 24 uger siden jeg startede denne følgeton om Performance Tuning på SQL serveren. Så dette er sidste indlæg i rækken og kommer til at handle om vedligeholdelse af databaser.

Vedligeholdelse af databaser er en lige så kritisk opgave som at få den bedste performance ud af databaserne. En SQL database fungerer lidt som en bil; den skal have eftersyn en gang imellem for at tilsikre at den kører som den skal og yder bedst muligt. Een af de vigtigste elementer af denne del er vedligeholdelsen af index og deres relaterede objekter omkring statistics.

Vedligeholdelse af Index

Index bliver fragmenteret over tid og statistics skal opdateres så query optimizeren kan producere en execution plan som er “god nok”.

Fragmentation af index (både Clustered og Non-Clustered) betyder at den logiske og fysiske sortering ikke er ens. Hvis data er gemt på rotationsdiske afleder det vilkårlige læse-operationer på tværs af hele disken med en negativ I/O performance. Det samme gør sig også gældende på SSD diske, men ikke i så udbredt grad.

Microsoft har udstukket en række best practice omkring vedligeholdelse af index:

  • Fragmentation under 10%: Gør intet
  • Fragmentation mellem 10% og 30%: Udfør Index Reorganize operationer
  • Fragmentation over 30%: Udfør Index Rebuild opreationer

Hertil skal man huske på at Index Reorganize og Index Rebuild kun bør ske når index har mindst 10.000 pages på leaf-level. Hvis man har færre end det, vil man ikke opleve den den store negative effekt ved et fragmenteret index. En Index Rebuild genskaber hele index fra bunden af. Det er også en af de helt store transaktioner som er fuldt logget i transaktionsloggen. Derfor er det også ret skidt at lave en rollback ved 99% af færdiggørelsen. Statistics bliver også opdateret – af naturlige åsager, idet index bliver genskabt.

Hvis man anvender high availability opsætninger med database mirroring som baserer sig på transaktionsloggen, så vil man også opleve en stor performance nedgang ved en Index Rebuild. SQL Serveren skal “sende” alle transaktioner til replika og dermed kan man overfylde sit netværk med datastrømme og påvirke sin high-availability strategi.

Dets alternativ Index Reorganize tager kun fat i leaf-level af index og arrangerer disse pages i korrekt logisk rækkefølge. Derfor vil Index Reorganize heller ikke opdatere statistics. En sådan operation består af flere mindre transaktioner og vil derfor kun påvirke transaktionsloggen i mindre grad. Ligeledes vil det også have en mindre påvirkning af high-avaliability og netværk.

“How to” vedligeholdelse af databaser

Der er mange veje i mål her – een af dem jeg ikke vil anbefale er den indbyggede Database Maintenance Plans som kommer ud af boksen med SQL serveren. Denne tilgang arbejder med SQL serveren med en stor forhammer og vil altid lave en reorganize/rebuild uanset status på index og fragmentationen.

Det er set at jobbet til Database Maintenange som er kørt hele natten for at opdatere index uden eller med kun meget lidt fragmentation – det er lidt tosset at bruge alle de ressourcer på den slags unødigt arbejde.

Der findes andre og meget bedre løsninger som tilmed også er gratis. Bl.a. Brent Ozar og Ola Hallengren har lavet nogen ret lækre løsninger til dette formål. Begge løsnigner har en række stored procedures som man kan kalde og få returneret status på bl.a. consistency checks, backups, index maintenance osv osv.

Du kan finde løsningerne her (og det er ikke reklame, kun min egen lyst til at dele):

Opsummering og tak for denne gang – Vedligeholdelse af databaser

Det var så det sidste indlæg i denne række om SQL Server Performance Tuning.

Jeg har gennem de sidste 24 uger og indlæg, forsøgt at hjælpe dig, som læser, godt på vej med at forstå den underliggende struktur og motor i SQL serveren, og dermed blive bedre til at selv at finde og løse problemerne med performance.

Tak for at følge med – og måske vi “læses ved” en anden god gang.

Få besked om næste indlæg

Skriv dig gerne op til at modtage en mail, ved næste indlæg. Det kan du gøre nedenfor.



Marketing stuff

Our emails contain marketing stuff, so we need to give you some fine quality fine print: brianbonk will use the information you provide on this form to email you with updates and marketing. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, or by contacting us at help@brianbonk.dk. We use Mailchimp as our marketing platform. By checking the box to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing, and that we may process your information in accordance with these terms.

Følg mig på Instagram

Leave a Reply

Your email address will not be published. Required fields are marked *

en_USEnglish