Mehrfaches PDB Recovery bei 23ai ist einfach?
Einführung
Eine pluggable Database (PDB) kann unabhängig von der Container Database (CDB) oder anderen PDBs verwaltet werden. Auch ein vollständiges oder unvollständiges Recovery ist für eine PDB separat möglich.
Speziell bei Oracle 19c gab es beim wiederholten unvollständigen Recovery allerdings einige Einschränkungen, siehe dazu auch meinen Blogbeitrag: Ist CDB und PDB Recovery in verwaiste(orphan) Inkarnationen bei Oracle 19c immer möglich?
Im folgenden Beitrag zeige ich, wie sich ein mehrfaches Recovery einer PDB in eine verwaiste (orphan) Incarnation unter Oracle 23ai einfach umsetzen lässt. Für weiterführende Informationen und konkrete Testszenarien empfehle ich den
Praxisworkshop Backup and Recovery Oracle 19c
1. Testumgebung
In der Testumgebung existiert die PDB ORCLPDB3. Der Archivelog Mode und Flashback Database sind angeschaltet.
SYS@ORCLCDB:CDB$ROOT:> select name, open_mode, log_mode, flashback_on from v$database;
NAME OPEN_MODE LOG_MODE FLASHBACK_ON
--------- -------------------- ------------ ------------------
ORCLCDB MOUNTED ARCHIVELOG YES
SYS@ORCLCDB:CDB$ROOT:> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ---------- --------- ----------
2 PDB$SEED READ ONLY NO
3 ORCLPDB1 READ WRITE NO
4 ORCLPDB2 READ WRITE NO
5 ORCLPDB3 READ WRITE NO
In der PDB ORCLPDB3 wird eine Testtabelle t_18_uhr angelegt. Danach werden ein PDB Restore Point(RS_PDB_18_30_Uhr) und ein CDB Restore Point(RS_CDB_18_30_Uhr) angelegt, die wir später für das Recovery benötigen.
SYS@ORCLCDB:ORCLPDB3:> create table t_18_uhr as select * from dba_users;
Table T_18_UHR created.
SYS@ORCLCDB:ORCLPDB3:> create RESTORE POINT RS_PDB_18_30_Uhr GUARANTEE FLASHBACK DATABASE;
RESTORE POINT RS_PDB_18_30_UHR created.
SYS@ORCLCDB:CDB$ROOT:> conn sys/<password>@localhost/orclcdb as sysdba
SYS@ORCLCDB:CDB$ROOT:> create RESTORE POINT RS_CDB_18_30_Uhr GUARANTEE FLASHBACK DATABASE;
RESTORE POINT RS_CDB_18_30_UHR created.
SYS@ORCLCDB:CDB$ROOT:> select name, scn, time, pdb_restore_point, pdb_incarnation# from v$restore_point;
NAME SCN TIME PDB_RESTORE_POINT PDB_INCARNATION#
________________ ___________ _______________________________ _________________ ___________________
RS_PDB_18_30_UHR 44895972 19-MAY-25 02.50.40.000000000 PM YES 0
RS_CDB_18_30_UHR 44896097 19-MAY-25 02.51.37.000000000 PM NO 0
Jetzt wird in der PDB ORCLPDB3 eine weitere Testtabelle t_19_uhr angelegt. Danach wird ein weiterer PDB Restore Point(RS_PDB_19_30_Uhr) und ein weiterer CDB Restore Point(RS_CDB_19_30_Uhr) angelegt.
SYS@ORCLCDB:ORCLPDB3:> create table t_19_uhr as select * from dba_users;
Table T_19_UHR created.
SYS@ORCLCDB:ORCLPDB3:> create RESTORE POINT RS_PDB_19_30_Uhr GUARANTEE FLASHBACK DATABASE;
SYS@ORCLCDB:ORCLPDB3:> conn / as sysdba
SYS@ORCLCDB:CDB$ROOT:> create RESTORE POINT RS_CDB_19_30_Uhr GUARANTEE FLASHBACK DATABASE;
SYS@ORCLCDB:CDB$ROOT:> select name, scn, time, pdb_restore_point, pdb_incarnation# from v$restore_point;
NAME SCN TIME PDB_RESTORE_POINT PDB_INCARNATION#
_________________ ___________ __________________________________ _________________ ________________
RS_PDB_18_30_UHR 44895972 19-MAY-25 02.50.40.000000000 PM YES 0
RS_CDB_18_30_UHR 44896097 19-MAY-25 02.51.37.000000000 PM NO 0
RS_PDB_19_30_UHR 45810849 21-MAY-25 12.24.58.000000000 PM YES 0
RS_CDB_19_30_UHR 45811495 21-MAY-25 12.26.33.000000000 PM NO 0
2. PDB Recovery auf 18:30 Uhr
Das erste unvollständige Recovery soll auf den CDB Restore Point stattfinden, der die Zeit 18:30 Uhr simuliert.
Variante 1 mit restore/recover:
$ rman target /
RMAN> alter pluggable database ORCLPDB3 close immediate;
RMAN> restore pluggable database ORCLPDB3 until RESTORE POINT RS_CDB_18_30_UHR;
RMAN> recover pluggable database ORCLPDB3 until RESTORE POINT RS_CDB_18_30_UHR;
RMAN> alter pluggable database ORCLPDB3 open;
ORA-38890: RESETLOGS option may need to be used to open this PDB
ORA-01113: file 69 needs media recovery
RMAN> alter pluggable database ORCLPDB3 open resetlogs;
Da es ein unvollständiges Recovery ist, kann die PDB nur mit RESETLOGS geöffnet werden.
Variante 2 mit flashback:
RMAN> flashback pluggable database orclpdb3 until RESTORE POINT RS_CDB_18_30_UHR;
RMAN> alter pluggable database ORCLPDB3 open resetlogs;
Damit ist die Tabelle t_18_uhr vorhanden, die Tabelle t_19_uhr ist entsprechend des Recovery Zeitpunktes verloren.
Es ist eine neue PDB Incarnation entstanden, aber keine neue CDB Incarnation.
SYSTEM@ORCLCDB:ORCLPDB3:> select count(*) from sys.t_18_uhr;
COUNT(*)
----------
42
SYSTEM@ORCLCDB:ORCLPDB3:> select count(*) from sys.t_19_uhr;
select count(*) from sys.t_19_uhr
*
ERROR at line 1:
ORA-00942: table or view "SYS"."T_19_UHR" does not exist
RMAN> select PDB_INCARNATION#, con_id, END_RESETLOGS_SCN, status, BEGIN_RESETLOGS_TIME from v$pdb_incarnation where con_id=5;
PDB_INCARNATION# CON_ID END_RESETLOGS_SCN STATUS BEGIN_RESETLOGS_TIM
---------------- ---------- ----------------- ------- -------------------
3 5 45813047 CURRENT 2025-05-21:12:38:36
0 5 5391272 PARENT 2024-12-03:10:38:27
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- ------ ---------- ----------
1 1 ORCLCDB 2957803683 PARENT 2045207 2024-05-03:17:05:34
2 2 ORCLCDB 2957803683 CURRENT 5391272 2024-12-03:10:38:27
3. PDB Recovery auf 19:30 Uhr
Jetzt könnte ein Anwender “entdeckt” haben, dass es noch wichtige Daten nach 18:30 Uhr gibt, die eigentlich verloren sind. Deshalb soll das Recovery wiederholt werden auf den Zeitpunkt 19:30 Uhr.
1. Versuch: Recovery auf den CDB Restore Point
RMAN> alter pluggable database ORCLPDB3 close immediate;
RMAN> restore pluggable database ORCLPDB3 until RESTORE POINT RS_CDB_19_30_UHR;
ORA-39889: Specified System Change Number (SCN) or timestamp is in the middle of a previous PDB RESETLOGS operation.
Wir erhalten eine Fehlermeldung, weil das Ziel in der anderen PDB Incarnation liegt.
Darüber gibt die ausführliche Fehlermeldung Auskunft:
$ oerr ora 39889
39889, 00000, "Specified System Change Number (SCN) or timestamp is in the middle of a previous PDB RESETLOGS operation."
// *Cause: The specified System Change Number (SCN) or timestamp was in the
// middle of a previous PDB RESETLOGS operation. More specifically,
// each PDB RESETLOGS operation may create a PDB incarnation as shown
// in v$pdb_incarnation. Any SCN between INCARNATION_SCN and
// END_RESETLOGS_SCN or any timestamp between INCARNATION_TIME and
// END_RESETLOGS_TIME as shown in v$pdb_incarnation is considered in
// the middle of the PDB RESETLOGS operation.
// *Action: Flashback the PDB to an SCN or timestamp that is not in the middle
// of a previous PDB RESETLOGS operation. If flashback to a SCN on the
// orphan PDB incarnation is required, then use
// "RESET PLUGGABLE DATABASE TO INCARNATION" RMAN command to specify
// the pluggable database incarnation along which flashback to the
// specified SCN must be performed. Also, ensure that the feature is
// enabled.
In der Oracle Dokumentation erfährt man allerdings, dass in den beiden folgenden Fällen ein Recovery ohne den Befehl “RESET PLUGGABLE DATABASE TO INCARNATION” möglich ist:
1. Recovery auf einen PDB Restore Point
2. Recovery auf einen Zeitpunkt
2. Versuch: Recovery auf PDB Restore Point oder Zeitpunkt.
RMAN> restore pluggable database ORCLPDB3 until RESTORE POINT RS_PDB_19_30_UHR;
RMAN> recover pluggable database ORCLPDB3 until RESTORE POINT RS_PDB_19_30_UHR;
RMAN> alter pluggable database ORCLPDB3 open resetlogs;
oder
RMAN> flashback pluggable database orclpdb3 until time "to_date('21-MAY-25 12.26.33','DD-MON-YY,HH24:MI:SS')";
RMAN> alter pluggable database ORCLPDB3 open resetlogs;
Jetzt ist auch die Tabelle 19 Uhr wiederhergestellt.
SYSTEM@ORCLCDB:ORCLPDB3:> select count(*) from sys.t_18_uhr;
COUNT(*)
----------
42
SYSTEM@ORCLCDB:ORCLPDB3:> select count(*) from sys.t_19_uhr;
COUNT(*)
----------
42
Es ist eine verwaiste (orphan) PDB Incarnation entstanden.
SYSTEM@ORCLCDB:ORCLPDB3:>select PDB_INCARNATION#, con_id, END_RESETLOGS_SCN, status, BEGIN_RESETLOGS_TIME from v$pdb_incarnation where con_id=5;
PDB_INCARNATION# CON_ID END_RESETLOGS_SCN STATUS BEGIN_RESETLOGS_TIM
---------------- ---------- ----------------- ------- -------------------
4 5 45817188 CURRENT 2025-05-21:12:53:13
0 5 5391272 PARENT 2024-12-03:10:38:27
3 5 45813047 ORPHAN 2025-05-21:12:38:36
Das Szenario könnte noch beliebig oft zu anderen gewünschten Zeitpunkten durchgeführt werden, solange die entsprechenden Archivelogs bzw. Flashback Logs vorhanden sind.
Zusammenfassung
Mit Oracle 23ai gestaltet sich das wiederholte unvollständige Recovery einer PDB deutlich einfacher. Das verschafft Datenbankadministratoren mehr Flexibilität, um auf spezielle Anwendungsszenarien gezielt reagieren zu können.
Wichtig: Garantierte Restore Points werden nicht automatisch gelöscht. Sie müssen daher durch den DBA manuell entfernt werden, sobald sie nicht mehr benötigt werden.
Kommentare
Keine Kommentare