Onze DBA spreekt wartaal

Herken je dit? Je hebt een probleem met de performance van je applicatie of rapportage. Je vraagt aan de database administrator (DBA) wat er aan de hand is. Vervolgens krijg je een waterval aan vaktermen. De DBA spreekt een taal die je niet verstaat. Toch is het wel handig als je iets van de taal begrijpt.

Wat gebeurt er precies als je een rapport maakt met gegevens uit een database?

Als je een rapport start dan stuurt het programma een vraag naar de database. We noemen deze vraag een ‘SQL statement’ of ‘query’. Je wilt bijvoorbeeld de naam, het adres en de woonplaats weten van de klanten die in 2020 meer omzet hadden dan € 500.000,-. Het rapport stuurt deze vraag niet in het Nederlands naar de database. De taal die het rapport gebruikt is ‘Structured Query Language’ of afgekort SQL.

Vroeger zou ik je het proces uitleggen met twee kaartenbakken. Maar ook ik ga mee met de tijd en doe dit nu aan de hand van een Excelsheet met twee tabbladen. We hebben een Excelsheet met daarin klant- en omzetgegevens. In het eerste tabblad staat het klantnummer, naam, adres en woonplaats. In het tweede tabblad staat het klantnummer, omzetdatum en het omzetbedrag.

SQL combineert de twee tabbladen om het antwoord terug te sturen.

Klanten (eerste 5 regels)

Omzet (eerste 5 regels)

Het antwoord komt terecht bij de Query Processor

We hebben de eerste twee begrippen gehad. Ik hoop dat je nog niet afhaakt. Nadat het rapport het SQL statement heeft verstuurd, komt dit terecht bij de ‘Query Processor’. Dit is het brein dat de ervoor zorgt dat de gegevens correct en efficiënt in het rapport verschijnen.

De Query Processor werkt een vast stappenplan af:

Bovenstaand figuur laat zien hoe het Query Processor-proces verloopt.

Stap 1: Parsing

Tijdens deze eerste stap controleert de Query Processor of het SQL statement foutloos geschreven is. Er wordt een spellingcheck en grammaticacontrole uitgevoerd.

Stap 2: Binding

Het ‘SQL statement’ is zonder fouten geschreven. De Query Processor controleert nu of alle onderdelen die in het statement staan in de database aanwezig zijn. In ons voorbeeld zijn dat bijvoorbeeld de naam, het adres, de woonplaats en de omzet.

Stap 3: Query optimization

Zodra stap 1 en 2 goed doorlopen zijn, volgt het ingewikkelde gedeelte. De Query Processor gaat nu het plan maken. Het optimalisatieproces krijgt de vraag (query) in hapklare brokken aangeboden (algebrizer tree). Je kunt dit vergelijken met een project. We hebben eerst de projectdefinitie bepaald. Vervolgens hebben we de projectstappen gemaakt. We moeten nu nog van de logische stappen fysieke stappen maken. Kortom: het bepalen van elke functie die nodig is en het maken van een inschatting van de benodigde capaciteit.

Dit plan moet:

• de juiste gegevens uit de database halen;
• zo efficiënt mogelijk; en
• binnen het gestelde tijdslimiet gereed zijn.

We noemen deze strategie ‘cost-based’. Het uitvoeren van de query moet zo min mogelijk tijd en capaciteit kosten. Op deze manier wil je als bedrijf ook werken.

Ook heeft de query processor nog wat gereedschappen beschikbaar. De belangrijkste:

• Statistieken over de inhoud van de tabellen. De kengetallen die je in een project gebruikt om een inschatting te maken.
• Een archief (cache) met query-plannen van eerder uitgevoerde query’s. Een soort ‘best practices’ in je projectomgeving.
• Zoekstructuren (indexen) om op een snelle manier de gegevens in de tabellen te vinden.

De randvoorwaarden zijn geschetst. Nu de vraag aan de query processor: maak binnen 10 seconden een plan om de gevraagde gegevens op de meest efficiënte manier samen te stellen. Het is duidelijk dat er meerdere oplossingen mogelijk zijn. Hoe zou jij dit oplossen?

Het maken van een plan kost best veel tijd. Dit zijn de eerste acties die de Optimizer uitvoert:

• Is deze query al eerder uitgevoerd?
• Zijn de statistieken nog hetzelfde als in dit eerdere plan?

Het opgeslagen plan hoeft niet altijd het beste plan te zijn. Voorbeeld: de Optimizer heeft op basis van de statistieken bepaald dat er 5 klanten aan de voorwaarde van omzet > € 500,000.00 voldoen. Maar in werkelijkheid zijn het er 100. Dan zou het best kunnen dat een ander query-plan veel beter zou zijn. Toch kiest de Query Processor het opgeslagen query-plan.

Als er geen eerder plan is gevonden, dan moet de Query Optimizer een nieuw plan maken. Als ik het voorbeeld erbij pak, dan komen de volgende vragen in me op:

• Zijn er zoekstructuren (indexen) die we kunnen gebruiken?
• Zoeken we eerst de gegevens van 2020?
• Berekenen we eerst de omzet per klant en jaar?
• Gaan we klant voor klant door de klanttabel?
• Wanneer plaatsen we het filter op de omzet?
• Over hoeveel data gaat het (statistieken)?

Er zijn best wel veel manieren die je kunt verzinnen om de query op te lossen. Het is aan de Optimizer om te bepalen welk plan er gekozen wordt, in welke volgorde deze uitgevoerd wordt en welke het meest efficiënt is. Dit moet dan ook nog binnen het tijdslimiet. Je kunt je dan ook voorstellen dat de Optimizer niet altijd de tijd heeft om het meest efficiënte plan te maken.

Stap 4: Query execution

In deze laatste stap voert de Query Processor het geoptimaliseerde plan uit. Als we het vergelijken met een project, dan voeren de projectmedewerkers de projectstappen uit volgens het projectplan. Het verschil met een project is dat bijstellen van het plan niet mogelijk is gedurende de uitvoer van het plan.

Rol DBA

De DBA heeft gereedschappen om dit proces te volgen en te analyseren. Op basis van deze analyse kan de DBA aanpassingen doen in de database-omgeving die het resultaat van de Query Optimizer beïnvloeden en zo de performance van de query’s kan verbeteren.

DBA-woordenboek

We hebben je in deze blog een spoedcursus DBA-taal gegeven. Voor het gemak geven we je ook een woordenlijst mee:

• SQL statement: vraag aan de database
• Query: vraag aan de database
• Structured Query Language (SQL): taal die het rapport gebruikt
• Query Processor: brein dat gegevens correct en efficiënt in het rapport zet
• Parsing: stap in het Query Processor-proces, waarbij een spellingcheck wordt uitgevoerd
• Binding: stap in het Query Processor-proces, waarbij gecontroleerd wordt of alle onderdelen van het statement in de database staan
• Query optimization: stap in het Query Processor-proces, waarbij een plan gemaakt wordt om de vraag op te lossen
• Query execution: uitvoering van het geoptimaliseerde plan

Veel succes in het volgende gesprek met de DBA!