Inkrementelles Backup und Block Change Tracking mit RMAN

Transkript

1 Tipps & Tricks: September 2014 Bereich: DBA Erstellung: 09/2014 HE Versionsinfo: 11.2, 12.1 Letzte Überarbeitung: 09/2014 HE Als PDF Downloaden! Inkrementelles Backup und Block Change Tracking mit RMAN Inkrementelle Backups sichern nur geänderte Blöcke, diese können differenziell (default) oder kumulativ sein. Differenzielle Backups sichern alle Blöcke, die seit dem letzten Backup mit dem selben oder dem nächst niedrigeren Level geändert wurden. Kumulative Backups sichern alle Blöcke, die seit dem letzten Backup mit dem nächst niedrigeren Level geändert wurden, sie dauern länger als inkrementelle differenzielle Backups. Dafür können sie das Recovery beschleunigen. Ein Level 0 Backup ist die Grundlage für weitere Level 1 inkrementelle Sicherungen. Tipp: Ein Level 0 Backup sollte mindestens jedes Wochenende (z. B. Sonntag) durchgeführt werden und montags bis samstags: Inkrementelles Backup (Level 1) der Datenbank. Block Change Tracking kann ab Oracle Datenbank 10g (Enterprise Edition) für inkrementelle Sicherungen (Level 1) mit RMAN verwendet werden. Die Zeit für inkrementelle Sicherungen mit RMAN verkürzt sich daher. Die Größe einer Datendatei spielt dann keine große Rolle mehr, sondern nur die Anzahl der veränderten Blöcke. Wenn Block Change Tracking eingeschaltet ist, wird eine Liste der veränderten Blöcke gepflegt, die seit dem letzten Level 0 Backup verändert worden sind. RMAN muss dann nur noch die geänderten Blöcke lesen um das Backup zu erstellen. Block Change Tracking (BCT) aktivieren Standardmäßig ist Block Change Tracking ausgeschaltet. select status,filename,bytes from v$block_change_tracking; STATUS FILENAME BYTES DISABLED Aktiviert wird BCT mit: alter database enable block change tracking; Wenn kein File-Name angegeben wird und DB_CREATE_FILE_DEST (für OMF => oracle managed files) nicht gesetzt ist, bekommt man die Fehlermeldung: MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 1 von 11

2 ORA-19773: must specify change tracking file name alter database enable block change tracking using file '/u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora'; select status,filename,bytes from v$block_change_tracking; STATUS FILENAME BYTES ENABLED /u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora Hinweis: Es muss nun zuerst ein Level 0 Backup (Full-Backup) durchgeführt werden, damit RMAN beim inkrementellen Backup das BCT File verwenden kann! Die Einstellung in der Datenbank ist so definiert, dass die Backups in der Fast Recovery Area abgelegt werden: db_recovery_file_dest string /u04/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 20G Einstellungen im RMAN: Mit dem folgenden Befehl wird bei jedem Backup der Datenbank auch ein Backup des Controlfiles sowie des Spfiles durchgeführt. rman target / RMAN> configure controlfile autobackup on; RMAN> backup incremental level 0 database; Starting backup at 15-JUL-14 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:55 Finished backup at 15-JUL-14 Jetzt kann man prüfen, ob RMAN auf das BCT File zugreifen konnte: RMAN> select FILE#,USED_CHANGE_TRACKING used,blocks_read,blocks,datafile_blocks,creation_time from v$backup_datafile; FILE# USE BLOCKS_READ BLOCKS DATAFILE_BLOCKS YES YES YES YES NO MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 2 von 11

3 RMAN> USE = YES bedeutet, dass der Zugriff erfolgreich war. File# 0 steht für das Controlfile. Nun einen inkrementellen Level 1 Backup durchführen: rman target / RMAN> backup incremental level 1 database; oder RMAN> (backup incremental level 1 cumulative database;) Starting backup at 15-JUL-14 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 15-JUL-14 RMAN> Mit folgenden Abfragen kann überprüft werden, ob RMAN beim inkrementellen Backup das BCT File benutzt hat, wie viele Blöcke gelesen (BLOCKS_READ) und wie viele Blöcke gesichert wurden (BLOCKS): (siehe auch My Oracle Support Note ) RMAN> select FILE#,USED_CHANGE_TRACKING used,blocks_read,blocks,datafile_blocks from v$backup_datafile; FILE# USE BLOCKS_READ BLOCKS DATAFILE_BLOCKS YES YES YES YES NO YES YES YES YES NO SELECT FILE#, AVG(DATAFILE_BLOCKS), AVG(BLOCKS_READ), AVG(BLOCKS_READ/DATAFILE_BLOCKS) * 100 AS "% READ FOR BACKUP" FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND USED_CHANGE_TRACKING = 'YES' GROUP BY FILE# ORDER BY FILE#; FILE# AVG(DATAFILE_BLOCKS) AVG(BLOCKS_READ) % READ FOR BACKUP MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 3 von 11

4 Hinweis: Wenn man die Backups im RMAN über den Befehl delete backup löscht verschwinden auch die Einträge aus der View v$backup_datafile! BCT File Größe Die Anfangsgröße des BCTF ist 1 MB + 10 MB für bitmaps und erweitert sich bei Bedarf immer um weitere 10 MB (bei einer Single Datenbank). Für eine Datenbank bis zu 300 GB ist die File Größe nie kleiner 10 MB und bis zu 600 GB nie kleiner als 20 MB usw. Bei einem RAC-System hat jede Instanz seine eigene Bitmap. Einige Anmerkungen zum Block Change Tracking Block Change Tracking sollte nur für inkrementelle Sicherungen (Level 1) mit RMAN aktiviert werden. Das BCT File ist eine binäre Datei. Eine Sicherung des BCT Files wird von RMAN nicht unterstützt. Block Change Tracking wird über den Background Prozess CTWR durchgeführt. Die Auswirkungen des Block Change Tracking auf die Performance sind minimal. Beim Deaktivieren/Aktivieren gehen die aktuellen Block Change Tracking Informationen verloren. Ab Version 11.2 kann Block Change Tracking auch auf der Standby-Datenbank verwendet werden. Voraussetzung ist die Option: 'Oracle Active Data Guard' In einer Oracle-RAC-Umgebung müssen alle Knoten des Clusters auf das Block Change Tracking-File zugreifen können, z. B. in einer ASM-Diskgroup: alter database enable block change tracking using file '+DATA'; Es werden per default nach einer Level 0 Sicherung nur die Blockänderungen der letzten 7 inkrementellen Backups aufgezeichnet: Normalerweise wird 1x die Woche oder auch 2x die Woche ein Level 0 Backup durchgeführt und an den anderen Tagen ein inkrementelles Level 1 Backup. Dazu ist der Platz in der Bitmap ausreichend, bevor er wieder überschrieben wird. Wenn aber zwischen zwei Level 0 Sicherungen mehr als 7 inkrementelle Sicherungen durchgeführt werden, dann sollte der Parameter _bct_bitmaps_per_file entsprechend höher gesetzt werden, damit mehr Bitmaps für die Speicherung der Block Change Tracking-Informationen zur Verfügung stehen, z. B.: alter system set "_bct_bitmaps_per_file" = 16 oder 32; (siehe auch My Oracle Support Note , ) MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 4 von 11

5 Der Block Change Tracking Status wird im Alert Log protokolliert. Speicherort des BCT Files ändern In diesem Fall bleiben die Informationen des BCT Files erhalten. 1. Aktuellen Speicherort des BCT Files feststellen SELECT filename FROM V$BLOCK_CHANGE_TRACKING; 2. Datenbank stoppen shutdown immediate; 3. BCT File an den neuen Speicherort kopieren 4. Datenbank mounten startup mount; 5. BCT File in der Datenbank umbenennen alter database rename file '<old_location>' TO '<new_location>'; 6. Datenbank öffnen alter database open; Falls die Datenbank nicht gestoppt werden soll, kann man den Speicherort auch über folgende Befehle ändern: alter database disable block change tracking; alter database enable block change tracking using file '<new_location>'; Dabei gehen allerdings die aktuellen Block Change Tracking Informationen verloren. Block Change Tracking kann auch wieder deaktiviert werden alter database disable block change tracking; Damit wird BCT ausgeschaltet und der BCT File im Dateisystem gelöscht: select status,filename,bytes from v$block_change_tracking; STATUS FILENAME BYTES DISABLED Was passiert eigentlich, wenn der BCT File nicht mehr vorhanden ist? Wir simulieren den Verlust, in dem wir das BCT File löschen, während die Datenbank geöffnet ist: MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 5 von 11

6 ls -ltr bct* -rw-r oracle oinstall Jul 15 14:59 bctorcl.ora oracle@s-tl-021:/u04/app/oracle/product/ /dbhome_1/dbs> rm -f bct* Jetzt versuchen wir, einen inkrementellen Level 1 Backup durchzuführen: rman target / RMAN> backup incremental level 1 database; Starting backup at 15-JUL-14 RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/15/ :01:27 ORA-19755: could not open change tracking file ORA-19750: change tracking file: '/u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory RMAN> Wie kann man den Fehler beheben? BCT aus- und wieder einschalten (aktuelle Block Change Tracking-Informationen gehen verloren): alter database disable block change tracking; alter database enable block change tracking using file '/u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora'; select status, filename from V$BLOCK_CHANGE_TRACKING; STATUS FILENAME ENABLED /u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora Eine mögliche, aber im Normalfall unerwünschte Option wäre auch, die Datenbank durchzustarten. Dabei wird das File automatisch wieder angelegt. Jetzt einen inkrementellen Level 1 Backup durchführen: rman target / RMAN> backup incremental level 1 database; Starting backup at 15-JUL-14 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07 Finished backup at 15-JUL-14 RMAN> MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 6 von 11

7 Prüfen, ob RMAN den BCT File benutzt hat: RMAN> select FILE#,USED_CHANGE_TRACKING used,blocks_read,blocks,datafile_blocks from v$backup_datafile; FILE# USE BLOCKS_READ BLOCKS DATAFILE_BLOCKS NO NO NO NO NO RMAN> Es zeigt sich, dass das BCT File nicht benutzt wurde (USE=NO). Es muss jetzt also erst wieder ein Level 0 Backup gemacht werden, damit der inkrementelle Backup wieder optimiert werden kann! Was passiert, wenn das Verzeichnis abhanden kommt, in dem sich der BCT File befindet und man stoppt und startet dann die Datenbank? Normalerweise wird der BCT File ja wieder angelegt, wenn die Datenbank startet. Das ist aber nicht möglich, wenn das Verzeichnis nicht vorhanden ist: select status, filename from V$BLOCK_CHANGE_TRACKING; STATUS FILENAME ENABLED /u04/app/oracle/admin/orcl/bct/bctorcl.ora Das Verzeichnis löschen: oracle@s-tl-021 [ORCL]:/u04/app/oracle/admin/ORCL> rm -rf bct oracle@s-tl-021 [ORCL]:/u04/app/oracle/admin/ORCL> Und die Datenbank stoppen: shutdown immediate; ORA-03113: end-of-file on communication channel Process ID: Session ID: 63 Serial number: exit Im Alert.log erkennbar: Errors in file /u04/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_lgwr_2339.trc: ORA-19755: could not open change tracking file ORA-19750: change tracking file: MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 7 von 11

8 ORA-19750: change tracking file: '/u04/app/oracle/product/ /dbhome_1/dbs/bctorcl.ora' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Und die Datenbank starten: startup ORACLE instance started. Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes Database mounted. ORA-19751: could not create the change tracking file ORA-19750: change tracking file: '/u04/app/oracle/admin/orcl/bct/bctorcl.ora' ORA-27040: file create error, unable to create file Linux-x86_64 Error: 2: No such file or directory Additional information: 1 ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Wenn man das Verzeichnis wieder erzeugt und dann die Datenbank öffnet, wird das BCT File wieder angelegt! oracle@s-tl-021 [ORCL]:/u04/app/oracle/admin/ORCL> mkdir bct oracle@s-tl-021 [ORCL]:/u04/app/oracle/admin/ORCL> alter database open; Database altered. Der aktuelle BCT-Status ist auch im Alert-Log erkennbar : CHANGE TRACKING is enabled for this database, but the change tracking file can not be found. Recreating the file. Change tracking file recreated. Block change tracking file is current. >> Danach unbedingt ein Level 0 Backup durchführen! << Was ist nach einem Restore/Recovery der Datenbank zu beachten? Nach einem Restore und Recovery der ganzen Datenbank bzw. nur einzelner Datenfiles, wird das BCT File zurückgesetzt. Nach einem Level 0 Backup kann dann der inkrementelle Level 1 Backup wieder davon profitieren. MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 8 von 11

9 Memory Verbrauch in der SGA Der CTWR background Prozess allokiert die Memory Area "CTWR dba buffer" im large pool der SGA: select pool,name,bytes from v$sgastat where name like 'CTWR%'; POOL NAME BYTES large pool CTWR dba buffer Wenn viele inkrementelle Level 1 Backups durchgeführt werden, sollte der CTWR dba buffer sowie der Large Pool beobachtet werden! (siehe auch My Oracle Support Note : ) Eine andere durchaus empfehlenswerte Backup-Strategie wäre ein "Incrementally Updating Backup" zusammen mit einem Image-Copy und dem Feature "recover copy of" und dem Block Change Tracking. Der Parameter tag muss bei Incrementally Updated Backups angegeben werden. Damit wird später beim Anwenden der inkrementellen Backups definiert, welches Backup verwendet werden soll, z. B. Bei einer Retention Policy von 1 Tag: rman target / RMAN> configure retention policy to redundancy 1; run { recover copy of database with tag 'incr_update'; backup incremental level 1 for recover of copy with tag 'incr_update' database; } Bei der ersten Ausführung wird eine Level 0 Image-Copy der Datendateien erzeugt. Der "recover copy of" wird noch nicht benutzt. Erst ab dem 3. Mal wird dann ein Roll-Forward des Image-Copy mit der inkrementellen Sicherung durchgeführt. Bei einer Retention Policy von 7 Tagen : run { recover copy of database with tag 'incr_update' until time 'sysdate-8'; backup incremental level 1 for recover of copy with tag 'incr_update' database; } Jetzt kann noch die Fast Recovery Area z. B. auf eine andere Platte oder auch auf Band gesichert werden. Mit Oracle 11g Release 2 ist die Sicherung der FRA auf Platte möglich: RMAN> backup recovery area to destination '<backup_location>'; MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 9 von 11

10 Neu ab Oracle 12.1 Ab Oracle 12c gibt es auch die Möglichkeit Mulitsection Incremental Backups zu verwenden. Dies war bereits für Level 0 Backups ab Oracle 11g möglich. Das Multisection bietet den Vorteil, dass große Datendateien parallel gesichert werden können. Empfehlenswert auch für die Sicherung bei Bigfile Tablespaces. Hier kann auch das Block Change Tracking wie weiter oben erwähnt eingesetzt werden. Das folgende Beispiel konfiguriert 2 Disk Channels und macht dann den Backup der Datenbank: rman target/ RMAN> configure device type disk parallelism 2; RMAN> backup incremental level 0 section síze 500M database; Parallelism ist nur mit Enterprise Option verfügbar, sonst kommt folgender Fehler : Starting backup at 27-AUG-14 RMAN-06908: WARNING: operation will not run in parallel on the allocated channels RMAN-06909: WARNING: parallelism require Enterprise Edition RMAN> backup incremental level 1 section size 500M database; Sollte die Section Size größer sein als die Size des Datenfiles, dann macht RMAN keine multisection Backups. Archivelog Backup Grundsätzlich sollte auch immer regelmäßig ein Backup der Archivelogs durchgeführt werden, unabhängig von der Backup-Strategie der Datenbank, z. B. nach jedem Level 0 / Level 1 Backup und zusätzlich ca. alle 2 Stunden - Backup aller archivierten Redolog-Dateien, die nicht schon zweimal gesichert wurden: rman> connect target / RMAN> backup archivelog all not backed up 2 times; Starting backup at 15-JUL-14 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02 Finished backup at 15-JUL-14 RMAN> Bereinigen der Backups und Archivelogs rman> connect target / RUN { crosscheck archivelog all; delete noprompt expired archivelog all; crosscheck backup; delete noprompt expired backup; delete noprompt obsolete; delete noprompt archivelog all backed up 2 times to disk; } MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 10 von 11

11 Fazit Durch das Block Change Tracking kann man den inkrementellen Backup wesentlich beschleunigen, weil nur die geänderten Blöcke zum Sichern gelesen werden müssen. Durch regelmäßiges Monitoring sollte sichergestellt werden, dass der BCT File auch dafür benutzt werden kann: select count(1) from v$backup_datafile where USED_CHANGE_TRACKING = 'NO' and file#!= 0; Falls hier Werte > 1 zurückgegeben werden, sollte eine Überprüfung stattfinden. Diesen und weitere Tipps rund um den RMAN erhalten Sie in unseren RMAN- oder DBA-Kursen. Schauen Sie doch einfach mal vorbei. MuniQSoft GmbH, Grünwalder Weg 13a, Unterhaching, Tel. 089 / Seite 11 von 11