Backup to Disk

This section contains these topics:

See Also: Oracle Database Backup and Recovery Advanced User's Guide for more information on RMAN repository

See Also: Oracle Database Backup and Recovery Basics for more information on block change tracking

See Also: Oracle Database Backup and Recovery Basics for more information on autobackup

■ Determine Disk Backup Methods

■ Create Backups in NOCATALOG Mode and RESYNC CATALOG Afterwards

■ Create Database Backups on Disk in the Flash Recovery Area

■ In a Data Guard Environment, Back Up to Flash Recovery Area on All Sites

2.5.3.1 Determine Disk Backup Methods

When selecting a backup mechanism, the following priorities will drive your backup strategy:

■ Overall backup time

■ Impact on primary

■ Space used by backup

■ Recovery time

Table 2–4 compares different backup alternatives against the different priorities you might have. The table should guide you to choose the best backup approach for your specific business requirements. You might want to minimize backup space while sacrificing recovery time. Alternatively, a higher priority might be on recovery and backup times while space is not an issue.

Best Practices on Optimizing Recovery Times If restore time is the primary concern, then either a database copy or an incremental backup with roll forward immediately should be performed. These two are the only options that provide an immediately usable backup of the database, which then needs only to be recovered to the time of the failure using archive logs created since the last backup was performed.

Best Practices on Minimizing Space Usage If space usage is the primary concern, then an incremental backup with a deferred roll forward should be performed. If a cumulative level 1 incremental backup is performed, then it stores only those blocks that have been changed since the last level 0 backup. With a cumulative incremental backup, the last level 1 backup need only be applied to the level 0 backup. With a differential incremental backup, all level 1 backups have to be applied to the level 0 backup. A cumulative incremental backup will initially consume more space in the flash recovery area than a differential incremental backup. But over time the cumulative incremental backup will consume less space.

Best Practices on Minimizing System Resource Consumption (I/O and CPU) If system resource consumption is the primary concern, then an incremental backup with a block change-tracking file will consume the least amount of resources on the

database. This is true when the amount of data changed for each backup window is below 20% of the total database size. When the amount of data changed for each Table 2–4 Comparison of Backup Options

Backup Option

Overall Backup Time

Impact on Primary

Space Used by Backup

Recovery Time

Full data file copy Fast High Large Fastest

Full backup sets Faster High Smaller Slowest

Incremental backup with roll forward immediately

Faster Low Large Fastest

Incremental backup with roll forward deferred until recovery

Fastest Low Smallest Fast

backup window exceeds 20%, then performing incremental backups will still reduce the amount of disk space required to hold the backup, but may not reduce the backup time.

Example

For many applications, only a small percentage of the entire database is changed each day regardless of whether the transaction rate is very high. Frequently, applications modify a same set of blocks frequently; so, the total dirty block set is small.

For example, a database contains about 600 GB of user data, not including temp files and redo logs. Every 24 hours, approximately 2.5% of the database is changed, which is approximately 15 GB of data. The first level 0 backup takes about 180 minutes and a subsequent level 1 backup takes 20 minutes, while the merge of the backups take 45 minutes. In this example, we observed the following results:

■ Level 0 backup takes 180 minutes, including READs from the data area and WRITEs to the flash recovery area

■ Level 1 backup takes 20 minutes, including READs from the data area and WRITEs to the flash recovery area

■ Rolling forward and merging the backups takes only 45 minutes included READs and WRITEs from the flash recovery area, which offloads possibly contention to the data area if they use separate storage.

■ The net savings are:

– 115 minutes or 64% time savings to create a complete backup – Reduced I/O on the database during backups

For bigger databases, we observed even larger gains.

2.5.3.2 Create Backups in NOCATALOG Mode and RESYNC CATALOG Afterwards

When creating backups to disk or tape, use the target database control file as the RMAN repository, so that backup success does not depend on the availability of the database holding the RMAN repository. This is accomplished by running RMAN with the NOCATALOG option. After the backup is complete, the new backup information stored in the target database control file can be resynchronized with the recovery catalog using the RESYNC CATALOG command.

2.5.3.3 Create Database Backups on Disk in the Flash Recovery Area

Using automatic disk-based backup and recovery, you can create a flash recovery area which automates management of backup-related files:

1. Choose a location on disk.

This location is specified by DB_RECOVERY_FILE_DEST.

2. Choose an upper bound for storage space.

This upper bound is specified by DB_RECOVERY_FILE_DEST_SIZE.

3. Set a retention policy that governs how long backup files are needed for recovery.

Oracle Database 10g then manages the storage used for backup, archived redo logs, and other recovery-related files for your database within this space. Files no longer needed are eligible for deletion when RMAN must reclaim space for new files.

See Also: Oracle Database Backup and Recovery Reference for more information on RESYNC CATALOG

2.5.3.4 In a Data Guard Environment, Back Up to Flash Recovery Area on All Sites

Take backups at the primary and secondary sites. The advantages of this practice include:

■ Significantly reduces RTO in certain double outage scenarios

■ Avoids introducing new backup procedures upon a switchover or failover

■ RMAN file and block media recovery is a recovery option for data failure outages at both primary and secondary sites

Consider a scenario in which backups are done only at the secondary site. Suppose there is a site outage at the secondary site where the estimated time to recover is three days. The primary site is completely vulnerable to an outage that is typically resolved by a failover, or any outage that could be resolved by having a local backup (such as a data failure outage resolved by block media recovery).

In this scenario, a production database outage can be resolved only by physically shipping the off-site tape backups that were taken at the standby site. If primary site backups were available, then restoring locally would be an available option in place of the failover that cannot be done. Data might be lost, but having primary site backups significantly shortens the RTO.

Primary site disk backups are also necessary to ensure a reasonable RTO when using RMAN file or block media recovery. Without a local on disk backup, a backup taken at the standby site must be restored to the primary site, significantly lengthening the RTO for this type of outage.