Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 1 (10.1)

Part Number B10734-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

4
RMAN Maintenance Concepts

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

This chapter contains these topics:

RMAN Reporting

The RMAN repository contains extensive records of about backups as well as other useful information such as database schema and configuration settings. You can use RMAN commands LIST, REPORT, and SHOW to access this repository information.

In addition to these general reporting commands, you can also make use of the RESTORE... PREVIEW command to see which backup files are required to restore specific database objects from backup. See Oracle Database Backup and Recovery Basics for more details on RESTORE... PREVIEW.

Using the RMAN LIST Command

The LIST command is used to query the RMAN repository and obtain data about:

RMAN LIST output is sent either to standard output or to the message log (though 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.

You can also list backups by querying V$BACKUP_FILES and the RC_BACKUP_FILES recovery catalog view. These views provide access to the same information as the LIST BACKUPSET command.

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.

See Also:

RMAN Reports

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

RMAN's reporting can be used to monitor and validate your ongoing backup strategy. The REPORT NEED BACKUP and REPORT UNRECOVERABLE commands let you ensure that the necessary backups are available for media recovery, and that you can perform media recovery within a reasonable amount of time.

Also, if you are managing backup storage yourself instead of using a flash recovery area, then you should run REPORT OBSOLETE regularly to identify backups no longer needed to meet your retention policy. You can then delete these backups with DELETE OBSOLETE.


Note:

A datafile that does not have a backup is still considered recoverable by RMAN, as long as a complete set of archived redo logs is available, from the time the datafile was created to the present. During recovery, an empty datafile is created, and then all of the changes to the datafile from the archived redo logs are applied to reconstruct the full contents of the file.


Reports of Obsolete Backups

The REPORT OBSOLETE command displays backups 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 of this file already exist.

RECOVERY WINDOW integer

The backup is not needed for recovery to any 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 of datafiles are no longer needed, which in turn determines when archived logs (and backups of archived logs) are no longer needed. Note that if a datafile has never been backed up, then all archived redo logs back to the creation time of the file will be retained. With a full set of logs, the file can be completely re-created during media recovery. An empty datafile is automatically created during recovery, and all changes ever applied to the original datafile that was not backed up are re-applied to the newly created file.

The REPORT OBSOLETE command lets you identify files which are no longer needed to satisfy backup retention policies. By default, the REPORT OBSOLETE commannd reports which files are obsolete under the currently configured retention policy. To generate reports of which files are obsolete according to different retention policies by using REDUNDANCY or RECOVERY WINDOW retention policy options with the REPORT OBSOLETE command. For example, if you run any of these commands:

RMAN> REPORT OBSOLETE REDUNDANCY 2;
RMAN> REPORT OBSOLETE RECOVERY WINDOW OF 5 DAYS;

RMAN displays backups that are obsolete according to those retention policies, regardless of the actual configured retention policy.

If you disable the retention policy completely (that is, if you run CONFIGURE RETENTION POLICY TO NONE), then RMAN does not consider any backups to be obsolete. If you run REPORT OBSOLETE with no options and no retention policy is configured, then RMAN issues an error message.

You can also query V$BACKUP_FILES and RC_BACKUP_FILES, using the OBSOLETE column to identify backup sets, datafile copies, and archived logs that are obsolete according to the configured retention policy.


Note:

An obsolete backup differs from an expired backup. An obsolete backup is no longer needed according to the user's retention policy. An expired backup is a backup that the CROSSCHECK command fails to find on the specified media device.


See Also:

Oracle Database Recovery Manager Reference for CONFIGURE command syntax

Reports of Orphaned Backups

The REPORT OBSOLETE ORPHAN command displays orphaned backups. To understand orphaned backups, you must understand the ide aof a database incarnation.

Understanding Database Incarnations

A new incarnation of a database is created whenever each time the database is opened with the RESETLOGS option. Performing an OPEN RESETLOGS archives the current online redo logs, resets the log sequence number to 1, and then gives the online redo logs a new time stamp and SCN.

RMAN is able to restore backups from direct ancestor incarnations and recover to the current time, even across OPEN RESETLOGS operations, as long as a continuous path of archived logs exists from the earliest backups to the point to which you want to recover.

When a database goes through multiple incarnations, some backups can become orphaned. Orphaned backups are backups that are unusable because they belong to incarnations of the database that are not direct ancestors of the current incarnation. That is, they are not in an unbroken incarnation path from the current incarnation.

Figure  shows a database that goes through three incarnations.

Figure 4-1 Database Incarnations and Orphaned Backups

Text description of bradv034.gif follows

Text description of the illustration bradv034.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 in this example 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
See Also:

Oracle Database Backup and Recovery Basics to learn how to generate reports, and Oracle Database Recovery Manager Reference for REPORT syntax

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 run SHOW ALL to display all current configurations. This configuration data is also stored in the V$RMAN_CONFIGURATION view.

See Also:

Oracle Database Recovery Manager Reference for SHOW syntax

Crosschecks of RMAN Backups

RMAN's record of backups can become out of step with the actual backups that exist on tape or disk. For example, a user may inadvertently delete backup pieces from disk using operating system commands, or one of the tapes used by the media manager may become corrupted.

To ensure that data about backups 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 4-2 illustrates a crosscheck of the media manager. RMAN queries the RMAN repository for the names and locations of the four backup pieces 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 4-2 Crosschecking the Media Manager

Text description of bradv031.gif follows

Text description of the illustration bradv031.gif

Crosschecks are useful because they can

Use the crosscheck feature to check the status of a backup on disk or tape. If the backup 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 in the media management software's catalog.

Backup pieces and image 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.

You can issue the DELETE EXPIRED command to delete all expired backups. 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.


Note:

The CROSSCHECK command does not delete operating system files or remove repository records. You must use the DELETE command for these operations.


See Also:

Monitoring RMAN Through V$ Views

When LIST, REPORT and SHOW do not provide all the information you need on RMAN activities, there are a number of useful V$ views that can provide more details.

Sometimes it is useful to identify exactly what a server session performing a backup or recovery task is doing. You have access to several views that can assist in monitoring the progress of or obtaining information about RMAN jobs, as described in the following table.

View Description

V$RMAN_OUTPUT

Displays messages reported by an RMAN job in progress.

V$RMAN_STATUS

Shows the success/failure status of all recently completed RMAN jobs.

V$PROCESS

Identifies currently active processes.

V$RECOVER_FILE

Identifies which datafiles require recovery.

V$SESSION

Identifies currently active sessions. Use this view to determine which database server sessions correspond to which RMAN allocated channels.

V$SESSION_LONGOPS

Provides progress reports on RMAN backup and restore jobs.

V$SESSION_WAIT

Lists the events or resources for which sessions are waiting.

V$BACKUP_SYNC_IO

Displays rows when the I/O is synchronous to the process (or thread on some platforms) performing the backup.

V$BACKUP_ASYNC_IO

Displays rows when the I/O is asynchronous to the process (or thread on some platforms) performing the backup.

Asynchronous I/O is obtained either through the use of slave I/O processes or because it is supported by the underlying operating system.

You can use RMAN to perform the checks discussed in the following sections:

Correlating Server Sessions with RMAN Channels

To identify which server sessions correspond to which RMAN channels, you can query V$SESSION and V$PROCESS. The SPID column of V$PROCESS identifies the operating system ID number for the process or thread. For example, on UNIX the SPID column shows the process ID, whereas on Windows the SPID column shows the thread ID. You have two basic methods for obtaining this information, depending on whether you have multiple RMAN sessions active concurrently.

Matching Server Sessions with Channels When One RMAN Session Is Active

When only one RMAN session is active, the easiest method for determining the server session ID for an RMAN channel is to execute the following query on the target database while the RMAN job is executing:

COLUMN CLIENT_INFO FORMAT a30
COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999

SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM V$PROCESS p, V$SESSION s
WHERE p.ADDR = s.PADDR
AND CLIENT_INFO LIKE 'rman%'
;

If you do not run the SET COMMAND ID command in the RMAN job, then the CLIENT_INFO column displays in the following format:

rman channel=channel_id

For example, the following shows sample output:

 SID SPID         CLIENT_INFO
---- ------------ ------------------------------
  14 8374         rman channel=ORA_SBT_TAPE_1

Matching Server Sessions with Channels in Multiple RMAN Sessions

If more than one RMAN session is active, it is possible for the V$SESSION.CLIENT_INFO column to yield the same information for a channel in each session. For example:

 SID SPID         CLIENT_INFO
---- ------------ ------------------------------
  14 8374         rman channel=ORA_SBT_TAPE_1
   9 8642         rman channel=ORA_SBT_TAPE_1

In this case, you have the following methods for determining which channel corresponds to which SID value.

Obtaining the Channel ID from the RMAN Output

In this method, you must first obtain the sid values from the RMAN output and then use these values in your SQL query.

To correlate a process with a channel during a backup:

  1. In one of the active sessions, run the RMAN job as normal and examine the output to get the sid for the channel. For example, the output may show:
    Starting backup at 21-AUG-01
    allocated channel: ORA_SBT_TAPE_1
    channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE
    
    
  2. Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS views while the RMAN job is executing. For example, enter:
    COLUMN CLIENT_INFO FORMAT a30
    COLUMN SID FORMAT 999
    COLUMN SPID FORMAT 9999
    
    SELECT s.SID, p.SPID, s.CLIENT_INFO
    FROM V$PROCESS p, V$SESSION s
    WHERE p.ADDR = s.PADDR
    AND CLIENT_INFO LIKE 'rman%'
    /
    
    

    Use the sid value obtained from the first step to determine which channel corresponds to which server session:

           SID SPID         CLIENT_INFO
    ---------- ------------ ------------------------------
            14 2036         rman channel=ORA_SBT_TAPE_1
            12 2066         rman channel=ORA_SBT_TAPE_1
    
Correlating Server Sessions with Channels by Using SET COMMAND ID

In this method, you specify a command ID string in the RMAN backup script. You can then query V$SESSION.CLIENT_INFO for this string.

To correlate a process with a channel during a backup:

  1. In each session, set the COMMAND ID to a different value after allocating the channels and then back up the desired object. For example, enter the following in session 1:
    RMAN> RUN 
    {
      ALLOCATE CHANNEL c1 TYPE sbt;
      SET COMMAND ID TO 'sess1';
      BACKUP DATABASE;
    }
    
    

    Set the command ID to a string such as sess2 in the job running in session 2:

    RUN 
    {
      ALLOCATE CHANNEL c1 TYPE sbt;
      SET COMMAND ID TO 'sess2';
      BACKUP DATABASE;
    }
    
    
  2. Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS views while the RMAN job is executing. For example, enter:
    SQL> SELECT SID, SPID, CLIENT_INFO 
      FROM V$PROCESS p, V$SESSION s 
      WHERE p.ADDR = s.PADDR 
      AND CLIENT_INFO LIKE '%id=sess%';
    
    

    If you run the SET COMMAND ID command in the RMAN job, then the CLIENT_INFO column displays in the following format:

    id=command_id,rman channel=channel_id
    
    

    For example, the following shows sample output:

     SID SPID         CLIENT_INFO
    ---- ------------ ------------------------------
      11 8358         id=sess1
      15 8638         id=sess2
      14 8374         id=sess1,rman channel=c1
       9 8642         id=sess2,rman channel=c1
    
    

    The rows that contain the string rman channel show the channel performing the backup. The remaining rows are for the connections to the target database.

    See Also:

    Oracle Database Recovery Manager Reference for SET COMMAND ID syntax, and Oracle Database Reference for more information on V$SESSION and V$PROCESS

Monitoring RMAN Job Progress

Monitor the progress of backups and restores by querying the view V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOPS: detail and aggregate rows. Detail rows describe the files being processed by one job step, while aggregate rows describe the files processed by all job steps in an RMAN command. A job step is the creation or restore of one backup set or datafile copy. Detail rows are updated with every buffer that is read or written during the backup step, so their granularity of update is small. Aggregate rows are updated when each job step completes, so their granularity of update is large.

Table 4-1 describes column in V$SESSION_LONGOPS that are most relevant for RMAN. Typically, you will view the detail rows rather than the aggregate rows to determine the progress of each backup set.

Table 4-1 Columns of V$SESSION_LONGOPS Relevant for RMAN
Column Description for Detail Rows

SID

The server session ID corresponding to an RMAN channel.

SERIAL#

The server session serial number. This value changes each time a server session is reused.

OPNAME

A text description of the row. Examples of details rows include RMAN: datafile copy, RMAN: full datafile backup, and RMAN: full datafile restore.

Note: RMAN: aggregate input and RMAN: aggregate output are the only aggregate rows.

CONTEXT

For backup output rows, this value is 2. For all other rows except proxy copy (which does not update this column), the value is 1.

SOFAR

The meaning of this column depends on the type of operation described by this row:

  • For image copies, the number of blocks that have been read.
  • For backup input rows, the number of blocks that have been read from the files being backed up.
  • For backup output rows, the number of blocks that have been written to the backup piece.
  • For restores, the number of blocks that have been processed to the files that are being restored in this one job step.
  • For proxy copies, the number of files that have been copied.

TOTALWORK

The meaning of this column depends on the type of operation described by this row:

  • For image copies, the total number of blocks in the file.
  • For backup input rows, the total number of blocks to be read from all files processed in this job step.
  • For backup output rows, the value is 0 because RMAN does not know how many blocks that it will write into any backup piece.
  • For restores, the total number of blocks in all files restored in this job step.
  • For proxy copies, the total number of files to be copied in this job step.

Each server session performing a backup or restore reports its progress compared to the total amount of work required for a job step. For example, if you perform a database restore that uses two channels, and each channel has two backup sets to restore (a total of four sets), then each server session reports its progress through a single backup set. When that set is completely restored, RMAN begins reporting progress on the next set to restore.

To monitor job progress:

  1. Before starting the job, create a script file (called, for this example, longops) containing the following SQL statement:
    SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
           ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
    FROM V$SESSION_LONGOPS
    WHERE OPNAME LIKE 'RMAN%'
      AND OPNAME NOT LIKE '%aggregate%'
      AND TOTALWORK != 0
      AND SOFAR <> TOTALWORK
    ;
    
    
  2. After connecting to the target database and, if desired, the recovery catalog database, start an RMAN job. For example, enter:
    RESTORE DATABASE;
    
    
  3. While the job is running, start SQL*Plus connected to the target database, and execute the longops script to check the progress of the RMAN job. If you repeat the query while the restore progresses, then you see output such as the following:
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK %_COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      10377      36617      28.34
    
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      21513      36617      58.75
    
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      29641      36617      80.95
    
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      35849      36617       97.9
    
    SQL> @longops
    no rows selected
    
    
  4. If you run the script at intervals of two minutes or more and the %_COMPLETE column does not increase, then RMAN is encountering a problem. Refer to "Monitoring RMAN Interaction with the Media Manager" to obtain more information.

If you frequently monitor the execution of long-running tasks, you could create a shell script or batch file under your host operating system that runs SQL*Plus to execute this query repeatedly.

Monitoring RMAN Interaction with the Media Manager

You can use the event names in the dynamic performance event views to monitor RMAN calls to the media management API. The event names have one-to-one correspondence with sbt functions, as shown in the following examples:

sbtinit
sbtopen
sbtread
sbtwrite
sbtbackup

Before making a call to any of functions in the media management API, the server adds a row in V$SESSION_WAIT, with the STATUS column including the string WAIT. The V$SESSION_WAIT.SECONDS_IN_WAIT column shows the number of seconds that the server has been waiting for this call to return. After an sbt function is returned from the media manager, this row disappears.

A row in V$SESSION_WAIT corresponding to an sbt event name does not indicate a problem, because the server updates these rows at runtime. The rows appear and disappear as calls are made and returned. However, if the SECONDS_IN_WAIT column is high, then the media manager may be hung.

To monitor the sbt events, you can run the following SQL query:

COLUMN EVENT FORMAT a10
COLUMN SECONDS_IN_WAIT FORMAT 999
COLUMN STATE FORMAT a20
COLUMN CLIENT_INFO FORMAT a30

SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT, 
       STATE, CLIENT_INFO
FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE sw.EVENT LIKE 'sbt%'
       AND s.SID=sw.SID
       AND s.PADDR=p.ADDR
/

Examine the SQL output to determine which sbt functions are waiting. For example, the following output indicates that RMAN has been waiting for the sbtbackup function to return for ten minutes:

SPID EVENT        SEC_WAIT STATE                CLIENT_INFO
---- ---------- ---------- -------------------- ------------------------------
8642 sbtbackup         600 WAITING              rman channel=ORA_SBT_TAPE_1

Note:

The V$SESSION_WAIT view shows only database events, not media manager events.


See Also:

Oracle Database Reference for descriptions of V$SESSION_WAIT

Monitoring RMAN Job Performance

Monitor backup and restore performance by querying V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO.

See Also:

Oracle Database Reference for more information on these V$ views, and "Step 5: Query V$ Views to Identify Bottlenecks" to learn how to use these views to tune backup performance

Determining Which Datafiles Require Recovery

You can often use the dynamic performance view V$RECOVER_FILE to determine which files need to be recovered and why they need to be recovered. The following query shows the file numbers of datafiles that require recovery, as well as the reason for recovery (if known) and the SCN and time when recovery needs to begin:

COL FILE# FORMAT 999
COL ERROR FORMAT a10
SELECT * FROM V$RECOVER_FILE;

FILE# ONLINE  ONLINE_ ERROR         CHANGE# TIME
----- ------- ------- ---------- ---------- --------------------
    4 ONLINE  ONLINE  FILE NOT            0
                      FOUND
    5 ONLINE  ONLINE  FILE NOT            0
                      FOUND
    8 OFFLINE OFFLINE OFFLINE             0
                      NORMAL
     

Note:

The view is not useful if the control file currently in use is a restored backup or a new control file created after the media failure occurred. A restored or re-created control file does not contain the information needed to update V$RECOVER_FILE accurately.



You canperform a useful join between V$RECOVER_FILE, V$DATAFILE and V$TABLESPACE to see which datafiles and tablespaces are in need of recovery, as shown in the following example:

COL df# FORMAT 999
COL df_name FORMAT a35
COL tbsp_name FORMAT a10
COL status FORMAT a7
COL error FORMAT a10

SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, 
       d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#
;

Sample output follows:


 DF# DF_NAME                            TBSP_NAME  STATUS   ERROR         CHANGE# TIME
---- -------------------------          ---------- -------  ---------- ---------- -----
   4 /oracle/oradata/trgt/drsys01.dbf   DRSYS      ONLINE   FILE NOT          0
                                                            FOUND
   5 /oracle/oradata/trgt/example01.dbf EXAMPLE    ONLINE   FILE NOT          0
                                                            FOUND
   8 /oracle/oradata/trgt/users01.dbf   USERS      OFFLINE  OFFLINE           0
                                                            NORMAL

Deletion of RMAN Backups

Every RMAN backup produces a corresponding record in the RMAN repository. This record is stored in the control file. If a recovery catalog is used, the record can also be found in the recovery catalog after the recovery catalog is resynced from the control file.

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 access the record in the RC_BACKUP_SET catalog view.

The V$ control file views and recovery catalog tables differ in the way that they store information, and this affects how RMAN handles repository records. The recovery catalog RMAN repository is stored in actual database tables, while the control file version of the repository is stored in an internal structure in the control file.

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

Because of the way that control file data is stored, RMAN cannot remove 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 4-2 describes the functionality of the various RMAN deletion commands. All of these work whether you store the RMAN repository only in the control file or use a recovery catalog.

Table 4-2 Maintenance Commands and Scripts (Page 1 of 2)
Command or Script Purpose

DELETE

To delete physical backups, update the control file records to status DELETED, and remove their records from the recovery catalog (if a recovery catalog is used).

You can specify that DELETE should remove backups that are EXPIRED or OBSOLETE. If you run DELETE EXPIRED on a backup that exists, RMAN issues a warning and does not delete the backup. You can override this behavior and delete the backup 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 specific files that it backs up. If you specify ALL INPUT, then RMAN deletes all copies of the files recorded in the RMAN repository.

CHANGE ... UNCATALOG

To delete recovery catalog records for specified backups and change their control file records to status DELETED. Note that the CHANGE ... UNCATALOG command does not delete files from the operating system.

See Also:

"Crosschecks of RMAN Backups"

Removal of Backups 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 command within RMAN to remove RMAN backups, rather than an operating system or media manager utility or command. Otherwise, the RMAN repository can contain records of backups that are no longer available for use in restore operations.

If you delete backups without using RMAN, you can use one of the following methods within RMAN to update the RMAN repository directly without performing a crosscheck:

Deletion of Obsolete Backups

The DELETE OBSOLETE command provides a convenient way to delete backups that are no longer needed. 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 considered obsolete by this policy. For example, you can run DELETE OBSOLETE in a script every night with a scheduling utility, freeing disk and tape space used by backups that are no longer needed.

Note that using a flash recovery area as the destination for all backups eliminates the need to manage obsolete backups. Obsolete backups will be deleted from the flash recovery area automatically as disk space is needed to store backup-related files.

See Also:

"Reports of Obsolete Backups"

Deletion of Expired Backups

The CROSSCHECK command updates the repository status for a backup to EXPIRED when it cannot locate it at the location to which it was backed up. This condition could occur if, for example, a backup was deleted from disk at the operating system level. You can identify expired backups 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

If you run CROSSCHECK while some backup device is temporarily not accessible. This can happen if a disk is unmounted or if RMAN does not correctly connect to a media manager. In such a case, fix the problem that prevented RMAN from finding the backups and rerun CROSSCHECK.

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

This command is especially useful if a user inadvertently deletes RMAN backups or archived logs from disk with an operating system utility. In such a case, the RMAN repository is not synchronized with the actual contents of disk. By running the CROSSCHECK command, RMAN marks the backups 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 archived redo logs that have already been backed up at least two times to tape:

RMAN> 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 backup an archived redo 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.

If you use the FORCE option of DELETE, RMAN will remove the repository record and delete the file if it exists. All I/O errors are ignored, and RMAN displays the number of objects deleted at the end of the job.

Removal of Backups 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 copy of each log sequence number, and then deletes the file that it backs up. For example, assume that you issue:

RMAN> 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 archived redo log file that it actually backs up. If you have multiple redo log archiving destinations, the other copies of the same log sequence number are not deleted.

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 three different directories. Then, you issue this command:

RMAN> 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.

During backup of archived redo logs, RMAN checks the file being backed up for corruption. If corruption is found, RMAN automatically switches to reading another copy of the same archived redo log, if one exists. For example, assume that /log1 and /log2 are the only enabled archiving destinations, and that they contain logs with sequence number up through 150. You run this command:

RMAN> BACKUP ARCHIVELOG FROM SEQUENCE 123 DELETE ALL INPUT;

RMAN can start reading from any cpoy of a given log. For example, if RMAN starts reading the copy of log sequence 123 from /log1 and discovers corruption in the file, it continues reading from the copy in /log2. Because DELETE ALL INPUT is specified, RMAN deletes all copies of logs on disk of sequence 123 and higher.

See Also:

CHANGE AVAILABLE and CHANGE UNAVAILABLE with RMAN Backups

RMAN can update the repository to show backups as AVAILABLE or UNAVAILABLE. An unavailable backup is one that cannot be accessed at a particular moment but that has not been deleted. For example, you may have backups on tape that are temporariliy stored offsite and are inaccesible. You can use the CHANGE ... UNAVAILABLE command to update the repository status for these backups to UNAVAILABLE so that RMAN will not try to use them for its backup and recovery operations.

When the tapes become available again, you can issue the CHANGE ... AVAILABLE command to update the RMAN repository to show that these backups now can be used. After setting the files back to status AVAILABLE, you can also run a CROSSCHECK to verify that RMAN can access the files.

See Also:

Changing Retention Policy Status of RMAN Backups

Use CHANGE... KEEP or CHANGE... NOKEEP to specify whether a backup should be subject to the configured retention policy or kept until a different date or even indefinitely.

The KEEP option exempts a backup 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. CHANGE ... NOKEEP is used to undo the effects of CHANGE ... KEEP, so that the configured retention policy applies to the backup.

For example, the following command blocks RMAN from considering backupsets with the tag 'year_end_2002' as obsolete under the retention policy:

RMAN> CHANGE BACKUPSET TAG year_end_2002 KEEP;

To allow backupsets with the tag year_end_2002 to be marked as obsolete based on the retention policy, use this command:

RMAN> CHANGE BACKUPSET TAG year_end_2002 NOKEEP;

If you want to prevent the use of a backup marked with KEEP in restore and recovery operations, then mark these backups as UNAVAILABLE. RMAN will not delete the records for these backups from the RMAN repository, but will not try to use them in restore and recovery until they are marked AVAILABLE again.

See Also: