Inkrementelles Backup und Block Change Tracking mit RMAN

03.
September
2014
Veröffentlicht von: Helmut Exner

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.

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.

SQL> select status,filename,bytes from v$block_change_tracking;

STATUS     FILENAME                                        BYTES
---------- ----------------------------------------------- ----------
DISABLED
SQL>


Aktiviert wird BCT mit:

SQL> 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:

ORA-19773: must specify change tracking file name
 
SQL> alter database enable block change tracking
     using file '/u04/app/oracle/product/12.1.0.1/dbhome_1/dbs/bctORCL.ora';
   

SQL> select status,filename,bytes from v$block_change_tracking;

STATUS  FILENAME                                                  BYTES
------- --------------------------------------------------------- --------
ENABLED /u04/app/oracle/product/12.1.0.1/dbhome_1/dbs/bctORCL.ora 11599872

SQL>


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
---------- --- ----------- ---------- ---------------
         2 YES       47936      38766          163840
         1 YES       51072      37591           98304
         3 YES        2112        596           65536
         4 YES       62144      46883           65536
         0 NO         1196       1196            1196

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 262853.1)

RMAN> select FILE#,USED_CHANGE_TRACKING used,BLOCKS_READ,blocks,datafile_blocks from v$backup_datafile;

     FILE# USE BLOCKS_READ     BLOCKS DATAFILE_BLOCKS
---------- --- ----------- ---------- ---------------
         2 YES       47936      38766          163840
         1 YES       51072      37591           98304
         3 YES        2112        596           65536
         4 YES       62144      46883           65536
         0 NO         1196       1196            1196
         2 YES          25          9          163840
         1 YES           5          2           98304
         3 YES          45          7           65536
         4 YES           9          3           65536
         0 NO         1196       1196            1196

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
----- -------------------- ---------------- ------------------
    1                98304                5  .0050862630208333
    2               163840               25  .0152587890625
    3                65536               45  .06866455078125
    4                65536                9  .01373291015625

SQL>

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:

    SQL> 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.:
     
    SQL> alter system set "_bct_bitmaps_per_file" = 16 oder 32;
    (siehe auch My Oracle Support Note 745798.1, 452455.1)

  • 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

  SQL> SELECT filename FROM V$BLOCK_CHANGE_TRACKING;

2.  Datenbank stoppen

  SQL> shutdown immediate;  

3.  BCT File an den neuen Speicherort kopieren

4.  Datenbank mounten

  SQL> startup mount;

5.  BCT File in der Datenbank umbenennen    

  SQL> alter database rename file '<old_location>' TO '<new_location>';

6.  Datenbank öffnen

  SQL> alter database open;


Falls die Datenbank nicht gestoppt werden soll, kann man den Speicherort auch über folgende Befehle ändern:

  SQL> alter database disable block change tracking;
  SQL> 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

SQL> alter database disable block change tracking;

Damit wird BCT ausgeschaltet und der BCT File im Dateisystem gelöscht:

SQL> 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:

oracle@s-tl-021:/u04/app/oracle/product/12.1.0.1/dbhome_1/dbs> ls -ltr bct*
-rw-r----- 1 oracle oinstall 11600384 Jul 15 14:59 bctORCL.ora
oracle@s-tl-021:/u04/app/oracle/product/12.1.0.1/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/2014 15:01:27
ORA-19755: could not open change tracking file
ORA-19750: change tracking file: '/u04/app/oracle/product/12.1.0.1/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):

SQL> alter database disable block change tracking;

SQL> alter database enable block change tracking
     using file '/u04/app/oracle/product/12.1.0.1/dbhome_1/dbs/bctORCL.ora';
     
SQL> select status, filename from V$BLOCK_CHANGE_TRACKING;

STATUS   FILENAME
-------- ------------------------------------------------------------
ENABLED  /u04/app/oracle/product/12.1.0.1/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>


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
---------- --- ----------- ---------- ---------------
         2 NO        47936          1          163840
         1 NO        51072          8           98304
         3 NO         1984         22           65536
         4 NO        62144          2           65536
         0 NO         1200       1200            1200

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;
SQL>
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:

SQL> shutdown immediate;
ORA-03113: end-of-file on communication channel
Process ID: 29313
Session ID: 63 Serial number: 13169
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: '/u04/app/oracle/product/12.1.0.1/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:

SQL> startup
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size                  2290416 bytes
Variable Size            1325403408 bytes
Database Buffers          805306368 bytes
Redo Buffers                4886528 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

SQL>


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>

SQL> alter database open;

Database altered.

SQL>

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.


Memory Verbrauch in der SGA

Der CTWR background Prozess allokiert die Memory Area "CTWR dba buffer"  im large pool der SGA:

SQL> select pool,name,bytes from v$sgastat where name like 'CTWR%';

POOL         NAME                            BYTES
------------ -------------------------- ----------
large pool   CTWR dba buffer                651264

SQL>


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 : 1311518.1)


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>';


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;
}


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:

SQL> 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-Opens internal link in current windowKursen. Schauen Sie doch einfach mal vorbei.

Block Change Tracking RMAN Backup & Recovery

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.