Incrementally updated image copy backups with RMAN

This ‘Incrementally Updated Backups’ feature was introduced in Oracle 10g.  It allows you to create image copies of your datafiles, and then roll forward the image copies with incremental backups of the database.  Changes made between the SCN of your image copy and the SCN of when your incremental backup was taken, are then applied to the image copy to wind it forward.

The initial image copy backup can take a while to perform, but from thereon you can simply roll forward your image copy each day quite quickly.  The main advantage of using image copies as part of your backup strategy is that the restore times can be reduced quite significantly…always a good thing!

Below is the RMAN backup script I’ve been using recently, scheduled to run on a daily basis:

run {
      recover copy of database with tag 'SNAPDB_INCR_BACKUP' until time 'SYSDATE-7';
      backup incremental level 1 for recover of copy with tag 'SNAPDB_INCR_BACKUP' database;
      backup tag 'SNAPDB_INCR_BACKUP' archivelog all not backed up delete all input;
      delete noprompt obsolete device type disk;
    }

Starting recover at 20-MAR-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=47 device type=DISK
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover
Finished recover at 20-MAR-13

Starting backup at 20-MAR-13
using channel ORA_DISK_1
no parent backup or copy of datafile 1 found
no parent backup or copy of datafile 3 found
no parent backup or copy of datafile 5 found
no parent backup or copy of datafile 4 found
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/u02/oradata/snapdb/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at 20-MAR-13
channel ORA_DISK_1: finished piece 1 at 20-MAR-13
piece handle=/backups/snapdb/03ovsb18_1_1 tag=SNAPDB_INCR_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/u02/oradata/snapdb/system01.dbf
...

Let’s go back to the RUN block above and break it down a little:

run {
      recover copy of database with tag 'SNAPDB_INCR_BACKUP' until time 'SYSDATE-7';
      backup incremental level 1 for recover of copy with tag 'SNAPDB_INCR_BACKUP' database;
      backup tag 'SNAPDB_INCR_BACKUP' archivelog all not backed up delete all input;
      delete noprompt obsolete device type disk;
    }

recover copy of database – this won’t actually do anything in terms of recovering the copy, until the backups have been running for more than 7 days.  After that, RMAN will start applying incremental level 1 backups (with the same tag) to the datafile copies, rolling the database copy forward each day (assuming you run this script daily).

backup incremental level 1 – the first time this command is run, RMAN will perform a full level 0 backup in the form of datafile copies.  Subsequent runs will perform incremental level 1 backups, which will then be used to perform the ‘recover copy’ operation above.

So you end up with a continual 7 day recovery window on disk, in the form of a level 0 backup (datafile copies) and several incremental level 1 backups.

The 3rd and 4th lines of the script above take care of the archive logs and obsolete backup pieces.  The important thing to remember here, is that the same backup tag must be used throughout the script, otherwise your image copy might not roll forward, or you may end up with more than one image copy of your database!

If you wanted a different recovery window, just update the “until time” appropriately, or remove this syntax altogether if you just want to keep your image copy backup as up-to-date as possible.  Here are a couple of examples:

recover copy of database with tag 'SNAPDB_INCR_BACKUP' until time 'SYSDATE-14';
...
recover copy of database with tag 'SNAPDB_INCR_BACKUP';

Using this ‘incrementally updated image copy backup’ strategy is probably the fastest and easiest way to restore a database in full using RMAN.

If you prefer, you can even set the following RMAN configuration parameter so that default backup commands are performed as image copies:

rman target /
configure device type disk parallelism 1 backup type to copy;

You can still override this at runtime, it will just default to this mechanism the rest of the time.

Restoring from image copy backups

There are a couple of routes to restoring your database when using the incrementally updated backup strategy above…

1) Use the SWITCH command

If time is of the essence, then you could use the SWITCH command.  This basically points references in the control file to your datafile copies, so it’s pretty much immediate!  Whilst you can recover your database very quickly using this method, I personally don’t like the idea of your backup area suddenly becoming your datafile location.  In addition, your backup area might be using slower storage etc.

As a test, I’ve just ‘accidentally’ deleted all of my database’s datafiles!  So, to quickly get everything back from my backups, I’m going to use the ‘SWITCH DATABASE TO COPY’ RMAN command:

rm /u02/oradata/snapdb/*.dbf

rman target /

RMAN> shutdown immediate;

using target database control file instead of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of shutdown command at 20/03/2013 15:58:00
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/u02/oradata/snapdb/system01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

RMAN> shutdown abort;

Oracle instance shut down

RMAN> startup mount;

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area     521936896 bytes

Fixed Size                     2229944 bytes
Variable Size                402655560 bytes
Database Buffers             113246208 bytes
Redo Buffers                   3805184 bytes

RMAN> switch database to copy;

datafile 1 switched to datafile copy "/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSTEM_FNO-1_04ovsb2c"
datafile 2 switched to datafile copy "/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSAUX_FNO-2_01ovsaqr"
datafile 3 switched to datafile copy "/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-UNDOTBS1_FNO-3_05ovsb5v"
datafile 4 switched to datafile copy "/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-USERS_FNO-4_07ovsb9d"
datafile 5 switched to datafile copy "/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-APEX_FNO-5_06ovsb8k"

RMAN> recover database;

Starting recover at 20-MAR-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=18 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00002: /backups/snapdb/SNAPDB_data_D-SNAPDB_I-2785346758_TS-SYSAUX_FNO-2_01ovsaqr
channel ORA_DISK_1: reading from backup piece /backups/snapdb/03ovsb18_1_1
channel ORA_DISK_1: piece handle=/backups/snapdb/03ovsb18_1_1 tag=SNAPDB_INCR_BACKUP
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSTEM_FNO-1_04ovsb2c
destination for restore of datafile 00002: /backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSAUX_FNO-2_01ovsaqr
destination for restore of datafile 00003: /backups/snapdb/data_D-SNAPDB_I-2785346758_TS-UNDOTBS1_FNO-3_05ovsb5v
destination for restore of datafile 00004: /backups/snapdb/data_D-SNAPDB_I-2785346758_TS-USERS_FNO-4_07ovsb9d
destination for restore of datafile 00005: /backups/snapdb/data_D-SNAPDB_I-2785346758_TS-APEX_FNO-5_06ovsb8k
channel ORA_DISK_1: reading from backup piece /backups/snapdb/0aovsbvl_1_1
channel ORA_DISK_1: piece handle=/backups/snapdb/0aovsbvl_1_1 tag=SNAPDB_INCR_BACKUP
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 20-MAR-13

RMAN> alter database open;

database opened

We haven’t restored from backup here, only pointed or switched the database to the backup copies.  The datafiles are now referencing what used to be the datafile image copies…

sqlplus / as sysdba
select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-USERS_FNO-4_07ovsb9d
/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-UNDOTBS1_FNO-3_05ovsb5v
/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSAUX_FNO-2_01ovsaqr
/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-SYSTEM_FNO-1_04ovsb2c
/backups/snapdb/data_D-SNAPDB_I-2785346758_TS-APEX_FNO-5_06ovsb8k

Of course, you can just switch individual datafiles to use the copies too, if one datafile in particular went missing:

rman target /
switch datafile 5 to copy;
recover datafile 5;

sqlplus / as sysdba
alter database datafile 5 online;

2) Normal database restore

Alternatively, you can recover your database from the image copy in the same way you would with any other backup set:

run {
      shutdown immediate;
      startup mount;
      set until time "to_date('01-MAR-2013 15:00:00','DD-MON-YYYY HH24:MI:SS')";
      restore database;
      recover database;
      alter database open resetlogs;
    }

Using the script above, RMAN knows about the image copies and will use these to restore and recover your database.

Enabling Block Change Tracking (BCT)

To enhance performance of the incremental backups, you should really look at enabling Block Change Tracking…

select status from v$block_change_tracking;
alter database enable block change tracking using file '/u02/oradata/snapdb/block_change_tracking.dbf';

I’ll write-up a separate post later on about BCT, in some more detail…but when enabled, it keeps a track of any changed blocks so RMAN doesn’t have to scan the entirety of each datafile, for every incremental backup, thus saving quite a bit of processing time.

Some useful image copy RMAN commands

list copy of database;
list copy of datafile 1;
list copy of tablespace system;
backup as copy datafile 1;

References:
RMAN Incremental Backups