sql >> Database teknologi >  >> RDS >> Sqlserver

Brent Ozar forklarer SQL Server intern og ekstern fragmentering

Ifølge Microsoft SQL Master, Brent Ozar, har han truffet nogle forfærdelige beslutninger om justering af databaseydelse gennem hele sin karriere. Heldigvis for os kan vi drage fordel af hans fejl og behøver ikke finde ud af alt på egen hånd. Han har delt sin hårdt tjente visdom gratis under Quest's Database Training Days webcast-serie.

I en af ​​hans sessioner lærte vi "Hvorfor det ikke hjælper at defragmentere dine indekser." Faktisk kunne det gøre din databases ydeevne dårligere, og Brent udfyldte os om hvorfor. Undervejs understregede han vigtigheden af ​​at vide, hvad du måler, når det kommer til at optimere SQL Server-ydeevne.

Intern vs. ekstern fragmentering

Brent gav os en hurtig vejledning om, hvordan SQL Server gemmer data på 8 KB "sider." I et nyt eller ombygget indeks er siderne alle fyldte og gemt i rækkefølge. Men efterhånden som flere data bliver tilføjet, bliver siderne delt:Ikke alle sider er fyldte, og de er ude af drift. Dette er den afgørende forskel mellem intern og ekstern fragmentering:

  • Ekstern fragmentering – henviser til, at sider er ude af drift
  • Intern fragmentering – henviser til den tomme plads på en side

Fokusering af færre opdelinger på siden

Mange databaseprofessionelle fokuserer på sideopdelinger som et mål for databasefragmentering, men Brent forklarede, at dette tal er meningsløst, fordi sideopdelinger forekommer både, når du tilføjer en ny række til en tom tabel, og når du tilføjer en ny side. Så det er trods alt ikke nyttigt.

Hvordan ekstern fragmentering kan gøre tingene værre

I denne session hævdede Brent, at ekstern fragmentering ikke er et nyttigt mål for databasens ydeevne, da siderækkefølgen ikke har meget indflydelse på hastigheden af ​​vedligeholdelsesopgaver, kørsel af forespørgsler i RAM eller læsning af data fra disk. Så databaseprofessionelle, der forsøger at rette ekstern fragmentering ved at omorganisere og genopbygge indekser, gør faktisk ydeevnen dårligere ved at oppuste sikkerhedskopier og bruge mere vedligeholdelsesperiode.

Databaseprofessionelle, der forsøger at reducere ekstern fragmentering ved at efterlade plads på sider ved at indstille en udfyldningsfaktor, forårsager også et problem, der er værre end det, de forsøger at løse. Det skyldes i høj grad, at du næsten aldrig behøver at indsætte data på et punkt midtvejs i indekset. Så forsøg på at holde siderne i orden ved at lægge færre data på hver enkelt side forårsager faktisk intern fragmentering.

Overvågning af ventetid

Hvad skal du gøre i stedet for? Brent råder til at indstille fyldfaktoren til standardværdien på 100 % (eller mindst 80 % eller højere) og derefter genopbygge indekserne for at pakke dem igen. Dernæst skal du fokusere på at overvåge det rigtige præstationsjusteringsnummer – ventetid. En af de bedste måder at se forskellige aspekter af ventetid på på tværs af dine databaseforekomster er ved at bruge et ydelsesovervågningsværktøj til at lokalisere præcis, hvor processer hænger fast.

For endnu mere af Brents indsigt i indeksfragmentering, ventetidsstatistikker og hvad du bør gøre ved indeksvedligeholdelse, lyt til webcast on-demand.

Du kan også få adgang til flere ekspertråd om databaseydeevne gennem Quests Database Training Days.


  1. Vælg ulåst række i Postgresql

  2. Kan du få adgang til den automatiske stigningsværdi i MySQL inden for en erklæring?

  3. Vis navne på alle begrænsninger for en tabel i Oracle SQL

  4. SQL Server:Vedhæft forkert version 661