RMAN Management Enhancements - Oracle 11g

Oracle Database 11g implements several general enhancements in the RMAN management area.These improvements include new RMAN persistent configuration parameters, the introduction of substitution variables in RMAN scripting, multi section backups wherein RMAN backs up a large datafile in sections,improved archived redo log management, archived redo log failover, the new back up shred ding feature, and the optimized backup of undo data.There is also a new archi val backup feature and a new validate command in this release.We’ll cover these new backup and recovery management–related features in detail in the following sections.

Scripting with RMAN Substitution Variables

You can now use substitution variables in RMAN command files, which you can then incorporate in shell scripts.Using substitution variables lets you create dynamic command files that you can use for multiple backup jobs. All you have to do is pass different values for the substitution variables for different RMAN jobs.

Include the new clause using to specify the substitution variables you’re using in the RMAN command file.Use the familiar integer syntax (&1, &2,and so on) to indicate the substitution variables to which you’d like to assign values. Here’s a simple example that shows how to create a dynamic backup shell script:

• Create an RMAN script named backup.cmd that uses two substitution variables:
• The script shown here will back up the database using two substitution variables (&1 and &2),one for the backup tag and the other for the string value in the formatspecification.
• Create the shell script to run the backup script you created in step 1:
• Note that you have to specify the using clause when employing a dynamic command file.The using clause will specify which substitution variables will be used.In this example,the two substitution variables are tag and format.
• Specify the arguments for the tag and format variables when you invoke the backup
• shell script, as shown in the following example:
$yearly_backup.sh longterm_backup back0420 The example shows how to execute the shell script yearly_backup with two dynamic parameters,longterm_backup (tag) andback0420 (format string). The previous example showed you how to create a dynamic command file.You can also employ substitution variables in a create script command to create a dynamic stored script.To do this, simply specify the substitution variables for all values that you want to be dynamically updated.Before you can create a dynamic stored script,you must specify the using clause when you start RMAN at the command line and also pass the initial values for the substitution vari ables you want to use in the stored script. Once you invoke RMAN in this fash ion, you must create the dynamic stored script. Here’s how to create a dynamic stored script that uses substitution variables: • Create a command file with the create script statement using substitution variables for those values that you want to pass dynamically at script execution time. Here’s the command file with the create script statement: • The create script statement includes three substitution variables, &1, &2,and &3,which stand for tag, part of the format string, and restore point, respectively. We’ll name this command file testcmd1 and use it to create the stored script. • Connect RMAN to both the target database and the recovery catalog (since we’re using the keep forever clause). Also,specify the initial values for all three of the substitution variables: • Once you log in to RMAN after specifying the initial values for the substitution variables, you must create the stored script using our command file (testcmd1) from step 1.Create the stored script by running the command file you created earlier: • Notice how RMAN replaced the three substitution variables with the actual values you supplied at the command line when you invoked RMAN in step 2. • In future executions of the stored script, you can specify values for the three substitution valuables as part of a run block, as shown here: • You can see that the introduction of substitution variables make creating dynamic RMAN stored scripts quite easy, just as in the case of creating dynamic RMAN command files. New RMAN Configuration Parameters There are a couple of important new persistent configuration parameters for RMAN.Issue the show all command at the RMAN prompt to see all the configu ration parameters in Oracle Database 11g.The compression algorithm and the archivelog deletion policy parameters are new in the Oracle Database 11g release: You can now choose the compression algorithm RMAN uses for compressing a backup.You have a choice of two different compression algorithms. Query the V$RMAN_ COMPRESSION_ALGORITHM view to find out what compression algorithms you can choose from, as shown in the following example:

The default compression algorithm, BZIP2,provides a better compression ratio but performs the compression more slowly than the ZLIB algorithm.The alternate compression algorithm, ZLIB,is faster but doesn’t offer the best compression ratio.Use the following command to switch to the ZLIB compression algorithm from the default BZIP2 algorithm:

This command will switch the RMAN compression algorithm from the default compression algorithm BZIP2 to the alternatecompression algorithm ZLIB. You must set the initialization parameter compatibility to at least 11.0.0 to use the ZLIB compression algorithm.

The other important new configuration parameter is thespecification of an archived redo log deletion policy.Bydefault,there is no archived redo log policy, as shown by the output of the show all command for the archivelog deletion policy parameter(CONFIGURE ARCHIVELOG DELETION POLICY TO NONE).We discuss the configuration of an archived redo log deletion policy later in this chapter.

Backing Up Large Files in Sections

In Oracle Database 10g,the unit of an RMAN backup and restore was the file level.That is,you had to back up or restore an entire datafile but couldn’t break up the backup/recovery into a sub file chunk.Since you can now have an Oracle file theoretically as large as 2 terabytes,there comes a point when it becomes impractical to back up and restore at the file level.Oracle Database 11g offers a way out of this predicament by letting you back up and restore a large file in sections.

The backups you perform at the section level are known as multisection backups.Each backup piece of a backup set that belongs to a multisection backup will contain blocks from a single file section, which is a contiguous set of blocks in a file.

In a multisection backup,each RMAN channel backs up a different section of a datafile.Thus,you can enhance backup performance by specifying a multi section backup and use multiple channels to back up a large datafile. Multi section backups thus offer tremendous performance benefits,since you can back up a single datafile in parallel in multiple sections.You also don’t have to back up a large file all over again if the backup fails midway—you need to back up only those sections that weren’t backed up prior to the backup failure.

You can have up to 256 sections per datafile.RMAN makes uniform-sized sections,except the very last one,which may or may not be the same size as all the other sections.You can specify different section size values for different files,within the same backup job.

Performing Multisection Backups

Use the new backup command clause section size to perform multisection backups.Each backup piece then will be limited to the value you set for the section sizeparameter.If you don’t specify a value for the sections with the section size parameter,RMAN computes an internal default section size for that backup job.Each section of the backup corresponds to a separate backup piece in a backup set.

The following is an example showing how using the section size parameter breaks up the backup of a datafile into multiple sections of the same size. Here are the steps you must follow in order to make a multisection backup:

• Connect to the target database:
• $rman target sys/<sys_password>@target_db • Configure channel parallelism.In this example,we use a parallel setting of 3 for the SBT device,so we configure three SBT channels,as shown here: • Execute the backup command, specifying the section size parameter: Let’s say that our tablespace example has one datafile,sized 1500m.The section size parameter breaks up the datafile backup into three chunks of 500m apiece.Each of the three channels you specified backs up a contiguous set of blocks,known as a section,with each section going to a different backup piece. You must set the initialization parameter compatibility to at least 11.0 when performing multisection backups,since it’s not possible to restore multi section backups with a release earlier than 11.0. You can also use the section size clause with the validate data file command.We’ll show an example of this later in this chapter, when we discuss the new version of the validate command. Managing Multisection Backups The SECTION_SIZE column in both the V$BACKUP_DATAFILEandRC_BACKUP_DATAFILE views shows the number of blocks in each section of a multisection backup.Of course, a whole file backup will show a value of zero in this column.If you haven’t performed any multisection backups, the SECTION_SIZE column will have a zero value.

The V$BACKUP_SET and RC_BACKUP_SET views tell you which backups are multisection backups.The following example shows a query on the V$BACKUP_DATAFILE view:

The query shows that backup pieces 2 and 7 are multisection backups since they each have a value of YES for the column MULTI_SECTION.

Creating Archival (Long-Term) Backups

You can use the backup...keep command in Oracle Database 11g to retain backups for longer periods than specified by your retention policy for RMAN backups.Using this command,you can make archival backups that you can retain for years,if you want,for purposes such as meeting regul atory requirements. You can also use archival backups for periodically restoring a database for testing purposes.These archival backups contain all the files necessary to restore and recover a database.

In Oracle Database 10g,you used the keep option to override any configured retention policy for a backup.The keep option made the backup exempt from a retention policy for a specified period of time.

The keep forever option (requires a recovery catalog)specified that a backup or copy never expired.In Oracle Database 11g,you use the keep and keep forever options to essentially do the same thing as before.However,some of the options from the previous release aren’t used now,and there is a new option called restore point.Since the backup...keep command is at the heart of the archival backups feature, we’ll cover this command in moredetail in the following sections.

The backup … keep Command in Oracle Database 10g

Before Oracle Database 11g, the backup...keep command had the following options:

• keep to mark as exempt and unkeep to mark the undoing of a backup’s exemption from the configured backup retention policy
• logs to specify that RMAN must retain the archived redo logs necessary for a recovery as long as the relevant backup is available,and the nologs option to specify that the archived redo logs to recover the backup not be kept.
• forever and until time to specify the length of time for which to exempt a backup from the configured backup retention policy

Changes in the backup … keep Command

In the new version of the backup...keep command, the keep, nokeep,forever, and until time options are retained.However,the logs and nologs options aren’t there any longer.Instead, you have a new option, restore point.

The restore point option lets RMAN automatically create a restore point corresponding to the SCN that RMAN must recover the target database backup to in order to make the database consistent.In other words,the restore point clause specifies the time to which RMAN can recover the archival backup.You must,of course,specify a restore point name when you use the restore point clause, as you’ll see in the section “Creating an Archival Backup” later in this chapter.

Archival Backups

The primary purpose of the backup...keep command in Oracle Database 11g is to specify a backup as a self-contained archival backup exempt from any backup retention policy you might have configured.

In addition to being exempt from the backup retention policy,the archival backup is an all-inclusive backup,in the sense that all the files needed to restore and recover the database are part of the archival backup.Note that this all-inclusive archival backup is backed up to a single disk or tape.The archival backups can be put to historical usage, or they can be used to restore the production databases on another system for testing.Previously,if you retained an online backup for a lengthy period, RMAN automatically retained all the archived redo logs for that period, assuming you might want to perform a point-in-time recovery in the time spanned by that period.Archival backups are somewhat different,since your goal isn’t a point-in-time recovery but rather a need to keep a backup for a specified length of time,along with all the archived redo logs necessary to recover that backup.

Thus, when you specify the keep option (keep forever or keep until), RMAN saves only the backups for the datafiles and just those archived redo logs necessary to recover the online backup and necessary autobackup files.Thus, the archival backup as a whole occupies far less space than saving a regular RMAN backup for a long period.

Creating an Archival Backup

You can create an archival backup in two ways.You can make a backup exempt from a retentionpolicy by using the backup... keep command,as explained earlier.The other way you can make an archival backup is by altering the status of an existing backup using the change command. Let’s create an archival backup using both of these methods.

First,we’ll create an archival backup using the backup...keep command. We’ll create an archival backup that’s retained for one year without being considered obsolete,regardless of the configuration of your back up retention policy.Here’s thecommand:

In this example,we used the keep until time clause, which makes RMAN mark this backup obsolete as soon as the time you specify (sysdate+365) has passed. Of course,if you specify the keep forever clause instead, the backup never becomes obsolete.That is, the backup will never be eligible for deletion by the backup retention policy. Here’s how you specify the keep forever clause in your backup command:

RMAN never deletes the archival backup you create with the previous backup command since the backup never becomes obsolete (you can use the change command to alter the status of this as well as any other backup,as we’ll show later in this chapter).

You can also make a temporary archival backup that you plan on deleting soon after you create it,instead of keeping it for a long period of time.This kind of backup would be ideal when you want to restore a backup to a different host and then delete it soon after that.If, for example,you want the backup to be obsolete after only one day,overriding the configured retention policy,you can do so by specifying the clause keep until sysdate+1, as shown in the following example:

The backup database command shown here creates a temporary archival backup with the tag proddb, which becomes obsolete after just one day.Here’s what happens when you issue the backup ... keep until time (or a backup … keep forever) command:

• The database performs a redo log switch so the redo information in the current online redo log is archived.This is to make the database consistent upon a recovery.
• RMAN makes a backup of all datafiles, archived redo logs, the controlfile,and the server parameter file.
• The archived redo log consists of only the redo logs necessary to recover the database to a consistent state.
• The command supports an optional restore point clause, which you can specify to create a normal restore point.This restore point captures the SCN right after the backup is completed.
• The controlfile autobackup will store the restore point created by RMAN, so it can be used when you restore the controlfile.

When you specify the keep clause in a backup command (keep until time, keep forever),RMAN creates multiple backup sets.For this reason,you must ensure that the format clause can create multiple backup pieces in the various backup sets.The easiest way to do this is to specify the %U parameter, as shown in the example earlier in this section.

The second method of creating an archival backup is to simply use the keep option of the change command to alter the status of a regular backup to that of an archival backup. Here’s a simple example:

The change command converts a routine weekly backup in this case to an archival backup that never becomes obsolete (keep forever).The change command thus changes the exemption status of a backup or copy vis-à-vis the configured retention policy.If you want to make a long-term backup that’s ineligible for deletion into one that’s eligible for deletion (that is, eligible for the obsolete status), you can do so by issuing the change ... nokeep command, as shown here:

RMAN> change copy of database controlfile nokeep;

The nokeep option brings the long-term image copies for both datafiles and controlfiles back under the purview of
theconfigured retention policy, thus guaranteeing that eventually they become eligible for the obsolete status again.

Restoring an Archival Backup

The easiest way to restore an archival backup is by using the duplicate command after creating a temporary instance.Here’s a quick summary of the procedure:

• Prepare the auxiliary instance, which includes the duplicate command’s usual preparatory steps for creating anauxiliary instance,such as creating the password file and the initialization parameter file.You must also esta blish Oracle Net connectivity to the auxiliary instance and start the auxiliary instance.
• Connect to the recovery catalog, the target, and the auxiliary instances, as shown here:
• Issue the list restore point all command to see the available restore points in the database:
• Issue the duplicate database command,making sure you specify the restore point to which you’d like to restore the database,using the archival backup:

The duplicate command shown here creates a new controlfile instead of restoring the controlfile of the target database.The restore point you created earlier with the keep command and the SCN corresponding to it are recorded in both the recovery catalog if you’re using one and the target database control file.Since you need the SCN for duplicating the database until the restore point that you specified (firstquart07), you must either use a recovery catalog or use the target database controlfile, as long as the restore point is still there and hasn’t been overwritten.

The New Validate Command

In Oracle Database 10g, you had access to two backup validation commands. The validate backupset command lets you validate a specific backup set when one or more backup pieces were suspected to be damaged or even missing.

RMAN would check all the backup pieces in the backup set and see whether their checksums were correct to verify that the backup set was OK and good for use in a recovery situation. You can still use this command when you suspect corruption in a backup set.

In addition to the validate backupset command, the previous release of the Oracle databas provided the backup validate command to perform checks on specified files to confirm that they could be backed up correctly.

The backup validate command checks for both physical and logical corruption in the datafiles.In addition,the command also verifies that all database files are indeed where they aresupposed to be.For example,you can issue the backup validate command to check all database files as well as the archived redo logs of a database by issuing the following command:

RMAN> backup validate database archivelog all.

RMAN would go through all the motions of an actual backup,except it doesn& rsquo;t produce any backup sets—it merely reads each data file and archived redo log to confirm that they aren’t corrupted and that they can be backed up success fully.

Any corruptions found would be recorded in theV\$DATABASE_BLOCK_CORRUPTION view.

In Oracle Database 11g, you can use the new validate command to check for corruption at a finer level of granularity than the old backup validate command.You can use this command to validate datafiles,backup sets,and even individual data blocks.Note that the new validate command is semantically equivalent to the backup validate command in the previous release.You use the validate command to check for things such as missing datafiles or corrupt data blocks.You also run thecommand to assure yourself that a backup set is restorable.

If RMAN finds that the validate command has trapped any errors,it auto matically triggers a failure assessment.If anyfailures are found, RMAN will log it into the automatic diagnostic repository.You can use the Data Recovery Advisor command list failure to view all the failures logged in the ADR.

Validating with the validate Command

We’ll present some examples that show how to validate various database objects in order to illustrate the range of the new validate command.Here’s an example showing how to validate a backup set by using the validate command:

You can validate an individual block in a datafile by specifying the datafile and block numbers, as shown in the following example:

RMAN> validate datafile 2 block 24;

The block-level validation shown here is the lowest level of granularity that you can go to with the validate command.On the other extreme, you can use the validate command to check the entire database at once,as shown in the following example:

The validate command begins with the message “Startingvalidate& rdquo;and not “Starting backup,”as is the case when you issue the backup...validate command.The semantics, however,of the new validate command are similar to those of the old backup...validate command, and both commands work in asimilar fashion.

The big advantage to using the new validate command is that it can check at a more granular level than the old backup ... validate command, including at the data block level. You can also apply the new validate command to a much larger number of objects,including such objects as the recovery area.

Speeding Up Validation with the Section Size Clause

If you want to validate a very large datafile fast, use the section size clause with the validate command.The section size clause works similarly to the section size clause during a multisection backup,which we discussed earlier in this chapter. Make sure you first configure multiple backup channels in order to parallelize the datafile validation when you run the validate command.The following example shows how to parallelize the validation of a large datafile by using the section size clause to break up the job into two parallel streams:

The validate command skips all unused blocks in the datafiles it’s vali dating.Set the section size clause’s value higher,and increase the number of backup channels to make the validation job significantly faster.You must con figure multiple channels when specifying the section size clause.Remember that thesection size clause applies only to the validation of data files.

Validate Command Options

Besides the options we illustrated in the previous section, you can also specify the following options with the validate command:

• validate recovery area
• validate recovery files
• validate spfile
• validate tablespace <tablespace_name>
• validate controlfilecopy
• validate backupset <primary_key>

Configuring an Archived Redo Log Deletion Policy

Oracle Database 11g provides several key enhancements in the management of archived redo logs.Oracle Database 11g lets you configure a persistent policy regarding when archived redo logs are eligible for deletion. The archived redo log deletion policy applies to logs stored on disk and applies to all archived redo log destinations, including the flash recovery area.

Deleting Archived Redo Logs

You can delete unwanted archived redo logs either manually or let RMAN delete them automatically.You can use either the delete ... archivelog or backup ... delete input commands to delete archived redo logs yourself.

RMAN automatically deletes only those archived redo logs that are in the flash recovery area.There’s no default RMAN archived redo log deletion policy.RMAN decides whether an archived redo log is eligible for deletion based on criteria such as whether a certain number of backups have been made and whether all archived redo logs have been successfully transferred to the necessary destinations.

To be precise,when you don’t configure an archived redo log deletion policy,RMAN will deem an archived redo log eligible for deletion if that log satisfies both of the following conditions.

• If you have specified the log_archived_dest_n parameter, the archived redo log must have been successfullytransferred to all the remote destinations youspecified.This applies to archived redo logs in the flash recovery area as well as those that are stored in a non-flash-recovery-area location.
• You must have already backed up that archived redo log at least once (either to disk or tape),or the archived redo log must be obsolete.Whether an archived redo log is deemed obsolete depends on the backup retention policy in force. Any archived redo log necessary to support a guaranteed restore point or the flashback database feature isn’tconsidered obsolete by the backup retention policy.

Remember that when you configure an archived redo log deletion policy, the following will be true:

• Both the backup ... delete and delete ... archivelogcommands take the configured policy into account.
• The flash recovery area takes the configured policy into consideration as well.

Configuring an Archived Redo Log Deletion Policy

As mentioned in the previous section, by default there isn’t an archived redo log deletion policy (it is set to none).To configure your own archived redo log deletion policy,use the configure command,with the archived redo log deletion policy clause.the following example showshow to configure a typical archived redo log deletion policy for archived redo logs made to a tape device:

The policy that was configured here specifies that all archived redo logs are eligible for deletion only after they have been backed up two or more times to tape. In this example,wespecified sbt (tape) as the device type. However, you can also specify disk as the device type instead of sbt. RMAN will make sure that the number of archived redo log backups that you require RMAN to keep exist on the particular device type you specify in the command.

Let’s say you configured an archived redo log deletion policy as shown earlier,stipulating that an archived redo log be backed up twice before being eligible for deletion.When you subsequently issue a backup...archivelog command, RMAN will back up an archived redo log only if there are less than two copies of that log and will skip the backup of the log otherwise.Sound familiar? Well,this behavior is similar to what you’d get if you had specified the not backed up 2 times clause in a backup archivelog command.You can,however,override the archived redo log deletion policy you configured by specifying the force clause in the backup archivelog command.

Once you configure an archived redo log deletion policy,it’senabled automatically and comes into force immediately.If you ever want to disable the policy, you can do so by issuing the following command:

RMAN> configure archivelog deletion policy to none;

When you issue the command shown here, the database will revert to the out-of-the-box setting for deletion of the archived redo logs, which was explained earlier.

Archived Redo Log Deletion in a Data Guard Setup

You can configure an archived redo log deletion for any standby destination or just for mandatory standby destinations.You can also specify whether the archived redo logs should be merely transferred or applied to the standby database before being considered for deletion.

The following discussion explains how to use the configurearchivelog deletion policy command, depending upon what your requirements are regarding the two criteria—the number ofdatabases and the status of the archived redo log application.

• Specify the to applied on standby clause if you want RMAN to delete the archived redo logs after the logs have been applied to all the mandatory standby destinations.To be eligible for deletion, the archived redo logs must inaddition also satisfy any backed up...times to device type policy that’s in force.If you want the archived redo logs to be considered for deletion only after they are applied on all remote standby destinations,use the to applied on all standby clause. Here are our two examples of ourcommand for specifying deletion of the archived redo logs after they are applied to remote dest nations:RMAN>configure archivelog deletion policy to applied on standby; RMAN> configure archivelog deletion policy to applied on all standby; The first command is applicable only to required standby destinations,and the second applies to all standbydestinations.
• Specify the to shipped on standby clause if you want RMAN to delete the archived redo logs after the logs have been merely transferred to all the mandatory standbydestinations.To be eligible for deletion, the archived redo logs must in addition also satisfy any backed up...times to device type policy that’s in force.If you want the archived redo logs to be considered for deletion only after they are applied on all remote standby destinations,use the to shipped on all standby clause.Here are our two examples of the command for specifying deletion of the archived redo logs after they are applied to remote destinations: RMAN>configure archivelog deletion policy to shipped onstandby;RMAN> configure archivelog deletion policy toshipped on all standby;

The first command is applicable only to required standbydestinations, and the second applies to all standby destinations.

Archived Redo Log Failover

If RMAN finds that the archived redo log in one or more archived redo log locations is corrupt or is missing during an archived redo log backup,it can now complete the backup successfully by using logs from an alternative location.

This is called the archived redo log failover feature.If, for example, you’re backing up the redo logs to the flash recovery area and RMAN finds that one or more redo logs in the flash recovery area are corrupted, it will search for a good archived redo log from outside the flash recovery area.

This failover to non-flash-recovery areas during a backup is automatic and guarantees that even if a disk hosting the flash recovery area is damaged, the backup of the flash recovery area won’t fail.

We’ll show a simple example to illustrate how the archived redo log failover feature works.Let’s say you have two archived redo log locations, /u01/app/oracle/arch1and /u01/app/oracle/arch2.You issue the following command to back up the archived redo logs:

RMAN> backup archivelog 2> from sequence 90 3> until sequence 100;

Now,assume that log 100 is missing in the /u01/app/oracle/arch1 directory.When you’re archiving redo logs to multiple locations, RMAN selects only one copy of each archived redo log when it’s backing up the archived redo logs. RMAN will back up redo logs 90–99.

/u01/aapp/oracle/arch1 directory and the redo log 100 from the second archived redo log location, /u01/app/oracle/arch2.

Backup Shredding

Oracle Database 11g lets you render encrypted backupsinaccessible by destroying the encryption key of the backup.You don’t need to physically access the backup media to perform this task,also called backup shredding. Backup shredding is disabled by default.Here’s how you configure backup shredding:

RMAN> configure encryption external key storage on;

Alternatively,you can use the set encryption command as shown here to configure backup shredding:

RMAN> set encryption external key storage on;

To actually use the backup shredding feature, you must use the delete force command, as shown here:

Note that you can’t shred RMAN backups protected with a password.

Optimized Backing Up of Undo Data

Up until this release,during a backup, all undo data in the undo tablespace was backed up.The undo data might include both committed as well as un committed data.

The committed data that’s recorded in the undo tablespacedoesn’t serve any useful purpose,since that data is also recorded in the data blocks upon committing the relevant transactions.In Oracle Database 11g,during a backup, the committed data isn’t backed up,thus leading to a saving of storage space as well as faster backups for large OLTP-type databases.

Since the new optimized undo backup is automaticallyenabled,you don’t have to configure any thing special to take advantage of this feature.