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 stoßen.
Kommentare
Keine Kommentare