RMAN Retention richtig einstellen

Oracle Datenbanken werden im Normalfall per RMAN gesichert und auch die Vorhaltezeit der Backups wird über RMAN-Einstellungen gesteuert. Dabei gibt es zwei Möglichkeiten, entweder gibt man die Redundanz der Backups an oder man definiert eine Zeitspanne. Oftmals wird die Redundanz verwendet. Beispielsweise soll eine Datenbank bis zu einer Woche in der Vergangenheit wiederhergestellt werden können. Die Vollsicherung läuft Samstags und Mittwochs, dazwischen laufen Archivelog- und/oder Inkremental-Backups. Die Redundanz wird also auf 2 gestellt, damit sind immer 2 Vollbackups verfügbar.

Was passiert aber genau? Das zeigen wir am Beispiel, allerdings mit einer Redundanz von 1.

MAN> show all;

 

RMAN configuration parameters for database with db_unique_name ORCL180A are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

[...]

CONFIGURE CONTROLFILE AUTOBACKUP ON; # default

[...]

Mit diesen Einstellungen wird am ersten Tag ein Vollbackup inklusive der Archivelogs durchgeführt:

RMAN> backup incremental level 0 database plus archivelog delete input;

Dementsprechend ergibt sich erst einmal folgendes Bild:

RMAN> list backup of database summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

140 B 0 A DISK 2020-09-22 08:53:36 1 1 NO TAG20200922T085312

141 B 0 A DISK 2020-09-22 08:53:55 1 1 NO TAG20200922T085312

142 B 0 A DISK 2020-09-22 08:54:10 1 1 NO TAG20200922T085312

 

RMAN> list backup of archivelog all summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

143 B A A DISK 2020-09-22 08:54:19 1 1 NO TAG20200922T085419

 

RMAN> list backup of controlfile summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

144 B F A DISK 2020-09-22 08:54:21 1 1 NO TAG20200922T085420

So weit, so gut. Es existiert also das Full Backup (Incremental Level 0) sowie Backups der Archivelogs und ein Backup des Controlfiles. Am darauffolgenden Tag wird die Datenbank erneut gesichert, diesmal aber nur mittels eines inkrementellen Backups.

RMAN> backup incremental level 1 cumulative database plus archivelog delete input;

Dementsprechend existieren nunmehr weitere Backups, unter anderem auch zwei Backups des Controlfile.

RMAN> list backup of database summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

140 B 0 A DISK 2020-09-22 08:53:36 1 1 NO TAG20200922T085312

141 B 0 A DISK 2020-09-22 08:53:55 1 1 NO TAG20200922T085312

142 B 0 A DISK 2020-09-22 08:54:10 1 1 NO TAG20200922T085312

146 B 1 A DISK 2020-09-23 08:21:15 1 1 NO TAG20200923T082101

147 B 1 A DISK 2020-09-23 08:21:22 1 1 NO TAG20200923T082101

 

RMAN> list backup of archivelog all summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

143 B A A DISK 2020-09-22 08:54:19 1 1 NO TAG20200922T085419

145 B A A DISK 2020-09-23 08:20:58 1 1 NO TAG20200923T082057

148 B A A DISK 2020-09-23 08:21:26 1 1 NO TAG20200923T082125

 

RMAN> list backup of controlfile summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

144 B F A DISK 2020-09-22 08:54:21 1 1 NO TAG20200922T085420

149 B F A DISK 2020-09-23 08:21:28 1 1 NO TAG20200923T082127

Üblich ist, das direkt im Anschluss an ein erfolgreiches Backup die nicht mehr benötigten Backups gelöscht werden. Das machen wir hier im Nachgang um den Effekt zu verdeutlichen.

RMAN> report obsolete;

 

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

Report of obsolete backups and copies

Type Key Completion Time Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set 144 2020-09-22 08:54:21

Backup Piece 144 2020-09-22 08:54:21 /u01/app/oracle/fast_recovery_area/orcl180/c-109831069-20200922-01

 

 

RMAN> delete noprompt obsolete;

 

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

using channel ORA_DISK_1

Deleting the following obsolete backups and copies:

Type Key Completion Time Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set 144 2020-09-22 08:54:21

Backup Piece 144 2020-09-22 08:54:21 /u01/app/oracle/fast_recovery_area/orcl180/c-109831069-20200922-01

deleted backup piece

backup piece handle=/u01/app/oracle/fast_recovery_area/orcl180/c-109831069-20200922-01 RECID=144 STAMP=1051779261

Deleted 1 objects

Wie man sieht, ist das Backup des Controlfiles vom Vortag obsolet geworden und wird gelöscht. Ursache dafür ist die Redundanz von 1, die besagt, das ein Backup ausreichend ist. Es existieren aber 2 Backups des Controlfiles, also kann das ältere Backup gelöscht werden.

Nun wird es spannend. Zwischen dem Level-0- und dem Level-1-Backup hat sich ein Fehler in die Datenbank eingeschlichen und die Datenbank soll daher per Point-in-Time Restore auf den Stand des Vortages zurückgesetzt werden. Das klingt erst einmal recht einfach, mündet aber in folgendem Problem:

RMAN> run {

2> set until time '2020-09-22 08:55:00';

3> restore controlfile from autobackup;

4> alter database mount;

5> restore database;

6> recover database;

7> }

 

executing command: SET until clause

 

Starting restore at 2020-09-23 08:28:50

using channel ORA_DISK_1

 

recovery area destination: /u01/app/oracle/fast_recovery_area

database name (or database unique name) used for search: ORCL180A

channel ORA_DISK_1: no AUTOBACKUPS found in the recovery area

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200922

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200921

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200920

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200919

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200918

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200917

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20200916

channel ORA_DISK_1: no AUTOBACKUP in 7 days found

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of restore command at 09/23/2020 08:28:53

RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece

Es wird kein passendes Backup des Controlfiles gefunden. Denn das Controlfile muss zum Stand der geplanten Wiederherstellung passen. Das entsprechende Backup wurde aber durch das "delete obsolete" bereits entfernt. Es gibt also keine (einfache) Möglichkeit, die Datenbank zum gewünschten Zeitpunkt wiederherzustellen. 

Daher sollte man nach Möglichkeit immer statt der Redundanz das Zeitfenster im RMAN definieren. Damit bleiben die Backups des Controlfiles bestehen und werden erst obsolet, wenn sie für das Zeitfenster nicht mehr benötigt werden. Wenn wir das Beispiel fortsetzen und ein weiteres inkrementelles Backup erzeugen, erhalten wir auch wieder ein weiteres Backup des Controlfiles.

RMAN> list backup of controlfile summary;

 

 

List of Backups

===============

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

------- -- -- - ----------- ------------------- ------- ------- ---------- ---

149 B F A DISK 2020-09-23 08:21:28 1 1 NO TAG20200923T082127

154 B F A DISK 2020-09-24 07:37:51 1 1 NO TAG20200924T073750

Nun können wir den Effekt der Retention Policy noch einmal genau nachvollziehen:

RMAN> report obsolete;

 

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

Report of obsolete backups and copies

Type Key Completion Time Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set 146 2020-09-23 08:21:15

Backup Piece 146 2020-09-23 08:21:15 /u01/app/oracle/fast_recovery_area/ORCL180A/backupset/2020_09_23/o1_mf_nnnd1_TAG20200923T082101_hpotbh46_.bkp

Backup Set 147 2020-09-23 08:21:23

Backup Piece 147 2020-09-23 08:21:23 /u01/app/oracle/fast_recovery_area/ORCL180A/AB1CBA0F054E5732E0537924100A5E8B/backupset/2020_09_23/o1_mf_nnnd1_TAG20200923T082101_hpotbyb4_.bkp

Backup Set 149 2020-09-23 08:21:28

Backup Piece 149 2020-09-23 08:21:28 /u01/app/oracle/fast_recovery_area/orcl180/c-109831069-20200923-00

 

RMAN> CONFIGURE RETENTION POLICY TO recovery window of 7 days;

 

old RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

new RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

new RMAN configuration parameters are successfully stored

 

RMAN> report obsolete;

 

RMAN retention policy will be applied to the command

RMAN retention policy is set to recovery window of 7 days

no obsolete backups found

Man sieht, mit einer Redundancy von 1 ist das ältere Backup des Controlfiles obsolet, nach der Änderung der Vorhaltezeit auf ein Zeitfenster von 1 Woche erkennt RMAN, dass das Backup des Controlfiles eigentlich noch benötigt wird. Außerdem wäre auch das erste inkrementelle Backup obsolet und gelöscht worden, durch die Änderung auf das Recovery Window wird auch dieses Backup nunmehr aufgehoben, weil es zur Erfüllung des Recovery Windows erforderlich ist.

Fazit: Ein Recovery Window ist der Redundancy immer vorzuziehen um nicht im Problemfall auf ungeahnte Hürden zu stossen.


Über den Autor

Marco Mischke

Weitere Beiträge dieses Autors

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich