Pluggable Databases en je Backup en Recovery Strategie in Noarchivelog

Zoals al in eerdere artikelen aangegeven raakt het het omschakelen naar de container architectuur (single en multi tenant) bijna alle aspecten van beheer. Backup en recovery is daar één van. Laten we een vaker voorkomend scenario onder de loop nemen.

Ten behoeve van test omgevingen is een multitenant omgeving ingericht met daarin een tiental pluggable databases. Het geheel staat niet in archivelog mode. In de oude Oracle 11 omgeving waren dit 10 aparte databases. Omdat dit een test omgeving is worden er geen (dagelijkse) (cold) backups genomen. In het verleden was het de gewoonte vlak voor een applicatie wijziging de directory van de database veilig te stellen.

Is het nu een optie de directory met de files van de betreffende pluggable database veilig te stellen?
Nee, de gehele database, root, en alle pluggables maken één geheel uit. Dit betekent dat het alleen terugzetten van de datafiles van een enkele pluggable fouten oplevert die aangeven dat de betreffende datafiles recovery nodig hebben. Als je voor dit scenario wilt kiezen zal er voor gekozen worden de gehele container database en pluggables veilig te stellen en terug te plaatsen. Hiermee worden alle applicatie systemen/pluggable terug gezet in de tijd. Consolidatie naar één omgeving betekent dan ook dat de recovery mogelijkheden geconsolideerd worden.

Zijn er alternatieven te bedenken? Ja, er zijn zeker alternatieven, elk met zijn eigen voor en nadelen. Het is daarom belangrijk vooraf de consequenties te overdenken en ook bij het inrichten van de omgeving hier al rekening te houden. Hierna een selectie van 5 alternatieven die wij het meest realistisch achten

  1. De test databases wel in archivelog plaatsen.
    Door de test database wel in archivelog te plaatsen wordt het mogelijk een PDB point in time recovery uit te voeren en online backups te maken. Nadeel van deze aanpak is dat er beheer op de archivelogs ingericht moet worden. Als je dit niet doet dan loopt uiteindelijk de disk vol.

  2. Een offline full database backup gebruiken om een auxilary database te gebruiken. Een offline backup kan gebruikt worden om de hele database te clonen en van uit deze database de vereiste pluggable database te extraheren met een uplug database en vervolgens deze in de originele test database in te pluggen.
    Nadeel van deze aanpak is dat ergens een down moment gekozen moet worden om de gehele container database te backupen. Verder is het opbouwen van de ‘auxilary’close database een actie die resources en nauwkeurig werken vereist.

  3. Het clonen van de PDB voor de upgrade
    Door de pluggable database binnen de huidige container database te clonen ontstaat er een kopie van de bestaande pluggable database. Hiermee is er een mogelijkheid in geval van nood deze terug te clonen. Nadeel van deze aanpak is dat er binnen de container database extra ruimte gealloceerd wordt voor de extra PDB en het risico bestaat dat er niet wordt weggegooid nadat de upgrade succesvol is afgerond

  4. Gebruik maken van een tijdelijke ‘werk’-CDB
    Door de PDB tijdelijk te unpluggen naar een speciale ‘werk’-CDB waarin slechts deze PDB zal draaien, is het mogelijk een offline backup te maken van deze ‘werk-CDB inclusief de PDB. Na de update (en eventueel restore) kan de PDB met uplug en plug-in weer terug geplaatst worden in de originele PDB
    Nadeel van deze aanpak is het hebben van de extra container database en de extra handelingen die nodig zijn rondom de update.

  5. Overweeg single tenant i.p.v. multi tenant
    Als laatste optie is de mogelijkheid te overwegen voor de T-omgevingen niet gebruik te maken van multi-tenant maar te kiezen voor single tenant. Hierdoor is de database per een geïsoleerde omgeving die zelfstandig (CDB + PDB) gebackupt kan worden. Nadeel van deze aanpak is het diskgebruik (een root cantainer voor elke applicatie) en het feit dat T en P een iet identieke structuur hebben.

Welke van de bovenstaande (en mogelijk alternatieve oplossingen) het best is, hangt sterk af van de organisatie en argumenten. Vanuit een puur principieel standpunt lijkt ons alternatief 1 het meest te adviseren, immers hier wordt aangesloten bij core Oracle technologie. Mocht de keuze voor noarchivelog essentieel zijn dat lijkt ons optie 5 het meest te gepast.

Scroll to Top