7
RMAN Concepts III: Maintenance

This chapter describes the basic concepts involved in using the Recovery Manager (RMAN) utility.

This chapter contains these topics:

• RMAN Reporting Functionality
• Crosschecks of RMAN Backups and Copies
• Deletion of RMAN Backups and Copies
• Allocation of Multiple Channels for RMAN Maintenance Commands
• Changes to Availability of RMAN Backups and Copies
• Changes to Retention Status of RMAN Backups and Copies

  See Also: Chapter 18, "Performing Maintenance with Recovery Manager" to learn how to perform RMAN maintenance jobs

RMAN Reporting Functionality

The RMAN repository, which is either a recovery catalog or the target database control file, contains a wealth of metadata about backups and copies as well as other useful things such as database schema and configuration settings. You can use RMAN commands LIST, REPORT, and SHOW to access this repository information.

This section contains these topics:

• LIST Command Output
• REPORT Command Output
• SHOW Command Output
• PRINT SCRIPT Command Output

LIST Command Output

The LIST command queries the RMAN repository (recovery catalog or control file) and produces a record of its contents. Use this command to obtain data about:

• RMAN-generated files, that is, backup sets, proxy copies, and image copies
• Specified objects contained in the RMAN-generated files, that is, archived logs, datafiles, and control files
• Incarnations of a specified database or of all databases known to the recovery catalog

RMAN records the output to either standard output or the message log, but not to both at the same time. You can also control how the output is organized as well as the level of detail in the output. Running the LIST command is usually preferable to querying V$ or recovery catalog views.

The LIST command displays the same files that the CROSSCHECK and DELETE commands operate on. Consequently, you can issue LIST to see what is in the repository, and then run CROSSCHECK to ensure that these files exist on disk or tape.

REPORT Command Output

This section contains these topics:

• About RMAN Reports
• Reports of Obsolete Backups
• Reports of Orphaned Backups

About RMAN Reports

RMAN reports are intended to provide analysis of your backup and recovery situation. An RMAN report can answer questions such as:

• Which datafiles need a backup?
• Which backups and copies are obsolete because they are redundant or because they are not needed for recovery within a recovery window?
• Which datafiles are not recoverable because of unrecoverable operations performed on them?
• What is the current physical schema of the database or what was it at some previous time?
• Which backups are orphaned, that is, unusable in a restore operation, because they belong to incarnations of the database that are not direct predecessors of the current incarnation?

Run the REPORT NEED BACKUP and REPORT UNRECOVERABLE commands regularly to ensure that the necessary backups are available to perform media recovery, as well as to ensure that you can perform media recovery within a reasonable amount of time. Also, run REPORT OBSOLETE regularly so that you can delete unnecessary files and conserve disk space.

Reports of Obsolete Backups

The REPORT OBSOLETE command displays backups and copies of datafiles, control files, and archived redo logs that can be deleted because they are no longer needed. You can define what makes a file obsolete in the following mutually exclusive ways:

Parameter	Meaning
REDUNDANCY integer	At least integer more recent backups or image copies of this file already exist.
RECOVERY WINDOW integer	The backup or copy is not needed for recovery to a random point within the recovery window of integer days. For each datafile, one backup that is older than the recovery window must exist. In other words, one backup of each datafile must satisfy the condition SYSDATE - CHECKPOINT_TIME >= RECOVERY WINDOW. All backups older than the most recent backup that satisfies this condition are obsolete.

In addition to obsolete datafile backups, RMAN reports obsolete archived logs and archived log backups. Regardless of which parameter is specified, RMAN uses this setting to determine which backups and copies of datafiles are no longer needed, which in turn determines when archived logs (and backups of archived logs) are no longer needed. The creation of a datafile is considered as a backup when deciding which logs to keep.

You can specify the REDUNDANCY and RECOVERY WINDOW parameter options in the following places:

• The REPORT OBSOLETE command with the REDUNDANCY or RECOVERY WINDOW clauses
• The CONFIGURE RETENTION POLICY command with the REDUNDANCY or RECOVERY WINDOW clauses

When generating a report, the REPORT OBSOLETE options override the CONFIGURE RETENTION POLICY options. For example, if you configure a retention policy to a recovery window of 7 days, and then run REPORT OBSOLETE REDUNDANCY 2, the REPORT OBSOLETE command displays backups and copies that are obsolete because they have REDUNDANCY 2. Note that the configured retention policy is still in effect: the REPORT command simply displays what is obsolete given the options that specified in the command. If you run REPORT OBSOLETE and specify neither the REDUNDANCY nor RECOVERY WINDOW options, then RMAN displays what is obsolete given the configured retention policy.

If you disable the retention policy, that is, if you run CONFIGURE RETENTION POLICY TO NONE, then RMAN does not consider any backups or copies as obsolete. If you then run REPORT OBSOLETE with no other options, then RMAN issues an error message because no retention policy is configured to mark files as obsolete.

Reports of Orphaned Backups

The REPORT OBSOLETE ORPHAN command displays orphaned backups. Orphaned backups are backups that are unusable because they belong to incarnations of the database that are not direct ancestors of the current incarnation.

A new incarnation of a database occurs whenever you open a database with the RESETLOGS option, which resets the current redo log to log sequence 1. The RESETLOGS option causes Oracle to write a new RESETLOGS SCN into the control file and datafile headers. To prevent possible redo corruption, archived redo logs from a database with one RESETLOGS SCN cannot be applied to a database with a different RESETLOGS SCN. Although the database is the same, that is, it has the same DBID, the database can go through different incarnations depending on how often a RESETLOGS operation is performed.

RMAN can reset a database to a previous incarnation. For example, if you perform a RESETLOGS operation on database prod1 on Tuesday, you can use RMAN to reset the current database incarnation to Monday's incarnation and restore backups and archived redo logs associated with it. For this reason, backups from previous incarnations are in some cases still usable.

The situation can become complicated when a database goes through multiple incarnations. In such cases, some backups can become unusable, that is, orphaned. You should delete orphaned backups to conserve disk or tape space. The incarnation scenario depicted in Figure 7-1 shows a database that goes through three incarnations.

Figure 7-1 Orphaned Backups

Text description of the illustration sbr81087.gif

Incarnation A of the database started at SCN 1. At SCN 10, assume that you performed a RESETLOGS operation and created incarnation B. At SCN 20, you performed another RESETLOGS operation on incarnation B and created a new incarnation C.

The following table explains which backups are orphans depending on which incarnation is current.

Current Incarnation	Usable Backups (Nonorphaned)	Orphaned Backups
Incarnation A	All backups from incarnation A	All backups from incarnations B and C
Incarnation B	All backups from incarnation A prior to SCN 10 All backups from incarnation B	Backups from incarnation A after SCN 10. All backups from incarnation C
Incarnation C	All backups from incarnation A prior to SCN 10 All backups from incarnation B prior to SCN 20 All backups from incarnation C	All backups from incarnation A after SCN 10 All backups from incarnation B after SCN 20

SHOW Command Output

The SHOW command can display any configuration set by the CONFIGURE command. For example, to display the CONFIGURE CHANNEL settings, run SHOW CHANNEL. You can also run SHOW ALL to display all current configurations.

PRINT SCRIPT Command Output

The PRINT SCRIPT command displays the text of a specified RMAN script stored in the recovery catalog. Note that this command does not display the list of all the scripts stored in the catalog. To see the list of all catalog scripts, query the recovery catalog view RC_STORED_SCRIPT_LINE.

Crosschecks of RMAN Backups and Copies

Sometimes backups and copies disappear from disk, or tapes in the media management library become unavailable. For example, someone may inadvertently delete backup pieces from disk, or one of the tapes used by the media manager may become corrupted.

To ensure that data about backup sets and image copies in the recovery catalog or control file is synchronized with actual files on disk or in the media management catalog, perform a crosscheck. The CROSSCHECK command operates only on files that are recorded in the RMAN repository.

Figure 7-2 illustrates a crosscheck of the media manager. RMAN queries the repository (recovery catalog or target database control file) for the names and locations of the four backup sets to be checked. RMAN sends this information to the target database server, which queries the media management software about the backups. The media management software then checks its media catalog and reports back to the server that backup set 3 is missing. RMAN updates the status of backup set 3 to EXPIRED in the repository. The record for backup set 3 will now be deleted if you run DELETE EXPIRED.

Figure 7-2 Crosschecks

Text description of the illustration sbr81084.gif

Crosschecks are useful because they can

• Update outdated information about backups and copies that disappeared from disk or tape or became corrupted
• Update the repository if you delete archived redo logs or other files using operating system commands

Use the crosscheck feature to check the status of a backup or copy on disk or tape. If the backup or copy is on disk, then CROSSCHECK checks whether the header of the file is valid. If a backup is on tape, then the command checks that the backups exist.

Backup sets, backup pieces, and copies can have the status AVAILABLE, EXPIRED, or UNAVAILABLE. You can view the status information in the output of the LIST command and the recovery catalog views.

Note that you can issue the DELETE EXPIRED command to delete all expired backups and copies. RMAN removes the record for the expired file from the repository. If for some reason the file still exists on the media, then RMAN issues warnings and lists the mismatched objects that cannot be deleted.

Deletion of RMAN Backups and Copies

This section contains these topics:

• About RMAN Deletions
• Summary of RMAN Deletion Methods
• Removal of Backups and Copies with the DELETE Command
• Behavior of DELETE Command When the Repository and Media Do Not Correspond
• Removal of Backups and Copies with the BACKUP ... DELETE INPUT Command

About RMAN Deletions

Every RMAN backup or copy produces a corresponding record in the control file and, if used, recovery catalog. For example, if you generate a full database backup set, then you can view the record for this backup set in the V$BACKUP_SET control file view. If you use a recovery catalog, then you can also see the record in the RC_BACKUP_SET catalog view.

The V$ control file views and catalog tables differ in the way that they store information, and this affects how RMAN handles repository records. The RMAN information stored in the control file is not stored in an actual table, although the V$ views display it in tabular format. The data is stored in an internal data structure in the circular reuse section of the control file. In contrast, the recovery catalog data is stored in actual database tables.

When you use an RMAN command to delete a backup or copy, RMAN performs the following steps:

• Removes the physical file from the operating system
• Updates the backup or copy records in the control file to status DELETED
• Removes the backup or copy records from the catalog tables (if a catalog is used)

Because of the way that control file data is stored, RMAN cannot delete the record from the control file, only update it to DELETED status. However, because the catalog tables are ordinary database tables, RMAN removes rows from them.

Summary of RMAN Deletion Methods

Table 7-1 describes the functionality of the various RMAN deletion commands and scripts. None of these commands or scripts requires a recovery catalog.

Table 7-1 Maintenance Commands and Scripts (Page 1 of 2)

Command or Script	Purpose
DELETE	To delete physical backups and image copies, update the control file records to status DELETED, and remove their records from the catalog (if a catalog is used). You can specify that DELETE should remove backups or copies that are EXPIRED or OBSOLETE. If you run DELETE EXPIRED on an object that exists, RMAN issues a warning and does not delete the object. You can override this behavior and delete the object by running DELETE FORCE.
BACKUP ... DELETE [ALL] INPUT	To back up archived logs, datafile copies, or backup sets, then delete the input files from the operating system after the successful completion of the backup. RMAN also deletes and updates repository records for the deleted input files. If you specify DELETE INPUT (without ALL), then RMAN deletes only the copy that it backs up. If you specify ALL, then RMAN deletes all copies of the specified logs that it finds in the V$ARCHIVED_LOG view.
CHANGE ... UNCATALOG	To delete recovery catalog records for specified backups and copies and change their control file records to status DELETED. Note that the CHANGE ... UNCATALOG command does not delete files from the operating system.
prgrmanc.sql	To remove all records of backups or copies with status DELETED from the recovery catalog. Prior to release 8.1.6, RMAN sometimes updated recovery catalog records to DELETED status rather than removing them entirely (as it does in the current release). Note: If the version of your recovery catalog is the same version as the current release of RMAN, then the only way that the recovery catalog could have records marked DELETED is if the catalog has been upgraded from a catalog prior to release 8.1.6, or the catalog was resynchronized from a backup control file created prior to release 8.1.6.

Removal of Backups and Copies with the DELETE Command

The DELETE command can remove any file that the LIST and CROSSCHECK commands can operate on. For example, you can delete backup sets, archived redo logs, and datafile copies. The DELETE command removes both the physical file and the catalog record for the file.

Advantage of Using DELETE Instead of Operating System Commands

Always use DELETE rather than an operating system utility to remove RMAN backups and copies. If you do not, then the RMAN repository is not synchronized with what exists on the file system or on tape. If you remove files using an operating system utility, you can

• Run CROSSCHECK to change the status of these files to EXPIRED and then run DELETE EXPIRED
• Run DELETE on the files that you deleted with the operating system utility
• Run CHANGE ... UNCATALOG to remove the catalog records

Deletion of Obsolete Backups and Copies

The DELETE OBSOLETE command provides a convenient way to physically delete backups and copies that are no longer needed, as well as remove their catalog records. It uses the same REDUNDANCY, RECOVERY WINDOW, and ORPHAN options as the REPORT OBSOLETE command.

If you have configured a retention policy, then you can run DELETE OBSOLETE periodically to delete all backups and copies considered obsolete by this policy. For example, you can run DELETE OBSOLETE as a script every night using a scheduling utility. In this way, you keep your disk drives uncluttered by removing all unnecessary files.

Deletion of Expired Backups

The CROSSCHECK command marks a backup or copy as expired when it cannot locate it at the location to which it was backed up. In short, expired means "not found." You can view the expired backups and copies by running the CROSSCHECK command as in the following example:

RMAN> CROSSCHECK BACKUP;

crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=0ad8d32i_1_1 recid=10 stamp=445025363
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-1334876723-20011105-00 recid=11 stamp=445025367
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=0cd8d361_1_1 recid=12 stamp=445025473
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-1334876723-20011105-01 recid=13 stamp=445025475
Crosschecked 4 objects

The DELETE EXPIRED command removes the recovery catalog records for expired backups and copies, and updates their control file records to status DELETED.

This command is especially useful if you inadvertently delete RMAN backups or archived logs from disk using an operating system utility. If you do this, then the RMAN repository is not synchronized with the physical reality of what is on disk. By running the CROSSCHECK command, RMAN marks the backups and copies that it cannot find as expired. Then, you can run DELETE EXPIRED to remove the records for these files.

Deletion of Archived Redo Logs That Are Already Backed Up

You may want to delete files such as archived logs only if they have been backed up a specified number of times to tape. The DELETE command supports this behavior. The following example deletes all backups and copies (archived logs are considered as copies) that have already been backed up at least two times to tape:

DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;

Behavior of DELETE Command When the Repository and Media Do Not Correspond

The repository record for an object can sometimes fail to reflect the physical status of the object. For example, you back up a log to disk and then use an operating system utility to delete the object. If you do not run the CROSSCHECK command to update the repository, and if you then run DELETE against the object, then the repository shows that the object is AVAILABLE while the object is in fact missing. The following table indicates the behavior of DELETE in such situations.

Repository Status	Physical Status	Behavior of DELETE Command
AVAILABLE	Not found on media	Does not delete the object and reports the list of mismatched objects at the end of the job. RMAN does not update the repository status.
EXPIRED	Found on media	Does not delete the object and reports the list of mismatched objects at the end of the job. RMAN does not update the repository status.
UNAVAILABLE	Any	Removes repository record and deletes object if it exists. All I/O errors are ignored.
FORCE	Any	Removes repository record and deletes file if it exists. All I/O errors are ignored. RMAN displays the number of objects deleted at the end of the job.

Removal of Backups and Copies with the BACKUP ... DELETE INPUT Command

The BACKUP ... DELETE INPUT command can delete archived redo logs, datafile copies, and backup sets after backing them up. This functionality is especially useful when backing up archived logs on disk to tape. RMAN backs up one and only one copy of each log sequence number, and then deletes the file that it backs up. For example, assume that you issue:

BACKUP ARCHIVELOG ALL DELETE INPUT;

In this command, RMAN backs up one copy of each log for each available sequence number, and then deletes only the file that it actually backs up.

If you specify the DELETE ALL INPUT option, then RMAN deletes whichever files match the criteria that you specify, even if there are several files of the same log sequence number. For example, assume that you archive to 3 different directories. Then, you issue this command:

BACKUP ARCHIVELOG ALL FROM SEQUENCE 1200 DELETE ALL INPUT;

In this case, RMAN backs up only one copy of each log sequence between 1200 and the most recent sequence, but deletes all logs with these sequence numbers contained in the three archive destinations.

The archived log failover feature means that RMAN searches every enabled archiving destination for good copies of a log sequence number. For example, assume that /log1 and /log2 are the only enabled archiving destinations, and that they contain the same sequence number. You run this command:

BACKUP ARCHIVELOG FROM SEQUENCE 123 DELETE ALL INPUT;

RMAN can start reading from any enabled archiving directory. For example, assume RMAN starts in directory /log1 and finds log_123.f there. Then, if RMAN discovers that log_124.f is corrupt, it searches in /log2 for a good copy of this log. Because DELETE ALL INPUT is specified, RMAN deletes all copies of logs on disk of sequence 123 and higher.

Allocation of Multiple Channels for RMAN Maintenance Commands

You can use maintenance commands such as CROSSCHECK or DELETE on all configured device types. If you have automatic channels configured for all devices on which you have made backups, then you can simply run CROSSCHECK or DELETE at the RMAN prompt as in the following example (sample output included):

CROSSCHECK BACKUP;

allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/ade/lashdown_seeddb/oracle/dbs/c-1337987235-20011210-01 recid=6 
stamp=448109988
Crosschecked 1 objects

crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=01dbb78r_1_1 recid=1 stamp=448109852
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=02dbb791_1_1 recid=2 stamp=448109857
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=03dbb7af_1_1 recid=3 stamp=448109904
Crosschecked 3 objects

RMAN uses the default configured DISK channel as well as a channel for the configured sbt device. RMAN looks for each backup on all channels that have the same device type as the channel used to create the backup. The multiple-channel crosscheck feature is designed for the following scenarios:

• To allow crosschecking or deleting of all backup pieces or proxy copies, both on disk and tape, with a single command
• To make crosschecking and deleting work correctly in an Oracle Real Application Clusters configuration in which each backup piece or proxy copy exists only on one node

To perform maintenance on files on only one device type, you can specify the device type on the maintenance command itself. For example:

DELETE EXPIRED BACKUP DEVICE TYPE sbt;

If you do not have an automatic channel configured, then you can manually allocate a maintenance channel. For example, you can run commands as follows:

ALLOCATE CHANNEL FOR MAINTENANCE TYPE sbt;
CROSSCHECK BACKUP;

Changes to Availability of RMAN Backups and Copies

RMAN can update the repository to show backups and copies as available or unavailable. For example, you may have several backups on a tape drive that is being upgraded or replaced. You can use the CHANGE ... UNAVAILABLE command to mark these backups and copies as unavailable for the duration of the maintenance on the drive. RMAN does not consider UNAVAILABLE backups and copies for its backup and recovery operations.

When the maintenance is complete, you can issue the CHANGE ... AVAILABLE command to inform RMAN that these backups and copies are now available again. After setting the files back to status AVAILABLE, you can also run a CROSSCHECK to double-check that RMAN can access the files.

Changes to Retention Status of RMAN Backups and Copies

RMAN can change the status of backups and copies by using the KEEP or NOKEEP options. The KEEP option exempts a backup or copy from the current retention policy either indefinitely or until the specified UNTIL time. RMAN does not mark the files as obsolete even if they would be considered obsolete under the retention policy. Such backups are called long-term backups. The NOKEEP option removes the exempt status of the files.

The CHANGE ... KEEP or CHANGE ... NOKEEP commands alter the retention status of a backup or copy. For example, this command allows the retention policy to mark backup sets with the tag SAVE_BACKUP as obsolete:

CHANGE BACKUPSET TAG save_backup NOKEEP;