Oracle 8i | Oracle 9i | Oracle 10g | Oracle 11g | Oracle 12c | Miscellaneous | PL/SQL | SQL | Oracle RAC | Oracle Apps | Linux

Incrementally Updated Backups : Rolling Forward Image Copies Using RMAN

Incrementally updated backups were introduced in Oracle 10g. Using this feature, all changes between the SCN of the original image copy and the SCN of the incremental backup are applied to the image copy, winding it forward to make the equivalent of a new datafile image copy, without the overhead of actually creating a new image copy. Having up to date image copy backups can drastically reduce recovery time in comparison to restoring and recovering conventional RMAN backupsets.

Related articles.

Incrementally Updated Backups

The following example shows how an incrementally updated backup can be used.

RUN {
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE - 7';
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
}

The RECOVER COPY... line will not do anything until the script has been running for more than 7 days. The BACKUP INCREMENTAL line will perform a complete backup (level 0) the first day it is run, with all subsequent backups being level 1 incremental backups. After 7 days, the RECOVER COPY... line will start to take effect, merging all incremental backups older than 7 days into the level 0 backup, effectively moving the level 0 backup forward. The effect of this is that you will permanently have a 7 day recovery window with a 7 day old level 0 backup and 6 level 1 incremental backups. Notice that the tag must be used to identify which incremental backups apply to which image copies.

The following script uses the same method, but includes the archivelog backups and management of obsolete backups.

RUN {
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE-7';
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
  BACKUP DEVICE TYPE DISK TAG 'mydb_incr_backup' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT;
  DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
}

If you wanted to keep your image copy as up to date as possible you might do the following.

RUN {
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE;
  RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup';
}

In this example the incremental backup is merged into the image copy as soon as it is completed.

For best performance, this method should be combined with block change tracking, explained below.

Restoring From Image Copies

Using image copy backups allow two recovery options.

Examples of conventional recoveries are shown below.

# Complete
RUN {
  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  RESTORE DATABASE;
  RECOVER DATABASE;
  ALTER DATABASE OPEN;
}

# Incomplete - Point In Time Recovery (PITR)
RUN { 
  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  SET UNTIL TIME "TO_DATE('15-NOV-2004 00:09:00','DD-MON-YYYY HH24:MI:SS')";
  #SET UNTIL SCN 1000;       # alternatively, you can specify SCN
  #SET UNTIL SEQUENCE 9923;  # alternatively, you can specify log sequence number
  RESTORE DATABASE;
  RECOVER DATABASE;
  ALTER DATABASE OPEN RESETLOGS;
}

Examples of the SWITCH ... TO COPY approach are shown below.

# Switch whole database to image copy backups.
RUN {
  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  SWITCH DATABASE TO COPY; # No restore, just switch
  RECOVER DATABASE;
  ALTER DATABASE OPEN;
}

# Switch an individual file.
SQL "ALTER DATABASE DATAFILE 3 OFFLINE";
SWITCH DATAFILE 3 TO COPY;
RECOVER DATAFILE 3;
SQL "ALTER DATABASE DATAFILE 3 ONLINE";

Block Change Tracking

There are performance issues associated with incremental backups as the whole of each datafile must be scanned to identify changed blocks. From Oracle 10g onward it is possible to track changed blocks using a change tracking file. Enabling change tracking does produce a small overhead, but it greatly improves the performance of incremental backups. The current change tracking status can be displayed using the following query.

SELECT status FROM v$block_change_tracking;

Change tracking is enabled using the ALTER DATABASE command.

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

By default the change tracking file is created as an Oracle Managed File (OMF) in the location pointed to by the DB_CREATE_FILE_DEST parameter. An alternate location can be specified using the following command.

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 
  USING FILE '/u01/oradata/mydb/rman_change_track.f' REUSE;

The tracking file is created with a minumum size of 10M and grows in 10M increments. It's size is typically 1/30,000 the size of the datablocks to be tracked.

Change tracking can be disabled using the following command.

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Renaming or moving a tracking file can be accomplished in the normal way using the ALTER DATABASE RENAME FILE command. If the instance cannot be restarted you can simply disable and re-enable change tracking to create a new file. This method does result in the loss of any current change information.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.