DataFacts.nl

Wat te doen als de performance van de queries op uw databaseserver te wensen overlaat

Natuurlijk probeert u uw queries te optimaliseren. Als dit geen oplossing biedt dan wordt het tijd om te kijken of uw databaseserver wel voldoende geheugen heeft. Een belangrijke indicator hiervoor is de ‘Page Life Expectancy’. Deze kunt u met de applicatie ‘perfmon.exe’ monitoren.

Page Life Expectancy
De PLE geeft aan hoeveel seconden een ‘page’ van 8kb gemiddeld in het Buffer Cache van SQL Server blijft staan. Zodra de PLE 100 is dan betekent dat gemiddeld iedere page in het Buffer Cache eenmaal per 100 seconden wordt vervangen door een nieuwe page.

Tijdens het laden van deze nieuwe page wordt uw disk-systeem en vaak ook netwerk belast. Dit heeft meestal gevolgen voor de performance van de queries die gebruik maken van deze pages, immers deze worden eerst vanaf disk geladen.

Vaak wordt een grens van 300 seconden gehanteerd. Is uw PLE lager dan 300 seconden, dan kan uw databaseserver meer RAM gebruiken. Bij een PLE hoger dan 300 dan is dat vaak niet nodig.

Mijns inziens ligt dit wat genuanceerder. Het is namelijk afhankelijk van de hoeveelheid geheugen die uw SQL Server reeds beschikbaar heeft.

Voorbeelden
1) Bij een PLE van 50 voor een SQL Server met 8 Gb wordt elke 50 seconden 8 Gb aan data van disk in het buffer cache gelezen. Dat is circa 160 Mb per seconde.

2) Bij een PLE van 50 voor een SQL Server met 2 Gb wordt elke 50 seconden 2 Gb aan data van disk in het buffer cache gelezen. Dat is circa 40 Mb per seconde.

3) Bij een PLE van 200 voor een SQL Server met 8 Gb wordt elke 200 seconden 8 Gb aan data van disk in het buffer cache gelezen. Dat is circa  40 Mb per seconde.

De laatste 2 voorbeelden zullen de disk en het netwerk net zoveel belasten.

Mijn advies is daarom om de volgende formule te gebruiken om te bepalen of uw databaseserver genoeg geheugen heeft:
 

[Max Beschikbaar Buffer Geheugen] / [PLE]
mag niet hoger zijn dan 5.000.000.

Dat wil zeggen dat er gemiddeld niet meer dan 5mb/sec van disk mag worden gelezen. Is dit wel het geval dan heeft uw databaseserver meer geheugen nodig.

Vaak volstaat het om een SQL query te schrijven die functioneel het juiste resultaat oplevert zonder dat de snelheid van de query een rol speelt, bijvoorbeeld als één record moet worden opgehaald van een tabel die in mutatiescherm van een applicatie moet worden gebruikt.

Vaak is de snelheid waarmee de SQL query een resultaat oplevert wel heel erg belangrijk (Lees verder…)

Onlangs ben ik een conversie-uitdaging aangegaan waarbij 2.1 miljoen XML bestanden (relationele nawbestanden) geconverteerd/geimporteerd moesten worden naar een SQL server database in een afwijkend datamodel. Deze 2.1 miljoen XML bestanden gebruikten 4 verschillende XML formaten maar moesten wel allemaal ingelezen worden in het zelfde datamodel. Ik had de beschikking over een Windows server en SQL server 2005 om dit voor elkaar te krijgen.

Bij een dergelijke conversie loop je in ieder geval tegen de volgende uitdagingen aan:

• Windows kan niet meer dan ongeveer 64000 bestanden per map aan.
• Windows is niet gebouwd om snel met dit soort hoeveelheden bestanden om te kunnen gaan.
• Er moet XSL transformatie worden toegepast. (4 verschillende transformaties)
• De referentiele integriteit moet ‘buitenom’ bewaakt worden
• De codering van de karakterset

Ik heb dit conversietraject opgelost met behulp van SQL Server Integration Services (SSIS) en zal globaal uitleggen hoe ik dit heb gedaan. Let op! Alleen voor techneuten.

(Lees verder…)

Ik werk zelf veel met SQL Server en MySQL. Met name voor het schrijven van queries om gegevens te bevragen en te manipuleren. Sommige bewerkingen vragen dusdanig veel resources van een systeem dat ik deze queries ook snel (lees: korte executietijd) moet maken zodat deze efficient met de resources omgaan.

Om deze queries gemakkelijker te kunnen schrijven heb ik enige tijd geleden al een factsheet gemaakt waarop alle voor mij belangrijke functies, datatypen, checklijsten, symbolen en syntaxis voor SQL Server te vinden.

Deze cheat sheet (factsheet) past op een dubbelzijdig in kleur afgedrukt A4-tje en kan (het liefst gelamineerd) als naslag in de tas geschoven worden.

(Lees verder…)