Nieuws

SQL Server is geen Black Box

Meestal sta je als ontwikkelaar niet vaak stil bij de manier waarop SQL Server zijn taken uitvoert. In de loop der jaren is de techniek dusdanig verbeterd en slimmer geworden dat dit (gelukkig) ook niet meer noodzakelijk is. Je stelt een vraag in de vorm van een query aan de Database Engine, en na verloop van tijd (hopelijk niet te lang) krijg je een antwoord terug. Sterker nog, met allerlei ORM tools als Entity Framework, NHibernate, LINQ to SQL, et cetera schrijf je zelf niet eens meer de query’s, maar worden deze voor je gegenereerd.

Niets aan de hand zou je zeggen. Tot het moment dat de eerste tekenen van traagheid beginnen te ontstaan. Die problemen kunnen tal van oorzaken hebben, bijvoorbeeld als gevolg van lazy loading bij veel ORM frameworks, waardoor een ogenschijnlijk simpele loop zorgt voor een stortvloed aan query’s richting de database. Maar ook niet zelden ligt de oorzaak bij niet optimaal presterende query’s. Een voor de hand liggende oplossing is het upgraden van de hardware (meer geheugen, snellere CPU, meer CPU’s), echter, vaak stelt dat het onderliggende probleem alleen maar uit.

In die gevallen is het goed om te realiseren dat SQL Server geen Black Box is waar je ‘niet in kunt kijken’ om te zien wat er gebeurt. Twee handige features die meegeleverd worden zijn de Query Analyzer en de Profiler. Afhankelijk van het probleem dat optreedt zijn een (of beide) van deze tools je beste vriend!

SQL Server Query Analyzer

Met de Query Analyzer kun je inzichtelijk krijgen hoe SQL Server jouw query uitvoert. Welke tabellen worden als eerste geraadpleegd, van welke indexen wordt daarbij gebruik gemaakt? Worden de indexen optimaal benut, of worden ze volledig gescand? Bieden de indexen voldoende informatie om tot een resultaat te komen (zgn Covering Indexes), of worden er nog lookups uitgevoerd om aanvullende gegevens op te halen? Kloppen de schattingen waar de Query Optimizer van uit is gegaan bij het bepalen van het Execution Plan?

Dit zijn allemaal vragen die beantwoord kunnen worden met behulp van de Query Analyzer, waarna je op zoek kunt naar een oplossing. Met behulp van deze gegevens kun je bijvoorbeeld gericht een index aanpassen of toevoegen.

SQL Server Profiler

Met de Profiler kun je inzicht krijgen in de taken die SQL Server allemaal uitvoert. Dit kan variëren van een overzicht van alle query’s die uitgevoerd worden, met daarbij behorende indicatoren als doorlooptijd, aantal schrijf/lees acties, CPU tijd, et cetera. Maar ook kun je tot in detail inzichtelijk krijgen hoeveel locks er geplaatst worden, op welke objecten, welk type locks dit zijn en op welke locks gewacht wordt tot deze zijn toegekend. Met behulp van deze gegevens kun je de zoektocht naar de oorzaak van de traagheid verder voortzetten.

Generaliserend kun je bijvoorbeeld stellen dat, wanneer er een hoog aantal leesacties zijn ten opzichte van het aantal resultaten van de query, dat de juiste indexen ontbreken of niet optimaal zijn. Vergelijk het met het bladeren in een ongesorteerd telefoonboek: voor het zoeken van een telefoonnummer zal je een hoop pagina’s door moeten bladeren (lezen) voordat je bij het juiste resultaat komt. Andersom, als er een hoop schrijfacties zijn voor één insert, betekend dit dat er veel indexen bijgewerkt moeten worden. Zijn al die indexen wel nodig?

Indien de doorlooptijd van de query lang is, maar er niet enorm veel CPU / IO tijd besteedt wordt, kan dit duiden op locking problemen. In dat geval is het handig te weten welke locks er geplaatst worden voor het uitvoeren van de query, en op welke locks gewacht wordt met toekennen. Wat voor type locks zijn dat, en waar komen die locks vandaan? Staan er bijvoorbeeld langdurige transacties open, of worden query’s misschien met een te pessimistisch Isolation Level uitgevoerd?

Geen Black Box

Veel database intensieve applicaties krijgen vroeg of laat te maken met performance issues. Helaas is de techniek nog niet zó slim dat deze problemen nooit meer optreden. Wanneer ze optreden is het echter belangrijk te weten dat SQL Server uitgebreide tooling biedt om het probleem verder te analyseren om zo tot een oplossing te komen. Natuurlijk zijn een aantal problemen te verhelpen door bijvoorbeeld gebruik te maken van caching, maar als je daarbij niet oplet kun je al snel vervallen in symptoombestrijding. Grote kans dat dit je vroeg of laat tegen zal werken, en dan meestal op de momenten dat je dit het minst kunt gebruiken. Ervaar je traagheid bij je data-toegang, dan is het goed je te realiseren dat SQL Server geen ‘Black Box’ is.

Marcel Verweij, Seven Stars

Vragen over dit onderwerp? We helpen je graag.

Snel naar...