Oracle Refreshable Pluggable Database

Met de release van versie 12.2 heeft Oracle de Refreshable Pluggable Database (PDB) optie geïntroduceerd. Met deze optie is het mogelijk om fysieke kopie van een Pluggable Database in een andere CDB (Container) te maken en over een database link bij te werken. Deze optie is beschikbaar in alle versies van de Oracle software dus zowel in Oracle EE als SE2 en zowel on-prem als in de Cloud. Het moet niet worden gezien als een vervanging van DataGuard dus wanneer EE-licenties beschikbaar zijn zal het de voorkeur hebben van DBA.nl om DataGuard in te zetten. Om die reden zal deze optie voornamelijk interessant in omgevingen die middels SE2 licenties zijn gelicentieerd.

Setup

• Stap 1, is het creëren van een Pluggable database in CDB1 op server 1.
• In stap 2, wordt een copy van de PDB gemaakt in CDB2 op server 2 middels een database link. Door de Refresh Mode mee te geven wordt deze database elke 2 minuten bijgewerkt op basis van de beschikbare redo informatie van de bron PDB.

Vanaf Oracle 19c is het ook zonder Multitenant optie mogelijk om meerdere PDB’s (Max 3) in een CDB te plaatsen. Het is ook mogelijk om kruislings PDB’s Refreshable PDB’s te creëren en bij te werken middels hetzelfde principe.  Zie onderstaande:

De refresh mode geeft aan dat de stand-by database elke x minuten refreshed (in dit voorbeeld elke 2 minuten) en dus in principe maximaal 2 minuut achterloopt. De Refreshable PDB kan ook tijdelijk als read-only worden geopend en als je hem sluit gaat het refreshen weer door.

CDB> alter pluggable database PDBORA2 open read only;
CDB> alter pluggable database close;

Een Refreshable PDB wordt bijgewerkt op basis van redo informatie. In tegenstelling tot DataGuard maakt een Refreshable PDB gebruik van een tijdelijke archivelog (op de bron) die op de primaire database in de FRA wordt gecreëerd. Wanneer de redo-stream uit deze archivelog is toegepast op de Refreshable PDB wordt deze tijdelijke archivelog weer verwijderd. In de FRA wordt een directory foreign_archivelog gecreëerd waarin de tijdelijke archivelog wordt gecreëerd.  In de alertlogs van de beide databases is dat ook terug te zien:

— CDB1 => Primaire
2020-03-26T16:22:24.030666+01:00
Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/CDB1/foreign_archivelog/RED/2020_03_26/o1_mf_1_13_1315987322_.arc

— CDB2 => Standby
RED(3):Media Recovery Start
2020-03-26T16:22:23.500067+01:00
RED(3):Serial Media Recovery started
RED(3):max_pdb is 3
2020-03-26T16:22:23.551406+01:00
RED(3):Media Recovery Log /u01/app/oracle/fast_recovery_area/CDB1/foreign_archivelog/RED/2020_03_26/o1_mf_1_13_1315987322_.arc
2020-03-26T16:22:23.860669+01:00
RED(3):Incomplete Recovery applied until change 1123625 time 03/26/2020 16:22:22
2020-03-26T16:22:23.866060+01:00
RED(3):Media Recovery Complete (CDB2)
RED(3):Completed: alter pluggable database refresh

Op zowel de primaire als de stand-by blijven geen bestanden permanent staan waar iets mee gedaan moet worden zoals dat bijvoorbeeld bij een scripted stand-by wel het geval is.

Activeren Stand-by
Op het moment dat de brondatabase niet meer beschikbaar is kan de stand-by database worden geactiveerd zodat deze gebruikt kan worden.  De RPO (Recovery Point Objective = het maximale dataverlies) hangt af van de interval waarmee de Refreshable PDB is geconfigureerd en het moment waarop de brondatabase is weggevallen. De RTO (Recovery Time Objective = hoe lang het duurt voor de database weer beschikbaar is) hangt af van:

• De hoeveelheid redo generatie in de brondatabase.
• De frequentie van de refresh.

In het slechtste geval valt de brondatabase net voor de volgende refresh weg op het moment dat in de bron PDB zeer veel redo werd gegenereerd. In dat geval moet namelijk de stand-by PDB eerst worden bijgewerkt tot het laatste moment alvorens deze in read-write mode geopend wordt. Voorwaarde hiervoor is wel dat de Container van de bron PDB beschikbaar is. Ondanks dat de bron PDB niet beschikbaar is kan de stand-by PDB toch worden bijgewerkt op basis van de beschikbare online redologs (CDB niveau) en eventuele archivelogs alvorens deze read-write te openen. In onderstaande voorbeeld wordt uitgegaan van twee Containers (CDB1 en CDB2). Vanuit beide Containers is een DB-Link gecreëerd naar de andere CDB.

— Create PDB RED in CDB1
CDB1> CREATE PLUGGABLE DATABASE RED
ADMIN USER PDBADM IDENTIFIED BY COMPLEXPASSWORD
CREATE_FILE_DEST=’/u01/app/oracle/oradata’;
CDB1> alter pluggable database RED open read write;

— Create Refreshable PDB RED in CDB2
CDB2> create pluggable database RED from RED@CDB1
CREATE_FILE_DEST=’/u01/app/oracle/oradata’
refresh mode every 2 minutes;

Door de refresh mode in te stellen op x minuten zal er in de CDB een scheduler_job worden gecreëerd die de refresh elke x minuten initieert. Zoals:

CDB2> select job_action from dba_scheduler_jobs where job_name = ‘RED_2733630503_REFRESH’;
declare
cur integer := sys.dbms_sql.open_cursor(security_level => 2);
begin
sys.dbms_sql.parse( c   => cur, statement  => ‘alter pluggable database refresh’, language_flag => sys.dbms_sql.native, container => ‘RED’);
sys.dbms_sql.close_cursor(c=>cur);
end;

De database parameter job_queue_processes parameter moet dus op een waarde hoger dan 0 zijn ingesteld anders wordt er niet veel gerefreshed.

Crash Primaire PDB
In onderstaande voorbeeld wordt er crash van de primaire PDB geïnitieerd.

Eerst wat test rijen creëren.

— Create HR demo schema in CDB1
CDB1/RED>@?/demo/schema/human_resources/hr_main.sql
— Check na 2 minuten of HR ook in de RED PDB zit in CDB2.
CDB2> alter pluggable database RED open read only;
CDB2> alter session set container=RED;
CDB2/RED> select count(*) from dba_objects where owner=’HR’;
COUNT(*)
———-
34

— Sluit de RED PDB in CDB2 zodat deze weer ververst kan worden.
CDB2> alter pluggable database RED close;

— In primaire RED PDB
CDB1/RED> exec for i in 1..150 loop update hr.employees set hire_date=sysdate, salary=salary+1; dbms_lock.sleep(1); commit; end loop
CDB1/RED>  select max(to_char(hire_date,’DD-MM-YYYY HH24:MI:SS’)) from hr.employees;

26-03-2020 14:29:01

CDB1/RED>  shutdown abort
Pluggable Database closed.

Nu de primaire PDB is gecrasht zal de Refreshable PDB geopend moeten worden in de read-write mode. Hiervoor zal allereerst een handmatige refresh worden uitgevoerd. Dit kan alleen wanneer de CDB1 beschikbaar is voor redo.

— manual refresh
CDB2> alter pluggable database RED refresh;
— Disable auto refresh
CDB2> alter pluggable database RED refresh mode none;
— Open PDB read-write
CDB2> alter pluggable database RED open read write;
CDB2> alter session set container=RED;
— Controle of laatste record ook daadwerkelijk is toegepast op de Refreshable PDB.
CDB2/RED> select max(to_char(hire_date,’DD-MM-YYYY HH24:MI:SS’)) from hr.employees;

26-03-2020 14:29:01

Crash Primaire CDB
In onderstaande voorbeeld wordt er crash van de primaire CDB geïnitieerd. Wanneer de bron CDB niet beschikbaar is betekent dat de stand-by PDB niet eerst bijgewerkt kan worden alvorens deze read-write te openen. In dat geval zullen de wijzigingen tot en met de laatste refresh meegenomen zijn. Er is op dat moment dus spraken van dataverlies. In onderstaande voorbeeld is de primaire database de RED PDB in CDB2. De RED database in CDB1 is stand-by en refreshed elke minuut.

— Primaire (CDB2/RED)
CDB2> alter session set container=RED;
Session altered.
— Updaten Employees tabel.
CDB2/RED> exec for i in 1..150 loop update hr.employees set hire_date=sysdate, salary=salary+1; dbms_lock.sleep(1); commit; end loop
PL/SQL procedure successfully completed.
— Check laatste record
CDB2/RED> select max(to_char(hire_date,’DD-MM-YYYY HH24:MI:SS’)) from hr.employees;
MAX(TO_CHAR(HIRE_DA

---

 

27-03-2020 11:50:16

— Crash van CDB
CDB2> shutdown abort

Vanuit de CDB1 is niet zichtbaar dat de brondatabase niet beschikbaar is. Wel is zichtbaar dat de LAST_REFRESH_SCN niet meer oploopt. Dit zou kunnen worden gebruikt als controlemechanisme door deze met een vaste interval weg te schrijven in een hulptabel. Hier kan vervolgens ook gemakkelijk een alert aan gekoppeld kunnen worden.

In de alertlog van de standby database is duidelijk zichtbaar dat het Refreshen faalt.

2020-03-27T11:50:33.898050+01:00

RED(4):alter pluggable database refresh

***********************************************************************

Fatal NI connect error 12514, connecting to:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.16.196)(PORT=1521))(CONNECT_DATA=(SERVER=dedicated)(SERVICE_NAME=CDB2)(CID=(PROGRAM=oracle@kvm1)(HOST=kvm1)(USER=oracle))))

TNS-12564: TNS:connection refused

    ns secondary err code: 0

    nt main err code: 0

    nt secondary err code: 0

    nt OS err code: 0

***********************************************************************

Dit betekent dat ook manuele verversing ook mislukt.

CDB1> alter pluggable database RED refresh;

alter pluggable database RED refresh

*

ERROR at line 1:

ORA-17627: ORA-12514: TNS:listener does not currently know of service_name

Het openen van de Refreshable PDB in read-write mode faalt.

CDB1> alter pluggable database RED open read write;

alter pluggable database RED open read write

*

ERROR at line 1:

ORA-65341: cannot open pluggable database in read/write mode

Wanneer de CDB niet beschikbaar is moeten er een aantal stappen worden uitgevoerd om deze read-write te kunnen openen.

CDB1> alter pluggable database RED open read only;
CDB1> alter session set container=RED;
CDB1/RED> exec dbms_pdb.describe(‘/tmp/RED.xml’);
CDB1/RED> alter pluggable database RED close immediate;
CDB1> alter session set container=cdb$root;
CDB1> drop pluggable database RED keep datafiles;
CDB1> create pluggable database RED using ‘/tmp/RED.xml’ NOCOPY;
CDB1> alter pluggable database RED open;
CDB1> alter session set container=RED;

Qua doorlooptijd stelt het niet veel voor maar kijkend naar de stappen die genomen moeten worden wanneer de CDB wel beschikbaar is dit een stukje complexer. Maar hoe zit het met dataverlies in dit geval?

CDB1/RED> select max(to_char(hire_date,’DD-MM-YYYY HH24:MI:SS’)) from hr.employees;
MAX(TO_CHAR(HIRE_DA

---

 

27-03-2020 11:49:32

Bron voor Crash:

27-03-2020 11:50:16

In dit geval is het dataverlies (RPO) dus onder de minuut zijn en de RTO onder de 5 minuten.

Wanneer de gecrashte CDB weer beschikbaar is zal de Refreshable PDB opnieuw moeten worden opgebouwd. LET OP want de oude bron PDB zal standaard read write worden geopend wat een risico is want dat zou betekenen dat er twee actieve database zijn. Er kan dus geen gebruik worden gemaakt van een HA-Service omdat dit een te groot risico is dat er op twee databases mutaties worden doorgevoerd.

Switchover optie

Vanaf Oracle 18c er een optie bijgekomen namelijk de switchover optie. Deze optie is momenteel alleen beschikbaar in de Cloud of op Engineered Systems als onderdeel van de Multitenant optie. Met deze optie wordt het mogelijk om de PDB’s van rol te wisselen. Voor grote databases is dit niet echt een optie op het moment dat je switched zal de voormalige brondatabase opnieuw worden gemaakt. De reden hiervoor zit in het feit dat wanneer een PDB read-write is geopend geweest dat deze niet als Refreshable PDB te starten is. Bij grote databases is dit dus een minder goede optie omdat dan gedurende de tijd dat de stand-by wordt ververst er geen stand-by beschikbaar is.

Conclusie

De inrichting en het bijwerken van Refreshable PDB’s is simpel en werkt goed. De enige benodigdheden zijn:

• Een container op een tweede server.
• Netwerk connectiviteit (SQL*NET) tussen beide containers.
• Fast_Recovery_Area.
• Job_Queue_Processes > 0

Wel is van belang dat de beide servers zijn gelicentieerd.

Door de beperkingen op het moment dat de bron CDB wegvalt is deze optie primair geschikt als een Disaster-Recovery oplossing waarbij een aantal handmatige acties uitgevoerd moeten worden op database-niveau en vanuit de applicatie om ervoor te zorgen dat naar de juiste database geconnecteerd wordt.
De mogelijkheid om de Refreshable PDB read-only te openen maakt het een goede oplossing voor bijvoorbeeld rapportage doeleinde. Doordat er niet gemakkelijk geswitched kan worden van rol is een nadeel omdat in dat geval de Refreshable PDB opnieuw opgebouwd moet worden.
Deze methode kan heel goed worden ingezet voor bijvoorbeeld migraties naar een nieuwe server of migraties naar een CDB met een hoger patchlevel. In dat geval zal de Refreshable PDB na het openen in Read-Write deze middels Datapatch moeten worden voorzien van de Patches die geïnstalleerd zijn in de CDB.