Enligt Microsoft SQL Master, Brent Ozar, har han fattat några hemska beslut om inställning av databasprestanda under hela sin karriär. Lyckligtvis för oss kan vi dra nytta av hans misstag och behöver inte ta reda på allt på egen hand. Han har delat med sig av sin surt förvärvade visdom gratis under Quests webbsändningsserie för Databas Training Days.
I en av hans sessioner lärde vi oss "Varför det inte hjälper att defragmentera dina index." Faktum är att det kan göra din databas prestanda sämre, och Brent berättade varför. Längs vägen betonade han vikten av att veta vad man mäter när det gäller att optimera SQL Server-prestanda.
Intern kontra extern fragmentering
Brent gav oss en snabb handledning om hur SQL Server lagrar data på 8 KB-sidor. I ett nytt eller ombyggt index är alla sidorna fulla och lagrade i ordning. Men när mer data läggs till delas sidorna:inte alla sidor är fulla och de är ur funktion. Detta är den avgörande skillnaden mellan intern och extern fragmentering:
- Extern fragmentering – syftar på att sidor inte fungerar
- Intern fragmentering – hänvisar till det tomma utrymmet på en sida
Fokuserar mindre på siddelningar
Många databasproffs fokuserar på siddelningar som ett mått på databasfragmentering, men Brent förklarade att detta nummer är meningslöst eftersom siddelningar inträffar både när man lägger till en ny rad i en tom tabell och när man lägger till en ny sida. Så det är inte användbart trots allt.
Hur extern fragmentering kan göra saker värre
I den här sessionen hävdade Brent att extern fragmentering inte är ett användbart mått på databasprestanda eftersom sidordning inte har någon större inverkan på hastigheten på underhållsuppgifter, köra frågor i RAM eller läsa data från disk. Så databasproffs som försöker fixa extern fragmentering genom att omorganisera och bygga om index gör faktiskt prestandan sämre genom att blåsa upp säkerhetskopior och använda mer tid för underhållsperioden.
Databasproffs som försöker minska extern fragmentering genom att lämna utrymme på sidorna genom att ställa in en fyllnadsfaktor orsakar också ett problem som är värre än det de försöker fixa. Detta beror till stor del på att du nästan aldrig behöver infoga data vid en punkt mitt i indexet. Så att försöka hålla ordning på sidorna genom att lägga mindre data på varje enskild sida orsakar faktiskt intern fragmentering.
Övervaka väntetiden
Vad ska man göra istället? Brent rekommenderar att man ställer in fyllningsfaktorn till standardvärdet på 100 % (eller åtminstone 80 % eller högre) och sedan bygger om indexen för att packa dem igen. Fokusera sedan på att övervaka rätt prestandajusteringsnummer – väntetid. Ett av de bästa sätten att se olika aspekter av väntetid i dina databasinstanser är att använda ett prestandaövervakningsverktyg för att fastställa exakt var processer fastnar.
För ännu mer av Brents insikter om indexfragmentering, väntetidsstatistik och vad du bör göra om indexunderhåll, lyssna på webbsändningen på begäran.
Du kan också få tillgång till fler expertråd om databasprestanda genom Quests databasutbildningsdagar.