Error message stack follows

23 Troubleshooting RMAN Operations

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

Interpreting RMAN Message Output

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

Identifying Types of Message Output

Output that is useful for troubleshooting failed or unresponsive RMAN jobs is located in several different places, as explained in Table 23-1.

Table 23-1 Types of Message Output

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:

A log file specified by LOG on the command line or the SPOOL LOG command

A file created by redirecting RMAN output (for example, in UNIX, using the’ > ‘ operator)

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

You can execute the following PL/SQL to remove all entries from V$RMAN_STATUS :

The preceding function removes all job-related entries. No rows are visible until new backup jobs are shown in V$RMAN_BACKUP_JOB_DETAILS .

The alert subdirectory of the Automatic Diagnostic Repository (ADR) home

Contains a chronological log of errors, initialization parameter settings, and administration operations. Records values for overwritten control file records.

Oracle trace file

The trace subdirectory of the ADR home

Contains detailed output generated by Oracle Database 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.

Third-party media management software

The trace subdirectory of the ADR home

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

Media manager log file

Third-party media management software

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

Contains information about the functioning of the media management device

Recognizing RMAN Error Message Stacks

RMAN reports errors as they occur. If an error is not retrievable, that is, if 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. Example 23-1 shows a syntax error.

Example 23-1 RMAN Syntax Error

Identifying Error Codes

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

Errors prefixed with RMAN-

Errors prefixed with ORA-

Errors preceded by the line Additional information:

Oracle Database Error Messages for explanations of RMAN and ORA error codes

RMAN Error Message Numbers

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

Table 23-2 RMAN Error Message Ranges

Compilation of RESTORE or RECOVER command

Compilation of DUPLICATE command

Low-level keyword analyzer

Interphase errors between PL/SQL and RMAN

Recovery catalog packages

ORA-19511: Media Manager Errors

If a media manager error occurs, ORA-19511 is signaled, and the media manager is expected to provide RMAN a descriptive error. RMAN displays the error passed back to it by the media manager. For example, you might see this:

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 with Oracle Database. The database just passes the message on from the media manager. The cause can be addressed only by the media management vendor.

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:

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 23-3. RMAN again 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 23-3 lists media manager message numbers and their corresponding error text. In the error codes, O/S stands for operating system . The errors marked with an asterisk (*) are internal and should not typically be seen during normal operation.

Table 23-3 Media Manager Error Message Ranges

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

Can’t connect with Media Manager

O/S error for example malloc, fork error

Invalid argument(s) to sbtopen

Invalid file handle or file not open

Invalid flags to sbtclose

Invalid argument(s) to sbtclose

Can’t connect with Media Manager

Invalid file handle or file not open

End of volume reached

Invalid argument(s) to sbtwrite

Invalid file handle or file not open

End of volume reached

Invalid argument(s) to sbtread

Backup file not found

Backup file in use

Can’t connect with Media Manager

Invalid argument(s) to sbtremove

Backup file not found

Can’t connect with Media Manager

Invalid argument(s) to sbtinfo

Invalid argument(s) to sbtinit

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:

Read the messages from the bottom up, because this is the order in which RMAN issues the messages. The last one or two errors displayed in the stack are often the most informative.

When you are using an SBT 1.1 media management layer and you are presented with SBT 1.1 style error messages containing the » Additional information: » numeric error codes, look for the ORA-19511 message that follows for the text of error messages passed back to RMAN by the media manager. These should identify the real failure in the media management layer.

Look for the RMAN-03002 or RMAN-03009 message ( RMAN-03009 is the same as RMAN-03002 but includes the channel ID), immediately following the error banner. These messages indicate which command failed. Syntax errors generate RMAN-00558 .

Identify the basic type of error according to the error range chart in Table 23-2 and then refer to Oracle Database Error Messages for information about the most important messages.

Interpreting RMAN Errors: Example

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

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 user 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:

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

Interpreting SBT 2.0 Media Management Errors: Example

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

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

Interpreting SBT 1.1 Media Management Errors: Example

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

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

Referring to Table 23-3, 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.

The sbtio.log contains information written by the media management software, not Oracle Database. Thus, you must consult your media vendor documentation to interpret the error codes and messages. If no information is written to the sbtio.log , then contact your media manager support to ask whether they are writing error messages in some other location, or whether there are steps you must 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 run 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.

Using V$ Views for RMAN Troubleshooting

When LIST , REPORT , and SHOW do not provide all the information that you need for RMAN operations, some V$ views can provide more details.

Sometimes it is useful to identify exactly what a server session performing a backup and recovery job is doing. The views described in Table 23-4 are useful for obtaining information about RMAN jobs.

Table 23-4 Useful V$ Views for Troubleshooting

Identifies currently active processes

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

Lists the events or resources for which sessions are waiting

You can use the preceding views to perform the following tasks:

Monitoring RMAN Interaction with the Media Manager

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

To obtain the complete list of SBT events, you can use the following query:

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

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

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

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

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

Oracle Database Reference for descriptions of the V$SESSION_WAIT view.

Correlating Server Sessions with RMAN Channels

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

Matching Server Sessions with Channels When One RMAN Session Is Active

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

The following shows sample output:

If you set an ID using the RMAN SET COMMAND ID command instead of using the system-generated default ID, then search for that value in the CLIENT_INFO column instead of ‘rman%’ .

Matching Server Sessions with Channels in Multiple RMAN Sessions

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

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

Obtaining the Channel ID from the RMAN Output

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

To correlate a process with a channel during a backup:

In an active session, run the RMAN job as usual and examine the output to get the sid for the channel. For example, the output may show:

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:

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

Correlating Server Sessions with Channels by Using SET COMMAND ID

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

To correlate a process with a channel during a backup:

In each session, set the COMMAND ID to a different value after allocating the channels and then back up the desired object. For example, enter the following in session 1:

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

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

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

For example, the following shows sample output:

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

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

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

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 Services to obtain the C version of the program. You can compile this version of the program on all UNIX platforms.

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:

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

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

Using the sbttest Utility

Use sbttest to perform a quick test of the media manager.

If sbttest returns 0, then the test ran without error, which means that the media manager is correctly installed and can accept a data stream and return the same data when requested. If sbttest returns a nonzero value, then either the media manager is not installed or it is not configured correctly.

Confirm that the program is installed and included in the system path by typing sbttest at the command line:

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

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 :

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

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:

In some cases, sbttest can work but an RMAN backup does not. The reasons can be the following:

The user who starts sbttest is not the owner of the Oracle Database processes.

If the database server is not linked with the media management library or cannot load it dynamically when needed, then RMAN backups to the media manager fail, but sbttest may still work.

The sbttest program passes all environment parameters from the shell but RMAN does not.

Terminating an RMAN Command

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

The preferred method is to press Control+C (or the equivalent «attention» key combination for your system) in the RMAN interface. This also terminates allocated channels, unless they are suspended in the media management code, as happens when, for example, they are waiting for a tape to be mounted.

You can end the server session corresponding to the RMAN channel by running the SQL ALTER SYSTEM KILL SESSION statement.

You can terminate the server session corresponding to the RMAN channel on the operating system.

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:

The sid and devtype are displayed for each allocated channel. The Oracle Database sid is different from the operating system process ID. You can end 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:

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

This statement has no effect on the session if the session stopped in media manager code.

Terminating the Session at the Operating System Level

Finding and terminating 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. See your operating system-specific documentation for more information.

Terminating an RMAN Session That Is Not Responding in the Media Manager

You may sometimes need to terminate an RMAN job that is not responding in the media manager. The best way to terminate RMAN when the channel connections are not responding in the media manager is to terminate the session in the media manager. If this action does not solve the problem, then on some platforms, such as Linux, you may be able to terminate the Oracle Database processes of the connections. (Terminating the Oracle processes may cause problems with 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:

The RMAN client process itself

The default channel , the initial connection to the target database

One target connection to the target database corresponding to each allocated channel

The catalog connection to the recovery catalog database, if you use a recovery catalog

An auxiliary connection to an auxiliary instance, during DUPLICATE or TSPITR operations

A polling connection to the target database, used for monitoring RMAN command execution on the various allocated channels. By default, RMAN makes one polling connection. RMAN makes additional polling connections if you use different connect strings in the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. One polling connection exists for each distinct connect string used in the ALLOCATE CHANNEL or CONFIGURE CHANNEL command.

Process Behavior During a Suspended Job

RMAN usually stops responding because a channel connection is waiting in the media manager code for a tape resource. The catalog connection and the default channel appear to suspend, 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 terminate the RMAN process itself, then you also terminate the catalog connection, the auxiliary connection, the default channel, and the polling connections. If target and auxiliary connections are suspended but not while executing media manager code, they also terminate. If either the target connection or any of the auxiliary connections are executing in the media management layer, then they do not terminate until the processes are manually terminated at the operating system level.

Not all media managers can detect the termination of the Oracle Database 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 channel is no longer present and then exits. In this case, the connections to the unresponsive channels remain active as described previously.

Terminating an RMAN Session: Basic Steps

After the unresponsive channels in the media manager code are terminated, the RMAN process detects this termination and exits, removing all connections except target connections that are still operative in the media management layer. The warning about the media manager resources still applies in this case.

To terminate an Oracle Database process that is not responding in the media manager:

Query V$SESSION and V$SESSION_WAIT as described in «Using V$ Views for RMAN Troubleshooting». For example, execute the following query:

Examine the SQL output to determine which SBT functions are waiting. For example, the output may be as follows:

Using operating system-level tools appropriate to your platform, end the unresponsive sessions. For example, on Linux execute a kill -9 command:

Some platforms include a command-line utility called orakill that enables you to terminate a specific thread. From a command prompt, run the following command, where sid identifies the database instance to target, and the thread_id is the SPID value from the query in Step 1:

Check that the media manager also clears its processes. If any remain, the next backup or restore operation may freeze again, due to the previous problems in the backup or restore operation. 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.

Your operating system-specific documentation for the relevant commands

Источник

Adblock
detector

3-11. Старт и остановка базы данных в RMAN

Во время выполнения задач резервного копирования и восстановления можно загружать и выгружать базу данных Oracle не выходя из клиента RMAN. Для выполнения этих действий используются аналоги команд SQL*Plus STARTUP и SHUTDOWN.

Старт базы данных

Для старта базы данных используется команда RMAN startup. Так же как и её аналог из SQL*Plus она может использоваться с различными опциями. Если опции не указываются, то команда осуществляет автоматическое монтирование и открытие базы данных:

RMAN> startup;
connected to target database (not started)
Oracle instance started
database mounted
database opened
Total System Global Area     285212672 bytes
Fixed Size                     1261372 bytes
Variable Size                268435652 bytes
Database Buffers              12582912 bytes
Redo Buffers                   2932736 bytes

Использование опций в команде STARTUP из RMAN клиента позволяет сделать процесс восстановления базы данных гибче. В следующем примере можно наблюдать, как происходит восстановление в RMAN по шагам, начиная от старта базы данных в NOMOUNT режиме и заканчивая открытием базы данных с опцией RESETLOGS:

[oracle@alfa ~]$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Nov 8 14:59:16 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database (not started) 
RMAN> startup nomount;
Oracle instance started
Total System Global Area     285212672 bytes
Fixed Size                     1261372 bytes
Variable Size                268435652 bytes
Database Buffers              12582912 bytes
Redo Buffers                   2932736 bytes
RMAN> restore controlfile from autobackup;
Starting restore at 08-NOV-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=155 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111108
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111107
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111106
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111105
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111104
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111103
channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111102
channel ORA_SBT_TAPE_1: no autobackup in 7 days found
recovery area destination: /u01/app/oracle/flash_recovery_area/
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: 
/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2011_11_08/o1_mf_s_766683874_7cl91lo5
_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/u02/oradata/orcl/control01.ctl
output filename=/u02/oradata/orcl/control02.ctl
output filename=/u02/oradata/orcl/control03.ctl
Finished restore at 08-NOV-11
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
released channel: ORA_SBT_TAPE_1
RMAN> recover database;
Starting recover at 08-NOV-11
Starting implicit crosscheck backup at 08-NOV-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 08-NOV-11
Starting implicit crosscheck copy at 08-NOV-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 08-NOV-11
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: 
/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2011_11_08/o1_mf_s_766683874_7cl91lo5
_.bkp
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=156 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
starting media recovery
archive log thread 1 sequence 45 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_45_759tw74z_.arc
archive log thread 1 sequence 46 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_46_759tw8sj_.arc
archive log thread 1 sequence 47 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_47_759twjfk_.arc
archive log thread 1 sequence 48 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_48_759twkrz_.arc
archive log thread 1 sequence 49 is already on disk as file /u02/oradata/orcl/redo03.log
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_45_759tw7
4z_.arc thread=1 sequence=45
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_46_759tw8
sj_.arc thread=1 sequence=46
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_47_759twj
fk_.arc thread=1 sequence=47
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_48_759twk
rz_.arc thread=1 sequence=48
archive log filename=/u02/oradata/orcl/redo03.log thread=1 sequence=49
media recovery complete, elapsed time: 00:00:02
Finished recover at 08-NOV-11
RMAN> alter database open resetlogs;
database opened

Для того чтобы вышеуказанный пример получился, резервная копия, с которой происходит восстановление контрольного файла, должна быть создана с предварительно включенным параметром CONTROLFILE AUTOBACKUP:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

Опцию NOMOUNT команды STARTUP можно так же использовать, если серверный (или инициализационный) файл параметров потерян и требуется его восстановление из резервной копии. Следующий пример демонстрирует этот процесс по шагам.

Для начала, переименуем файл параметров, имитируя его потерю:

[oracle@alfa /]$ cd $ORACLE_HOME/dbs
[oracle@alfa dbs]$ ls spfileorcl.ora
spfileorcl.ora
[oracle@alfa dbs]$ mv spfileorcl.ora spfileorcl.old

Если сейчас попробовать стартовать экземпляр, то он запросит файл параметров:

SQL> startup;
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 
'/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora'

Утерянный файл параметров имеется в резервной копии RMAN, но для того чтобы восстановить его, надо запустить базу данных в NOMOUNT режиме. Поэтому, используем для старта базы данных фиктивный файл параметров.

Перед стартом обязательно устанавливаем идентификатор базы данных, так как мы не подключаемся к каталогу восстановления:

RMAN> set DBID 1265664822;
executing command: SET DBID

Стартуем экземпляр с фиктивным файлом параметров:

RMAN> startup force nomount;
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 
'/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora'
starting Oracle instance without parameter file for retrival of spfile
Oracle instance started
Total System Global Area     159383552 bytes
Fixed Size                     1260648 bytes
Variable Size                 58721176 bytes
Database Buffers              96468992 bytes
Redo Buffers                   2932736 bytes

Попробуем восстановить файл параметров из резервной копии:

RMAN> restore spfile from autobackup;
Starting restore at 11-JAN-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: looking for autobackup on day: 20120111
channel ORA_DISK_1: looking for autobackup on day: 20120110
channel ORA_DISK_1: looking for autobackup on day: 20120109
channel ORA_DISK_1: looking for autobackup on day: 20120108
channel ORA_DISK_1: looking for autobackup on day: 20120107
channel ORA_DISK_1: looking for autobackup on day: 20120106
channel ORA_DISK_1: looking for autobackup on day: 20120105
channel ORA_DISK_1: no autobackup in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 01/11/2012 13:39:14
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece

Восстановление закончилось неудачей. Почему? Чтобы ответить на этот вопрос, вспомним, что экземпляр базы данных запускался с фиктивным файлом параметров. В нём нет указаний на путь к директории флэш-области восстановления, которая содержит резервные копии. RMAN просто не может их найти. Значит, придётся задавать расположение флэш-области вручную. В нашем случае путь к директории флэш-области складывается из значений двух параметров db_recovery_file_dest и db_name, которые можно определить прямо в команде восстановления файла параметров:

RMAN> restore spfile from autobackup 
db_recovery_file_dest='/u01/app/oracle/flash_recovery_area' db_name='orcl';
Starting restore at 11-JAN-12
using channel ORA_DISK_1
recovery area destination: /u01/app/oracle/flash_recovery_area
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: 
/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2012_01_10/o1_mf_s_772211704_7jrby9p9
_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 11-JAN-12

Как видно RMAN нашел резервную копию и восстановил из неё файл параметров. Проверим наличие файла в операционной системе:

[oracle@alfa dbs]$ ls spfileorcl.ora
spfileorcl.ora

Файл параметров действительно присутствует. Теперь можно стартовать базу данных:

RMAN> startup force;
Oracle instance started
database mounted
database opened
Total System Global Area     285212672 bytes
Fixed Size                     1261372 bytes
Variable Size                268435652 bytes
Database Buffers              12582912 bytes
Redo Buffers                   2932736 bytes

Файл параметров восстановлен, и база данных открыта. Причём сделано это всё было только в клиенте RMAN.

Остановка базы данных

Для закрытия базы данных и остановки экземпляра, в клиенте RMAN можно использовать команду SHUTDOWN. Команда поддерживает в синтаксисе те же самые опции, что и её аналог в SQL*Plus. В следующем примере показано, как используя только RMAN клиент, можно остановить базу данных, стартовать её в смонтированном режиме, сделать резервную копию и открыть базу данных для использования:

RMAN> shutdown immediate;
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area     285212672 bytes
Fixed Size                     1261372 bytes
Variable Size                264241348 bytes
Database Buffers              16777216 bytes
Redo Buffers                   2932736 bytes
RMAN> backup database;
Starting backup at 11-JAN-12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u02/oradata/orcl/system01.dbf
input datafile fno=00003 name=/u02/oradata/orcl/sysaux01.dbf
input datafile fno=00002 name=/u02/oradata/orcl/undotbs01.dbf
input datafile fno=00005 name=/u02/oradata/orcl/example01.dbf
input datafile fno=00004 name=/u02/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 11-JAN-12
channel ORA_DISK_1: finished piece 1 at 11-JAN-12
piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_11/o1_mf_nnndf_TAG20120
111T142105_7jtw51on_.bkp tag=TAG20120111T142105 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:14
Finished backup at 11-JAN-12
Starting Control File and SPFILE Autobackup at 11-JAN-12
piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2012_01_11/o1_mf_s_772294711_7
jtw98ss_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 11-JAN-12 
RMAN> alter database open;
database opened

Стоит отметить, что команды STARTUP и SHUTDOWN в клиенте RMAN имеют ограничения. Так, с их помощью нельзя закрыть и стартовать экземпляр каталога восстановления. Данные команды относятся только к целевой базе данных. Поэтому, если всё же потребуется остановить или стартовать экземпляр каталога из клиента RMAN, необходимо подключиться к нему как к целевой базе данных, и только затем использовать команды STARTUP и SHUTDOWN.

3-12. Проверка синтаксиса RMAN команд

В RMAN имеется возможность проверки синтаксиса вводимых команд. Для входа в этот режим необходимо запустить клиента RMAN с аргументом командной строки checksyntax. После этого, можно проверять синтаксис команд, вводя и запуская их в оболочке клиента или подгружая файл скрипта с содержащимися в нём командами. Сами команды исполняться при этом не будут.

Следующий пример демонстрирует проверку синтаксиса единственной команды:

[oracle@alfa ~]$ rman checksyntax
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:33:39 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
RMAN> run {backup database;}
The command has no syntax errors

Как видно из примера, ошибок в синтаксисе этой команды не обнаружено.

Кроме проверки синтаксиса отдельных команд, в RMAN можно проверить синтаксис команд целого скрипта. Для этого надо указать файл скрипта в качестве аргумента командной строки при запуске клиента:

[oracle@alfa ~]$ rman checksyntax @backup1.rman
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:43:42 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
RMAN> run
2> {
3> allocate channel dev1 device type sbt;
4> set backup copies = 2;
5> backup datafiles 
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "archivelog, as, backup, 
backupset, blocks, channel, check, copy, copies, controlfilecopy, cumulative, current, 
database, datafile, datafilecopy, device, diskratio, db_recovery_file_dest, 
db_file_name_convert, duration, filesperset, for, format, full, force, incremental, keep, 
(, maxsetsize, nochecksum, noexclude, nokeep, not, proxy, pool, reuse, recovery, skip, 
spfile, setsize, tablespace, tag, to, validate"
RMAN-01008: the bad identifier was: datafiles
RMAN-01007: at line 5 column 8 file: backup1.rman

В примере мы видим, что в синтаксисе третьей команды скрипта имеется ошибка.

Использование аргумента checksyntax позволяет предотвратить появление грубых ошибок во время выполнения командного скрипта RMAN. Рекомендуется всегда использовать данную проверку, когда скрипт модифицируется.

3-13. Сокрытие паролей при подключении к RMAN

Запуск клиента RMAN часто сопровождается указанием в аргументах командной строки параметров подключения, таких как база данных, имя и пароль пользователя. В результате, в различные логи операционной системы могут попадать данные, которые содержат командную строку запуска RMAN с паролём пользователя в открытом виде. Существует два способа избежать этого. Первый – это указывать в командной строке только имя пользователя. Клиент RMAN сам запросит пароль. Вводимые символы при этом отображаться не будут:

[oracle@alfa ~]$ rman target Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:50:07 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
target database Password: 
connected to target database: ORCL (DBID=1265664822)

Если же требуется выполнить командный скрипт RMAN и при этом необходимо избежать указывания пароля в командной строке, то можно поместить команду подключения CONNECT с именем и паролём пользователя в самое начало файла скрипта. При выполнении такого скрипта RMAN клиент сделает подключение, заменив в выводе имя пользователя и пароль звёздочками:

[oracle@alfa ~]$ rman @backup.rman;
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 14:04:56 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
RMAN> connect target *
2> backup database;
connected to target database: ORCL (DBID=1265664822)
Starting backup at 24-JAN-12
…

В последнем случае стоит ограничить доступ другим пользователям к файлу сценария на уровне операционной системы, так как в нём будет указаны параметры подключения в открытом виде.

3-14. Идентификация серверных сеансов RMAN

Для выполнения задач резервного копирования и восстановления, RMAN образует с целевой базой данных или каталогом восстановления сеансы. Иногда возникают случаи, когда необходимо прервать работу одного из таких сеансов. Ниже на примерах будет показано, как можно идентифицировать такие сеансы в системе, для того чтобы их в дальнейшем можно было уничтожить.

Определение колличества сеансов

Узнать количество сеансов RMAN можно с помощью следующей формулы:

Количество сеансов = C+N+2

где:

• C – количество выделенных каналов;
• N – число опций CONNECT, используемых в командах выделения каналов (если не определено, то равно 1);

Если используется каталог восстановления, всегда имеется, по крайней мере, два сеанса, один к каталогу восстановления, другой по умолчанию к целевой базе данных. Сеанс по умолчанию необходим для того, чтобы выполнить такие задачи, как применение архивных журналов во время процесса восстановления.

Идентификация сеансов

Если RMAN клиент запускается на сервере базы данных (unix), то для того чтобы отобразить список серверных процессов относящихся к сеансам RMAN достаточно выполнить следующую команду:

[oracle@alfa ~]$ ps -ef | grep rman
oracle    3743  2887  4 10:20 pts/1    00:00:00 rman target /

Из примера видно, что был запущен клиент RMAN c идентификатором процесса PID равным 3743. Ищем процессы имеющие идентификаторы родительского процесса PPID равным этому значению:

[oracle@alfa ~]$ ps -ef | grep 3743
oracle    3748  3743  0 10:20 ?        00:00:00 oracleorcl 
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle    3749  3743  0 10:20 ?        00:00:00 oracleorcl 
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

Найденные процессы и будут принадлежать сеансам запущенного клиента RMAN. По их PID можно легко найти идентификаторы (SID, SERIAL#) сеансов и уничтожить их с помощью команды ALTER SYSTEM … KILL SESSION.

Идентификатор сеанса SID так же можно встретить и в выходной информации RMAN:

RMAN> backup database;
Starting backup at 25-JAN-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=145 devtype=DISK

В этом примере мы видим, что для резервного копирования базы данных был применён канал ORA_DISK_1, который использует сеанс с идентификатором SID = 145.

Если клиент RMAN подключается к базе данных удалённо, то определить такие сеансы через команды операционной системы будет затруднительно. В этом случае придётся обращаться к системному представлению V$SESSION и идентифицировать сеансы либо по названию программы клиента, либо по терминалу. В остальном сеансы RMAN не несут никаких отличительных признаков по сравнению с другими сеансами:

SQL> SELECT sid, serial#, username, terminal FROM v$session WHERE program = 
'rman.exe'
 
SID SERIAL# USERNAME TERMINAL
--- ------- -------- --------
146 31      SYS      0500-ASU
158 57      SYS      0500-ASU
 
Выбрано: 2 строки

3-15. Удаление базы данных из клиента RMAN

Если требуется удалить базу данных, то сделать это можно с помощью утилиты SQL*Plus. Но если нет возможности в её использовании, то удаление можно провести и в RMAN клиенте.

Для удаления базы данных, надо:

1. Запустить базу данных в смонтированном эксклюзивном режиме:

   SQL> startup restrict mount exclusive;
   ORACLE instance started.
   Total System Global Area  285212672 bytes
   Fixed Size                  1261372 bytes
   Variable Size             268435652 bytes
   Database Buffers           12582912 bytes
   Redo Buffers                2932736 bytes
   Database mounted.
   SQL> exit 
   

2. Использовать команду DROP для удаления базы:

   RMAN> drop database;
   database name is "ORCL" and DBID is 1290912723
   

3. RMAN потребует подтверждение на удаление. Необходимо ввести YES:

   Do you really want to drop the database (enter YES or NO)? YES
   database dropped
   

Можно использовать ключевое слово noprompt в команде DROP для предотвращения диалога запроса на удаление. Это может пригодиться в случае составления командного скрипта RMAN.

Стандартная команда DROP DATABASE удаляет только файлы данных, файлы онлайн журналов, и контрольные файлы. Но в RMAN эта команда имеет расширенный синтаксис. Используя дополнительные ключевые слова, можно с помощью этой команды дополнительно избавиться и от всех резервных копий сделанных ранее RMAN:

RMAN> drop database including backups;
database name is "ORCL" and DBID is 1301354837
Do you really want to drop all backups and the database (enter YES or NO)? YES
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1       1       1   1   AVAILABLE   DISK        
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_nnndf_TAG20120126T094
438_7l1xlq7k_.bkp
2       2       1   1   AVAILABLE   DISK        
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_ncnnf_TAG20120126T094
438_7l1xnkg7_.bkp
deleted backup piece
backup piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_nnndf_TAG20120
126T094438_7l1xlq7k_.bkp recid=1 stamp=773574279
deleted backup piece
backup piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_ncnnf_TAG20120
126T094438_7l1xnkg7_.bkp recid=2 stamp=773574337
Deleted 2 objects
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
specification does not match any archive log in the recovery catalog
database name is "ORCL" and DBID is 1301354837
database dropped

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.

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

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

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

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"

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'

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

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

Additional information: 7005

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.

% sbttest

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>

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.

Terminating an RMAN Command

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

• The preferred method is to press CTRL+C (or the equivalent «attention» key combination for your system) in the RMAN interface. This will also terminates allocated channels, unless they are hung in the media management code, as happens when, for example, when they are waiting for a tape to be mounted.

• You can kill the server session corresponding to the RMAN channel by running the SQL ALTER SYSTEM KILL SESSION statement.

• You can terminate the server session corresponding to the RMAN channel on the operating system.

channel ch1: sid=15 devtype=SBT_TAPE

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

ALTER SYSTEM KILL SESSION 'sid_in_rman_output,serial#';

RMAN Troubleshooting Scenarios

This section contains these topics:

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

• Backup Job Is Hanging: Scenario

• RMAN Fails to Start RPC Call: Scenario

• Backup Fails with Invalid RECID Error: Scenario

• Backup Fails Because of Control File Enqueue: Scenario

• RMAN Fails to Delete All Archived Logs: Scenario

• Backup Fails Because RMAN Cannot Locate an Archived Log: Scenario

• RMAN Does Not Recognize Character Set Name: Scenario

• RMAN Denies Logon to Target Database: Scenario

• Database Duplication Fails Because of Missing Log: Scenario

• Duplication Fails with Multiple RMAN-06023 Errors: Scenario

• UNKNOWN Database Name Appears in Recovery Catalog: Scenario

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

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

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)';
}

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 control file in backupset
# Hanging here for 30 minutes now

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

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

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

RPC call appears to have failed

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

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 control file enqueue unavailable

waiting for snapshot control file enqueue

BACKUP ARCHIVELOG ALL DELETE INPUT;

CROSSCHECK ARCHIVELOG ALL;

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

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

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

CROSSCHECK ARCHIVELOG ALL;

BACKUP DEVICE TYPE sbt 
  ARCHIVELOG ALL 
  DELETE ALL INPUT;

PLS-00553: character set name is not recognized

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

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

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

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

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

Добрый день. Мне посоветовали использовать RMAN и вот я решил испробовать его в деле. Хорошая вещь конечно но на одном этапе возникла проблема которая никак не решается.
Имя базы — exp. Я прочел много инфы в нете и вот что сделал:
1. Перебил и расширил папку для бэкапов. Было
SQL> show parameter db_recovery_file_dest;

NAME TYPE VALUE
———————————— ———— ——————————
db_recovery_file_dest string C:oracleproduct10.2.0flash_recovery_area
db_recovery_file_dest_size big integer 1G

Далее
SQL> alter system set db_recovery_file_dest=’c:bkp’ SCOPE=BOTH SID=’exp’;

System altered

SQL> alter system set db_recovery_file_dest_size=2G SCOPE=BOTH SID=’exp’;

System altered

Получили:

SQL> show parameter db_recovery_file_dest;

NAME TYPE VALUE
———————————— ———— ——————————
db_recovery_file_dest string c:bkp
db_recovery_file_dest_size big integer 2G

Вроде все хорошо. Далее узнал что есть такая штука как snapshot controlfile и его тоже на всякий случай переделал.
RMAN> configure snapshot controlfile name to ‘c:bkpSNCFEXP.ORA’;

snapshot control file name set to: c:bkpSNCFEXP.ORA
new RMAN configuration parameters are successfully stored

Как видите папка c:bkp будет содержать все бэкапы (кроме архивников)

RMAN> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘c:bkpctl_%F’;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘C:BKPSNCFEXP.ORA’;

Теперь начинаю бэкап. Для этого запускаю свой скрипт:

C:>rman target sys/bak123@exp @’c:bkpfull_backup.txt’

Recovery Manager: Release 10.2.0.1.0 — Production on Tue Sep 27 14:36:27 2011

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: EXP (DBID=2455611900)

RMAN> run {
2> configure controlfile autobackup on;
3> allocate channel c1 device type disk format ‘c:bkp%U’;
4> SQL ‘alter system archive log current’;
5> backup database; #plus archivelog;
6> release channel c1;
7> }
8>
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

allocated channel: c1
channel c1: sid=132 devtype=DISK

sql statement: alter system archive log current

Starting backup at 27-SEP-11
channel c1: starting datafile copy
input datafile fno=00001 name=C:ORACLEPRODUCT10.2.0ORADATAEXPSYSTEM01 .DBF
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-SYSTEM_FNO-1_ANMNJQJJ tag=TAG20110927T143634 recid=273 stamp=762964622
channel c1: datafile copy complete, elapsed time: 00:00:35
channel c1: starting datafile copy
input datafile fno=00003 name=C:ORACLEPRODUCT10.2.0ORADATAEXPSYSAUX01 .DBF
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-SYSAUX_FNO-3_AOMNJQKM tag=TAG20110927T143634 recid=274 stamp=762964671
channel c1: datafile copy complete, elapsed time: 00:00:45
channel c1: starting datafile copy
input datafile fno=00005 name=C:ORACLEPRODUCT10.2.0ORADATAEXPEXAMPLE0 1.DBF
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-EXAMPLE_FNO-5_APMNJQM3 tag=TAG20110927T143634 recid=275 stamp=762964684
channel c1: datafile copy complete, elapsed time: 00:00:15
channel c1: starting datafile copy
input datafile fno=00002 name=C:ORACLEPRODUCT10.2.0ORADATAEXPUNDOTBS0 1.DBF
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-UNDOTBS1_FNO-2_AQMNJQMI tag=TAG20110927T143634 recid=276 stamp=762964696
channel c1: datafile copy complete, elapsed time: 00:00:07
channel c1: starting datafile copy
input datafile fno=00006 name=C:ORACLEPRODUCT10.2.0ORADATAMYINDEXES.DB F
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-MYINDEXES_FNO-6_ARMNJQMP tag=TAG20110927T143634 recid=277 stamp=762964699
channel c1: datafile copy complete, elapsed time: 00:00:03
channel c1: starting datafile copy
input datafile fno=00004 name=C:ORACLEPRODUCT10.2.0ORADATAEXPUSERS01. DBF
output filename=C:BKPDATA_D-EXP_I-2455611900_TS-USERS_FNO-4_ASMNJQMT tag=TAG20110927T143634 recid=278 stamp=762964701
channel c1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 27-SEP-11

Starting Control File and SPFILE Autobackup at 27-SEP-11
piece handle=C:BKPCTL_C-2455611900-20110927-04 comment=NONE
Finished Control File and SPFILE Autobackup at 27-SEP-11

released channel: c1

Recovery Manager complete.

Вроде все прекрасно. Но я знаю что возможно произошла ошибка поэтому на всякий случай проверяю то что вообще-то мало кто делает

RMAN> restore controlfile validate;

Starting restore at 27-SEP-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=134 devtype=DISK

channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece C:BKPCTL_C-2455611900-20110927-04
channel ORA_DISK_1: restored backup piece 1
piece handle=C:BKPCTL_C-2455611900-20110927-04 tag=TAG20110927T143822
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
Finished restore at 27-SEP-11

RMAN>

То есть контрольный бэкап проверен и все с ним в порядке. С радостью начинаю гадить в своей БД )). Я стираю вот тут прошу обратить внимание я полностью стираю папку oradata из C:oracleproduct10.2.0 где у меня хранилась БД. Затем начинаю восстановление:

C:>rman target sys/bak123@exp

Recovery Manager: Release 10.2.0.1.0 — Production on Tue Sep 27 14:45:37 2011

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database (not started)

RMAN> startup nomount

Oracle instance started

Total System Global Area 293601280 bytes

Fixed Size 1248624 bytes
Variable Size 104858256 bytes
Database Buffers 184549376 bytes
Redo Buffers 2945024 bytes

RMAN> restore controlfile;

Starting restore at 27-SEP-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK

RMAN-00571: ================================================== =========
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ================================================== =========
RMAN-03002: failure of restore command at 09/27/2011 14:46:39
RMAN-06563: control file or SPFILE must be restored using FROM AUTOBACKUP

Вот тут уже идет первая гадость потому что по книжке если указан для autobackup в скрипте он должен был сам его найти. Ну да ладно продолжаю:

RMAN> restore controlfile from autobackup;

Starting restore at 27-SEP-11
using channel ORA_DISK_1

recovery area destination: c:bkp
database name (or database unique name) used for search: EXP
channel ORA_DISK_1: no autobackups found in the recovery area
autobackup search outside recovery area not attempted because DBID was not set
RMAN-00571: ================================================== =========
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ================================================== =========
RMAN-03002: failure of restore command at 09/27/2011 14:46:58
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece

RMAN>

Тогда пытаюсь дать ему имя бэкапа контрольного файла

RMAN> restore controlfile from ‘CTL_C-2455611900-20110927-04’;

Starting restore at 27-SEP-11
using channel ORA_DISK_1

RMAN-00571: ================================================== =========
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ================================================== =========
RMAN-03002: failure of restore command at 09/27/2011 14:47:55
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece

Тогда я тыкаю этот файл ему в морду

RMAN> restore controlfile from ‘c:bkpCTL_C-2455611900-20110927-04’;

Starting restore at 27-SEP-11
using channel ORA_DISK_1

channel ORA_DISK_1: restoring control file
RMAN-00571: ================================================== =========
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ================================================== =========
RMAN-03002: failure of restore command at 09/27/2011 14:48:17
ORA-19870: error reading backup piece C:BKPCTL_C-2455611900-20110927-04
ORA-19504: failed to create file «C:ORACLEPRODUCT10.2.0ORADATAEXPCONTROL01.CT L»
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.

RMAN>

Но он даже не видит этот файл! Но ведь RMAN сам проверял файл CTL_C-2455611900-20110927-04 и сам сказал что он в порядке! Вообще какая-то загадка!
Могу сказать две вещи — один раз каким-то боком восстановление прошло нормально но дальше все встало. Второе — если не стирать папку oradata то восстановление проходит нормально. Вообщем я не могу понять что не то с этим бэкапом и просьба помочь найти мне ошибку.