1. Start
  2. Unternehmen
  3. Blog
  4. RMAN: Wie prüfe ich meine Backups

RMAN: Wie prüfe ich meine Backups

Veröffentlicht
Author
Join the Conversation
3 Comments
Categories
Tags

Einleitung

Der heutige Blogeintrag dreht sich um das Datenbank Backup. Seit der Release 8 gibt es den RMAN für diesen Job. Allerdings ist ein Backup und die Backupstrategie nur die halbe Miete. Viel wichtiger ist es, zu wissen, ob man die Backups auch für die erforderlichen Restore Szenarien verwenden kann. Hier gibt es oft Lücken, Backups werden nur selten auf ihre Wiederherstellbarkeit hin geprüft, noch seltener werden echte Tests der Wiederherstellung durchgeführt. Daher wollen wir heute ein paar Grundlagen dazu vorstellen.

Hier die Einstellungen der 19c Datenbank, die für die folgenden Beispiele verwendet wurde. Zu sehen ist da beispielsweise auch unsere Empfehlung, die Vorhaltezeit als Recovery Window festzulegen anstelle von Redundancy. Denn typischerweise bestehen Anfordernungen, wie lange Backups aufgehoben werden müssen. Das Recovery Window sorgt genau dafür. Bei Verwendung von Redundancy ergibt sich die Vorhaltezeit nur mittelbar aus der Backup Strategie und ändert sich folglich auch bei Anpassungen an der Strategie.

 

RMAN> show all;

RMAN configuration parameters for database with db_unique_name ASM19A are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/db/19/db_se/dbs/snapcf_asm19.f'; # default

 

 

Wiederherstellbarkeit

Kommen wir nun zum eigentlichen Thema, der Prüfung der Backups. Die erste Frage ist, kann ich meine Datenbank überhaupt zum Zeitpunkt X wiederherstellen und welche Dateien benötige ich dafür? Vorraussetzung zur Beantwortung dieser Frage ist ein aktuelles Controlfile und die Datenbankinstanz mindestens im Mount Status. Ist das gegeben, kann mit dem RMAN Befehl "RESTORE PREVIEW" eine Übersicht generiert werden, welche Datendateien aus welchen Backups wiederhergestellt werden müssen, bis zu welcher SCN recovered werden muss, um die Datenbank konsistent zu machen und woher die dafür nötigen Archivelogs zu beziehen sind.

 

MAN> restore preview database;

Starting restore at 2022-06-20 12:58:55
using channel ORA_DISK_1


List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
36      Full    949.34M    DISK        00:00:51     2022-06-20 12:55:57
        BP Key: 36   Status: AVAILABLE  Compressed: NO  Tag: TAG20220620T125506
        Piece Name: +DATA/ASM19A/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.410.1107867307
  List of Datafiles in backup set 36
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  1       Full 6537257    2022-06-20 12:55:07              NO    +DATA/ASM19A/DATAFILE/system.264.1101215045
  3       Full 6537257    2022-06-20 12:55:07              NO    +DATA/ASM19A/DATAFILE/sysaux.266.1101215093
  5       Full 6537257    2022-06-20 12:55:07              NO    +DATA/ASM19A/DATAFILE/undotbs1.268.1101215125
  7       Full 6537257    2022-06-20 12:55:07              NO    +DATA/ASM19A/DATAFILE/users.272.1101215181

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
38      Full    511.19M    DISK        00:00:40     2022-06-20 12:57:11
        BP Key: 38   Status: AVAILABLE  Compressed: NO  Tag: TAG20220620T125506
        Piece Name: +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.408.1107867409
  List of Datafiles in backup set 38
  Container ID: 2, PDB Name: PDB$SEED
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  2       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/system.265.1101215079
  4       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/sysaux.267.1101215115
  6       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/undotbs1.269.1101215137

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
37      Full    473.00M    DISK        00:00:36     2022-06-20 12:56:23
        BP Key: 37   Status: AVAILABLE  Compressed: NO  Tag: TAG20220620T125506
        Piece Name: +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.409.1107867363
  List of Datafiles in backup set 37
  Container ID: 3, PDB Name: PDBMMI
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  8       Full 6537280    2022-06-20 12:56:02              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/system.324.1103016905
  9       Full 6537280    2022-06-20 12:56:02              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/sysaux.323.1103016903
  10      Full 6537280    2022-06-20 12:56:02              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/undotbs1.322.1103016903

List of Archived Log Copies for database with db_unique_name ASM19A
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
181     1    180     A 2022-06-19 23:08:11
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_180.406.1107867523

182     1    181     A 2022-06-20 12:58:43
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_181.405.1107867527

recovery will be done up to SCN 6537257
Media recovery start SCN is 6537257
Recovery must be done beyond SCN 6537280 to clear datafile fuzziness
Finished restore at 2022-06-20 12:58:57

 

Das Beispiel wäre ein vollständiges Recovery. Natürlich funktioniert das auch als Point-in-Time Recovery, wenn wir den entsprechenden Zeitstempel mitgeben. RMAN wählt dann entsprechend die dafür erforderlichen Dateien aus.

 

RMAN> run {
2> set until time "to_date('15.06.2022 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";
3> restore preview database;
4> }

executing command: SET until clause

Starting restore at 2022-06-20 12:40:30
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=381 device type=DISK


List of Backup Sets
===================


BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
28      Full    946.90M    DISK        00:01:18     2022-06-14 08:25:22
        BP Key: 28   Status: AVAILABLE  Compressed: NO  Tag: TAG20220614T082404
        Piece Name: +DATA/ASM19A/BACKUPSET/2022_06_14/nnndf0_tag20220614t082404_0.429.1107332645
  List of Datafiles in backup set 28
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  1       Full 5877170    2022-06-14 08:24:04              NO    +DATA/ASM19A/DATAFILE/system.264.1101215045
  3       Full 5877170    2022-06-14 08:24:04              NO    +DATA/ASM19A/DATAFILE/sysaux.266.1101215093
  5       Full 5877170    2022-06-14 08:24:04              NO    +DATA/ASM19A/DATAFILE/undotbs1.268.1101215125
  7       Full 5877170    2022-06-14 08:24:04              NO    +DATA/ASM19A/DATAFILE/users.272.1101215181

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
30      Full    511.19M    DISK        00:01:10     2022-06-14 08:27:35
        BP Key: 30   Status: AVAILABLE  Compressed: NO  Tag: TAG20220614T082404
        Piece Name: +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/BACKUPSET/2022_06_14/nnndf0_tag20220614t082404_0.431.1107332817
  List of Datafiles in backup set 30
  Container ID: 2, PDB Name: PDB$SEED
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  2       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/system.265.1101215079
  4       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/sysaux.267.1101215115
  6       Full 3568066    2022-05-13 08:02:10              NO    +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/DATAFILE/undotbs1.269.1101215137

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
29      Full    472.72M    DISK        00:01:18     2022-06-14 08:26:18
        BP Key: 29   Status: AVAILABLE  Compressed: NO  Tag: TAG20220614T082404
        Piece Name: +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/BACKUPSET/2022_06_14/nnndf0_tag20220614t082404_0.430.1107332731
  List of Datafiles in backup set 29
  Container ID: 3, PDB Name: PDBMMI
  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- ------------------- ----------- ------ ----
  8       Full 5877219    2022-06-14 08:25:30              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/system.324.1103016905
  9       Full 5877219    2022-06-14 08:25:30              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/sysaux.323.1103016903
  10      Full 5877219    2022-06-14 08:25:30              NO    +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/DATAFILE/undotbs1.322.1103016903
using channel ORA_DISK_1


List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
32      124.40M    DISK        00:00:08     2022-06-14 08:28:45
        BP Key: 32   Status: AVAILABLE  Compressed: NO  Tag: TAG20220614T082836
        Piece Name: +DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t082836_0.434.1107332917

  List of Archived Logs in backup set 32
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    160     5867536    2022-06-14 03:55:26 5877469    2022-06-14 08:28:34

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
34      252.50K    DISK        00:00:00     2022-06-14 08:52:22
        BP Key: 34   Status: AVAILABLE  Compressed: NO  Tag: TAG20220614T085222
        Piece Name: +DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t085222_0.428.1107334343

  List of Archived Logs in backup set 34
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    161     5877469    2022-06-14 08:28:34 5878658    2022-06-14 08:52:20
List of Archived Log Copies for database with db_unique_name ASM19A
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
163     1    162     A 2022-06-14 08:52:20
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_162.432.1107338933

164     1    163     A 2022-06-14 10:08:52
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_163.427.1107338975

165     1    164     A 2022-06-14 10:09:34
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_164.426.1107381641

166     1    165     A 2022-06-14 22:00:39
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_15/thread_1_seq_165.425.1107389427

167     1    166     A 2022-06-15 00:10:25
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_15/thread_1_seq_166.424.1107443361

recovery will be done up to SCN 6129930
Media recovery start SCN is 5877170
Recovery must be done beyond SCN 5877219 to clear datafile fuzziness
Finished restore at 2022-06-20 12:40:34

 

Beide Varianten können auch als "Summary" ausgeführt werden, was die Ausgabe deutlich verkürzt, aber auch die Ausgabe der Namen der Backupsets weglässt.

 

MAN> restore preview summary database;

Starting restore at 2022-06-20 12:59:38
using channel ORA_DISK_1


List of Backups
===============
Key     TY LV S Device Type Completion Time     #Pieces #Copies Compressed Tag
------- -- -- - ----------- ------------------- ------- ------- ---------- ---
36      B  F  A DISK        2022-06-20 12:55:57 1       1       NO         TAG20220620T125506
38      B  F  A DISK        2022-06-20 12:57:11 1       1       NO         TAG20220620T125506
37      B  F  A DISK        2022-06-20 12:56:23 1       1       NO         TAG20220620T125506

List of Archived Log Copies for database with db_unique_name ASM19A
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
181     1    180     A 2022-06-19 23:08:11
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_180.406.1107867523

182     1    181     A 2022-06-20 12:58:43
        Name: +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_181.405.1107867527

recovery will be done up to SCN 6537257
Media recovery start SCN is 6537257
Recovery must be done beyond SCN 6537280 to clear datafile fuzziness
Finished restore at 2022-06-20 12:59:40

 

 

Backupsets prüfen

Durch das Restore Preview wissen wir nun, welche Dateien für ein Restore/Recover benötigt werden. Das stellt aber noch keine Aussage darüber dar, ob diese Dateien sich überhaupt wiederherstellen lassen. Das können wir mit dem Befehl "RESTORE VALIDATE" überprüfen. Dabei werden die Backupsets komplett gelesen, nicht aber zurückgeschrieben. Wir erhalten damit also eine Aussage zur Lesbarkeit der Backupsets und zur Dauer eines Restores.

 

RMAN> restore validate database;

Starting restore at 2022-06-20 13:08:56
using channel ORA_DISK_1

channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece +DATA/ASM19A/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.410.1107867307
channel ORA_DISK_1: piece handle=+DATA/ASM19A/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.410.1107867307 tag=TAG20220620T125506
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece +DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.409.1107867363
channel ORA_DISK_1: piece handle=+DATA/ASM19A/DD8ABAEDBCFF41B3E0537924100A7D12/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.409.1107867363 tag=TAG20220620T125506
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece +DATA/ASM19A/DBE733C49C871061E0537924100A94F1/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.408.1107867409
channel ORA_DISK_1: piece handle=+DATA/ASM19A/DBE733C49C871061E0537924100A94F1/BACKUPSET/2022_06_20/nnndf0_tag20220620t125506_0.408.1107867409 tag=TAG20220620T125506
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:15
Finished restore at 2022-06-20 13:09:45

 

Wir wissen nun, dass sich die Datendateien wie gewünscht wiederherstellen lassen. Was ist aber mit den Archivelogs? Auch diese gehören zu einem Recovery Szenario und müssen geprüft werden. Dafür verwenden wir die Ausgabe aus dem "RESTORE PREVIEW":

 

Media recovery start SCN is 6537257
Recovery must be done beyond SCN 6537280 to clear datafile fuzziness

 

Wir benötigen die Start-SCN für das Validieren der Archivelogs:

 

RMAN> restore validate archivelog from scn 6537257;

Starting restore at 2022-06-20 13:20:57
using channel ORA_DISK_1

channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_180.406.1107867523
channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_20/thread_1_seq_181.405.1107867527
Finished restore at 2022-06-20 13:21:00

 

In diesem Fall, für ein vollständiges Recovery, werden also zwei Archivelogs benötigt, die noch in der Fast Recovery Area verfügbar sind. Analog können wir auch für das Point-in-Time Recovery aus dem obigen Beispiel die benötigten Archivelogs prüfen.

 

RMAN> run {
2> set until time "to_date('15.06.2022 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";
3> restore validate archivelog from scn 5877170;
4> }

executing command: SET until clause

Starting restore at 2022-06-20 13:18:36
using channel ORA_DISK_1

channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_162.432.1107338933
channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_163.427.1107338975
channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_14/thread_1_seq_164.426.1107381641
channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_15/thread_1_seq_165.425.1107389427
channel ORA_DISK_1: scanning archived log +DATA/ASM19A/ARCHIVELOG/2022_06_15/thread_1_seq_166.424.1107443361
channel ORA_DISK_1: starting validation of archived log backup set
channel ORA_DISK_1: reading from backup piece +DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t082836_0.434.1107332917
channel ORA_DISK_1: piece handle=+DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t082836_0.434.1107332917 tag=TAG20220614T082836
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting validation of archived log backup set
channel ORA_DISK_1: reading from backup piece +DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t085222_0.428.1107334343
channel ORA_DISK_1: piece handle=+DATA/ASM19A/BACKUPSET/2022_06_14/annnf0_tag20220614t085222_0.428.1107334343 tag=TAG20220614T085222
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
Finished restore at 2022-06-20 13:18:46

 

Wie wir sehen, werden einige Archivelogs aus einem Backupset gelesen, andere werden direkt aus der Fast Recovery Area bezogen. Aber es werden zumindest alle benötigten Dateien gefunden und können fehlerfrei gelesen werden.

Auf diese Art würden wir auch feststellen, wenn Backups und/oder Archivelogs fehlen. Um das zu demonstrieren, wurden alle Archivelog Backups und die Archivelogs der letzten 24 Stunden gelöscht.

 

RMAN> restore validate archivelog from scn 6537257;

Starting restore at 2022-06-20 13:29:11
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/20/2022 13:29:11
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of archived log for thread 1 with sequence 181 and starting SCN of 6537424 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 180 and starting SCN of 6504270 found to restore

 

RMAN> run {
2> set until time "to_date('15.06.2022 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";
3> restore validate archivelog from scn 5877170;
4> }

executing command: SET until clause

Starting restore at 2022-06-20 13:27:19
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/20/2022 13:27:20
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of archived log for thread 1 with sequence 161 and starting SCN of 5877469 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 160 and starting SCN of 5867536 found to restore

 

 

Trial Recovery

Über die vorgestellten Befehle hinaus gibt es auch noch das Trial Recovery, dass mit dem RMAN Befehl "RECOVER TEST" durchgeführt werden kann. Dabei werden die Archivelogs nicht nur gelesen, sondern es wird darüber hinaus auch geprüft, ob die Änderungen aus dem Redostream anwendbar sind. Allerdings hat diese Funktion zwei Haken. Zum einen müssen die Datendateien dann schon wiederhergestellt sein und zum anderen ist das ein Feature der Enterprise Edition.

 

RMAN> recover test database until  scn 5877220;

Starting recover at 2022-06-14 09:03:16
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/14/2022 09:03:17
RMAN-06556: datafile 1 must be restored from backup older than SCN 5877220

 

Das Feature kann man zum Testen des Backups also nur sinnvoll verwenden, wenn das Restore auf einer separaten Instanz erfolgt. Und dann können wir auch gleich das Recovery komplett durchführen.

Fazit

Mit den beiden RMAN Befehlen "RESTORE PREVIEW" und "RESTORE VALIDATE" kann man sehr gut prüfen, ob die gewählte Backup Strategie funktioniert um die gewünschten Recovery Szenarien abzudecken. Außerden erhält man gleich noch eine Aussage, ob die Backups überhaupt verfügbar und lesbar sind. So ist man im Falle eines Falles zumindest etwas ruhiger beim Durchführen des Restores und erlebt hoffentlich keine bösen Überraschungen.

Kommentare

|

Hi Jaya,

that's true, the example works at CDB level. That implies, we include all PDBs that exist inside this CDB. So if the CDB can be restored, so can any PDB. In case you want to make sure, use these commands:

RMAN> run {

2> set until time "to_date('05.01.2024 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";

3> restore preview pluggable database pdb2;

4> }

RMAN> run {

2> set until time "to_date('05.01.2024 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";

3> restore preview summary pluggable database pdb2;

4> }

But remember, you can't just restore a PDB, you will always need a CDB to host the PDB. So to be more precise, you might want to use this syntax:

RMAN> run {

2> set until time "to_date('05.01.2024 14:00:00', 'dd.mm.yyyy hh24:mi:ss')";

3> restore preview summary database pluggable database pdb2;

4> }

The check for the necassary archivelogs is then the same as already descibed in the post.

Hope that helps, Marco

|

Hi, Thanks for excellent article

I have one question if you can please answer

In above case as i understand you are validating/preview complete CDB level backup

If i have to restore only one PDB is there way i can only validate/preview one PDB backup instead of full CDB backup , to make sure restore of below pdb command finish successfully

For Example

run {

set until time "to_date('2023-10-20:10:41:09', 'yyyy-mm-dd:hh24:mi:ss')";

restore pluggable database pdb1;

recover pluggable database pdb1 auxiliary destination='/u04/recover';

alter pluggable database pdb1 open resetlogs;

}

Thank you

|

Vielen Dank für diesen Artikel, werde ich mal ausprobieren.

Kommentar schreiben

* Diese Felder sind erforderlich