PK C|Joa,mimetypeapplication/epub+zipPKC|JMETA-INF/container.xml PKYuPKC|JOEBPS/rcmsynta2017.htmA SPOOL

SPOOL

Purpose

Use the SPOOL command to direct RMAN output to a log file.

See Also:

RMAN for a description of LOG files

Prerequisites

Execute the SPOOL command at the RMAN prompt.

Syntax

spool::=

Description of GUID-1A0D4E5A-767D-4649-A9EF-300D34118BC0-print.eps follows

Semantics


Syntax ElementDescription

OFF

Turns off spooling.

TO filename

Specifies the name of the log file to which RMAN directs its output. RMAN creates the file if it does not exist, or overwrites the file if it does exist. If the specified file cannot be opened for writing, then RMAN turns SPOOL to OFF and continues execution.

   APPEND

Appends the RMAN output to the end of the existing log.


Example

Example 3-59 Spooling RMAN Output to a File

This example directs RMAN output to standard output for configuration of the default device type, spools output of the SHOW command to log file current_config.log, and then spools output to db_backup.log for the whole database backup:

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
SPOOL LOG TO '/tmp/current_config.log';
SHOW ALL;
SPOOL LOG OFF;
SPOOL LOG TO '/tmp/db_backup.log';
BACKUP DATABASE;
SPOOL LOG OFF;
PK6PKC|JOEBPS/rcviews046.htmd RC_RESTORE_RANGE

RC_RESTORE_RANGE

The RC_RESTORE_RANGE view contains details about the restore range of databases registered in the recovery catalog. Because a database can have multiple restore ranges, this view can contain multiple rows for a single database.

This view corresponds to the V$RESTORE_RANGE view.


ColumnData TypeDescription

DB_KEY

NUMBER

The unique database identifier.

SITE_KEY

NUMBER

The primary key of the database site that is associated with this restore range. Each database in a Data Guard environment has a unique SITE_KEY value. You can use the SITE_KEY in join with the RC_SITE view to obtain the DB_UNIQUE_NAME of the database.

LOW_TIME

DATE

The earliest time to which the database can be restored.

HIGH_TIME

DATE

The latest time to which the database can be restored.

LOW_SCN

NUMBER

The lowest SCN to which the database can be restored.

HIGH_SCN

NUMBER

The highest SCN to which the database can be restored.

LOW_DBINC_KEY

NUMBER

The primary key for the incarnation of the database to which LOW_SCN belongs.

HIGH_DBINC_KEY

NUMBER

The primary key for the incarnation of the database to which HIGH_SCN belongs.


PKU쇠PKC|JOEBPS/rcmsynta016.htm4 DELETE SCRIPT

DELETE SCRIPT

Purpose

Use the DELETE SCRIPT command to delete a local or global stored script from the recovery catalog.

Prerequisites

Execute DELETE SCRIPT only at the RMAN prompt. RMAN must be connected to a recovery catalog and target database. The recovery catalog database must be open.

Usage Notes

A stored script may be local or global. A local script is created for the current target database only, whereas a global script is available for use with any database registered in the recovery catalog.

If GLOBAL is specified, then a global script with this name must exist in the recovery catalog; otherwise, RMAN returns error RMAN-06710. If you do not specify GLOBAL, then RMAN looks for a local stored script with the specified name defined on the current target database. If no such script is defined on the target database, then RMAN checks for a global stored script with this name and deletes it if it exists.

Syntax

deleteScript::=

Description of GUID-09FE425E-38A0-49E1-8462-9F5EF0877C4A-print.eps follows

Semantics


Syntax ElementDescription

GLOBAL

Identifies the script as global.

If you attempt to delete a global script, then RMAN must not be connected to a virtual private catalog. Virtual catalog users cannot modify global scripts, although they can execute them.

See Also: "Usage Notes" for an explanation of the difference between global and local scripts

SCRIPT script_name

Specifies the name of the script to delete. Quotes must be used around the script name when the name contains either spaces or reserved words.


Example

Example 2-79 Deleting a Global Script

This example deletes global script backup_db from the recovery catalog (sample output included):

RMAN> LIST SCRIPT NAMES;
 
List of Stored Scripts in Recovery Catalog
 
 
    Scripts of Target Database PROD
 
       Script Name
       Description
       -----------------------------------------------------------------------
       backup_whole
       backup whole database and archived redo log files
 
 
    Global Scripts
 
 
       Script Name
       Description
       -----------------------------------------------------------------------
       global_backup_db
       back up any database from the recovery catalog, with logs
 
RMAN> DELETE GLOBAL SCRIPT global_backup_db;
 
deleted global script: global_backup_db
 
RMAN> LIST SCRIPT NAMES;
 
List of Stored Scripts in Recovery Catalog
 
 
    Scripts of Target Database PROD
 
       Script Name
       Description
       -----------------------------------------------------------------------
       backup_whole
       backup whole database and archived redo log files
PK~S9 4 PKC|JOEBPS/rcmsynta2010.htmU% REVOKE

REVOKE

Purpose

Use the REVOKE command to revoke recovery catalog privileges previously granted with the GRANT command.

Prerequisites

Execute this command at the RMAN prompt only.

Usage Notes

Assume that a virtual private catalog user is granted the REGISTER DATABASE privilege, which implicitly grants the CATALOG FOR DATABASE privilege for any registered database. This user registers multiple databases. If you REVOKE the REGISTER DATABASE privilege from this user, then this user retains CATALOG FOR DATABASE privileges for the registered databases. The CATALOG privileges include registering and unregistering the specified databases.

To prevent this user from accessing the metadata for any databases or registering additional databases, execute REVOKE ALL PRIVILEGES for this user. To revoke CATALOG privileges for a subset of the databases registered by this user, execute REVOKE CATALOG FOR DATABASE for each database in the subset.

Syntax

revoke::=

Description of GUID-904B8E6E-D67B-4FEE-B5D4-1E998D4E4404-print.eps follows

Semantics


Syntax ElementDescription
CATALOG FOR DATABASE{databasename | integer}

Revokes recovery catalog access for the specified database from the specified user.

You can specify the database by either database name or DBID. If you specify a database name when multiple databases with this name are registered in the recovery catalog, then RMAN returns an error. In this case, specify the database by DBID.

REGISTER DATABASE

Revokes the ability to for the specified user to register new databases in this recovery catalog (see Example 3-40).

ALL PRIVILEGES

Revokes all CATALOG and REGISTER privileges from the specified user.

   FROM userid

Specifies the name of the user from which you are revoking privileges.


Examples

Example 3-40 Revoking Privileges from a Virtual Private Catalog Users

Assume that you connect RMAN to a base recovery catalog as the recovery catalog owner rco. As the base catalog owner, you use the RMAN GRANT command as follows to give bckop2 the ability to register any database in her virtual private catalog, but grant bckop3 access to only a subset of the databases in the data center:

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> GRANT REGISTER DATABASE TO bckop2;
RMAN> GRANT CATALOG FOR DATABASE prod TO bckop3;
RMAN> GRANT CATALOG FOR DATABASE prodb TO bckop3;
RMAN> EXIT;

Later, you want to restrict the privileges for user BCKOP2 so that this user cannot register new databases, so you connect to the base catalog as rco and execute a REVOKE command. BCKOP2 retains catalog privileges on the database that this user registered.

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> REVOKE REGISTER DATABASE FROM bckop2;
PKTZ%U%PKC|JOEBPS/rcviews041.htm" RC_PROXY_COPY_SUMMARY

RC_PROXY_COPY_SUMMARY

RC_PROXY_COPY_SUMMARY contains aggregate information about all available proxy copy backups for databases registered in the recovery catalog.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for this database.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

NUM_COPIES

NUMBER

Number of copies created by all proxy copy operations for this database.

NUM_DISTINCT_COPIES

NUMBER

Number of distinct copies created by all proxy copy operations for this database.

MIN_CHECKPOINT_CHANGE#

NUMBER

Minimum checkpoint SCN among any proxy copies for this database.

MAX_CHECKPOINT_CHANGE#

NUMBER

Maximum checkpoint SCN among any proxy copies for this database.

MIN_CHECKPOINT_TIME

DATE

The oldest checkpoint time among any proxy copies for this database.

MAX_CHECKPOINT_TIME

DATE

The most recent checkpoint time among any proxy copies for this database.

OUTPUT_BYTES

NUMBER

Sum of sizes of all output files generated by proxy copies.

OUTPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.


PKChy ""PKC|JOEBPS/rcmsynta011.htm CONVERT

CONVERT

Purpose

Use the CONVERT command to convert a tablespace, data file, or database to the format of a destination platform in preparation for transport across different platforms.

In Oracle Database 10g and later releases, CONVERT DATAFILE or CONVERT TABLESPACE is required in the following scenarios:

  • Transporting data files between platforms for which the value in V$TRANSPORTABLE_PLATFORM.ENDIAN_FORMAT differs.

  • Transporting tablespaces with undo segments (typically SYSTEM and UNDO tablespaces, but also tablespaces using rollback segments) between platforms, regardless of whether the ENDIAN_FORMAT is the same or different. Typically, the SYSTEM and UNDO tablespaces are converted only when converting the entire database.

  • Performing any required conversion on other platform-specific data files, such as when converting to or from the HP Tru64 operating system.

One use of CONVERT is to transport a tablespace into a database stored in Oracle Automatic Storage Management (Oracle ASM). Native operating system commands such as Linux cp and Windows COPY cannot read from or write to Oracle ASM disk groups.

See Also:

Oracle Database Backup and Recovery User's Guide for a complete discussion of the use of CONVERT DATAFILE, CONVERT TABLESPACE, and CONVERT DATABASE

Prerequisites

The source and destination platforms must be supported by the CONVERT command. Query V$TRANSPORTABLE_PLATFORM to determine the supported platforms. Cross-platform tablespace transport is only supported when both the source and destination platforms are contained in this view.

Both source and destination databases must be running with initialization parameter COMPATIBLE set to 10.0.0 or higher. Note the following compatibility prerequisites:

  • If COMPATIBLE is less than 11.0.0, then read-only tablespaces or existing transported tablespaces must have been made read/write at least once before they can be transported to a different platform. You can open a tablespace read/write and then immediately make it read-only again.

  • If COMPATIBLE is 11.0.0 or higher, then the preceding read/write tablespace restriction does not apply. However, any existing transported tablespaces must have been made read/write with COMPATIBLE set to 10.0 before they were transported.

CONVERT TABLESPACE Prerequisites

You can only use CONVERT TABLESPACE when connected as TARGET to the source database and converting tablespaces on the source platform.

The source database must be mounted or open. The tablespaces to be converted must be read-only at the time of the conversion. The state of the destination database is irrelevant when converting tablespaces on the source database.

CONVERT DATAFILE Prerequisites

You can only use CONVERT DATAFILE when connected as TARGET to the destination database and converting data file copies on the destination platform.

If you run a CONVERT DATAFILE script generated by CONVERT DATABASE ON DESTINATION, then the destination database instance must be started with the NOMOUNT option. If you are not running a CONVERT DATAFILE script generated by CONVERT DATABASE ON DESTINATION, then the destination database can be started, mounted, or open.

The state of the source database is irrelevant when converting data file copies on the destination database. However, if you run a CONVERT DATAFILE script as part of a database conversion on the destination database, and if the script is directly accessing the data files on the source database (for example, through an NFS mount), then the source database must be open read-only.

When converting a tablespace on the destination host, you must use CONVERT DATAFILE rather than CONVERT TABLESPACE because the target database cannot associate the data files with tablespaces during the conversion. After you have converted the data files required for a tablespace, you can transport them into the destination database.

CONVERT DATABASE Prerequisites

You can only use CONVERT DATABASE when connected as TARGET to the source database, which must be opened read-only. The state of the destination database is irrelevant when executing CONVERT DATABASE, even if you run CONVERT DATABASE ON DESTINATION.

Because CONVERT DATABASE uses the same mechanism as CONVERT TABLESPACE and CONVERT DATAFILE to convert the data files, the usage notes and restrictions for tablespaces and data files also apply.

The primary additional prerequisite for CONVERT DATABASE is that the source and target platforms must share the same endian format. For example, you can transport a database from Microsoft Windows to Linux for x86 (both little-endian), or from HP-UX to AIX (both big-endian), but not from Solaris to Linux x86. You can create a new database on a target platform manually, however, and transport individual tablespaces from the source database with CONVERT TABLESPACE or CONVERT DATAFILE.

Even if the endian formats for the source and destination platform are the same, the data files for a transportable database must undergo a conversion on either the source or destination host. Unlike transporting tablespaces across platforms, where conversion is not necessary if the endian formats are the same, transporting an entire database requires that certain types of blocks, such as blocks in undo segments, be converted to ensure compatibility with the destination platform.

Usage Notes

Input files are not altered by CONVERT because the conversion is not performed in place. Instead, RMAN writes converted files to a specified output destination.

Data Type Restrictions

CONVERT does not perform endian conversions of data stored in the following data types:

  • RAW

  • LONG RAW

  • BLOB

  • ANYTYPE/ANYDATA/ANYDATASET

  • User-defined types or Oracle abstract types (such as the ORDImage media type) that contain attributes of any of the above data types

Note:

Although the file locator within the BFILE data type is converted, the external file to which the BFILE points is not converted.

To transport objects between databases that are built on underlying types that store data in a platform-specific format, use the Data Pump Import and Export utilities.

Before Oracle Database 10g, CLOBs in a variable-width character set such as UTF8 were stored in an endian-dependent fixed width format. The CONVERT command does not perform conversions on these CLOBs. Instead, RMAN captures the endian format of each LOB column and propagates it to the target database. Subsequent reads of this data by the SQL layer interpret the data correctly based on either endian format and write it out in an endian-independent way if the tablespace is writeable. CLOBs created in Oracle Database 10g and later releases are stored in character set AL16UTF16, which is platform-independent.

See Also:

Oracle Database Administrator's Guide to learn how to transport tablespaces

Syntax

convert::=

Description of GUID-40AD0E62-A979-44B8-87D2-76CD0AFBCBCA-print.eps follows

(transportOptionList::=, convertOptionList::=)

transportOptionList::=

Description of GUID-F2CBB482-DF3F-46E1-BD57-CAC85EF87B58-print.eps follows

(skipSpec::=)

skipSpec::=

Description of GUID-5CC0E22B-3C55-422D-9A8A-1508AD2D6D3F-print.eps follows

convertOptionList::=

Description of GUID-84A5D6EC-855E-43C0-9016-A535298CE022-print.eps follows

(fileNameConversionSpec::=, formatSpec::=)

formatSpec::=

Description of GUID-6BD330F9-C4D7-4F30-A5E5-35C3446B25A1-print.eps follows

Semantics

convert

This clause specifies the objects to be converted: data files, tablespaces, or database.


Syntax ElementDescription

DATABASE

Converts all the data files of a database to the format of the destination platform and ensures the creation of other required database files.

In a multitenant container database (CDB), converts all the data files in the CDB. You connect to the root to convert the whole CDB. See "Connecting to CDBs and PDBs".

Note: Converting a PDB by connecting to the PDB and then using the CONVERT DATABASE command is not supported.

You use CONVERT DATABASE to transport an entire database from a source platform to a destination platform. The source and destination platforms must have the same endian format.

Depending on the situation, you can use CONVERT DATABASE on either the source or destination platform (see Example 2-66). The following parts of the database are not transported directly:

  • Redo logs and control files from the source database are not transported. RMAN creates new control files and redo logs for the target database during the transport and performs an OPEN RESETLOGS after the new database is created. The control file for the converted database does not contain the RMAN repository from the source database. Backups from the source database are not usable with the converted database.

  • BFILEs are not transported. The CONVERT DATABASE output provides a list of objects that use the BFILE data type, but you must copy the BFILEs manually and fix their locations on the target platform.

  • Data files for locally managed temporary tablespaces are not transported. The temporary tablespaces are re-created at the target platform by running the transport script.

  • External tables and directories are not transported. The CONVERT DATABASE output shows a list of affected objects, but you must redefine these objects on the target platform. See Oracle Database Administrator's Guide for more information on managing external tables and directories.

  • Password files are not transported. If a password file was used with the source database, then the output of CONVERT DATABASE includes a list of all user names and their associated privileges. Create a new password file on the target database with this information. See Oracle Database Administrator's Guide for more information on managing password files.

When using CONVERT DATABASE, RMAN detects the following problems and does not proceed until they are fixed:

  • The database has active or in-doubt transactions.

  • The database has save undo segments.

  • The database COMPATIBILITY setting is below 10.

  • Some tablespaces have not been open read/write when the database COMPATIBILITY setting is 10 or higher.

DATABASE ROOT

In a CDB, converts the data files of the root to the format of the destination platform and ensures the creation of other required database files. Connect to the root as described in "Connecting to CDBs and PDBs" and convert the data files.

See the previous description of the DATABASE parameter for general information about converting databases.

   transportOptionList

Specifies options that control the transport.

See Also: transportOptionList

PLUGGABLE DATABASE pdb_name

This clause is not supported for converting one or more PDBs.

You can use the BACKUP command with the FOR TRANSPORT or TO PLATFORM clause to create backup sets that can be used to transport one or more PDBs.

[convertOptionList] DATAFILE 'filename' convertOptionList

Specifies the name of a data file to be transported into a destination database (see Example 2-64). To transport a data file in a PDB, connect to the PDB as described in "Connecting to CDBs and PDBs".

Note: You cannot convert a tablespace that contains undo segments when connected as TARGET to a PDB.

The CONVERT DATAFILE command is only one part of a multiple-step procedure for transporting data files across platforms. You can transport data files using your live data files with the procedure described in Oracle Database Administrator's Guide or from backups using the procedure described in Oracle Database Backup and Recovery User's Guide. Refer to that document before attempting to transport a tablespace across platforms.

Use FROM PLATFORM in convertOptionList to identify the source platform of the data files to be converted. If you do not specify FROM PLATFORM, then the value defaults to the platform of the destination database, that is, the database to which RMAN is connected as TARGET. The destination platform is, implicitly, the platform of the destination host.

You can use CONVERT DATAFILE without FROM PLATFORM or TO PLATFORM to move data files into and out of ASM (see Example 2-65). In this case, CONVERT DATAFILE creates data files copies that do not belong to the target database. Thus, a LIST DATAFILECOPY command does not display them. The following query shows all converted data files that do not belong to the database:

SELECT NAME 
FROM   V$DATAFILE_COPY
WHERE  CONVERTED_FILE='YES';

The CONVERT DATAFILE syntax supports multiple format names, so that each data file can have a separate format. The DATAFILE syntax supports convertOptionList both immediately following the CONVERT keyword and after each DATAFILE 'filename' clause. However, RMAN generates an error in the following situations:

  • Any option in convertOptionList except FORMAT is specified more than once

  • Any option in convertOptionList except FORMAT is specified in the DATAFILE options list when multiple DATAFILE clauses are specified

TABLESPACE tablespace_name convertOptionList

Specifies the name of a tablespace in the source database that you intend to transport into the destination database on a different platform (see Example 2-63).

To transport a tablespace in a PDB, you must connect to the PDB as described in "Connecting to CDBs and PDBs".

Specify this option to produce data files for the specified tablespaces in the format of a different destination platform. You can then transport the converted files to the destination platform.

When connected to the root in a CDB, refers to tablespaces in the root. Refers to a tablespace in a PDB when connected directly to a PDB. See "Connecting to CDBs and PDBs" for information about connecting to CDBs or PDBs.

You can only use CONVERT TABLESPACE when connected as TARGET to the source database and converting on the source platform. The tablespaces to be converted must be read-only at the time of the conversion. You use CONVERT TABLESPACE when the data files that you intend to convert are known to the database.

Use TO PLATFORM to identify the destination platform of the tablespaces to be converted. If you do not specify TO PLATFORM, then the value defaults to the platform of the database to which RMAN is connected as TARGET. The source platform is, implicitly, the platform of the source host.

The CONVERT TABLESPACE command is only one part of a multiple-step process for transporting tablespaces across platforms. You can transport tablespaces using your live data files with the procedure described in Oracle Database Administrator's Guide or from backups using the procedure described in Oracle Database Backup and Recovery User's Guide. Refer to that document before attempting to transport a tablespace across platforms.

Note: To convert the data files of a tablespace on the source host, use CONVERT TABLESPACE ... TO and identify the tablespace to be converted and the destination platform. Do not convert individual data files on the source platform with CONVERT DATAFILE because RMAN does not verify that data files belong to a read-only tablespace, which means you might convert active data files.

convertOptionList

Specifies options that control the conversion.

See Also: convertOptionList


transportOptionList

This clause specifies options for the data files, tablespaces, or database to be transported.


Syntax ElementDescription
NEW DATABASE database_name

Specifies the DB_NAME for the new database produced by the CONVERT DATABASE command.

ON DESTINATION PLATFORM

Generates a convert script of CONVERT DATAFILE commands (see CONVERT SCRIPT parameter) that you can run on the destination host to create the database.

Note: When this option is specified, CONVERT generates a script but does not generate converted data file copies.

This option is useful for avoiding the overhead of the conversion on the source platform, or in cases in which you do not know the destination platform. For example, you may want to publish a transportable tablespace to be used by recipients with many different target platforms.

When you run CONVERT with the ON DESTINATION PLATFORM option, the source database must be open read-only. However, the script generated by CONVERT ON DESTINATION PLATFORM must be run on a database instance that is started NOMOUNT. If the convert script reads data files from the source database during execution of the CONVERT DATAFILE commands, then the source database must not be open read/write during the execution.

   CONVERT SCRIPT script_name

Specifies the location of the file to contain the convert script generated by CONVERT DATABASE ... ON TARGET PLATFORM.

If not specified, the convert script is not generated.

skipSpec

CONVERT DATABASE skips inaccessible, offline, or read-only data files during the conversion process.

SKIP UNNECESSARY DATAFILES

Converts only data files with undo segments. If converting at the destination platform then the generated CONVERT script only includes data files with undo segments. Data files without undo segments do not need to be converted and can be copied directly from the source database to the destination database. If the command is converting from or to hp Tru64, data files with ASSM segment headers must also be converted.

TRANSPORT SCRIPT script_name

Specifies the location of the file to contain the transport script generated by CONVERT DATABASE. If omitted, the transport script is not generated.


skipSpec

This subclause specifies which files are excluded from the conversion.


Syntax ElementDescription

SKIP

Excludes data files according to the criteria specified by the following keywords.

INACCESSIBLE

Excludes data files that cannot be read due to I/O errors.

A data file is only considered inaccessible if it cannot be read. Some offline data files can still be read because they still exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible.

OFFLINE

Excludes offline data files.

READONLY

Excludes read-only data files.


convertOptionList

This subclause specifies input and output options for the conversion.

You can use either the FORMAT or fileNameConversionSpec arguments to control the names of the output files generated by the CONVERT command. If you do not specify either, then the rules governing the location of the output files equal those governing the output files from a BACKUP AS COPY operation. These rules are described in the backupTypeSpec entry.


Syntax ElementDescription

ALLOW INCONSISTENT

Enables you to create a inconsistent backup of tablespaces that are not in read-only mode. Although the backup is created, you cannot plug in these tablespaces directly into the target database.

Note: You cannot use ALLOW INCONSISTENT for cross-platform database backups.

fileNameConversionSpec

A set of string pairs. Whenever an input file name contains the first half of a pair anywhere in the file name, it is replaced with the second half of the same pair. You can use as many pairs of replacement strings as required. You can use single or double quotation marks.

See Also: "Duplication with Oracle Managed Files" to learn about restrictions related to ASM and Oracle Managed Files

FORMAT formatSpec

Specifies the name template for the output files. See the BACKUP AS COPY command for the format values that are valid here.

If the database to which RMAN is connected as TARGET uses a recovery area, then you must specify the FORMAT clause.

You can use CONVERT ... FORMAT without specifying FROM PLATFORM or TO PLATFORM. If you do not specify platforms, then running CONVERT TABLESPACE on the source database generates data file copies that are not cataloged. If you run CONVERT DATAFILE on the destination database, and if the data file copy uses the same endianess, then the command generates another data file copy.

As shown in Example 2-65, you can use CONVERT DATAFILE ... FORMAT to convert a data file into ASM format. For very large data files, copying data files between hosts consumes a large amount of space. Consider using NFS or disk sharing. You can create a backup on the source host, mount the disk containing the backups on the destination host, and then convert the data file into ASM.

FROM PLATFORM 'platform'

Specifies the name of the source platform. If not specified, the default is the platform of the database to which RMAN is connected as TARGET.

The specified platform must be a platform listed in the PLATFORM_NAME column of V$TRANSPORTABLE_PLATFORM. You must use the exact name of the source or target platform as a parameter to the CONVERT command. The following statement queries supported Linux platforms:

SELECT PLATFORM_NAME, ENDIAN_FORMAT
FROM   V$TRANSPORTABLE_PLATFORM 
WHERE  UPPER(PLATFORM_NAME) LIKE 'LINUX%';

PARALLELISM integer

Specifies the number of channels to be used to perform the operation. If not used, then channels allocated or configured for disk determine the number of channels.

TO PLATFORM 'platform'

Specifies the name of the destination platform. If not specified, the default is the platform of the database to which RMAN is connected as TARGET.

The specified platform must be a platforms listed in the PLATFORM_NAME column of V$TRANSPORTABLE_PLATFORM. You must use the exact name of the source or target platform as a parameter to the CONVERT command. The following SQL statement queries supported Linux platforms:

SELECT PLATFORM_NAME, ENDIAN_FORMAT
FROM   V$TRANSPORTABLE_PLATFORM 
WHERE  UPPER(PLATFORM_NAME) LIKE 'LINUX%';

Examples

Example 2-63 Converting Tablespaces on the Source Platform

Suppose you must convert tablespaces finance and hr in source database prodlin to the platform format of destination database prodsun. The finance tablespace includes data files /disk2/orahome/fin/fin01.dbf and /disk2/orahome/fin/fin02.dbf. The hr tablespace includes data files /disk2/orahome/fin/hr01.dbf and /disk2/orahome/fin/hr02.dbf.

The prodlin database runs on Linux host lin01. You query V$DATABASE and discover that platform name is Linux IA (32-bit) and uses a little-endian format. The prodsun database runs on Solaris host sun01. You query V$TRANSPORTABLE_PLATFORM and discover that the PLATFORM_NAME for the Solaris host is Solaris[tm] OE (64-bit), which uses a big-endian format.

You plan to convert the tablespaces on the source host and store the converted data files in /tmp/transport_to_solaris/ on host lin01. The example assumes that you have set COMPATIBLE is to 10.0 or greater on the source database.

On source host lin01, you start the RMAN client and run the following commands, where SBU is any user with the SYSBACKUP privilege:

CONNECT TARGET "sbu@prodlin AS SYSBACKUP"

target database Password: password
connected to target database: PRODLIN (DBID=39525561)

ALTER TABLESPACE finance READ ONLY;
ALTER TABLESPACE hr READ ONLY;
CONVERT TABLESPACE finance, hr
  TO PLATFORM 'Solaris[tm] OE (64-bit)'
  FORMAT '/tmp/transport_to_solaris/%U';

The result is a set of converted data files in the /tmp/transport_to_solaris/ directory, with data in the right endian-order for the Solaris 64-bit platform.

From this point, you can follow the rest of the general outline for tablespace transport. Use the Data Pump Export utility to create the file of structural information, move the structural information file and the converted data files from /tmp/transport_to_solaris/ to the desired directories on the destination host, and plug the tablespace into the new database with the Data Pump Import utility.

Example 2-64 Converting Data Files on the Destination Platform

This example assumes that you want to convert the finance and hr tablespaces from database prodsun on host sun01 into a format usable by database prodlin on destination host lin01. You temporarily store the unconverted data files in directory /tmp/transport_from_solaris/ on destination host lin01 and perform the conversion with CONVERT DATAFILE. When you transport the data files into the destination database, they are stored in /disk2/orahome/dbs.

The example assumes that you have carried out the following steps in preparation for the tablespace transport:

  • You used the Data Pump Export utility to create the structural information file (named, in our example, expdat.dmp).

  • You made the finance and hr tablespaces read-only on the source database.

  • You used an operating system utility to copy expdat.dmp and the unconverted data files to be transported to the destination host lin01 in the /tmp/transport_from_solaris directory. The data files are stored as:

    • /tmp/transport_from_solaris/fin/fin01.dbf

    • /tmp/transport_from_solaris/fin/fin02.dbf

    • /tmp/transport_from_solaris/hr/hr01.dbf

    • /tmp/transport_from_solaris/hr/hr02.dbf

  • You queried the name for the source platform in V$TRANSPORTABLE_PLATFORM and discovered that the PLATFORM_NAME is Solaris[tm] OE (64-bit).

Note the following considerations when performing the conversion:

  • Identify the data files by file name, not by tablespace name. Until the data files are plugged in, the local instance has no way of knowing the intended tablespace names.

  • The FORMAT argument controls the name and location of the converted data files.

  • When converting on the destination host, you must specify the source platform with the FROM argument. Otherwise, RMAN assumes that the source platform is also the platform of the host performing the conversion.

You start the RMAN client and connect to the destination database prodlin as TARGET. sbu is a user who is granted the SYSBACKUP privilege. The following CONVERT command converts the data files to be transported to the destination host format and deposits the results in /disk2/orahome/dbs:

CONNECT TARGET "sbu@prodlin AS SYSBACKUP"

target database Password: password
connected to target database: PRODLIN (DBID=39525561)

CONVERT DATAFILE
   '/tmp/transport_from_solaris/fin/fin01.dbf',
   '/tmp/transport_from_solaris/fin/fin02.dbf',
   '/tmp/transport_from_solaris/hr/hr01.dbf',
   '/tmp/transport_from_solaris/hr/hr02.dbf'
   DB_FILE_NAME_CONVERT
        '/tmp/transport_from_solaris/fin','/disk2/orahome/dbs/fin',
        '/tmp/transport_from_solaris/hr','/disk2/orahome/dbs/hr'
   FROM PLATFORM 'Solaris[tm] OE (64-bit)';

The result is that the following data files have been converted to the Linux format:

  • /disk2/orahome/dbs/fin/fin01.dbf

  • /disk2/orahome/dbs/fin/fin02.dbf

  • /disk2/orahome/dbs/hr/hr01.dbf

  • /disk2/orahome/dbs/hr/hr02.dbf

From this point, follow the rest of the general outline for tablespace transport. Use Data Pump Import to plug the converted tablespaces into the new database, and make the tablespaces read/write if applicable.

Example 2-65 Copying Data Files to and from ASM with CONVERT DATAFILE

This example illustrates copying data files into ASM from normal storage. The generated files are not considered data file copies that belong to the target database, so LIST DATAFILECOPY does not display them.

Use CONVERT DATAFILE without specifying a source or destination platform. Specify ASM disk group +DATAFILE for the output location, as shown here:

RMAN> CONVERT DATAFILE '/disk1/oracle/dbs/my_tbs_f1.df', 
   '/disk1/oracle/dbs/t_ax1.f'
   FORMAT '+DATAFILE';
 
Starting conversion at 29-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input filename=/disk1/oracle/dbs/t_ax1.f
converted datafile=+DATAFILE/asmv/datafile/sysaux.280.559534477
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16
channel ORA_DISK_1: starting datafile conversion
input filename=/disk1/oracle/dbs/my_tbs_f1.df
converted datafile=+DATAFILE/asmv/datafile/my_tbs.281.559534493
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:04
Finished conversion at 29-MAY-13
 

The following example illustrates copying the data files of a tablespace out of ASM storage to directory /tmp, with uniquely generated file names.

RMAN> CONVERT TABLESPACE tbs_2 FORMAT '/tmp/tbs_2_%U.df';
 
Starting conversion at 03-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=20 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00006 name=+DATAFILE/tbs_21.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-6_11gm2fq9.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00007 name=+DATAFILE/tbs_22.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-7_12gm2fqa.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00019 name=+DATAFILE/tbs_25.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-19_13gm2fqb.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00009 name=+DATAFILE/tbs_23.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-9_14gm2fqc.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00010 name=+DATAFILE/tbs_24.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-10_15gm2fqd.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
Finished conversion at 03-JUN-13

Example 2-66 Transporting a Database to a Different Platform

The arguments to CONVERT DATABASE vary depending on whether you plan to convert the data files on the source or destination platform. For a description of the conversion process on source and destination platforms and extended examples, refer to Oracle Database Backup and Recovery User's Guide. Read that discussion in its entirely before attempting a database conversion.

Assume that you want to transport database prod on a Linux host to a Windows host. You decide to convert the data files on the source host rather than on the destination host. The following example connects RMAN to the PROD database on the Linux host and uses CONVERT DATABASE NEW DATABASE to convert the data files and generate the transport script:

CONNECT TARGET "sbu@lin01 AS SYSBACKUP"

target database Password: password
connected to target database: PROD (DBID=39525561)

CONVERT DATABASE
  NEW DATABASE 'prodwin'
  TRANSPORT SCRIPT '/tmp/convertdb/transportscript'
  TO PLATFORM 'Microsoft Windows IA (32-bit)'
    DB_FILE_NAME_CONVERT '/disk1/oracle/dbs','/tmp/convertdb';

In the following variation, you want to transport a database running on a Linux host to a Windows host, but you want to convert the data files on the destination host rather than the source host. sbu is a user who is granted the SYSBACKUP privilege. The following example connects RMAN to the prod database on the Linux host and executes CONVERT DATABASE ON DESTINATION PLATFORM:

CONNECT TARGET "sbu@lin01 AS SYSBACKUP"

target database Password: password
connected to target database: PROD (DBID=39525561)

CONVERT DATABASE
  ON DESTINATION PLATFORM
  CONVERT SCRIPT '/tmp/convertdb/convertscript.rman'
  TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'
  NEW DATABASE 'prodwin'
  FORMAT '/tmp/convertdb/%U';

The CONVERT DATABASE ON DESTINATION PLATFORM command, which is executed on a Linux database, generates a convert script that can be run on the Windows host to convert the data files to the Windows format. The CONVERT DATABASE command also generates a transport script.

Example 2-67 Transporting a Database to a Different Platform and Storage Type

In this scenario, you have a database prod on a Solaris host named sun01 that you want to move to an AIX host named aix01. The Solaris data files are stored in a non-ASM file system, but you want to store the data files in ASM on the AIX host.

The following example connects to sun01 and runs CONVERT DATABASE to generate the necessary scripts:

CONNECT TARGET "sbu@sun01 AS SYSBACKUP"

target database Password: password
connected to target database: PROD (DBID=39525561)

CONVERT DATABASE
  ON DESTINATION PLATFORM
  CONVERT SCRIPT '/tmp/convert_newdb.rman'
  TRANSPORT SCRIPT '/tmp/transport_newdb.sql'
  NEW DATABASE 'prodaix'
  DB_FILE_NAME_CONVERT '/u01/oradata/DBUA/datafile','+DATA';

The convert script contains statements of the following form, where your_source_platform stands for your source platform:

CONVERT DATAFILE '/u01/oradata/DBUA/datafile/o1_mf_system_2lg3905p_.dbf'
  FROM PLATFORM 'your_source_platform'
  FORMAT '+DATA/o1_mf_system_2lg3905p_.dbf';

To reduce downtime for the conversion, you can use NFS rather than copying data files over the network or restoring a backup. For example, you could mount the Solaris files system on the AIX host as /net/solaris/oradata. In this case, you would edit the convert script to reference the NFS-mounted directory as the location of the source data files to convert, putting the commands into the following form:

CONVERT DATAFILE '/net/solaris/oradata/DBUA/datafile/o1_mf_system_2lg3905p_.dbf'
  FROM PLATFORM 'your_source_platform'
  FORMAT '+DATA/o1_mf_system_2lg3905p_.dbf';

You then connect RMAN to the destination database instance, in this case the instance on host aix01, and convert the data files. During the conversion, the database at host sun01 remains in open read only mode. Afterward, you connect SQL*Plus to the database instance on aix01 and run the transport script to create the database.

PKPKC|JOEBPS/rcmsubcl009.htmE forDbUniqueNameOption

forDbUniqueNameOption

Purpose

Use the forDbUniqueNameOption subclause to specify either all databases or a specific database in a Data Guard environment.

Usage Notes

The DBID for a primary database is identical to the DBID of its associated physical standby databases. A database is uniquely identified in the recovery catalog by a DBID and the value of its DB_UNIQUE_NAME initialization parameter.

When you specify forDbUniqueNameOption for any command, RMAN restricts its operations to the objects that are associated exclusively with the database with the specified DB_UNIQUE_NAME. For example, if you use this option with the LIST command, then RMAN lists only the objects associated exclusively with the database with the specified DB_UNIQUE_NAME. Objects that are not associated with any database (SITE_KEY column in the recovery catalog view is null) are not listed.

Syntax

forDbUniqueNameOption::=

Description of GUID-ACC77609-7337-45BC-ABC0-CA0FA570E3D7-print.eps follows

Semantics


Syntax ElementDescription

FOR DB_UNIQUE_NAME ALL

Specifies all primary and standby databases in the recovery catalog that share the DBID of the target database (or DBID specified by the SET DBID command).

FOR DB_UNIQUE_NAME db_unique_name

Specifies the primary or standby database in the recovery catalog with the specified db_unique_name.


Examples

Example 4-19 Listing Expired Backups Associated with a Standby Database

This example connects to a recovery catalog and sets the DBID for the Data Guard environment. All primary and standby databases in this environment share the same DBID. The LIST command lists all expired backups associated with database standby1:

RMAN> CONNECT CATALOG rco@catdb;

recovery catalog database Password: password
connected to recovery catalog database

RMAN> SET DBID 3257174182;
RMAN> LIST EXPIRED BACKUP FOR DB_UNIQUE_NAME standby1;
PKohPKC|JOEBPS/rcmsubcl007.htm$ deviceSpecifier

deviceSpecifier

Purpose

Use the deviceSpecifier subclause to specify the type of storage for a backup.

Syntax

deviceSpecifier::=

Description of GUID-80DADCD3-D920-4E01-8DDA-52FC97761723-print.eps follows

Semantics


Syntax ElementDescription

DISK

Specifies a disk storage device (see Example 4-16).

media_device

Specifies a sequential I/O device or access method for storage (see Example 4-15).

The media_device variable specifies a case-insensitive name for a media manager. The syntax and semantics of sequential I/O device types are platform-specific. The most common value is sbt or sbt_tape (which are synonymous values).

Note: RMAN stores the value sbt in the recovery catalog as sbt_tape for backward compatibility.


Examples

Example 4-15 Allocating a Tape Channel

This example allocates a maintenance channel for a media management device:

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
RELEASE CHANNEL;

Example 4-16 Backing Up the Database to Disk

This example backs up the database to disk:

BACKUP DEVICE TYPE DISK DATABASE;
PK PKC|JOEBPS/rcviews033.htm) RC_OFFLINE_RANGE

RC_OFFLINE_RANGE

This view lists the offline ranges for data files. It corresponds to the V$OFFLINE_RANGE view.

An offline range is created for a data file when its tablespace is first altered to be offline normal or read-only, and then subsequently altered to be online or read/write. No offline range is created if the data file itself is altered to be offline or if the tablespace is altered to be offline immediate.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for the target database. Use this column to join with almost any other catalog view.

DBINC_KEY

NUMBER

The primary key for the incarnation of the target database. Use this column to join with RC_DATABASE_INCARNATION.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

RECID

NUMBER

The record identifier for the offline range from V$OFFLINE_RANGE. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

STAMP

NUMBER

The stamp for the offline range from V$OFFLINE_RANGE. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

FILE#

NUMBER

The absolute file number of the data file.

CREATION_CHANGE#

NUMBER

The SCN at data file creation.

OFFLINE_CHANGE#

NUMBER

The SCN taken when the data file was taken offline.

ONLINE_CHANGE#

NUMBER

The online checkpoint SCN.

ONLINE_TIME

DATE

The online checkpoint time.

CF_CREATE_TIME

DATE

The time of control file creation.

RESETLOGS_CHANGE#

NUMBER

The SCN of the most recent RESETLOGS in the data file header.

RESETLOGS_TIME

DATE

The time corresponding to RESETLOGS_CHANGE#.

OFFR_KEY

NUMBER


PK]3))PKC|JOEBPS/rcviews034.htm| RC_PDBS

RC_PDBS

This view provides information about the pluggable databases (PDBs) registered in the recovery catalog. It corresponds to the V$PDBS view.


ColumnData TypeDescription

PDB_KEY

NUMBER

The primary key for this PDB in the recovery catalog.

DB_KEY

NUMBER

The primary key for the multitenant container database (CDB) in the recovery catalog. Use this column to join with almost any other catalog view.

NAME

VARCHAR2

Name of the PDB.

CON_ID

NUMBER

Unique identifier of the CDB.

DBID

NUMBER

Unique identifier of the PDB.

CREATION_CHANGE#

NUMBER

SCN at which the PDB was created.


PK||PKC|JOEBPS/rcmsynta2019.htm!H SQL (Quoted)

SQL (Quoted)

Purpose

The SQL command executes a SQL statement or a PL/SQL stored procedure from within RMAN. This syntax is available for compatibility with Oracle Database Release 11.2 and earlier, but for ease of use, refer to SQL.

Prerequisites

None.

Syntax

quotedsqlcommand::=

Description of GUID-35B88509-AC00-4485-A1C9-224DB7316828-print.eps follows

Semantics


Syntax ElementDescription

CHANNEL channel_id

Specifies the case-sensitive name of a channel to use when executing an RMAN command within a RUN command.

The channel must first be allocated by ALLOCATE CHANNEL in this RUN command. If you do not set this parameter, then RMAN uses the default channel.

'command'

Specifies a SQL statement for execution (see Example 3-63). SELECT statements are not permitted.

You must use duplicate single quotes to insert a single quote into a quoted string when the quoted string uses the same style of quoting. For example, if the string that RMAN passes to SQL contains a file name, then the file name must be enclosed in duplicate single quotes and the entire string following the SQL keyword must be enclosed in double quotes (see Example 3-64).

Note: Because EXECUTE is a SQL*Plus command, you cannot execute a PL/SQL program unit by specifying EXECUTE within the RMAN SQL command. Instead, you must use the BEGIN and END keywords. For example, to execute the PL/SQL procedure rman.rman_purge with the SQL command, issue the following command:

SQL 'BEGIN rman.rman_purge; END;';

Examples

Example 3-63 Archiving the Unarchived Online Logs

This example backs up a tablespace and then archives all unarchived online redo logs.

BACKUP TABLESPACE users;
sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';

Example 3-64 Specifying a File Name Within a Quoted String

This example specifies a file name by using duplicate single quotes within a double-quoted string.

sql 'ALTER TABLESPACE users ADD DATAFILE ''/disk1/oradata/users02.dbf'' 
  SIZE 100K AUTOEXTEND ON NEXT 10K MAXSIZE 100K';
PKF诼!!PKC|JOEBPS/rcviews048.htmL2 RC_RMAN_BACKUP_JOB_DETAILS

RC_RMAN_BACKUP_JOB_DETAILS

RC_RMAN_BACKUP_JOB_DETAILS provides detailed information on RMAN backup jobs. An RMAN job is the set of commands executed within an RMAN session. An RMAN backup job is the set of BACKUP commands executed in one RMAN job. For example, a BACKUP DATABASE and BACKUP ARCHIVELOG ALL command executed in the same RMAN job compose a single RMAN backup job.

This view contains one row for each RMAN session, even if multiple BACKUP commands are executed in the same session. The SESSION_KEY column is the unique key for the RMAN session in which the backup job occurred. Details for operations performed during an RMAN session are available in the RC_RMAN_BACKUP_SUBJOB_DETAILS view.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for this database.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

SESSION_KEY

NUMBER

Identifier for the RMAN session. Use in joins with RC_RMAN_OUTPUT and RC_RMAN_BACKUP_JOB_DETAILS.

SESSION_RECID

NUMBER

With SESSION_KEY and SESSION_STAMP, used to uniquely identify job's output from RC_RMAN_OUTPUT

SESSION_STAMP

NUMBER

With SESSION_RECID and SESSION_KEY, used to uniquely identify job's output from RC_RMAN_OUTPUT

COMMAND_ID

VARCHAR2(33)

Either a user-specified value set using SET COMMAND ID, or an RMAN-generated unique command id.

START_TIME

DATE

Start time of the first backup command in the RMAN job.

END_TIME

DATE

End time of the last backup command in the RMAN job.

INPUT_BYTES

NUMBER

Sum of sizes of all input files backed up during this RMAN job.

OUTPUT_BYTES

NUMBER

Sum of sizes of all output backup pieces generated by this RMAN job.

STATUS_WEIGHT

NUMBER

Used internally by Enterprise Manager.

OPTIMIZED_WEIGHT

NUMBER

Used internally by Enterprise Manager.

INPUT_TYPE_WEIGHT

NUMBER

Used internally by Enterprise Manager.

OUTPUT_DEVICE_TYPE

VARCHAR2(17)

DISK, SBT_TAPE, or *. An asterisk indicates a backup job that wrote its output to multiple device types.

AUTOBACKUP_COUNT

NUMBER

Number of autobackups performed by this RMAN job.

BACKED_BY_OSB

VARCHAR2(3)

Indicates whether the backup piece is backed up to Oracle Secure Backup (YES) or not (NO).

AUTOBACKUP_DONE

VARCHAR2(3)

YES or NO, depending upon whether a control file autobackup was done as part of this backup job.

STATUS

VARCHAR2(23)

One of the following values: RUNNING,RUNNING WITH WARNINGS, RUNNING WITH ERRORS, COMPLETED, COMPLETED WITH WARNINGS, COMPLETED WITH ERRORS, FAILED.

A failed job does not mean that no backup sets were created. It is possible that the job failed after RMAN created some backup sets. Thus, the RC_BACKUP_SET_DETAILS view may contain rows describing backup sets created successfully by the backup job. You can join this view with RC_BACKUP_SET_DETAILS to obtain more information about the failed backup job.

INPUT_TYPE

VARCHAR2(13)

Contains a value indicating the type of input for this backup. For possible values, see the RC_RMAN_BACKUP_TYPE view.

If a job includes backups corresponding to multiple values, then multiple rows appear in the view, corresponding to the different INPUT_TYPE values for each type of input, with corresponding values for the INPUT_BYTES, OUTPUT_BYTES, INPUT_BYTES_DISPLAY, OUTPUT_BYTES_DISPLAY fields.

OPTIMIZED

VARCHAR2(3)

YES or NO, depending on whether backup optimization was applied.

ELAPSED_SECONDS

NUMBER

Number of seconds elapsed during execution of this backup job.

COMPRESSION_RATIO

NUMBER

Compression ratio for this backup.

INPUT_BYTES_PER_SEC

NUMBER

Input read rate, in bytes/second.

OUTPUT_BYTES_PER_SEC

NUMBER

Output write rate, in bytes/second.

INPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as INPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.

OUTPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.

INPUT_BYTES_PER_SEC_DISPLAY

VARCHAR2(32K)

Same value as INPUT_BYTES_PER_SEC, but converted to a user-displayable format, for example, 798.01M or 5.25G.

OUTPUT_BYTES_PER_SEC_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES_PER_SEC, but converted to a user-displayable format, for example, 798.01M or 5.25G.

TIME_TAKEN_DISPLAY

VARCHAR2(32K)

Total time for the RMAN job, converted to a user-displayable format, such as hh:mm:ss.


PK[LLPKC|J OEBPS/toc.htm]P Table of Contents

Contents

Preface

Changes in This Release for Backup and Recovery Reference

1 About RMAN Commands

2 RMAN Commands: @ (at sign) to QUIT

3 RMAN Commands: RECOVER to VALIDATE

4 RMAN Subclauses

5 Recovery Catalog Views

A RMAN Reserved Words

B Deprecated RMAN Syntax

C RMAN Compatibility

D Oracle Database Cloud Backup Module

E Oracle Secure Backup (OSB) Cloud Module

Index

PK0 bP]PPKC|JOEBPS/css/root-page.css_/** * CSS Stylesheet for Root page of generated HTML. * * Copyright (c) 2010 DITA for Publishers * * May be used without restriction. */ iframe, nav { overflow-y: scroll; } header { display: block; width: 100%; height: 50px; color: #444; background-color: #F6F6F6; } nav, .static-toc { display: block; float: left; width: 20%; height: 900px; color: #CCC; background-color: #F0F0F0; } .static-toc { display: none; } .publication-title { font-family: verdana, helvetica, sans-serif; font-size: 10pt; text-align: center; } .contentwin { display: block; width: 80%; height: 900px; } PK8HlԥPKC|JOEBPS/css/reset-html5.css/* style.css contains a reset, font normalization and some base styles. credit is left where credit is due. additionally, much inspiration was taken from these projects: yui.yahooapis.com/2.8.1/build/base/base.css camendesign.com/design/ praegnanz.de/weblog/htmlcssjs-kickstart */ /* html5doctor.com Reset Stylesheet (Eric Meyer's Reset Reloaded + HTML5 baseline) v1.4 2009-07-27 | Authors: Eric Meyer & Richard Clark html5doctor.com/html-5-reset-stylesheet/ */ html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, figure, footer, header, hgroup, menu, nav, section, menu, time, mark, audio, video { margin:0; padding:0; border:0; outline:0; font-size:100%; vertical-align:baseline; background:transparent; } article, aside, figure, footer, header, hgroup, nav, section { display:block; } nav ul { list-style:none; } blockquote, q { quotes:none; } blockquote:before, blockquote:after, q:before, q:after { content:''; content:none; } a { margin:0; padding:0; font-size:100%; vertical-align:baseline; background:transparent; } ins { background-color:#ff9; color:#000; text-decoration:none; } mark { background-color:#ff9; color:#000; font-style:italic; font-weight:bold; } del { text-decoration: line-through; } abbr[title], dfn[title] { border-bottom:1px dotted #000; cursor:help; } /* tables still need cellspacing="0" in the markup */ table { border-collapse:collapse; border-spacing:0; } hr { display:block; height:1px; border:0; border-top:1px solid #ccc; margin:1em 0; padding:0; } input, select { vertical-align:middle; } /* END RESET CSS */ /* fonts.css from the YUI Library: developer.yahoo.com/yui/ Please refer to developer.yahoo.com/yui/fonts/ for font sizing percentages There are three custom edits: * remove arial, helvetica from explicit font stack * make the line-height relative and unit-less * remove the pre, code styles */ body { font:13px sans-serif; *font-size:small; *font:x-small; line-height:1.22; } table { font-size:inherit; font:100%; } select, input, textarea { font:99% sans-serif; } /* normalize monospace sizing * en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Teletype_style_fix_for_Chrome */ pre, code, kbd, samp { font-family: monospace, sans-serif; } /* * minimal base styles */ /* #444 looks better than black: twitter.com/H_FJ/statuses/11800719859 */ body, select, input, textarea { color:#444; } /* Headers (h1,h2,etc) have no default font-size or margin, you'll want to define those yourself. */ /* www.aestheticallyloyal.com/public/optimize-legibility/ */ h1,h2,h3,h4,h5,h6 { font-weight: bold; text-rendering: optimizeLegibility; } /* maxvoltar.com/archive/-webkit-font-smoothing */ html { -webkit-font-smoothing: antialiased; } /* Accessible focus treatment: people.opera.com/patrickl/experiments/keyboard/test */ a:hover, a:active { outline: none; } a, a:active, a:visited { /*color:#607890;*/ /* WEK: Make TOC entries consistently dark. */ color: #444; } a:hover { color:#036; } ul { margin-left:30px; } ol { margin-left:30px; list-style-type: decimal; } small { font-size:85%; } strong, th { font-weight: bold; } td, td img { vertical-align:top; } sub { vertical-align: sub; font-size: smaller; } sup { vertical-align: super; font-size: smaller; } pre { padding: 15px; /* www.pathf.com/blogs/2008/05/formatting-quoted-code-in-blog-posts-css21-white-space-pre-wrap/ */ white-space: pre; /* CSS2 */ white-space: pre-wrap; /* CSS 2.1 */ white-space: pre-line; /* CSS 3 (and 2.1 as well, actually) */ word-wrap: break-word; /* IE */ } /* align checkboxes, radios, text inputs with their label by: Thierry Koblentz tjkdesign.com/ez-css/css/base.css */ input[type="radio"] { vertical-align: text-bottom; } input[type="checkbox"] { vertical-align: bottom; *vertical-align: baseline; } .ie6 input { vertical-align: text-bottom; } /* hand cursor on clickable input elements */ label, input[type=button], input[type=submit], button { cursor: pointer; } /* These selection declarations have to be separate. No text-shadow: twitter.com/miketaylr/status/12228805301 Also: hot pink. */ ::-moz-selection{ background: #FF5E99; color:#fff; text-shadow: none; } ::selection { background:#FF5E99; color:#fff; text-shadow: none; } /* j.mp/webkit-tap-highlight-color */ a:link { -webkit-tap-highlight-color: #FF5E99; } /* always force a scrollbar in non-IE */ html { overflow-y: scroll; } /* make buttons play nice in IE: www.viget.com/inspire/styling-the-button-element-in-internet-explorer/ */ button { width: auto; overflow: visible; } /* bicubic resizing for non-native sized IMG: code.flickr.com/blog/2008/11/12/on-ui-quality-the-little-things-client-side-image-resizing/ */ .ie7 img { -ms-interpolation-mode: bicubic; } /* * Non-semantic helper classes */ /* for image replacement */ .ir { display:block; text-indent:-999em; overflow:hidden; background-repeat: no-repeat; } /* Hide for both screenreaders and browsers css-discuss.incutio.com/wiki/Screenreader_Visibility */ .hidden { display:none; visibility:hidden; } /* Hide only visually, but have it available for screenreaders www.webaim.org/techniques/css/invisiblecontent/ Solution from: j.mp/visuallyhidden - Thanks Jonathan Neal! */ .visuallyhidden { position:absolute !important; clip: rect(1px 1px 1px 1px); /* IE6, IE7 */ clip: rect(1px, 1px, 1px, 1px); } /* Hide visually and from screenreaders, but maintain layout */ .invisible { visibility: hidden; } /* >> The Magnificent CLEARFIX << */ .clearfix:after { content: "."; display: block; height: 0; clear: both; visibility: hidden; } .clearfix { display: inline-block; } * html .clearfix { height: 1%; } /* Hides from IE-mac \*/ .clearfix { display: block; } /* Primary Styles Author: */ /* * print styles * inlined to avoid required HTTP connection www.phpied.com/delay-loading-your-print-css/ */ @media print { * { background: transparent !important; color: #444 !important; text-shadow: none; } a, a:visited { color: #444 !important; text-decoration: underline; } a:after { content: " (" attr(href) ")"; } abbr:after { content: " (" attr(title) ")"; } .ir a:after { content: ""; } /* Don't show links for images */ pre, blockquote { border: 1px solid #999; page-break-inside: avoid; } img { page-break-inside: avoid; } @page { margin: 0.5cm; } p, h2, h3 { orphans: 3; widows: 3; } h2, h3{ page-break-after: avoid; } } /* * Media queries for responsive design */ @media all and (orientation:portrait) { /* Style adjustments for portrait mode goes here */ } @media all and (orientation:landscape) { /* Style adjustments for landscape mode goes here */ } /* Grade-A Mobile Browsers (Opera Mobile, iPhone Safari, Android Chrome) Consider this: www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ */ @media screen and (max-device-width: 480px) { /* Prevent iOS, WinMobile from adjusting font size */ html { -webkit-text-size-adjust:none; -ms-text-size-adjust:none; } } PKCPKC|JOEBPS/css/commonrtl.css/* | This file is part of the DITA Open Toolkit project hosted on | Sourceforge.net. See the accompanying license.txt file for | applicable licenses. */ /* | (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved. */ .unresolved { background-color: skyblue; } .noTemplate { background-color: yellow; } .base { background-color: #ffffff; } /* Add space for top level topics */ .nested0 { margin-top : 1em;} /* div with class=p is used for paragraphs that contain blocks, to keep the XHTML valid */ .p {margin-top: 1em} /* Default of italics to set apart figure captions */ .figcap { font-style: italic } .figdesc { font-style: normal } /* Use @frame to create frames on figures */ .figborder { border-style: solid; padding-left : 3px; border-width : 2px; padding-right : 3px; margin-top: 1em; border-color : Silver;} .figsides { border-left : 2px solid; padding-left : 3px; border-right : 2px solid; padding-right : 3px; margin-top: 1em; border-color : Silver;} .figtop { border-top : 2px solid; margin-top: 1em; border-color : Silver;} .figbottom { border-bottom : 2px solid; border-color : Silver;} .figtopbot { border-top : 2px solid; border-bottom : 2px solid; margin-top: 1em; border-color : Silver;} /* Most link groups are created with
. Ensure they have space before and after. */ .ullinks { list-style-type: none } .ulchildlink { margin-top: 1em; margin-bottom: 1em } .olchildlink { margin-top: 1em; margin-bottom: 1em } .linklist { margin-top: 1em; margin-bottom: 1em } .linklistwithchild { margin-top: 1em; margin-right: 1.5em; margin-bottom: 1em } .sublinklist { margin-top: 1em; margin-right: 1.5em; margin-bottom: 1em } .relconcepts { margin-top: 1em; margin-bottom: 1em } .reltasks { margin-top: 1em; margin-bottom: 1em } .relref { margin-top: 1em; margin-bottom: 1em } .relinfo { margin-top: 1em; margin-bottom: 1em } .breadcrumb { font-size : smaller; margin-bottom: 1em } dt.prereq { margin-right : 20px;} /* Set heading sizes, getting smaller for deeper nesting */ .topictitle1 { margin-top: 0pc; margin-bottom: .1em; font-size: 1.34em; } .topictitle2 { margin-top: 1pc; margin-bottom: .45em; font-size: 1.17em; } .topictitle3 { margin-top: 1pc; margin-bottom: .17em; font-size: 1.17em; font-weight: bold; } .topictitle4 { margin-top: .83em; font-size: 1.17em; font-weight: bold; } .topictitle5 { font-size: 1.17em; font-weight: bold; } .topictitle6 { font-size: 1.17em; font-style: italic; } .sectiontitle { margin-top: 1em; margin-bottom: 0em; color: black; font-size: 1.17em; font-weight: bold;} .section { margin-top: 1em; margin-bottom: 1em } .example { margin-top: 1em; margin-bottom: 1em } div.tasklabel { margin-top: 1em; margin-bottom: 1em; } h2.tasklabel, h3.tasklabel, h4.tasklabel, h5.tasklabel, h6.tasklabel { font-size: 100%; } /* All note formats have the same default presentation */ .note { margin-top: 1em; margin-bottom : 1em;} .notetitle { font-weight: bold } .notelisttitle { font-weight: bold } .tip { margin-top: 1em; margin-bottom : 1em;} .tiptitle { font-weight: bold } .fastpath { margin-top: 1em; margin-bottom : 1em;} .fastpathtitle { font-weight: bold } .important { margin-top: 1em; margin-bottom : 1em;} .importanttitle { font-weight: bold } .remember { margin-top: 1em; margin-bottom : 1em;} .remembertitle { font-weight: bold } .restriction { margin-top: 1em; margin-bottom : 1em;} .restrictiontitle { font-weight: bold } .attention { margin-top: 1em; margin-bottom : 1em;} .attentiontitle { font-weight: bold } .dangertitle { font-weight: bold } .danger { margin-top: 1em; margin-bottom : 1em;} .cautiontitle { font-weight: bold } .caution { font-weight: bold; margin-bottom : 1em; } .warning { margin-top: 1em; margin-bottom : 1em;} .warningtitle { font-weight: bold } /* Simple lists do not get a bullet */ ul.simple { list-style-type: none } /* Used on the first column of a table, when rowheader="firstcol" is used */ .firstcol { font-weight : bold;} /* Various basic phrase styles */ .bold { font-weight: bold; } .boldItalic { font-weight: bold; font-style: italic; } .italic { font-style: italic; } .underlined { text-decoration: underline; } .uicontrol { font-weight: bold; } .parmname { font-weight: bold; } .kwd { font-weight: bold; } .defkwd { font-weight: bold; text-decoration: underline; } .var { font-style : italic;} .shortcut { text-decoration: underline; } /* Default of bold for definition list terms */ .dlterm { font-weight: bold; } /* Use CSS to expand lists with @compact="no" */ .dltermexpand { font-weight: bold; margin-top: 1em; } *[compact="yes"]>li { margin-top: 0em;} *[compact="no"]>li { margin-top: .53em;} .liexpand { margin-top: 1em; margin-bottom: 1em } .sliexpand { margin-top: 1em; margin-bottom: 1em } .dlexpand { margin-top: 1em; margin-bottom: 1em } .ddexpand { margin-top: 1em; margin-bottom: 1em } .stepexpand { margin-top: 1em; margin-bottom: 1em } .substepexpand { margin-top: 1em; margin-bottom: 1em } /* Align images based on @align on topic/image */ div.imageleft { text-align: left } div.imagecenter { text-align: center } div.imageright { text-align: right } div.imagejustify { text-align: justify } /* The cell border can be turned on with {border-right:solid} This value creates a very thick border in Firefox (does not match other tables) Firefox works with {border-right:solid 1pt} but this causes a barely visible line in IE */ .cellrowborder { border-right:none; border-top:none; border-left:solid 1px; border-bottom:solid 1px } .row-nocellborder { border-left:none; border-right:none; border-top:none; border-left: hidden; border-bottom:solid 1px} .cell-norowborder { border-top:none; border-bottom:none; border-right:none; border-bottom: hidden; border-left:solid 1px} .nocellnorowborder { border:none; border-left: hidden;border-bottom: hidden } pre.screen { padding: 5px 5px 5px 5px; border: outset; background-color: #CCCCCC; margin-top: 2px; margin-bottom : 2px; white-space: pre} span.filepath, samp.codeph, pre.codeblock { font-family:monospace }PKXHPKC|JOEBPS/css/commonltr.css3/* | This file is part of the DITA Open Toolkit project hosted on | Sourceforge.net. See the accompanying license.txt file for | applicable licenses. */ /* | (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved. */ .unresolved { background-color: skyblue; } .noTemplate { background-color: yellow; } .base { background-color: #ffffff; } /* Add space for top level topics */ .nested0 { margin-top : 1em;} /* div with class=p is used for paragraphs that contain blocks, to keep the XHTML valid */ .p {margin-top: 1em} /* Default of italics to set apart figure captions */ .figcap { font-style: italic } .figdesc { font-style: normal } /* Use @frame to create frames on figures */ .figborder { border-style: solid; padding-left : 3px; border-width : 2px; padding-right : 3px; margin-top: 1em; border-color : Silver;} .figsides { border-left : 2px solid; padding-left : 3px; border-right : 2px solid; padding-right : 3px; margin-top: 1em; border-color : Silver;} .figtop { border-top : 2px solid; margin-top: 1em; border-color : Silver;} .figbottom { border-bottom : 2px solid; border-color : Silver;} .figtopbot { border-top : 2px solid; border-bottom : 2px solid; margin-top: 1em; border-color : Silver;} /* Most link groups are created with
. Ensure they have space before and after. */ .ullinks { list-style-type: none } .ulchildlink { margin-top: 1em; margin-bottom: 1em } .olchildlink { margin-top: 1em; margin-bottom: 1em } .linklist { margin-bottom: 1em } .linklistwithchild { margin-left: 1.5em; margin-bottom: 1em } .sublinklist { margin-left: 1.5em; margin-bottom: 1em } .relconcepts { margin-top: 1em; margin-bottom: 1em } .reltasks { margin-top: 1em; margin-bottom: 1em } .relref { margin-top: 1em; margin-bottom: 1em } .relinfo { margin-top: 1em; margin-bottom: 1em } .breadcrumb { font-size : smaller; margin-bottom: 1em } dt.prereq { margin-left : 20px;} /* Set heading sizes, getting smaller for deeper nesting */ .topictitle1 { margin-top: 0pc; margin-bottom: .1em; font-size: 1.34em; } .topictitle2 { margin-top: 1pc; margin-bottom: .45em; font-size: 1.17em; } .topictitle3 { margin-top: 1pc; margin-bottom: .17em; font-size: 1.17em; font-weight: bold; } .topictitle4 { margin-top: .83em; font-size: 1.17em; font-weight: bold; } .topictitle5 { font-size: 1.17em; font-weight: bold; } .topictitle6 { font-size: 1.17em; font-style: italic; } .sectiontitle { margin-top: 1em; margin-bottom: 0em; color: black; font-size: 1.17em; font-weight: bold;} .section { margin-top: 1em; margin-bottom: 1em } .example { margin-top: 1em; margin-bottom: 1em } div.tasklabel { margin-top: 1em; margin-bottom: 1em; } h2.tasklabel, h3.tasklabel, h4.tasklabel, h5.tasklabel, h6.tasklabel { font-size: 100%; } /* All note formats have the same default presentation */ .note { margin-top: 1em; margin-bottom : 1em;} .notetitle { font-weight: bold } .notelisttitle { font-weight: bold } .tip { margin-top: 1em; margin-bottom : 1em;} .tiptitle { font-weight: bold } .fastpath { margin-top: 1em; margin-bottom : 1em;} .fastpathtitle { font-weight: bold } .important { margin-top: 1em; margin-bottom : 1em;} .importanttitle { font-weight: bold } .remember { margin-top: 1em; margin-bottom : 1em;} .remembertitle { font-weight: bold } .restriction { margin-top: 1em; margin-bottom : 1em;} .restrictiontitle { font-weight: bold } .attention { margin-top: 1em; margin-bottom : 1em;} .attentiontitle { font-weight: bold } .dangertitle { font-weight: bold } .danger { margin-top: 1em; margin-bottom : 1em;} .cautiontitle { font-weight: bold } .caution { font-weight: bold; margin-bottom : 1em; } .warning { margin-top: 1em; margin-bottom : 1em;} .warningtitle { font-weight: bold } /* Simple lists do not get a bullet */ ul.simple { list-style-type: none } /* Used on the first column of a table, when rowheader="firstcol" is used */ .firstcol { font-weight : bold;} /* Various basic phrase styles */ .bold { font-weight: bold; } .boldItalic { font-weight: bold; font-style: italic; } .italic { font-style: italic; } .underlined { text-decoration: underline; } .uicontrol { font-weight: bold; } .parmname { font-weight: bold; } .kwd { font-weight: bold; } .defkwd { font-weight: bold; text-decoration: underline; } .var { font-style : italic;} .shortcut { text-decoration: underline; } /* Default of bold for definition list terms */ .dlterm { font-weight: bold; } /* Use CSS to expand lists with @compact="no" */ .dltermexpand { font-weight: bold; margin-top: 1em; } *[compact="yes"]>li { margin-top: 0em;} *[compact="no"]>li { margin-top: .53em;} .liexpand { margin-top: 1em; margin-bottom: 1em } .sliexpand { margin-top: 1em; margin-bottom: 1em } .dlexpand { margin-top: 1em; margin-bottom: 1em } .ddexpand { margin-top: 1em; margin-bottom: 1em } .stepexpand { margin-top: 1em; margin-bottom: 1em } .substepexpand { margin-top: 1em; margin-bottom: 1em } /* Align images based on @align on topic/image */ div.imageleft { text-align: left } div.imagecenter { text-align: center } div.imageright { text-align: right } div.imagejustify { text-align: justify } /* The cell border can be turned on with {border-right:solid} This value creates a very thick border in Firefox (does not match other tables) Firefox works with {border-right:solid 1pt} but this causes a barely visible line in IE */ .cellrowborder { border-left:none; border-top:none; border-right:solid 1px; border-bottom:solid 1px } .row-nocellborder { border-left:none; border-right:none; border-top:none; border-right: hidden; border-bottom:solid 1px} .cell-norowborder { border-top:none; border-bottom:none; border-left:none; border-bottom: hidden; border-right:solid 1px} .nocellnorowborder { border:none; border-right: hidden;border-bottom: hidden } pre.screen { padding: 5px 5px 5px 5px; border: outset; background-color: #CCCCCC; margin-top: 2px; margin-bottom : 2px; white-space: pre} span.filepath, samp.codeph, pre.codeblock { font-family:monospace }PK-:IPKC|JOEBPS/rcmsynta018.htm!D DROP CATALOG

DROP CATALOG

Purpose

Use the DROP CATALOG command to remove the recovery catalog or a virtual private catalog.

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to drop the recovery catalog

Prerequisites

Execute this command only at the RMAN prompt.

You must be connected to the recovery catalog schema or virtual private catalog schema with the CATALOG command-line option or the CONNECT CATALOG command. The recovery catalog database must be open.

You do not have to be connected to a target database.

Usage Notes

After you execute DROP CATALOG, RMAN prompts you to enter the command again to confirm that you want to perform the operation.

A base recovery catalog is created with CREATE CATALOG, whereas a virtual private catalog is created with CREATE VIRTUAL CATALOG. To drop the base recovery catalog, execute DROP CATALOG while connected to the recovery catalog database as the recovery catalog owner.

Note:

When you drop the base recovery catalog, all RMAN metadata is removed from the recovery catalog. Any backups recorded in the recovery catalog but not in a target database control are not usable by RMAN.

To drop a virtual private catalog using Oracle Database 12c Release 1 (12.1.0.1), execute the DROP CATALOG command while connected to the virtual private catalog. When connected to a virtual private catalog, the DROP CATALOG command does not remove the base recovery catalog itself, but only drops the security policies that are used to restrict user access to the base catalog. To drop a virtual private catalog using Oracle Database 12c Release 1 (12.1.0.2), see Oracle Database Backup and Recovery User's Guide.

You must use a different technique to drop a virtual catalog when using a 10.2 or earlier release of the RMAN client. Before dropping the virtual private catalog, the user must connect to the recovery catalog database as the virtual private catalog owner and execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog):

base_catalog_owner.DBMS_RCVCAT.DROP_VIRTUAL_CATALOG

If you drop the base recovery catalog but not the virtual private catalog, then the virtual catalog is unusable. However, if a dedicated database user owns the virtual private catalog, then you can execute DROP USER ... CASCADE to remove the virtual catalog.

Syntax

dropCatalog::=

Description of GUID-0218BE7C-1DEE-4F05-8BAF-D1902499A80F-print.eps follows

Example

Example 2-80 Dropping a Virtual Private Catalog

Assume that you are using Oracle Database 12c Release 1 (12.1.0.1). You want to remove the virtual private catalog belonging to database user vpu1, but do not want to drop the base recovery catalog. This example connects to the recovery catalog database as vpu1 and drops the virtual private catalog for this user. The base recovery catalog is not affected by the removal of this virtual private catalog.

RMAN> CONNECT CATALOG vpu1@catdb

recovery catalog database Password: password
connected to recovery catalog database
 
RMAN> DROP CATALOG;
 
recovery catalog owner is VPU1
enter DROP CATALOG command again to confirm catalog removal
 
RMAN> DROP CATALOG;
 
virtual catalog dropped
PKb!!PKC|JOEBPS/content.opf Oracle® Database Backup and Recovery Reference , 12c Release 1 (12.1) en-US E50791-07 Oracle Corporation Oracle Corporation Oracle® Database Backup and Recovery Reference , 12c Release 1 (12.1) 2016-10-04T07:56:50Z Provides detailed descriptions of the Recovery Manager (RMAN) commands and recovery catalog views. PK"O>PKC|JOEBPS/rcviews001.htmL RC_ARCHIVED_LOG

RC_ARCHIVED_LOG

This view contains historical information about archived and unarchived redo log files. It corresponds to the V$ARCHIVED_LOG view in the target database control file.

Oracle inserts an archived redo log record after the online redo log is successfully archived. If a log that has not been archived is cleared, then a record is inserted with the NAME column set to NULL.

If the log is archived multiple times, then the view contains multiple archived log records with the same THREAD#, SEQUENCE#, and RESETLOGS_CHANGE#, but with a different name.

An archived log record is also inserted when an archived log is restored from a backup set or a copy.

An archived log can have no record if the record ages out of the control file.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

DBINC_KEY

NUMBER

The primary key for the incarnation of the target database to which this record belongs. Use this column to join with RC_DATABASE_INCARNATION.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

AL_KEY

NUMBER

The primary key of the archived redo log in the recovery catalog. If you issue the LIST command while RMAN is connected to the recovery catalog, then this value appears in the KEY column of the output.

RECID

NUMBER

The archived redo log RECID from V$ARCHIVED_LOG. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

STAMP

NUMBER

The archived redo log stamp from V$ARCHIVED_LOG. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

NAME

VARCHAR2(1024)

The file name of the archived redo log.

THREAD#

NUMBER

The number of the redo thread.

SEQUENCE#

NUMBER

The log sequence number.

RESETLOGS_CHANGE#

NUMBER

The SCN of the most recent RESETLOGS when the record was created.

RESETLOGS_TIME

DATE

The time stamp of the most recent RESETLOGS when the record was created.

FIRST_CHANGE#

NUMBER

The first SCN of this redo log.

FIRST_TIME

DATE

The time when Oracle switched into the redo log.

NEXT_CHANGE#

NUMBER

The first SCN of the next redo log in the thread.

NEXT_TIME

DATE

The first time stamp of the next redo log in the thread.

BLOCKS

NUMBER

The size of this archived log in operating system blocks.

BLOCK_SIZE

NUMBER

The size of the block in bytes.

COMPLETION_TIME

DATE

The time when the redo log was archived or copied.

ARCHIVED

VARCHAR2(3)

Indicates whether the log was archived: YES (archived redo log) or NO (inspected file header of online redo log and added record to V$ARCHIVED_LOG). Inspecting the online logs creates archived log records for them, which allows them to be applied during RMAN recovery. Oracle sets ARCHIVED to NO to prevent online logs from being backed up.

STATUS

VARCHAR2(1)

The status of the archived redo log: A (available), U (unavailable), D (deleted), or X (expired).

IS_STANDBY

VARCHAR2(3)

The database that archived this log: Y (belongs to a standby database) or N (belongs to the primary database).

DICTIONARY_BEGIN

VARCHAR2(3)

Indicates whether this archived log contains the start of a LogMiner dictionary: YES or NO.

If both DICTIONARY_BEGIN and DICTIONARY_END are YES, then this log contains a complete LogMiner dictionary. If DICTIONARY_BEGIN is YES but DICTIONARY_END is NO, this log contains the start of the dictionary, and it continues through each subsequent log of this thread and ends in the log where DICTIONARY_END is YES.

DICTIONARY_END

VARCHAR2(3)

Indicates whether this archived log contains the end of a LogMiner dictionary: YES or NO. See the description of DICTIONARY_BEGIN for an explanation of how to interpret this value.

IS_RECOVERY_DEST_FILE

VARCHAR2(3)

This copy is located in the fast recovery area: YES or NO.

COMPRESSED

VARCHAR2(3)

Internal only

CREATOR

VARCHAR2(7)

Creator of the archived redo log:

  • ARCH - Archiver process

  • FGRD - Foreground process

  • RMAN - Recovery Manager

  • SRMN - RMAN at standby

  • LGWR - Log Writer process

TERMINAL

VARCHAR2(3)

Indicates whether this log was created during terminal recovery of a standby database. Values are YES or NO.

SITE_KEY

NUMBER

Primary key of the Data Guard database associated with this file. Each database in a Data Guard environment has a unique SITE_KEY value. You can use SITE_KEY in a join with the RC_SITE view to obtain the DB_UNIQUE_NAME of the database.


PK눲 LLPKC|JOEBPS/rcviews006.htme' RC_BACKUP_CONTROLFILE_SUMMARY

RC_BACKUP_CONTROLFILE_SUMMARY

RC_BACKUP_CONTROLFILE_SUMMARY provides summary information about control file backups that can be restored, including backups in control file image copies, backup sets, and proxy copies.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

NUM_FILES_BACKED

NUMBER

Total number of control file backups.

NUM_DISTINCT_FILES_BACKED

NUMBER

Number of distinct control files backed up.

MIN_CHECKPOINT_CHANGE#

NUMBER

Lowest checkpoint SCN among all backed up control file s.

MAX_CHECKPOINT_CHANGE#

NUMBER

Highest checkpoint SCN among all backed up control files.

MIN_CHECKPOINT_TIME

DATE

Earliest checkpoint time of any control file in the summary.

MAX_CHECKPOINT_TIME

DATE

Latest checkpoint time of any control file in the summary.

INPUT_BYTES

NUMBER

Total size of input files, in bytes.

OUTPUT_BYTES

NUMBER

Sum of sizes of all output pieces generated by this job.

COMPRESSION_RATIO

NUMBER

Compression ratio for this backup.

INPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as INPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.

OUTPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.


PKyCj'e'PKC|JOEBPS/rcviews.htm Recovery Catalog Views

5 Recovery Catalog Views

This chapter contains descriptions of recovery catalog views. You can only access these views if you have created a recovery catalog (see CREATE CATALOG). For a summary of the recovery catalog views, refer to "Summary of RMAN Recovery Catalog Views".

Note:

These views are not normalized, but are optimized for RMAN and Enterprise Manager usage. Hence, most catalog views have redundant values that result from joining of several underlying tables.

The views intended for use by Enterprise Manager are generally less useful for direct querying than the other views.

PKPKC|JOEBPS/rcmsynta2025.htm VALIDATE

VALIDATE

Purpose

Use the VALIDATE command to check for corrupt blocks and missing files, or to determine whether a backup set can be restored.

If VALIDATE detects a problem during validation, then RMAN displays it and triggers execution of a failure assessment. If a failure is detected, then RMAN logs it into the Automated Diagnostic Repository. You can use LIST FAILURE to view the failures.

Prerequisites

The target database must be mounted or open.

Usage Notes

The options in the VALIDATE command are semantically equivalent to options in the BACKUP VALIDATE command. Unlike BACKUP VALIDATE, however, VALIDATE can check individual backup sets and data blocks.

The VALIDATE command skips never-used blocks. RMAN also skips currently unused (as opposed to never used) blocks for locally managed tablespaces when the COMPATIBLE parameter is set to 10.2 or greater. If RMAN does not read a block because of unused block compression, and if the block is corrupt, then RMAN does not detect the corruption. A corrupt unused block is not harmful.

In a physical corruption, the database does not recognize the block at all. In a logical corruption, the contents of the block are logically inconsistent. By default, the VALIDATE command checks for physical corruption only. You can specify CHECK LOGICAL to check for logical corruption as well. RMAN populates the V$DATABASE_BLOCK_CORRUPTION view with its findings.

Block corruptions can be divided into interblock corruption and intrablock corruption. In intrablock corruption, the corruption occurs within the block itself and can be either physical or logical corruption. In interblock corruption, the corruption occurs between blocks and can only be logical corruption. The VALIDATE command checks for intrablock corruptions only.

Semantics

validate

This subclause specifies backup sets for validation. Refer to validate::= for syntax.


Syntax ElementDescription

validateOperand

Specifies options that control the validation.

See Also: validateOperand

validateObject

Specifies the files to be validated.

See Also: validateObject

 INCLUDE CURRENT    CONTROLFILE

Creates a snapshot of the current control file and validates it.

   PLUS ARCHIVELOG

Includes archived redo log files in the validation. Causes RMAN to perform the following steps:

  1. Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

  2. Run the VALIDATE ARCHIVELOG ALL command. If backup optimization is enabled, then RMAN only validates logs that have not yet been backed up.

  3. Validate the files specified in the VALIDATE command.

  4. Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

  5. Validate any remaining archived redo log files.


validateObject

This subclause specifies database files for validation. Refer to validateObject::= for syntax.


Syntax ElementDescription

archivelogRecordSpecifier

Validates a range of archived redo log files. VALIDATE ARCHIVELOG is equivalent to BACKUP VALIDATE ARCHIVELOG.

BACKUPSET primary_key

Checks that the backup sets specified by primary_key exist and can be restored.

You can obtain the primary keys of backup sets by executing a LIST statement or, if you use a recovery catalog, by querying the RC_BACKUP_SET recovery catalog view.

The VALIDATE BACKUPSET command checks every block in the backup set to ensure that the backup is restorable. If RMAN finds block corruption, then it issues an error and terminates the validation. In contrast, the CROSSCHECK command examines the headers of the specified files if they are on disk or queries the media management catalog if they are on tape.

Use VALIDATE BACKUPSET when you suspect that one or more backup pieces in a backup set are missing or have been damaged. VALIDATE BACKUPSET selects which backups to test, whereas the VALIDATE option of the RESTORE command lets RMAN choose which backups to validate. For validating image copies, run RESTORE VALIDATE FROM DATAFILECOPY.

If you do not have automatic channels configured, then manually allocate at least one channel before executing VALIDATE BACKUPSET.

Note: If multiple copies of a backup set exist, then RMAN validates only the most recent copy. The VALIDATE command does not support an option to validate a specific copy. If one copy is on a different device from another copy, however, then you can use VALIDATE DEVICE TYPE to validate the copy on the specified device. If both copies exists on the same device, then you can use CHANGE to make one copy temporarily UNAVAILABLE and then reissue VALIDATE.

CONTROLFILECOPY{'filename' | ALL |LIKE 'string_pattern'}

Validates control file copies. You can specify a control file copy in one of the following ways:

  • 'filename' specifies a control file copy by file name.

  • ALL specifies all control file copies.

  • LIKE 'pattern' specifies a file name pattern that matches one or more control file copies. The percent sign (%) is a wildcard matching zero or more characters; an underscore (_) is a wildcard matching one character.

The control file copy can be created with the BACKUP AS COPY CURRENT CONTROLFILE command or the SQL statement ALTER DATABASE BACKUP CONTROLFILE TO '...'.

copyOfSpec

Validates image copies of data files and control files.

See Also: copyOfSpec for details.

CURRENT CONTROLFILE

Validates the current control file.

DATABASE

Validates the database.

In a multitenant container database (CDB), validates the whole CDB. Connect to the root as described in "Connecting to CDBs and PDBs". When connected to a pluggable database (PDB), validates the PDB.

RMAN validates all data files and control files. If the database is currently using a server parameter file, then RMAN validates the server parameter file.

Note: The online redo log files and temp files are not validated.

DATABASE ROOT

In a CDB, validates only the root. See the previous description of DATABASE for details about database validation.

PLUGGABLE DATABASE pdb_name

In a CDB, validates the specified PDBs. Use a comma-delimited list to specify multiple PDBs. Connect to the root as described in "Connecting to CDBs and PDBs".

See the previous description of DATABASE for details about database validation.

datafileCopySpec

Validates one or more data file image copies.

When validating data file copies, RMAN checks for block corruption but does not terminate the validation if corruption is discovered. Unlike VALIDATE BACKUPSET, RMAN proceeds and reports the number of blocks that are corrupted.

See Also: datafileCopySpec for details

DATAFILE datafileSpec

Specifies a list of one or more data files that contain blocks requiring validation.

Note: You do not have to take a data file offline if you are validating it.

See Also: datafileSpec

RECOVERY AREA

Validates recovery files created in the current and all previous fast recovery area destinations. Recovery files are full and incremental backup sets, control file autobackups, archived redo log files, and data file copies. Flashback logs, the current control file, and online redo logs are not validated.

DB_RECOVERY_FILE_DEST

Semantically equivalent to RECOVERY AREA.

RECOVERY FILES

Validates all recovery files on disk, whether they are stored in the fast recovery area or other locations on disk. Recovery files include full and incremental backup sets, control file autobackups, archived redo log files, and data file copies. Flashback logs are not validated.

SPFILE

Validates the server parameter file currently used by the database. RMAN cannot validates other copies of the server parameter file, and cannot validate the server parameter file when the instance was started with an initialization parameter file.

TABLESPACE tablespace_name

Validates the specified tablespaces. RMAN translates tablespace names internally into a list of data files, then validates all data files that are currently part of the tablespaces. RMAN validates all data files that are currently members of the specified tablespaces.

When connected to the root in a CDB, refers to tablespaces in the root. Refers to tablespaces in a PDB when connected directly to a PDB.

See "Connecting to CDBs and PDBs".


validateOperand

This subclause specifies modifiers for the validation. Refer to validateOperand::= for syntax.


Syntax ElementDescription

CHECK LOGICAL

Tests data and index blocks in the files that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert log and server session trace file. The RMAN command completes and V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges.

Note: VALIDATE does not use MAXCORRUPT.

DEVICE TYPE deviceSpecifier

Allocates automatic channels for the specified device type only. This option is valid only if you have configured automatic channels and have not manually allocated channels. For example, if you configure automatic disk and tape channels, and run VALIDATE ...DEVICE TYPE DISK, RMAN allocates only disk channels.

See Also: deviceSpecifier

NOEXCLUDE

When specified on a VALIDATE DATABASE or VALIDATE COPY OF DATABASE command, RMAN validates all tablespaces, including any for which a CONFIGURE EXCLUDE command has been entered. This option does not override SKIP OFFLINE or SKIP READONLY.

SECTION SIZE sizeSpec

Parallelizes the validation by dividing each file into the specified section size.

Only specify this parameter when multiple channels are configured or allocated and you want the channels to parallelize the validation, so that multiple channels can validate a single data file. This parameter applies only when validating data files.

If you specify a section size that is larger than the size of the file, then RMAN does not parallelize validation for the file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.

See Also: BACKUP SECTION SIZE to learn how to make multisection backups

skipSpec

Excludes the specified files from the validation.


skipSpec

This subclause specifies files to be excluded from the validation.


Syntax ElementDescription

SKIP

Excludes data files or archived redo log files if they are inaccessible, offline, or read-only.

   INACCESSIBLE

Excludes data files and archived redo log files that cannot be read due to I/O errors.

A data file is only considered inaccessible if it cannot be read. Some offline data files can still be read because they still exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible.

   OFFLINE

Excludes offline data files.

   READONLY

Excludes read-only data files.


VALIDATE Command Output

Table 3-11 List of Data Files

ColumnIndicates

File

Absolute number of the data file being validated.

Status

OK if no corruption, or FAILED if block corruption is found.

Marked Corrupt

Number of blocks marked corrupt. These blocks were previously marked corrupt by the database. For example, the database may intentionally mark blocks corrupt during a recovery involving a NOLOGGING operation. Also, an RMAN backup may contain corrupt blocks permitted by the SET MAXCORRUPT command. When this backup is restored, the file contains blocks that are marked corrupt.

Empty Blocks

Number of blocks that either have never been used.

Blocks Examined

Total number of blocks in the file.

High SCN

The highest SCN recorded in the file.

File Name

The name of the file being validated.

Block Type

The type of block validated: Data, Index, or Other.

Blocks Failing

The number of blocks that fail the corruption check. These blocks are newly corrupt.

Blocks Processed

The number of blocks checked for corruption.

Table 3-12 List of Control File and SPFILE

ColumnIndicates

File TYPE

Type of file: SPFILE or Control File.

Status

OK if no corruption, or FAILED if block corruption is found.

Blocks Failing

The number of blocks that fail the corruption check. These blocks are newly corrupt.

Blocks Examined

Total number of blocks in the file.

Table 3-13 List of Archived Logs

ColumnIndicates

Thrd

The redo thread number.

Seq

The log sequence number.

Status

OK if no corruption, or FAILED if block corruption is found.

Blocks Failing

The number of blocks that fail the corruption check. These blocks are newly corrupt.

Blocks Examined

Total number of blocks in the file.

Name

The name of the archived redo log file.

Examples

Example 3-77 Validating a Backup Set

This example lists all available backup sets and then validates them. As the sample output indicates, RMAN confirms that it is possible to restore the backups.

RMAN> LIST BACKUP SUMMARY; 
 
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
3871    B  F  A DISK        08-MAR-13       1       1       NO         TAG20130308T092426
3890    B  F  A DISK        08-MAR-13       1       1       NO         TAG20130308T092534
RMAN> VALIDATE BACKUPSET 3871, 3890;
Starting validate at 08-MAR-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece
 /disk2/PROD/backupset/2013_03_08/o1_mf_nnndf_TAG20130308T092 426_2z0kpc72_.bkp
channel ORA_DISK_1: piece
 handle=/disk2/PROD/backupset/2013_03_08/o1_mf_nnndf_TAG20130308T092426_2z0kpc72_.bkp ta
 g=TAG20130308T092426
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:18
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece
 /disk2/PROD/autobackup/2013_03_08/o1_mf_s_616670734_2z0krhjv_.bkp
channel ORA_DISK_1: piece
 handle=/disk2/PROD/autobackup/2013_03_08/o1_mf_s_616670734_2z0krhjv_.bkp
 tag=TAG20130308T092534
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:00
Finished validate at 08-MAR-13

Example 3-78 Validating the Database

This example validates the database and includes sample output. The validation finds one corrupt block in data file 1. The VALIDATE output indicates that more information about the corruption can be found in the specified trace file.

RMAN> VALIDATE DATABASE;

Starting validate at 26-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf
input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf
input datafile file number=00003 name=/disk1/oradata/prod/undotbs01.dbf
input datafile file number=00004 name=/disk1/oradata/prod/cwmlite01.dbf
input datafile file number=00005 name=/disk1/oradata/prod/drsys01.dbf
input datafile file number=00006 name=/disk1/oradata/prod/example01.dbf
input datafile file number=00007 name=/disk1/oradata/prod/indx01.dbf
input datafile file number=00008 name=/disk1/oradata/prod/tools01.dbf
input datafile file number=00009 name=/disk1/oradata/prod/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:01:25
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    FAILED 0              4140         57600           498288
  File Name: /disk1/oradata/prod/system01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       1              41508
  Index      0              7653
  Other      0              4299
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     0              8918         20040           498237
  File Name: /disk1/oradata/prod/sysaux01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              2473
  Index      0              2178
  Other      0              6471
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
3    OK     0              36           2560            498293
  File Name: /disk1/oradata/prod/undotbs01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              2524
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4    OK     0              1            1280            393585
  File Name: /disk1/oradata/prod/cwmlite01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              1279
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
5    OK     0              1            1280            393644
  File Name: /disk1/oradata/prod/drsys01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              1279
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
6    OK     0              1            1280            393690
  File Name: /disk1/oradata/prod/example01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              1279
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7    OK     0              1            1280            393722
  File Name: /disk1/oradata/prod/indx01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              1279
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
8    OK     0              1            1280            393754
  File Name: /disk1/oradata/prod/tools01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              1279
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
9    OK     0              1272         1280            393785
  File Name: /disk1/oradata/prod/users01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0
  Index      0              0
  Other      0              8
 
validate found one or more corrupt blocks
See trace file /disk2/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_10609.trc for details
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
Control File OK     0              506
Finished validate at 26-FEB-13
PKuPKC|JOEBPS/compat.htmHi RMAN Compatibility

C RMAN Compatibility

This appendix describes the requirements for compatibility among the different components of the Recovery Manager (RMAN) environment. This appendix contains these topics:

See Also:

Oracle Database Upgrade Guide

About RMAN Compatibility

Table C-1 describes the components of an RMAN environment. Each component has a release number associated with it.


Table C-1 Components of an RMAN Environment

ComponentRelease Number Refers to ...

RMAN client

Version of RMAN client (displayed when you start RMAN)

Recovery catalog database

Version of Oracle Database

Recovery catalog schema in recovery catalog database

Version of RMAN client used to create the recovery catalog

Target database

Version of Oracle Database

Auxiliary database

Version of Oracle Database


Starting with Oracle Database 12c, the version of the RMAN client, target database, and auxiliary database must be the same. The recovery catalog schema can be any supported catalog schema whose version is greater than the version of the RMAN client. For example an Oracle Database 12c RMAN client can only connect to a target database whose version is Oracle Database 12c, an auxiliary database whose version is Oracle Database 12c, and a recovery catalog schema that is created in an Oracle Database 12c or higher version.

Determining the Recovery Catalog Schema Version

To determine the current release of the catalog schema, you must run a SQL query.

  1. Use SQL*Plus to connect to the recovery catalog database as the catalog owner. For example, enter:
    % sqlplus rco@catdb
    
  2. Query the rcver catalog table. For example, run this query:
    SQL> SELECT * FROM rcver; 
    
         VERSION 
         ------------ 
         12.01.00.01
    

RMAN Compatibility Matrix

In general, the rules of RMAN compatibility are as follows:

  • The version of the RMAN client must be equal to the version of the target database.

  • The version of the auxiliary database must be equal to the version of the RMAN client.

  • The version of the recovery catalog schema must be greater than or equal to the version of the RMAN client.

  • If the recovery catalog is a virtual private catalog (see CREATE CATALOG), then the version of the RMAN client connecting to it must be Oracle Database 10g Release 1 (10.1.0.6) or Oracle Database 10g Release 2 (10.2.0.3). Oracle 9i RMAN clients cannot connect to a virtual private catalog. This version restriction does not affect RMAN client connections to an Oracle Database 11g base recovery catalog, even if the base catalog has virtual private catalog users.

  • While backing up an Oracle Database 10g or later release with the Oracle9i RMAN client, you cannot include a control file that was created using COMPATIBLE=10.0.0 in a data file backup set. The workaround is to turn control file autobackup ON.

  • Any release of Oracle Database can restore backup sets and copies created by any prior Oracle Database release.

Table C-2 shows version-specific requirements for RMAN components. The symbol >= before a release means all Oracle Database releases from this release or later along with their patches.

Table C-2 RMAN Compatibility Table

Target/Auxiliary Database versionRMAN client versionRecovery Catalog Database versionRecovery Catalog Schema version

10.1.0.5

>= 10.1.0.5 and <= target database executable

>= 10.1.0.5

>= RMAN client version

10.2.0

>= 10.1.0.5 and <= target database executable

>= 10.1.0.5

>= RMAN client version

11.1.0

>= 10.1.0.5 and <= target database executable

>= 10.2.0.3

>= RMAN client version

11.2.0

>= 10.1.0.5 and <= target database executable

>= 10.2.0.3

>= RMAN client version

12.1.0.x

= 12.1.0.x

>= 10.2.0.3

>= RMAN client version

When using an older version of the RMAN client with a newer version of the database, you do not get the features added in the newer version.

Cross-Version Compatibility of Recovery Catalog Exports and Imports

Data Pump Exports of the recovery catalog are often used as a way to backup its contents. When planning to use Data Pump Export to make a logical backup of the recovery catalog, see Oracle Database Utilities for details on compatibility issues relating to the use of database exports across versions of Oracle Database.

Exports from a later version of the database cannot be imported into databases running under earlier versions. You must export your recovery catalog data using the export utility from the earliest version of Oracle Database that you use for a recovery catalog.

For example, to export the recovery catalog data from an Oracle Database 11g Release 2 (11.2) database and import it into an Oracle Database 10g Release 1 (10.1.0.5) database for disaster recovery, you must use the export utility from Oracle Database 10g Release 1 (10.1.0.5) to perform the export operation. Otherwise, the import operation fails.

RMAN Compatibility: Scenario

Assume that you maintain a production databases of the following releases:

  • Oracle Database 10g Release 2 (10.2)

  • Oracle Database 11g Release 1 (11.1)

  • Oracle Database 11g Release 2 (11.2)

  • Oracle Database 12c Release 1 (12.1)

You want to record RMAN repository data about these databases in a single recovery catalog database. According to RMAN Compatibility Matrix, you can use a single recovery catalog database whose version is Oracle Database 12c Release 1 (12.1) with a catalog schema whose version is Oracle Database 12c Release 1 (12.1) for all target databases. Ensure that the version of the RMAN client used to back up each target database meets the following requirements:

  • Use the Oracle Database 10g Release 2 (10.2) RMAN client to back up the Oracle Database 10g Release 2 (10.2) database.

  • Use either the Oracle Database 10g Release 2 (10.2) or Oracle Database 11g Release 1 (11.1) RMAN client to back up the Oracle Database 11g Release 1 (11.1) database.

  • Use either the Oracle Database 10g Release 2 (10.2), Oracle Database 11g Release 1(11.1), or Oracle Database 11g Release 2 (11.2) RMAN client to back up the Oracle Database 11g Release 2 (11.2) database.

  • Use the Oracle Database 12c RMAN client to back up Oracle Database 12c.

PK0HHPKC|JOEBPS/rcmsynta024.htm66 GRANT

GRANT

Purpose

Use the GRANT command to assign privileges for a virtual private catalog schema to a database user. By default, a virtual catalog user has no access to the base recovery catalog.

Prerequisites

Execute this command at the RMAN prompt.

A base recovery catalog must have been created with CREATE CATALOG before you can use GRANT to assign privileges for a virtual private catalog.

Usage Notes

The best practice is to create a base recovery catalog that stores metadata for all databases. You can then create an Oracle Database user to own the virtual private catalog schema. In Oracle Database 12c Release 1 (12.1.0.1), the virtual private catalog user must be granted the RECOVERY_CATALOG_OWNER role. In Oracle Database 12c Release 1 (12.1.0.2), the virtual private catalog user only needs the CREATE SESSION privilege.

Connect RMAN to the base recovery catalog and use the GRANT command to assign recovery catalog privileges to the virtual catalog owner. Afterwards, run CREATE VIRTUAL CATALOG to create a virtual catalog schema for this user. You can use REVOKE to revoke catalog privileges.

Relationship Between Users with CATALOG Privileges on the Same Database

As an illustration of GRANT usage, suppose databases prod1 and prod2 are registered in the base recovery catalog. While logged in as a user with the SYSBACKUP or SYSDBA privilege to the base recovery catalog, you create two virtual private catalog users: VPC1 and VPC2. You grant both users CATALOG FOR DATABASE access for database PROD1, but not PROD2.

In this scenario, both VPC1 and VPC2 can access the metadata for backups of PROD1 made by the base recovery catalog owner. Both users can also access the metadata for backups of PROD1 made by each other. Neither VPC1 nor VPC2 can access backup metadata for database PROD2.

Relationship Between GRANT REGISTER and GRANT CATALOG

When you grant REGISTER DATABASE to a user, RMAN implicitly grants recovery CATALOG FOR DATABASE privileges for any database registered by this user. If you REVOKE only the REGISTER DATABASE privilege from a user (for example, VIRTCAT), then it does not implicitly revoke the CATALOG FOR DATABASE privilege for a database registered by virtcat (for example, PROD). Because the CATALOG FOR DATABASE privilege includes registration privileges for prod, virtcat can continue to unregister and register prod. To prevent VIRTCAT from performing any operations on prod, including reregistering it, REVOKE ALL PRIVILEGES from VIRTCAT.

Syntax

grant::=

Description of GUID-F19118DF-F7AE-40EF-8626-EF18D12C54A5-print.eps follows

Semantics


Syntax ElementDescription
CATALOG FOR DATABASE [database_name | integer] TO userid

Grants recovery catalog access for the specified database to the specified user.

Note: The catalog operations granted on the specified database include registering and unregistering this database.

Specify the database by either database name or DBID. If you specify a name when multiple databases with this name are registered in the catalog, then RMAN returns an error. In this case, specify the database by DBID.

To grant access to databases that are registered in the recovery catalog, you must use the GRANT CATALOG command. You can also grant access for a target database that is not yet registered in the catalog, thereby enabling a virtual private catalog user to register a database. You must grant access by using the DBID of the database that has not yet been registered.

REGISTER DATABASE TO userid

Grants the specified user the ability to use REGISTER DATABASE to register databases that are currently unknown to the recovery catalog.

When you grant REGISTER DATABASE to a user, RMAN implicitly grants recovery CATALOG FOR DATABASE privileges for any database registered by the user. The CATALOG FOR DATABASE privileges on the database include registering and unregistering this database.

For example, assume that user virtcat is granted REGISTER DATABASE and registers database prod in the catalog. RMAN implicitly grants recovery CATALOG FOR DATABASE privileges for prod to virtcat.


Examples

Example 2-100 Granting Privileges for a Virtual Private Catalog

Assume that database user RCO own the base recovery catalog in database CATDB. This base recovery catalog stores the RMAN metadata for a large number of databases in a data center. Your goal is to create virtual private catalogs for two backup operators in the data center. The database version is Oracle Database 12c Release 1 (12.1.0.2).

You start SQL*Plus and connect to the CATDB database as SYS. You then use the CREATE USER statement to create the BCKOP2 and BCKOP3 users on CATDB. You can grant the CREATE SESSION privilege to these users as follows:

SQL> GRANT CREATE SESSION TO bckop2, bckop3;
SQL> EXIT

You then start the RMAN client and connect to the recovery catalog database as user RCO. You use the RMAN GRANT command to give BCKOP2 the ability to register any database in her virtual private catalog, but grant BCKOP3 access to only a subset of the databases in the data center:

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> GRANT REGISTER DATABASE TO bckop2;
RMAN> GRANT CATALOG FOR DATABASE prod TO bckop3;
RMAN> GRANT CATALOG FOR DATABASE prodb TO bckop3;
RMAN> EXIT;

You start a new RMAN session and connect as user BCKOP2. When you connect for the first time, RMAN automatically creates the virtual private catalog. You must exit and restart RMAN after creating each virtual catalog.

RMAN> CONNECT CATALOG bckop2@catdb

recovery catalog database Password: password
connected to recovery catalog database


RMAN> EXIT;

You start a new RMAN session and connect as user BCKOP3 to create the virtual private catalog associated with this user:

RMAN> CONNECT CATALOG bckop3@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> EXIT;

In the following example, backup operator DBA1 uses her virtual private catalog, which is stored in the BCKOP3 schema on CATDB, to store the metadata for a backup of a target database:

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG bckop3@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
PKƤ;666PKC|JOEBPS/rcviews008.htm! RC_BACKUP_COPY_SUMMARY

RC_BACKUP_COPY_SUMMARY

RC_BACKUP_COPY_SUMMARY contains summary information about all AVAILABLE control file and data file copies for each database.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

NUM_COPIES

NUMBER

Total number of image copy backups.

NUM_DISTINCT_COPIES

NUMBER

Number of distinct image copy backups.

MIN_CHECKPOINT_CHANGE#

NUMBER

Minimum checkpoint SCN among all image copy backups described in this view.

MAX_CHECKPOINT_CHANGE#

NUMBER

Maximum checkpoint SCN among all image copy backups described in this view.

MIN_CHECKPOINT_TIME

DATE

Earliest checkpoint time among all copies described in this view.

MAX_CHECKPOINT_TIME

DATE

Latest checkpoint time among all copies described in this view.

OUTPUT_BYTES

NUMBER

Sum of sizes of all data file and control file copies.

OUTPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.


PKf!!PKC|JOEBPS/rcmsynta2022.htm^` TRANSPORT TABLESPACE

TRANSPORT TABLESPACE

Purpose

Use the TRANSPORT TABLESPACE command to create transportable tablespace sets from RMAN backups instead of the live data files of the source database.

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to transport tablespaces with RMAN

Prerequisites

The limitations on creating transportable tablespace sets described in Oracle Database Administrator's Guide apply to transporting tablespaces from backup, except the requirement to make the tablespaces read-only.

The SYSAUX tablespace must not be part of the recovery set, which is the set of tablespaces to be transported. RMAN enforces inclusion of the SYSAUX tablespace in the auxiliary set, which contains data files and other files required for the tablespace transport.

TRANSPORT TABLESPACE does not convert endian formats. If the target platform has a different endian format, then after running TRANSPORT TABLESPACE use the CONVERT command to convert the endian format of the transportable set data files.

If you drop a tablespace, then you cannot later use TRANSPORT TABLESPACE to include this tablespace in a transportable tablespace set, even if the SCN for TRANSPORT TABLESPACE is earlier than the SCN at which the table was dropped. If you rename a tablespace, then you cannot use TRANSPORT TABLESPACE to create a transportable tablespace set as of a point in time before the tablespace was renamed.

Backups and Backup Metadata

You must have a backup of all needed tablespaces (including those in the auxiliary set) and archived redo log files needed to recover to the target point in time.

If you do not use a recovery catalog, and if the database has re-used control file records containing metadata about required backups, then the command fails because RMAN cannot locate the backups. You may be able to use CATALOG to add backups to the RMAN repository, but if the database is overwriting control file records, you may lose records of other backups.

Data Pump Export and Import

Because the RMAN uses the Data Pump Export and Import utilities, you cannot use TRANSPORT TABLESPACE if the tablespaces to be transported use XMLType. In this case you must use the procedure in Oracle Database Administrator's Guide.

If a file under the name of the export dump file exists in the tablespace destination, then TRANSPORT TABLESPACE fails when it calls Data Pump Export. If you are repeating a previous TRANSPORT TABLESPACE job, then make sure to delete the previous output files, including the export dump file.

Tablespace and Column Encryption

The following database encryption features both use the Oracle software keystore: Transparent Data Encryption (TDE) column encryption, which functions at the column level, and TDE tablespace encryption. Note the following restrictions for tablespaces that are encrypted or contain encrypted columns:

  • If you are transporting an encrypted tablespace, then you must manually copy the keystore to the destination database.

  • If the destination database has an existing keystore, then you cannot copy the keystore from the source database to the destination database. Thus, you cannot transport encrypted data to a database that already has a keystore. If you encrypt columns with TDE column encryption, then you can export them into an export file that is password-protected and import the data into the destination database.

See Also:

Oracle Database Advanced Security Guide to learn about TDE

Usage Notes

Because RMAN creates the automatic auxiliary instance used for restore and recovery on the same node as the source instance, there is some performance overhead during the operation of the TRANSPORT TABLESPACE command.

If RMAN is not part of the backup strategy for your database, then you can still use TRANSPORT TABLESPACE if the needed data file copies and archived redo log files are available on disk. Use the CATALOG command to record the data file copies and archived redo log files in the RMAN repository. You can then use TRANSPORT TABLESPACE. You also have the option of using RMAN to back up your database specifically so you can use TRANSPORT TABLESPACE.

Syntax

transpt_tbs::=

Description of GUID-93701145-14A8-44F0-BB84-2055F8C79F7C-print.eps follows

(transpt_tbs_optlist::=)

transpt_tbs_optlist::=

Description of GUID-2A0AC170-38EC-476C-B6CF-C7BE82BCF51D-print.eps follows

(untilClause::=)

Semantics

transpt_tbs


Syntax ElementDescription

tablespace_name

Specifies the name of each tablespace to transport.

You must have a backup of all needed tablespaces (including those in the auxiliary set) and archived redo log files available for use by RMAN that can be recovered to the target time for the TRANSPORT TABLESPACE operation.


transpt_tbs_optlist

This subclause specifies optional parameters that affect the tablespace transport.


Syntax ElementDescription
AUXILIARY DESTINATION'location'

Specifies the location for files for the auxiliary instance.

You can use SET NEWNAME and CONFIGURE AUXNAME to override this argument for individual files. If using your own initialization parameter file to customize the auxiliary instance, then you can use the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters instead of AUXILIARY DESTINATION.

See Also: Oracle Database Backup and Recovery User's Guide for details on the interactions among the different techniques for naming the auxiliary instance files

DATAPUMP DIRECTORY datapump_directory

Specifies a database directory object where Data Pump Export outputs are created (see Example 3-72). If not specified, then RMAN creates files in the location specified by TABLESPACE DESTINATION.

See Also: Oracle Database Utilities for more details on Data Pump Export and database directory objects

DUMP FILE 'filename'

Specifies where to create the Data Pump Export dump file. If not specified, the export dump file is named dmpfile.dmp and stored in the location specified by the DATAPUMP DIRECTORY clause or in the tablespace destination.

Note: If a file under the name of the export dump file exists in the tablespace destination, then TRANSPORT TABLESPACE fails when it calls Data Pump Export. If you are repeating a previous TRANSPORT TABLESPACE job, then make sure to delete the previous output files, including the export dump file.

EXPORT LOG 'filename'

Specifies the location of the log generated by Data Pump Export. If omitted, the export log is named explog.log and stored in the location specified by the DATAPUMP DIRECTORY clause or in the tablespace destination.

IMPORT SCRIPT 'filename'

Specifies the file name for the sample input script generated by RMAN for use in plugging in the transported tablespace at the destination database. If omitted, the import script is named impscript.sql. The script is stored in the tablespace destination.

TABLESPACE DESTINATION tablespace_destination

Specifies the location of the data files for the transported tablespaces after the tablespace transport operation completes.

TO RESTORE POINT restore_point_name

Specifies a restore point for tablespace restore and recovery, with the SCN at which the restore point was created as the upper, inclusive limit. Because the limit is inclusive, RMAN selects only files that it can use to restore or recover tablespaces up to and including the SCN corresponding to the restore point.

untilClause

Specifies a past time, SCN, or log sequence number (see Example 3-71). If specified, RMAN restores and recovers the tablespaces at the auxiliary instance to their contents at that past point in time before export.

If you rename a tablespace, then you cannot use this command to create a transportable tablespace set as of a point in time before the tablespace was renamed. RMAN has no knowledge of the previous name of the tablespace.

Tablespaces including undo segments as of the UNTIL time or SCN for TRANSPORT TABLESPACE must be part of the auxiliary set. The control file only contains a record of tablespaces that include undo segments at the current time. If the set of tablespaces with undo segments was different at the UNTIL time or SCN, then TRANSPORT TABLESPACE fails. Thus, if you use RMAN in NOCATALOG mode and specify UNTIL, then the set of tablespaces with undo segments at the time TRANSPORT TABLESPACE executes must equal the set of tablespaces with undo segments at the UNTIL time or SCN.


Examples

Example 3-71 Using TRANSPORT TABLESPACE with a Past Time

In this example, the tablespaces for the transportable set are example and tools, the transportable set files are to be stored at /disk1/transport_dest, and the transportable tablespaces are to be recovered to a time 15 minutes ago:

TRANSPORT TABLESPACE example, tools
  TABLESPACE DESTINATION '/disk1/transportdest'
  AUXILIARY DESTINATION '/disk1/auxdest'
  UNTIL TIME 'SYSDATE-15/1440';

Partial sample output follows:

Creating automatic instance, with SID='egnr'
 
initialization parameters used for automatic instance:
db_name=PROD
compatible=11.0.0
db_block_size=8192
.
.
.
starting up automatic instance PROD
.
.
. 
executing Memory Script
 
executing command: SET until clause
 
Starting restore at 07-JUN-13
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=44 device type=DISK
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring control file
.
.
.
output file name=/disk1/auxdest/cntrl_tspitr_PROD_egnr.f
Finished restore at 07-JUN-13
 
sql statement: alter database mount clone database
 
sql statement: alter system archive log current
 
sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;
 
starting full resync of recovery catalog
full resync complete
.
.
.
executing Memory Script
.
.
.
 
Starting restore at 07-JUN-13
using channel ORA_AUX_DISK_1
 
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /disk1/auxdest/TSPITR_PROD_EGNR/datafile/o1_mf_system_%u_.dbf
datafile 1 switched to datafile copy
.
.
.
starting media recovery
.
.
. 
Finished recover at 07-JUN-13
 
database opened
.
.
.
executing Memory Script
.
.
.
sql statement: alter tablespace EXAMPLE read only
Removing automatic instance
shutting down automatic instance
Oracle instance shut down
Automatic instance removed
auxiliary instance file /disk1/auxdest/cntrl_tspitr_PROD_egnr.f deleted
.
.
.

Example 3-72 Using TRANSPORT TABLESPACE with Customized File Locations

This example illustrates the use of the optional arguments that control the locations of Data Pump-related files such as the dump file. The DATAPUMP DIRECTORY must refer to an object that exists in the target database. Use the CREATE DIRECTORY SQL statement to create a directory object.

TRANSPORT TABLESPACE example
  TABLESPACE DESTINATION '/disk1/transportdest'
  AUXILIARY DESTINATION '/disk1/auxdest'
  DATAPUMP DIRECTORY mypumpdir
  DUMP FILE 'mydumpfile.dmp'
  IMPORT SCRIPT 'myimportscript.sql'
  EXPORT LOG 'myexportlog.log';
PKA^^PKC|JOEBPS/rcmsynta023.htmn FLASHBACK DATABASE

FLASHBACK DATABASE

Purpose

Use the FLASHBACK DATABASE command to rewind the database to a target time, SCN, log sequence number, or restore point.

This command works by undoing changes made by Oracle Database to the data files that exist when you run the command. Flashback can fix logical failures, but not physical failures. Thus, you cannot use the command to recover from disk failures or the accidental deletion of data files.

FLASHBACK DATABASE is usually much faster than a RESTORE operation followed by point-in-time recovery, because the time needed to perform FLASHBACK DATABASE depends on the number of changes made to the database since the desired flashback time. On the other hand, the time needed to do a traditional point-in-time recovery from restored backups depends on the size of the database.

Flashback Database also has several uses in a Data Guard environment.

See Also:

Prerequisites

You can run this command from the RMAN prompt or from within a RUN command.

RMAN must be connected as TARGET to a database, which must be Oracle Database 10g or later. The target database must be mounted with a current control file, that is, the control file cannot be a backup or re-created. The database must run in ARCHIVELOG mode.

You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file. If the database control file is restored from backup or re-created, then all existing flashback log information is discarded.

The fast recovery area must be configured to enable flashback logging. Flashback logs are stored as Oracle-managed files in the fast recovery area and cannot be created if no fast recovery area is configured. You must enable flashback logging before the target time for flashback by issuing the SQL statement ALTER DATABASE ... FLASHBACK ON. Query V$DATABASE.FLASHBACK_ON to see whether flashback logging has been enabled.

The database must contain no online tablespaces for which flashback functionality was disabled with the SQL statement ALTER TABLESPACE ... FLASHBACK OFF.

Usage Notes

A Flashback Database operation applies to the whole database. You cannot flash back individual tablespaces. A Flashback Database operation is similar to a database point-in-time recovery (DBPITR) performed with RECOVER, but RMAN uses flashback logs to undo changes to a point before the target time or SCN. RMAN automatically restores from backup any archived redo log files that are needed and recovers the database to make it consistent. RMAN never flashes back data for temporary tablespaces.

The earliest SCN that can be used for a Flashback Database operation depends on the setting of the DB_FLASHBACK_RETENTION_TARGET initialization parameter, and on the actual retention of flashback logs permitted by available disk. View the current database SCN in V$DATABASE.CURRENT_SCN.

Effect of NOLOGGING Operations on Flashback Database

When using FLASHBACK DATABASE with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and data files affected by the NOLOGGING operation. For example, assume that you do a direct-path INSERT operation in NOLOGGING mode and that the operation runs from 9:00 to 9:15 on April 3. If you later use Flashback Database to return to 09:07 on this date, then the objects and data files updated by the direct-path INSERT may be left with block corruption after Flashback Database completes.

If possible, avoid using FLASHBACK DATABASE with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected data files immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use FLASHBACK DATABASE to return to a point in time during an operation such as a direct-path INSERT, then consider performing the operation in LOGGING mode.

See Also:

The discussion of logging_clause in Oracle Database SQL Language Reference for more information about operations that support NOLOGGING mode

Effect of Data File Status Changes on Flashback Database

The FLASHBACK DATABASE command does not start modifying the database until it has made sure that it has all the files and resources that it needs. A Flashback Database operation does not fail due to missing data files, redo log files, or flashback logs.

If a data file has changed status between the current SCN and the target SCN of the flashback, then the FLASHBACK DATABASE command behaves differently depending on the nature of the status change. Refer to Table 2-8 for details.


Table 2-8 How FLASHBACK DATABASE Responds to Data File Status Changes

If this data file operation occurred during the flashback window ...Then the FLASHBACK DATABASE command ...

Added

Removes the data file record from the control file.

Dropped

Adds the data file to the control file, but marks it as offline and does not flash it back. You can then restore and recover the data file to the same time or SCN.

Renamed

Ignores the renaming. The data file retains its current name.

Resized

May fail. You can take the data file offline and then rerun the FLASHBACK DATABASE command. The data file is not flashed back. You can then restore and recover the data file to the same time or SCN.

Taken offline

Ignores the operation. The data file retains its current online status.

Brought online

Ignores the operation. The data file retains its current offline status.

Made read-only or read/write

Changes the status of the data file in the control file.


Tablespaces with Flashback Logging Disabled

It is possible for the ALTER TABLESPACE ... FLASHBACK OFF statement to have been executed for some tablespaces. If FLASHBACK DATABASE has insufficient flashback data to rewind a tablespace to the target SCN, then RMAN issues an error and does not modify the database. Whenever FLASHBACK DATABASE fails or is interrupted, the database is left mounted.

In this scenario, query V$TABLESPACE to determine which tablespaces have flashback logging disabled. You have the following options:

  • Take the data files in the affected tablespaces offline. Afterwards, run RESTORE and then RECOVER to bring these data files to the same point in time as the rest of the database.

  • Drop the affected data files with the ALTER DATABASE DATAFILE ... OFFLINE FOR DROP statement. You can then open the database with the RESETLOGS option. After the database is open, execute DROP TABLESPACE statements for the tablespaces that contain the dropped data files.

State of the Database After Flashback Database

After running FLASHBACK DATABASE, the database may not be left at the SCN most immediately before the target time. Events other than transactions can cause the database SCN to be updated. If you use the FLASHBACK DATABASE TO form of the command, and if a transaction is associated with the target SCN, then after the flashback the database includes all changes up to and including this transaction. Otherwise, all changes up to but not including this transaction are included in the data files, whether you use the FLASHBACK DATABASE TO or FLASHBACK DATABASE TO BEFORE form of the command. Changes after the specified target SCN are never applied because of FLASHBACK DATABASE.

After FLASHBACK DATABASE completes, you may want to open the database read-only and run queries to ensure that you achieved the intended result. If you are not satisfied, then you can use RECOVER DATABASE to recover the database to its state when you started the flashback. You can then rerun FLASHBACK DATABASE.

If you are satisfied with the results of the flashback, then you can OPEN RESETLOGS to abandon all changes after the target time. Alternatively, you can use Data Pump to export lost data, use RECOVER DATABASE to return the database to its state before the flashback operation, and then use Data Pump to reimport the lost data.

Syntax

flashback::=

Description of GUID-F209E31E-938E-4C15-8936-669AE6F80216-print.eps follows

(deviceSpecifier::=)

Semantics


Syntax ElementDescription

DEVICE TYPE deviceSpecifier

Allocates automatic channels for the specified device type only. For example, if you configure automatic disk and tape channels, and issue FLASHBACK ... DEVICE TYPE DISK, then RMAN allocates only disk channels. RMAN may need to restore redo logs from backup during the flashback database process. Changes between the last flashback log and the target time must be re-created based on the archived redo log. If no automatic channels are allocated for tape and a needed redo log is on tape, then the FLASHBACK DATABASE operation fails.

See Also: deviceSpecifier

DATABASE

Rewinds the entire database.

TO BEFORE SCN integer

Returns the database to its state just before the specified SCN. Any changes at an SCN lower than that specified are applied, but if there is a change associated with the specified SCN it is not applied. By default, the provided SCN resolves to the current or ancestor incarnation. You can override the default by using the RESET DATABASE INCARNATION command.

Query OLDEST_FLASHBACK_SCN in V$FLASHBACK_DATABASE_LOG to see the approximate lowest SCN to which you can flash back.

TO BEFORE SEQUENCE integer [THREAD integer]

Specifies a redo log sequence number and thread as an upper limit. RMAN applies changes up to (but not including) the last change in the log with the specified sequence and thread number.

TO BEFORE RESETLOGS

Returns the database to its state including all changes up to the SCN of the most recent OPEN RESETLOGS.

Note: FLASHBACK DATABASE can only return the database to a point before the most recent OPEN RESETLOGS operation if your database has been upgraded to Oracle Database 10g Release 2 or later.

TO BEFORE TIME 'date_string'

Returns the database to its state including all changes up to but not including changes at the specified time.

Query OLDEST_FLASHBACK_TIME in V$FLASHBACK_DATABASE_LOG to see the approximate lowest time to which you can flash back.

TO SCN integer

Returns the database to the point up to (and including) the specified SCN. By default, the provided SCN resolves to the current or ancestor incarnation. You can override the default by using the RMAN RESET DATABASE command to set the recovery target incarnation.

Query OLDEST_FLASHBACK_SCN in V$FLASHBACK_DATABASE_LOG to see the approximate lowest SCN to which you can flash back.

TO SEQUENCE integer THREAD integer

Specifies a redo log sequence number and thread as an upper limit. RMAN applies changes up to (and including) the last change in the log with the specified sequence and thread number.

TO RESTORE POINT restore_point_name

Returns the database to the SCN associated with the specified restore point. This can be an ordinary restore point or a guaranteed restore point.

TO TIME 'date_string'

Returns the database to its state at the specified time. You can use any SQL DATE expressions to convert the time to the current format, for example, FLASHBACK DATABASE TO TIME 'SYSDATE-7'.

Query OLDEST_FLASHBACK_TIME in V$FLASHBACK_DATABASE_LOG to see the approximate lowest time to which you can flash back.


Examples

Example 2-98 FLASHBACK DATABASE to a Specific SCN

Assume that you inserted corrupted rows in many tables at 5:00 p.m. on February 14. You connect SQL*Plus to the database and query the earliest SCN in the flashback window:

SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
  2  FROM   V$FLASHBACK_DATABASE_LOG;

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK
-------------------- ----------------
              411010 2013/02/14 16:49

You then open a new terminal, start the RMAN client, and connect to the target database and recovery catalog. You enter RMAN commands as follows (sample output for the FLASHBACK DATABASE is included):

RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO SCN 411010;
 
Starting flashback at 15-FEB-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
 
 
starting media recovery
media recovery complete, elapsed time: 00:00:07
 
Finished flashback at 15-FEB-13
 
RMAN> ALTER DATABASE OPEN RESETLOGS;

Example 2-99 FLASHBACK DATABASE to a Restore Point

Assume that you are preparing to load a massive number of updates to the database. You create a guaranteed restore point before the performing the updates:

SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE;

The bulk update fails, leaving the database with extensive corrupted data. You start an RMAN session, connect to the target database and recovery catalog, and list the guaranteed restore points:

RMAN> LIST RESTORE POINT ALL;

SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
412742                     GUARANTEED 15-FEB-13 BEFORE_UPDATE

You mount the database, flash back the database to the restore point (sample output included), and then open the database with the RESETLOGS option:

RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO RESTORE POINT 'BEFORE_UPDATE';
 
Starting flashback at 15-FEB-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
 
 
starting media recovery
 
archived log for thread 1 with sequence 34 is already on disk as file /disk2/oracle/oradata/prod/arch/archive1_34_614598462.dbf
media recovery complete, elapsed time: 00:00:01
Finished flashback at 15-FEB-13
 
RMAN> ALTER DATABASE OPEN RESETLOGS;
PK:nnPKC|J OEBPS/toc.ncxZ Oracle® Database Backup and Recovery Reference , 12c Release 1 (12.1) Cover Title and Copyright Information Contents Preface Changes in This Release for Backup and Recovery Reference 1 About RMAN Commands 2 RMAN Commands: @ (at sign) to QUIT 3 RMAN Commands: RECOVER to VALIDATE 4 RMAN Subclauses 5 Recovery Catalog Views A RMAN Reserved Words B Deprecated RMAN Syntax C RMAN Compatibility D Oracle Database Cloud Backup Module E Oracle Secure Backup (OSB) Cloud Module Index Copyright PK|<_ZPKC|JOEBPS/rcviews019.htm+Q RC_BACKUP_SET_SUMMARY

RC_BACKUP_SET_SUMMARY

RC_BACKUP_SET_SUMMARY provides aggregate information about available backup sets for each database registered in the recovery catalog.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

NUM_BACKUPSETS

NUMBER

Total number of available backup sets recorded in the recovery catalog for this database.

OLDEST_BACKUP_TIME

DATE

Creation time of the oldest available backup set recorded in the recovery catalog for this database.

NEWEST_BACKUP_TIME

DATE

Creation time of the newest available backup set recorded in the recovery catalog for this database.

OUTPUT_BYTES

NUMBER

Sum of sizes of all backup pieces for all available backup sets recorded in the recovery catalog for this database.

ORIGINAL_INPUT_BYTES

NUMBER

Sum of sizes of all input files for all available backup sets recorded in the recovery catalog for this database.

ORIGINAL_INPRATE_BYTES

NUMBER

Average input rate in bytes for the creation of all available backup sets recorded in the recovery catalog for this database.

OUTPUT_RATE_BYTES

NUMBER

Average output rate in bytes for the creation of all available backup sets recorded in the recovery catalog for this database.

COMPRESSION_RATIO

NUMBER

Aggregate compression ratio for all available backup sets recorded in the recovery catalog for this database.

ORIGINAL_INPUT_BYTES_DISPLAY

VARCHAR2(32K)

Total size of all input files stored in all available backup sets recorded in the recovery catalog for this database.

OUTPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.

ORIGINAL_INPRATE_BYTES_DISPLAY

VARCHAR2(32K)

Same value as ORIGINAL_INPRATE_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.

OUTPUT_RATE_BYTES_DISPLAY

VARCHAR2(32K)

Same value as OUTPUT_RATE_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.


PK&%;++PKC|JOEBPS/rcviews017.htmBe RC_BACKUP_SET

RC_BACKUP_SET

This view lists information about backup sets for all incarnations of the database. It corresponds to the V$BACKUP_SET view. A backup set record is inserted after the backup has successfully completed.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

DB_ID

NUMBER

The unique database identifier.

BS_KEY

NUMBER

The primary key of the backup set in the recovery catalog. If you issue the LIST command while RMAN is connected to the recovery catalog, then this value appears in the KEY column of the output. Use this column to join with RC_BACKUP_PIECE.

RECID

NUMBER

The backup set RECID from V$BACKUP_SET. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file. Use either RECID and STAMP or SET_STAMP and SET_COUNT to access V$BACKUP_SET.

STAMP

NUMBER

The backup set STAMP from V$BACKUP_SET. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file. Use either RECID and STAMP or SET_STAMP and SET_COUNT to access V$BACKUP_SET.

SET_STAMP

NUMBER

The SET_STAMP value from V$BACKUP_SET. SET_STAMP and SET_COUNT form a concatenated key that uniquely identifies this record in the target database control file. Use either RECID and STAMP or SET_STAMP and SET_COUNT to access V$BACKUP_SET.

SET_COUNT

NUMBER

The SET_COUNT value from V$BACKUP_SET.SET_STAMP and SET_COUNT form a concatenated key that uniquely identifies this record in the target database control file. Use either RECID and STAMP or SET_STAMP and SET_COUNT to access V$BACKUP_SET.

BACKUP_TYPE

VARCHAR2(1)

The type of the backup: D (full backup or level 0 incremental), I (incremental level 1), L (archived redo log).

INCREMENTAL_LEVEL

NUMBER

The level of the incremental backup: NULL, 0, or 1.

PIECES

NUMBER

The number of backup pieces in the backup set.

START_TIME

DATE

The time when the backup began.

COMPLETION_TIME

DATE

The time when the backup completed.

ELAPSED_SECONDS

NUMBER

The duration of the backup in seconds.

STATUS

VARCHAR2(1)

The status of the backup set: A (all backup pieces available), D (all backup pieces deleted), O (some backup pieces are available but others are not, so the backup set is unusable).

CONTROLFILE_INCLUDED

VARCHAR2(7)

Possible values are NONE (backup set does not include a backup control file), BACKUP (backup set includes a normal backup control file), and STANDBY (backup set includes a standby control file).

INPUT_FILE_SCAN_ONLY

VARCHAR2(3)

This backup set record was created by the BACKUP VALIDATE command. No real backup set exists. This record is only a placeholder used to keep track of which data files were scanned and which corrupt blocks (if any) were found in those files.

If COMPATIBLE is set to 11.0.0 or greater, then RMAN does not populate this column.

KEEP

VARCHAR2(3)

Indicates whether this backup set has a retention policy different from the value for CONFIGURE RETENTION POLICY. Possible values are YES and NO.

KEEP_UNTIL

DATE

If the KEEP UNTIL TIME clause of the BACKUP command was specified, then this column shows the date after which this backup becomes obsolete. If the column is NULL and KEEP OPTIONS is not NULL, then the backup never becomes obsolete.

KEEP_OPTIONS

VARCHAR2(11)

The KEEP options specified for this backup set. Possible values are NOLOGS, BACKUP_LOGS, LOGS, and NULL. NOLOGS indicates a consistent backup made when the database was mounted. BACKUP_LOGS indicates that the backup was made in open mode, so archived log backups must be applied to make it consistent. LOGS indicates a long-term backup made with the LOGS keyword, which is now deprecated. NULL indicates that this backup has no KEEP options and becomes obsolete based on the retention policy.

BLOCK_SIZE

NUMBER

Block size of the backup set.

SITE_KEY

NUMBER

Primary key of the Data Guard database associated with this backup set. Each database in a Data Guard environment has a unique SITE_KEY value.You can use SITE_KEY in a join with the RC_SITE view to obtain the DB_UNIQUE_NAME of the database.

MULTI_SECTION

VARCHAR2(3)

Y if this is a multisection backup; otherwise null.


PK6ǟBBPKC|JOEBPS/rcviews010.htmc4 RC_BACKUP_DATAFILE

RC_BACKUP_DATAFILE

This view lists information about data files in backup sets. It corresponds to the V$BACKUP_DATAFILE view. A backup data file is uniquely identified by BDF_KEY.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

DBINC_KEY

NUMBER

The primary key for the incarnation of the target database. Use this column to join with RC_DATABASE_INCARNATION.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

BDF_KEY

NUMBER

The primary key of the data file backup in the recovery catalog. If you issue the LIST command while RMAN is connected to the recovery catalog, then this value appears in the KEY column of the output.

RECID

NUMBER

The backup data file RECID from V$BACKUP_DATAFILE. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

STAMP

NUMBER

The backup data file stamp from V$BACKUP_DATAFILE. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

BS_KEY

NUMBER

The primary key of the backup set to which this record belongs in the recovery catalog. Use this column to join with RC_BACKUP_SET or RC_BACKUP_PIECE.

SET_STAMP

NUMBER

The SET_STAMP value from V$BACKUP_SET. SET_STAMP and SET_COUNT form a concatenated key that uniquely identifies the backup set to which this record belongs in the target database control file.

SET_COUNT

NUMBER

The SET_COUNT value from V$BACKUP_SET. SET_STAMP and SET_COUNT form a concatenated key that uniquely identifies the backup set to which this record belongs in the target database control file.

BS_RECID

NUMBER

The RECID from V$BACKUP_SET.

BS_STAMP

NUMBER

The STAMP from V$BACKUP_SET.

BACKUP_TYPE

VARCHAR2(1)

The type of the backup: D (full or level 0 incremental) or I (incremental level 1).

INCREMENTAL_LEVEL

NUMBER

The level of the incremental backup: NULL, 0, or 1.

COMPLETION_TIME

DATE

The completion time of the backup.

FILE#

NUMBER

The absolute file number of the data file. When FILE#=0, the record refers to the control file. See the note following this table for special semantics of other columns when FILE#=0.

CREATION_CHANGE#

NUMBER

The creation SCN of the data file.

RESETLOGS_CHANGE#

NUMBER

The SCN of the most recent RESETLOGS in the data file header.

RESETLOGS_TIME

DATE

The time stamp of the most recent RESETLOGS in the data file header.

INCREMENTAL_CHANGE#

NUMBER

The SCN that determines whether a block is included in the incremental backup. A block is only included if the SCN in the block header is greater than or equal to INCREMENTAL_CHANGE#.

The range of redo covered by the incremental backup begins with INCREMENTAL_CHANGE# and ends with CHECKPOINT_CHANGE#.

CHECKPOINT_CHANGE#

NUMBER

The checkpoint SCN of this data file in this backup set.

CHECKPOINT_TIME

DATE

The time associated with CHECKPOINT_CHANGE#.

ABSOLUTE_FUZZY_CHANGE#

NUMBER

The absolute fuzzy SCN. See the note following this table for special semantics when FILE#=0.

DATAFILE_BLOCKS

NUMBER

The number of data blocks in the data file.

BLOCKS

NUMBER

The number of data blocks written to the backup. This value is often less than DATAFILE_BLOCKS because for full backups, blocks that have never been used are not included in the backup, and for incremental backups, blocks that have not changed are not included in the backup. This value is never greater than DATAFILE_BLOCKS.

BLOCK_SIZE

NUMBER

The size of the data blocks in bytes.

STATUS

VARCHAR2(1)

The status of the backup set: A (all pieces available), D (all pieces deleted), O (some pieces are available but others are not, so the backup set is unusable).

BS_LEVEL

NUMBER

The incremental level (NULL, 0, or 1) specified when this backup was created. This value can be different from the INCREMENTAL_LEVEL column because if you run, for example, a level 1 incremental backup, but no previous level 0 backup exists for some files, a level 0 backup is automatically taken for these files. In this case, BS_LEVEL is 1 and INCREMENTAL_LEVEL is 0.

PIECES

NUMBER

The number of backup pieces in the backup set that contains this backup data file.

BLOCKS_READ

NUMBER

Number of blocks that were scanned while taking this backup. If this was an incremental backup, and change tracking was used to optimize the backup, then the value of this column is smaller than DATAFILE_BLOCKS. Otherwise, the value of this column equals DATAFILE_BLOCKS. Even when change tracking data is used, the value of this column may be larger than BLOCKS, because the data read by change tracking is further refined during the process of creating an incremental backup.

CREATION_TIME

DATE

Creation timestamp of the data file.

MARKED_CORRUPT

NUMBER

Number of blocks marked corrupt.

USED_CHANGE_TRACKING

VARCHAR2(3)

Whether change tracking data was used to accelerate this incremental backup (YES) or was not used (NO).

USED_OPTIMIZATION

VARCHAR2(3)

Whether backup optimization was applied (YES) or not (NO).

PCT_NOTREAD

NUMBER

The percentage of the file that was skipped during this backup. For incremental backups, this value indicates the efficiency of the block change tracking file.

FOREIGN_DBID

NUMBER

Foreign DBID of the database from which this data file was transported. The value is 0 if the file backed up is not a foreign database file.

PLUGGED_READONLY

VARCHAR2(3)

YES if this is a backup of a transported read-only foreign file; otherwise NO.

PLUGIN_CHANGE#

NUMBER

SCN at which the foreign data file was transported into the database. The value is 0 if this file is not a foreign database file.

PLUGIN_RESETLOGS_CHANGE#

NUMBER

The SCN of the RESETLOGS operation for the incarnation into which this foreign file was transported. The value is 0 if this file is not a foreign database file.

PLUGIN_RESETLOGS_TIME

DATE

The time of the RESETLOGS operation for the incarnation into which this foreign file was transported. The value is 0 if this file is not a foreign database file.

SECTION_SIZE

NUMBER

Specifies the number of blocks in each section of a multisection backup. Value is 0 for whole file backups.


PK%zљccPKC|JOEBPS/rcviews025.htm-f RC_COPY_CORRUPTION

RC_COPY_CORRUPTION

This view lists corrupt block ranges in data file copies. It corresponds to the V$COPY_CORRUPTION view.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for the target database. Use this column to join with almost any other catalog view.

DBINC_KEY

NUMBER

The primary key for the incarnation of the target database. Use this column to join with RC_DATABASE_INCARNATION.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

RECID

NUMBER

The record identifier from V$COPY_CORRUPTION. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

STAMP

NUMBER

The stamp from V$COPY_CORRUPTION. RECID and STAMP form a concatenated primary key that uniquely identifies this record in the target database control file.

CDF_KEY

NUMBER

The primary key of the data file copy in the recovery catalog. If you issue the LIST command while RMAN is connected to the recovery catalog, then this value appears in the KEY column of the output. Use this column to join with RC_DATAFILE_COPY.

COPY_RECID

NUMBER

The RECID from RC_DATAFILE_COPY. This value is propagated from the control file.

COPY_STAMP

NUMBER

The STAMP from RC_DATAFILE_COPY. This value is propagated from the control file.

FILE#

NUMBER

The absolute file number of the data file.

CREATION_CHANGE#

NUMBER

The creation SCN of this data file. Because file numbers can be reused, FILE# and CREATION_CHANGE# are both required to uniquely identify a specified file over the life of the database.

BLOCK#

NUMBER

The block number of the first corrupted block in the file.

BLOCKS

NUMBER

The number of corrupted blocks found beginning with BLOCK#.

CORRUPTION_CHANGE#

NUMBER

For media corrupt blocks, this value is zero. For logically corrupt blocks, this value is the lowest SCN in the blocks in this corrupt range.

MARKED_CORRUPT

VARCHAR2(3)

YES if this corruption was not previously detected by the database server or NO if it was known by the database server.

CORRUPTION_TYPE

VARCHAR2(9)

Same as RC_DATABASE_BLOCK_CORRUPTION.CORRUPTION_TYPE.


PKx--PKC|JOEBPS/rcmsynta009.htm CONFIGURE

CONFIGURE

Purpose

Use the CONFIGURE command to create or change a persistent configuration affecting RMAN backup, restore, duplication, and maintenance jobs on a particular database. A configuration is in effect for any RMAN session on this database until the configuration is explicitly cleared or changed. You can use the SHOW command to display the configurations for one or more databases.

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to configure the RMAN environment

Prerequisites

Execute this command only at the RMAN prompt.

Unless you specify the FOR DB_UNIQUE_NAME clause, an RMAN connection to a target database is required. The target database must be mounted or open.

In CDBs, you must connect to the root to create or change configuration settings. You cannot configure settings when connected to a PDB.

Usage Notes

The CONFIGURE command always stores a configuration for a target database in the target database control file. If you use RMAN with a recovery catalog, then RMAN also stores persistent configuration settings for each registered database in the catalog.

Default RMAN Configuration Settings

The RMAN CONFIGURE settings have defaults. You can return to the default for any CONFIGURE command by rerunning the command with the CLEAR option, but you cannot clear individual parameters in this way. For example, the following command is valid:

CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR

However, the following command is invalid:

CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 5M CLEAR

RMAN Configuration in a Data Guard Environment

In a Data Guard environment, Oracle recommends that you always use RMAN with a recovery catalog. You can use the CONFIGURE command to create persistent RMAN configurations for any individual primary or standby database in the Data Guard environment, except settings for backup retention policy, tablespace exclusion, and auxiliary names. Thus, the primary and standby databases can have different channel configurations, control file autobackup locations, and so on.

You can use the FOR DB_UNIQUE_NAME clause to configure a database to which RMAN is not connected as TARGET. You can use CONFIGURE DB_UNIQUE_NAME to make a new physical standby database known to the recovery catalog and implicitly register it.

Semantics

configure


Syntax ElementDescription
DB_UNIQUE_NAME db_unique_name CONNECT IDENTIFIER 'connect_string'

Specifies the net service name for the physical standby database specified by DB_UNIQUE_NAME. The CONNECT IDENTIFIER string must not include the database user name and password.

RMAN must also be connected to the primary database as TARGET. RMAN must be connected to a recovery catalog.

When you run the RESYNC CATALOG FROM DB_UNIQUE_NAME command, databases in a Data Guard environment use the net service name to connect with the db_unique_name database. For example, assume that a standby database has the unique name standby1 and the net service name sby1. You connect RMAN as TARGET to the primary database and execute CONFIGURE DB_UNIQUE_NAME 'standby1' CONNECT IDENTIFIER 'sby1'. Every primary and standby database in the environment uses the net service name sby1 when it needs to make an Oracle Net connection to standby1.

Note: When the target database needs to connect to other standby or primary databases, it connects as the SYSDBA or SYSBACKUP user by using the existing Data Guard authentication mechanisms.

Suppose that you recently connected RMAN as TARGET to the primary database and used CONFIGURE ... FOR DB_UNIQUE_NAME standby_new to configure backup settings for standby database standby_new. However, you have not yet connected RMAN as TARGET to standby_new. In this case, you can execute RESYNC CATALOG FROM DB_UNIQUE_NAME standby_new. The primary database uses the connect identifier to make an Oracle Net connection to the standby database. When you later connect RMAN to the standby database, RMAN pushes the configuration from the recovery catalog to the mounted control file.

Note: If the database specified by CONFIGURE DB_UNIQUE_NAME is not registered in the recovery catalog, then RMAN implicitly registers it.

CLEAR

Returns a parameter to its default setting. See the Usage Notes.

delalConf

Configures an archived redo log deletion policy.

AUXNAME FOR DATAFILE datafileSpec CLEAR | TO 'filename'

Configures the auxiliary file name for the specified target data file to 'filename' (see Example 2-53). Specify CLEAR to unspecify the auxiliary file name.

If you are performing TSPITR or using DUPLICATE, then you can set AUXNAME to preconfigure the file names for use on the auxiliary database without manually specifying the auxiliary file names during the procedure. You cannot use CONFIGURE AUXNAME for recovery set, you must use SET NEWNAME.

For example, use this command during TSPITR if the data files are on raw disk and you must restore auxiliary data files to raw disk for performance reasons. Typically, you set the AUXNAME parameter in TSPITR for the data files of the SYSTEM and SYSAUX tablespaces and the tablespaces containing rollback or undo segments. Do not overlay files which are in use by the production database and can be discarded after TSPITR completes. In essence, the AUXNAME of a data file is the location where TSPITR can create a temporary copy of it.

When renaming files with the DUPLICATE command, CONFIGURE AUXNAME is an alternative to SET NEWNAME. The difference is that after you set the AUXNAME the first time, you do not need to reset the file name when you issue another DUPLICATE command: the AUXNAME setting remains in effect until you issue CONFIGURE AUXNAME ... CLEAR. In contrast, you must reissue the SET NEWNAME command every time you execute the DUPLICATE command.

See Also: Oracle Database Backup and Recovery User's Guide to learn how to perform RMAN TSPITR, and Oracle Database Backup and Recovery User's Guide to learn how to duplicate a database with RMAN

backupConf

Configures default backup options such as duplexing, optimization, excluding tablespaces, backup set sizes, and retention policies.

cfauConf

Configures control file autobackup settings.

COMPRESSION ALGORITHM 'algorithm_name'

Specifies the algorithm that RMAN uses to create compressed backup sets.

The default compression algorithm setting is BASIC and does not require the Advanced Compression Option.

If, however, you have enabled the Oracle Database 11g Release 2 Advanced Compression Option, you can choose from the following compression levels:

  • HIGH - Best suited for backups over slower networks where the limiting factor is network speed

  • MEDIUM -Recommended for most environments. Good combination of compression ratios and speed

  • LOW - Least impact on backup throughput and suited for environments where CPU resources are the limiting factor.

Note: The compression ratio generally increases from LOW to HIGH, with a trade-off of potentially consuming more CPU resources.

Since the performance of the various compression levels depends on the nature of the data in the database, network configuration, system resources and the type of computer system and its capabilities, Oracle cannot document universally applicable performance statistics. The decision about which level is best must factor in on how balanced your system is regarding bandwidth into the CPU and the actual speed of the CPU. It is highly recommended that you run tests with the different compression levels on the data in your environment. Choosing a compression level based on your environment, network traffic characteristics (workload) and data set is the only way to ensure that the backup set compression level can satisfy your organization's performance requirements and any applicable service level agreements.

Note: The V$RMAN_COMPRESSION_ALGORITHM view describes the supported algorithms.

See Also: Oracle Database Reference entry for V$RMAN_COMPRESSION_ALGORITHM.

OPTIMIZE FOR LOAD

{TRUE|FALSE}

Specifies whether Oracle Database performs pre-compression block processing when compressed backups have been requested. TRUE is the default and FALSE enables pre-compression processing. The default behavior is not to perform pre-compression block processing. Such processing can consume extra CPU resources, and is not needed for blocks that contain all originally loaded data, and have never been the subject of single-row inserts and deletes. Specifying FALSE uses additional CPU resources to perform pre-compression block processing which consists of internal block cleanups and defragmentation that can result in improved levels of binary compression.

See Also: Oracle Database Backup and Recovery User's Guide to learn more about this option.

AS OF RELEASE

'version'

Specifies the release version. The version number uses the release number format and may use as many as 5 numbers to fully qualify the release. For example, 10.2.0.3.0 and 11.2 are acceptable values. This option ensures compression algorithm stability across future releases.

deviceConf

Configures default backup settings for devices, such as the default backup device, channel configurations for devices, default backup types for each device, and parallelism.

ENCRYPTION

Specifies transparent-mode encryption settings for the database or tablespaces.

This configuration applies unless overridden with the SET ENCRYPTION command. Options specified for an individual tablespace take precedence over options specified for the whole database.

See Also: "Encryption of Backup Sets" to learn about the different modes of backup encryption, and Oracle Database Advanced Security Guide to learn about transparent data encryption

   ALGORITHM 'algorithm_name'

Specifies the default algorithm to use for encryption when writing backup sets. Possible values are listed in V$RMAN_ENCRYPTION_ALGORITHMS. The CLEAR option resets the database to the default value.

   FOR DATABASE [ON | OFF | CLEAR]

Specifies whether to enable transparent encryption for the entire database. The options are as follows:

  • ON enables encryption for all database files.

  • OFF turns off encryption for all database files.

  • CLEAR restores the default setting of OFF.

Note: You must use the SET ENCRYPTION IDENTIFIED BY command to enable password encryption.

   FOR TABLESPACE tablespace_name [ON | OFF | CLEAR]

Specifies whether to enable transparent encryption for one or more tablespaces. Configured settings for a tablespace always override configuration set at the database level. The options are as follows:

  • ON enables encryption for the specified tablespace unless SET ENCRYPTION OFF FOR ALL TABLESPACES is used.

  • OFF disables encryption for the specified tablespace unless SET ENCRYPTION ON FOR ALL TABLESPACES is used.

  • CLEAR means that encryption for the specified tablespace is determined by the current default for the whole database.

Note: You must use the SET ENCRYPTION IDENTIFIED BY command to enable password encryption.

FOR TABLESPACE pdb_name:tablespace_name [ON | OFF | CLEAR]

The name of the tablespace in a CDB. Multiple databases can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. pdb-name is the name of a PDB.

See the previous description of FOR TABLESPACE.

RMAN OUTPUT TO KEEP FOR integer DAYS

Configures RMAN output logging to the number of days specified by integer. Information regarding the output of RMAN commands is stored in two views, RC_RMAN_OUTPUT and V$RMAN_OUTPUT. When you configure output logging to integer days, any logging entry that is older than integer days is deleted from both the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views.

For example, assume that the existing output logging configuration is set to 20 days. You use the CONFIGURE command to change output logging to 10 days. Any logging entries that are older than 10 days are deleted from RC_RMAN_OUTPUT and V$_RMAN_OUTPUT.

To disable RMAN output logging, set integer to zero, as shown in the following example.

CONFIGURE RMAN OUTPUT TO KEEP FOR 0 DAYS; 

When you disable output logging, no logging information is stored in the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views. Existing logging entries in RC_RMAN_OUTPUT are deleted.

CLEAR

Clears the existing RMAN output logging configuration and resets it to 7 days, which is the default.

RMAN stores output logging information in the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views. When you clear the output logging configuration, any logging entry that is older than 7 days (the default value) is deleted from the RC_RMAN_OUTPUT view. Entries older than 7 days in the V$RMAN_RMAN_OUTPUT view are not deleted immediately. They are deleted only when the maximum number of rows permitted for this view is exceeded.

SNAPSHOT CONTROLFILE NAME TO 'filename'

Configures the snapshot control file name and location to 'filename'. If you run CONFIGURE SNAPSHOT CONTROLFILE NAME CLEAR, then RMAN sets the snapshot control file name to its default.

The default value for the snapshot control file name is platform-specific and dependent on Oracle home. For example, the default on some UNIX systems is ?/dbs/snapcf_@.f. If you clear the control file name, and if you change Oracle home, then the default location of the snapshot control file changes as well.

The snapshot control file name is valid for this database only. Assume that you configure the snapshot control file name to a nondefault value on the primary database. If you use DUPLICATE to create a standby database, then the snapshot control file location on the standby database is set to the default value. If desired, you can then configure the snapshot location on the standby database to a nondefault value.

See Also: Oracle Database Backup and Recovery User's Guide for more information about snapshot control files

forDbUniqueNameOption

Creates an RMAN configuration in the recovery catalog for the database in a Data Guard environment specified by DB_UNIQUE_NAME. You can specify a single database with db_unique_name or use ALL for all databases in the recovery catalog that share the DBID of the target database (or DBID specified by the SET DBID command).

A recovery catalog is required when performing operations in a Data Guard environment. RMAN must be connected as TARGET to a mounted or open database (which can be a primary or standby database), or you must identify the target database with the SET DBID command. Thus, you can use this clause to create a persistent configuration for a standby database without connecting as TARGET to the standby or primary database. For example, you can create a configuration for a standby database before its creation so that the configuration applies after the database is created (see Example 2-55).

When you specify FOR DB_UNIQUE_NAME, RMAN directly updates the configuration metadata in the recovery catalog. When RMAN connects as TARGET to a database whose configurations were changed with FOR DB_UNIQUE_NAME, RMAN updates the mounted control file with the configuration metadata from the recovery catalog.

Note: It is possible to run CONFIGURE locally on a standby database and then run CONFIGURE FOR DB_UNIQUE_NAME for the same database while RMAN is not connected to this database as TARGET. In this case, the configuration in the recovery catalog overrides the configuration in the control file for the specific database.


delalConf

This subclause manages persistent configurations for archived redo log deletion policy.


Syntax ElementDescription

ARCHIVELOG DELETION POLICY

Determines when archived redo log files are eligible for deletion.

The archived log deletion policy applies to all log archiving destinations, including the fast recovery area. The policy does not apply to archived redo log files in backup sets.

Only archived redo log files in the fast recovery area are automatically deleted by the database. You can execute the BACKUP ... DELETE INPUT, DELETE ARCHIVELOG, or DELETE OBSOLETE commands to delete logs manually from log archiving destinations, including the recovery area. If FORCE is not specified on the deletion commands, then these deletion commands obey the archived log deletion policy. If FORCE is specified, then the deletion commands ignore the archived log deletion policy.

In the recovery area, the database retains logs eligible for deletion if possible. The database deletes the oldest logs first when disk space is required. When the recovery area is under disk pressure, the database may delete archived redo log files needed by Oracle Streams.

Note: The deletion policy does not apply to foreign archived redo log files, which are logs received by a logical standby database for a LogMiner session. These logs are transferred from a primary database, but unlike ordinary archived redo log files they have a different DBID. Foreign archived redo log files cannot be backed up or restored on a logical standby database.

 TO APPLIED ON [ALL] STANDBY

Archived redo log files are eligible for deletion if both of the following conditions are met:

  • The archived redo log files have been applied to the required standby databases.

  • The logs are not needed by the BACKED UP ... TIMES TO DEVICE TYPE deletion policy. If the BACKED UP policy is not set, then this condition is always met.

This policy is applicable to primary databases, standby databases, and FAR SYNC standby databases (if valid standby remote databases exist). For primary databases, the archived redo log files are eligible for deletion after they are applied on the standby. If no valid standby database exists, then RMAN uses TO NONE as the policy. For standby databases, the archived redo log files are eligible for deletion after they are applied on the standby and on any cascading standby databases.

Which remote destinations are considered depends on the following criteria:

  • If you do not specify ALL, then archived redo log files are eligible for deletion after being applied to all mandatory remote destinations.

  • If you specify ALL, then archived redo log files are eligible after being applied or consumed on all remote destinations, whether mandatory or not.

    For example, standby database sby1 may be the only remote destination receiving logs, but other remote destinations may apply logs by referring to the same location on sby1. With ALL, sby1 marks the log on the primary database as consumed as soon as it is not required at sby1, but does not permit deletion of this log until it is applied or consumed by all other dependent remote destinations referring to the same location.

Note: It is invalid to specify the TO APPLIED clause in combination with either NONE or the TO SHIPPED clause.

See Also: Oracle Data Guard Concepts and Administration for details

   BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier

Archived redo log files are eligible for deletion if both of the following conditions are met:

  • The specified number of archived log backups exist on the specified device type.

  • The logs are not needed by the TO SHIPPED TO ... STANDBY or TO APPLIED ON ... STANDBY deletion policy. If neither standby deletion policy is set, then this condition is always met.

If you configure the deletion policy with this clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs. In this way, the archived log deletion policy functions as a default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVELOG command. You can override this deletion policy by specifying FORCE option on the BACKUP command.

See Also: deviceSpecifier

   TO NONE

Disables the archived log deletion policy. This is the default setting.

Archived redo log files can be located inside or outside of the fast recovery area. Logs in any location can be deleted by manual commands. Only logs in the fast recovery area can be deleted automatically by the database.

When the deletion policy is set to NONE, RMAN considers archived redo log files as eligible for deletion if they meet both of the following conditions:

  • The archived redo log files, whether in the fast recovery area or outside of it, have been transferred to the required remote destinations specified by LOG_ARCHIVE_DEST_n.

  • The archived redo log files in the fast recovery area have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy.

    The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by Flashback Database. Archived redo log files are needed by Flashback Database if the logs were created later than SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'.

For example, suppose that archived redo log files have been transferred to required remote destinations. The logs are obsolete according to the recovery window retention policy, but have not been backed up. In this case, the logs are eligible for deletion. Alternatively, suppose that the logs are obsolete and have been backed up to SBT, but have not been transferred to required remote destinations. In this case, the logs are not eligible for deletion.

If the deletion policy is set to NONE, and if you execute a deletion command for archived redo log files outside the fast recovery area, then RMAN obeys only the conditions specified on the deletion command.

TO SHIPPED TO  [ALL] STANDBY

Archived redo log files are eligible for deletion if both of the following conditions are met:

  • The archived redo log files have been transferred to the required remote destinations.

  • The logs are not needed by the BACKED UP ... TIMES TO DEVICE TYPE deletion policy. If the BACKED UP deletion policy is not set, then this condition is always met.

This policy is applicable to primary databases, standby databases, and FAR SYNC standby databases (if valid standby remote databases exist).

  • For primary databases, the archived redo log files are eligible for deletion after they are shipped to the standby. If no valid standby database exists, then RMAN uses TO NONE as the default policy.

    RMAN will not delete archived redo log files that are not shipped regardless of the archive log policy configuration, even when the policy is configured as TO NONE.

  • For standby databases, the archived redo log files are eligible for deletion after they are shipped to the cascading standby database. If no cascading standby is available, then this configuration is invalid.

Which remote destinations are considered depends on the following criteria:

  • If you do not specify ALL, then the archived redo log files are eligible for deletion after transfer to mandatory remote destinations only.

  • If you specify ALL, then the logs are eligible for deletion after transfer to all remote destinations, whether mandatory or not.

Note: It is invalid to specify the TO SHIPPED clause in combination with NONE or the TO APPLIED clause.

See Also: Oracle Data Guard Concepts and Administration for details


backupConf

This subclause manages persistent configurations relating to the BACKUP command. One configuration is backup optimization. If you enable backup optimization, then RMAN does not back up a file to a device type if the identical file is already backed up on the device type.

Table 2-3 explains the criteria used by backup optimization to determine whether a file is identical and can potentially be skipped. The table also explains the algorithm that RMAN uses when backup optimization is enabled and it needs to determine whether to skip the backup of an identical file. If RMAN does not skip a backup, then it makes the backup exactly as specified.

Table 2-3 Backup Optimization Algorithm

File TypeCriteria for an Identical FileBackup Algorithm When Backup Optimization Is Enabled

Data file

The data file must have the same DBID, checkpoint SCN, creation SCN, and RESETLOGS SCN and time as a data file already in a backup. The data file must be offline-normal, read-only, or closed normally.

If a recovery window-based retention policy is enabled, then whether RMAN skips a data file depends on the backup media.

For backups to tape, if the most recent backup is older than the recovery window, then RMAN takes another backup of a data file even if a backup of an identical data file exists. In this way, tapes can be recycled after they expire.

For backups to disk, RMAN skips the backup if an identical data file is available on disk, even if that backup is older than the beginning of the recovery window. The window-based retention policy causes RMAN to retain the old backup if it is needed.

If a retention policy is enabled with CONFIGURE RETENTION POLICY TO REDUNDANCY r , then RMAN skips backups only if at least n backups of an identical file exist on the specified device, where n=r+1.

If no retention policy is enabled, then RMAN skips a backup only if at least n backups of an identical file exist on the specified device. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

  1. BACKUP ... COPIES n

  2. SET BACKUP COPIES n

  3. CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n

  4. n=1

Archived redo log

The archived redo log must have the same thread, sequence number, and RESETLOGS SCN and time as an archived log already in a backup.

RMAN skips a backup only if at least n backups of an identical file exist on the specified device. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

  1. BACKUP ... COPIES n

  2. SET BACKUP COPIES n

  3. CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ... TO n

  4. n=1

Backup set

The backup set must have the same record ID and stamp as an existing backup set.

RMAN skips a backup only if at least n backups of an identical file exist on the specified device. By default, n=1. RMAN searches for other values of n in this order of precedence (that is, values higher on the list override values lower on the list):

  1. BACKUP ... COPIES n

  2. SET BACKUP COPIES n

  3. n=1



Syntax ElementDescription
{ARCHIVELOG | DATAFILE} BACKUP COPIES FOR DEVICE TYPE deviceSpecifier TO integer

Specifies the number of copies of each backup set for DATAFILE (both data files and control files) or ARCHIVELOG files on the specified device type (see Example 2-50). You can create from 1 (default) to 4 copies.

RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape and disk simultaneously. When backing up to tape, ensure that the number of copies does not exceed the number of available tape devices. Also, if COPIES is greater than 1, then the BACKUP_TAPE_IO_SLAVES initialization parameter must be enabled on the target database.

Control file autobackups are never duplexed. Also, duplexing is not permitted in the fast recovery area.

If duplexing is specified in the BACKUP command or in a SET BACKUP COPIES command, then the CONFIGURE setting is overridden.

BACKUP OPTIMIZATION [ON | OFF | CLEAR]

Toggles backup optimization ON or OFF (default). Specify CLEAR to return optimization to its default value of OFF.

Backup optimization is enabled when all of the following conditions are met:

  • The CONFIGURE BACKUP OPTIMIZATION ON command has been run.

  • You run BACKUP DATABASE, BACKUP ARCHIVELOG with the ALL or LIKE options, BACKUP BACKUPSET ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES, or BACKUP DATAFILECOPY.

  • The RMAN job uses a channel of only one device type.

Optimization prevents RMAN from backing up a file to a device type if the identical file is already backed up on the device type. RMAN does not signal an error if backup optimization causes all files to be skipped during a backup. The backup retention policy affects which files backup optimization skips.

For two files to be identical, their content must meet the requirements described in Table 2-3. When you create backup pieces on disk or on media managed by Oracle Secure Backup, optimization excludes undo data from the backup when the data does not belong to an active transaction.

Note: BACKUP ... DELETE INPUT deletes all specified archived redo log whether or not optimization would skip these files during a backup.

Note: You can override backup optimization with the FORCE option of the BACKUP command.

See Also: Oracle Database Backup and Recovery User's Guide for a description of how RMAN determines that it can skip the backup of a file

EXCLUDE FOR TABLESPACE tablespace_name [CLEAR]

Excludes the specified tablespace from BACKUP DATABASE and RESTORE DATABASE commands (see Example 2-52). You cannot exclude the SYSTEM tablespace.

The BACKUP command default does not exclude tablespaces. You must declare the option to use it. The exclusion is stored as an attribute of the tablespace and not to the individual data files. In this manner, the exclusion applies not only to the present set of data files but also to any files that are added to this tablespace in the future. If you run CONFIGURE ... CLEAR on a tablespace after excluding it, then it returns to the default configuration of nonexclusion.

You can still back up an excluded tablespace by explicitly specifying it in a BACKUP command or by specifying the NOEXCLUDE option on a BACKUP DATABASE command. Similarly, you can restore an excluded tablespace by specifying it in the RESTORE TABLESPACE command.

EXCLUDE FOR TABLESPACE pdb_name:tablespace_name [CLEAR]

The name of the tablespace in a PDB. Multiple PDBs can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. pdb-name is the name of a PDB.

See the previous description of EXCLUDE FOR TABLESPACE.

MAXSETSIZE

Specifies the maximum size of each backup set created on a channel. Use the CLEAR option to return MAXSETSIZE to the default value of UNLIMITED.

Note: This option is ignored by BACKUP AS COPY.

   TO sizeSpec

Specifies the maximum size of each backup set as integer gigabytes, kilobytes, or megabytes.

   TO UNLIMITED

Specifies no size limit for backup sets.

RETENTION POLICY

Specifies a persistent, ongoing policy for backup sets and copies that RMAN marks as obsolete, that is, not needed and eligible for deletion.

As time passes, RMAN marks backup sets and copies as obsolete according to the criteria specified in the retention policy. RMAN automatically deletes obsolete backup sets and copies in the fast recovery area when space is needed. RMAN does not automatically delete obsolete files outside the fast recovery area: you must manually execute DELETE OBSOLETE to remove them.

For backups, the basic unit of the retention policy is a backup set (not a backup piece) or image copy. For example, BACKUP AS BACKUPSET COPIES 4 TABLESPACE users creates a single backup set that is duplexed into four identical backup pieces. The retention policy considers this as one backup, not four separate backups.

Note: Use the CLEAR option to return RETENTION POLICY to its default of REDUNDANCY 1.

   TO NONE

Disables the retention policy feature. RMAN does not consider any backup sets or copies as obsolete.

   TO RECOVERY WINDOW OF integer DAYS

Specifies a time window in which RMAN can recover the database.

The window stretches from the current time (SYSDATE) to the point of recoverability, which is the earliest date to which you want to recover. The point of recoverability is SYSDATE - integer days in the past.

Note: The REDUNDANCY and RECOVERY WINDOW options are mutually exclusive. Only one type of retention policy can be in effect at any time.

   TO REDUNDANCY integer

Retains integer full or level 0 backups of each data file and control file. The default retention policy setting is REDUNDANCY 1.

If more than integer full or level 0 backups of a data file or control file exist, then RMAN marks these extra files as obsolete. RMAN then determines the oldest of the retained backups and marks all archived redo log files and log backups older than this backup as obsolete. The DELETE OBSOLETE command removes obsolete data file backups (full or incremental), control file backups, and archived log backups or image copies.

The following scenario illustrates how redundancy works in an incremental backup strategy. Assume that the redundancy level is 1. You run a level 0 database backup at noon Monday, a level 1 cumulative backup at noon on Tuesday and Wednesday, and a level 0 backup at noon on Thursday. Immediately after each daily backup you run a DELETE OBSOLETE. The Wednesday DELETE command does not remove the Tuesday level 1 backup because this backup is not redundant: the Tuesday level 1 backup could be used to recover the Monday level 0 backup to a time between noon on Tuesday and noon on Wednesday. However, the DELETE command on Thursday removes the previous level 0 and level 1 backups.

Note: The REDUNDANCY and RECOVERY WINDOW options are mutually exclusive. Only one type of retention policy can be in effect at any time.


cfauConf

This subclause creates persistent configurations relating to control file autobackups.


Syntax ElementDescription

CONTROLFILE AUTOBACKUP

Controls the control file autobackup feature.

By default, control file autobackup is turned on for CDBs and turned off for non-CDBs.

Note: Oracle recommends that you enable the control file autobackup feature.

   ON

Performs a control file autobackup in the following circumstances:

  • After every BACKUP or CREATE CATALOG command issued at the RMAN prompt.

  • Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP.

  • At the end of every RUN block if the last command in the block was BACKUP.

  • After structural changes for databases in ARCHIVELOG mode. The autobackup after structural changes does not occur for databases in NOARCHIVELOG mode.

    Structural changes include adding tablespaces, altering the state of a tablespace or data file (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, enabling or disabling Flashback Database, and so on. This type of autobackup, unlike autobackups that occur in the preceding circumstances, is only to disk. You can run CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set a nondefault disk location.

    Starting with Oracle 11g Release 2, RMAN creates a single autobackup file encompassing all of the structural changes that have occurred within a few minutes of each other rather than creating a new backup of the controlfile on each structural change to the database.

The first channel allocated during the backup or copy job creates the autobackup and places it into its own backup set; for post-structural autobackups, the default disk channel makes the backup. RMAN writes the control file and server parameter file to the same backup piece. After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log.

The default location for the autobackup on disk is the fast recovery area (if configured) or a platform-specific location (if not configured). RMAN automatically backs up the current control file using the default format of %F. You can change the location and file name format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT and SET CONTROLFILE AUTOBACKUP FORMAT commands.

You cannot configure RMAN to write the autobackup to multiple locations. To create multiple control file backups, you can make the last command in your backup job a BACKUP CURRENT CONTROLFILE FORMAT command, which backs up the control file to the specified FORMAT location and then executes an autobackup.

Note: The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the session only. The order of precedence is:

  1. SET within a RUN block

  2. SET at RMAN prompt

  3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

You can configure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CONTROLFILE AUTOBACKUP to ON.

   OFF

Disables the autobackup feature (default).

Any BACKUP command that includes data file 1 automatically includes the current control file and server parameter file in the backup set. Otherwise, RMAN does not include these files.

   CLEAR

Returns this configuration to its default setting of OFF.

   FORMAT FOR  DEVICE TYPE deviceSpecifier  TO formatSpec

Configures the default location and file name format for the control file autobackup on the specified device type (see Example 2-54).

By default, the format is %F for all devices. Any default format string specified with CONFIGURE must include the %F substitution variable. Use of any other substitution variable is an error. Specify CLEAR to return the format to the default %F.

If a fast recovery area is enabled, and if the format is the default '%F', then RMAN creates the autobackup in the recovery area in a directory named autobackup. Otherwise, the default autobackup location is an operating system-specific location (?/dbs on UNIX, Linux, and Windows).

The string # default in the output of the SHOW command indicates when RMAN is using the default format. If you manually configure the disk format to '%F', then RMAN creates the autobackups in the operating system-specific default location even though the recovery area is enabled. To change the format back to its default so that RMAN creates the autobackups in the recovery area, run CONFIGURE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR.

The formatSpec can specify an Automatic Storage Management disk group. The following example configures a channel for an ASM disk group:

CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1';

See Also: formatSpec for the semantics of the %F substitution variable


deviceConf

This subclause creates persistent configurations relating to channels and devices.

Names for Configured Channels

RMAN determines the names for configured channels. RMAN uses the following convention: ORA_devicetype_n, where devicetype refers to the user device type (such as DISK or sbt_tape) and n refers to the channel number. Channel names beginning with the ORA_ prefix are reserved by RMAN for its own use. You cannot manually allocate a channel with a name that begins with ORA_.

Note:

The sbt and sbt_tape device types are synonymous, but RMAN output always displays sbt_tape whether the input is sbt or sbt_tape.

RMAN names the first DISK channel ORA_DISK_1, the second ORA_DISK_2, and so on. RMAN names the first sbt channel ORA_SBT_TAPE_1, the second ORA_SBT_TAPE_2, and so on. When you parallelize channels, RMAN always allocates channels in numeric order, starting with 1 and ending with the parallelism setting (CONFIGURE DEVICE TYPE ... PARALLELISM n).

To run BACKUP or jobs on specific configured channels, use the system-generated channel names. If you specify channel numbers in the CONFIGURE CHANNEL command (see the deviceConf clause), then RMAN uses the same numbers in the system-generated channel names.

Automatic channel allocation also applies to maintenance commands. If RMAN allocates an automatic maintenance channel, then it uses the same naming convention as any other automatically allocated channel.

Configured Channels in an Oracle RAC Environment

When using RMAN in an Oracle RAC environment, Oracle recommends that you specify a TARGET connect string that establishes sessions on various instances in the cluster, depending on their load and availability.

Oracle does not recommend using the CONNECT option to configure individual channels to connect to specific Oracle RAC instances, because they make your RMAN script dependent on the particular instances named in the channel configuration. If just one of those instances is unavailable, then your backup script fails to run. Using a load-balancing connect string makes your RMAN scripts both easier to code and more resilient to individual instance failures.

If you decide to use the CONNECT option to direct RMAN channels to specific nodes, then Oracle strongly recommends that you not use passwords in your channel configuration. If the password for the user with SYSACKUP privilege for every instance is the same as the password in the TARGET connection, you only need to configure your channels with CONNECT "@nodename". RMAN connects to that channel with the user ID and password from the TARGET connection.


Syntax ElementDescription
[AUXILIARY] CHANNEL [ integer] DEVICE TYPE deviceSpecifier

Specifies the standard or AUXILIARY channel that you are configuring or clearing, and the device type of the channel.

Note: Channels allocated with ALLOCATE CHANNEL within a RUN command override configured automatic channels.

Either configure a generic channel or specify a channel number, where integer is less than 255. See Example 2-52 for an illustration of numbered channels.

If AUXILIARY is specified, then this configuration is used only for channels allocated at the auxiliary instance. Specify configuration information for auxiliary channels if they require different parameters from the channels allocated at the target instance. If no auxiliary device configuration is specified, then RMAN configures any auxiliary channels using the target database device configuration.

You must specify at least one channel option. For example, you cannot issue a command such as CONFIGURE CHANNEL 2 DEVICE TYPE DISK, but you can issue a command such as CONFIGURE CHANNEL 2 DEVICE TYPE DISK MAXPIECESIZE 2500K.

For generic channels of a specified device type, a new command erases previous settings for this device type. Assume that you run these commands:

CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 1G;
CONFIGURE CHANNEL DEVICE TYPE sbt FORMAT 'bkup_%U';

The second command erases the MAXPIECESIZE setting of the first command.

Note: RMAN does not simultaneously allocate automatic channels for multiple device types in the BACKUP command.

See Also: Oracle Database Backup and Recovery User's Guide to learn how configure automatic channels specified by channel number

   allocOperandList

Specifies control options for the configured channel.

If you configure channels by using the nondefault CONNECT or PARMS options to create backups or copies, then you must either use the same configured channels or manually allocate channels with the same options to restore or cross-check these backups.

The FORMAT parameter can specify an Automatic Storage Management disk group. The following example configures a channel for an ASM disk group:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

See Also: allocOperandList

   CLEAR

Clears the specified channel. For example, CONFIGURE CHANNEL 1 DEVICE TYPE DISK CLEAR returns only channel 1 to its default, whereas CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR returns the generic disk channel to its default. You cannot specify any other channel options (for example, PARMS) when you specify CLEAR.

DEFAULT DEVICE TYPE TO deviceSpecifier

Specifies the default device type for automatic channels. By default, DISK is the default device type. CLEAR returns the default device type to DISK.

By default, the BACKUP command only allocates channels of the default device type. For example, if you configure automatic channels for DISK and sbt and set the default device type to sbt, then RMAN only allocates tape channels when you run the BACKUP DATABASE command. You can override this behavior either by manually allocating channels in a RUN command, or by specifying DEVICE TYPE on the BACKUP command itself (see Example 2-50).

The RESTORE command allocates automatic channels of all configured device types, regardless of the default device type. The RESTORE command obeys the PARALLELISM setting for each configured device type.

DEVICE TYPE deviceSpecifier

Specifies the device type (disk or sbt) to which to apply the settings specified in this CONFIGURE command. The CLEAR option resets backup type and parallelism settings for this device to their defaults.

If you run the CONFIGURE DEVICE TYPE command to configure default settings for a device type and do not run CONFIGURE CHANNEL for this device type, then RMAN allocates all channels without other channel control options. Assume that you configure the sbt device and run a backup as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
BACKUP DEVICE TYPE sbt DATABASE;

In effect, RMAN does the following when executing this backup:

RUN 
{
  ALLOCATE CHANNEL ORA_SBT_TAPE_1 DEVICE TYPE sbt;
  BACKUP DATABASE;
}
   BACKUP TYPE TO [[COMPRESSED] BACKUPSET | COPY]

Configures the default backup type for disk or tape backups. For SBT devices the COPY option is not supported. The default for disk is BACKUPSET.

If BACKUP TYPE is set to BACKUPSET, then the BACKUP command always produces backup sets regardless of which media the backup is created on. With the COMPRESSED option, the backup sets produced use binary compression.

The default location for disk backups is the fast recovery area, if one is configured; otherwise, RMAN stores backups in a platform-specific location. The default format for backup file names is %U.

   PARALLELISM integer

Configures the number of automatic channels of the specified device type allocated for RMAN jobs. By default, PARALLELISM is set to 1.

Note: The CONFIGURE ... PARALLELISM parameter specifies channel parallelism, that is, the number of channels that RMAN allocates during backup and restore operations. The RECOVERY_PARALLELISM initialization parameter specifies the number of processes used in instance recovery.

Suppose you set PARALLELISM for disk backups to 2 (see Example 2-51). If you set the default device type as disk, then RMAN allocates two disk channels when you run BACKUP DATABASE at the RMAN prompt. RMAN always allocates the number of channels set by PARALLELISM, although it may use only a subset of these channels.

Note: If you configure n manually numbered channels, then the PARALLELISM setting can be greater than or less than n. For example, you can manually number 10 automatic channels and configure PARALLELISM to 2 or 12.

To change the parallelism for a device type to n, run a new CONFIGURE DEVICE TYPE ... PARALLELISM n command. For example, you can change configure PARALLELISM to 3 for sbt and then change it to 2 as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

Examples

Example 2-49 Configuring Device and Backup Options

This example configures channels of device type DISK and sbt and sets the default device type as sbt. The example also enables backup optimization and configures a recovery windows of two weeks.

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/backups/%U';
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_DEVICE_1=tape1)';
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;

Example 2-50 Overriding the Default Device Type

This example configures duplexing to 2 for DISK backups of data files and control files (control file autobackups on disk are a special case and are never duplexed), then configures sbt as the default device.

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_DEVICE_1=tape1)';
CONFIGURE DEFAULT DEVICE TYPE TO sbt;

The first BACKUP command backs up the archived redo log files on the default sbt channel. The second BACKUP command backs up the database to disk locations. Because duplexing is enabled for disk backups, two copies of each output backup set are created.

BACKUP ARCHIVELOG ALL;
BACKUP DEVICE TYPE DISK 
  DATABASE
  FORMAT '/disk1/db_backup_%U','/disk2/db_backup_%U';

Example 2-51 Configuring Automatic Channels Across File Systems

This example configures automatic disk channels across two file systems:

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U';

Because PARALLELISM is set to 2, the following command divides the output data between two file systems:

BACKUP DEVICE TYPE DISK
  DATABASE PLUS ARCHIVELOG;

The following LIST command shows how the data file backup was parallelized:

RMAN> LIST BACKUPSET 2031, 2032;
 
List of Backup Sets
========'\===========
 
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2031    Full    401.99M    DISK        00:00:57     19-JAN-13
        BP Key: 2038   Status: AVAILABLE  Compressed: NO  Tag: TAG20130119T100532
        Piece Name: /disk1/24i7ssnc_1_1
  List of Datafiles in backup set 2031
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 973497     19-JAN-13 /disk3/oracle/dbs/t_db1.f
  5       Full 973497     19-JAN-13 /disk3/oracle/dbs/tbs_112.f
 
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2032    Full    133.29M    DISK        00:00:57     19-JAN-13
        BP Key: 2039   Status: AVAILABLE  Compressed: NO  Tag: TAG20130119T100532
        Piece Name: /disk2/25i7ssnc_1_1
  List of Datafiles in backup set 2032
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  2       Full 973501     19-JAN-13 /disk3/oracle/dbs/t_ax1.f
  3       Full 973501     19-JAN-13 /disk3/oracle/dbs/t_undo1.f
  4       Full 973501     19-JAN-13 /disk3/oracle/dbs/tbs_111.f

Example 2-52 Configuring Automatic Channels in an Oracle Real Application Clusters (Oracle RAC) Configuration

This example assumes an Oracle RAC database with two nodes. Oracle Secure Backup is the media manager. Tape drive tape1 is directly attached to node1, while tape drive tape2 is directly attached to node2. The example configures an automatic SBT channel for each cluster node.

This example illustrates channel connections to Oracle RAC instances node1 and node2. For both channel connections, RMAN uses the same user name and password that were entered for the target database connection.

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT '@node1'
  PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT '@node2'
  PARMS 'ENV=(OB_DEVICE=tape2)';

Example 2-53 Configuring Auxiliary File Names

This example uses CONFIGURE AUXNAME to specify new file names for the data files. The DUPLICATE command duplicates a database to a remote host with a different directory structure.

# set auxiliary names for the data files 
CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; 
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f'; 
CONFIGURE AUXNAME FOR DATAFILE 3 TO '/oracle/auxfiles/aux_3.f'; 
CONFIGURE AUXNAME FOR DATAFILE 4 TO '/oracle/auxfiles/aux_4.f'; 

RUN
{  
  ALLOCATE AUXILIARY CHANNEL dupdb1 TYPE DISK;
  DUPLICATE TARGET DATABASE TO dupdb 
  LOGFILE
    GROUP 1 ('?/dbs/dupdb_log_1_1.f', 
             '?/dbs/dupdb_log_1_2.f') SIZE 4M,
    GROUP 2 ('?/dbs/dupdb_log_2_1.f', 
             '?/dbs/dupdb_log_2_2.f') SIZE 4M REUSE; 
}
# Unspecify the auxiliary names for the data files so that they are not 
# overwritten by mistake:
CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; 
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; 
CONFIGURE AUXNAME FOR DATAFILE 3 CLEAR; 
CONFIGURE AUXNAME FOR DATAFILE 4 CLEAR;

Example 2-54 Specifying the Default Format for Control File Autobackup

The following example enables the autobackup feature and configures the default autobackup format for the DISK and sbt devices:

CONFIGURE CONTROLFILE AUTOBACKUP ON; 
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/disk2/%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'cf_auto_%F';

Example 2-55 Creating Configurations for Standby Databases

Assume that primary database prod is associated with two standby databases with the DB_UNIQUE_NAME names dgprod3 and dgprod4. Assume that you start RMAN and connect to prod as TARGET and connect to a recovery catalog. The following commands configure the default device type for databases dgprod3 and dgprod4.

CONFIGURE DEFAULT DEVICE TYPE TO sbt
  FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2
  FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK
  FOR DB_UNIQUE_NAME dgprod4;

The control files of the two standby databases are updated with the configuration only after the reverse resynchronization from the recovery catalog to the control file, which occurs the first time that the user connects to dgprod3 and dgprod4.

The following SHOW command displays the persistent device type configurations for the database whose unique name is dgprod3:

RMAN> SHOW DEVICE TYPE FOR DB_UNIQUE_NAME dgprod3;
RMAN configuration parameters for database with db_unique_name DGPROD3 are:

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

The following SHOW command displays the persistent configurations for all databases known to the recovery catalog whose DBID is 3257174182 (the value specified by the preceding SET DBID command):

SHOW ALL FOR DB_UNIQUE_NAME ALL;

Example 2-56 Optimizing Backups

This scenario illustrates the backup optimization behavior described in Table 2-3. Assume that backup optimization is disabled. At 9 a.m., you back up three copies of all existing archived redo log files to tape. The BACKUP_TAPE_IO_SLAVES initialization parameter must be true when duplexing backups to tape.

BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;

At 11 a.m., you enable backup optimization:

CONFIGURE BACKUP OPTIMIZATION ON;

At noon, you run the following archived redo log backup:

BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
Starting backup at 19-JAN-13
current log archived
using channel ORA_SBT_TAPE_1
skipping archived log file /d1/db1r_605ab325_1_34_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_35_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_36_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_37_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_38_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_39_612112605.arc; already backed up 3 time(s)
channel ORA_SBT_TAPE_1: starting archived log backup set
channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=40 RECID=170 STAMP=612270506
channel ORA_SBT_TAPE_1: starting piece 1 at 19-JAN-13
channel ORA_SBT_TAPE_1: finished piece 1 at 19-JAN-13 with 2 copies and tag TAG20130119T110827
piece handle=2hi7t0db_1_1 comment=API Version 2.0,MMS Version 10.1.0.0
piece handle=2hi7t0db_1_2 comment=API Version 2.0,MMS Version 10.1.0.0

In this case, the BACKUP ... COPIES setting overrides the CONFIGURE ... COPIES setting, so RMAN sets n=2. RMAN skips the backup of a log only if at least two copies of the log exist on the sbt device. Because three copies of each log exist on sbt of all the logs generated on or before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet been backed up to tape.

Example 2-57 Configuring a Default Compression Algorithm

This example assumes that you have a license for the Advanced Compression Option (ACO) of the database.

If you want to make the MEDIUM compression algorithm the default compression algorithm for all compressed backups, issue the following:

CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';

From this point on, you can use the MEDIUM compression algorithm by issuing the following command:

BACKUP AS COMPRESSED BACKUPSET DATABASE;
PK^򅷧PKC|JOEBPS/rcmsubcl011.htm foreignlogRecordSpecifier

foreignlogRecordSpecifier

Purpose

Use the foreignlogRecordSpecifier subclause to specify a set of foreign archived redo log files for use in RMAN operations.

Usage Notes

Foreign archived redo log files are received by a logical standby database for a LogMiner session. Unlike normal archived logs, foreign archived logs have a different DBID. For this reason, they cannot be backed up or restored on a logical standby database.

A logical standby database creates foreign archived logs in the fast recovery area if the following conditions are met:

  • A fast recovery area is configured on the logical standby database.

  • a LOG_ARCHIVE_DEST_n initialization parameters is set to 'LOCATION=USE_DB_RECOVERY_FILE_DEST' with a proper VALID_FOR setting to receive foreign archived logs.

  • The COMPATIBLE initialization parameter is set to a value greater than or equal to 11.0.0.

Syntax

foreignlogRecordSpecifier::=

Description of GUID-E27892E5-9D5B-48AA-A3E4-93E59F8C6838-print.eps follows

archlogRange::=

Description of GUID-C5D12267-E268-488C-97D7-EB2173DF83AB-print.eps follows

Semantics

The semantics duplicate archivelogRecordSpecifier except that the logs are foreign archived redo log files.

Examples

Example 4-21 Crosschecking Foreign Archived Redo Log Files

This example crosschecks all foreign archived redo log files:

RMAN> CROSSCHECK FOREIGN ARCHIVELOG ALL;
PKBPKC|JOEBPS/rcmsynta2008.htm RESTORE

RESTORE

Purpose

Use the RESTORE command to restore, validate, or preview RMAN backups. Typically, you restore backups when a media failure has damaged a current data file, control file, or archived redo log or before performing a point-in-time recovery.

Prerequisites

To restore data files to their current location, the database must be started, mounted, or open with the tablespaces or data files to be restored offline.

If you use RMAN in a Data Guard environment, then connect RMAN to a recovery catalog.

If you are performing a trial restore of the production database, then perform either of the following actions before restoring the database in the test environment:

  • If the test database uses a fast recovery area that is physically different from the recovery area used by the production database, then set DB_RECOVERY_FILE_DEST in the test database instance to the new location.

  • If the test database uses a fast recovery area that is physically the same as the recovery area used by the production database, then set DB_UNIQUE_NAME in the test database instance to a different name from the production database.

If you do not perform either of the preceding actions, then RMAN assumes that you are restoring the production database and deletes flashback logs from the fast recovery area because they are considered unusable.

Usage Notes

The RESTORE command restores full backups, level 0 incremental backups, or image copies. You can restore files to their default location or a different location.

By default, RMAN examines read-only data files to make sure they exist, are readable, and have the correct checkpoint. If any of the conditions is not met, then RMAN restores the files. If all of the conditions are met, then RMAN does not restore the files.

Backup Selection

By default, RESTORE chooses the most recent backup set or file copy, that is, the file copy or backup set that needs the least media recovery. RMAN only restores backups created on the same type of channels allocated by the RESTORE command. For example, if you made backups of a data file with DISK and sbt channels, and if only a DISK channel is allocated for the RESTORE command, then RMAN does not restore the sbt backups. If you do not manually allocate channels, then RMAN allocates all automatic channels that it possibly needs, subject to any restrictions imposed by the DEVICE TYPE option.

In an Oracle RAC configuration, RMAN automatically restores backups, control file copies, and data file copies from channels that can read the files on tape or a local file system. For example, if channel ch1 connected to inst1 can read log 1000 from its tape drive, but channel ch2 connected to inst2 cannot read the same log from its tape drive, then ch2 cannot participate in restoring the log and so ch1 restores the log. Autolocation is automatically enabled when the channels have different PARMS or CONNECT settings.

If data file names are symbolic links, then the control file stores the file names of the link files but RMAN performs I/O on the data files pointed to by the link files. If a link file is lost and you restore a data file without re-creating the symbolic link, then RMAN restores the data file to the location of the link file rather than to the location pointed to by the link file.

See Also:

Oracle Database Backup and Recovery User's Guide for details on restore failover

Restore Operations for CDBs and PDBs

The RESTORE command can be used to restore a whole multitenant container database (CDB), the root, one or more pluggable databases (PDBs), and tablespaces in a PDB. The information in this section about restoring data is also applicable to restoring CDBs and PDBs.

The process of restoring CDBs and PDBs is similar to that of non-CDBs. The only differences are in connecting to the database and in the commands used. To restore a whole CDB, the root, or multiple PDBs, you connect to the root. To restore a particular PDB, you connect to that PDB. While restoring PDBs, use RESTORE PLUGGABLE DATABASE. To restore a CDB, use RESTORE DATABASE and to restore the root, use RESTORE DATABASE ROOT.

See Also:

"CONNECT" for information about connecting to CDBs and PDBs

Restore Operations Using Encrypted Backup Sets

As explained in "Encryption of Backup Sets", how RMAN handles encrypted backup sets during restore operations depends on the encryption mode with which the backup was created. You can use CONFIGURE and SET to manage the RMAN backup encryption settings for your database. Note the following restore considerations:

  • For transparent-mode encrypted backups, the required passwords must be available in the Oracle software keystore. The same keystore used when creating the backup must be open and available when restoring it. If a password-based keystore was used while creating the backups, then you must use SET DECRYPTION WALLET OPEN IDENTIFIED BY to provide the password used to open the keystore.

  • For password-mode encrypted backups, the required passwords must be provided with SET DECRYPTION.

  • For dual-mode encrypted backups, the required passwords must be available in the Oracle software keystore or provided with SET DECRYPTION.

Note:

Keystore-based encryption is more secure than password-based encryption because no passwords are involved. Use password-based encryption only when absolutely necessary because your backups must be transportable.

Restore Failover

If a backup piece, image copy or proxy copy is inaccessible or if a block is corrupted, then RMAN performs restore failover. The RESTORE command automatically looks for another usable copy of a backup or image copy on the same device and other devices. If no usable copies are available, then RMAN searches for previous backups. RMAN continuously searches for previous usable backups until it has exhausted all possibilities. RMAN automatically uses eligible backups from previous database incarnations if required.

If you are restoring a data file for which no backups are available, then RMAN creates an empty data file with the checkpoint change as creation SCN. During recovery, all archived redo log files back to the creation of the data file are restored, and all changes during the history of the data file are reapplied to re-create its contents.

Location of Restored Data Files

If you restore data files to the default location, then RMAN overwrites files with the same file names. By default, RMAN does not restore a data file if it is in the correct place and its header contains the expected data. RMAN does not scan the data file body for corrupt blocks.

If RMAN detects that the default file name cannot be used (for example, the file may be an Oracle-managed file or on an Automatic Storage Management disk group), then RMAN attempts to create a new file in the same location or disk group.

RMAN restores data files to the location currently stored in the recovery catalog. This default behavior eliminates problems with restoring data files to locations that may have become obsolete since the time of the original backup. It also means that if you have changed the location of the data files from their original backup location, that RMAN restores the files to the most current or changed location.

To restore files to a nondefault location, use SET NEWNAME commands to rename the restored files and then use a SWITCH command to make the restored files current (as illustrated in Example 3-22). If you do not issue SWITCH commands, then RMAN considers the restored files as valid copies for use in future restore operations. Table 3-8 describes the behavior of the RESTORE, SET NEWNAME, and SWITCH commands.

Table 3-8 SET NEWNAME, SWITCH, and RESTORE

SET NEWNAME RunSWITCH RunRESTORE Behavior

No

N/A

RMAN restores the files to the most recent location stored in the recovery catalog.

Yes

Yes

RMAN restores the files to the path names specified by SET NEWNAME. RMAN replaces the current data file names in the control file with the names of the restored files. RMAN records the data files with the old names as data file copies.

Yes

No

RMAN restores the files to the path names specified by SET NEWNAME. RMAN does not update the current data file names in the control file. The restored files are listed in the RMAN repository as data file copies.

Because temp files cannot be backed up and because no redo is ever generated for them, RMAN never restores or recovers temp files. RMAN does track the names of temp files, but only so that it can automatically re-create them when needed.

RMAN Behavior When Restoring Control Files

The behavior of RMAN when restoring control files depend on a variety of factors, which are summarized in Table 3-9. Required commands and options for restoring autobackups are summarized in Table 3-10.

Table 3-9 RESTORE CONTROLFILE Scenarios

RMAN ConnectionRESTORE CONTROLFILE;RESTORE CONTROLFILE FROM AUTOBACKUP;RESTORE CONTROLFILE ... TO 'filename';RESTORE CONTROLFILE ... FROM 'media_handle' or TAG 'user_tag';

No catalog, target database started in NOMOUNT state

Error. Must specify FROM AUTOBACKUP.

Restores to CONTROL_FILES locations. See Table 3-10 for required commands and options.

Must specify FROM AUTOBACKUP. Restores only to filename.

First run SET DBID. Restores from specified file (cannot restore from TAG). If TO 'filename' not used, restores to all CONTROL_FILES locations.

No catalog, target database mounted or open

Error. Must use TO 'filename', where filename is not in CONTROL_FILES list.

Error. Must use TO 'filename', where filename is not in CONTROL_FILES list.

Restores only to filename, where filename is not in CONTROL_FILES list.

RMAN issues error RMAN-06496. Use TO 'filename' instead.

Catalog, target database started in NOMOUNT state

Restores to CONTROL_FILES locations. Run SET DBID only if DB_NAME not unique in catalog.

Only use with recovery catalog for testing.

Restores only to filename, where filename is not in CONTROL_FILES list.

Restores from specified file. If TO 'filename' not used, restores to all CONTROL_FILES locations.

Catalog, target database mounted or open

Error. Must use TO 'filename', where filename is not in CONTROL_FILES list.

Do not use with recovery catalog.

Restores only to filename, where filename is not in CONTROL_FILES list.

RMAN issues error RMAN-06496. Use TO 'filename' instead.

If you use RMAN in a Data Guard environment, then RMAN transparently converts primary control files to standby control files and vice versa. RMAN automatically updates file names for data files, online redo logs, standby redo logs, and temp files when you issue RESTORE and RECOVER. The recovery catalog always contains the correct information about the backup file names for each database, as explained in "RMAN Backups in a Data Guard Environment".

Control File and Server Parameter File Autobackup Options

When restoring an autobackup, the commands and options that you use depend on the autobackup type (control file or server parameter file) and location (inside or outside fast recovery area). The options are summarized in Table 3-10.

Table 3-10 RESTORE ... FROM AUTOBACKUP

Restore ObjectAutobackup LocationRun SET DBID?Specify RECOVERY AREA on RESTORE?Specify DB_NAME or DB_UNIQUE_NAME on RESTORE?Run SET CONTROLFILE AUTOBACKUP FORMAT?

SPFILE

Recovery area

No

Yes

Yes

No

SPFILE

Outside recovery area

Yes

No

No

Only if autobackup is not in default location

Control file

Recovery area

No

Only if autobackup is in noncurrent recovery area

Only if autobackup is in noncurrent recovery area and uses a noncurrent DB_UNIQUE_NAME

No

Control file

Outside recovery area

Yes

No

No

Only if autobackup is not in default location

Restoring Data Files and Control Files Using Files from a Remote Host

Starting with Oracle Database 12c, you can restore a database, data files, control files, tablespaces, or an spfile using files from a remote database. RMAN connects to the remote database and transfers the required files, over the network, to the target database using backup sets. This is very useful in a Data Guard environment. You can restore data files on a primary database by connecting to a standby database over the network. You can also restore data files on a standby database by connecting to the primary database.

While restoring files from a remote host over the network, you must use FROM SERVICE to specify the service name of the remote host from which the files are obtained. Optionally, use SECTION SIZE to restore files from the source database as multisection backup sets. You can compress the transferred files by specifying the USING COMPRESSED BACKUPSET.

To encrypt the files being transferred from the source database, use the SET ENCRYPTION command before the RESTORE command. You can also use SET COMPRESSION ALGORITHM to specify the algorithm used to compress the backup sets before transferring them over the network.

Prerequisites for Restoring Files Using a Remote Host

  • The password file on the source database and the target database must be the same.

  • The tnsnames.ora file in the target database must contain an entry that corresponds to the remote database.

Syntax

restore::=

Description of GUID-C7795283-5E74-4F42-B4EB-72F455DC5A16-print.eps follows

(restoreObject::=, restoreSpecOperand::=, deviceSpecifier::=, untilClause::=)

restoreObject::=

Description of GUID-3D472F64-D318-45B7-90C9-8B6785283ABF-print.eps follows

(archivelogRecordSpecifier::=, datafileSpec::=, foreignFileSpec::=)

restoreSpecOperand::=

Description of GUID-B8422B02-EB4E-4705-91A8-3330EC2D2DF1-print.eps follows

autoBackupOptList::=

Description of GUID-6D6807AE-8D5A-407D-81F0-0C1C8C7E4017-print.eps follows

Semantics

restore

This clause enables you to select which files you want to restore and specify parameters that control the behavior of the restore operation.


Syntax ElementDescription

restoreObject

Specifies the files to be restored.

restoreSpecOperand

Specifies options for the restoreObject clause.

CHANNEL channel_id

Refer to the restoreSpecOperand clause.

CHECK LOGICAL

Tests data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert log and server session trace file.

If the total number of physical and logical corruptions detected in a file is less than its SET MAXCORRUPT setting, then the RMAN command completes and the database populates the V$DATABASE_BLOCK_CORRUPTION view with corrupt block ranges. If MAXCORRUPT is exceeded, then the command terminates without populating the views.

When restoring a backup data file, RMAN honors the DB_BLOCK_CHECKSUM initialization parameter setting. RMAN clears the checksum if DB_BLOCK_CHECKSUM is set to false. If set to typical, then RMAN verifies the checksum when restoring from the backup and writing to the data file. If the initialization parameter DB_BLOCK_CHECKSUM=typical, and if MAXCORRUPT is not set, then specifying CHECK LOGICAL detects all types of corruption that are possible to detect.

Note: The MAXCORRUPT setting represents the total number of physical and logical corruptions permitted on a file.

DEVICE TYPE deviceSpecifier

Allocates automatic channels for the specified device type only. For example, if you configure automatic disk and tape channels, and issue RESTORE ... DEVICE TYPE DISK, then RMAN allocates only disk channels. You must configure a device type by using CONFIGURE (except for DISK, which is preconfigured) before specifying the DEVICE TYPE option.

Note: You cannot manually allocate channels within a RUN block and then run RESTORE with the DEVICE TYPE clause.

See Also: deviceSpecifier

FORCE

Overrides the restartable restore feature and restores all files regardless of whether they must be restored. If you do not specify FORCE, then RMAN restores a file only if its header information does not match the information in the control file.

FROM BACKUPSET

Restores from backup sets only. By default RESTORE chooses the file copy or backup set that needs the least media recovery.

If you use the FROM BACKUPSET option, then channels for the appropriate type of storage devices must be allocated for the backup sets that must be restored. For example, if needed backups are only available on tape, and no sbt channels have been allocated, then RMAN cannot find a candidate backup set to restore, and the RESTORE command fails.

FROM DATAFILECOPY

Restores data file copies only. By default RESTORE chooses the file copy or backup set that needs the least media recovery. If you use the FROM DATAFILECOPY option, then the allocated channels must be of DEVICE TYPE DISK.

   INSTANT FULL

This clause is reserved for a future release.

   INSTANT SPARSE

This clause is reserved for a future release.

FROM PLATFORM platform

Specifies the name of the platform on which the cross platform backup was created. Cross-platform data transportation is supported starting with Oracle Database 12c Release 1 (12.1). This clause must be accompanied by a foreignFileSpec that specifies the backup sets that contain the data to be restored. The FROM PLATFORM clause is optional. You can restore a cross-platform backup by specifying only a foreignFileSpec. However, if you specify a platform name using FROM PLATFORM, the name must match the platform identifier stored in the cross-platform backup header.

FROM SERVICE service_name

Restores data files, control files, or the spfile on the target database using files transferred over the network from a remote database. service_name specifies the service name of the remote database.

Note: Restoring files over the network is supported starting with Oracle Database 12c.

FROM TAG tag_name

Refer to the restoreSpecOperand clause.

PREVIEW

Reports—but does not restore—the backups and archived redo log files that RMAN could use to restore and recover the database to the specified time. RMAN queries the metadata and does not actually read the backup files.

The RESTORE ... PREVIEW output is in the same format as the LIST BACKUP output (see Example 3-27).

Some media managers provide status information to RMAN about which backups are offsite. Offsite backups are stored in a remote location, such as a secure storage facility, and cannot be used without retrieving media.

Offsite backups are marked as AVAILABLE in the RMAN repository even though the media must be retrieved from storage before the backup can be restored. If RMAN attempts to restore a offsite backup, then the restore operation fails. RESTORE ... PREVIEW can identify backups needed for a RESTORE operation that are stored on media that requires retrieval. The output indicates whether backups are stored offsite.

If a needed backup is stored offsite, but the media manager does not support offsite backups, then your options are:

  • Use CHANGE ... UNAVAILABLE to prevent RMAN from selecting the needed offsite backups, and attempt the RESTORE ... PREVIEW operation again to determine whether RMAN selects another offsite backup. When RMAN does not select any offsite backups, you can perform the restore operation.

  • Use RESTORE ... PREVIEW with the RECALL option.

See Also: LIST, specifically the BACKUPS and SUMMARY options, and the RECOVER ... VALIDATE HEADER command

   RECALL

Instructs the media manager to retrieve the backup media needed for the specified restore operation from offsite storage (see Example 3-28).

Note: This option only works if your media manager supports this functionality. You can use RESTORE ... PREVIEW periodically to monitor whether the needed backups are stored locally again.

   SUMMARY

Summarizes the backups that RMAN would restore. The output is in the same format as the output of the LIST BACKUPS ... SUMMARY command.

SECTION SIZE

Restores a multi-section backup.

SKIP READONLY

Does not restore read-only files.

TO RESTORE POINT restore_point_name

Specifies a restore point, with the SCN at which the restore point was created as the upper, inclusive limit. Because the limit is inclusive, RMAN selects only files that it can use to restore files up to and including the SCN corresponding to the restore point.

untilClause

Limits the selection to backup sets or file copies that are suitable for a point-in-time recovery to the specified time, SCN, or log sequence number.

In the absence of any other criteria, RMAN selects the most current file copy or backup set to restore. The time specified in the UNTIL clause must fall within the current database incarnation.

See Also: untilClause

USING [COMPRESSED] BACKUPSET

Specifies that the files being restored, over the network, must be transferred from the remote database as compressed backup sets. By default, RMAN transfers files as backup sets. Therefore, even when you omit the USING BACKUPSET clause, the files are transferred as backup sets.By default, compression is performed by using the compression algorithm that is set in the RMAN configuration. You can use a different compression algorithm by executing the SET COMPRESSION ALGORITHM command before executing the RESTORE command.

VALIDATE

RMAN identifies which backup sets, data file copies, and archived redo log files must be restored, and then validates them (see Example 3-29). No files are restored.

For files on both disk and tape, RMAN reads all blocks in the backup piece or image copy. RMAN also validates offsite backups. The validation is identical to a real restore operation except that RMAN does not write output files.

Note: If you use RESTORE with the VALIDATE option, then the database can be open with data files online.

See Also: VALIDATE

   HEADER

Reports and validates—but does not restore—the backups that RMAN could use to restore to the specified time.

When you specify this option, RMAN performs the same functions as when you run RESTORE with the PREVIEW option. However, in addition to listing the files needed for restore and recovery, RMAN validates the backup file headers to determine whether the files on disk or in the media management catalog correspond to the metadata in the RMAN repository.

See Also: The descriptions of the RESTORE PREVIEW option and the RECOVER ... VALIDATE HEADER option


restoreObject

This subclause specifies the objects to be restored: control files, data files, archived redo log files, or the server parameter file. RMAN does not support backup and recovery of the change tracking file. RMAN re-creates the change tracking file after database restore and recovery; the next incremental backup after any recovery can use the file. Thus, restore and recovery has no user-visible effect on change tracking.


Syntax ElementDescription

archivelogRecordSpecifier

Restores the specified range of archived redo log files.

The default restore location is DB_RECOVERY_FILE_DEST (if one of LOG_ARCHIVE_DEST_n is configured to USE_DB_RECOVERY_FILE_DEST either implicitly or explicitly). Otherwise, the default restore file names are constructed with the LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_DEST_1 initialization parameters of the target database. These parameters combine in a port-specific fashion to derive the name of the restored log. You can override the default location with the SET ARCHIVELOG DESTINATION command.

Because the RECOVER command automatically restores archived redo log files as needed, you seldom need to restore logs manually. Possible reasons for manually restoring archived redo log files are to speed up recovery, to stage the logs to multiple destinations, or to analyze the log contents after a point-in-time recovery. To restore logs from a previous incarnation without shutting down the database, you can use RESTORE ARCHIVELOG with:

  • ... FROM SCN

  • ...SCN BETWEEN... AND

  • FROM SCN ... INCARNATION <integer>

  • FROM SCN... INCARNATION ALL

Note: The database can be started, mounted, or open for this operation.

See Also: archivelogRecordSpecifier.

CONTROLFILE

Restores either a standby or backup control file depending on the target database role.

If the control file is lost, then restore the control file (see Table 3-9) and restore the database after mounting the restored control file. You must always run the RECOVER command after mounting a restored control file and you must open the database with the RESETLOGS option.

Note: If the target database is not mounted, and if RMAN is not connected to a recovery catalog, then you must specify the FROM AUTOBACKUP clause with RESTORE CONTROLFILE. If the autobackup is in a nondefault format, then first use the SET CONTROLFILE AUTOBACKUP FORMAT command to specify the format. If the target database is mounted or open, then you must specify the TO filename clause with RESTORE CONTROLFILE.

When you run RESTORE with a backup control file while connected to a recovery catalog (see Example 3-23), RMAN automatically updates the control file to reflect the structure of the restored database based on the metadata in the catalog.

   TO 'filename'

Restores the control file to the specified file name.

Table 3-9 explains RMAN behavior when restoring the control file with the TO clause.

DATABASE

Restores all data files in the database except those that are offline. By default, RMAN restores data files in read-only tablespaces.

In a CDB, restores the whole CDB. You connect to the root to restore the CDB. In a PDB, restores the data files in the specified PDB. To backup a PDB, connect to that PDB. See "Connecting to CDBs and PDBs".

Unlike BACKUP DATABASE, RESTORE DATABASE does not automatically include the control file and the server parameter file—you must issue additional RESTORE CONTROLFILE and RESTORE SPFILE commands to restore these files.

Note: To restore offline data files you must use RESTORE DATAFILE or RESTORE TABLESPACE.

DATABASE ROOT

In a CDB, restores all online data files belonging to the root. Connect to the root as described in "Connecting to CDBs and PDBs".

PLUGGABLE DATABASE pdb_name

In a CDB, restores all data files belonging to the specified PDB. No other PDBs are affected; they can remain open and operational. Use a comma-separated list to restore multiple PDBs. Connect to the root as described in "Connecting to CDBs and PDBs".

   SKIP [FOREVER]  TABLESPACE tablespace_name

Excludes the specified tablespaces from the restore operation. This option is useful to avoid restoring tablespaces containing temporary data. In a CDB, refers to a tablespace in the root when connected to the root, and refers to a tablespace in a PDB when connected directly to the PDB.

Specifying the FOREVER keyword does not change the behavior of SKIP. The FOREVER keyword exists solely to maintain compatible syntax between RESTORE SKIP FOREVER and RECOVER SKIP FOREVER.

   TABLESPACE pdb_name:tablespace_name

In a CDB, excludes the specified tablespaces from the restore operation. This syntax is required only when connected to the root. When connected directly to a PDB, use TABLESPACE tablespace_name.

DATAFILE datafileSpec

Restores the data files specified by file name or absolute data file number (see Example 3-22).

Note: Do not specify a data file more than once in a restore job. For example, the following command is invalid because data file 1 is both specified explicitly and implied by the SYSTEM tablespace:

RESTORE TABLESPACE SYSTEM DATAFILE 1;

See Also: datafileSpec

   foreignFileSpec

Restores a cross-platform backup that uses backup sets. Specifying foreignFileSpec is mandatory when you perform a cross-platform restore operation. This clause specifies the data that must be restored (data files, tablespaces, or entire database) and the backup sets that contain the data to be restored. The cross-platform backup that is being restored can consist of multiple backup sets or multiple backup pieces.

Use the BACKUPSET syntax to specify the backup set to be restored. To restore data files, use ALL FOREIGN DATAFILES or FOREIGN DATAFILE. To restore tablespaces. use FOREIGN TABLESPACE. To restore an entire database, use FOREIGN DATABASE.

To plug the restored tablespaces in to the destination database, you use the export dump file containing the tablespace metadata that was created along with the backup. Use DUMP FILE to indicate that the backup contains an export dump file and BACKUPSET to specify the backup set that contains the export dump file.

Note: This clause can be used only to restore data that was backed up using backup sets. It cannot be used for backups created as image copies.

See Also: foreignFileSpec

PRIMARY CONTROLFILE

Restores a control file for a primary database in a Data Guard environment.

RMAN restores either a normal or standby control file as appropriate, depending on the most recent database role known to the recovery catalog (RC_SITE.DATABASE_ROLE) for the target database. The purpose of this option to override the default setting in cases where the most recent database role is out-of-date.

Assume that you perform a switchover from primary database dgny to standby database dgsf, so that dgsf is the new primary database. You want to restore a control file on dgsf, but the recovery catalog was not resynchronized and still shows dgsf as a standby database. In this case, you can specify PRIMARY CONTROLFILE to override the default RMAN behavior and restore a normal control file.

SPFILE

Restores a primary or standby server parameter file to the location from which it was backed up. RMAN cannot overwrite a server parameter file currently in use by the target database.

By default RMAN restores the most current server parameter file. Specify the UNTIL or TAG options to restore older versions of the server parameter file.

If the server parameter file is lost, then connect RMAN to the target database (and recovery catalog if used) and run SET DBID. Run STARTUP FORCE NOMOUNT before running RESTORE SPFILE. Then run STARTUP FORCE to restart the database instance with the restored server parameter file.

Note: If the target database is not mounted, and if RMAN is not connected to a recovery catalog, then you must specify the FROM AUTOBACKUP clause with RESTORE SPFILE. If the autobackup is in a nondefault format, then first use the SET CONTROLFILE AUTOBACKUP FORMAT command to specify the format. If the target database is started, mounted, or open, and if the database was started with a server parameter file, then you must specify the TO filename clause with RESTORE SPFILE.

   TO [PFILE] 'filename'

Restores a primary or standby server parameter file to the location specified by the TO clause. Specify PFILE to save the server parameter file as a text-based initialization parameter file.

   FOR DB_UNIQUE_NAME db_unique_name

Specifies the DB_UNIQUE_NAME for the target database when the instance is not started. This parameter is only useful in a Data Guard environment.

When FOR DB_UNIQUE_NAME is specified, RMAN can locate the correct RMAN configurations for the host on which the SPFILE is being restored and use them to access backup devices. Otherwise, RMAN cannot choose the correct channel configurations and returns an RMAN-6758 error.

In a Data Guard environment, the primary and standby hosts may have different channel configurations for communicating with their associated SBT backup and disk devices. If both the primary and standby databases are known to the recovery catalog, then the configuration settings for both databases are recorded in the recovery catalog. Because the two databases have the same DB_NAME, the records in the recovery catalog can only be distinguished with the DB_UNIQUE_NAME initialization parameter.

Note: Using RESTORE SPFILE when the DB_NAME is not unique in the recovery catalog produces an RMAN-6758 error.

See Also: Oracle Data Guard Concepts and Administration for a detailed procedure for restoring the server parameter file in a Data Guard environment

   TO 'filename'

Restores the standby control file to the specified file name. Table 3-9 explains the RMAN behavior when restoring the control file with the TO clause.

STANDBY CONTROLFILE

Restores a control file for a standby database. RMAN can transparently restore a normal control file backup and make it usable for a standby database.

RMAN restores either a normal or standby control file as appropriate, depending on the most recent database role known to the recovery catalog (RC_SITE.DATABASE_ROLE) for the target database. The purpose of this option to override the default setting in cases where the most recent database role is out-of-date. Assume that you perform a switchover from primary database dgny to standby database dgsf, so that dgsf is the new primary database. Later, you make dgny a standby database for dgsf. You want to restore a control file on dgny, but the recovery catalog was not resynchronized and still shows dgny as a primary database. In this case, you can specify STANDBY CONTROLFILE to override the default RMAN behavior and restore a standby control file.

If you restore the control file of a database whose DB_UNIQUE_NAME is known to the recovery catalog, then RMAN updates all file names in the control file to file names known to the recovery catalog. Any file names explicitly renamed with ALTER DATABASE RENAME FILE take precedence over the file names in the recovery catalog.

See Also: Table 3-9 for restrictions and usage notes

Note: You must always run the RECOVER command after mounting a restored control file, and must also always open the database with the RESETLOGS option.

TABLESPACE tablespace_name

Restores all data files in the specified tablespaces (see Example 3-21).

RMAN translates the tablespace name internally into a list of data files. If you rename a tablespace (for example, from users to customers), then so long as an additional tablespace with the old name (users) has not been created, you can use either the old name (users) or the new name (customers) for the tablespace. RMAN detects that the tablespace has changed its name and updates the recovery catalog on the next resynchronization.

Note: RMAN can back up and restore dictionary-managed temporary tablespaces, but it cannot back up locally managed temporary tablespaces. However, RMAN automatically re-creates locally managed temporary tablespaces after restoring the database.


restoreSpecOperand

This subclause specifies options for the restoreObject clause. These parameters override the parameters with the same name at the RESTORE command level.


Syntax ElementDescription

CHANNEL channel_id

Specifies the case-sensitive name of a channel to use for this restore operation. If you do not specify a channel, then RESTORE uses any available channel allocated with the correct device type.

FROM AUTOBACKUP

Restores a control file autobackup (see Example 3-24).

This option is only valid on the RESTORE CONTROLFILE and RESTORE SPFILE commands. When restoring either type of file in NOCATALOG mode, the FROM AUTOBACKUP clause is required.

RMAN begins the search on the current day or on the day specified with the SET UNTIL. On the first day searched, the search begins with sequence number 256 (or the sequence number specified by MAXSEQ, if provided) and counts back to sequence 0. If no autobackup is found in the current or SET UNTIL day, then RMAN checks preceding days, starting with sequence 256 and counting back to 0. The search continues up to MAXDAYS days (default of 7, maximum of 366) before the current or SET UNTIL day. If no autobackup is found within MAXDAYS days, then RMAN signals an error and the command stops.

See Also: Table 3-9 for restrictions and usage notes.

   autoBackupOptList

Specifies parameters that control the search for a control file autobackup.

   'media_handle'

Specifies the name of the control file copy or backup piece containing a control file. The media_handle can be any backup piece that contains a backup of a control file: the control file backup does not need to be an autobackup.

See Also: Table 3-9 for restrictions and usage notes.

FROM SERVICE service_name

Restores data files or control files using backups transferred, over the network, from the remote database. service_name specifies the service name of the remote database.

FROM TAG tag_name

Overrides the default selection of the most recent backups or file copy available. The tag restricts the automatic selection to backup sets or file copies created with the specified tag. If multiple backup sets or copies have a matching tag, then RMAN selects the most recent one. Tag names are not case sensitive.

See Also: BACKUP for a description of how a tag can be applied to an individual copy of a duplexed backup set, and for a description of the default file name format for tags.


autoBackupOptList

This subclause specifies parameters that control the search for a control file autobackup.


Syntax ElementDescription

DB_NAME database_name

Provides a DB_NAME to be used in searching for control file autobackups. See Table 3-10 to determine when to set this parameter.

The default value of the DB_UNIQUE_NAME initialization parameter is the DB_NAME initialization parameter setting. If no DB_UNIQUE_NAME initialization parameter is set for a target database, then use either RESTORE ... DB_NAME or RESTORE ... DB_UNIQUE_NAME. If the DB_UNIQUE_NAME initialization parameter setting for a target database is different from DB_NAME, then use RESTORE ... DB_UNIQUE_NAME.

MAXDAYS integer

Limits the search for a control file autobackup to within the specified number of days earlier.

MAXSEQ integer

Specifies the highest sequence number for the control file autobackup search.

RECOVERY AREA 'pathname'

Specifies a path to the fast recovery area to search for autobackups. RECOVERY AREA and DB_RECOVERY_FILE_DEST are synonyms. See Table 3-10 to determine when to set this parameter.

DB_RECOVERY_FILE_DEST 'pathname'

RECOVERY AREA and DB_RECOVERY_FILE_DEST are synonyms.

   DB_NAME database_name

Provides a DB_NAME to be used in searching for control file autobackups. See Table 3-10 to determine when to set this parameter.

The default value of the DB_UNIQUE_NAME initialization parameter is the DB_NAME initialization parameter setting. If no DB_UNIQUE_NAME initialization parameter is set for a target database, then use either RESTORE ... DB_NAME or RESTORE ... DB_UNIQUE_NAME. If the DB_UNIQUE_NAME initialization parameter setting for a target database is different from DB_NAME, then use RESTORE ... DB_UNIQUE_NAME.

   DB_UNIQUE_NAME    db_unique_name

Specifies the DB_UNIQUE_NAME of the database in the specified fast recovery area that is the target of the restore operation.

The default value of the DB_UNIQUE_NAME initialization parameter is the DB_NAME initialization parameter setting. If no DB_UNIQUE_NAME initialization parameter is set for a target database, then use either RESTORE ... DB_NAME or RESTORE ... DB_UNIQUE_NAME. If the DB_UNIQUE_NAME initialization parameter setting for a target database is different from DB_NAME, then use RESTORE ... DB_UNIQUE_NAME.


Examples

Example 3-21 Restoring a Tablespace

This example takes a tablespace offline, restores it, then performs media recovery.

ALTER TABLESPACE users OFFLINE IMMEDIATE; 
RESTORE TABLESPACE users; 
RECOVER TABLESPACE users;  
ALTER TABLESPACE users ONLINE;

Example 3-22 Setting a New Name for a Restored Data File

Assume that /disk1, which contains data file 9, suffers a media failure. This example specifies a new name for the data file, restores it, updates the control file to use the new name, recovers it, and then brings it online:

RUN
{
  ALTER DATABASE DATAFILE 9 OFFLINE;
  SET NEWNAME FOR DATAFILE 9 TO '/disk2/users01.dbf';
  RESTORE DATAFILE 9;
  SWITCH DATAFILE ALL;
  RECOVER DATAFILE 9;
  ALTER DATABASE DATAFILE 9 ONLINE;
}

Example 3-23 Restoring the Control File When Using a Recovery Catalog

Assume that you want to restore the control file backup with the tag monday_cf_backup. You start the RMAN client, connect to the target and recovery catalog databases, and run the following commands:

RUN
{ # SET DBID is not necessary when RMAN is connected to a recovery catalog
  STARTUP FORCE NOMOUNT;
  RESTORE CONTROLFILE FROM TAG 'monday_cf_backup';
  ALTER DATABASE MOUNT;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS; # required after recovery with backup control file

RMAN restores the control file to its default location and replicates it automatically to all CONTROL_FILES locations. RMAN mounts the control file and restores and recovers the database. RMAN automatically updates the control file to reflect the structure of the restored database based on the metadata in the recovery catalog.

Example 3-24 Recovering the Database with a Control File Autobackup

Assume that the control file and some data files are lost and must be restored from tape. Because RMAN does not use a recovery catalog in this scenario, the SET DBID command is necessary to identify the control file to be restored. The example restores the control file from tape, mounts the database, and then restores and recovers the database.

CONNECT TARGET /
STARTUP FORCE NOMOUNT;
SET DBID 36508508;  # required when restoring control file in NOCATALOG mode
RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  ALTER DATABASE MOUNT;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

Example 3-25 Restoring a Control File Autobackup to a Nondefault Location

This example is a variation on Example 3-24. In this scenario, the control file autobackup is located on disk in a nondefault location. RMAN starts searching for backups with a sequence number of 20, and searches backward for 5 months:

CONNECT TARGET /
STARTUP FORCE NOMOUNT
SET DBID 36508508;  # required when restoring control file in NOCATALOG mode
RUN
{
  SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK 
    TO '/disk1/prod_cf_auto_%F';
  RESTORE CONTROLFILE TO '/tmp/cf_auto.dbf' FROM AUTOBACKUP 
    MAXSEQ 20 MAXDAYS 150;
  ALTER DATABASE MOUNT;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

Example 3-26 Restoring a Server Parameter File Autobackup to the Current Location

The following series of commands restores the current server parameter file in NOCATALOG mode and then starts the instance with the restored server parameter file.

CONNECT TARGET /
SET DBID 1620189241; # set dbid to dbid of target database
STARTUP FORCE NOMOUNT; # start instance with dummy SPFILE
RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  RESTORE SPFILE FROM AUTOBACKUP; # FROM AUTOBACKUP needed in NOCATALOG mode
  STARTUP FORCE; # startup with restored SPFILE
}

Example 3-27 Previewing Backups

This example shows the results of a RESTORE ... PREVIEW command, which identifies the backup sets RMAN selects for use in restoring archived redo log files.

RMAN> RESTORE ARCHIVELOG ALL DEVICE TYPE sbt PREVIEW;
 
Starting restore at 01-MAR-13
released channel: ORA_SBT_TAPE_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=85 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
List of Backup Sets
===================
 
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
53      1.25M      SBT_TAPE    00:00:18     01-MAR-13
        BP Key: 53   Status: AVAILABLE  Compressed: NO  Tag: TAG20130301T150155
        Handle: 2aibhej3_1_1   Media: RMAN-DEFAULT-000001
 
  List of Archived Logs in backup set 53
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    8       526376     01-MAR-13 527059     01-MAR-13
  1    9       527059     01-MAR-13 527074     01-MAR-13
  1    10      527074     01-MAR-13 527091     01-MAR-13
  1    11      527091     01-MAR-13 527568     01-MAR-13
  1    12      527568     01-MAR-13 527598     01-MAR-13
validation succeeded for backup piece
Finished restore at 01-MAR-13

Example 3-28 Recalling Offsite Backups from Offsite Storage

When used with a media manager that reports information about offsite storage of backups and supports recalling offsite backups, RESTORE ... PREVIEW RECALL requests that any media needed to restore archived redo log files from backup be recalled from offsite storage.

RMAN> RESTORE ARCHIVELOG ALL PREVIEW RECALL;

Starting restore at 10-JUN-13
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
 
 
List of Backup Sets
===================
 
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
31      12.75M     SBT_TAPE    00:00:02     10-JUN-13     
        BP Key: 33   Status: AVAILABLE  Compressed: NO  Tag: TAG20130610T152755
        Handle: 15gmknbs   Media: /v1,15gmknbs
 
  List of Archived Logs in backup set 31
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    1       221154     06-JUN-13 222548     06-JUN-13
  1    2       222548     06-JUN-13 222554     06-JUN-13
  1    3       222554     06-JUN-13 222591     06-JUN-13
  1    4       222591     06-JUN-13 246629     07-JUN-13
  1    5       246629     07-JUN-13 262451     10-JUN-13
 
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
32      256.00K    SBT_TAPE    00:00:01     10-JUN-13     
        BP Key: 34   Status: AVAILABLE  Compressed: NO ]! Tag: TAG20130610T153105
        Handle: 17gmknhp_1_1   Media: /v1,17gmknhp_1_1
 
  List of Archived Logs in backup set 32
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    6       262451     10-JUN-13 262547     10-JUN-13
  1    7       262547     10-JUN-13 262565     10-JUN-13
 
Initiated recall for the following list of offsite backup files
==========================================================
        Handle: 15gmknbs   Media: /v1,15gmknbs
Finished restore at 10-JUN-13

Example 3-29 Validating the Restore of a Backup

The following example illustrates using RESTORE... VALIDATE to confirm that backups required to restore the database are present on disk or tape, readable, and not corrupted:

RMAN> RESTORE DATABASE VALIDATE;
 
Starting restore at 01-MAR-13
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=85 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2013_03_01/o1_mf_nnndf_TAG20130301T161038_2ygtvzg0_.bkp
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2013_03_01/o1_mf_nnndf_TAG20130301T161038_2ygtvzg0_.bkp tag=TAG20130301T161038
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:16
Finished restore at 01-MAR-13

Example 3-30 Restoring Data Files on the Primary Database Using the Standby

This example restores the data file users.dbf that was lost on the primary database by restoring it, over the network, from the standby database:

RESTORE DATAFILE '/oradata/files/users.dbf'
          FROM SERVICE standby_tns
          SECTION SIZE 200M
          USING COMPRESSED BACKUPSET;

The service name of the remote database that contains the data file to be restored is standby_tns. The SECTION SIZE clause indicates that the data file is restored using multisection backup sets. The USING COMPRESSED BACKUPSET clause specifies that the backup sets are compressed using the default compression algorithm that is configured for RMAN.

Example 3-31 Restoring a Database from a Cross-Platform Database Backup

This example restores the database using a cross-platform backup that was created in Example 2-33. This backup was created on a Microsoft Windows IA (32-bit) platform and is being restored on Linux x86 64-bit. The backup set containing the database is stored in /tmp/xplat_restores/full_db.bck. The restored data files are stored in /oradata/datafiles using unique file names that begin with df_

RESTORE 
   FROM PLATFORM 'Microsoft Windows IA (32-bit)'
   ALL FOREIGN DATAFILES
   FORMAT '/oradata/datafiles/df_%U'
   FROM BACKUPSET '/tmp/xplat_restores/full_db.bck';

Example 3-32 Restoring a Tablespace from a Cross-Platform Tablespace Backup

This example restores the tablespace example from the cross-platform backup created in Example 2-34. The backup set containing the tablespace to be restored is stored in /tmp/xplat_restores/example_readonly.bck. The restored data files use unique names that being with example_readonly_. The metadata required to plug this tablespace into the target database is stored in the backup set /tmp/xplat_restores/example_dmp.bck.

RESTORE
   FOREIGN TABLESPACE example
   FORMAT '/tmp/xplat_restores/example_readonly_%U_%n'
   FROM BACKUPSET '/tmp/xplat_restores/example_readonly.bck'   DUMP FILE
   DATAPUMP DESTINATION '/tmp/datapump'
   FROM BACKUPSET '/tmp/xplat_restores/example_dmp.bck';

See Also:

Oracle Database Backup and Recovery User's Guide for an example of backing up and restoring multiple tablespaces

Example 3-33 Restoring a Tablespace Using a Cross-Platform Backup Consisting of Multiple Backup Sets

This example restores the tablespace example from a cross-platform backup consisting of multiple backup sets that was created in Example 2-35. You must use a separate BACKUPSET clause for each backup set. The backup sets must be listed in the order in which they were created, starting with the first backup set.

RESTORE
   BACKUPSET '/tmp/xplat_restores/db_multiple_59nkcln6_1_1'
   BACKUPSET '/tmp/xplat_restores/db_multiple_5ankcln7_1_1'
   BACKUPSET '/tmp/xplat_restores/db_multiple_5bnkcln8_1_1'
   BACKUPSET '/tmp/xplat_restores/db_multiple_5cnkcln9_1_1'
   DUMP FILE
       FROM BACKUPSET '/tmp/xplat_restores/db_multiple.dmp';

Example 3-34 Restoring a Tablespace Using a Cross-Platform Consistent Backup that Contains Multiple Backup Pieces

This example restores the tablespace example from a cross-platform backup consisting of multiple backup pieces that was created in Example 2-36. The export dump file containing the metadata of the tablespace is stored in /tmp/xplat_restores/example_mutli-piece_dmp.bck. The FROM BACKUPSET clause contains a comma-separated list of all the backup pieces. List the backup pieces in the same order in which they were created.

RESTORE
   FOREIGN TABLESPACE sales
   FORMAT '/tmp/xplat_restores/datafiles/example_mult_%u'
   FROM BACKUPSET 
       '/tmp/xplat_restores/example_multi-piece_0lnjnujs_1_1',
       '/tmp/xplat_restores/example_multi-piece_0lnjnujs_2_1',
       '/tmp/xplat_restores/example_multi-piece_0lnjnujs_3_1'
   DUMP FILE 
   FROM BACKUPSET '/tmp/xplat_restores/example_multi-piece_dmp.bck';

Example 3-35 Restoring a Cross-Platform Inconsistent Tablespace Backup

This example restores the tablespace example from the cross-platform inconsistent backup created in Example 2-37. The restored data files are stored using unique names that begin with inconsist_. Because the tablespace was not read-only when the backup was created, you cannot directly plug it into the target database. You must apply an incremental backup of the tablespace taken when the tablespace is read-only to the recovered foreign data files.

RESTORE
    FOREIGN TABLESPACE example
    FORMAT '/tmp/xplat_restores/datafiles/inconsist_%u'
    FROM BACKUPSET '/tmp/xplat_backups/example_inconsist.bck';
PK/q]PKC|JOEBPS/rcviews059.htmGK RC_TEMPFILE

RC_TEMPFILE

This view lists information about all temp files registered in the recovery catalog. It corresponds to the V$TEMPFILE view. A temp file is shown as dropped if its tablespace is dropped.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for the target database. Use this column to join with almost any other catalog view.

DBINC_KEY

NUMBER

The primary key for the incarnation of the target database. Use this column to join with RC_DATABASE_INCARNATION.

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

CON_ID

NUMBER

The ID of the current container:

  • 0: Rows containing data that pertain to the entire multitenant container database (CDB) or a traditional Oracle databases (non-CDBs)

  • 1: Rows containing data that pertains only to the root

  • n: Where n is the applicable container ID for the rows containing data

PDB_NAME

VARCHAR2(30)

The name of the pluggable database (PDB) in the recovery catalog.

PDB_KEY

NUMBER

The primary key for the PDB in the recovery catalog.

TS#

NUMBER

The tablespace ID in the target database. The TS# may exist multiple times in the same incarnation if the tablespace is dropped and re-created.

TABLESPACE_NAME

VARCHAR2(30)

The tablespace name. The name may exist multiple times in the same incarnation if the tablespace is dropped and re-created.

FILE#

NUMBER

The absolute file number of the temp file. The same temp file number may exist in the same incarnation of the temp file is dropped and re-created.

CREATION_CHANGE#

NUMBER

The SCN when the temp file is created.

CREATION_TIME

DATE

The time when the temp file is created.

DROP_CHANGE#

NUMBER

The SCN recorded when the temp file was dropped. If a new temp file with the same FILE# is discovered, then the DROP_CHANGE# is set to CREATION_CHANGE# for the temp file; otherwise, the value is set to RC_CHECKPOINT.CKP_SCN.

DROP_TIME

DATE

The time when the temp file was dropped. If a new temp file with the same FILE# is discovered, then the DROP_TIME is set to CREATION_TIME for the temp file; otherwise the value is RC_CHECKPOINT.CKP_TIME.

BYTES

NUMBER

The size of the temp file in bytes.

BLOCKS

NUMBER

Size of the file in blocks.

BLOCK_SIZE

NUMBER

The block size of the temp file in bytes.

NAME

VARCHAR2(1024)

The temp file name.

RFILE#

NUMBER

The relative file number of this temp file within the tablespace.

AUTOEXTEND

VARCHAR2(3)

ON if the temp file is autoextensible. Otherwise OFF.

MAXSIZE

NUMBER

Maximum file size in blocks to which the file can be extended. Valid only when AUTOEXTEND is ON. Always 0 when AUTOEXTEND is OFF.

NEXTSIZE

NUMBER

Amount of incremental size for file extensible in blocks. Valid only when AUTOEXTEND is ON. Always 0 when AUTOEXTEND is OFF.

BIGFILE

VARCHAR2(3)

YES if the tablespace is a bigfile tablespace; otherwise, NO.

SITE_KEY

NUMBER

Primary key of the Data Guard database associated with this file. Each database in a Data Guard environment has a unique SITE_KEY value. You can use SITE_KEY in a join with the RC_SITE view to obtain the DB_UNIQUE_NAME of the database.

TABLESPACE_CREATION_CHANGE#

NUMBER

SCN at which this tablespace was created.

TABLESPACE_CREATION_TIME

DATE

Timestamp at which this tablespace was created.

TABLESPACE_DROP_CHANGE#

NUMBER

SCN at which this tablespace was dropped.

TABLESPACE_DROP_TIME

DATE

Timestamp at which the tablespace was dropped.

DB_UNIQUE_NAME

VARCHAR2(512)

The DB_UNIQUE_NAME of the database incarnation to which this record belongs. All databases in a Data Guard environment share the same DBID but different DB_UNIQUE_NAME values. The value in this column is null when the database name is not known for a specific file. For example, rows for databases managed by versions of RMAN before Oracle Database 11g are null.


PK1%uDGGPKC|JOEBPS/rcmsubcl.htmf RMAN Subclauses PKrPKC|JOEBPS/rcmsubcl016.htm;P maintSpec

maintSpec

Purpose

Use the maintSpec subclause to specify the backup files operated on by the CHANGE, CROSSCHECK, and DELETE commands.

Semantics

maintSpec


Syntax ElementDescription

BACKUP

Processes backup sets. For processing image copies, use the option COPY.

If you do not use the OF clause with CHANGE BACKUP, then RMAN changes all backup sets recorded in the repository. If you do not use the OF clause with CROSSCHECK BACKUP, then RMAN crosschecks backups of the whole database. If you do not use the OF clause with DELETE BACKUP, then RMAN deletes backups of the whole database.

   OF listObjList

Restricts the list of files operated on to the object type specified in the listObjList clause.

See Also: listObjList

archivelogRecordSpecifier

Processes the specified archived redo log files.

If you specify DELETE ARCHIVELOG without the BACKED UP clause, then RMAN uses the configured settings to determine whether an archived log can be deleted (CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP). If you specify DELETE ARCHIVELOG with the BACKED UP clause, then RMAN uses the DELETE settings to determine whether an archived log can be deleted. Use FORCE with DELETE ARCHIVELOG to override a configured deletion policy and any mismatches between media and repository.

See Also: archivelogRecordSpecifier

COPY

Processes data file copies, control file copies, and archived redo log files.

If you do not specify an option for CHANGE COPY, then the command operates on all image copies recorded in the repository. If you are using CROSSCHECK COPY, then by default the command checks all image copies of all files in the database with status AVAILABLE or EXPIRED. If you are using DELETE COPY, then by default COPY removes copies of all files in the database. Specify the EXPIRED option to remove only copies that are marked EXPIRED in the repository.

   OF listObjList

Restricts the list of objects operated on to the object type specified in the listObjList clause. If you do not specify an object, then the command defaults to all copies. CHANGE COPY OF DATABASE includes data files but not control files.

See Also: listObjList

foreignlogRecordSpecifier

Processes the specified foreign archived redo log files.

See Also: foreignlogRecordSpecifier

maintQualifier

Restricts the command based on the specified options.

See Also: maintQualifier

recordSpec

Specifies the file that you are performing maintenance on.

If you use the BACKUPSET parameter in recordSpec, then the keys identify backup sets for use with the CHANGE, CROSSCHECK and DELETE commands. For more details, see "LIST Command Output" for an explanation of the column headings of the LIST output tables. Use the KEY column of the output to obtain the primary key usable in the CHANGE and DELETE commands.

See Also: recordSpec

DEVICE TYPE deviceSpecifier

Allocates automatic channels for the specified device type only. This option is valid only if you have configured automatic channels and have not manually allocated channels. For example, if you configure automatic disk and tape channels and run CROSSCHECK...DEVICE TYPE DISK, then RMAN allocates only disk channels.

See Also: deviceSpecifier


Examples

Example 4-32 Crosschecking Backups

The following command crosschecks backups of archived redo log files:

RMAN> CROSSCHECK BACKUP OF ARCHIVELOG ALL;
 
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=103 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=8cic4031_1_1 RECID=195 STAMP=616693857
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=8oic41ad_1_1 RECID=198 STAMP=616695118
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=8qic41c3_1_1 RECID=200 STAMP=616695171
Crosschecked 3 objects
PKyQ);;PKC|JOEBPS/rcviews022.htm+ RC_BACKUP_SPFILE_SUMMARY

RC_BACKUP_SPFILE_SUMMARY

RC_BACKUP_SPFILE_SUMMARY provides summary information about server parameter file backups for databases registered in the recovery catalog.

This view is primarily intended to be used internally by Enterprise Manager.


ColumnData TypeDescription

DB_NAME

VARCHAR2(8)

The DB_NAME of the database incarnation to which this record belongs.

DB_KEY

NUMBER

The primary key for this database in the recovery catalog. Use this column to join with almost any other catalog view.

NUM_FILES_BACKED

NUMBER

Number of files backed up.

NUM_DISTINCT_FILES_BACKED

NUMBER

Number of distinct files backed up (based on differing modification timestamps).

MIN_MODIFICATION_TIME

DATE

Earliest modification time of any SPFILE backed up for this database.

MAX_MODIFICATION_TIME

DATE

Latest modification time of any SPFILE backed up for this database.

INPUT_BYTES

NUMBER

Total number of bytes in the input files backed up.

INPUT_BYTES_DISPLAY

VARCHAR2(32K)

Same value as INPUT_BYTES, but converted to a user-displayable format, for example, 798.01M or 5.25G.


PK%NhPKC|JOEBPS/rcmsubcl018.htm)% recordSpec

recordSpec

Purpose

Use the recordSpec subclause to specify which backups or copies the CHANGE, CROSSCHECK, DELETE, and LIST commands process.

Most recordSpec options allow you to specify a primary key. Use the output of the LIST command to obtain primary keys.

Syntax

recordSpec::=

Description of GUID-34D0D181-2D56-4802-AB5E-E231EC406000-print.eps follows

Semantics


Syntax ElementDescription

ARCHIVELOG

Specifies an archived redo log by either primary key or file name.

BACKUPSET

Specifies a backup set by primary key.

BACKUPPIECE

Specifies a backup piece by media handle, primary key, or tag name.

PROXY

Specifies a proxy copy by media handle, primary key, or tag name.

CONTROLFILECOPY

Specifies a control file copy by primary key, file name pattern ('filename'), or TAG tag_name. If you crosscheck a control file copy, then you must specify a file name rather than a primary key.

DATAFILECOPY

Specifies a data file copy by primary key, file name pattern ('filename'), tag (TAG tag_name), or matching string (LIKE 'string_pattern'). Specify ALL to indicate all data file copies recorded in the RMAN repository.

   NODUPLICATES

Targets only one copy of the control file or data file copy for the operation, even when there are multiple copies.


Examples

Example 4-34 Crosschecking Backups

This example crosschecks backup sets specified by primary key:

RMAN> LIST BACKUP SUMMARY; 
 
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
8504    B  A  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T155057
8558    B  F  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T155114
9872    B  F  A DISK        08-MAR-13       1       1       NO         TAG20130308T160830
9954    B  A  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T161157
9972    B  F  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T161224
10021   B  A  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T161251
10042   B  F  A SBT_TAPE    08-MAR-13       1       1       NO         TAG20130308T161308
10185   B  F  A DISK        08-MAR-13       1       1       NO         TAG20130308T170532
10210   B  F  A DISK        08-MAR-13       1       1       NO         TAG20130308T170535
 
RMAN> CROSSCHECK BACKUPSET 9872, 10185, 10210;
 
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=103 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/disk2/PROD/autobackup/2013_03_08/o1_mf_s_616694910_2z19d0wg_.bkp RECID=197 STAMP=616694912
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/disk2/PROD/backupset/2013_03_08/o1_mf_nnsnf_TAG20130308T170532_2z1dpwz6_.bkp RECID=202 STAMP=616698332
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/disk2/PROD/autobackup/2013_03_08/o1_mf_s_616698335_2z1dq0d0_.bkp RECID=203 STAMP=616698336
Crosschecked 3 objects

Example 4-35 Deleting Data File Copies

This example deletes the specified data file copy:

RMAN> DELETE NOPROMPT DATAFILECOPY '/disk1/oradata/prod/users01.dbf';
PK3))PKC|JOEBPS/rcmsynta2001.htm RECOVER

RECOVER

Purpose

Use the RECOVER command to perform one of the following distinct tasks:

  • Perform complete recovery of the whole database or one or more restored data files

  • Perform point-in-time recovery of a database (DBPITR), pluggable database (PDB), tablespace (TSPITR), table, or table partition

  • Apply incremental backups to a data file image copy (not a restored data file) to roll it forward in time

  • Recover a corrupt data block or set of data blocks within a data file

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to recover data files

Prerequisites

All redo or incremental changes required for the recovery must exist on disk or in SBT. If RMAN needs to restore incremental backups or archived redo log files during recovery, then you must either have automatic channels configured or manually allocate channels of the same type that created these backups.

If you perform media recovery on an encrypted tablespace, then the Oracle keystore must be open when performing media recovery of this tablespace. See Oracle Database Administrator's Guide to learn about encrypted tablespaces.

Prerequisites Specific to RECOVER BLOCK

The following prerequisites apply to RECOVER BLOCK:

  • The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.

  • RMAN can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file were marked corrupt since the most recent BACKUP or BACKUP ... VALIDATE command was run against the file.

  • The backups of the data files containing the corrupt blocks must be full backups and not proxy backups. If only proxy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them data file copies. You can then use the data file copies for block media recovery.

  • RMAN can use only archived redo log files for recovery. Block media recovery cannot survive a missing or inaccessible log, although it can sometimes survive missing or inaccessible records (see Oracle Database Backup and Recovery User's Guide).

  • For RMAN to be able to search the flashback logs for good copies of corrupt blocks, Flashback Database must be enabled on the target database.

  • For RMAN to be able to search a standby database for good copies of corrupt blocks, the target database must be associated with a physical standby database in a Data Guard environment. In addition, the physical standby database must be open read-only in managed recovery.

Note

An active Data Guard license is required for this operation.

Usage Notes

By default, RMAN performs complete recovery. For point-in-time recovery, the best practice is to enter a SET UNTIL command before both the RESTORE and RECOVER commands in a RUN command so that the UNTIL time applies to both commands. If you run SET UNTIL after restoring the database, then you may not be able to recover the database to the target time because the restored files may have timestamps later than the target time.

Note:

You must open the database with the RESETLOGS option after incomplete recovery or recovery with a backup control file.

Incremental Backups and Archived Redo Log Files

Except for RECOVER BLOCK, RMAN can use both incremental backups and archived redo log files for recovery. RMAN uses the following search order:

  1. Incremental backup sets on disk or tape

  2. Archived redo log files on disk

  3. Archived redo log backups on disk

  4. Archived redo log backup sets on tape

When RMAN chooses a destination to restore archived redo log files, it uses the following order of precedence:

  1. SET ARCHIVELOG DESTINATION

  2. The LOG_ARCHIVE_DEST_n parameter whose value is set to LOCATION=USE_DB_RECOVERY_FILE_DEST

  3. LOG_ARCHIVE_DEST_1

RMAN can apply incremental backups to data files that were not restored from an incremental backup. If overlapping levels of incremental backup exist, then RMAN automatically chooses the level covering the longest period of time.

Recovery Using Storage Snapshots

Storage Snapshot Optimization enables you to use third-party technologies to take storage snapshots without putting the database or associated data files in BACKUP mode. When recovering the database using a storage snapshot, specify the SNAPSHOT TIME option.

See Also:

Oracle Database Backup and Recovery User's Guide for information about specifying the snapshot time

To be usable in recovery operations, the snapshots must conform to the following requirements. Ask your vendor for a guarantee of compliance.

  • The database is crash consistent during the snapshot.

  • The snapshot preserves write order for each file.

  • The snapshot technology stores the time at which the snapshot is completed.

Caution:

Take care that the database snapshots are usable. Oracle Database does not use a snapshot for recovery if structural changes were made during the snapshot. Some SQL operations can make database structural changes and should not be used during a snapshot. A few examples of such operations include the OFFLINE, ONLINE, READONLY, DROP, RENAME, SHRINK, and ADD clauses.

See Also:

ALTER DATABASE and ALTER TABLESPACE commands in Oracle Database SQL Language Reference for information about clauses that make database structural changes

Recovery Through RESETLOGS

You must RESTORE data files before you can recover them. RMAN can recover through RESETLOGS operations transparently if the data files to be recovered are from a parent incarnation. If required, the RECOVER command can also restore and apply archived redo log files and incremental backups from previous database incarnations, even if those logs were generated in previous releases of Oracle Database.

When recovering through an OPEN RESETLOGS, ensure that you have all logs needed for recovery. In a previous database incarnation, you must have the logs from the time of the backup until the SCN that is 1 less than the RESETLOGS SCN. The incarnation table must have a complete history of RESETLOGS operations from the creation time of the database backup. If the complete metadata is not found in V$DATABASE_INCARNATION, then you can re-create this metadata by using CATALOG for the archived redo log files from the missing incarnations.

See Also:

RESTORE command for explanation of the default location for restoring archived redo log files. RMAN automatically specifies the MAXSIZE option when staging logs in the fast recovery area.

Recovery of CDBs and PDBs

RMAN enables you to recover a whole multitenant container database (CDB), the root, one or more PDBs, and tablespaces in a root or PDB. You can perform complete recovery or point-in-time recovery for PDBs and CDBs. However, you cannot recover the root to a specified point in time.

The process of recovering CDBs and PDBs is similar to that of non-CDBs. The difference is in the process of connecting to the CDB or PDB and in the commands used. To recover the whole CDB, the root, or multiple PDBs, you connect to the root. To recover a particular PDB, connect to that PDB. To recover PDBs, you use the RECOVER PLUGGABLE DATABASE command. To recover a whole CDB, use the RECOVER DATABASE command and to recover the root, use the RECOVER DATABASE ROOT command.

See Also:

"CONNECT" for information about connecting to CDBs and PDBs

See Also:

Oracle Database Backup and Recovery User's Guide for information about performing recovery of CDBs and PDBs

In a Data Guard environment, you may need to restore the entire CDB after the point-in-time recovery of a primary database, for the standby database to follow the primary database.

Syntax

recover::=

Description of GUID-B0C02F16-077C-471A-BFC7-77448F879B78-print.eps follows

(deviceSpecifier::=, recoverObject::=, recoverOptionList::=)

recoverSpec::=

Description of GUID-DC01C95D-2F3B-4444-BF4C-CAE836BBC4BC-print.eps follows

(recoverObject::=, blockObject::=, recoverOptionList::=)

recoverObject::=

Description of GUID-5DB380A7-9329-45A9-89F5-3C3906971002-print.eps follows

(dbObject, untilClause::=)

dbObject::=

Description of GUID-2019A0F8-3C0F-47D4-8512-3A3D8E33B579-print.eps follows

blockObject::=

Description of GUID-C2E37654-1AB6-4B49-8A50-2C968BE4B7CF-print.eps follows

(datafileSpec::=)

recoverOptionList::=

Description of GUID-AC4D94FA-9C1B-4B80-9798-7686C34C60C0-print.eps follows

(remapTableList::=, sizeSpec::=)

remapTableList::=

Description of GUID-D3878820-F94A-4431-93AA-215E40B150E3-print.eps follows

Semantics

recover


Syntax ElementDescription

DEVICE TYPE deviceSpecifier

Allocates automatic channels for the specified device type only. For example, if you configure automatic disk and tape channels, and if you issue RECOVER DEVICE TYPE DISK, then RMAN allocates only disk channels.

You configure a device type with the CONFIGURE DEVICE TYPE command (except for DISK, which is preconfigured) before specifying the DEVICE TYPE option.

Note: You cannot manually allocate channels and then run RECOVER DEVICE TYPE.

See Also: deviceSpecifier

recoverSpec

Specifies the type of object being recovered.


recoverSpec


Syntax ElementDescription

recoverObject

Specifies the type of object being recovered.

blockObject

Specifies the blocks to be recovered with block media recovery.

recoverOptionList

Specifies recovery options.


recoverObject

This subclause specifies which files to recover. Refer to recoverObject::= for the syntax diagram.


Syntax ElementDescription

COPY OF dbObject

Applies incremental backups to the specified image copy to roll it forward to any time equal to or before the most recent incremental backup of the file. The existing image copy is overwritten and remains in a fuzzy state during the recovery. RMAN makes an autobackup after recovering the image copy.

This command updates a data file copy and is not a media recovery of a current database file. This command is meant to be used with the BACKUP ... FOR RECOVER OF COPY syntax to implement a strategy using incrementally updated backups.

The following requirements must be met:

  • At least one copy of each data file that you are recovering must exist.

  • Incremental backups taken after the image copy that you are recovering must exist.

RMAN selects one suitable copy if there are multiple possible copies to which the incremental backups can be applied to carry out the operation.

Note: RMAN issues a warning (not an error) if it cannot recover to the specified time because no incremental backups are available.

   WITH TAG tag_name

Specifies a tag name to identify the image copy to be rolled forward.

DATAFILECOPY 'filename'

Applies incremental backups to the specified data file image copy (see Example 3-4). Refer to description of RECOVER COPY OF.

dbObject

Specifies the data blocks that require recovery.

FOREIGN DATAFILECOPY 'filename'

Specifies the name of the foreign data file copies that need to be made consistent by applying incremental backups. These foreign data file copies were created during an inconsistent cross-platform backup by using either the CONVERT or BACKUP command with the ALLOW INCONSISTENT clause.

FROM BACKUPSET 'filename'

Specifies the name of the backup set containing the cross-platform incremental backup that must be applied to the foreign data file copies specified using the FOREIGN DATAFILECOPY 'filename' clause.

The following conditions must be satisfied for a cross-platform incremental backup to be applied:

  • The start SCN of each data file in the cross-platform incremental backup must be less than the current checkpoint SCN of the foreign data file copy.

  • The foreign data file copy must not be modified.

    For example, it should not have been plugged in to the target database, changed to read-write mode, and then changed back to read-only mode. This changes the database ID and file number in the foreign data file copy header.

If these conditions are not met, an error occurs and the cross-platform incremental backup is not applied to the foreign data file copies.

Note: You cannot apply an incremental backup consisting of multiple backup sets to a set of foreign data files.

TABLE schema.table[:partition]

Specifies the tables or table partitions that must be recovered. The target database must be in read-write mode.

You can assign new names for recovered tables or table partitions in the target database by using the REMAP TABLE option.

When the recovered tables are imported into the target database, if a table with the same name exists in the target database, an error message is displayed indicating that the REMAP TABLE clause must be used to rename the tables.

When you recover only certain partitions from a partitioned table, each partition is imported into the target database as separate table. If REMAP TABLE is not used to rename recovered objects, RMAN names each table by using a concatenation of the table name and partition name. The table names of the recovered objects are in the format tablename_partitionname. If a table with this name exists in the target database, RMAN appends _1 to the generated table name. If a table with this name too exists, RMAN appends _2 to the table name, and so on.

See Example 3-8

OF PLUGGABLE DATABASE pdb_name

In a CDB, the name of a PDB in which the table or table partition that must be recovered resides. To recover tables or table partitions in a PDB, you must connect to the root as described in "Connecting to CDBs and PDBs".

SKIP

Takes the data files in the specified tablespaces offline before starting media recovery. These files are left offline after the media recovery is complete.

This option is useful for avoiding recovery of tablespaces containing only temporary data or for postponing recovery of some tablespaces.

   FOREVER

Takes the data files offline with the DROP option (see Example 3-3). Use SKIP FOREVER TABLESPACE when you intend to drop the specified tablespaces after opening the database with the RESETLOGS option.

Note: If you perform incomplete recovery, then SKIP requires the FOREVER option.

TABLESPACE tablespace_name

Specifies the name of the tablespace to take offline.

TABLESPACE pdb_name:tablespace_name

The name of a tablespace in a PDB.

SNAPSHOT TIME 'date_string'

Specifies time-based recovery from a snapshot backup that was created using Storage Snapshot Optimization. date_string is the time at which the snapshot was completed and is specified in RMAN TIME format (defined by NLS_DATE_FORMAT environment variable).

You can combine SNAPSHOT TIME with UNTIL TIME or UNTIL SCN to do a database point-in-time recovery (DBPITR). However, you can only do a DBPITR to a time or an SCN greater than specified snapshot completion time.

See Also: "Recovery Using Storage Snapshots" for information about the requirements of the snapshot system and how to specify the snapshot time.

TO RESTORE POINT restore_point_name

Specifies a restore point for termination of the RECOVER command, with the SCN at which the restore point was created as the upper, inclusive limit. Because the limit is inclusive, RMAN selects only files that it can use to recover up to and including the SCN corresponding to the restore point.

untilClause

Specifies a past time, SCN, or log sequence number for termination of the RECOVER command.

When used with one or more tablespaces, the clause indicates a tablespace point-in-time recovery (TSPITR) operation for the named tablespaces. Do not use this clause with RECOVER DATAFILE or for RECOVER DATABASE (see "Usage Notes"). After database point-in-time recovery (DBPITR), you must open the database with the RESETLOGS option.

See Also: untilClause


dbObject

This subclause specifies whether to recover the database or a subset of the database. Refer to dbObject::= for the syntax diagram.


Syntax ElementDescription

DATABASE

Specifies the entire database (see Example 3-3). For CDBs, it specifies the entire CDB.

In a CDB, recovers the entire CDB. You connect to the root to backup the whole CDB as described in "Connecting to CDBs and PDBs".

By default, the RECOVER DATABASE command does not recover files that are offline normal at the point in time to which the files are being recovered. RMAN omits offline normal files with no further checking.

When recovering after the loss of control files, RMAN automatically updates the control file to point to the actual location of the data files on disk (see Example 3-5).

If RMAN encounters redo for adding a data file, then RMAN automatically creates a new data file unless the tablespace containing the added data file is skipped during recovery. This situation can arise when a backup control file is restored before recovery and the backup control file does not contain a record of the recently-added data file.

DATABASE ROOT

Specifies only the root in a CDB. Connect to the root as described in "Connecting to CDBs and PDBs".

PLUGGABLE DATABASE pdb_name

Specifies one or more PDBs in a CDB. No other PDBs are affected; they can remain open and operational. Use a comma-delimited list to specify multiple PDBs. To use this clause, you must connect to the root.

Performing complete recovery does not require you to connect to the root. You connect to the root to perform any of the following operations for PDBs: point-in-time recovery, table recovery, TSPITR, or duplication. To connect to the root or a PDB, see "Connecting to CDBs and PDBs".

DATAFILE datafileSpec

Specifies a list of one or more data files by either file name or absolute data file number.

The target database must be mounted or open. If the database is open, then the data files to be recovered must be offline.

If you are not using a recovery catalog, then the file name must be the name of the data file as recorded in the control file. If you are using a recovery catalog, then the file name of the data file must be the most recent name recorded in the catalog, even if the name in the control file has been updated more recently. For example, assume that a data file was renamed in the control file, but the instance fails before you resynchronize the catalog. Specify the old name of the data file in the RECOVER command because this is the name recorded in the catalog.

Note: You cannot arbitrarily recover individual data files to different points in time, although you can recover the whole database to a single point in time or recover wholly contained tablespaces to a point in time different from the rest of the database (TSPITR). For more information on TSPITR, see the procedure described in Oracle Database Backup and Recovery User's Guide.

See Also: datafileSpec

TABLESPACE tablespace_name

Specifies a list of one or more tablespaces. The target database must be mounted or open. If the database is open, then the tablespaces to be recovered must be offline.

When connected to the root in a CDB, specifies the tablespaces in the root. Specifies the names of tablespaces in a PDB when connected to a PDB.

In a CDB, specifies the name of a tablespace in the root when connected to the root, and specifies the name of a tablespace in a PDB when connected to a PDB.

Note: If the RMAN encounters redo for adding a data file, then RMAN automatically creates a new data file. This situation can arise when a backup control file is restored before recovery and the backup control file does not contain a record of the recently-added data file.

TABLESPACE pdb-name:tablespace_name

The name of the tablespace in a PDB. Multiple PDBs can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. This syntax is needed only when connected to the root. When connected directly to a PDB, use TABLESPACE tablespace_name. pdb-name is the name of a PDB.

See the previous description for TABLESPACE for general information.


blockObject

This subclause specifies the data blocks that require recovery. Refer to blockObject::= for the syntax diagram. Refer to "Prerequisites Specific to RECOVER BLOCK" for prerequisites specific to block media recovery.

You can either use RECOVER CORRUPTION LIST to recover all blocks reported in the V$DATABASE_BLOCK_CORRUPTION view, or specify the data file number and block number or the tablespace and data block address (DBA). RMAN can only perform complete recovery of individual blocks.

By default, if Flashback Database is enabled, then RMAN searches the flashback logs for good copies of corrupt blocks. By default, if the target database exists in a Data Guard environment, then RECOVER BLOCK command can automatically retrieve blocks from a physical standby database to a primary database and vice-versa.


Syntax ElementDescription

CORRUPTION LIST

Recovers all physically corrupt blocks listed in the V$DATABASE_BLOCK_CORRUPTION view. Block media recovery may not be able to repair all listed logically corrupt blocks. In these cases, alternate recovery methods, such as tablespace point-in-time recovery, or dropping and recreating the affected objects, may repair the corruption.

The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by Oracle Database components such as RMAN commands, ANALYZE, SQL queries, and so on. In short, any process that encounters an ORA-1578 error records the block corruption in this view. The following types of corruption result in rows added to this view:

  • Physical corruption (sometimes called media corruption). The database does not recognize the block at all: the checksum is invalid, the block contains all zeros, or the header and footer of the block do not match.

  • Logical corruption. The block has a valid checksum, the header and footer match, and so forth, but the contents are logically inconsistent.

The view does not record corruptions that can be detected by validating relationships between blocks and segments, but cannot be detected by a check of an individual block.

Note: Any RMAN command that fixes or detects that a block is repaired updates V$DATABASE_BLOCK_CORRUPTION. For example, RMAN updates the repository at the end of successful block media recovery. If a BACKUP, RESTORE, or VALIDATE command detects that a block is no longer corrupted, then it removes the repaired block from the view.

DATAFILE datafileSpec

BLOCK integer TO integer

Recovers an individual data block or set of data blocks within a data file. It can copy blocks from either a standby or a primary database. The TO range is inclusive, so that BLOCK 10 TO BLOCK 20 includes both block 10 and block 20.

Block media recovery is useful when the data loss or corruption applies to a small number of blocks rather than to an entire data file. Typically, block corruption is reported in error messages in trace files or by the ADVISE FAILURE command. Block-level data loss usually results from:

  • I/O errors causing minor data loss

  • Memory corruptions that get written to disk

If you do not specify an option from recoverOptionList, and if Flashback Database is enabled on the database, then RECOVER BLOCK first searches the flashback logs and then the backups for a good version of the block to restore.

Blocks marked media corrupt are not accessible until recovery completes.

Note: You can only perform complete recovery of individual blocks. In other words, you cannot stop recovery before all redo has been applied to the block.

See Also: datafileSpec

TABLESPACE tablespace_name DBA integer

Specifies the tablespace name or number containing the corrupt blocks and the data block address (DBA) of the corrupt block. You can only perform block media recovery on corrupt blocks.

Note: The data file header block (block 1) cannot be recovered.

TABLESPACE pdb-name:tablespace_name DBA integer

The name of the tablespace in a PDB. Multiple PDBs can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. pdb-name is the name of a PDB.

See the previous description of TABLESPACE for general information.


recoverOptionList

This subclause specifies various recovery options. Refer to recoverOptionList::= for the syntax diagram.


Syntax ElementDescription

ALLOW integer CORRUPTION

Specifies the number of corrupt blocks that can be tolerated while allowing recovery to proceed. You can set this parameter in case of redo log corruption.

ARCHIVELOG TAG tag_name

Specifies the tag for an archived log backup to be used during recovery. Tag names are not case sensitive and display in all uppercase. If the tagged backup does not contain all the necessary archived redo log files for recovery, then RMAN uses logs or incremental backups as needed from whatever is available.

AUXILIARY DESTINATION 'location'

Specifies a location where auxiliary set data files, control files, and online redo logs are created during TSPITR if another location for an individual file is not explicitly specified.

If you do not specify AUXILIARY DESTINATION for a TSPITR, then you must specify the naming of individual auxiliary set data files, control files, and online redo logs before executing RECOVER TABLESPACE with the UNTIL clause. Otherwise, TSPITR fails.

While performing point-in-time recovery of PDBs, if no auxiliary destination is specified, then the fast recovery area is used as the auxiliary destination. When an auxiliary destination is not specified and a fast recovery area is not configured, the recovery of the PDB fails.

See also: The chapter on TSPITR in Oracle Database Backup and Recovery User's Guide for more details about the auxiliary destination

CHECK LOGICAL

Tests data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log and server session trace file.

The SET MAXCORRUPT setting represents the total number of physical and logical corruptions permitted on a file. By default, MAXCORRUPT is 0, so that if any corrupt blocks exist, media recovery fails. If recovery including corrupt blocks is permissible, then set MAXCORRUPT to the smallest number of corrupt blocks that causes media recovery to fail. For example, to tolerate one corrupt block, set MAXCORRUPT to 1.

If the total number of physical and logical corruptions detected for a file is less than its MAXCORRUPT setting, then the RMAN command completes and the database populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges. Otherwise, the command terminates without populating V$DATABASE_BLOCK_CORRUPTION.

DATAPUMP DESTINATION 'datapump_destination'

Specifies the location of the Data Pump export dump file that contains the tables or table partitions that are recovered from an RMAN backup.

If you do not specify a Data Pump destination, RMAN creates the export dump file in the destination indicated by AUXILARY DESTINATION. If no auxiliary destination is specified, RMAN creates the dump file in a default operating system-specific location. On Linux, the default location is $ORACLE_HOME/dbs. On Windows the default location is %ORACLE_HOME\database.

DELETE ARCHIVELOG

Deletes archived redo log files restored from backups or copies that are no longer needed. RMAN does not delete archived redo log files that were on disk before the RESTORE command started. If you do not specify MAXSIZE, then RMAN deletes restored archived redo log files as they are applied.

Note: If archived redo log files are restored to the fast recovery area, then the DELETE ARCHIVELOG option is enabled by default.

   MAXSIZE sizeSpec

Does not use more than sizeSpec amount of disk space for restored archived redo log files. If recovery requires the restore of a log larger than the MAXSIZE value, then RMAN reports an error indicating that you must increase the MAXSIZE value. If MAXSIZE is smaller than the backup set containing the logs, then RMAN must read the backup set more than once to extract the logs. In this situation, RMAN issues a warning to increase MAXSIZE.

DUMP FILE 'filename'

Specifies the name of the Data Pump export dump file that contains the recovered tables or table partitions. If you do not specify a name for the dump file, RMAN assigns a default name based on the operating system of the target database. The default name is tspitr_SID-of-clone_n.dmp where SID-of-clone is the Oracle SID of the auxiliary database used by RMAN for recovery and n is a randomly-generated number. The dump file is created in the location specified by DATAPUMP DESTINATION.

If DATAPUMP DESTINATION contains a file with the name specified in DUMP FILE, the recovery process fails.

See Also: DATAPUMP DESTINATION

EXCLUDE FLASHBACK LOG

Does not search the flashback logs for blocks to restore. By default, RMAN searches the flv3ashback logs if Flashback Database is enabled.

EXCLUDE STANDBY

Does not search a physical standby database for blocks to restore. By default, in a Data Guard environment RMAN searches the blocks from a physical standby database.

FROM BACKUPSET

Specifies that only backup sets are restored.This clause is supported only while performing block media recovery. The RECOVER ... BLOCK command is used to perform block media recovery.

FROM DATAFILECOPY

Restores only data file image copies.

This clause is supported only while performing block media recovery. The RECOVER ... BLOCK command is used to perform block media recovery.

FROM PLATFORM 'platform'

Specifies the name of the source platform on which the cross-platform backup was created. The platform name specified must match the platform identifier stored in the cross-platform backup header.

This clause is required when conversion is performed on the destination database. If conversion is performed on the source database (by using the TO PLATFORM clause in the BACKUP command), then this clause is optional. When this clause is omitted, you can still recover a cross-platform backup by specifying the FOREIGN DATAFILECOPY clause with the FROM BACKUPSET clause.

Note: Cross-platform data transportation using backup sets is supported starting with Oracle Database 12c Release 1 (12.1).

See FOREIGN DATAFILECOPY 'filename'.

See Also: Oracle Database Backup and Recovery User's Guide for more information about source and destination platform conversion.

FROM SERVICE service_name

Recovers data files using backup sets that are transferred, over the network, from a remote database. service_name specifies the service name of the remote database.

See "Restoring Data Files and Control Files Using Files from a Remote Host".

FROM TAG 'tag_name'

Specifies the tag for an incremental backup to be used during recovery. If the tagged backup does not contain all the necessary incrementals for recovery, then RMAN uses logs or incremental backups as needed from whatever is available. Tag names are not case sensitive and display in all uppercase.

See Also: BACKUP to learn how a tag can be applied to an individual copy of a duplexed backup set, and to learn about the default file name format for backup tags

NOPARALLEL

Does not perform media recovery in parallel. Parallel execution is the default for RECOVER (see the description of the RECOVER ... PARALLEL option).

NOREDO

Suppresses the application of redo logs during recovery. Only incremental backups are applied.

One use of this option is to use incremental backups to update full backups of NOARCHIVELOG databases (see Example 3-6). The NOREDO options is required if redo logs are not available. If you do not specify NOREDO when recovering a NOARCHIVELOG database, then RMAN ends recovery and issues an error.

Note: Incremental backups of NOARCHIVELOG databases can only be taken after a consistent shutdown.

Another use is to update standby or duplicate databases. Incremental backups created with the BACKUP INCREMENTAL FROM SCN command can be applied at a standby or duplicate database. The standby database procedure is described in Oracle Data Guard Concepts and Administration.

NOTABLEIMPORT

Specifies that RMAN must not import recovered tables or table partitions into the target database.

The recovered objects are stored in an Data Pump export dump file that is specified using DUMP FILE and DATAPUMP DESTINATION. If these clauses are omitted, the export dump file is created in a default location.

When required, you need to explicitly import the tables or table partitions contained in the export dump file into the target database. Use the Data Pump import utility to import the recovered objects.

Note: You cannot use NOTABLEIMPORT with the REMAP TABLE or REMAP TABLESPACE clauses.

PARALLEL

Specifies parallel recovery (default).

By default, the database uses parallel media recovery to improve performance of the roll forward phase of media recovery. To override the default behavior of performing parallel recovery, use the RECOVER with the NOPARALLEL option, or RECOVER PARALLEL 0.

In parallel media recovery, the database uses a "division of labor" approach to allocate different processes to different data blocks while rolling forward, thereby making the operation more efficient. The number of processes is derived from the CPU_COUNT initialization parameter, which by default equals the number of CPUs on the system. For example, if parallel recovery is performed on a system where CPU_COUNT is 4, and only one data file is recovered, then four spawned processes read blocks from the data file and apply redo.

Typically, recovery is I/O-bound on reads from and writes to data blocks. Parallelism at the block level may only help recovery performance if it increases total I/Os, for example, by bypassing operating system restrictions on asynchronous I/Os. Systems with efficient asynchronous I/O see little benefit from parallel media recovery.

Note: The RECOVERY_PARALLELISM initialization parameter controls instance or crash recovery only. Media recovery is not affected by the value used for RECOVERY_PARALLELISM.

See Also: The description of the PARALLEL clause in the discussion of CREATE TABLE in Oracle Database SQL Language Reference

   integer

Specifies the integer degree of parallelism.

Each parallel thread may use one or two parallel execution servers. Optional.

REMAP TABLE

Renames recovered tables or table partitions in the target database. You cannot remap a table or partition that is not listed in the TABLE clause of the RECOVER command.

When a recover a partitioned table, if you remap only some partitions in the table, then all the table partitions are imported as separate tables.

Named constraints and indexes are not imported when you use the REMAP option.

REMAP TABLESPACE source_tablespace_name:target_tablespace_name

Imports the recovered tables or table partitions into a tablespace that is different from the one to which they belonged in the source database.

source_tablespace_name refers to the name of the tablespace in which the tables or partitions resided in the source database and target_tablespace_name refers to the name of the tablespace into which the tables or table partitions must be imported.

Named constraints and indexes are not imported when you use the REMAP option.

SECTION SIZE sizeSpec

Parallelizes the validation by dividing each file into the specified section size.

See "SECTION SIZE sizeSpec".

SKIP READONLY

Omits read-only files from the recovery.

TEST

Initiates a trial recovery.

A trial recovery is useful if a normal recovery procedure has encountered a problem. It enables the database to look ahead into the redo stream to detect possible problems. The trial recovery applies redo in a way similar to normal recovery, but it does not write changes to disk and it rolls back its changes at the end of the trial recovery.

Note: You can use this clause only if you have restored a backup taken since the last RESETLOGS operation. Otherwise, the database returns an error.

UNDO TABLESPACE tablespace_name

Specifies a list of tablespaces with undo segments at the target time. Only for use with RECOVER TABLESPACE.

During TSPITR, RMAN needs information about which tablespaces had undo segments at the TSPITR target time. This information is usually available in the recovery catalog, if one is used.

If there is no recovery catalog, or if the information is not found in the recovery catalog, then RMAN proceeds if the set of tablespaces with undo segments at the target time equals the set of tablespaces with undo segments now. If this assumption is not correct, then TSPITR fails with an error. In such a case, you can use UNDO TABLESPACE.

USING [COMPRESSED] BACKUPSET

Specifies that the files being recovered must be transferred from the remote database as compressed backup sets, if USING COMPRESSED BACKUPSET is used. By default, RMAN transfers files as backup sets. Therefore, even if you do not use the USING BACKUPSET clause, the files are transferred as backup sets.The compression algorithm from the RMAN configuration is used to perform compression. You can use a different compression algorithm by running the SET COMPRESSION ALGORITHM before your RECOVER command.

VALIDATE HEADER

Reports and validates—but does not restore—the backups that RMAN could use to restore files needed for the recovery.

When you run RECOVER with VALIDATE HEADER, RMAN performs the same functions as when you specify the RESTORE ... PREVIEW option. However, in addition to listing the files needed for restore and recovery, RMAN validates the backup file headers to determine whether the files on disk or in the media management catalog correspond to the metadata in the RMAN repository.

See Also: The description of the RESTORE ... PREVIEW option


remapTableList


Syntax ElementDescription

schema

Name of the schema in the source database

old_tablename

Name of the table in the source database

partition

Name of the table partition in the source database

new_tablename

Name of the table in the target database, after the table has been recovered


Examples

Example 3-1 Recovering a Tablespace in an Open Database

Assume that the disk containing the data files for tablespace users becomes unavailable because of a hardware error, but is repaired after a few minutes. This example takes tablespace users offline, uses automatic channels to restore the data files to their default location and recover them (deleting the logs that it restored from tape), then brings the tablespace back online.

ALTER TABLESPACE users OFFLINE IMMEDIATE;
RESTORE TABLESPACE users;
RECOVER TABLESPACE users DELETE ARCHIVELOG MAXSIZE 2M;
ALTER TABLESPACE users ONLINE;

Example 3-2 Recovering Data Files Restored to New Locations

This example uses the preconfigured disk channel and manually allocates one media management channel to use data file copies on disk and backups on tape, and restores a data file in tablespace USERS to a different location.

RUN
{  
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;  
  ALTER TABLESPACE users OFFLINE IMMEDIATE;  
  SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf' 
    TO '/disk2/users01.dbf';
  RESTORE TABLESPACE users;
  SWITCH DATAFILE ALL;
  RECOVER TABLESPACE users;
  ALTER TABLESPACE users ONLINE;
}

Example 3-3 Performing DBPITR with a Backup Control File and Recovery Catalog

Assume that all data files, all control files, and archived redo log 58 were lost due to a disk failure. Also assume that you do not have incremental backups. You must recover the database with available archived redo log files. You do not need to restore tablespace TOOLS because it has been read-only since before the most recent backup. After connecting RMAN to the target database and recovery catalog, issue the following commands:

STARTUP FORCE NOMOUNT;
RUN
{  
  SET UNTIL SEQUENCE 40 THREAD 1;  # Recover database until log sequence 40 
  RESTORE CONTROLFILE;
  ALTER DATABASE MOUNT;
  RESTORE DATABASE SKIP TABLESPACE tools;
  RECOVER DATABASE SKIP TABLESPACE tools;
}
ALTER DATABASE OPEN RESETLOGS;

RMAN automatically skips the restore and recovery of data file 8, which is the data file in the read-only tablespace. The following portion of sample output indicates the skip:

using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
skipping datafile 8; already restored to file /disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: starting datafile backup set restore
.
.
.
Finished restore at 19-FEB-13 

Starting recover at 19-FEB-13
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
datafile 8 not processed because file is read-only

Example 3-4 Incrementally Updating Backups

By incrementally updating backups, you can avoid the overhead of making full image copy backups of data files, while also minimizing time required for media recovery of your database. This example enables you to recover to any SCN within the previous week, but enables you to avoid having to apply more than one day of redo.

Assume you run the following script daily. On first execution, the script creates an image copy backup of the database on disk with the specified tag. On the second through the seventh executions, the script creates a level 1 differential backup of the database. On the eighth and all subsequent executions, RMAN applies the level 1 incremental to the data file copy made 7 days ago and then makes a new level 1 backup with the changes from the previous day.

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update' 
    UNTIL TIME 'SYSDATE - 7';
  BACKUP
    INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

Example 3-5 Recovery from Loss of a Control File on a Standby Database

Assume that the standby database dgprod3 control files are lost because of a media failure. The primary and standby database share SBT storage. A backup of the primary database control file exists on tape.

You start the RMAN client and connect to dgprod3 as TARGET and connect to the recovery catalog. The following RMAN commands restore a control file that is usable by the standby database, update the file names to existing files on disk, and recover the standby database:

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RECOVER DATABASE;

You can then start redo apply on the standby database.

Example 3-6 Recovering a NOARCHIVELOG Database

You can perform limited recovery of changes to a database running in NOARCHIVELOG mode by applying incremental backups. The incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot back up the database when it is open.

Assume that you run database prod in NOARCHIVELOG mode with a recovery catalog. You shut down the database consistently and make a level 0 backup of database prod to tape on Sunday afternoon. You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.

On Saturday, a media failure destroys half of the data files and all the online redo logs. Because the online logs are lost, you must specify the NOREDO option in the RECOVER command. Otherwise, RMAN searches for the redo logs after applying the Friday incremental backup and issues an error message when it does not find them.

After connecting RMAN to prod and the catalog database, recover as follows:

STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE;      # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE;         # restore data files from consistent backup
RECOVER DATABASE NOREDO;  # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;

The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo log files, there is no way to recover changes made after the incremental backup.

Example 3-7 Recovering All Block Corruption in the Database

This example runs a backup validation to populate the V$DATABASE_BLOCK_CORRUPTION view, then recovers any corrupt blocks recorded in the view. Sample output is included for both commands.

RMAN> VALIDATE DATABASE;
 
Starting validate at 19-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
.
.
.
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    FAILED 0              4070         57600           555975
  File Name: /disk1/oradata/prod/system01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       1              41550
  Index      0              7677
  Other      0              4303
.
.
.
RMAN> RECOVER CORRUPTION LIST;
 
Starting recover at 19-FEB-13
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
searching flashback logs for block images until SCN 547548
finished flashback log search, restored 1 blocks
 
starting media recovery
media recovery complete, elapsed time: 00:00:03
 
Finished recover at 19-FEB-13

Example 3-8 Recovering Tables Partitions from a Backup

This example recovers the partitions sales_2009 and sales_2010 from the table SALES to the time when the SCN of the target database was 34582. In the source database, the tables are owned by the schema SH. While importing these partitions into the target database, the partitions are created as tables named historic_sales_2009 and historic_sales_2010.

RECOVER TABLE SH.SALES:SALES_2009, SH.SALES:SALES_2010
     UNTIL SCN 34582
     AUXILIARY DESTINATION '/tmp/oracle/recover'
     REMAP TABLE 'SH'.'SALES':'SALES_2009':'HISTORIC_SALES_2009', 'SH'.'SALES':'SALES_2010':'HISTORIC_SALES_2010';

Example 3-9 Recovering Tables to a Specified Log Sequence and Renaming the Tables

This example uses an auxiliary instance to recover the table EMP from the SCOTT schema to the time when the log sequence number of the database was 5466. After the EMP table is recovered, it is imported into the target database using the name MY_EMP.

RECOVER TABLE SCOTT.EMP
     UNTIL SEQUENCE 5466
     AUXILARY DESTINATION '/tmp/recover'
     REMAP TABLE 'SCOTT'.'EMP':'MY_EMP';

Example 3-10 Recovering Tables to a Specified Time and Into a Different Tablespace

This example recovers tables EMP and DEPT to the point in time specified by the UNTIL TIME clause. The tables were originally part of the EXAMPLE tablespace. However, after the recovery operation, they are mapped to the tablespace MY_TBS in the target database.

RECOVER TABLE SCOTT.EMP, SCOTT.DEPT
      UNTIL TIME "TO_CHAR('12/23/2012 12:00:00','mm/dd/yyyy hh24:mi:ss')"
      AUXILIARY DESTINATION '/tmp/oracle/recover'
      REMAP TABLESPACE 'EXAMPLE':'MY_TBS';
PKMvvPKC|JOEBPS/rcviews050.htm\ RC_RMAN_BACKUP_TYPE

RC_RMAN_BACKUP_TYPE

This view is used internally by Enterprise Manager.

It contains information used in filtering the other Enterprise Manager views when generating reports on specific backup types.


ColumnData TypeDescription

WEIGHT

NUMBER

Used internally by Enterprise Manager to set precedence order of different backup types in reports.

INPUT_TYPE

VARCHAR2(13)

Used internally by Enterprise Manager to represent possible filters used in creating various reporting screens.


PK!Q|yPKC|JOEBPS/rcviews1.htm Summary of RMAN Recovery Catalog Views

Summary of RMAN Recovery Catalog Views

The following table provides a functional summary of RMAN recovery catalog views.

Note:

The data type of some recovery catalog view columns is listed as VARCHAR2(4000). This length for VARCHAR2 columns is applicable when the initialization parameter VARCHAR2_MAX_SIZE is set to LEGACY. If you set the value of VARCHAR2_MAX_SIZE to 32767, the columns with data type listed as VARCHAR2(4000) will be VARCHAR2(32767).

Table 5-1 Recovery Catalog Views

Recovery Catalog ViewCorresponding V$ ViewCatalog View Description

RC_ARCHIVED_LOG

V$ARCHIVED_LOG

Archived and unarchived redo log files

RC_BACKUP_ARCHIVELOG_DETAILS

V$BACKUP_ARCHIVELOG_DETAILS

Details about archived redo log backups for Enterprise Manager

RC_BACKUP_ARCHIVELOG_SUMMARY

V$BACKUP_ARCHIVELOG_SUMMARY

Summary of information about archived redo log backups for Enterprise Manager

RC_BACKUP_CONTROLFILE

V$BACKUP_DATAFILE

Control files backed up in backup sets

RC_BACKUP_CONTROLFILE_DETAILS

V$BACKUP_CONTROLFILE_DETAILS

Details about control file backups for Enterprise Manager

RC_BACKUP_CONTROLFILE_SUMMARY

V$BACKUP_CONTROLFILE_SUMMARY

Summary of information about control file backups for Enterprise Manager

RC_BACKUP_COPY_DETAILS

V$BACKUP_COPY_DETAILS

Details about data file image copy backups for Enterprise Manager

RC_BACKUP_COPY_SUMMARY

V$BACKUP_COPY_SUMMARY

Summary of information about data file image copy backups for Enterprise Manager

RC_BACKUP_CORRUPTION

V$BACKUP_CORRUPTION

Corrupt block ranges in data file backups

RC_BACKUP_DATAFILE

V$BACKUP_DATAFILE

Data files in backup sets

RC_BACKUP_DATAFILE_DETAILS

V$BACKUP_DATAFILE_DETAILS

Details about data file backups for Enterprise Manager

RC_BACKUP_DATAFILE_SUMMARY

V$BACKUP_DATAFILE_SUMMARY

Summary of information about data file backups for Enterprise Manager

RC_BACKUP_FILES

V$BACKUP_FILES

RMAN backups and copies known to the repository.

RC_BACKUP_PIECE

V$BACKUP_PIECE

Backup pieces

RC_BACKUP_PIECE_DETAILS

V$BACKUP_PIECE_DETAILS

Details about backup pieces for Enterprise Manager

RC_BACKUP_REDOLOG

V$BACKUP_REDOLOG

Archived redo log files in backup sets

RC_BACKUP_SET

V$BACKUP_SET

Backup sets for all incarnations of databases registered in the catalog

RC_BACKUP_SET_DETAILS

V$BACKUP_SET_DETAILS

Details about backup sets for Enterprise Manager

RC_BACKUP_SET_SUMMARY

V$BACKUP_SET_SUMMARY

Summary of information about backup sets for Enterprise Manager

RC_BACKUP_SPFILE

V$BACKUP_SPFILE

Server parameter files in backups

RC_BACKUP_SPFILE_DETAILS

V$BACKUP_SPFILE_DETAILS

Details about server parameter file backups for Enterprise Manager

RC_BACKUP_SPFILE_SUMMARY

V$BACKUP_SPFILE_SUMMARY

Summary of information about server parameter file backups for Enterprise Manager

RC_CHECKPOINT

n/a

Deprecated in favor of RC_RESYNC

RC_CONTROLFILE_COPY

V$DATAFILE_COPY

Control file copies on disk

RC_COPY_CORRUPTION

V$COPY_CORRUPTION

Corrupt block ranges in data file copies

RC_DATABASE

V$DATABASE

Databases registered in the recovery catalog

RC_DATABASE_BLOCK_CORRUPTION

V$DATABASE_BLOCK_CORRUPTION

Database blocks marked as corrupted in the most recent RMAN backup or copy

RC_DATABASE_INCARNATION

V$DATABASE_INCARNATION

Database incarnations registered in the recovery catalog

RC_DATAFILE

V$DATAFILE

Data files registered in the recovery catalog

RC_DATAFILE_COPY

V$DATAFILE_COPY

Data file copies on disk

RC_DISK_RESTORE_RANGE

V$DISK_RESTORE_RANGE

Details about the restore range of the database for backup data stored on disk

RC_LOG_HISTORY

V$LOG_HISTORY

Online redo log history indicating when log switches occurred

RC_OFFLINE_RANGE

V$OFFLINE_RANGE

Offline ranges for data files

RC_PDBS

V$PDBS

Pluggable databases (PDBs) registered in the recovery catalog

RC_PLUGGABLE_DATABASE_INC

V$PDB_INCARNATION

PDB incarnations registered in the recovery catalog

RC_PROXY_ARCHIVEDLOG

V$PROXY_ARCHIVEDLOG

Archived log backups taken with the proxy copy functionality

RC_PROXY_ARCHIVELOG_DETAILS

V$PROXY_ARCHIVELOG_DETAILS

Details about proxy archived redo log files for Enterprise Manager

RC_PROXY_ARCHIVELOG_SUMMARY

V$PROXY_ARCHIVELOG_SUMMARY

Summary of information about proxy archived redo log files for Enterprise Manager

RC_PROXY_CONTROLFILE

V$PROXY_DATAFILE

Control file backups taken with the proxy copy functionality

RC_PROXY_COPY_DETAILS

V$PROXY_COPY_DETAILS

Details about data file proxy copies for Enterprise Manager

RC_PROXY_COPY_SUMMARY

V$PROXY_COPY_SUMMARY

Summary of information about data file proxy copies for Enterprise Manager

RC_PROXY_DATAFILE

V$PROXY_DATAFILE

Data file backups that were taken using the proxy copy functionality

RC_REDO_LOG

V$LOG and V$LOGFILE

Online redo logs for all incarnations of the database since the last catalog resynchronization

RC_REDO_THREAD

V$THREAD

All redo threads for all incarnations of the database since the last catalog resynchronization

RC_RESTORE_POINT

V$RESTORE_POINT

All restore points for all incarnations of the database since the last catalog resynchronization

RC_RESTORE_RANGE

V$RESTORE_RANGE

Details about the restore range of databases registered in the recovery catalog

RC_RESYNC

n/a

Recovery catalog resynchronizations

RC_RMAN_BACKUP_JOB_DETAILS

V$RMAN_BACKUP_JOB_DETAILS

Details about backup jobs for Enterprise Manager

RC_RMAN_BACKUP_SUBJOB_DETAILS

V$RMAN_BACKUP_SUBJOB_DETAILS

Details about backup subjobs for Enterprise Manager

RC_RMAN_BACKUP_TYPE

V$RMAN_BACKUP_TYPE

Used internally by Enterprise Manager

RC_RMAN_CONFIGURATION

V$RMAN_CONFIGURATION

RMAN configuration settings

RC_RMAN_OUTPUT

V$RMAN_OUTPUT

Output from RMAN commands for use in Enterprise Manager

RC_RMAN_STATUS

V$RMAN_STATUS

Historical status information about RMAN operations.

RC_SBT_RESTORE_RANGE

V$SBT_RESTORE_RANGE

Details about the restore range of the database for backup data stored on tape

RC_SITE

n/a

Databases in a Data Guard environment

RC_STORED_SCRIPT

n/a

Names of scripts stored in the recovery catalog

RC_STORED_SCRIPT_LINE

n/a

Contents of the scripts stored in the recovery catalog

RC_TABLESPACE

V$TABLESPACE

All tablespaces registered in the recovery catalog, all dropped tablespaces, and tablespaces that belong to old incarnations

RC_TEMPFILE

V$TEMPFILE

All temp files registered in the recovery catalog

RC_UNUSABLE_BACKUPFILE_DETAILS

V$UNUSABLE_BACKUPFILE_DETAILS

Unusable backup files registered in the recovery catalog

PK{\PKC|JOEBPS/rcmsynta007.htm-Rҭ CATALOG

CATALOG

Purpose

Use the CATALOG command to do the following:

  • Add backup pieces and image copies on disk to the RMAN repository

  • Record a data file copy as a level 0 incremental backup in the RMAN repository, which enables you to use it as part of an incremental backup strategy

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to manage target database records stored in the catalog

Prerequisites

You must be connected to the target database, which must be mounted or open. If RMAN is connected to a recovery catalog, then the catalog database must be open.

The file that you are cataloging must meet the following conditions:

  • It must not exist on an SBT device.

  • If it is a user-managed copy, then it must be a data file copy, control file copy, archived redo log, or backup piece.

Usage Notes

RMAN considers all user-managed backups as image copies. While cataloging, RMAN does not check whether the file was correctly copied by the operating system utility: it just checks the header.

A recovery catalog is required when using RMAN in a Data Guard environment. The recovery catalog supports a unified file namespace for all primary and standby databases with the same DBID but different DB_UNIQUE_NAME values. Thus, the recovery catalog keeps track of database file names for all primary and standby databases, and also where online redo logs, standby redo logs, temp files, archived redo log files, backup sets, and image copies were created.

"RMAN Backups in a Data Guard Environment" explains how RMAN handles backups made on a different primary and standby databases. In general, tape backups made on one database are accessible to any database in the environment, whereas disk backups are accessible only to the database that created them.

If backups are accessible to the connected target database, RMAN commands such as RESTORE and RECOVER behave transparently across different databases. You can manually transfer a disk backup from one host in the environment to another host and then catalog the backup. If a backup is on shared disk, then you can use CHANGE RESET DB_UNIQUE_NAME to associate the backup with a new database.

Syntax

catalog::=

Description of GUID-2FA8469C-45C6-4F3B-8181-799283B690ED-print.eps follows

Semantics


Syntax ElementDescription

ARCHIVELOG 'filename'

Specifies the file name of an archived redo log to be added to the RMAN repository.

Note: This command does not catalog foreign archived redo log files, which are redo logs received by a logical standby database for a LogMiner session. Unlike normal archived redo log files, foreign archived redo log files have a different DBID.

BACKUPPIECE 'filename'

Specifies the name of a backup piece to be added to the RMAN repository (see Example 2-39).

The backup piece must be on disk. RMAN verifies the backup piece header before cataloging it. RMAN can catalog a backup piece from a previous database incarnation.

You may choose to catalog backup pieces in the following situations:

  • You copy or move a backup piece with an operating system utility and want it to be usable by RMAN.

  • The RMAN metadata for the backup piece was removed, but the backup piece still exists. This situation can occur if you ran the DELETE command on a backup piece that was only temporarily unavailable.

  • You make a NOCATALOG backup on one database host in a Data Guard environment and move the backup piece to the same location on a different database host. In this case, the recovery catalog has no record of the original backup piece.

  • You do not use a recovery catalog and must re-create the control file, thereby losing all RMAN repository data. Cataloging your backups makes them available again.

  • When control file autobackup is disabled, you back up the control file and then back up the archived redo log files. You can restore and mount the control file, but must catalog the backup pieces containing the archived redo log files backed up after the control file.

If you specify a list of backup pieces, then RMAN attempts to catalog all pieces in the given list even if some of them fail. Cataloging a backup piece creates a new row in V$BACKUP_PIECE. A backup set is only usable when all backup pieces are cataloged because otherwise it is only in a partially available state.

Note: If RMAN creates a server parameter file backup when the COMPATIBLE parameter of the database is set to 11.0.0 or higher, then the backup is associated with this database. In this case, even if you connect RMAN to a different database and explicitly catalog the backup piece, the DB_UNIQUE_NAME associated with this backup does not change. For example, if RMAN backs up the server parameter file of the database with DB_UNIQUE_NAME 'NEWYORK' when COMPATIBLE is 11.0.0, then RMAN cannot use the server parameter file backup created at database NEWYORK to restore the server parameter file on database BOSTON.

CONTROLFILECOPY 'filename'

Specifies the file name of a control file copy to be added to the RMAN repository. The control file copy can be a normal or standby control file copy created by one of the following commands:

  • RMAN: BACKUP AS COPY CURRENT CONTROLFILE

  • SQL: ALTER DATABASE BACKUP CONTROLFILE

  • SQL: ALTER DATABASE CREATE STANDBY CONTROLFILE

Note: RMAN can automatically convert a primary database control file backup to a standby control file during a restore operation.

DATAFILECOPY 'filename'

Specifies the file name of a data file copy to be added to the RMAN repository (see Example 2-39). You can create data file copies with the RMAN BACKUP AS COPY command or with operating system utilities used with ALTER TABLESPACE BEGIN/END BACKUP.

   LEVEL integer

Records the data file copy as a level 0 incremental backup (0 is the only valid value of LEVEL).

You can perform incremental backups by using this data file copy as the base level 0 backup.

   TAG tagname

Specifies a tag for the data file copy.

RECOVERY AREA

Catalogs all valid backup sets, data file copies, and archived redo log files in the fast recovery area (see Example 2-41).

RMAN must be connected to a database as TARGET. The target database must be mounted or open. The keywords RECOVERY AREA and DB_RECOVERY_FILE_DEST are exact synonyms.

Note: This command also catalogs foreign archived redo log files, which are archived redo log files received by logical standby for a LogMiner session, if they exist in the fast recovery area.

DB_RECOVERY_FILE_DEST

The keywords RECOVERY AREA and DB_RECOVERY_FILE_DEST are exact synonyms.

START WITH 'string_pattern'

Catalogs all valid backup sets, data file and control file copies, and archived redo log files whose name start with string_pattern. The string pattern can be an ASM disk group, Oracle-managed files directory, or part of a file name (see Example 2-40).

RMAN reports any files in the disk location that it cannot catalog. RMAN must be connected to a mounted target database.

If the string pattern specifies a file name, then it matches the left part of the file name pattern. For example, /tmp/arc matches everything in directories /tmp/arc_dest and /tmp/archive/january, and file /tmp/arc.cpy.

Note: You cannot use wildcard characters in the string pattern, only a strict prefix.

   NOPROMPT

Suppresses the confirmation prompt. By default, RMAN prompts after every match.


Examples

Example 2-39 Cataloging a Data File Copy as an Incremental Backup

Assume that you used a Linux utility to back up the users01.dbf data file to /disk2/backup/users01.bak. This example catalogs the data file copy as an incremental level 0 backup and then lists all copies.

CATALOG DATAFILECOPY '/disk2/backup/users01.bak' LEVEL 0;
LIST COPY;

Example 2-40 Cataloging Multiple Copies in a Directory

This example catalogs a directory full of archived redo log files that were copied into the /disk2/archlog directory with an operating system utility. The example includes sample output.

CATALOG START WITH '/disk2/archlog' NOPROMPT; 

searching for all files that match the pattern /disk2/archlog
 
List of Files Unknown to the Database
=====================================
File Name: /disk2/archlog/o1_mf_1_10_24trtc7s_.arc
File Name: /disk2/archlog/o1_mf_1_11_24trtg7s_.arc
File Name: /disk2/archlog/o1_mf_1_12_24trtk84_.arc
File Name: /disk2/archlog/o1_mf_1_13_24trtn85_.arc
File Name: /disk2/archlog/o1_mf_1_14_24trtq84_.arc
File Name: /disk2/archlog/o1_mf_1_15_24trtt84_.arc
File Name: /disk2/archlog/o1_mf_1_16_24trtx84_.arc
File Name: /disk2/archlog/o1_mf_1_17_24trv085_.arc
File Name: /disk2/archlog/o1_mf_1_18_24trv385_.arc
File Name: /disk2/archlog/o1_mf_1_19_24trv685_.arc
cataloging files...
cataloging done
 
List of Cataloged Files
=======================
File Name: /disk2/archlog/o1_mf_1_10_24trtc7s_.arc
File Name: /disk2/archlog/o1_mf_1_11_24trtg7s_.arc
File Name: /disk2/archlog/o1_mf_1_12_24trtk84_.arc
File Name: /disk2/archlog/o1_mf_1_13_24trtn85_.arc
File Name: /disk2/archlog/o1_mf_1_14_24trtq84_.arc
File Name: /disk2/archlog/o1_mf_1_15_24trtt84_.arc
File Name: /disk2/archlog/o1_mf_1_16_24trtx84_.arc
File Name: /disk2/archlog/o1_mf_1_17_24trv085_.arc
File Name: /disk2/archlog/o1_mf_1_18_24trv385_.arc
File Name: /disk2/archlog/o1_mf_1_19_24trv685_.arc

Example 2-41 Cataloging Files in the Fast Recovery Area

This example catalogs all files in the currently enabled fast recovery area without prompting the user for each one. As shown in the sample output, RMAN displays a message if it finds no files to catalog.

CATALOG RECOVERY AREA;
 
searching for all files in the recovery area
no files found to be unknown to the database

Example 2-42 Cataloging a Backup Piece

Assume that you use an operating system utility to copy a backup piece from one location to another. This example catalogs the backup piece in the new location (sample output included):

CATALOG BACKUPPIECE '/disk1/c-874220581-20131128-01';

using target database control file instead of recovery catalog
cataloged backup piece
backup piece handle=/disk1/c-874220581-20131128-01 RECID=12 STAMP=607695990
PKDi2R-RPKC|JOEBPS/rcmsynta2006.htm REPORT

REPORT

Purpose

Use the REPORT command to perform detailed analyses of the RMAN repository. RMAN writes the report to standard output or the message log file.

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to create RMAN reports

Prerequisites

Execute this command only at the RMAN prompt. Either of the following conditions must be met:

  • RMAN must be connected to a target database.

  • RMAN must be connected to a recovery catalog and SET DBID must have been run.

Syntax

report::=

Description of GUID-E3F8D37B-EC79-444B-9471-96576C7B8527-print.eps follows

(needBackupOption::=, atClause::=, reportObject::=, obsOperandList::=, deviceSpecifier::=)

needBackupOption::=

Description of GUID-232C44E5-93AF-446B-96A0-4E5D1E458EC9-print.eps follows

(reportObject::=)

reportObject::=

Description of GUID-69CA0D04-9775-4B3C-BA11-8AD3EAF0E69D-print.eps follows

(datafileSpec::=)

atClause::=

Description of GUID-8488D1AA-071B-446A-82C6-55469B72FCF0-print.eps follows

Semantics

report

This clause specifies the type of report.


Syntax ElementDescription

needBackupOption

Lists files that require backups.

See Also: needBackupOption

OBSOLETE obsOperandList

Lists full backups, data file copies, and archived redo log files recorded in the RMAN repository that can be deleted because they are no longer needed. See Table 3-6 for description of output. The command works in two steps:

  1. For each data file that has been backed up, RMAN identifies the oldest full backup, level 0 backup, or image copy that is not obsolete under the retention policy. Any backup of the data file older than the one identified in this step is considered obsolete.

  2. Any archived redo log files and level 1 incremental backups that are older than the oldest nonobsolete full backup are considered obsolete. These files are obsolete because no full or level 0 backup exists to which they can be applied. Incremental level 1 backups or archived redo log files are not considered obsolete if they can be applied to nonobsolete level 0 or full backups.

The subclause obsOperandList describes the criteria that RMAN uses to determine what is obsolete. If you do not specify parameters in obsOperandList, then RMAN uses the options specified in CONFIGURE RETENTION POLICY (see Example 3-19). If you use this option with DEVICE TYPE, then RMAN only considers backups and copies created on the specified device. If the retention policy is disabled, then RMAN does not consider any backups as obsolete. Thus, RMAN issues an error when you run REPORT OBSOLETE with no other options and the retention policy is NONE.

Note: A backup made with the KEEP UNTIL TIME clause is obsolete after the KEEP time passes, regardless of the configured retention policy settings.

SCHEMA

Lists the names of all data files (permanent and temporary) and tablespaces for the target database at the specified point in time. See Table 3-1 for description of output.

For REPORT SCHEMA without forDbUniqueNameOption, a target database connection is required, but a recovery catalog connection is optional.

forDbUniqueNameOption

Reports the names of all data files and tablespaces for the database specified by its DB_UNIQUE_NAME.

You can specify a database with db_unique_name or use ALL for all uniquely named databases recorded in the catalog for a particular DBID. A database is uniquely identified in the recovery catalog by a DBID and the value of the DB_UNIQUE_NAME initialization parameter.

RMAN must be connected to a recovery catalog. RMAN must be connected to a target database or SET DBID must have been run.

See Also: forDbUniqueNameOption for descriptions of the options in this clause

   atClause

Specifies an SCN, log sequence number, or time.

UNRECOVERABLE reportObject

Lists all unrecoverable data files. See Table 3-7 for description of output.

A data file is considered unrecoverable if an unrecoverable operation has been performed against an object residing in the data file since the last backup of the data file. In an unrecoverable operation, redo is not generated. Examples are direct load of table data and updates with the NOLOGGING option.

Note: The nonexistence of any backup of a data file is not sufficient reason to consider it unrecoverable. Such data files can be recovered with the CREATE DATAFILE command, if redo logs starting from when the file was created still exist.

   DEVICE TYPE deviceSpecifier

Specifies the type of storage device. RMAN only considers backups and copies available on the specified device for its report.


needBackupOption

This clause reports only on files that need backups.


Syntax ElementDescription

NEED BACKUP

Lists all data files in the specified reportObject that require a new backup.

The report assumes that you restore the most recent backup. If you do not specify any option, then RMAN uses the current retention policy configuration. If the retention policy is disabled (CONFIGURE RETENTION POLICY TO NONE), then RMAN generates an error.

   DAYS integer

Lists all data files requiring more than the specified number of days' worth of archived redo log files for complete recovery. For example, REPORT NEED BACKUP DAYS 7 DATABASE shows the data files whose recovery requires more than seven days' worth of archived redo log files. See Table 3-2 for description of output.

If the target database control file is mounted and current, then RMAN makes the following optimizations to this report:

  • Files that are offline and whose most recent backup contains all changes to the file are not included.

  • Files that were offline and are now online, and whose most recent backup contains all changes up to the offline time, are only reported if they have been online for more than the specified number of days.

   INCREMENTAL integer

Specifies a threshold number of incremental backups required for recovery (see Example 3-18). If complete recovery of a data file requires more than integer incremental backups, then the data file requires a new full backup. See Table 3-3 for description of output.

Note: Files for which no backups exist do not appear in this list: issue the REPORT NEED BACKUP REDUNDANCY command to display them.

   RECOVERY WINDOW OF integer DAYS

Reports data files for which there are not sufficient backups to satisfy a recovery window-based retention policy for the specified number of days, that is, data files without sufficient backups for point-in-time recovery to any point back to the time SYSDATE - integer. See Table 3-4 for description of output.

   REDUNDANCY integer

Specifies the minimum number of backups or copies that must exist for a data file to be considered not in need of a backup. In other words, a data file needs a backup if there are fewer than integer backups or copies of this file. For example, REDUNDANCY 2 means that if there are fewer than two copies or backups of a data file, then it needs a new backup. See Table 3-5 for description of output.

reportObject

Specifies the object for which you are generating the report.


reportObject

This subclause specifies the data files to be included in the report. The report can include the entire database (optionally skipping certain tablespaces), a list of tablespaces, or a list of data files. RMAN includes objects from prior incarnations.


Syntax ElementDescription

DATABASE

Lists backups or data file copies of all files in the database.

Note: Specify SKIP TABLESPACE tablespace_name to exclude the specified tablespace from the DATABASE specification.

DATABASE ROOT

Specifies the root in a CDB. Connect to the root as described in "Connecting to CDBs and PDBs".

PLUGGABLE DATABASE pdb_name

Lists backups or data file copies in one or more PDBs in a CDB. Use a comma-delimited list to specify multiple PDBs. To report on one or more PDBs using this syntax, connect to the root as described in "Connecting to CDBs and PDBs".

DATAFILE datafileSpec

Lists the specified data files. RMAN reports on backups or data file copies that contain at least one specified data file.

TABLESPACE tablespace_name

Lists data files in the specified tablespace. RMAN reports on backups or data file copies that include at least one data file from a specified tablespace.

When connected to the root in a CDB, refers to tablespaces in the root. Refers to tablespaces in a PDB when connected directly to a PDB. See "Connecting to CDBs and PDBs".


atClause

This subclause specifies a point in time as a time, SCN, or log sequence number. You must be connected to a recovery catalog when issuing a REPORT SCHEMA command with an AT clause.


Syntax ElementDescription

AT SCN integer

Specifies an SCN.

AT SEQUENCE integer

Specifies a log sequence number. The integer indicates the time when the specified log was first opened.

   THREAD integer

Specifies a redo THREAD number. The integer indicates the time when the thread was first opened.

AT TIME 'date_string'

Specifies a date (see Example 3-17). The NLS_LANG and NLS_DATE_FORMAT environment variables specify the format for the time.


Report Output

The information that appears in the output is described in the following tables:

Table 3-1 Report of Database Schema

ColumnIndicates

File

The absolute data file number.

Size(MB)

The size of the file in megabytes.

Tablespace

The tablespace name.

RB segs

For data files only. YES if rollback segments exist in the tablespace and NO if they do not (only if connected to the recovery catalog). If RMAN is not connected to the catalog, then *** is displayed.

Datafile Name

For permanent data files only. The name of the data file.

Maxsize(MB)

For temp files only. The maximum size of the temp file.

Tempfile Name

For temp files only. The name of the temp file.

Table 3-2 Report of Files Whose Recovery Needs More Than n Days of Archived Logs

ColumnIndicates

File

The absolute file number of a data file that requires more than n days of archived redo log files for recovery.

Days

The number of days of archived redo data required for recovery.

Name

The name of the data file.

Table 3-3 Report of Files That Need More than n Incrementals During Recovery

ColumnIndicates

File

The absolute file number of a data file that requires more than n incrementals for complete recovery.

Incrementals

The number of incremental backups required for complete recovery.

Name

The name of the data file.

Table 3-4 Report of Files That Must Be Backed Up to Satisfy n Days Recovery Window

ColumnIndicates

File

The absolute file number of a data file that must be backed up to satisfy a recovery window of n days.

Days

The number of days required for complete recovery.

Name

The name of the data file that requires backup.

Table 3-5 Report of Files with Fewer Than n Redundant Backups

ColumnIndicates

File

The absolute data file number of a data file with less than n redundant backups.

#bkps

The number of backups that exist for this file.

Name

The name of the file.

Table 3-6 Report of Obsolete Backups and Copies

ColumnIndicates

Type

Whether the object is a backup set, backup piece, proxy copy, or data file copy.

Key

A unique key that identifies this backup in the target database control file.

Completion Time

The time that the backup or copy completed.

Filename/handle

The file name or media handle of the backup or data file copy.

Table 3-7 Report of Files that Need Backup Due to Unrecoverable Operations

ColumnIndicates

File

The absolute number of the data file that needs a new backup due to unrecoverable operations.

Type Of Backup Required

FULL or INCREMENTAL, depending on which type of backup is necessary to ensure the recoverability of all of the data in this file. If FULL, then create a full backup, level 0 backup, or a data file copy. If INCREMENTAL, then an incremental backup also suffices.

Name

The name of the data file.

Examples

Example 3-17 Reporting a Database Schema

This example, which requires a recovery catalog, reports the names of all data files and tablespaces 20 minutes ago.

RMAN> REPORT SCHEMA AT TIME 'sysdate-20/1440';

Report of database schema for database with db_unique_name PROD
 
List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    450      SYSTEM               YES     /disk1/oradata/prod/system01.dbf
2    197      SYSAUX               YES     /disk1/oradata/prod/sysaux01.dbf
3    20       UNDOTBS              YES     /disk1/oradata/prod/undotbs01.dbf
4    10       CWMLITE              YES     /disk1/oradata/prod/cwmlite01.dbf
5    10       DRSYS                YES     /disk1/oradata/prod/drsys01.dbf
6    10       EXAMPLE              YES     /disk1/oradata/prod/example01.dbf
7    10       INDX                 YES     /disk1/oradata/prod/indx01.dbf
8    10       TOOLS                YES     /disk1/oradata/prod/tools01.dbf
9    10       USERS                YES     /disk1/oradata/prod/users01.dbf
 
List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    40       TEMP                 32767       /disk1/oradata/prod/temp01.dbf

Example 3-18 Reporting Data Files Needing Incremental Backups

This example reports all data files in the database that require the application of one or more incremental backups to be recovered to their current state:

RMAN> REPORT NEED BACKUP INCREMENTAL 1;
 
Report of files that need more than 1 incrementals during recovery
File Incrementals Name
---- ------------ ----------------------------------------------
1    2            /disk1/oradata/prod/system01.dbf
2    2            /disk1/oradata/prod/sysaux01.dbf
3    2            /disk1/oradata/prod/undotbs01.dbf
4    2            /disk1/oradata/prod/cwmlite01.dbf
5    2            /disk1/oradata/prod/drsys01.dbf
6    2            /disk1/oradata/prod/example01.dbf
7    2            /disk1/oradata/prod/indx01.dbf
9    2            /disk1/oradata/prod/users01.dbf

Example 3-19 Reporting Obsolete Backups and Copies

The following example reports obsolete backups and copies that are redundant according to the current retention policy. The retention policy is set to redundancy 1.

RMAN> REPORT OBSOLETE;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of obsolete backups and copies
Type                 Key    Completion Time    Filename/Handle
-------------------- ------ ------------------ --------------------
Archive Log          1022   19-FEB-13          /disk1/prod/arch/archive1_59_614712405.dbf
Archive Log          1023   19-FEB-13          /disk1/prod/arch/archive1_61_614712405.dbf
Archive Log          1024   19-FEB-13          /disk1/prod/arch/archive1_60_614712405.dbf
Archive Log          1025   19-FEB-13          /disk1/prod/arch/archive1_55_614712405.dbf
Backup Set           1032   19-FEB-13
  Backup Piece       1050   19-FEB-13         
 /disk2/PROD/backupset/2013_02_19/o1_mf_nnndf_TAG20130219T173839_2xnpmp0l_.bkp
Datafile Copy        1073   19-FEB-13         
 /disk2/PROD/datafile/o1_mf_system_2xmz5l5m_.dbf
Backup Set           1035   19-FEB-13
  Backup Piece       1053   19-FEB-13         
 /disk2/PROD/backupset/2013_02_19/o1_mf_nnndf_TAG20130219T111434_2xnpozym_.bkp
Datafile Copy        1074   19-FEB-13         
 /disk2/PROD/datafile/o1_mf_sysaux_2xmz6zdg_.dbf
Datafile Copy        1075   19-FEB-13         
 /disk2/PROD/datafile/o1_mf_undotbs_2xmz7rof_.dbf
Datafile Copy        1076   19-FEB-13         
 /disk2/PROD/datafile/o1_mf_cwmlite_2xmz7vrg_.dbf
Datafile Copy        1077   19-FEB-13          /disk2/PROD/datafile/o1_mf_drsys_2xmz7wyc_.dbf
Datafile Copy        1078   19-FEB-13         
 /disk2/PROD/datafile/o1_mf_example_2xmz7y5s_.dbf
Datafile Copy        1079   19-FEB-13          /disk2/PROD/datafile/o1_mf_indx_2xmz81jg_.dbf
Datafile Copy        1081   19-FEB-13          /disk2/PROD/datafile/o1_mf_users_2xmz85vo_.dbf
Datafile Copy        1777   20-FEB-13          /disk2/users01.dbf
PKǡPKC|JOEBPS/rcviews057.htm RC_STORED_SCRIPT_LINE

RC_STORED_SCRIPT_LINE

This view lists information about individual lines of stored scripts in the recovery catalog. The view contains one row for each line of each stored script.


ColumnData TypeDescription

DB_KEY

NUMBER

The primary key for the database that owns this stored script. Use this column to join with almost any other catalog view.

SCRIPT_NAME

VARCHAR2(100)

The name of the stored script.

LINE

NUMBER

The number of the line in the stored script. Each line of a stored script is uniquely identified by SCRIPT_NAME and LINE.

TEXT

VARCHAR2(1024)

The text of the line of the stored script.


PK3PKC|JOEBPS/rcmsynta2023.htm*: UNREGISTER

UNREGISTER

Purpose

Use the UNREGISTER command to remove the RMAN metadata for one or more registered databases from the recovery catalog.

See Also:

DROP DATABASE to learn how to delete a database and unregister it with one command

Prerequisites

Execute this command only at the RMAN prompt. RMAN must be connected to a recovery catalog. The database to unregister must be currently registered in this catalog.

Usage Notes

The UNREGISTER command cannot be used when the target database is configured to create backups to Zero Data Loss Recovery Appliance, commonly known as Recovery Appliance. In this case, use the DBMS_RA.DELETE_DB procedure to unregister a database from Recovery Appliance.

See Also:

Zero Data Loss Recovery Appliance Administrator's Guide for information about the DBMS_RA.DELETE_DB procedure

Syntax

unregister::=

Description of GUID-C1279EFD-0D82-40EB-8062-33B6FF8636D1-print.eps follows

Semantics


Syntax ElementDescription

DATABASE

Specifies a primary database to be unregistered. RMAN unregisters the primary database and any of its associated standby databases (see Example 3-73).

If database_name is not specified, then RMAN must identify the database in one of the following ways:

  • If RMAN is connected to a database as TARGET, then RMAN unregisters the target database and any associated standby databases.

  • If RMAN is not connected to a database as TARGET, or if the name of the TARGET database is not unique in the recovery catalog, then RMAN uses the value specified in the SET DBID command (see Example 3-74). RMAN unregisters all databases with this DBID.

   database_name

Specifies the name of the primary database that you are unregistering.

This database name must be unique in the recovery catalog. Because the database name is unique, RMAN does not need to be connected to a target database or use the SET DBID command.

DB_UNIQUE_NAME db_unique_name

Removes all metadata except backup metadata for the Data Guard database specified by db_unique_name.

The specified database can be either a primary or standby database, although typically you use this clause to unregister a standby database (see Example 3-75).

You can use this clause only when RMAN is connected to a mounted or open target database or the SET DBID command has been run. Typically, the target database is not the database that you are unregistering. For example, you can connect as TARGET to prod1 and use DB_UNIQUE_NAME to unregister standby1. The DBID used in SET DBID is the same for the primary database and its associated standby databases.

The backups of a database have the DB_UNIQUE_NAME associated with the backup file names in the recovery catalog. When a database is unregistered, the database name for these backup files is marked as null. You can associate a database name with these files by using the CHANGE ... RESET DB_UNIQUE_NAME command.

   INCLUDING BACKUPS

Removes backup metadata for the database specified by db_unique_name.

Note: This clause cannot be used when unregistering standby databases.

Note: Physical backups are not deleted by the UNREGISTER command. If you want the physical backups removed, then first remove them with the DELETE command and then execute UNREGISTER with the INCLUDING BACKUPS option.

   NOPROMPT

Does not prompt for confirmation before unregistering the database.


Example

Example 3-73 Unregistering a Primary Database and Its Standby Databases

Assume that primary database prod has associated standby databases dgprod3 and dgprod4. In this example, you connect RMAN to target database prod, whose database name is unique in the recovery catalog, and unregister it. RMAN removes all metadata about prod, dgprod3, and dgprod4 from the catalog. Sample output is included.

RMAN> CONNECT TARGET /

connected to target database: PROD (DBID=1627709917)

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> UNREGISTER DATABASE NOPROMPT;
 
database name is "PROD" and DBID is 1627709917
database unregistered from the recovery catalog
 
RMAN> LIST DB_UNIQUE_NAME ALL;

RMAN>

Example 3-74 Unregistering a Database That is Not Unique in Catalog

Assume that two databases registered in a recovery catalog have the name prod. Your goal is to unregister the prod database that has the DBID 28014364. Because multiple databases called prod are registered in the recovery catalog, and because RMAN is not connected as TARGET to the 28014364 database (which has been deleted from the file system), you run SET DBID before UNREGISTER DATABASE. This example includes sample output.

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> SET DBID 28014364;

executing command: SET DBID
database name is "PROD" and DBID is 28014364
 
RMAN> UNREGISTER DATABASE;

Do you really want to unregister the database (enter YES or NO)? YES
database unregistered from the recovery catalog

Example 3-75 Unregistering a Standby Database

Assume that primary database prod has associated standby databases dgprod3 and dgprod4. You want to unregister dgprod4, but not remove the metadata for backups taken on this database because these backups are still usable by other databases in the environment. This example uses SET DBID to specify the DBID of the standby database and then unregisters it (sample output included):

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> SET DBID 1627367554;

executing command: SET DBID
database name is "PROD" and DBID is 1627367554

RMAN>  UNREGISTER DB_UNIQUE_NAME dgprod4;

database db_unique_name is "dgprod4", db_name is "PROD" and DBID is 1627367554

Want to unregister the database with target db_unique_name (enter YES or NO)? YES
database with db_unique_name dgprod4 unregistered from the recovery catalog
PKH/:*:PKC|JOEBPS/rcmsynta022.htm2 EXIT

EXIT

Purpose

Use the EXIT command to shut down the Recovery Manager utility. This command is functionally equivalent to the QUIT command.

Prerequisites

Execute only at the RMAN prompt.

Syntax

exit::=

Description of GUID-7F6BE415-E3E8-4600-B61E-95189AA1BA16-print.eps follows

Example

Example 2-97 Exiting RMAN

This example terminates RMAN:

RMAN> EXIT
PKGmGPKC|JOEBPS/rcmsynta2024.htmF UPGRADE CATALOG

UPGRADE CATALOG

Purpose

Use the UPGRADE CATALOG command to upgrade a recovery catalog schema from an older version to the version required by the RMAN client.

Prerequisites

RMAN must be connected to the recovery catalog database, which must be open, as the owner of the recovery catalog. You cannot use the UPGRADE CATALOG command while connected to a virtual private catalog (see CREATE CATALOG command). Only the base catalog can be upgraded.

The recovery catalog must not already be at a version greater than needed by the RMAN executable; otherwise, RMAN issues an error. RMAN displays all error messages generated during the upgrade in the message log.

The Oracle Database 10gR1 version of the recovery catalog schema requires the CREATE TYPE privilege. If you created the recovery catalog owner in a release before 10gR1, and if you granted the RECOVERY_CATALOG_OWNER role to this user when the role did not include the CREATE TYPE privilege, then you must grant CREATE TYPE to this user explicitly before performing the upgrade.

If you are upgrading a recovery catalog to Oracle Database 12c Release 1 (12.1.0.2), then you must run the dbmsrmansys.sql script that manages recovery catalog privileges. Additionally, if virtual private catalogs are used, then you must run the dbmsrmanvpc.sql script that upgrades virtual private catalogs. Starting with Oracle Database 12c Release 1 (12.1.0.2), the recovery catalog database must use Oracle Database Enterprise Edition.

See Also:

Oracle Database Backup and Recovery User's Guide for the steps to upgrade a recovery catalog to Oracle Database 12c Release 1 (12.1.0.2)

Usage Notes

You must enter the UPGRADE CATALOG command two consecutive times to confirm the upgrade.

RMAN permits the command to be run if the recovery catalog is already current so that the packages can be re-created if necessary.

If an upgrade to a base recovery catalog requires changes to an existing virtual private catalog, then RMAN makes these changes automatically the next time RMAN connects to that virtual private catalog.

The UPGRADE CATALOG command does not run scripts to perform an upgrade. Instead, RMAN sends various SQL DDL statements to the recovery catalog to update the recovery catalog schema with new tables, views, columns, and so on.

Syntax

upgradeCatalog::=

Description of GUID-20FAB1F5-D2FB-4AC0-9B75-738601B73B7D-print.eps follows

Semantics

None.

Example

Example 3-76 Upgrading a Recovery Catalog

This example connects RMAN to recovery catalog database catdb and then upgrades it to a more current version:

RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database 
PL/SQL package rman.DBMS_RCVCAT version 10.01.00 in RCVCAT database is too old

RMAN> UPGRADE CATALOG;

recovery catalog owner is RCO 
enter UPGRADE CATALOG command again to confirm catalog upgrade 

RMAN> UPGRADE CATALOG;

recovery catalog upgraded to version 11.01.00
DBMS_RCVMAN package upgraded to version 11.01.00
DBMS_RCVCAT package upgraded to version 11.01.00
PK]TK F PKC|J?OEBPS/img/GUID-25F586A8-4264-479C-96C9-2A2E3FFD0FF7-default.gif?GIF87a}}}wwwqqqmmmkkkUUUSSSKKK;;;777333)))'''%%%### ppphhhfffddd```\\\XXXRRRPPPHHHDDD@@@>>><<<888222000...&&&$$$"""  ,35 5,Mҭͧ5שჱA>>MAAM5 mA)(!E):D z7Ǐ" Xb堔L͛Ht`WPAF ʠ0HFAbn,ӧ )(E3Tj&ԯ`[aGAY*:|+Kb8;vA a]ғ3sSpȂ ҥ͂ޒքS~hTCcD0rɔ*OP cnQz&xȢДiνwb  4q483V0˟ RP\ӄhG*^߂h΀8W$`hP`` ȀHW_N_(.'˅֠`ؙ,Ba.,5n,DjB8a a& iCI<Wl1K DAc VZXPE2i (i J 18:p@-ЂNA jJª[Y ,.2iK՝0SaԪ'aٝp[1u8RLAA}%%<2CȀd6'n&$̀$(&l^Id& ̚c2 ߕY&>ɆO듴N;$K΍S{9N|"S@J3b|Vw/L}%ou~%ۧSS(0_)G??(vmƧ;կLb &w;)H<>D%Y!:  d d&t S&p\E W7C6†3V:-=^ 0XуE CܥF[hVc!,:gr\t‚?%xaL&XX"i A.{gAIJr0Q FCYa!XmB70Of7ay FIPID芙4*`xe%DLruE1уL)3kmg.$%) Bjݔ9mN3N$L=1%4褧7lqvPM9*tF1 z8Ѩ9 >)P>tgJӚA23`ԎRM !ڢRԦ:u;\!"`?{Z,@e^0;@GdT@M^7A8/Wւ;B_r]RQEJ/l  6bE'WЈ@ [JJ}_hJ@DDȃ6xӒt&~dX#*Rc %ljr [Rĭ`'zt04w+?uvkANB$=ɄMJL`kVT1 RDD^*CUJzBtXlTUr\E,U OH) F%j>;)(ukc+[\7د\ij|VӔ 62s\^b9U5 CFHiO"+]q t2^̄13,#dX+ !dKL RZTڻURxq!Lְ~€m>2 eݗ|b>*v)V lj3}-*c@ `63U! "MyW8 8 oXIIė:Han8[0}[PŢ^MllӤHnAs S"jITpkJc/:U" ݱnJ20Vd85~a>͜e䳁n6k:Q01qs<ۆ7Q.Eah6 ̩j4ϖʮZ}7Ql@IK1ATʡ`'z\B5m3nX>zT/14CAhv3{d;3 ݵ87 }kI}6Su4϶7y`WaTX U@UV)ݡU>a8nS؁ PT 蓼C.*28 58grԂ僐};s<:(n2 SMÄ)Eu=R8QVxT[8XfEixe=m&to(U!_gwqxqs P{}Sk|8!+Q > X i[&ETOVF< 8 CZI IHS iDd@Cg:M1q4H;MCZ8Yh~gU׸H&vPO9(=mXڨ4h UG0sԃQB< 4:1#hE13 ;* (` >X ! # (#i$cX=6X2vBz#sВ<<+[WuҦ-B@77*i_!)b)TgO:B J/H(a6o5;u^iU|ɗ>q= na15Yw.,@T' 30+ :h VdnC8T#5R g|8! ]: _Л f2M2ȜiY!uYl `e8ɹBH `jp0"~/Xnqa'")È0j$q4avuu@]99 mB : N0 ?x*5+.6tI6bM`Ġ z^_zppru6wryR t=6p