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 '/u01/app/oracle/product/19.3.0.1/dbhome_1/dbs/bctORCL.ora';
    

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

STATUS  FILENAME                                                  BYTES
------- --------------------------------------------------------- --------
ENABLED /u01/app/oracle/product/19.3.0.1/dbhome_1/dbs/bctORCL.ora 11599872

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

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

Finished backup at 15-JUL-19
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
..............
Starting backup at 15-JUL-19

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>

Tipp:
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ÖSSE
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;

Linux-x86_64 Error: 2: No such file or directory
ORA-27037: unable to obtain file status
ORA-19750: change tracking file: '/u04/app/oracle/product/12.1.0.1/dbhome_1/dbs/bctORCL.ora'
ORA-19755: could not open change tracking file
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/15/2014 15:01:27
..............
Starting backup at 15-JUL-14

..............

Wie kann man den Fehler beheben?

BCT aus- und wieder einschalten (aktuelle Block Change Tracking-Informationen gehen jedoch 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.

Es muss jetzt 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

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.

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.