Ist CDB und PDB Recovery in verwaiste (orphan) Inkarnationen bei Oracle 19c immer möglich?
Überblick
Oracle 19c bietet umfangreiche Möglichkeiten, bei Anwendungsfehlern die Datenbank zu einem gewünschtem Zeitpunkt vor dem Fehler wiederherzustellen.
In diesem Blogeintrag werden Möglichkeiten und Grenzen von wiederholtem unvollständigen Recovery in CDB und PDB Containern in Oracle 19c und 21c gezeigt.
1. Aufbau der Testumgebung in Oracle 19c
Ausgangspunkt ist eine Testumgebung in Oracle 19c mit drei Tabellen, die für drei unterschiedliche Recovery-Zeitpunkte (18 Uhr, 19 Uhr, 20 Uhr) stehen.
Für diese Tabellen werden sich Zeitpunkt und SCN gemerkt.
SYS@CDB2>create table t_18_uhr as select * from dba_users;
SYS@CDB2>select current_scn from v$database;
CURRENT_SCN
-----------
35623259
SYS@CDB2>select scn_to_timestamp(35623259) as timestamp from dual;
TIMESTAMP
-------------------------------
09-MAY-23 10.05.22.000000000 AM
SYS@CDB2>create table t_19_uhr as select * from dba_users;
SYS@CDB2>select current_scn from v$database;
CURRENT_SCN
-----------
35623350
SYS@CDB2>select scn_to_timestamp(35623350) as timestamp from dual;
TIMESTAMP
-------------------------------
09-MAY-23 10.08.17.000000000 AM
SYS@CDB2>create table t_20_uhr as select * from dba_users;
SYS@CDB2>select current_scn from v$database;
CURRENT_SCN
-----------
35623403
SYS@CDB2>select scn_to_timestamp(35623403) as timestamp from dual;
TIMESTAMP
-------------------------------
09-MAY-23 10.09.32.000000000 AM2. Unvollständiges Recovery der gesamten CDB
2.1 CDB Recovery auf den Zeitpunkt "19 Uhr"
Dieses Recovery entspricht in etwa dem Recovery in einer NON-CDB-Architektur.
Empfohlen wird beim unvollständigen Recovery das Einspielen eines strukturgleichen Backups der Kontrolldatei.
Dabei muss beim Einspielen des Autobackups der Kontrolldatei die "UNTIL TIME" Klausel genutzt werden.
RMAN> startup force nomount;
RMAN> restore controlfile from autobackup until scn 35416116;
Starting restore at 2023-05-08:14:54:46
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=256 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 05/08/2023 14:54:46
RMAN-06493: only UNTIL TIME clause is allowed when performing a restore from AUTOBACKUP, found: SCN
## Beim Einspielen des Autobackup der CF muss die Klausel "until time" verwendet werden
RMAN> restore controlfile from autobackup
until time "to_date('09-MAY-23 10.08.17','DD-MON-YY,HH24:MI:SS')";
RMAN> alter database mount;
SYS@CDB2>select current_scn from v$database;
CURRENT_SCN
-----------
0
SYS@CDB2>archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 8
Next log sequence to archive 10
Current log sequence 10
Die SCN Nummer im eingespielten Backup der Kontrolldatei entspricht nicht den File Headern der aktuellen Datenbank.
Jetzt wird ein komplettes Restore der Datenbank durchgeführt und anschließend ein unvollständiges Recovery bis zum gewünschtem Zeitpunkt "19 Uhr".
Danach muss die Datenbank mit "Resetlogs" geöffnet, dabei wird Archive-Log-Nummer wird auf 1 gesetzt und eine neue Generation von archivierten Redo Logs entsteht - eine neue Datenbank Inkarnation.
Im Beispiel entsteht die neue Inkarnation 4.
Die File Header der Datendateien sind wieder synchronisiert mit der Kontrolldatei.
RMAN> restore database until time "to_date('09-MAY-23 10.08.17','DD-MON-YY,HH24:MI:SS')";
RMAN> recover database until time "to_date('09-MAY-23 10.08.17','DD-MON-YY,HH24:MI:SS')";
RMAN> alter database open resetlogs;
RMAN> alter system switch logfile;
## Archive log Nummer auf 1 gesetzt
SYS@CDB2>archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1
Next log sequence to archive 2
Current log sequence 2
## Neue Inkarnation 4 ist entstanden !
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 CDB2 873329825 PARENT 1 2019-04-17:00:55:59
2 2 CDB2 873329825 PARENT 1920977 2023-01-16:16:19:48
3 3 CDB2 873329825 PARENT 26932048 2023-05-09:09:04:41
4 4 CDB2 873329825 CURRENT 35623361 2023-05-09:10:19:41
In der Testumgebung sind jetzt Tabelle "t_18_Uhr" und "t_19_Uhr" erreichbar,
Tabelle "t_20_Uhr" ist nicht verfügbar.
SYS@CDB2>select count(*) from t_18_uhr;
COUNT(*)
----------
36
SYS@CDB2>select count(*) from t_19_uhr;
COUNT(*)
----------
36
SYS@CDB2>select count(*) from t_20_uhr;
*
ERROR at line 1:
ORA-00942: table or view does not exist
2.2 Recovery der gesamten CDB auf den Zeitpunkt "20 Uhr"
Im nächsten Schritt wird das Recovery auf "20 Uhr " wiederholt, weil wichtige Daten wiedergestellt werden sollen, die nach 19 Uhr entstanden sind.
## Im nächsten Schritt soll auf den Zeitpunkt 20 Uhr zurückgesetzt werden.
RMAN> startup force nomount;
RMAN> restore controlfile from autobackup
until time "to_date('09-MAY-23 10.09.32','DD-MON-YY,HH24:MI:SS')";
RMAN> alter database mount;
RMAN> restore database
until time "to_date('09-MAY-23 10.09.32','DD-MON-YY,HH24:MI:SS')";
...
RMAN-03002: failure of restore command at 05/09/2023 10:25:47
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
Der Fehler besagt, dass das Ziel der Recoverys in einer anderen Inkarnation (hier incarnation 3) liegt. Das normale Recovery ended sonst in der aktuellen Inkarantion (hier incarnation 4).
Mit dem Befehl "reset database to incarnation" kann ein Recovery auf eine ältere Inkarnation durchführen. Dabei werden in unserem Fall auch "tote" Transaktionen nach 19 Uhr "wiederbelebt".
RMAN> reset database to incarnation 3;
RMAN> restore database
until time "to_date('09-MAY-23 10.09.32','DD-MON-YY,HH24:MI:SS')";
RMAN> recover database
until time "to_date('09-MAY-23 10.09.32','DD-MON-YY,HH24:MI:SS')";
RMAN> alter database open resetlogs;
RMAN> alter system switch logfile;
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
...
3 3 CDB2 873329825 PARENT 26932048 2023-05-09:09:04:41
4 4 CDB2 873329825 ORPHAN 35623361 2023-05-09:10:19:41
5 5 CDB2 873329825 CURRENT 35623409 2023-05-09:10:32:43
Eine neue Inkarnation 5 ist entstanden.
Die bisherige aktuelle Inkarnation wird zu einer orphan (verwaisen) Inkarnation, die beim Recovery normalerweise übersprungen wird. Damit ist jetzt auch die bereits "verlorene" Tabelle "t_20_Uhr" wieder vorhanden.
SYS@CDB2> select count(*) from t_20_uhr;
COUNT(*)
----------
363. Unvollständiges Recovery einer PDB
3.1 Recovery einer PDB auf den Zeitpunkt "19 Uhr"
Klappt dieses Szenario aber auch innerhalb einer PDB? Dazu wird die analoge Testumgebung mit den drei Tabellen in der PDB aufgebaut.
Das erste Recovery Szenario bis auf "19 Uhr" klappt ohne Probleme.
## Tabelle "18 Uhr"
SYS@localhost/pdb21>create table t_18_uhr as select * from dba_users;
SYS@localhost/pdb21>select current_scn from v$database;
CURRENT_SCN
-----------
35625074
SYS@localhost/pdb21>select scn_to_timestamp(35625074) as timestamp from dual;
TIMESTAMP
---------------------------------------------------------------------------
09-MAY-23 10.41.19.000000000 AM
## Tabelle "19 Uhr"
SYS@localhost/pdb21>create table t_19_uhr as select * from dba_users;
SYS@localhost/pdb21>select current_scn from v$database;
CURRENT_SCN
-----------
35625165
SYS@localhost/pdb21>select scn_to_timestamp(35625165) as timestamp from dual;
TIMESTAMP
---------------------------------------------------------------------------
09-MAY-23 10.42.58.000000000 AM
## Tabelle "20 Uhr"
SYS@localhost/pdb21>create table t_20_uhr as select * from dba_users;
SYS@localhost/pdb21>select current_scn from v$database;
CURRENT_SCN
-----------
35625629
SYS@localhost/pdb21>select scn_to_timestamp(35625629) as timestamp from dual;
TIMESTAMP
---------------------------------------------------------------------------
09-MAY-23 10.44.20.000000000 AM
RMAN> alter pluggable database PDB21 close immediate;
RMAN> restore pluggable database PDB21
until time "to_date('09-MAY-23 10.42.58','DD-MON-YY,HH24:MI:SS')";
RMAN> recover pluggable database PDB21
until time "to_date('09-MAY-23 10.42.58','DD-MON-YY,HH24:MI:SS')";
RMAN> alter pluggable database PDB21 open resetlogs;
Dabei wird nur die PDB zurückgesetzt, der ROOT Container und alle anderen PDBs behalten ihre aktuellen Daten. Es ist keine neue Datenbank Inkarnation entstanden, aber eine neue PDB Inkarnation 1 für CON_ID=3.
RMAN> list incarnation:
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
...
3 3 CDB2 873329825 PARENT 26932048 2023-05-09:09:04:41
4 4 CDB2 873329825 ORPHAN 35623361 2023-05-09:10:19:41
5 5 CDB2 873329825 CURRENT 35623409 2023-05-09:10:32:43
RMAN> select PDB_INCARNATION#, con_id, END_RESETLOGS_SCN, status, BEGIN_RESETLOGS_TIME
from v$pdb_incarnation;
using target database control file instead of recovery catalog
PDB_INCARNATION# CON_ID END_RESETLOGS_SCN STATUS BEGIN_RESETLOGS_TIM
---------------- ---------- ----------------- ------- -------------------
0 1 35623409 CURRENT 2023-05-09:10:32:43
0 1 26932048 PARENT 2023-05-09:09:04:41
0 1 1920977 PARENT 2023-01-16:16:19:48
0 1 1 PARENT 2019-04-17:00:55:59
0 2 35623409 CURRENT 2023-05-09:10:32:43
0 2 26932048 PARENT 2023-05-09:09:04:41
0 2 1920977 PARENT 2023-01-16:16:19:48
1 3 35626315 CURRENT 2023-05-09:10:48:29
0 3 35623409 PARENT 2023-05-09:10:32:43
0 3 26932048 PARENT 2023-05-09:09:04:413.2 Recovery einer PDB auf den Zeitpunkt "20 Uhr"
Klappt aber das gleiche Szenario, wenn die PDB auf "20 Uhr" zurückgesetzt wird?
RMAN> alter pluggable database PDB21 close immediate;
RMAN> restore pluggable database PDB21
until time "to_date('09-MAY-23 10.44.20','DD-MON-YY,HH24:MI:SS')";
RMAN> recover pluggable database PDB21
until time "to_date('09-MAY-23 10.44.20','DD-MON-YY,HH24:MI:SS')";
RMAN-03002: failure of recover command at 05/09/2023 11:06:10
ORA-39889: Specified System Change Number (SCN) or timestamp is in the middle of a previous PDB RESETLOGS operation.
$ 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 is 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.
Es ist anscheinend nicht möglich, eine Wiederherstellung in eine orphan PDB-Inkarnation durchzuführen.
Beschreibung findet sich in der folgenden MOS Note : PITR to Orphan Incarnation Fails with ORA-39889 (Doc ID 2807322.1)
...
Until 20.1 a PDB in the same CDB can only be recovered to a point in time (PITR) only once.
...
Der folgender Befehl ist nicht supported. RMAN> reset pluggable database PDB21 to incarnation 0;
...
RMAN-05108: Command is not supported for pluggable database
4. Unvollständiges Recovery in eine orphan PDB-Inkarnation bei Oracle 21c
Die Dokumentation von Oracle 21c sagt dazu Folgendes:
…
"PDBs can be recovered to an orphan PDB incarnation within the same CDB incarnation or an ancestor incarnation.
Availability of PDBs is enhanced. Both flashback and point-in-time recovery operations are supported when recovering PDBs to orphan PDB incarnations"
…
Zur besseren Übersicht wird jetzt mit drei Restore Points gearbeitet werden, die für Zeitpunkte 18 Uhr, 19 Uhr und 20 Uhr stehen.
$ sqlplus sys/<password>@pdb2 as sysdba
Connected to:
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.6.0.0.0
SYS@CDB01>show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
4 PDB2 READ WRITE NO
...
SYS@CDB01>create RESTORE POINT Restore_Point_18_Uhr GUARANTEE FLASHBACK DATABASE;
Restore point created.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
RESTORE POINT ONLY
...
SYS@CDB01>create RESTORE POINT Restore_Point_19_Uhr GUARANTEE FLASHBACK DATABASE;
...
SYS@CDB01>create RESTORE POINT Restore_Point_20_Uhr GUARANTEE FLASHBACK DATABASE;
Restore point created.
Analog dem vorherigen Beispiel mit Oracle 19c erfolgt das PDB Recovery auf den "Restore_Point_18 Uhr".
select scn, time, name from v$restore_point;
SCN TIME NAME
---------- ------------------------------- ---------------------
50443836 11-MAY-23 01.32.18.000000000 PM RESTORE_POINT_18_UHR
50443888 11-MAY-23 01.32.49.000000000 PM RESTORE_POINT_19_UHR
50443932 11-MAY-23 01.33.16.000000000 PM RESTORE_POINT_20_UHR
RMAN> alter pluggable database PDB2 close immediate;
RMAN>
run
{
set until RESTORE POINT Restore_Point_18_Uhr;
restore pluggable database PDB2;
recover pluggable database PDB2;
alter pluggable database PDB2 open resetlogs;
}
# Test Tabellen, 18 Uhr ist da, 19 Uhr nicht vorhanden
SYSTEM@pdb2>conn sys/<pw>@pdb2 as sysdba
SYSTEM@pdb2>select count(*) from t_18_uhr;
COUNT(*)
----------
45
SYSTEM@pdb2>select count(*) from t_19_uhr;
select count(*) from t_19_uhr
*
ERROR at line 1:
ORA-00942: table or view does not exist
Eine neue PDB-Inkarnation 1 für CON_ID=4 ist entstanden.
RMAN> select PDB_INCARNATION#, con_id, END_RESETLOGS_SCN, status, BEGIN_RESetlogs_time
from v$pdb_incarnation where con_id=4;
PDB_INCARNATION# CON_ID END_RESETLOGS_SCN STATUS BEGIN_RESETLOGS_TIM
---------------- ---------- ----------------- ------- -------------------
1 4 50444694 CURRENT 2023-05-11:13:39:06
0 4 2601843 PARENT 2022-06-08:12:30:06
Jetzt soll die PDB auf den "Restore_Point_ 19 Uhr" wiederhergestellt werden.
Das Restore ist erfolgreich, das Recovery liefert jedoch anfangs einen Fehler:
RMAN> alter pluggable database PDB2 close immediate;
run
{
set until RESTORE POINT Restore_Point_19_Uhr;
restore pluggable database PDB2;
recover pluggable database PDB2;
alter pluggable database PDB2 open resetlogs;
}
...
RMAN-03002: failure of recover command at 05/11/2023 13:57:29
ORA-39889: Specified System Change Number (SCN) or timestamp is in the middle
of a previous PDB RESETLOGS operation.
...
$ 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.
Mit dem in der Fehlermeldung empfohlenen Befehl "RESET PLUGGABLE DATABASE TO INCARNATION", der jetzt auch unterstützt wird, ist das Recovery erfolgreich.
Damit ist auch Tabelle "t_19_Uhr" wieder verfügbar. Es ensteht eine neue PDB-Inkarantion 2 für CON_ID=4. Die bisherige PDB Inkarnation 1 wir zur orphan PDB-Inkarnation.
Weitere Recovery-Vorgänge sind analog möglich, z.B. auf die Tabelle "t_20_Uhr".
RMAN> RESET PLUGGABLE DATABASE PDB2 TO INCARNATION 0;
RMAN> recover pluggable database PDB2
until RESTORE POINT Restore_Point_19_Uhr;
RMAN> alter pluggable database PDB2 open resetlogs;
## Jetzt ist auch Tabelle 19 Uhr da !
SYSTEM@pdb2>select count(*) from t_19_uhr;
COUNT(*)
----------
45
select PDB_INCARNATION#, con_id, END_RESETLOGS_SCN, status, BEGIN_RESETLOG_TIME
from v$pdb_incarnation where con_id=4;
PDB_INCARNATION# CON_ID END_RESETLOGS_SCN STATUS BEGIN_RESETLOGS_TIM
---------------- ---------- ----------------- ------- -------------------
2 4 50453701 CURRENT 2023-05-11:15:02:12
0 4 2601843 PARENT 2022-06-08:12:30:06
1 4 50444694 ORPHAN 2023-05-11:13:39:06
5. Zusammenfassung
Bis zum Oracle Release 19c konnten wiederholte unvollständiges Recovery- und Flashback-Operationen in aktuellen und orphan Inkarnationen ohne Einschränkungen für NON-CDB-Datenbanken sowie den gesamten CDB Container bei CDB-Datenbanken durchgeführt werden.
Das unvollständige Recovery für eine PDB ist bei Oracle bis 19c nur einmal unterstützt, es ist nicht möglich, ein Recovery in eine orphan PDB Incarnation durchzuführen.
Ab dem Oracle Release 21 ist diese Einschränkung gefallen. Ein unvollständiges Recovery sowie Flashback einer PDB kann mehrfach innerhalb der gleichen oder einer früheren (ancestor) CDB/PDB-Inkarnation durchgeführt werden.
Damit können auch komplexere Recovery-Szenarien in vollem Umfang in der CDB/PDB-Architektur implementiert werden.
Für weitergehende Informationen und Testmöglichkeiten zum Thema Backup/Recovery aktueller Oracle-Datenbanken empfehlen wir den Workshop:
Kommentare
Keine Kommentare