Vandaag het algemene overzicht en een paar geteste onderdelen. Morgen komen de rest van de functionaliteiten en de conclusie aan bod. Overzicht en inleiding

Bij het upgraden van mijn database hanteer ik een vijfpuntenregel: als een nieuwe versie mijn leven niet op vijf punten kan veranderen, dan is het geen belangrijke upgrade. Tijd is daarbij de hoeksteen: hoeveel uur heb ik per week nodig om bepaalde taken uit te voeren, en hoeveel uur gaat een upgrade mij besparen. Als ik bijvoorbeeld wekelijks vijf uur nodig heb om het gebruik van hulpbronnen te regulieren, dan is het een besparing van vijf uur als dit in een nieuwe versie wordt geautomatiseerd. Dan moet ik nog vier andere nieuwe functies vinden en op deze manier uitdrukken, en ik heb een verhaal tegenover de managers.

Ik neem aan dat het de meeste gebruikers van Oracle Database wel lukt om tenminste vijf van deze keerpunten des levens te benoemen in Oracle Database 11g. Maar er is een functie in de meest recente release, Real Application Testing, die dusdanig aanlokkelijk is dat een upgrade alleen daarom al de moeite is. Elk bedrijf rommelt wel eens aan de code, en elk bedrijf heeft daarom een betrouwbare manier nodig om workloads na te bootsen voor het testen van codeveranderingen.

En Real Application Testing doet dat. Als combinatie van Database Replay en SQL Performance Analyzer maakt Real Application Testing het mogelijk om een workload met bijbehorende prestatiecijfers op te nemen en waar dan ook te reconstrueren. De cijfers zijn daarna te vergelijken, met een diepgang waar de meeste andere databaseleveranciers nog moeite mee hebben.

Andere nieuwigheden in Oracle Database 11g zijn Snapshot Standby, Active Data Guard, Advanced Compression, verbeteringen aan hulpbronnenbeheer, het verscherpen van de SQL en controle op de systeemstatus.

Hoewel Active Data Guard vooral onder Windows problemen kent, zoals een ingewikkelde installatieprocedure en slechte documentatie, is het onmisbaar voor databasebeheerders die databases in standby nuttig willen maken. De nieuwe Snapshot Standby-functie helpt de beheerder daarnaast om grip te krijgen op veranderingsbeheer en het testen van applicaties.

Wel is het raadzaam om op te passen met Advanced Compression. Oracle heeft die niet zo goed geïmplementeerd als had gekund, en de kosten zijn dusdanig hoog dat het voor de meeste klanten niet de moeite is. Wel kan Advanced Compression de databasebeheerder helpen met deduplicatie, mits het op de juiste manier gebruikt wordt.

Nog een nieuwe functionaliteit is Result Cache. Het doet precies datgene wat ervan gevraagd wordt, en moet daarom ook met zorg worden behandeld. Maar wie de technologie begrijpt, paal en perk stelt aan doelen en binnen de grenzen van het eigen systeem blijft kan erg mooie resultaten boeken.

De automatische controle op systeemstatus en datacorruptie is ook een hoogtepunt in deze versie. DB 11g is pro-actief en besluitvaardig op momenten dat er mogelijkheden tot corruptie ontstaan.

Status en afstelling

De vraag rijst: worden ontwikkelaars slechter, of kunnen ze gewoonweg de explosie aan nieuwe eisen niet bijbenen nu databases volwassener worden? Hoe dan ook, Oracle heeft beheerders flink wat middelen gegeven om inefficiënte code te vinden en op te vangen.

Om te beginnen kan 11g zijn automatische SQL-procedures uit zichzelf aanpassen, waarbij het een autodidactisch systeem gebruikt. De engine merkt zware SQL-statements op en bewaart ze ter afslanking op een onderhoudsmoment. Hij kan uit zichzelf een paar fixes doorvoeren, of structurele veranderingen aanbevelen, bijvoorbeeld in de indexen.

Maar wilt u meer controle houden, en de engine dus minder zelf laten doen, dan is het ook mogelijk om zelf zoekopdrachten op te stellen en reparaties in te dienen. Als dan blijkt dat de engine in de meeste gevallen goed zit, kunt u meer aan deze overlaten. Een probleem is wel dat Oracle geen rekening kan houden met de complete systeemlast, waardoor het een suggestie kan geven die de complete reeks in de war kan schoppen om een zoekopdracht die zelden gebruikt wordt.

Een losgeslagen werklast kan op meerdere manieren worden aangepakt, en Oracle heeft daar ook zorg aan besteed. Als het misgaat met een werklast, dan ligt dat meestal aan de CPU, geheugen of disk input/output van de server. Een losgeslagen werklast wordt door de meeste regelaars gemeten binnen de processor of geheugen, en niet de I/O. 11g daarentegen kan per sessie ook limieten stellen aan de I/O.

Die limieten maken het mogelijk om een maximumwaarde (aantal aanvragen of megabytes) te stellen aan het opereren van verbindingen op de server. Dit is erg belangrijk, zeker in het geval van grote warehouses, omdat deze systemen erg snel gekoppeld worden aan specifieke schijven. CPU- en geheugenlimieten ondervangen dit onvoldoende.

Bovendien kunnen databasebeheerders met de I/O-limieten helpen om langdurige aanvragen in goede banen te leiden. Vaak schrijven ze hun eigen controleroutines om bijvoorbeeld te zien of een aanvraag twintig minuten lang 20 procent van de processorcapaciteit gebruikt, omdat het niet mogelijk is om hoervoor ter plekke een policy te definiëren. Afhankelijk van de resultaten sturen ze vervolgens de code aan. Die handmatige middelen zijn niet meer nodig, nu I/O-gebruik kan worden gereguleerd.

Zoals gebruikelijk kunnen de langdurige aanvragen die problemen veroorzaken worden verplaatst naar een groep met lage prioriteit. Het is alsof het in quarantaine verder behandeld wordt, want wie een SQL schrijft die het systeem in de weg zit, dan krijg deze minder middelen om te voorkomen dat anderen beïnvloed worden. Uiteraard duurt de zoekopdracht dan wel een stuk langer.

Result Cache

Result Cache is een functie die u kan maken of breken, afhankelijk van wie de regie heeft. Het maakt het mogelijk om een aanvraag op te slaan in een speciale buffer in het geheugen, zodat opeenvolgende calls voor dezelfde aanvraag niet via de schijven hoeven te gaan. Volledige of gedeeltelijke aanvragen, of zelfs PS/SQL-funties, ze kunnen gecached worden. Uiteraard moet de opdracht wel dezelfde zijn als die in de cache, en daarin zit nou net het venijn. Opdrachten hebben namelijk de neiging om zich alleen maar te onderscheiden in de parameters (het geval bij de meeste OLTP-aanvragen), en zo krijgt u snel heel veel gecachte aanvragen die amper hergebruikt worden.

Daarom kan de cache op drie verschillende niveaus worden ingedeeld: database-niveau, sessieniveau en aanvraagniveau. Daar zit nogal wat achter, zowel goed als slecht, en daarom raad ik aan om het te beperken tot de sessie- en aanvraagniveaus; het databaseniveau kunt u beter pas gebruiken na uitgebreide tests. Dan worden namelijk alle resultaten in de cache opgeslagen, ook de resultaten die u niet meer nodig hebt. De cache voor resultaten heeft slechts een klein gedeelte van de buffer tot zijn beschikking, dus het aantal zal erg beperkt blijven tenzij u de toewijzing uitbreidt.

De Result Cache is redelijk goed geïmplementeerd, en doet precies wat het moet doen. Ik had tijdens de eerste tests geen problemen om resultaten tevoorschijn te krijgen. Om een beetje een gevoel te krijgen, heb ik me beperkt tot een handjevol zoekvragen. Eigenlijk zag ik direct een verbetering in de responstijden. Maar dat effect werd danig afgezwakt toen ik het aantal aanvragen opschroefde en de parameters aanpaste. Nu viel dat te verwachten, en kan het moeilijk aangemerkt worden als een tekortkoming, maar het moet wel gezien worden als teken dat het goed getest en gepland moet worden voor het toe te passen in productie.

Het spreekt uiteraard vanzelf dat deze functionaliteit bedoeld is voor systemen gebaseerd op harde schijven, en niet nuttig is voor geheugensystemen. Als het geheugen beperkt is, dan is het logisch dat het gebruiken van de buffer alleen maar voor meer ellende zorgt. Bovendien zal het voor OLTP-workloads weinig uitmaken. Ook moet u op de gecachte resultaten letten als u deze functie gebruikt op uw workloads ter ondersteuning van beslissingen; het wordt snel over het hoofd gezien dat ook 64-bits systemen limieten stellen aan het geheugen, en dat een resultaat van 200 miljoen rijen niet bevorderlijk is voor uw beschikbare geheugen.

Morgen: Corruptiebeheer, Snaphot Standby, Active Data Guard, Real Application Testing en de conclusie Bron: Techworld