Volgens Microsoft SQL Master, Brent Ozar, heeft hij gedurende zijn carrière een aantal vreselijke beslissingen genomen over het afstemmen van databaseprestaties. Gelukkig voor ons kunnen we profiteren van zijn fouten en hoeven we niet alles zelf uit te zoeken. Hij heeft zijn zuurverdiende wijsheid gratis gedeeld tijdens de webcast-serie Database Training Days van Quest.
In een van zijn sessies leerden we "Waarom het defragmenteren van uw indexen niet helpt." Het zou zelfs de prestaties van uw database kunnen verslechteren, en Brent vertelde ons waarom. Onderweg benadrukte hij hoe belangrijk het is om te weten wat je meet als het gaat om het optimaliseren van de prestaties van SQL Server.
Interne versus externe fragmentatie
Brent gaf ons een korte tutorial over de manier waarop SQL Server gegevens opslaat in 8 KB "pagina's". In een nieuwe of herbouwde index zijn de pagina's allemaal vol en op volgorde opgeslagen. Maar naarmate er meer gegevens worden toegevoegd, worden pagina's gesplitst:niet alle pagina's zijn vol en ze komen niet in de juiste volgorde voor. Dit is het essentiële verschil tussen interne en externe fragmentatie:
- Externe fragmentatie – verwijst naar pagina's die niet in orde zijn
- Interne fragmentatie – verwijst naar de lege ruimte op een pagina
Focus op minder splitsingen op de pagina
Veel databaseprofessionals richten zich op paginasplitsingen als een maatstaf voor databasefragmentatie, maar Brent legde uit dat dit aantal zinloos is omdat paginasplitsingen zowel optreden bij het toevoegen van een nieuwe rij aan een lege tabel als bij het toevoegen van een nieuwe pagina. Dus het is toch niet handig.
Hoe externe fragmentatie de zaken erger kan maken
In deze sessie beweerde Brent dat externe fragmentatie geen bruikbare maatstaf is voor databaseprestaties, aangezien paginavolgorde niet veel invloed heeft op de snelheid van onderhoudstaken, het uitvoeren van query's in RAM of het lezen van gegevens van schijf. Dus databaseprofessionals die externe fragmentatie proberen op te lossen door indexen te reorganiseren en opnieuw op te bouwen, verslechteren de prestaties in feite door back-ups op te blazen en meer onderhoudstijd te gebruiken.
Databaseprofessionals die externe fragmentatie proberen te verminderen door ruimte op pagina's te laten door een vulfactor in te stellen, veroorzaken ook een probleem dat erger is dan het probleem dat ze proberen op te lossen. Dit komt grotendeels omdat u bijna nooit gegevens halverwege de index hoeft in te voegen. Dus proberen pagina's op orde te houden door minder gegevens op elke afzonderlijke pagina te plaatsen, veroorzaakt in feite interne fragmentatie.
Wachttijd bewaken
Wat moet u in plaats daarvan doen? Brent adviseert om de vulfactor in te stellen op de standaardwaarde van 100% (of ten minste 80% of hoger) en vervolgens de indexen opnieuw op te bouwen om ze opnieuw in te pakken. Concentreer u vervolgens op het bewaken van het juiste prestatieafstemmingsnummer - wachttijd. Een van de beste manieren om verschillende aspecten van de wachttijd in uw database-instanties te bekijken, is door een prestatiebewakingstool te gebruiken om precies vast te stellen waar processen vastlopen.
Voor nog meer inzichten van Brent over indexfragmentatie, wachttijdstatistieken en wat u zou moeten doen aan indexonderhoud, luistert u naar de on-demand webcast.
U kunt ook toegang krijgen tot meer deskundig advies over databaseprestaties via de Database Training Days van Quest.