SOS DBA

Oracle Backup and Recovery for a VLDB (Very Large Database) February 10, 2011

There is an ongoing focus for businesses to minimise downtime and increase operational continuity.  With such challenges, IT staff are constantly under pressure to meet such demands.   For DBAs, backup and recovery is one of the key areas which can be reviewed to ensure that a faster approach to recovery can be achieved to reduce downtime.

An RMAN feature called Incremental Merge (also referred to as Incremental Updated)  Backups can significantly reduce recovery time if configured correctly.  Perhaps not as widely used but has been around since 10g,  it is the ideal backup methodology for a VLDB (Very Large Database).  How it works is that the image copies of the data files are created and  incrementals are then applied rolling forward the image copies after each backup operation.   It is also important to enable fast incremental backups with BCT (Block Change Tracking). For more detailed information on BCT, please refer to the Pythian Whitepaper written by Alexander Gorbachev.

The table below lists the configuration that will be used for the following demonstration:

SECTION 1 – CONFIGURE BLOCK CHANGE TRACKING

1. To create block change tracking file, run the command in sqlplus as sysdba:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '<path_to_block_change_file_name>';

For example:
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u02/oradata/VLDB/bct_VLDB.ctf';


IMPORTANT NOTE: If running in a RAC configuration, the following file needs to be placed on the cluster shared file system.

2. Login to database and verify the location of data files.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u02/oradata/VLDB/o1_mf_system_7o8kj2gt_.dbf
2 /u02/oradata/VLDB/o1_mf_sysux_2o3mt9jl_.dbf
3 /u02/oradata/VLDB/o1_mf_undotbs_1c5gb8nh_.dbf
4 /u02/oradata/VLDB/o1_mf_users_5v5db3vv_.dbf

SECTION 2 – CONFIGURE RMAN PARAMETERS

1. Register database with RMAN Catalog if using Catalog mode. See example here.

2. Connect to RMAN in catalog (or no catalog) mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] rman target / catalog rman/@RMANCAT


3. Configure the preferred RMAN Recovery Window. In the example, the recovery window will be 3 days.
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

4. It is also recommended that you enable autobackup of controlfile in RMAN.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;


SECTION 3 – Performing the Incremental Merge (Updated) Backup

1. Perform the backup of the database in RMAN, and this will create an image copy on the initial run otherwise it will apply the incrementals and rolls forward the image copies of data files.
RMAN> run
{
sql 'alter system archive log current';
recover device type disk
copy of database with tag 'MIB_UPDATE';
backup incremental level 1
for recover of copy with tag 'MIB_UPDATE' database;
sql 'alter system archive log current';
}
list copy of database tag 'MIB_UPDATE';
list backup tag 'MIB_UPDATE';


2. Repeat the previous step for any future or subsequent backups.

SECTION 4 – Performing the Recovery from Incremental Merge (Updated) Backup

An unexpected outage has occurred and now a recovery is required to be performed to bring the database back up quickly as possible.

1. To perform the database recovery ensure that the database in MOUNT mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> shutdown abort
SQL> startup mount


2. In RMAN, switch database to use image copy and then perform recovery.
RMAN> set echo on;
switch database to copy;
run {
recover database;
alter database open;
}


3. Login to database and verify the location of data files are pointing to the recovered image copies.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u03/orafra/VLDB/datafile/o1_mf_system_6o7mj1gt_.dbf
2 /u03/orafra/VLDB/datafile/o1_mf_sysaux_6o7mj4j9_.dbf
3 /u03/orafra/VLDB/datafile/o1_mf_undotbs1_6o7ml4yx_.dbf
4 /u03/orafra/VLDB/datafile/o1_mf_users_6o7mlhl4_.dbf

SECTION 5 – Switching database files back to original data file location

As the database is continuing to run from where the recovered image copies are located, there may be a desire to restore it back to its original location. This is optional, however it is recommended if you are running image copies from FRA (Fast Recovery Area).

1. Backup the database in RMAN
RMAN> run
{
ALLOCATE CHANNEL d1 TYPE DISK FORMAT '/u02/oradata/VLDB/%U.dbf';
recover
copy of database with tag 'MIB_RELOCATE';
backup incremental level 1
for recover of copy with tag 'MIB_RELOCATE' database;
release channel d1;
}
list copy of database tag 'MIB_RELOCATE';
list backup tag 'MIB_RELOCATE';


NOTE: If this is the first time of running the backup to new location, it will create the image copies of the datafiles.

2. Repeat the previous step for any future or subsequent backups until a time can be scheduled to switch back.

3. When a planned time has been scheduled and switch back can be performed, shutdown database and startup in MOUNT mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup mount


4. Switch database to use image copy and then perform recovery.  The database will now be started using image copies which is now configure in the original data file location.
RMAN> set echo on;
switch database to copy;
run {
recover database;
alter database open;
}


5. Login to database and verify the data files are pointing to the recovered image copies back in the original location (or directory).
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-SYSTEM_FNO-1_cim4edhc.dbf
2 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-SYSAUX_FNO-2_cjm4edig.dbf
3 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-UNDOTBS1_FNO-3_ckm4edjj.dbf
4 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-USERS_FNO-4_clm4edk2.dbf


CONSIDERATIONS
In conclusion, it is worth noting that when using RMAN Incremental Merge (Updated) Backup strategy, it is important to consider the following:

• More storage is required to store the copy of database in addition to the traditional incremental backups.
• For Point-In-Time recovery, continue to at least perform one full backup of database and include archive logs.  This can be can be performed less frequently (ie weekly, fortnightly, monthly).
• Validate image copies and backups to detect if there is corruption or missing files which may compromise recovery.
• Image copies of database should be on same storage tier as online data files to ensure performance it is not impacted when switching to database copy for recovery.
• Image copies do not have to be stored in FRA, but should be stored on disk.