Oracle 11g feature van de maand: Database Replay

Oktober 2007 - Het is een veel gezien probleem: hoe kan een testomgeving zo worden vormgegeven dat deze niet alleen op het gebied van hard- en software zoveel mogelijk lijkt op de productieomgeving, maar ook voor wat betreft workload? Een in hoge mate gelijkende testomgeving zal immers de meest betrouwbare resultaten opleveren indien deze vertaald dienen te worden naar de productiesituatie.

In Oracle's meest recente versie van haar database-software, Oracle 11g, is een nieuwe functionaliteit opgenomen die dit probleem het hoofd biedt: Database Replay. Samen met Oracle SQL Analyzer vormt Database Replay de nieuwe optie Real Application Testing.

Het principe van Database Replay is eenvoudig: workload op een live database wordt 'opgenomen' en opgeslagen in binaire bestanden op het filesysteem van de server. Deze set van bestanden kan na de opname naar willekeurig welke andere omgeving worden getransporteerd waarna de data weer kan worden ‘afgespeeld’ op een database aldaar. Deze database dient dan uiteraard wel dezelfde logische structuur (tabellen, indexen, views e.d.) te bevatten als de brondatabase, en zal hiervan derhalve in de praktijk vaak een (exacte) kopie zijn.

Het hele proces is onder te verdelen in vier stappen:

• Opnemen (capture) van workload op de brondatabase
• Voorverwerken (preprocessing) van de opgenomen data
• Afspelen (replay) van de opgenomen data op de doeldatabase
• Analyse en rapportage

Elk van deze stappen is te configureren en te starten met behulp van de Oracle 11g Enterprise Manager (OEM) grafische user interface, maar kan tevens direct door de aanroep van database-packages (API’s) worden uitgevoerd.

Afbeelding 1 - Overzicht van de Database Replay-procesgang

Stap 1 - Het opnemen van workload

De eerste van de vier stappen omvat het opnemen van de workload op de brondatabase.

Voordat het opnemen gestart kan worden vanuit OEM dient de gebruiker een drietal aannames bevestigend te beantwoorden. Dit heeft veel weg van een soort “disclaimer” van de kant van Oracle aangaande het (correct) gebruik van de Database Replay-feature.

Het betreft hier de volgende aannames:

• Er is een backup beschikbaar van de brondatabase die als basis kan fungeren voor het vervaardigen van een doeldatabase (voor het afspelen van de opgenomen data), waarbij deze uiteindelijke doeldatabase zich dient te bevinden in de staat van de brondatabase zoals bij aanvang van het opnameproces.
• Er is voldoende ruimte op het filesysteem om alle opgenomen data in de binaire bestanden op te slaan
• De brondatabase kan worden herstart voor aanvang het van het opnameproces.

Hoewel de acceptatie van deze voorwaarden niet strikt noodzakelijk is (er kan immers direct gebruik worden gemaakt van database-packages om het opnameproces te starten), verdient het wel aanbeveling deze op te volgen om een correcte en volledige werking van Database Replay te garanderen.

Na acceptatie van de voorwaarden kunnen eventueel filters worden gedefinieerd op de op te nemen workload. Standaard worden alle activiteiten van externe clients op de brondatabase in de opname meegenomen, met als enige uitzonderingen de activiteiten van de Oracle Enterprise Manager-programmatuur. Met behulp van filters kunnen specifieke gebruikers, programma’s of sessies uitgesloten worden van opname.

Als laatste dienen de locatie voor de opnamebestanden alsmede de beoogde starttijd en, optioneel, de duur van de opname te worden opgegeven, waarna het capture-proces gestart kan worden.

Afbeelding 2 - Overzicht capture-proces

Stap 2 - Het voorverwerken van verzamelde data

Na een succesvolle opname dienen de gecreëerde binaire bestanden met workloaddata een voorverwerking (preprocessing) te ondergaan alvorens ze gebruikt kunnen worden voor het afspelen van de workload op de doeldatabase.

Voordat deze voorverwerking gestart kan worden dienen de bestanden aanwezig te zijn op het doelsysteem. De taak van het voorwerkingsproces is om de bestanden te transformeren in bestanden die geschikt zijn voor het afspeelproces. Tevens wordt benodigde metadata toegevoegd:

Afbeelding 3 - (Voorverwerkte) opnamebestanden

Stap 3 - Opgenomen workload afspelen

De workload in de voorverwerkte bestanden kan in deze stap worden afgespeeld op de doeldatabase.

Voor dit doel dienen, afhankelijk van de omvang van de af te spelen workload, één of meerdere zogenaamde Replay Clients te worden gestart op het doelsysteem. Dit zijn OS-processen die de workloadbestanden lezen en op de doeldatabase afspelen.

Na afloop van het afspeelproces laat OEM in een duidelijk overzicht zien hoe het afspelen van de workload op de doeldatabase zich verhoudt tot de opname van dezelfde workload op de brondatabase. Dit gebeurt op basis van een aantal grootheden, waaronder (database)tijd en het gemiddelde aantal actieve sessies.

Afbeelding 4 - Overzicht na afspeelproces

Stap 4 - Analyse en rapportage

Naast het bovengenoemde overzicht omtrent de performance van zowel het opneem- als afspeelproces zijn er enkele, meer gedetailleerde, rapporten beschikbaar. Deze bevatten een meer diepgaande analyse van de, eventuele, verschillen in performance tussen opname en afspelen van de workload, alsmede uitgebreide informatie over de AWR (Automatic Workload Repository) en ASH (Active Session History) ten tijde van het afspeelproces.

Afbeelding 5 - Gedetailleerde rapportage

Toepassingen voor Database Replay

De situaties waarin Database Replay een belangrijke rol kan spelen zijn divers. Te denken valt aan het meten van het effect van onderstaande acties op de algehele performance binnen de database:

• Oracle-parameter wijzigingen
• Upgrades van het Operating System
• Toepassen van patches
• Wijzigen van database-objecten
• Database-upgrades

In principe komt elke situatie waarin beoogde productiewijzigingen op voorhand dienen te worden getest in een zo waarheidsgetrouw mogelijk opgezette testomgeving (inclusief workload) in aanmerking voor het gebruik van Database Replay. Eigenlijk geldt dit dus vrijwel altijd.

Conclusie

Oracle heeft met Database Replay in 11g een mooi uitgevoerde en zeer nuttige feature toegevoegd aan het reeds rijke scala aan functionaliteit binnen de database.

Met name de mogelijkheid om een productie-workload real-time te ‘vangen’, met behoud van concurrency en afhankelijkheden maakt Database Replay krachtig.

De integratie met OEM is fraai en werkt nagenoeg vlekkeloos. Er is op ieder moment veel gedetailleerde informatie voorhanden.

Het is niet onwaarschijnlijk dat het in Oracle 11g geïntroduceerde Database Replay in toekomstige versies nog zal evalueren, en dat enkele, nu nog, scherpe kantjes verder worden bijgeschaafd. De eerder genoemde ‘disclaimer’ is hier het belangrijkste voorbeeld van, en dan met name de 'noodzaak' tot het stoppen en starten van de brondatabase voordat het opnameproces gestart wordt. De achterliggende gedachte is dat er op deze manier met een schone lei begonnen wordt binnen de database en het captureproces geen transacties zal tegenkomen die reeds gestart waren voor aanvang van de opname.

In de praktijk is het herstarten van een productiedatabase echter vaak meestal iets dat niet zomaar kan plaatsvinden. Daarnaast dienen allerlei (batch)processen die vaak automatisch bij de database aanloggen na herstart, uitgeschakeld te worden. Kortom, het starten van het opnameproces in een productieomgeving zal vaak nogal wat voeten in de aarde hebben, en dient zeer gecontroleerd te gebeuren.

Last but not least druist het feit dat de database voor aanvang van de opame bij voorkeur gestopt en gestart dient te worden enigszins in tegen het beoogde doel van Database Replay: het opnemen van een live productie-workload. Wellicht dat Oracle voor dit gegeven nog een goede oplossing vindt in een toekomstige versie.

Referenties

• Oracle Technology Network: The Top New Features for DBAs and Developers:
  www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/11g-replay.html
• Oracle 11g Documentatie:
  download.oracle.com/docs/cd/B28359_01/server.111/b28274/wcr.htm#BABHFDCE

Over de auteur
Marcel Mossel is sinds 1997 werkzaam in de ICT en heeft in die periode eerst als applicatiebeheerder en nu als DBA ruime ervaring opgedaan met Oracle-producten.