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

15
Recovery Manager Troubleshooting

This chapter describes how to troubleshoot Recovery Manager. This chapter contains these topics:

Interpreting RMAN Message Output

Recovery Manager provides detailed error messages that can aid in troubleshooting problems. Also, the Oracle database server and third-party media vendors generate useful debugging output of their own. The discussion which follows explains how to identify and interpret the different errors you may encounter.

Identifying Types of Message Output

Output that is useful for troubleshooting failed or hung RMAN jobs is located in several different places, as explained in the following table.

Type of Output Produced By Location Description

RMAN messages

RMAN

Completed job information is in V$RMAN_STATUS and RC_RMAN_STATUS. Current job information is in V$RMAN_OUTPUT.

When running RMAN from the command line, you can direct output to the following places:

  • Standard output
  • A log file specified by LOG on the command line or the SPOOL LOG command
  • A file created by redirecting RMAN output (for example, UNIX > operator)

Contains actions relevant to the RMAN job as well as error messages generated by RMAN, the database server, and the media vendor. RMAN error messages have an RMAN-xxxxx prefix. Normal action descriptions do not have a prefix.

alert_SID.log

Oracle database server

The directory named in the BACKGROUND_DUMP_DEST initialization parameter.

Contains a chronological log of errors, initialization parameter settings, and administration operations. Records values for overwritten control file records (refer to Oracle Data Guard Concepts and Administration).

Oracle trace file

Oracle database server

The directory specified in the USER_DUMP_DEST initialization parameter.

Contains detailed output generated by Oracle server processes. This file is created when an ORA-600 or ORA-3113 error message occurs, whenever RMAN cannot allocate a channel, and when the database fails to load the media management library.

sbtio.log

Third-party media management software

The directory specified in the USER_DUMP_DEST initialization parameter.

Contains vendor-specific information written by the media management software. This log does not contain Oracle server or RMAN errors.

Media manager log file

Third-party media management software

The filenames for any media manager logs other than sbtio.log are determined by the media management software.

Contains information on the functioning of the media management device.

Recognizing RMAN Error Message Stacks

RMAN reports errors as they occur. If an error is not retriable, that is, RMAN cannot perform failover to another channel to complete a particular job step, then RMAN also reports a summary of the errors after all job sets complete. This feature is known as deferred error reporting.

One way to determine whether RMAN encountered an error is to examine its return code, as described in "Identifying RMAN Return Codes". A second way is to search the RMAN output for the string RMAN-00569, which is the message number for the error stack banner. All RMAN errors are preceded by this error message. If you do not see an RMAN-00569 message in the output, then there are no errors. Following is sample output for a syntax error:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found ")": expecting one of: "archivelog, backup, 
backupset, controlfilecopy, current, database, datafile, datafilecopy, (, plus, 
;, tablespace"
RMAN-01007: at line 1 column 18 file: standard input

Identifying Error Codes

Typically, you find the following types of error codes in RMAN message stacks:

RMAN Error Message Numbers

Table 15-1 indicates the error ranges for common RMAN error messages, all of which are described in Oracle Database Error Messages.

Table 15-1 RMAN Error Message Ranges 
Error Range Cause

0550-0999

Command-line interpreter

1000-1999

Keyword analyzer

2000-2999

Syntax analyzer

3000-3999

Main layer

4000-4999

Services layer

5000-5499

Compilation of RESTORE or RECOVER command

5500-5999

Compilation of DUPLICATE command

6000-6999

General compilation

7000-7999

General execution

8000-8999

PL/SQL programs

9000-9999

Low-level keyword analyzer

10000-10999

Server-side execution

11000-11999

Interphase errors between PL/SQL and RMAN

12000-12999

Recovery catalog packages

ORA-19511: Media Manager Errors

In the event of a media manager error, ORA-19511 is signalled, and the media manager is expected to provide RMAN a descriptive error. RMAN will display the error passed back to it by the media manager. For example, you might see this:

ORA-19511: Error received from media manager layer, error text:
   sbtpvt_open_input: file .* does not exist or cannot be accessed, errno = 2

The message from the media manager should provide you with enough information to let you fix the root problem. If it does not, you should refer to the documentation for your media manager or contact your media management vendor support representative for further information. ORA-19511 errors originate with the media manager, not the Oracle database. The database merely passes the message on from the media manager. The cause can only be addressed by the media management vendor.

Note that if you are still using an SBT 1.1-compliant media management layer, you may see some additional error message text. Output from an SBT 1.1-compliant media management layer is similar to the following:

ORA-19507: failed to retrieve sequential file, handle="c-140148591-20031014-06", 
parms=""
ORA-27007: failed to open file
Additional information: 7000
Additional information: 2
ORA-19511: Error received from media manager layer, error text:
   SBT error = 7000, errno = 0, sbtopen: backup file not found

The "Additional information" provided uses error codes specific to SBT 1.1. The values displayed correspond to the media manager message numbers and error text listed in Table 15-2. RMAN re-signals the error, as an ORA-19511 Error received from media manager layer error, and a general error message related to the error code returned from the media manager and including the SBT 1.1 error number is then displayed.

The SBT 1.1 error messages are listed here for your reference. Table 15-2 lists media manager message numbers and their corresponding error text. In the error codes, O/S stands for operating system. The errors prefixed with an asterisk are internal and should not typically be seen during normal operation.

Table 15-2 Media Manager Error Message Ranges (Page 1 of 2)
Cause No. Message

sbtopen

7000

7001

7002*

7003

7004

7005

7006

7007

7008

7009

7010

7011

7012*

Backup file not found (only returned for read)

File exists (only returned for write)

Bad mode specified

Invalid block size specified

No tape device found

Device found, but busy; try again later

Tape volume not found

Tape volume is in-use

I/O Error

Can't connect with Media Manager

Permission denied

O/S error for example malloc, fork error

Invalid argument(s) to sbtopen

sbtclose

7020*

7021*

7022

7023

7024*

7025

Invalid file handle or file not open

Invalid flags to sbtclose

I/O error

O/S error

Invalid argument(s) to sbtclose

Can't connect with Media Manager

sbtwrite

7040*

7041

7042

7043

7044*

Invalid file handle or file not open

End of volume reached

I/O error

O/S error

Invalid argument(s) to sbtwrite

sbtread

7060*

7061

7062

7063

7064

7065*

Invalid file handle or file not open

EOF encountered

End of volume reached

I/O error

O/S error

Invalid argument(s) to sbtread

sbtremove

7080

7081

7082

7083

7084

7085

7086*

Backup file not found

Backup file in use

I/O Error

Can't connect with Media Manager

Permission denied

O/S error

Invalid argument(s) to sbtremove

sbtinfo

7090

7091

7092

7093

7094

7095*

Backup file not found

I/O Error

Can't connect with Media Manager

Permission denied

O/S error

Invalid argument(s) to sbtinfo

sbtinit

7110*

7111

Invalid argument(s) to sbtinit

O/S error

Interpreting RMAN Error Stacks

Sometimes you may find it difficult to identify the useful messages in the RMAN error stack. Note the following tips and suggestions:

Interpreting RMAN Errors: Example

You attempt a backup of tablespace users and receive the following message:

Starting backup at 29-AUG-02
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2002 15:14:03
RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "USESR"

The RMAN-03002 error indicates that the BACKUP command failed. You read the last two messages in the stack first and immediately see the problem: no tablespace usesr appears in the recovery catalog because you mistyped the name.

Interpreting Server Errors: Example

Assume that you attempt to recover a tablespace and receive the following errors:

RMAN> RECOVER TABLESPACE users;

Starting recover at 29-AUG-01
using channel ORA_DISK_1

starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2001 15:18:43
RMAN-11003: failure during parse/execution of SQL statement: alter database 
recover if needed tablespace USERS
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 8 - file is in use or recovery
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'

As suggested, you start reading from the bottom up. The ORA-01110 message explains there was a problem with the recovery of datafile users01.dbf. The second error indicates that the database cannot recover the datafile because it is in use or already being recovered. The remaining RMAN errors indicate that the recovery session was cancelled due to the server errors. Hence, you conclude that because you were not already recovering this datafile, the problem must be that the datafile is online and you need to take it offline and restore a backup.

Interpreting SBT 2.0 Media Management Errors: Example

Assume that you use a tape drive and receive the following output during a backup job:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-19624: operation failed, retry possible
ORA-19507: failed to retrieve sequential file, handle="/tmp/foo", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
  sbtpvt_open_input:file /tmp/foo does not exist or cannot be accessed, errno=2

The error text displayed following the ORA-19511 error is generated by the media manager and describes the real source of the failure. Refer to the media manager documentation to interpret this error.

Interpreting SBT 1.1 Media Management Errors: Example

Assume that you use a tape drive and receive the following output during a backup job:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on c1 channel at 09/04/2001 13:18:19
ORA-19506: failed to create sequential file, name="07d36ecp_1_1", parms=""
ORA-27007: failed to open file
SVR4 Error: 2: No such file or directory
Additional information: 7005
Additional information: 1
ORA-19511: Error received from media manager layer, error text:
   SBT error = 7005, errno = 2, sbtopen: system error

The main information of interest returned by SBT 1.1 media managers is the error code in the "Additional information" line:

Additional information: 7005

Referring to Table 15-2, "Media Manager Error Message Ranges", you discover that error 7005 means that the media management device is busy. So, the media management software is not able to write to the device because it is in use or there is a problem with it.


Note:

The sbtio.log contains information written by the media management software, not the Oracle database server. Hence, you must consult your media vendor documentation to interpret the error codes and messages. If no information is written to the sbtio.log, contact your media manager support to ask whether they are writing error messages in some other location, or whether there are steps you need to take to have the media manager errors appear in sbtio.log.


Identifying RMAN Return Codes

One way to determine whether RMAN encountered an error is to examine its return code or exit status. The RMAN client returns 0 to the shell from which it was invoked if no errors occurred, and a nonzero error value otherwise.

How you access this return code depends upon the environment from which you invoked the RMAN client. For example, if you are running UNIX with the C shell, then, when RMAN completes, the return code is placed in a shell variable called $status. The method of returning exit status is a detail specific to the host operating system rather than the RMAN client.

Testing the Media Management API

On some platforms, Oracle provides a diagnostic tool called sbttest. This utility performs a simple test of the media management software by attempting to communicate with the media manager as the Oracle database server would.

Obtaining the sbttest Utility

On UNIX, the sbttest utility is typically located in $ORACLE_HOME/bin. If for some reason the utility is not included with your platform, then contact Oracle Support to obtain the C version of the program. You can compile this version of the program on all UNIX platforms.

Note that on platforms such as Solaris, you do not have to relink when using sbttest. On other platforms, relinking may be necessary.

Obtaining Online Documentation for the sbttest Utility

For online documentation of sbttest, issue the following on the command line:

% sbttest

The program displays the list of possible arguments for the program:

Error: backup file name must be specified
Usage: sbttest backup_file_name # this is the only required parameter
               <-dbname database_name>
               <-trace trace_file_name>
               <-remove_before>
               <-no_remove_after> 
               <-read_only>
               <-no_regular_backup_restore>
               <-no_proxy_backup>
               <-no_proxy_restore>
               <-file_type n>
               <-copy_number n>
               <-media_pool n>
               <-os_res_size n>
               <-pl_res_size n>
               <-block_size block_size> 
               <-block_count block_count>
               <-proxy_file os_file_name bk_file_name 
                           [os_res_size pl_res_size block_size block_count]>
               <-libname sbt_library_name>

The display also indicates the meaning of each argument. For example, following is the description for two optional parameters:

Optional parameters:
  -dbname  specifies the database name which will be used by SBT
           to identify the backup file. The default is "sbtdb"
  -trace   specifies the name of a file where the Media Management 
           software will write diagnostic messages.

Using the sbttest Utility

Use sbttest to perform a quick test of the media manager. The following table explains how to interpret the output.

If sbttest returns . . . Then . . .

0

The program ran without error. In other words, the media manager is installed and can accept a data stream and return the same data when requested.

a nonzero value

The program encountered an error. Either the media manager is not installed or it is not configured correctly.

To use sbttest:

  1. Make sure the program is installed and included in the system path by typing sbttest at the command line:
    % sbttest
    
    

    If the program is operational, then you should see a display of the online documentation.

  2. Execute the program, specifying any of the arguments described in the online documentation. For example, enter the following to create test file some_file.f and write the output to sbtio.log:
    % sbttest some_file.f -trace sbtio.log
    
    

    You can also test a backup of an existing datafile. For example, this command tests datafile tbs_33.f of database prod:

    % sbttest tbs_33.f -dbname prod
    
    
  3. Examine the output. If the program encounters an error, then it provides messages describing the failure. For example, if the database cannot find the library, you see:
    libobk.so could not be loaded. Check that it is installed properly, and that 
    LD_LIBRARY_PATH environment variable (or its equivalent on your platform) 
    includes the directory where this file can be found. Here is some additional 
    information on the cause of this error:
    ld.so.1: sbttest: fatal: libobk.so: open failed: No such file or directory
    
    

Note that in some cases sbttest can work but an RMAN backup does not. The reasons can be the following:

Terminating an RMAN Command

There are several ways to terminate an RMAN command in the middle of execution:

Terminating the Session with ALTER SYSTEM KILL SESSION

You can identify the Oracle session ID for an RMAN channel by looking in the RMAN log for messages with the format shown in the following example:

channel ch1: sid=15 devtype=SBT_TAPE

The sid and devtype are displayed for each allocated channel. Note that the Oracle sid is different from the operating system process ID. You can kill the session using a SQL ALTER SYSTEM KILL SESSION statement.

ALTER SYSTEM KILL SESSION takes two arguments, the sid printed in the RMAN message and a serial number, both of which can be obtained by querying V$SESSION. For example, run the following statement, where sid_in_rman_output is the number from the RMAN message:

SELECT SERIAL# FROM V$SESSION WHERE SID=sid_in_rman_output;

Then, run the following statement, substituting the sid_in_rman_output and serial number obtained from the query:

ALTER SYSTEM KILL SESSION 'sid_in_rman_output,serial#';

Note that this will not unhang the session if the session is hung in media manager code..

Terminating the Session at the Operating System Level

Finding and killing the processes that are associated with the server sessions is operating system specific. On some platforms the server sessions are not associated with any processes at all. Refer to your operating system specific documentation for more information.

Terminating an RMAN Session That Is Hung in the Media Manager

You may sometimes need to kill an RMAN job that is hung in the media manager. The best way to terminate RMAN when the channel connections are hung in the media manager is to kill the session in the media manager. If this action does not solve the problem, then on some platforms, such as Unix, you may be able to kill the Oracle processes of the connections. (Note that killing the Oracle processes may cause problems from the media manager. See your media manager documentation for details.)

Components of an RMAN Session

The nature of an RMAN session depends on the operating system. In UNIX, an RMAN session has the following processes associated with it:

Process Behavior During a Hung Job

RMAN usually hangs because one of the channel connections is waiting in the media manager code for a tape resource. The catalog connection and the default channel appear to hang, because they are waiting for RMAN to tell them what to do. Polling connections seem to be in an infinite loop while polling the RPC under the control of the RMAN process.

If you kill the RMAN process itself, then you also kill the catalog connection, the auxiliary connection, the default channel, and the polling connections. If target and auxiliary connections are not hung in the media manager code, they also terminate. If either the target connection or any of the auxiliary connections are executing in the media management layer, they will not terminate until the processes are manually killed at the operating system level.

Not all media managers can detect the termination of the Oracle process. Those which cannot may keep resources busy or continue processing. Consult your media manager documentation for details.

Terminating the catalog connection does not cause the RMAN process to terminate because RMAN is not performing catalog operations while the backup or restore is in progress. Removing default channel and polling connections causes the RMAN process to detect that one of the channels has died and then proceed to exit. In this case, the connections to the hung channels remain active as described previously.

Terminating an RMAN Session: Basic Steps

Once the hung channels in the media manager code are killed, the RMAN process detects this termination and proceed to exit, removing all connections except target connections that are still operative in the media management layer. The caveat about the media manager resources still applies in this case.

To terminate an Oracle process that is hung in the media manager:

  1. Query V$SESSION and V$SESSION_WAIT as described in "Monitoring RMAN Through V$ Views". For example, execute the following 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 output may be as follows:

    SPID EVENT        SEC_WAIT STATE                CLIENT_INFO
    ---- ---------- ---------- -------------------- -------------
    8642 sbtwrite2         600 WAITING              rman channel=ORA_SBT_TAPE_1
    8374 sbtwrite2         600 WAITING              rman channel=ORA_SBT_TAPE_2
    
    
  2. Using operating system-level tools appropriate to your platform, kill the hung sessions. For example, on Solaris execute a kill -9 command:
    % kill -9 8642 8374
    
    

    On Windows, there is a command-line utility called ORAKILL which lets you kill a specific thread in this situation. From a command prompt, run the following command:

    orakill sid thread_id
    
    

    where sid identifies the database instance to target, and the thread_id is the SPID value from the query in step 1.

  3. Check that the media manager also clears its processes. If any remain, the next backup or restore operation may hang again, due to the previous hang. In some media managers, the only solution is to shut down and restart the media manager. If the documentation from the media manager does not provide the needed information, contact technical support for the media manager.

    See Also:

    Your operating system specific documentation for the relevant commands

RMAN Troubleshooting Scenarios

This section contains these topics:

After Installation of Media Manager, RMAN Channel Allocation Fails: Scenario

In this scenario, you install and test the media manager as explained in "Configuring RMAN to Make Backups to a Media Manager", but you still cannot make RMAN back up to tape. For example, after allocating the sbt channel, you receive an error stack similar to the following:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on c1 channel at 08/29/2001 17:16:54
ORA-19554: error allocating device, device type: SBT_TAPE, device name: 
ORA-27211: Failed to load Media Management Library
Additional information: 25

The most important line of the error output is the ORA-27211 error. It indicates the basic problem, that the media management library could not be loaded. Typically, there is no need to refer to the trace file or sbtio.log in such a case.

After Installation of Media Manager, RMAN Channel Allocation Fails: Diagnosis

The ORA-27211 error indicates that the channel allocation is failing because the database is not loading the media management library. If the channel allocation fails, then the database generates a trace file in the USER_DUMP_DEST location that contains the error that caused the channel allocation to fail. The trace file should have the complete path name of the media management library loaded by the database as well as any other media manager errors or operating system errors. For example, the trace file on UNIX may be called something like /oracle/rdbms/log/prod1_ora_16226.trc, and may contain information such as the following:

*** 2001-08-29 17:16:54.385
SKGFQ OSD: Error in function sbtinit on line 2396
SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log
SBT Initialize failed for oracle.static 

The last line of this output indicates that Oracle is loading the default static library instead of the media management library that you installed.

You may find more detailed information in the file sbtio.log, as described in the error message. Note, however, that writing SBT trace messages is the responsibility of the media management software, not the Oracle database or RMAN. The media management vendor may not have implemented the writing of trace messages in a particular situation. Contact the media management vendor for details about the trace messages written to sbtio.log.

To test the loading of the media management library, try allocating a channel by using the PARMS parameter SBT_LIBRARY to force the loading of the media management library. For example, if your library is called /vendor/lib/some_mm_lib.so, then run a command such as the following, making sure to specify whatever PARMS settings are required by your media manager:

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt 
    PARMS='SBT_LIBRARY=/vendor/lib/some_mm_lib.so',
    'ENV=(NSR_SERVER=tape_svr,NSR_CLIENT=oracleclnt,NSR_GROUP=oracle_tapes)';
}

If the channel allocation fails, then check the trace file again to see whether you can learn anything new. If the channel allocation with SBT_LIBRARY succeeds, but an ordinary sbt channel allocation fails, then the database is probably trying to load a library other than the one you installed. By default, the database expects to find the media management library at $ORACLE_HOME/lib/libobk.so on UNIX, or %ORACLE_HOME%/bin/orasbt.dll on NT. You may have more than one library in the operating system path, and the database is loading the wrong one.

After Installation of Media Manager, RMAN Channel Allocation Fails: Solution

If the problem is that the database is not loading the correct library, then make sure that the library is named correctly in the SBT_LIBRARY parameter.


See Also:

Oracle Database Recovery Manager Reference for descriptions of the legal PARMS parameters


Backup Job Is Hanging: Scenario

In this scenario, an RMAN backup job starts as normal and then pauses inexplicably:

Recovery Manager: Release 10.1.0.2.0 - Production

Copyright (c) 1995, 2003, Oracle.  All rights reserved.

connected to target database: TRGT
connected to recovery catalog database

RMAN> BACKUP TABLESPACE SYSTEM, tools;

allocated channel: t1
channel t1: sid=16 devtype=SBT_TAPE

channel t1: starting datafile backupset
set_count=15 set_stamp=338309600
channel t1: including datafile 2 in backupset
channel t1: including datafile 1 in backupset
channel t1: including current controlfile in backupset
# Hanging here for 30 minutes now

Backup Job Is Hanging: Diagnosis

If a backup job is hanging, that is, not proceeding, then several scenarios are possible:

Query sbt wait events to gain more information. For example, run the following query on the target instance:

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 output may be as follows:

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

Backup Job Is Hanging: Solution

Because the causes of a hung backup job can be varied, so are the solutions. For example, backup jobs often hang simply because the tape device has completely filled the current cassette and is waiting for a new tape to be inserted. Ideally, the query of the sbt wait events should indicate the problem.

In this example, a single sbtbackup has taken 1500 seconds, so RMAN is waiting on the media manager to finish its write operation. Check that the media manager is functioning normally, and contact the media management vendor's technical support for assistance.

If the sbt wait event query is unhelpful, then examine media manager process, log, and trace files for signs of abnormal termination or other errors (refer to the description of message files in "Identifying Types of Message Output").


See Also:

"Terminating an RMAN Session: Basic Steps" to learn how to kill an RMAN session that is hanging


RMAN Fails to Start RPC Call: Scenario

In this scenario, you run a backup job and receive message output similar to the following:

channel c8: including datafile number 47 in backupset
RPC call appears to have failed to start on channel c9
RPC call ok on channel c9
channel c3: including datafile number 18 in backupset

RMAN Fails to Start RPC Call: Diagnosis

The RPC call appears to have failed message does not usually indicate a problem. The message indicates one of the following:

Timing problems occur in this way. When RMAN begins an RPC, it checks the V$SESSION performance view. The RPC updates the information in the view to indicate when it starts and finishes. Sometimes RMAN checks V$SESSION before the RPC has indicated it has started, which in turn generates the following message:

RPC call appears to have failed

If a message stating "RPC call ok" does not appear in the output immediately following the message stating "RPC call appears to have failed", then the backup job encountered an internal problem. Contact Oracle Support for further assistance.

Backup Fails with Invalid RECID Error: Scenario

In this scenario, you attempt a backup and receive the following error messages:

RMAN-3014: Implicit resync of recovery catalog failed
RMAN-6038: Recovery catalog package detected an error
RMAN-20035: Invalid high RECID error

Backup Fails with Invalid RECID Error: Diagnosis

In one common scenario, you restore a backup control file created through a non-Oracle mechanism, and then open the database without the RESETLOGS option. If you had created the backup control file through the RMAN BACKUP command or the SQL ALTER DATABASE BACKUP CONTROLFILE statement, then the database would have required you to reset the online logs.

The control file and the recovery catalog are now not synchronized. The database control file is older than the recovery catalog, because at one time the recovery catalog resynchronized with the old current control file, and now the database is using a backup control file. RMAN detects that the control file currently in use is older than the control file previously used to resynchronize.

Another common scenario occurs when you attempt to copy the target database to a new machine as follows:

  1. On machine 1, you shut down the database and make a copy of the control file with an operating system utility. You do not use CATALOG to add this control file copy to the repository.
  2. You transfer the control file copy to machine 2.
  3. On machine 2, you create a new initialization parameter file and new database instance.
  4. You mount the control file copy on machine 2. The database does not recognize the control file as a backup control file: to the database it looks like the current control file.
  5. You start RMAN and connect to the new target database and the recovery catalog on machine 2. Because the control file was not created with RMAN and was not cataloged as a control file copy, RMAN sees the database on machine 2 as the database on machine 1.
  6. You restore and recover database the new database on machine 2 and then open it. As a consequence, various records are added to the recovery catalog during the restore and recovery. For example, the highest RECID in the recovery catalog moves from 90 to 100.
  7. On machine 1, you start RMAN and connect to the original target database and recovery catalog. The recovery catalog indicates that the highest RECID is 100, but the control file indicates that the highest RECID is 90. The control file RECID should always be greater than or equal to the recovery catalog RECID, so RMAN issues RMAN-20035.

Backup Fails with Invalid RECID Error: Solution 1

This solution is safest and is strongly recommended. It preserves the control file, so that the historical information about the database stored in the control file continues to be available after the procedure.

To reset the database with RMAN:

  1. Connect to the target database with SQL*Plus. For example, enter:
    % sqlplus '/ AS SYSDBA'
    
    
  2. Mount the database if it is not already mounted. For example, enter:
    ALTER DATABASE MOUNT;
    
    
  3. Start cancel-based recovery by using the backup control file, then cancel it. The reason for canceling is that the USING BACKUP CONTROLFILE clause stamps the controlfile as a backup, which then permits OPEN RESETLOGS. For example, enter:
    ALTER DATABASE RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
    ALTER DATABASE RECOVER CANCEL;
    
    
  4. Use RMAN to connect to the target database and recovery catalog. For example, enter:
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
    
    
  5. Open the database with the RESETLOGS option. For example, enter:
    RMAN> ALTER DATABASE OPEN RESETLOGS;
    
    
  6. Take new backups so that you can recover the database if necessary. For example, enter:
    BACKUP DATABASE PLUS ARCHIVELOG;
    

Backup Fails with Invalid RECID Error: Solution 2

This solution is similar to the previous one, but does require that you re-create your control file. It is better-suited for the case in which you are copying your database to a second system, where you may not want to keep the history from the control file for the copy of the database on the second system, or where you might drop a few datafiles or change the online logs by editing your control file.

To create the control file with SQL*Plus:

  1. Connect to the target database with SQL*Plus. For example, enter:
    % sqlplus 'SYS/oracle@trgt AS SYSDBA'
    
    
  2. Mount the database if it is not already mounted:
    SQL> ALTER DATABASE MOUNT;
    
    
  3. Back up the control file to a trace file:
    SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
    
    
  4. Edit the trace file as necessary. The relevant section of the trace file looks something like the following:
    # The following commands will create a new control file and use it
    # to open the database.
    # Data used by the recovery manager will be lost. Additional logs may
    # be required for media recovery of offline data files. Use this
    # only if the current version of all online logs are available.
    STARTUP NOMOUNT
    CREATE CONTROLFILE REUSE DATABASE "TRGT" NORESETLOGS  ARCHIVELOG
    --  STANDBY DATABASE CLUSTER CONSISTENT AND UNPROTECTED
        MAXLOGFILES 32
        MAXLOGMEMBERS 2
        MAXDATAFILES 32
        MAXINSTANCES 1
        MAXLOGHISTORY 226
    LOGFILE
      GROUP 1 '/oracle/oradata/trgt/redo01.log'  SIZE 25M,
      GROUP 2 '/oracle/oradata/trgt/redo02.log'  SIZE 25M,
      GROUP 3 '/oracle/oradata/trgt/redo03.log'  SIZE 500K
    -- STANDBY LOGFILE
    DATAFILE
      '/oracle/oradata/trgt/system01.dbf',
      '/oracle/oradata/trgt/undotbs01.dbf',
      '/oracle/oradata/trgt/cwmlite01.dbf',
      '/oracle/oradata/trgt/drsys01.dbf',
      '/oracle/oradata/trgt/example01.dbf',
      '/oracle/oradata/trgt/indx01.dbf',
      '/oracle/oradata/trgt/tools01.dbf',
      '/oracle/oradata/trgt/users01.dbf'
    CHARACTER SET WE8DEC
    ;
    # Take files offline to match current control file.
    ALTER DATABASE DATAFILE '/oracle/oradata/trgt/tools01.dbf' OFFLINE;
    ALTER DATABASE DATAFILE '/oracle/oradata/trgt/users01.dbf' OFFLINE;
    # Configure RMAN configuration record 1
    VARIABLE RECNO NUMBER;
    EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE 
    DISK DEBUG 255');
    # Recovery is required if any of the datafiles are restored backups,
    # or if the last shutdown was not normal or immediate.
    RECOVER DATABASE
    # All logs need archiving and a log switch is needed.
    ALTER SYSTEM ARCHIVE LOG ALL;
    # Database can now be opened normally.
    ALTER DATABASE OPEN;
    # Commands to add tempfiles to temporary tablespaces.
    # Online tempfiles have complete space information.
    # Other tempfiles may require adjustment.
    ALTER TABLESPACE TEMP ADD TEMPFILE '/oracle/oradata/trgt/temp01.dbf' REUSE;
    # End of tempfile additions.
    
    
  5. Shut down the database:
    SHUTDOWN IMMEDIATE
    
    
  6. Execute the script to create the control file, recover (if necessary), archive the logs, and open the database:
    STARTUP NOMOUNT
    CREATE CONTROLFILE ...;
    EXECUTE ...;
    RECOVER DATABASE
    ALTER SYSTEM ARCHIVE LOG CURRENT;
    ALTER DATABASE OPEN ...;
    
  7. If you intend to keep and continue using this copy of the database, use the DBNEWID utility to change the name and DBID of the new database as needed.


    Caution:

    If you do not open with the RESETLOGS option, then two copies of an archived redo log for a given log sequence number may exist--even though these two copies have completely different contents. For example, one log may have been created on the original host and the other on the new host. If you accidentally confuse the logs during a media recovery, then the database will be corrupted but Oracle and RMAN cannot detect the problem.


Backup Fails Because of Control File Enqueue: Scenario

In this scenario, a backup job fails because RMAN cannot make a snapshot control file. The message stack is as follows:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/30/2001 22:48:44
ORA-00230: operation disallowed: snapshot controlfile enqueue unavailable

Backup Fails Because of Control File Enqueue: Diagnosis

When RMAN needs to back up or resynchronize from the control file, it first creates a snapshot or consistent image of the control file. If one RMAN job is already backing up the control file while another needs to create a new snapshot control file, then you may see the following message:

waiting for snapshot controlfile enqueue

Under normal circumstances, a job that must wait for the control file enqueue waits for a brief interval and then successfully obtains the enqueue. RMAN makes up to five attempts to get the enqueue and then fails the job. The conflict is usually caused when two jobs are both backing up the control file, and the job that first starts backing up the control file waits for service from the media manager.

To determine which job is holding the conflicting enqueue:

  1. After you see the first message stating "RMAN-08512: waiting for snapshot controlfile enqueue", start a new SQL*Plus session on the target database:
    % sqlplus 'SYS/oracle@trgt AS SYSDBA'
    
    
  2. Execute the following query to determine which job is causing the wait:
    SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE, 
           ACTION, LOGON_TIME "Logon", l.* 
    FROM V$SESSION s, V$ENQUEUE_LOCK l
    WHERE l.SID = s.SID
    AND l.TYPE = 'CF'
    AND l.ID1 = 0
    AND l.ID2 = 2;
    
    

    You should see output similar to the following (the output in this example has been truncated):

    SID User Program              Module                    Action           
    Logon
    --- ---- -------------------- ------------------- ---------------- ---------
    9 SYS rman@h13 (TNS V1-V3) backup full datafile: c10000210 STARTED 21-JUN-01
    

Backup Fails Because of Control File Enqueue: Solution

Commonly, enqueue situations occur when a job is writing to a tape drive, but the tape drive is waiting for new tape to be inserted. If you start a new job in this situation, then you will probably receive the enqueue message because the first job cannot complete until the new tape is loaded.

After you have determined which job is creating the enqueue, you can do one of the following:

RMAN Fails to Delete All Archived Logs: Scenario

In this scenario, the database archives automatically to two directories: ORACLE_HOME/oradata/trgt/arch and ORACLE_HOME/oradata/trgt/arch2. You tell RMAN to perform a backup and delete the input archived redo logs afterward in the following script:

BACKUP ARCHIVELOG ALL DELETE INPUT;

You then run a crosscheck to make sure the logs are gone and find the following:

CROSSCHECK ARCHIVELOG ALL;

validation succeeded for archived log
archivelog filename=/oracle/oradata/trgt/arch2/archive1_964.arc recid=19 
stamp=368726072

RMAN deleted one set of logs but not the other.

RMAN Fails to Delete All Archived Logs: Diagnosis

This problem is not an error. When you specify DELETE INPUT without the ALL keyword, RMAN deletes only one copy of each input log. Even if you archive to five destinations, RMAN deletes logs from only one directory.

RMAN Fails to Delete All Archived Logs: Solution

To force RMAN to delete all existing archived redo logs, use the DELETE ALL INPUT clause of the BACKUP command. For example, enter:

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

Backup Fails Because RMAN Cannot Locate an Archived Log: Scenario

In this scenario, you schedule regular backups of the archived redo logs. The next time you make a backup, you receive this error:

RMAN-6089:  archive log NAME not found or out of sync with catalog

Backup Fails Because RMAN Cannot Locate an Archived Log: Diagnosis

This problem occurs when the archived log that RMAN is looking for cannot be accessed by RMAN, or the recovery catalog needs to be resynchronized. Often, this error occurs when you delete archived logs with an operating system command, which means that RMAN is unaware of the deletion. The RMAN-6089 error occurs because RMAN attempts to back up a log that the repository indicates still exists.

Backup Fails Because RMAN Cannot Locate an Archived Log: Solution

Make sure that the archived logs exists in the specified directory and that the RMAN catalog is synchronized. Check the following:

  1. Make sure the archived log file that is specified by the RMAN-6089 error exists in the correct directory.
  2. Check that the operating system permissions are correct for the archived log (owner = oracle, group = DBA) to make sure that RMAN can access the file.
  3. If the file appears to be correct, then try synchronizing the catalog by running the following command from the RMAN prompt:
    RESYNC CATALOG;
    
    

If you know that the logs are unavailable because you deleted them by using an operating system utility, then run the following command at the RMAN prompt to update RMAN metadata:

CROSSCHECK ARCHIVELOG ALL;

It is always better to use RMAN to delete logs than to use an operating system utility. The easiest method to remove unwanted logs is to specify the DELETE INPUT option when backing up archived logs. For example, enter:

BACKUP DEVICE TYPE sbt 
  ARCHIVELOG ALL 
  DELETE ALL INPUT;

RMAN Does Not Recognize Character Set Name: Scenario

In this scenario, you are connected to the target database while it is not open and attempting to perform an RMAN operation. You receive the following error:

PLS-00553: character set name is not recognized

RMAN Does Not Recognize Character Set Name: Diagnosis

Typically, this message means that the character set in the client environment, that is, the environment in which you are running the RMAN client, is different from the character set in the target database environment.

RMAN Does Not Recognize Character Set Name: Solution

  1. Query the target database to determine the value of the NLS_CHARACTERSET parameter. For example, run this query:
    SQL>       SELECT VALUE FROM V$NLS_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';
    
    
  2. Set the character set environment variable in the client to the same value as the variable in the server. For example, you can set the NLS_LANG environment variable on a UNIX system as follows:
    % setenv NLS_LANG american_america.we8dec
    % setenv NLS_DATE_FORMAT "MON DD YYYY HH24:MI:SS"
    
    

If the connection is made througfh a listener, then the listener must be started with the correct Globalization Support settings. Otherwise, the spawned connections inherit the incorrect Globalization Support settings from the listener.

RMAN Denies Logon to Target Database: Scenario

RMAN fails with ORA-01031 (insufficient privileges) or ORA-01017 (invalid username/password) errors when trying to connect to the target database:

% rman
Recovery Manager: Release 10.1.0.2.0 - Production

Copyright (c) 1995, 2003, Oracle.  All rights reserved.

RMAN> CONNECT TARGET sys/mypass@inst1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-01031: insufficient privileges

RMAN Denies Logon to Target Database: Diagnosis

RMAN automatically requests a connection to the target database as SYSDBA. In order to connect to the target as SYSDBA, you must do one of the following:

If the target database does not have a password file, then the user you are logged in as must be validated with operating system authentication.

RMAN Denies Logon to Target Database: Solution

Either create a password file for the target database or add yourself to the administrator list in the operating system.

See Also:

Oracle Database Administrator's Guide to learn how to create a password file

Database Duplication Fails Because of Missing Log: Scenario

In this scenario, you attempt to duplicate a database with the DUPLICATE command, but receive the following error stack:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/04/2001 12:11:29
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 16 scn 145858 found to restore

Database Duplication Fails Because of Missing Log: Diagnosis

The problem is that RMAN is not able to apply all the archived logs needed for complete recovery. For example, if you only backed up logs through sequence 15, but the most recent archived log is sequence 16, then DUPLICATE fails.

Database Duplication Fails Because of Missing Log: Solution

When creating the duplication script, use the SET UNTIL command to specify a log sequence number for incomplete recovery. For example, to terminate recovery after applying log sequence 15, enter:

RUN
{
  SET UNTIL SEQUENCE 16 THREAD 1;  # recovers up to but not including log 16
  DUPLICATE TARGET DATABASE TO 'dupdb';

}

See Also:

"Creating Duplicate of the Database at a Past Point in Time: Example" for more information about performing incomplete recovery during the duplication operation

Duplication Fails with Multiple RMAN-06023 Errors: Scenario

In this scenario, you back up the database, then run the DUPLICATE command. You receive the following error stack:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/04/2001 13:55:11
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

Duplication Fails with Multiple RMAN-06023 Errors: Diagnosis

The DUPLICATE command recovers to archived redo logs, but cannot recover into online redo logs. Thus, if the restored backup cannot be made consistent without applying the online redo logs, then duplication fails with RMAN-06023 errors because RMAN is looking for backups created before the most recent archived log.

Duplication Fails with Multiple RMAN-06023 Errors: Solution

After backing up the source database, archive and back up the current redo log:

RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
RMAN> BACKUP ARCHIVELOG ALL;

This archives all records in the online redo logs so that RMAN can now recover the backup by applying the most recent archived redo log.

UNKNOWN Database Name Appears in Recovery Catalog: Scenario

In this scenario, you list the database incarnations registered in the recovery catalog and see a database with the name UNKNOWN:

LIST INCARNATION OF DATABASE;  
 
RMAN-03022: compiling command: list  
List of Database Incarnations  
DB Key  Inc Key   DB Name   DB ID       STATUS    Reset SCN    Reset Time
------- -------   -------   ------      ------    ----------   ----------
56      57        TRGT      4052472287  CURRENT   1            Sep 03 2001 06:45:51
1       19        UNKNOWN   4141147584  PARENT    1            Jan 08 2001 14:47:28
.
.
.

UNKNOWN Database Name Appears in Recovery Catalog: Diagnosis

One way you get the DB_NAME of UNKNOWN is when you register a database that was once opened with the RESETLOGS option. The DB_NAME can be changed during a RESETLOGS operation, so RMAN does not know what the DB_NAME was for those old incarnations of the database because it was not registered in the recovery catalog at the time. Consequently, RMAN sets the DB_NAME column to UNKNOWN when creating the DBINC record.

UNKNOWN Database Name Appears in Recovery Catalog: Solution

The UNKNOWN name entry is expected behavior after a RESETLOGS operation. You should not attempt to remove UNKNOWN entries from the recovery catalog.