Oracle8i Recovery Manager User's Guide and Reference
Release 2 (8.1.6)

A76990-01

Library

Product

Contents

Index

Prev Next

9
Recovery Manager Troubleshooting

This chapter describes how to troubleshoot and debug Recovery Manager. It includes the following topics:

Interpreting 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. This section addresses the following topics:

Identifying Types of Message Output

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

Type of Output   Produced By  Location  Description 

RMAN messages 

RMAN 

Direct this output to:

  • Standard output (typically the terminal)

  • A log file specified by the log option on the command line

  • A log file created by re-directing standard output using operators at the command line

 

Describes actions relevant to the RMAN job as well as error messages generated by RMAN, the server, and the media vendor. 

RMAN trace file 

RMAN's debug command 

The file specified using the trace parameter at the command line.  

Contains exhaustive output on the creation and execution of PL/SQL program units. 

alert.log 

Oracle database server 

The directory specified in the USER_DUMP_DEST initialization parameter. 

Contains a chronological log of errors, init.ora settings, and administration operations. Records values for overwritten control file records (see "Monitoring the Overwriting of Control File Records"). 

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. 

sbtio.log 

Third-party media management software 

The directory specified in the USER_DUMP_DEST initialization parameter.  

Contains information on the functioning of the media management device. 

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. 

Identifying Error Codes

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

Explanations for RMAN and ORA error codes are in Oracle8i Error Messages.

RMAN Error Message Numbers

Table 9-1 indicates the error ranges for common RMAN error messages, all of which are described in Oracle8i Error Messages:

Table 9-1 RMAN Error Message Ranges (Page 1 of 2)
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 

20000-20999 

Recovery catalog packages 

Media Manager Error Numbers

When errors occur through the media management API, RMAN returns an error message number prefixed as follows:

Additional information:

Below is the list of 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 never be seen during normal operation.

Table 9-2 Media Manager Error Message Ranges
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

Bad 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 

Bad th to sbtclose (no sbtopen done)

Bad flags to sbtclose

I/O error

O/S error

Invalid argument(s) to sbtclose

Can't connect with Media Manager 

sbtwrite 

7040*

7042

7043

7044* 

Bad th to sbtwrite

I/O error

O/S error

Invalid argument(s) to sbtwrite 

sbtread 

7060*

7061

7063

7064

7065* 

Bad th to sbtread

EOF encountered

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 being used

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:

  1. Because most of the messages in the error stack are not meaningful for the purposes of troubleshooting, try to identify the one or two errors that are most important.

  2. Check for a line that says Additional information: followed by an integer. This line indicates a media management error. The integer that follows refers to a code that is explained in the text of the error message.

  3. Read the messages from the bottom up, because this is the order in which RMAN issues the messages. The first one or two errors issued are usually the most informative.

  4. Identify the basic type of error according to the error range chart in Table 9-1 and then refer to Oracle8i Error Messages for information on the most important messages.

Interpreting RMAN Errors: Example

You attempt the following backup of tablespace TBS_99 and receive the following message:

RMAN> run{allocate channel c1 type disk; backup tablespace tbs_99;}

RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=8 devtype=DISK

RMAN-03022: compiling command: backup
RMAN-03026: error recovery releasing channel resources
RMAN-08031: released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: backup
RMAN-06038: recovery catalog package detected an error
RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "TBS_99"

You first note that the error occurred after RMAN compiled and executed the allocate command, but before it could execute the backup command. You read the last two messages in the stack first and immediately see the problem: no tablespace called TBS_99 appears in the recovery catalog. You conclude that either TBS_99 does not exist in the database, or it does exist in the database but the recovery catalog does not yet know about it.

Interpreting Server Errors: Example

Assume that you attempt to back up your database and receive the following error:

RMAN> run{allocate channel c1 type disk;backup database;}

RMAN-03022: compiling command: allocate
RMAN-03026: error recovery releasing channel resources
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: allocate
RMAN-06004: ORACLE error from recovery catalog database: ORA-03113: end-of-file on 
communication channel
RMAN-06097: text of failing SQL statement: begin dbms_rcvman . resetAll ; dbms_rcvman . 
set_package_constants ; :
RMAN-06099: error occurred in source file: krmk.pc, line: 14531

As suggested, you start reading from the bottom up. The first message is numbered 6099, so you know that RMAN was not able to compile the command. The third message from the bottom is more specific: the error came from the recovery catalog database. The ORA-03113 message indicates that there was a problem communicating with the recovery catalog server.

You then query the recovery catalog database and discover that it was in the process of being shut down when you executed the run command. Consequently, the job failed.

Interpreting Media Management Errors: Example

Media management errors are not uncommon. 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-03007: retryable error occurred during execution of command: allocate
RMAN-07004: unhandled exception during command execution on channel c4
RMAN-10032: unhandled exception during execution of job step 4: ORA-06512: at line 158 
RMAN-10035: exception raised in RPC: ORA-19624: operation failed, retry possible 
ORA-19506: failed to create sequential file, name="df_99_1", parms=""
ORA-27007: failed to open file
HP-UX Error: 1003: Unknown system error
Additional information: 7004
Additional information: 1
ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 410
RMAN-10031: ORA-19624 occurred during call to DBMS_BACKUP_RESTORE.DEVICEALLOCATE

Following the suggestions for reading error message stacks, you look for the Additional information: line and notice:

Additional information: 7004

You discover that error 7004 means that RMAN is unable to connect to the tape device. For some reason, RMAN is not recognizing your media management software.

Note also that when you read from the bottom up, the first line says that an error occurred during a call to a PL/SQL program unit called DEVICEALLOCATE. Also, the first message below the stack banner says that there was an error executing the allocate command. All of this information indicates that RMAN was not able to allocate a tape channel because it was unable to recognize the tape device.

Interpreting Debugging Output

If the standard RMAN error message stack is not generating sufficient information, then use the RMAN debug command to generate more extensive output. Use debugging for the following purposes:

Because debugging output can be voluminous, redirect the output to a trace file to prevent overloading the current log file or standard output. The debugging output displays the following detailed information:

Interpreting Debugging Output: Example

RMAN debugging output is so highly detailed that you may find yourself unable to distinguish the useful from the useless information. Assume that you execute the following command in debug mode:

run{ allocate channel c1 type disk; backup tablespace TBS_5, TBS_6; }

The command fails. See the following subset of the debug output for this failed command (note the commented lines in bold):

EXEC SQL AT RCVCAT begin :name := upper ( :name ) ; dbms_rcvman . translateTablespace ( 
:name ) ; end ;
   sqlcode=0
      :b1 = "TBS_5"

/* RMAN calls the translateTablespace procedure to translate tablespace  * 
 * name TBS_5 into its constituent datafiles and then calls getDataFile  *
 * to get information about each of the datafiles in tablespace TBS_5.   */

EXEC SQL AT RCVCAT begin dbms_rcvman . getDataFile ( :fno , :crescn , :cretime:cretime_i , 
:fname:fname_i , :tsname , :status:status_i , :blksize , :kbytes:kbytes_i , 
:blocks:blocks_i , :urscn , :stopscn:stopscn_i , :read_only ) ; end ;
   sqlcode=0
      :b1 = 14
      :b2 = 33410
      :b3 = "11-JUN-99"
      :b4 = "/vobs/oracle/dbs/tbs_51.f"  /* datafile name */
      :b5 = "TBS_5"
      :b6 = <EMPTY STRING>
      :b7 = 2048
      :b8 = 500
      :b9 = 250
      :b10 = 0
      :b11 = NULL
      :b12 = 0

EXEC SQL AT RCVCAT begin dbms_rcvman . getDataFile ( :fno , :crescn , :cretime:cretime_i , 
:fname:fname_i , :tsname , :status:status_i , :blksize , :kbytes:kbytes_i , 
:blocks:blocks_i , :urscn , :stopscn:stopscn_i , :read_only ) ; end ;
   sqlcode=0
      :b1 = 15
      :b2 = 33416
      :b3 = "11-JUN-99"
      :b4 = "/vobs/oracle/dbs/tbs_52.f"  /* datafile name */
      :b5 = "TBS_5"
      :b6 = <EMPTY STRING>
      :b7 = 2048
      :b8 = 500
      :b9 = 250
      :b10 = 0
      :b11 = NULL
      :b12 = 0

EXEC SQL AT RCVCAT begin dbms_rcvman . getDataFile ( :fno , :crescn , :cretime:cretime_i , 
:fname:fname_i , :tsname , :status:status_i , :blksize , :kbytes:kbytes_i , 
:blocks:blocks_i , :urscn , :stopscn:stopscn_i , :read_only ) ; end ;
   sqlcode=-1405

/* RMAN tries to translate tablespace name TBS_6 and get the datafiles, * 
 * but is unable to identify any datafiles for this tablespace.         */

EXEC SQL AT RCVCAT begin :name := upper ( :name ) ; dbms_rcvman . translateTablespace ( 
:name ) ; end ;
   sqlcode=0
      :b1 = "TBS_6"

EXEC SQL AT RCVCAT begin dbms_rcvman . getDataFile ( :fno , :crescn , :cretime:cretime_i , 
:fname:fname_i , :tsname , :status:status_i , :blksize , :kbytes:kbytes_i , 
:blocks:blocks_i , :urscn , :stopscn:stopscn_i , :read_only ) ; end ;
   sqlcode=-20202
krmicomp: error 6038 signalled during compilation
RMAN-03026: error recovery releasing channel resources
krmkdps: this_db_key=1
krmkdps: this_dbinc_key=2
krmkdps: until_scn=
krmkdps: until_time=
krmkdps: completed_after=
krmkdps: completed_before=
krmkdps: like_pattern=
krmkdps: RA_kindMask=255
krmkdps: all_flag=0
krmqclean: the compiled command tree is:
CMD type=cleanup id=1 status=NOT STARTED

As you can see, the debugging output is voluminous--and the sample included is just one portion of the total output. Nevertheless, the output is often useful for pinpointing which PL/SQL package, procedure, or function was unable to execute successfully.

Testing the Media Management API

On specified platforms, Oracle provides a diagnostic tool called sbttest. This utility performs a simple test of the tape library by acting as the Oracle database server and attempting to communicate with the media manager.

Obtaining the Utility

On UNIX, the sbttest utility is 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 SunSolaris, you do not have to relink when using sbttest. On other platforms, relinking may be necessary.

Obtaining Online Documentation

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]>

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

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.  

non-0 

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, included in your system path, and linked with Oracle by typing sbttest at the command line:

    % sbttest
    
    
    

    If the program is operational, 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, it provides messages describing the failure. For example, if Oracle 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
    

Monitoring RMAN Jobs

Sometimes it is useful to identify what a server session performing a backup or copy operation is doing. You have access to several views that can assist in monitoring the progress of or obtaining information about RMAN jobs:

View  Description 

V$PROCESS 

Identifies currently active processes. 

V$SESSION 

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

V$SESSION_LONGOPS 

Provides progress reports on long-running operations. 

V$SESSION_WAIT 

Lists the events or resources for which sessions are waiting. 

RMAN allows you to perform the following checks:

Correlating Server Sessions with Channels

To identify which server sessions correspond to which RMAN channels, use the set command with the command id parameter. The command id parameter enters the specified string into the CLIENT_INFO column of the V$SESSION dynamic performance view. Join V$SESSION with V$PROCESS to correlate the server session with the channel.

The CLIENT_INFO column of V$SESSION contains information for each Recovery Manager server session. The data appears in one of the following formats:

The SPID column of V$PROCESS identifies the operating system process number.

See Also:

Oracle8i Reference for more information on V$SESSION and V$PROCESS. 

To correlate a process with a channel during a backup:

  1. Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:

    % rman target / catalog rman/rman@rcat
    
    
    
  2. Set the command id parameter after allocating the channels and then back up the desired object. For example, enter:

    run {
         allocate channel t1 type disk;
         allocate channel t2 type disk;
         set command id to 'rman';
         backup 
           incremental level 0
           filesperset 5
           tablespace 'SYSTEM';
         # optionally, issue a host command to access the operating system prompt
         host;
         sql 'ALTER SYSTEM ARCHIVE LOG ALL';
    }
    
    
    
  3. 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:

    SELECT sid, spid, client_info 
    FROM v$process p, v$session s 
    WHERE p.addr = s.paddr 
    AND client_info LIKE '%id=rman%';
    
    SID        SPID      CLIENT_INFO  
    ---------- --------- ----------------------------------------------------------------
    8          21973     id=rman  
    16         22057     id=rman    
    17         22068     id=rman,ch=t1 
    18         22070     id=rman,ch=t2  
    

    See Also:

    "set_run_option" for set command id syntax. 

Monitoring Job Progress

Monitor the progress of backups, copies, and restores by querying the view V$SESSION_LONGOPS.

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

  1. Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:

    % rman target / catalog rman/rman@rcat
    
    
    
  2. Start an RMAN job. For example, enter:

    run {
         allocate channel t1 type disk;
         backup database;
    }
    
    
  3. While the job is running, execute a script 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
    /
    
    
    

    If you repeat the query while the backup 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. Query V$SESSION_WAIT to determine which events are being waited for. For example, enter:

    SQL> SELECT sid, seconds_in_wait AS sec_wait, event FROM v$session_wait
      2  WHERE wait_time = 0
      3  ORDER BY sid;
    
           SID   SEC_WAIT EVENT
    ---------- ---------- -----------------------------------------------
             1  368383335 pmon timer
             2       1097 rdbms ipc message
             3     387928 rdbms ipc message
             4          0 rdbms ipc message
             5       1408 smon timer
             6     386114 rdbms ipc message
             7     387626 rdbms ipc message
             8       1060 SQL*Net message from client
             9       1060 SQL*Net message from client
            12       1060 SQL*Net message from client
            13       2366 SQL*Net message from client
            14       2757 SQL*Net message from client
    12 rows selected.
    


    Note:

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


    See Also:

     

Monitoring Job Performance

Monitor backup and restore performance by querying V$BACKUP_SYNC and V$BACKUP_ASYNC_IO. For a complete description of the contents of these views and how you can use them to tune backup performance, see Oracle8i Designing and Tuning for Performance.

See Also:

Oracle8i Reference for more information on these V$ views. 

Terminating an RMAN Session

You may sometimes need to kill an RMAN job that is hanging. Often, hung jobs occur when RMAN is interfacing with a media manager. The best way to stop RMAN when the connections for the allocated channels are hung in the media manager is to kill the Oracle process of the connections. Be careful when executing this operation because killing the Oracle process may cause problems for the media manager.

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 seem 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 default channel, and the polling connections. Target connections that are not hung in the media manager code also terminate: only the target connection executing in the media management layer remains active. You must manually kill this process because terminating its session does not kill it. Even after termination, the media manager may keep resources busy or continue processing because it does not realize that the Oracle process is gone. This behavior is media manager-dependent.

Terminating the catalog connection does not cause RMAN to finish because RMAN is not performing catalog operations. Removing default channel and polling connections cause 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 above.

Terminating an RMAN Session

The best way to terminate RMAN when the connections for the allocated channels are hung in the media manager is to kill the Oracle process of the connections. 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 identify and terminate an oracle process that is hung in the media manager code:

This procedure is system-specific. See your operating system-specific documentation for the relevant commands.

  1. Obtain the current stack trace for the desired process id using a system-specific utility. For example, on SunSolaris you can use the command pstack located in /usr/proc/bin to obtain the stack.

  2. After the stack is obtained, look for the process with SBTxxxx (normally sbtopen) as one of its top calls. Note that other layers may appear on top of it.

  3. Obtain the stack again after a few minutes. If the same stack trace is returned, then you have identified the hung process.

  4. Kill the hung process using a system-specific utility. For example, on SunSolaris execute a kill -9 command.

  5. Repeat this procedure for all hung channels in the media management code.

  6. Check that the media manager also clears its processes, otherwise the next backup or restore may still hang due to the previous hang. In some media managers, the only solution is too shut down and restart the media manager daemons. If the documentation from the media manager is unhelpful, ask the media manager technical support for the correct solution.

Troubleshooting Scenarios

This section describes the most common problems encountered when using RMAN:

After Linking to the Media Manager on UNIX, RMAN Fails to Back Up to Tape

In this scenario, you link the media manager with Oracle but still cannot make RMAN back up to tape. You see either of these error messages:

# error 1
ORA-19511: SBT error = 4110, errno = 0, BACKUP_DIR environment variable is not set
# error 2
RMAN-008526: channel channel_name: WARNING: Oracle Test Disk API

Diagnosis of the Cause

When you install Oracle8i, the server kernel is linked with a shared library whose name and location differs depending on your operating system. For example, the library on SunSolaris in version 8.1 is called $ORACLE_HOME/lib/libobk.so. This is a symbolic link that points to the so-called dummy API that Oracle links to by default. On SunSolaris, this library is called libdsbtsh8.so.

This dummy shared library allows you to use RMAN to test writing to disk so long as you specify BACKUP_DIR in the parms parameter of the allocate channel command.

Executable  Shared Library 

oracle.exe 

libobk.so -> libdsbtsh8.so 

An SBT error of 4110 for Oracle version 8.1 or an Additional information: message of 4110 for Oracle version 8.0 indicates that Oracle is not linked with the media manager API. Instead, Oracle is linked with Oracle's own dummy API. These errors occur because the BACKUP_DIR environment variable is not specified for the channel servicing the backup. One way to set the BACKUP_DIR location is by using the parms parameter of the allocate channel command.

In Oracle version 8.1, if the RMAN-8526 message states that the disk API was used, then the BACKUP_DIR environment variable was successfully resolved by the Oracle channel and RMAN made the backup using the disk API. If you do not see the 4110 or RMAN-008526 errors, but RMAN is not making backups to the media manager, then follow the procedure below to determine whether Oracle is using the dummy API.

To determine whether Oracle is using the dummy API:

  1. Navigate to $ORACLE_HOME/bin. For example, enter:

    % cd $ORACLE_HOME/bin
    
    
  2. List the dynamic dependencies, that is, the shared objects linked at runtime when you execute Oracle. The command differs depending on your version of UNIX. For example, on Solaris issue:

    % ldd oracle | grep libobk.so
    
    
  3. Examine the output to see whether libobk.so is symbolically linked to libdsbtsh8.so:

    libobk.so  ->  libdsbtsh8.so
    
    

    If so, then Oracle is linking to the dummy API instead of your media management API.

  4. Test further by trying a backup using the dummy API. Note that you must set the parms parameter of the allocate command so that the ENV variable specifies a valid pathname for the BACKUP_DIR destination.

    For example, you can issue:

    run {
         allocate channel c1 type 'sbt_tape'
           parms="ENV=(BACKUP_DIR=/oracle/work)";
         backup tablespace system;
    }
    
    

    If you see RMAN-08526 and RMAN-08525 in the output, then the backup to disk using the dummy API was successful:

    RMAN-08526: channel c1: WARNING: Oracle Test Disk API
    RMAN-08525: backup set complete, elapsed time: 00:00:25
    

Solution

If Oracle is linked to the dummy API instead of your media manager's shared library, then you must tell Oracle to link to the media manager's shared library instead.


Note:

Database backups using the disk API are not supported. 


To relink to your media management API:

  1. Shut down all databases that are using the Oracle executable before removing the old libobk.so link. For example, enter:

    SQL> SHUTDOWN IMMEDIATE
    
    
  2. Delete the old symbolic link for libobk.so:

    % rm $ORACLE_HOME/lib/libok.so
    
    
  3. Create a symbolic link between libobk.so and the shared library that you want to use. For example, on SunSolaris you can create the symbolic link libobk.so to a shared library such as liblsm.so using the ln command:

    % ln  -s  $ORACLE_HOME/lib/libobk.so  $ORACLE_HOME/lib/liblsm.so
    
    
    
  4. Check that the link is successful by using the sbttest test program to back up a file. For example, enter:

    % sbttest  -testfile
    

After Installing the Media Manager on NT, RMAN Fails to Back Up to Tape

In this scenario, you install the media manager on the Windows platform, but cannot make RMAN back up to tape. Instead, RMAN does one or more of the following:

Diagnosis of the Cause

If you specify 'sbt_tape' but RMAN does not use the media management API, then the following scenarios are possible:

To diagnose the cause of the failure:

  1. Examine the RMAN message output to determine if the following message appears:

    RMAN-008526: channel channel_name: WARNING: Oracle Test Disk API
    
    

    If you see this information, then Oracle is linking to the dummy API instead of your media management API. If not, proceed to the next step.

  2. If Oracle is not using the dummy API and the backup fails to write to tape, then the problem is probably in your media manager's library. Contact the support team for your media management product and ask them help diagnose why the DLL cannot be loaded.

Solution

If Oracle is using the dummy API successfully, then it cannot find the media management API in its default directory path. You must configure the system so that Oracle can find the correct API.


Note:

Database backups using the disk API are not supported. 


Follow this procedure:

  1. Shut down the Oracle services using the Services dialogue box. If the services are running when the media manager is installed, the new DLL will not be used until the machine is rebooted or the service is stopped and started again.

  2. On Windows NT, there are two sets of environment variables: the USER and SYSTEM variables. Place orasbt.dll in the SYSTEM path so that the Oracle service can find it.

  3. Restart the Oracle service so that the Oracle executable uses the correct DLL.

Backup Job Is Hanging

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

Recovery Manager: Release 8.1.5.0.0 - Production
RMAN-06005: connected to target database: TORPEDO
RMAN-06008: connected to recovery catalog database
RMAN> run {
2> allocate channel t1 type "SBT_TAPE";
3> backup
4> tablespace system,users; }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: t1
RMAN-08500: channel t1: sid=16 devtype=SBT_TAPE
RMAN-03022: compiling command: backup
RMAN-03023: executing command: backup
RMAN-08008: channel t1: starting datafile backupset
RMAN-08502: set_count=15 set_stamp=338309600
RMAN-08010: channel t1: including datafile 2 in backupset
RMAN-08010: channel t1: including datafile 1 in backupset
RMAN-08011: channel t1: including current controlfile in backupset
# Hanging here for 30 min now

Diagnosis of the Cause

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

Your first task is to try to determine which of these scenarios is the most likely cause.

To determine the cause of the hang:

  1. If you are using a media manager, examine media manager process, log, and trace files for signs of abnormal termination or other errors (see the description of message files in "Identifying Types of Message Output"). If this information is not helpful, proceed to the next step.

  2. Restart RMAN and turn on debugging, making sure to specify a trace file to contain the output. For example, enter:

    % rman target / catalog rman/rman@catdb debug trace = /oracle/log
    
    
  3. Re-execute the job:

    run { 
         allocate channel c1 type 'sbt_tape'; 
         backup tablespace system; 
    }
    
    
  4. Examine the debugging output to determine where RMAN is hanging (see "Interpreting Debugging Output" for tips on reading this output). The output will most likely indicate that the last RPC sent from the client to the server was SYS.DBMS_BACKUP_RESTORE.BACKUPPIECECREATE, which is the call that causes the server to interact with the media manager to write the backup data:

    krmxrpc: xc=6897512 starting longrunning RPC #13 to target: DBMS_BACKUP_RESTORE.
    BACKUPPIECECREATE
    krmxr: xc=6897512 started long running rpc
    
    
    
  5. Check to see what the server processes performing the backup are doing. How many processes are hanging? If only one, check to see what it is doing by querying V$SESSION_WAIT. For example, to determine what process 12 is doing, enter:

         SELECT * FROM v$session_wait WHERE wait_time = 0 AND sid = 12;
    

Solution

Because the causes of a hung backup job can be varied, so are the solutions. The best practice is to look for the simplest solutions first. For example, it is quite common for backup jobs to hang simply because the tape device has completely filled the current cassette and is waiting for a new tape to be inserted.

To learn how to kill an RMAN session that is hanging, see "Terminating an RMAN Session".

RMAN Fails to Start RPC Call

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

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

Diagnosis of Cause

The RMAN-10030 error message does not usually indicate a problem. The RMAN-10030 error indicates one of the following:

Timing problems occur in this way. When RMAN posts a long-term 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 RMAN-10030 error message.

If the RMAN-10036 error message does not appear in the output along with RMAN-10030, then the backup job encountered a problem. For example, sometimes the RMAN-10030 message appears when a backup to tape hangs at the beginning of the job.

To determine the cause of the hung backup:

  1. If a backup to tape stalls at the beginning, issue the following query:

    SELECT * FROM V$SESSION_WAIT
    WHERE compnam = 'dbms_backup_restore';
    
    

    If Oracle returns no information, then the PL/SQL program performing the backup is hung.

  2. Check the media manager to ensure that it did not hang or terminate abnormally. The media manager does not pass all failures back to its libobk client. If the client does not receive the information, then Oracle does not get notified that the backup terminated due to MML problems.

Backup Fails with Invalid RECID Error

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

Diagnosis of Cause

You probably restored a backup control file created through a non-Oracle mechanism, and then opened the database without performing a RESETLOGS operation. If you had created the backup control file through the RMAN backup command or the ALTER DATABASE BACKUP CONTROLFILE statement, then Oracle would have required you to reset the 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 using 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.

Solution

You can follow either of these procedures, although the first procedure is safer and is strongly recommended:

To reset the database using RMAN:

  1. Connect to the target database using SQL*Plus:

    % sqlplus sys/oracle@prod1
    
    
  2. Mount the database if it is not already mounted:

    SQL> ALTER DATABASE MOUNT;
    
    
  3. Start cancel-based recovery using the backup control file, then cancel it:

    SQL> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
    SQL> ALTER DATABASE RECOVER CANCEL;
    
    
  4. Open the database with the RESETLOGS option:

    SQL> ALTER DATABASE OPEN RESETLOGS;
    
    
  5. Use RMAN to connect to the target database and recovery catalog:

    % rman target / rman/rman@rcat
    
    
  6. Issue the RMAN reset database command:

    reset database;
    
    
  7. Take new backups so that you can recover the database if necessary:

    run { 
         allocate channel c1 type disk;
         backup database;
    }
    
To create the control file using SQL*Plus:

  1. Connect to the target database using SQL*Plus:

    % sqlplus sys/oracle@prod1
    
    
  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 trace file looks something like the following:

    *** SESSION ID:(8.1) 1998.12.09.13.26.36.000
    *** 1998.12.09.13.26.36.000
    # The following statements 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 "PROD1" NORESETLOGS ARCHIVELOG
        MAXLOGFILES 32
        MAXLOGMEMBERS 2
        MAXDATAFILES 32
        MAXINSTANCES 1
        MAXLOGHISTORY 1012
    LOGFILE
      GROUP 1 '/oracle/dbs/t1_log1.f'  SIZE 200K,
      GROUP 2 '/oracle/dbs/t1_log2.f'  SIZE 200K
    DATAFILE
      '/oracle/dbs/tbs_01.f',
      '/oracle/dbs/tbs_02.f',
      '/oracle/dbs/tbs_11.f',
      '/oracle/dbs/tbs_12.f',
      '/oracle/dbs/tbs_21.f',
      '/oracle/dbs/tbs_22.f',
     CHARACTER SET WE8DEC
    ;
    # Configure snapshot controlfile filename
    EXECUTE SYS.DBMS_BACKUP_RESTORE.CFILESETSNAPSHOTNAME('/oracle/dbs/snapcf_prod1.f');
    # 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;
    # No tempfile entries found to add.
    
    
  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 ALL;
    ALTER DATABASE OPEN ...;
    


    WARNING:

    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 logs 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 RMAN cannot detect the problem. 


Backup Fails Because of Control File Enqueue

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

RMAN-08502: set_count=11 set_stamp=333299261
RMAN-08010: channel dev1: including datafile 1 in backupset
RMAN-08512: waiting for snapshot controlfile enqueue
RMAN-08512: waiting for snapshot controlfile enqueue
RMAN-20029: cannot make a snapshot controlfile
RMAN-03026: error recovery releasing channel resources
RMAN-08031: released channel: dev1
RMAN-00569: ================error message stack follows================
RMAN-03006: non-retryable error occurred during execution of command: backup

RMAN-07004: unhandled exception during command execution on channel dev1
RMAN-10032: unhandled exception during execution of
job step 1: ORA-06512: at line 90
RMAN-10035: exception raised in RPC: ORA-00230:
operation disallowed: snapshot controlfile enqueue unavailable
ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 1826
RMAN-10031: ORA-230 occurred during call to
DBMS_BACKUP_RESTORE.CFILEMAKEANDUSESNAPSHOT

Diagnosis of Cause

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:

RMAN-08512: 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 retrieves the enqueue. Recovery Manager 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 RMAN-08512: waiting for snapshot controlfile enqueue message, start a new SQL*Plus session on the target database:

    % sqlplus sys/sys_pwd@prod1
    
    
  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: c1  0000210 STARTED  21-JUN-99
    

Solution

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

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

RMAN Fails to Delete All Archived Logs

In this scenario, your database archives automatically to two directories: /arc_dest and arc_dest2. You tell RMAN to perform a backup and delete the input archived redo logs afterwards:

run {
     allocate channel c1 type 'sbt_tape';
     backup database;
     backup archivelog all delete input;
}

You then perform a crosscheck to make sure that the logs are gone and discover the following:

RMAN> change archivelog all crosscheck;

RMAN-03022: compiling command: change
RMAN-06158: validation succeeded for archived log
RMAN-08514: archivelog filename=/oracle/arch/dest2/arcr_1_964.arc recid=19 stamp=368726072

RMAN deleted one set of logs but not the other.

Diagnosis of Cause

This problem is not an error. RMAN deletes only one copy of each input log, so even if you archive to five destinations, RMAN deletes logs from only one directory.

Solution

To force RMAN to delete all existing archived redo logs, allocate multiple channels and specify that each channel back up and delete logs from a different archiving destination. For example, enter:

run { 
     allocate channel t1 type 'sbt_tape'; 
     allocate channel t2 type 'sbt_tape'; 
     backup 
       archivelog like '/oracle/arch/dest1/%' channel t1 delete input
       archivelog like '/oracle/arch/dest2/%' channel t2 delete input; 
} 

Backup Fails Because RMAN Cannot Locate an Archived Log

In this scenario, you schedule regular incremental backups of your database. Because RMAN can use incremental backups instead of archived redo logs to perform recovery, you use an operating system utility to delete all archived logs after each backup. The next time you take a backup, you receive this error:

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

Diagnosis of Cause

This problem occurs when you delete the archived logs using 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 it thinks still exists.

Solution

The easiest solution is to specify the delete input option when backing up archived logs. For example, enter:

run {
     allocate channel c1 type 'sbt_tape';
     backup archivelog all delete input;
}

The second easiest solution is to issue the following command at the RMAN prompt after deleting the logs using an operating system utility:

change archivelog all crosscheck;

If the compatible parameter in the catalog is set to 8.1.5 or lower, RMAN marks all archived logs it cannot located as having the status DELETED. If compatible is set to 8.1.6 or higher, then RMAN removes the records from the repository.

See Also:

"configure" to learn how to set the compatible parameter. 

RMAN Issues Character Set Errors When You Attempt to Connect to the Target

In this scenario, you are running an 8.1.5 version of RMAN and trying to connect to a version 8.0.4 target database. You receive the following error messages when you try to connect to the target database:

% rman catalog rman/rman@rcat 
 
Recovery Manager: Release 8.1.5.0.0 - Production 
RMAN-06008: connected to recovery catalog database 
 
RMAN> connect target sys/oscar123@nc0d 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ==== 
RMAN-00571: =========================================================== 
RMAN-04005: error from target database: ORA-06550: line 1, column 7: 
PLS-00201: identifier 'DBMS_BACKUP_RESTORE.SET_CHARSET' must be declared 
ORA-06550: line 1, column 7: PL/SQL: Statement ignored 
RMAN-04015: error setting target database character set to WE8ISO8859P1

Diagnosis of Cause

Typically, this error message means that the DBMS_BACKUP_RESTORE package was not created during the installation of the database. Here are possible causes:

Solution

If you did not install the PL/SQL option, then install it. If you did install the PL/SQL option, then create the required packages by connecting to SQL*Plus with SYSDBA privileges and running the following scripts:

SQL> @$ORACLE_HOME/rdbms/admin/dbmsbkrs.sql 
SQL> @$ORACLE_HOME/rdbms/admin/prvtbkrs.plb

RMAN Denies Logon to Target Database

Recovery Manager fails with the following errors when attempting to connect to the target database:

% rman
Recovery Manager: Release 8.1.5.0.0 - Production

RMAN> connect target sys/change_on_install@inst1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-04005: error from target database: 
ORA-01017: invalid username/password; logon denied

Diagnosis of Cause

Recovery Manager automatically requests a connection to the target database as SYSDBA. In order to connect to the target database as SYSDBA, you must either:

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

Solution

Either create a password file for the target database or add yourself to the administrator list in your operating system. To learn how to create a password file, see Oracle8i Administrator's Guide.

Database Duplication Fails with RMAN-20240

In this scenario, you attempt to duplicate a database to the same host (although it could also be a remote host) using the duplicate command, but get the following error stack during compilation of the recover command:

RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08060: unable to find archivelog
RMAN-08510: archivelog thread=1 sequence=6

RMAN-03022: compiling command: recover(4)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03012: fatal error during compilation of command
RMAN-03028: fatal error code: 3015
RMAN-03013: command type: Duplicate Db
RMAN-03015: error occurred in stored script Memory Script
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover(4)
RMAN-06038: recovery catalog package detected an error
RMAN-20242: specification does not match any archivelog in the recovery catalog

Diagnosis of Cause

The problem is probably that the backup of the datafiles is not consistent, that is, the following SQL statement was not issued after the datafile backup:

ALTER SYSTEM ARCHIVE LOG CURRENT

Consequently, the duplicate command is attempting to read the online redo logs for the necessary redo records.

Solution

When creating the duplication script, use the set until command to specify a log sequence number for incomplete recovery. For example, to stop recovery at log sequence 5 enter:

run { 
     set until logseq 5 thread 1;
     allocate auxiliary channel dupdb1 type disk; 
     duplicate target database to dupdb;

}

See Also:

"Creating a Non-Current Duplicate Database" for more information about performing incomplete recovery during the duplication operation. 

UNKNOWN Database Name Appears in Recovery Catalog

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       CUR    Reset SCN    Reset Time
------- -------   -------   ------      ---    ----------   ----------
56      57        SKDHRA    4052472287  YES    1            Sep 03 1998 06:45:51  
1       19        UNKNOWN   4141147584  NO     1            Jan 08 1999 14:47:28  
1       2         SKDHRC    4141147584  YES    14602        Jan 15 1999 15:32:57 

Diagnosis of Cause

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

Solution

The UNKNOWN name entry is expected behavior: you should not attempt to remove UNKNOWN entries from the recovery catalog. Also, the backups of this incarnation are not usable--at least with this recovery catalog--so RMAN cannot restore them even if you issue a reset database to incarnation command.


Prev Next
Oracle
Copyright © 1999 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index