Preparing an RMAN Backup Strategy

---

RMAN performs invaluable services to achieve high availability, even if you are not using RAC or Data Guard and merely looking for simple, straight-forward solutions for the unclustered, stand-alone database running on a modest server. While RMAN provides perhaps the single most powerful out-of-the-box backup experience in the market, to fully unlock its potential, you need to spend a few moments configuring RMAN to work for you.

The Flashback Recovery Area

The flashback recovery area (FRA) is not a requirement for using RMAN, but it should be. New to Oracle Database 10g, the recovery area is a specific location on disk that you set up to house all the Oracle recovery files. Recovery files refers to all files that might be required for a media recovery operation: full datafile backups, incremental backups, datafile copies, backup controlfiles, and archivelogs. The FRA also functions as a repository for mirrored copies of online redo log files, the block change tracking file, and a current controlfile. If set up, flashback logs for using the Flashback Database option also live in the FRA (see Chapter 9).

The concept behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and RMAN can then micromanage, while the DBA moves on to other important HA duties. This simplification is based on some underlying principles of a solid backup strategy that focuses on availability:

• At least one copy of important datafiles, if not the entire database, should be kept on disks that are locally accessible to the database.

• Backups past a certain age should be moved to tape based on storage pressure on local disks.

• Long-term backup management should be almost completely automatic, based on business rules.

The FRA that you set up can be either a directory on a normal disk volume or it can be an Automatic Storage Management (ASM) disk group (see Chapter 3 on ASM setup and usage). You specify the size of the FRA as an init parameter. When determining how large to make your FRA, consider the types and number of files that you will be putting there. This, of course, gets to the heart of your backup and recovery strategy (which we have not discussed yet) from an HA perspective. Let's just say, for now, that what you need is space for two complete copies of your database and a few days worth of archivelogs, and then add 20 percent on top of that.

The FRA is determined by two initialization parameters: db_recovery_file_dest and db_recovery_file_dest_size. The first determines the location and the second, the size. These can be set in your init.ora file, if you still use one, or in the spfile via an 'alter system set...' command.

With a flashback recovery area configured, you are not required to set any other log_archive_dest_n parameter for archivelogs; by default, with an FRA, Oracle will default log_archive_dest_10 to the FRA. It should be noted, as well, that with an FRA in use, you cannot use log_archive_dest or log_archive_duplex_dest-but, of course, you rid yourself of these outdated parameters long ago…right?

FRA functionality comes on the tails of two other Oracle technologies: Oracle Managed Files (OMF), the means by which init.ora parameters determine the size, name, and function of database files; and Automatic Storage Management, the technology that allows Oracle to manage disk volumes for easy DBA management of disk space. You can use the FRA without using OMF and ASM, but they work very well together to provide a complete management solution for all files related to Oracle. For the HADBA, using these three technologies in tandem provides the best of all worlds: availability, manageability, and top-notch performance.

HA Workshop: Configure the Flashback Recovery Area

Workshop Notes

The flashback recovery area is determined by initialization parameters. In this workshop, we are adding a recovery area to a running, operational database.

Step 1.  Determine the size you need for your recovery area. For this example, we are setting up a strategy to account for 24 hours of archivelogs and two full copies of the entire set of datafiles.

SQL> select sum(bytes) from v$datafile; SUM(BYTES) ----------  891289600

Then get the total size of archivelogs over the last 24 hours.

SQL> select sum(blocks*block_size) bytes from v$archived_log   2  where completion_time > sysdate-1;      BYTES ----------   81971200 

You can also gather the total size of the archivelogs based on the number of archivelogs that are currently listed as available on disk. To confirm the status of archivelogs, you would need to run 'crosscheck archivelog all' from the RMAN command prompt first.

SQL> select sum(blocks*block_size) bytes from v$archived_log   2  where status = 'A';      BYTES ----------   81971200

We then multiply our database size by 2, and then take the sum of the datafile and archivelog values, and multiple by 1.2 to get a 20 percent increase from this size to cover file header blocks and other files that may exist in this space:

((891289600 * 2) + 81971200) * 1.2 =  2237460480

Based on this calculation, we can now set our db_recovery_file_dest_size value in the spfile.

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2237460480 SCOPE=BOTH SID='*';

Step 2.  Determine the location for your recovery area. For this example, we are using a simple directory name on an existing mounted volume, u02. We reviewed the volume at the OS level to ensure that enough space existed for our recovery area size, determined above:

df -k

Then it is merely a matter of setting the value of our init parameter.

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u02/fra/' SCOPE=BOTH SID='*';

Final Notes on the Flashback Recovery Area

A few closing remarks on the FRA before we move on with our RMAN configuration:

• Using ASM  If you use ASM for your FRA, you should be mindful of any mirroring that you have established for the disk group in question. For instance, if you have set up a two-way mirror for the disk group, your FRA size value must only be half the size of the total disk group size.

• Using OMF  If you use OMF, it is worth noting that it's not really a good idea to set your db_recovery_file_dest to the same location as the db_file_create_dest or db_file_create_online_log_dest_n parameters. This is for performance as well as data protection purposes. Oracle will actually throw a warning if you set these to the same value.

• Sharing the FRA Across Multiple Databases  The same flashback recovery area can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes. Here's the catch: either all the databases that share the FRA have a different value for db_name, or a different name for the value db_unique_name.

Permanent Configuration Parameters

So we have set up the location for our backups. Next we have to configure the parameters of the backup itself. In the old days of RMAN-in version 8.1.7 or lower-every single backup job you ran from RMAN had to be configured at the time of job execution. So if you wanted to parallelize the backup across four channels, and you wanted to set a backup piece size, and you wanted to go to a tape device residing on your media management server, the job would look something like this:

run { allocate channel sbt1 type 'sbt_tape' parms = "env=(nb_ora_server=linx02)" maxpiecesize = 8G; allocate channel sbt2 type 'sbt_tape' parms = "env=(nb_ora_server=linx02)" maxpiecesize = 8G; allocate channel sbt3 type 'sbt_tape' parms = "env=(nb_ora_server=linx02)" maxpiecesize = 8G; allocate channel sbt4 type 'sbt_tape' parms = "env=(nb_ora_server=linx02)" maxpiecesize = 8G; backup database format = 'FULL_DB_%U' filesperset = 4; } 

Rest assured, if you come from 8i and you have a pile of RMAN scripts you still want to use, this script will still run successfully in Oracle Database 10g. However, starting with 9i, Oracle acknowledged that certain parameters of a backup are the same across every backup job, and should be stored permanently for use each time. The ability to set values for RMAN execution that can be used by all subsequent jobs is referred to as permanent configuration parameters. Permanent configuration parameters are set at the RMAN command prompt using the configure command. To list the current configuration parameters, you can type show all at the RMAN prompt:

RMAN> show all; using target database controlfile instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT     FOR DEVICE TYPE DISK TO '%F'; #default CONFIGURE DEVICE TYPE DISK PARALLELISM 1     BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES     FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES     FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\ORACLE\ORA10\DATABASE\SNCFBETA10.ORA'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

With permanent configuration parameters, you can set up job control information that will exist for all backups of the database. Thus, for the backup job mentioned above, you could instead configure it like this:

configure default device type to 'sbt_tape'; configure channel device type 'sbt_tape'    parms = "env=(nb_ora_server=linx02)"; configure channel device type 'sbt_tape' maxpiecesize = 8G; configure device type 'sbt_tape' parallelism 4;

Having done so, the script for running the backup each subsequent time would simply be

backup database format = 'FULL_DB_%U';

Note 

Why didn't we configure the format as a permanent configuration? The format we are using implies a full database backup, and there may come a time when we want to use our permanent config parameters to take an incremental backup to tape.

HA Workshop: Setting Permanent Configuration Parameters for High-Availability Backup Strategy

Workshop Notes

This workshop will set up the parameters for a backup strategy that maximizes the functionality of RMAN to assist in your HA environment. The actual backup commands, as well as restore/recover commands, can be found in HA Workshops later in the chapter.

Step 1.  Establish the default device as disk, and configure the disk channels.

Configure default device type to disk; Configure device type disk parallelism 2 backup type to copy; Configure retention policy to recovery window of 7 days; Configure backup optimization on; configure controlfile autobackup on;

Step 2.  Establish tape channels so that the recovery area files can be aged out to the tape device.

configure channel device type 'sbt_tape'      parms = "env=(nb_ora_server=lnx01, nb_ora_class=oracle)"; configure device type sbt parallelism 2;

Note 

Your PARMS clause will depend on your media management product. Refer to the documentation from your media manager to know what RMAN must pass to the tape device in order to successfully push the backup stream to tape.

Caring for Your Controlfile

The permanent configuration parameters can be applied to every backup of the target database because they are stored in the target database controlfile. You can always view the parameters by looking at V$RMAN_CONFIGURATION (note that this view is not populated with default configuration parameters).

RMAN adds an increased amount of reliance on the presence of a controlfile for its continual operation: the cfile is the lookup table for what to back up and restore-it is the lookup table for determining where the RMAN backups reside and when they were taken, and it is now the home of our backup job controls. As such, we must be just a little nervous about the health of the controlfile. Here's why.

The most important thing is to have an accessible backup of the controlfile that includes data from your most recent backup. In other words, the controlfile needs to be backed up after the successful completion of your database and archivelog backup. By default, RMAN backs up the controlfile whenever it notes that the system datafile is being backed up. The problem with this controlfile backup is that it is initiated at the same time as the datafile backup, so by its very nature it does not contain information about the backup in which it is contained.

One way to accomplish competent cfile backups is to set the permanent configuration parameter Controlfile Autobackup to On (see 'HA Workshop: Setting Permanent Configuration Parameters for High-Availability Backup Strategy'). When enabled, this parameter will automatically take a controlfile backup to the flashback recovery area or a specified location (on disk or tape) after every backup operation.

This backup comes at a very small cost-the controlfile is typically only a few megabytes in size. The controlfile autobackup has a few features that are extremely desirable to us in an HA environment. First, this autobackup cfile will always contain the RMAN backup metadata that is most recent. Second, the autobackup cfile will be written in a format that is immediately recognizable by RMAN-RMAN will be able to find the autobackup controlfile, even when all it knows about the database it is trying to restore is the DBID.

What is the snapshot controlfile?

You may have noticed when reviewing the RMAN configuration parameters that there is the option to rename the snapshot controlfile. The snapshot controlfile is a copy of the controlfile that RMAN utilizes during long-running operations (such as backup). RMAN needs a read-consistent view of the controlfile for the backup operation, but by its nature the controlfile is extremely volatile. Instead of putting a lock on the controlfile and causing all kinds of database enqueue problems, RMAN makes a copy of the cfile called the snapshot controlfile, and uses it instead of the actual controlfile. The snapshot is refreshed at the beginning of every backup. You can relocate the snapshot if it makes sense in your environment (such as making it accessible to all nodes in a RAC cluster), but for the most part it does no harm to leave it in the $ORACLE_HOME/dbs directory.

When turned on, the default location for the controlfile autobackup is the flashback recovery area. In the absence of an FRA, the location for disk backups is $ORACLE_HOME/dbs directory. If you configure the default device type to tape, then this backup goes to tape. If you back up to disk, lack an FRA, and want to set the controlfile autobackup to a smarter location than the dbs directory, it is done this way:

configure controlfile autobackup format = '/u02/backup/cf_%F';

The only requirement is that the format contain the %F format so that the backup is recognizable to RMAN during a restore operation.

---