Katmai, het territorium in Alaska waar de nakende SQL Server 2008 naar vernoemd is, staat bekend om zijn vele vulkanen. Dat is misschien niet het beste symbool voor een database, maar totnogtoe is huidige RC van SQL Server 2008 nog niet in mijn gezicht ontploft. Het iets kleiner gebrachte Katmai lijkt een waardige opvolger te worden van Yukon, oftewel het gigantische SQL Server 2005.

Katmai borduurt voort op de geweldige, op de onderneming gerichte verbeteringen die SQL Server 2005 al bracht, en het heeft een paar heel aardige nieuwe functies voor grote omgevingen. Een paar van de meest genoemde verbeteringen in de engine zijn de compressie van data en backup, besparende kolommen (de functie dat lege kolommen automatisch geen ruimte innemen) en gecomprimeerde en gefilterde indexes gericht op het besparen van ruimte, en Change Data Capture, waarmee veranderingen aan productiedatabases in tabellen opgeslagen kunnen worden zodat de data warehouse kan worden geupdate.

Dit is nog maar een topje van de ijsberg (of vulkaan?), want er zijn nog veel meer nieuwigheden, zoals op beleidsregels gebaseerd beheer, waarmee zowel kleine als grote bedrijven uit de voeren kunnen. Elk aspect van het product is flink onder handen genomen.

Meer data, minder opslag

Om te beginnen zijn er twee soorten datacompressie: rij en pagina. Deze pakken de gegevens op een andere manier in, dus het is belangrijk om te weten wat de voordelen van elk zijn, en hoe ze werken. Rijcompressie is echte compressie, waarbij de engine ongebruikte ruimtes aan het eind van kolommen verwijdert. SQL Server gebruikt deze techniek al voor vardecimale compressie, maar Microsoft heeft het dus uitgebreid naar andere datatypes.

Paginacompressie doet wat ook wel bekend staat als dictionary compression; het normaliseert de gegevens op elke pagina en houdt een referentiepointer achter de hand. Oracle Database 11g gebruikt min of meer dezelfde truc, al noemen ze het daar Oracle Advanced Compression. Zonder te erg in te gaan op de voor- en nadelen van elk, moet gezegd worden dat de paginacompressie in SQL Server ook doet aan rijcompressie op lagere niveaus. Met andere woorden: als paginacompressie aan staat, dan staat rijcompressie automatisch ook aan.

Microsoft levert een paar opgeslagen procedures mee om u te helpen met het inschatten hoeveel besparing er met welke methode te behalen valt, en hoeveel de database na het uitpakken weer groeit. Dit is een belangrijke en attente functie, want het is niet alleen nodig om te weten of de compressie de verbruikte tijd waard is, maar ook of de schijf de gegevens na uitpakken nog wel aankan als u het weer terug moet zetten. Hou wel in het achterhoofd dat het systeem gebruikt maakt van slechts een kleine maar significante steekproef van uw gegevens, en dat het dus mogelijk is dat de schattingen flink afwijken als de opdracht net een slechte representatie van uw data kiest.

De manier waarop compressie wordt aangepakt, bespaart meer dan opslagcapaciteit alleen. Ook in het geheugen blijven de gegevens ingepakt totdat ze daadwerkelijk gelezen worden, dus dat betekent meer pagina's in het geheugen. Daarmee daalt het aantal grepen naar de schijf, en de belasting van de processor zal een stuk lager uitvallen dan wanneer de data van de schijf moet worden gehaald.

De besparende kolommen maken het mogelijk om null-waarden op te slaan zonder dat deze enige fysieke ruimte innemen. Het aantal Null-waarden kan flink oplopen in een grote tabel, waarvan het bijhouden een aanslag kan betekenen op de schijfruimte. Nulls opslaan in de besparende kolommen kost geen ruimte, dus de benodigde opslag krimpt ook.

Groot probleem met de besparende kolommen is wel dat deze geen compressie toelaten. Dit is een ronduit grote fout van Microsoft, en ik hoop dat ze hun gebruikers eer aan doen en die functie meegeven in een service pack, en niet pas in een volgende versie. Verwacht in de tussentijd niet dat het mogelijk is om uw gegevens in een tabel te comprimeren wanneer er besparende kolommen zijn gedefinieerd. Ik weet eerlijk gezegd niet wat Microsoft bezielt, maar dit mag niet zo uitkomen. Besparende kolommen met compressie is een geweldige combinatie, en dit zou wel eens een dooddoener kunnen zijn.

Gecomprimeerde indexen is precies zoals het klink: nog een manier om opslagruimte te besparen. Gefilterde indexen maakt het mogelijk om net als bij een zoekvraag een 'waar' clausule op de index te plaatsen, zodat slechts een deel van de tabel geïndexeerd wordt. Dat lijk contraproductief, maar er zijn zeker gevallen te bedenken waarbij het filteren van de index wensbaar is. Het perfecte voorbeeld is de besparende kolom. In plaats van een index te behouden met allemaal nullwaardes, kunt u een index bouwen op de kolommen waar de waarde ongelijk is aan null. Dan worden alleen de werkelijke waardes meegenomen, en is de index opeens een stuk kleiner.

Goede werklast, slechte werklast

De Resource Governor is de eerste echte poging van Microsoft om een SQL Server uit te rusten met een werklastbeheerder. Maar, om eerlijk te zijn, deze kan nog niet echt op tegen de werklastbeheertool van Oracle. SQL Server 2008 maakt het mogelijk om limieten te stellen op verbruik door geheugen en CPU, wat een goed begin is, maar die dit soort dingen zijn dikwijls niet genoeg om een losgeslagen werklast te definiëren.

Om het even voor Microsoft op te nemen: het is ook nog niet de bedoeling van Resource Governor om rogue zoekvragen te definiëren. Deze eerste versie hoeft alleen nog maar om een plafond te stellen aan de hulpbronnen voor werklasten, om zo te voorkomen dat deze in eerste instantie al losslaan. Dat lost uiteraard het probleem van bovenmatig schijfverbruik of verwerkingstijd niet op, en het is nog niet mogelijk om een proces automatisch te verplaatsen naar een gedefinieerde Resource Governor als hij te veel hulpbronnen begint te verbruiken. Of een proces is al toegewezen aan een governor en heeft een plafond meegekregen, of niet.

Het grootste voordeel valt met dit systeem volgens mij te halen op OLTP-systemen, waar een beetje reporting soms nodig is en dit niet te veel van de systeembronnen mag kapen. De processen van zoekvragen kunnen in hun eigen governor worden geplaatst, en het plafond kan zo worden ingesteld dat het grootste gedeelte van de kracht van de server kan worden aangewend voor dingen die daadwerkelijk geld in het laadje brengen.

Change Data Capture (CDC) is een hele aardige functie die vooral erg populair kan worden onder beheerders die met ETL-processen te maken hebben. Met CDC kan SQL Server bijhouden welke rijen en kolommen hoe veranderd zijn, en deze vervolgens in een aparte tabel die met ETL kan worden aangeroepen. Zo is het mogelijk om erachter te komen welke rijen en kolommen zijn toegevoegd, weggehaald of veranderd, zonder dat hier ingewikkelde aanvragen voor nodig zijn. Het is nu verre van eenvoudig om dit soort bewerkingen in een tabel op te sporen, dikwijls moet er code in het proces bijgeschreven worden om ze aan te duiden. Met CDC kunnen deze policies echter op databaseniveau worden gedefinieerd, en zijn drastische veranderingen in de applicatiecode niet nodig.

Deze uitgave brengt ook Policy-Based Management (PBM), oftewel beheer met beleidsregels, waarmee regels voor een elke hoeveelheid aan systemen worden ingesteld die corrigerend of waarschuwende werken als een server de policy niet nakomt. Bijna alles is voor die beleidsregels in te stellen, dus zelfs zoiets als een zekering dat geen enkele tabel vooraf wordt gegaan met de 'tbl' prefix is een mogelijke beleidsregel. Maar een regel als dat elke database dagelijks een backup moet krijgen is ook mogelijk, waarbij een waarschuwing wordt afgegeven als een van de servers geen backup draait. PBM lijkt een erg krachtige tool te worden, en het bevalt me wel van wat ik totnogtoe gezien heb.

De kroonjuwelen

Katmai heeft te veel nieuwe functies om in een keer aan te snijden. Zo heb ik niet eens een kans gehad om de bijna compleet herschreven SQL Server Reporting Services te bekijken, of SQL Server Integration Services, of SQL Server Analysis Services. En dan blijven nog de management data warehouse, interactieve Dundad drill-down reports, IntelliSense, die nieuwe activiteitsmonitor, integratie met PowerShell en veel meer dingen op de plank liggen.

Maar het grote nieuws in SQL Server 2008 zal voor de meeste gebruikers toch de datacompressie en CDC zijn, omdat deze invloed hebben op een zaak die bedrijven direct raakt: het budget. De Resource Governor is aardig, maar het is denk ik nog te onvolwassen en het heeft te veel beperkingen om het de hit te maken waar Microsoft op hoopte. Het zal nog wel een paar uitgaven duren voordat het groeit tot iets waar Microsoftklanten echt veel profijt van hebben.

Gecomprimeerde en gefilterde indexen gaan wel een direct verschil maken, en ondanks de valkuilen met de gefilterde indexen bieden deze de voordelen die verwacht mogen worden. De tools hebben ook een paar flinke verbeteringen meegekregen, maar ze zullen nog steeds teleurstellend zijn voor beheerders die niet als ontwikkelaars behandeld willen worden. Maar zo lang als het duurde om SQL Server 2005 uit te brengen, is dit toch de versie die SQL Server 2005 vanaf het begin had moeten zijn. Bron: Techworld