8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | 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.
- Incrementally Updated Backups
- Incrementally Updated Backups and Compression
- Restoring From Image Copies
- Block Change Tracking
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 image copy backups the first day it is run (and for any new datafiles), 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'; DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK; 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.
Incrementally Updated Backups and Compression
Binary compression can be used in conjunction with incrementally updated image copy backups. In the following example, the AS COMPRESSED BACKUPSET
clause is added to both the backup commands. This will cause both incremental and archivelog backups to be compressed, since they are backup set backups. If there is no level 0 backup, the presence of the FOR RECOVER OF COPY WITH TAG
clause causes an image copy backup to be performed, rather than a backup set backup. Image copies are never compressed.
RUN { RECOVER COPY OF DATABASE WITH TAG 'mydb_incr_backup' UNTIL TIME 'SYSDATE-7'; BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'mydb_incr_backup' DATABASE; BACKUP AS COMPRESSED BACKUPSET DEVICE TYPE DISK TAG 'mydb_incr_backup' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT; DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK; }
So you end up with an uncompressed level 0 image copy backup, but all subsequent incremental and archivelog backups are compressed backup set backups.
Restoring From Image Copies
Using image copy backups allow two recovery options.
- Conventional restore and recovery : Image copies are copied from the backup location to the original datafile location, then they are recovered using any existing incremental backups and archived redo logs.
SWITCH ... TO COPY
: To improve recovery time, the restore of the image copy can be omitted and the image copy can be used in place as the new datafile. The image copies must still be recovered using any existing incremental backups and archived redo logs, so only the file copy time is saved. Remember, if the image copy is used in place, you have lost your image copy backup!
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. 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:
- Incrementally Updated Backups: Rolling Forward Image Copies of Data Files
- Recovery Manager (RMAN) Enhancements in Oracle Database 10g
Hope this helps. Regards Tim...