4
RMAN Maintenance Concepts

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

This chapter contains these topics:

• RMAN Reporting
• Crosschecks of RMAN Backups
• Deletion of RMAN Backups
• CHANGE AVAILABLE and CHANGE UNAVAILABLE with RMAN Backups
• Changing Retention Policy Status of RMAN Backups

Text description of the illustration bradv031.gif

Crosschecks are useful because they can

• Update outdated information about backups that disap peared from disk or tape or became corrupted
• Update the repository if you dele te archived redo logs or other files with operating system commands

Use the crosschec k 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 comm and to delete all expired backups. RMAN removes the record for the expired file from the repository. If for some reason the file stil l exists on the media, then RMAN issues warnings and lists the mismatched objects that cannot be deleted.

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 t he progress of or obtaining information about RMAN jobs, as described in the following table.

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

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

• Correlating Server Sessi ons with RMAN Channels
• Monitoring RMAN Job Progress
• Monitoring RMAN Interaction with t he Media Manager
• Monitoring RMAN Job Perfor mance
• Determining Which Datafiles Require R ecovery

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 S PID 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 Sessi ons 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

SELEC
T 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< /code> column displays in the following format:

rman channel=channel_id

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

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 proces s 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 'ses
   s2';
     BACKUP DATABASE;
   }
   
   

2. Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS vi ews while the RMAN job is executing. For example, enter:

   SQL> SELE
   CT SID, SPID, CLIENT_INFO 
     FROM V$PROCESS p, V$SESSION s 
     WHERE p.ADDR = s.PADDR 
     AND CLIENT_INFO LIKE '%id=sess%';
   
   

   If you ru n the SET COMMAND ID command in the RMAN job, then the CLIENT_INFO column display s in the following format:

   id=command_id,rman channel=channel_id
   
   

   For example, the following shows sample o utput:

    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 performi ng the backup. The remaining rows are for the connections to the target database.

   See Also:

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

   < /td>

Monitoring RMAN Job Progress

Monitor the progre ss of backups and restores by querying the view V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOP S: detail and aggregate rows. Detail rows describe the files being processed by one job step, while aggregate rows describe th e 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. Deta il rows are updated with every buffer that is read or written during the backup step, so their granularity of update is small. Aggreg ate 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.

Tabl e 4-1 Columns of V$SESSION_LONGOPS Relevant for RMAN

Each server session performing a backup or restore reports its pro gress compared to the total amount of work required for a job step. For example, if you perform a database restore that uses two chan nels, 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: