| Oracle® Database Backup and Recovery User's Guide 11g Release 1 (11.1) Part Number B28270-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery User's Guide 11g Release 1 (11.1) Part Number B28270-01 |
|
|
View PDF |
This chapter explains how to manage an RMAN recovery catalog. The catalog is a database schema that contains the RMAN repository data for one or more target databases. This chapter contains the following topics:
See Also:
Chapter 11, "Maintaining RMAN Backups and Repository Records"to learn how to manage the RMAN repository as stored in the control file, without a recovery catalog
The compatibility matrix in Oracle Database Backup and Recovery Reference describes supported interoperability scenarios
This section explains the basic concepts related to managing a recovery catalog.
A recovery catalog is a database schema used by RMAN to store metadata about one or more Oracle databases. Typically, you store the catalog in a dedicated database. A recovery catalog provides the following benefits:
A recovery catalog creates redundancy for the RMAN repository stored in the control file of each target database. The recovery catalog serves as a secondary metadata repository. If the target control file and all backups are lost, then the RMAN metadata still exists in the recovery catalog.
A recovery catalog centralizes metadata for all your target databases. Storing the metadata in a single place makes reporting and administration tasks easier to perform.
A recovery catalog can store metadata history much longer than the control file. This situation can be a problem if you have to do a recovery that goes further back in time than the history in the control file. The added complexity of managing a recovery catalog database can be offset by the convenience of having the extended backup history available.
Some RMAN features function only when you use a recovery catalog. For example, you can store RMAN scripts in a recovery catalog. The chief advantage of a stored script is that it is available to any RMAN client that can connect to the target database and recovery catalog. Command files are only available if the RMAN client has access to the file system on which they are stored.
A recovery catalog is required when you use RMAN in a Data Guard environment. By storing backup metadata for all primary and standby databases, the catalog enables you to offload backup tasks to one standby database while enabling you to restore backups on other databases in the environment.
The recovery catalog contains metadata about RMAN operations for each registered target database. When RMAN is connected to a recovery catalog, RMAN obtains its metadata exclusively from the catalog. The catalog includes the following types of metadata:
Datafile and archived redo log backup sets and backup pieces
Datafile copies
Archived redo logs and their copies
Database structure (tablespaces and datafiles)
Stored scripts, which are named user-created sequences of RMAN commands
Persistent RMAN configuration settings
The enrolling of a database in a recovery catalog for RMAN use is called registration. The recommended practice is to register every target database in your environment a single recovery catalog. For example, you can register databases prod1, prod2, and prod3 in a single catalog owned by catowner in the database catdb.
The owner of a centralized recovery catalog, which is also called the base recovery catalog, can grant or revoke restricted access to the catalog to other database users. Each restricted user has full read/write access to his own metadata, which is called a virtual private catalog. The RMAN metadata is stored in the schema of the virtual private catalog owner. The owner of the base recovery catalog determines which objects each virtual catalog user can access.
You can use a recovery catalog in an environment in which you use or have used different versions of Oracle Database. As a result, your environment can have different versions of the RMAN client, recovery catalog database, recovery catalog schema, and target database. "Importing and Moving a Recovery Catalog" explains how to merge multiple recovery catalog schemas into one.
For RMAN operations such as backup, restore, and crosscheck, RMAN always first updates the control file and then propagates the metadata to the recovery catalog. This flow of metadata from the mounted control file to the recovery catalog, which is known as recovery catalog resynchronization, ensures that the metadata that RMAN obtains from the control file is current.
See Also:
"Resynchronizing the Recovery Catalog"You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file system.
A local stored script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to this target database. A global stored script can be run against any database registered in the recovery catalog. A virtual private catalog user has read-only access to global scripts. Creating or updating global scripts must be done while connected to the base recovery catalog.
As explained in "RMAN in a Data Guard Environment", you must use a recovery catalog to manage RMAN metadata for all physical databases, both primary and standby databases, in the Data Guard environment. RMAN uses the recovery catalog as the single source of truth for the Data Guard environment.
RMAN can use the recovery catalog to update a primary or standby control file in a reverse resynchronization. In this case, the metadata flows from the catalog to the control file rather than the other way around. RMAN automatically performs resynchronizations in most situations in which they are needed. Thus, you should not need to use the RESYNC command to manually resynchronize very often.
See Also:
Oracle Data Guard Concepts and Administration to learn how to configure the RMAN environment for use with a standby databaseThe basic steps for setting up a recovery catalog for use by RMAN are as follows:
Create the recovery catalog.
"Creating a Recovery Catalog" explains how to perform this task.
Register your target databases in the recovery catalog.
This step enables RMAN to store metadata for the target databases in the recovery catalog. "Registering a Database in the Recovery Catalog" explains this task.
If needed, catalog any older backups whose records are no longer stored in the target control file.
"Cataloging Backups in the Recovery Catalog" explains how to perform this task.
If needed, create virtual recovery catalogs for specific users and determine the metadata to which they are permitted access.
"Creating and Managing Virtual Private Catalogs" explains how to perform this task.
Protect the recovery catalog by including it in your backup and recovery strategy.
"Protecting the Recovery Catalog" explains how to back up and recover the catalog as well as increase its availability.
The remainder of the chapter explains how to manage the recovery catalog after it is operational. You can perform the following tasks:
"Managing Stored Scripts" explains how to store RMAN scripts in the recovery catalog and manage them.
Chapter 10, "Reporting on RMAN Operations" explains how to report on RMAN operations. You can use the LIST and REPORT commands with or without a recovery catalog. "Querying Recovery Catalog Views" explains how to report on RMAN operations by means of fixed views in the recovery catalog.
"Maintaining a Recovery Catalog" explains a variety of tasks for ongoing recovery catalog maintenance, including how to import one recovery catalog into another recovery catalog.
If you no longer want to maintain a recovery catalog, then see "Dropping a Recovery Catalog".
This section explains the phases of recovery catalog creation. This section contains the following topics:
When you use a recovery catalog, RMAN requires that you maintain a recovery catalog schema. The recovery catalog is stored in the default tablespace of the schema. Note that SYS cannot be the owner of the recovery catalog.
Decide which database you will use to install the recovery catalog schema, and also how you will back up this database. Also, decide whether to operate the catalog database in ARCHIVELOG mode, which is recommended.
Note:
Do not use the target database to be backed up as the database for the recovery catalog. The recovery catalog must be protected in the event of the loss of the target database.You must allocate space to be used by the catalog schema. The size of the recovery catalog schema depends upon the number of databases monitored by the catalog. The schema also grows as the number of archived redo log files and backups for each database increases. Finally, if you use RMAN stored scripts stored in the catalog, some space must be allocated for those scripts.
For an example, assume that the trgt database has 100 files, and you back up the database once a day, producing 50 backup sets containing 1 backup piece each. If you assume that each row in the backup piece table uses the maximum amount of space, then one daily backup will consume less than 170 KB in the recovery catalog. So, if you back up once a day for a year, then the total storage in this period is about 62 MB. Assume approximately the same amount for archived logs. Thus, the worst case is about 120 MB for a year for metadata storage. For a more typical case in which only a portion of the backup piece row space is used, 15 MB for each year is realistic.
If you plan to register multiple databases in your recovery catalog, then remember to add up the space required for each one based on the previous calculation to arrive at a total size for the default tablespace of the recovery catalog schema.
If you are creating your recovery catalog in an existing database, then add enough room to hold the default tablespace to the recovery catalog schema. If you are creating a new database to hold your recovery catalog, then in addition to the space for the recovery catalog schema itself, allow space for other files in the recovery catalog database:
SYSTEM and SYSAUX tablespaces
Temporary tablespaces
Undo tablespaces
Online redo log files
Most of the space used in the recovery catalog database is devoted to supporting tablespaces, for example, the SYSTEM, temporary, and undo tablespaces. Table 12-1 describes typical space requirements.
Table 12-1 Typical Recovery Catalog Space Requirements for 1 Year
| Type of Space | Space Requirement |
|---|---|
|
|
90 MB |
|
Temp tablespace |
5 MB |
|
Rollback or undo tablespace |
5 MB |
|
Recovery catalog tablespace |
15 MB for each database registered in the recovery catalog |
|
Online redo logs |
1 MB each (3 groups, each with 2 members) |
Caution:
Ensure that the recovery catalog and target databases do not reside on the same disk. If both your recovery catalog and your target database suffer hard disk failure, then your recovery process is much more difficult. If possible, take other measures as well to eliminate common points of failure between your recovery catalog database and the databases you are backing up.After choosing the recovery catalog database and creating necessary space, you are ready to create the owner of the recovery catalog and grant this user necessary privileges. Assume the following background information for the instructions in the following sections:
User SYS with password oracle has SYSDBA privileges on the recovery catalog database catdb.
A tablespace called tools in the recovery catalog database catdb stores the recovery catalog. Note that to use an RMAN reserved word as a tablespace name, you must enclose it in quotes and put it in uppercase. (Refer to Oracle Database Backup and Recovery Reference for a list of RMAN reserved words.)
A tablespace called temp exists in the recovery catalog database.
To create the recovery catalog schema in the recovery catalog database:
Start SQL*Plus and then connect with administrator privileges to the database containing the recovery catalog. For example, enter:
CONNECT SYS/password@catdb AS SYSDBA
Create a user and schema for the recovery catalog. For example, enter:
CREATE USER rman IDENTIFIED BY cat TEMPORARY TABLESPACE temp DEFAULT TABLESPACE tools QUOTA UNLIMITED ON tools;
Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user with all privileges required to maintain and query the recovery catalog.
GRANT RECOVERY_CATALOG_OWNER TO rman;
After creating the catalog owner, create the catalog tables with the RMAN CREATE CATALOG command. The command creates the catalog in the default tablespace of the catalog owner.
To create the recovery catalog:
Connect RMAN to the database that will contain the catalog. Connect as the catalog owner. For example:
% rman
RMAN> CONNECT CATALOG rman/password@catdb
Run the CREATE CATALOG command to create the catalog. The creation of the catalog can take several minutes. If the catalog tablespace is this user's default tablespace, then you can run the following command:
CREATE CATALOG;
You can specify the tablespace name for the catalog in the CREATE CATALOG command. For example:
CREATE CATALOG TABLESPACE cat_ts;
Note:
If the tablespace name you wish to use for the recovery catalog is an RMAN reserved word, then it must be uppercase and enclosed in quotes. For example:CREATE CATALOG TABLESPACE 'CATALOG';
You can check the results by using SQL*Plus to query the recovery catalog to see which tables were created:
SQL> SELECT TABLE_NAME FROM USER_TABLES;
See Also:
Oracle Database SQL Language Reference for the SQL syntax for theGRANT and CREATE USER statements, and Oracle Database Backup and Recovery Reference for CREATE CATALOG command syntaxThis section describes how to maintain target database records in the recovery catalog. It contains the following sections:
The enrolling of a target database in a recovery catalog is called registration. If a target database is not registered in the recovery catalog, then RMAN cannot use the catalog to store metadata for operations on this database. Note that you can still perform RMAN operations on an unregistered database: RMAN always stores its metadata in the control file of the target database.
If you are not using the recovery catalog in a Data Guard environment, then use the REGISTER command to register each database. Each database must have a unique DBID. If you use the DUPLICATE command or the CREATE DATABASE statement in SQL, then the database is assigned a unique DBID automatically. If you create a database by other means, then the copied database may have the same DBID as its source database. You can change the DBID with the DBNEWID utility so that you can register the source and copy databases in the same catalog.
In a Data Guard environment, the primary and standby databases share the same DBID and database name. To be eligible for registration in the recovery catalog, each database in the Data Guard environment must have different DB_UNIQUE_NAME values. The DB_UNIQUE_NAME parameter for a database is set in its initialization parameter file.
If you use RMAN in a Data Guard environment, then you can use the REGISTER DATABASE command only for the primary database. You can use the following techniques to register a standby database in the recovery catalog:
When you connect to a standby database as TARGET, RMAN automatic registers the database in the recovery catalog.
When you run the CONFIGURE DB_UNIQUE_NAME command for a standby database that is not known to the recovery catalog, RMAN automatically registers this standby database as long as its primary database is registered.
Whether or not you use your recovery catalog in a Data Guard environment, you can use the UNREGISTER command to unregister a database from the recovery catalog.
See Also:
Oracle Database Backup and Recovery Reference for DUPLICATE syntax
Oracle Database Utilities to learn how to use the DBNEWID utility to change the DBID
Oracle Data Guard Concepts and Administration to learn about using RMAN in a Data Guard environment
The first step in using a recovery catalog with a target database is registering the target database in the recovery catalog. If you use the catalog in a Data Guard environment, then you can only register the primary database in this way.
Use the following procedure:
After making sure the recovery catalog database is open, connect RMAN to the target database and recovery catalog database. For example, issue the following to connect to the catalog database catdb as user rman (who owns the catalog schema):
% rman TARGET / CATALOG rman/password@catdb
If the target database is not mounted, then mount or open it:
STARTUP MOUNT;
Register the target database in the connected recovery catalog:
REGISTER DATABASE;
RMAN creates rows in the catalog tables to contain information about the target database, then copies all pertinent data about the target database from the control file into the catalog, synchronizing the catalog with the control file.
Verify that the registration was successful by running REPORT SCHEMA:
REPORT SCHEMA; Report of database schema File Size(MB) Tablespace RB segs Datafile Name ---- ---------- ---------------- ------- ------------------- 1 307200 SYSTEM NO /oracle/oradata/trgt/system01.dbf 2 20480 UNDOTBS YES /oracle/oradata/trgt/undotbs01.dbf 3 10240 CWMLITE NO /oracle/oradata/trgt/cwmlite01.dbf 4 10240 DRSYS NO /oracle/oradata/trgt/drsys01.dbf 5 10240 EXAMPLE NO /oracle/oradata/trgt/example01.dbf 6 10240 INDX NO /oracle/oradata/trgt/indx01.dbf 7 10240 TOOLS NO /oracle/oradata/trgt/tools01.dbf 8 10240 USERS NO /oracle/oradata/trgt/users01.dbf
If you have datafile copies, backup pieces, or archived logs on disk, then you can catalog them in the recovery catalog with the CATALOG command. When using a recovery catalog, cataloging older backups that have aged out of the control file lets RMAN use the older backups during restore operations. The following commands illustrate this technique:
CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
You can also catalog multiple backup files in a directory at once by using the CATALOG START WITH command, as shown in the following example:
CATALOG START WITH '/disk1/backups/';
RMAN lists the files to be added to the RMAN repository and prompts for confirmation before adding the backups. Be careful when creating your prefix with CATALOG START WITH. RMAN scans all paths for all files on disk which begin with the specified prefix. The prefix is not just a directory name. Using the wrong prefix can cause the cataloging of the wrong set of files.
For example, assume that a group of directories /disk1/backups, /disk1/backups-year2003, /disk1/backupsets, and /disk1/backupsets/test and so on, all contain backup files. The following command catalogs all files in all of these directories, because /disk1/backups is a prefix for the paths for all of these directories:
CATALOG START WITH '/disk1/backups';
To catalog only backups in the /disk1/backups directory, the correct command would be as follows:
CATALOG START WITH '/disk1/backups/';
See Also:
Oracle Database Backup and Recovery Reference for REGISTER syntax
Oracle Database Upgrade Guide for issues relating to database migration
The recommended practice is to create one recovery catalog that serves as the central RMAN repository for all your databases. The recovery catalog as a whole is also termed the base recovery catalog. This base catalog can contain zero or more virtual private catalogs. A virtual private catalog is a set of synonyms and views that refer to a base recovery catalog.
By default, only the owner of a base recovery catalog has access to its metadata. As the owner of a base recovery catalog, you can use the RMAN GRANT command to grant restricted access to the recovery catalog to other database users. The owner of the base recovery catalog decides which database users can share a recovery catalog and which databases they can access.
When you grant a catalog user restricted access, you give this user full read/write access to his own RMAN metadata, which is the virtual private catalog. Note that a virtual private catalog owner can create a local stored script, but only has read-only access to a global stored script. The set of views and synonyms that makes up the virtual private catalog is stored in the schema of the virtual catalog owner. The mechanisms for virtual private catalogs exist in the recovery catalog schema itself. Security is provided by the recovery catalog database, not by the RMAN executable.
The basic steps for creating a virtual catalog are as follows:
Create the database user who will own the virtual catalog (if this user does not already exist) and grant this user access privileges.
This task is described in "Creating and Granting Privileges to a Virtual Private Catalog Owner".
Create the virtual private catalog.
This task is described in "Creating a Virtual Private Catalog".
After the virtual private catalog is created, you can revoke catalog access privileges as necessary. This task is described in "Revoking Privileges from a Virtual Private Catalog Owner". "Dropping a Virtual Private Catalog" explains how to drop a virtual private catalog.
Note that if the recovery catalog is a virtual catalog, then the RMAN client connecting to it must be at patch level 10.1.0.6 or 10.2.0.3. Oracle9i 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 some virtual private catalog users.
See Also:
Oracle Database Backup and Recovery Reference for details about RMAN version compatibilityThis section assumes that you have already created a base recovery catalog and are the owner of this recovery catalog.
Assume that the following databases are registered in the base recovery catalog: prod1, prod2, and prod3. The database user who owns the base recovery catalog is catowner. You want to create database user vpc1 and grant this user access privileges only to prod1 and prod2. By default, a virtual private catalog owner has no access to the base recovery catalog.
To create and grant privileges to a virtual private catalog owner:
If the user that will own the virtual catalog is not yet created, then start a SQL*Plus session on the recovery catalog database and create the user.
For example, if you want to create database user vpc1 to own the catalog, then you could execute the following command:
CONNECT SYS/password@catdb AS SYSDBA
CREATE USER vpc1 IDENTIFIED BY apwd
DEFAULT TABLESPACE vpcusers
QUOTA UNLIMITED ON vpcusers;
Grant the RECOVERY_CATALOG_OWNER role to the database user that will own the virtual catalog, and then exit SQL*Plus.
The following example grants the role to user vpc1:
GRANT recovery_catalog_owner TO vpc1; EXIT;
Start RMAN and connect to the recovery catalog database as the base recovery catalog owner (not the virtual catalog owner).
The following example connects to the base recovery catalog as catowner:
% rman
RMAN> CONNECT CATALOG catowner/password@catdb;
Grant desired privileges to the virtual catalog owner.
The following example gives user vpc1 access to the metadata for prod1 and prod2 (but not prod3):
GRANT CATALOG FOR DATABASE prod1 TO vpc1; GRANT CATALOG FOR DATABASE prod2 TO vpc1;
You can also use a DBID rather than a database name. Note that the virtual catalog user does not have access to the metadata for any other databases registered in the recovery catalog.
You can also grant the user the ability to register new target databases in the recovery catalog. For example:
GRANT REGISTER DATABASE TO vpc1;
This section assumes that the virtual catalog owner has been given the RECOVERY_CATALOG_OWNER database role. Also, the base catalog owner used the GRANT command to give the virtual catalog owner access to metadata in the base recovery catalog.
To create a virtual private catalog:
Start RMAN and connect to the recovery catalog database as the virtual recovery catalog owner (not the base catalog owner).
The following example connects to the recovery catalog as vpc1:
% rman
RMAN> CONNECT CATALOG vpc1/password@catdb;
Create the virtual catalog.
The following command creates the virtual catalog:
CREATE VIRTUAL CATALOG;
If you intend to use a 10.2 or earlier release of RMAN with this virtual catalog, then 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.CREATE_VIRTUAL_CATALOG
This section assumes that you have already created a virtual recovery catalog.
Assume that two databases are registered in the base recovery catalog: prod1 and prod2. As owner of the base catalog, you have granted the vpc1 user access privileges to prod1. You have also granted this user the right to register databases in his virtual private catalog. Now you want to revoke privileges from vpc1.
To revoke privileges from a virtual catalog owner:
Start RMAN and connect to the recovery catalog database as the recovery catalog owner (not the virtual catalog owner).
The following example connects to the recovery catalog as catowner:
% rman
RMAN> CONNECT CATALOG catowner/password@catdb;
Revoke specified privileges from the virtual catalog owner.
The following command revokes access to the metadata for prod1 from virtual catalog owner vpc1:
REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
You can also specify a DBID rather than a database name. Note that vpc1 retains all other granted catalog privileges.
You can also revoke the privilege to register new target databases in the recovery catalog. For example:
REVOKE REGISTER DATABASE FROM vpc1;
This section assumes that you have already created a virtual recovery catalog and now want to drop the virtual catalog. When you drop a virtual private catalog, you do not remove the base recovery catalog itself, but only drop the synonyms and views that refer to the base recovery catalog.
To drop a virtual private catalog:
Start RMAN and connect to the recovery catalog database as the virtual catalog owner (not the base catalog owner).
The following example connects to the recovery catalog as vpc1:
% rman
RMAN> CONNECT CATALOG vpc1/password@catdb;
Drop the catalog.
If you are using an Oracle Database 11g or later RMAN executable, then drop the virtual private catalog with the DROP CATALOG command:
DROP CATALOG;
If you are using an Oracle Database 10g or earlier RMAN executable, then you cannot use the DROP CATALOG command. Instead, connect SQL*Plus to the catalog database as the virtual catalog user, then 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.CREATE_VIRTUAL_CATALOG
Include the recovery catalog database in your backup and recovery strategy. If you do not back up the recovery catalog and a disk failure occurs that destroys the recovery catalog database, then you may lose the metadata in the catalog. Without the recovery catalog contents, recovery of your other databases is likely to be more difficult.
A single recovery catalog is able to store metadata for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently. This section provides general guidelines for developing a strategy for protecting the recovery catalog.
The recovery catalog database is a database like any other, and is also a key part of your backup and recovery strategy. Protect the recovery catalog as you would protect any other part of your database, by backing it up. The backup strategy for your recovery catalog database should be part of your overall backup and recovery strategy.
Back up the recovery catalog with the same frequency that you back up the target database. For example, if you make a weekly whole database backup of the target database, then back up the recovery catalog immediately after all target database backups, in order to protect the record of the whole database backup. This backup can help you in a disaster recovery scenario. Even if you have to restore the recovery catalog database with a control file autobackup, you can then use the full record of backups in your restored recovery catalog database to restore the target database.
When backing up the recovery catalog database, you can use RMAN to make the backups. As illustrated in Figure 12-1, start RMAN with the NOCATALOG option so that the repository for the recovery catalog is the control file in the catalog database.
Figure 12-1 Using the Control File as the Repository for Backups of the Recovery Catalog
Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database:
Run the recovery catalog database in ARCHIVELOG mode so that you can do point-in-time recovery if needed.
Set the retention policy to a REDUNDANCY value greater than 1.
Back up the database to two separate media (for example, disk and tape).
Run BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if available, or just to disk.
Do not use another recovery catalog as the repository for the backups.
Configure the control file autobackup feature to ON.
With this strategy, the control file autobackup feature ensures that the recovery catalog database can always be recovered, so long as the control file autobackup is available.
See Also:
"Performing Disaster Recovery" for more information for recovery with a control file autobackupA recovery catalog is only effective when separated from the data that it is designed to protect. Thus, you should never store a recovery catalog containing the RMAN repository for a database in the same database as the target database. Also, do not store the catalog database on the same disks as the target database.
To illustrate why data separation is advised, assume that you store the catalog for database prod1 in prod1. If prod1 suffers a total media failure, and if the recovery catalog for prod1 is also stored in prod1, then if you lose the database you also lose the recovery catalog. At this point the only option is to restore an autobackup of the control file for prod1 and use it to restore and recover the database without the benefit of any information stored in the recovery catalog.
Logical backups of the RMAN recovery catalog created with the Data Pump Export utility can be a useful supplement for physical backups. In the event of damage to a recovery catalog database, you can use Data Pump Import to quickly reimport the exported recovery catalog data into another database and rebuild the catalog.
Restoring and recovering the recovery catalog database is much like restoring and recovering any other database with RMAN. You can restore the control file and server parameter file for the recovery catalog database from an autobackup, then restore and perform complete recovery on the rest of the database. If you are in a situation where you are using multiple recovery catalogs, then you can also use another recovery catalog to record metadata about backups of this recovery catalog database.
If recovery of the recovery catalog database through the normal Oracle recovery procedures is not possible, then you must re-create the catalog. Examples of this worst-case scenario include:
A recovery catalog database that has never been backed up
A recovery catalog database that has been backed up, but cannot be recovered because the datafile backups or archived logs are not available
You have the following options for partially re-creating the contents of the missing recovery catalog:
Use the RESYNC CATALOG command to update the recovery catalog with any RMAN repository information from the control file of the target database or a control file copy. Note that any metadata from control file records that aged out of the control file is lost.
Issue CATALOG START WITH... commands to recatalog any available backups.
To minimize the likelihood of this worst-case scenario, your backup strategy should at least include backing up the recovery catalog. This technique is described in "Backing Up the Recovery Catalog".
See Also:
Oracle Database Backup and Recovery Reference for information about the CATALOG command
Oracle Database Backup and Recovery Reference for information about the CROSSCHECK command
As explained in "About Stored Scripts", you can store scripts in the recovery catalog. This section explains how to create and manage stored scripts.
You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file system.
Stored scripts can be local or global. A local script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to that target database. A global stored script can be run against any database registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a target database.
The commands allowable within the brackets of the CREATE SCRIPT command are the same commands supported within a RUN block. Any command that is legal within a RUN command is permitted in the stored script. The following commands are not legal within stored scripts: RUN, @, and @@.
When specifying a script name, RMAN permits but generally does not require that you use quotes around the name of a stored script. If the name begins with a digit or is an RMAN reserved word, however, then you must put quotes around the name to use it as a stored script name. Consider avoiding stored script names that begin with nonalphabetic characters or that are the same as RMAN reserved words.
Consider using a naming convention to avoid confusion between global and local stored scripts. For the EXECUTE SCRIPT, DELETE SCRIPT and PRINT SCRIPT commands, if the script name passed as an argument is not the name of a script defined for the connected target instance, then RMAN looks for a global script by the same name. For example, if the global script global_backup is in the recovery catalog, but no local stored script global_backup is defined for the target database, then the following command deletes the global script:
DELETE SCRIPT global_backup;
Note that to use commands related to stored scripts, even global scripts, you must be connected to both a recovery catalog and a target instance.
You can use the CREATE SCRIPT command to create a stored script. If GLOBAL is specified, then a global script with this name must not already exist in the recovery catalog. If GLOBAL is not specified, then a local script must not already exist with the same name for the same target database. Note that you can also use the REPLACE SCRIPT to create a new script or update an existing script.
To create a stored script:
Connect RMAN to the right target database and the recovery catalog.
Run the CREATE SCRIPT command.
The following example illustrates creation of a local script:
CREATE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
For a global script, the syntax is similar:
CREATE GLOBAL SCRIPT global_full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
Optionally, you can provide a COMMENT with descriptive information:
CREATE GLOBAL SCRIPT global_full_backup
COMMENT 'use only with ARCHIVELOG mode databases'
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
You can also create a script by reading its contents from a text file. The file must begin with a left brace ({) character, contain a series of commands valid within a RUN block, and end with a right brace (}) character. Otherwise, a syntax error is signalled, just as if the commands were entered at the keyboard.
CREATE SCRIPT full_backup FROM FILE '/tmp/my_script_file.txt';
Examine the output.
If no errors are displayed, then RMAN successfully created the script and stored in the recovery catalog.
See Also:
Oracle Database Backup and Recovery Reference for the list of RMAN reserved wordsTo update stored scripts, use the REPLACE SCRIPT command. If you are replacing a local script, then you must be connected to the target database that you connected to when you created the script. If the script does not already exist, then RMAN creates it.
To replace a stored script:
Connect RMAN to the target database and recovery catalog.
Execute REPLACE SCRIPT.
This following example updates the script full_backup with new contents:
REPLACE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
You can update global scripts by specifying the GLOBAL keyword as follows:
REPLACE GLOBAL SCRIPT global_full_backup
COMMENT 'A script for full backup to be used with any database'
{
BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
}
As with CREATE SCRIPT, you can update a local or global stored script from a text file with the following form of the command:
REPLACE GLOBAL SCRIPT global_full_backup FROM FILE '/tmp/my_script_file.txt';
Use the EXECUTE SCRIPT command to run a stored script. If GLOBAL is specified, then a global script with this name must already exist in the recovery catalog; otherwise, RMAN returns error RMAN-06004. If GLOBAL is not specified, then RMAN searches for a local stored script defined for the current target database. If no local script with this name is found, then RMAN searches for a global script by the same name and executes it if one is found.
To execute a stored script:
Connect to the target database and recovery catalog.
If needed, use SHOW to examine your configured channels.
Your script will use the automatic channels configured at the time you execute the script. Use ALLOCATE CHANNEL commands in the script if you need to override the configured channels. Because of the RUN block, if an RMAN command in the script fails, subsequent RMAN commands in the script will not execute.
Run EXECUTE SCRIPT. This command requires a RUN block, as shown in the following example:
RUN
{
EXECUTE SCRIPT full_backup;
}
The preceding command invokes a local script if one is with the name specified. If no local script is found, but there is a global script with the name specified, then RMAN executes the global script.
You can also use EXECUTE GLOBAL SCRIPT to control which script is invoked if a local and a global script have the same name. If there is no local script called global_full_backup, the following two commands have the same effect:
RUN
{
EXECUTE GLOBAL SCRIPT global_full_backup;
}
RUN
{
EXECUTE SCRIPT global_full_backup;
}
You can specify substitution variables in the CREATE SCRIPT command. When you start RMAN on the command line, the USING clause specifies one or more values for use in substitution variables in a command file. As in SQL*Plus, &1 indicates where to place the first value, &2 indicates where to place the second value, and so on.
To create and use a dynamic stored script:
Create a command file that contains a CREATE SCRIPT statement with substitution variables for values that must be dynamically updated.
The following example shows the content of command file /tmp/catscript.rman.The script uses substitution variables for the name of the tape set, for a string in the FORMAT specification, and for the name of the restore point.
CREATE SCRIPT quarterly {
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3
DATABASE;
}
Connect RMAN to the target database (which must be mounted or open) and recovery catalog, specifying the initial values for the recovery catalog script.
For example, enter the following command:
% rman TARGET / CATALOG rman/password@inst2 USING arc_backup bck0906 FY06Q3
A recovery catalog is required for KEEP FOREVER, but is not required for any other KEEP option.
Run the command file created in the first step to create the stored script.
For example, run the /tmp/catscript.rman command file as follows:
RMAN> @/tmp/catscript.rman
Note that this step creates but does not execute the stored script.
Every quarter, execute the stored script, passing values for the substitution variables.
The following example executes the recovery catalog script named quarterly. The example specifies arc_backup as the name of the media family (set of tapes), bck1206 as part of the FORMAT string and FY06Q4 as the name of the restore point.
RUN
{
EXECUTE SCRIPT quarterly
USING arc_backup
bck1206
FY06Q4;
}
The PRINT SCRIPT command displays a stored script or writes it out to a file.
To print stored scripts:
Connect RMAN to the target database and recovery catalog.
Execute the PRINT SCRIPT command as follows:
PRINT SCRIPT full_backup;
To send the contents of a script to a file, use this form of the command:
PRINT SCRIPT full_backup TO FILE '/tmp/my_script_file.txt';
For global scripts, the analogous syntax would be as follows:
PRINT GLOBAL SCRIPT global_full_backup; PRINT GLOBAL SCRIPT global_full_backup TO FILE '/tmp/my_script_file.txt';
Use the LIST ... SCRIPT NAMES command to display the names of scripts defined in the recovery catalog. LIST GLOBAL SCRIPT NAMES and LIST ALL SCRIPT NAMES are the only commands that work when RMAN is connected to a recovery catalog without connecting to a target instance; the other forms of the LIST ... SCRIPT NAMES command require a recovery catalog connection.
To list stored script names:
Connect to the target instance and recovery catalog.
Execute the LIST ... SCRIPT NAMES command.
For example, run the following command to list the names of all global and local scripts that can be executed for the currently connected target database:
LIST SCRIPT NAMES;
The following example lists only global script names:
LIST GLOBAL SCRIPT NAMES;
To list the names of all scripts stored in the current recovery catalog, including global scripts and local scripts for all target databases registered in the recovery catalog, use the following form of the command:
LIST ALL SCRIPT NAMES;
The output will indicate for each script listed which target database the script is defined for (or whether a script is global).
See Also:
Oracle Database Backup and Recovery Reference forLIST SCRIPT NAMES command syntax and output formatUse the DELETE GLOBAL SCRIPT command to delete a stored script from the recovery catalog.
To delete a stored script:
Connect RMAN to the target database and recovery catalog.
Enter the DELETE SCRIPT command.
If you use DELETE SCRIPT without GLOBAL, and there is no stored script for the target database with the specified name, then RMAN looks for a global stored script by the specified name and deletes the global script if it exists. For example, suppose you enter the following command:
DELETE SCRIPT 'global_full_backup';
In this case, RMAN looks for a script global_full_backup defined for the connected target database, and if it did not find one, it searches the global scripts for a script called global_full_backup and delete that script.
To delete a global stored script, use DELETE GLOBAL SCRIPT:
DELETE GLOBAL SCRIPT 'global_full_backup';
To run the RMAN client and start a stored script in the recovery catalog on startup, use the SCRIPT argument when starting the RMAN client. For example, you could enter the following command to execute script /tmp/fbkp.cmd:
% rman TARGET SYS/password@trgt CATALOG rman/password@catdb SCRIPT '/tmp/fbkp.cmd';
You must connect to a recovery catalog, which contains the stored script, and target database, to which the script will apply, when starting the RMAN client.
If local and global scripts are defined with the same name, then RMAN always executes the local script.
See Also:
Oracle Database Backup and Recovery Reference for full RMAN client command line syntaxThis section describes various management and maintenance tasks. This section contains the following topics:
After you have created a recovery catalog and registered your target databases, you need to maintain this catalog. For example, you need to run the RMAN maintenance commands, which are explained in Chapter 11, "Maintaining RMAN Backups and Repository Records", to update backup records as well as to delete backups that are no longer needed. You must perform this type of maintenance regardless of whether you use RMAN with a recovery catalog. Other types of maintenance, such as upgrading a recovery catalog schema, are specific to use of RMAN with a recovery catalog.
If you use a recovery catalog in a Data Guard environment, then special considerations apply for backups and database files recorded in the catalog. See "RMAN File Management in a Data Guard Environment" for an explanation of when backups are accessible to RMAN and how RMAN maintenance commands work with accessible backups.
When RMAN performs a resynchronization, it compares the recovery catalog to either the current or backup control file of the target database and updates the catalog with metadata that is missing or changed. Most RMAN commands perform a resynchronization automatically when the target control file is mounted and the catalog is available. In a Data Guard environment, RMAN can perform a reverse resynchronization to update a database control file with metadata from the catalog.
Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current. Resynchronizations can be full or partial.
In a partial resynchronization, RMAN reads the current control file of the target database to update changed metadata about new backups, new archived redo logs, and so on. RMAN does not resynchronize metadata about the database physical schema.
In a full resynchronization, RMAN updates all changed records, including those for the database schema. RMAN performs a full resynchronization after structural changes to database (adding or dropping database files, creating new incarnation, and so on) or after changes to the RMAN persistent configuration.
RMAN creates a snapshot control file, which is a temporary backup control file, when it performs a full resynchronization. The database ensures that only one RMAN session accesses a snapshot control file at any point in time. RMAN creates the snapshot control file in an operating system-specific location on the target database host. You can specify the name and location of the snapshot control file, as explained in "Configuring the Snapshot Control File Location".
This snapshot control file ensures that RMAN has a consistent view of the control file. Because the control file is intended for short-term use, it is not registered in the catalog. RMAN records the control file checkpoint in the recovery catalog to indicate the currency of the catalog.
See Also:
Oracle Database Backup and Recovery Reference for more information about theRESYNC commandRMAN only automatically resynchronizes the recovery catalog with a database when connected to this database as TARGET. Thus, RMAN does not automatically resynchronize every database in a Data Guard environment when connected as TARGET to one database in the environment. You can use the RESYNC CATALOG FROM DB_UNIQUE_NAME command to manually resynchronize the recovery catalog with a database in the Data Guard environment.
For an example of a manual resynchronization, assume that RMAN is connected as TARGET to production database prod, and that you have used CONFIGURE to create a configuration for dgprod3. If you run RESYNC CATALOG FROM DB_UNIQUE_NAME FROM dgprod3, then RMAN resynchronizes the recovery catalog with the dgprod3 control file. In this case RMAN performs both a normal resynchronization, in which metadata flows from the dgprod3 control file to the catalog, and a reverse resynchronization. In a reverse resynchronization, RMAN uses the persistent configurations in the recovery catalog to update the dgprod3 control file.
RMAN automatically resynchronizes the recovery catalog when RMAN is connected to a target database and recovery catalog and you have executed RMAN commands. Thus, you should not need to manually run the RESYNC CATALOG command very often. The following sections describe situations requiring a manual catalog resynchronization.
If the recovery catalog is unavailable when you issue RMAN commands that cause a partial resynchronization, then open the catalog database later and resynchronize it manually with the RESYNC CATALOG command.
For example, the target database may be in New York while the recovery catalog database is in Japan. You may not want to make daily backups of the target database in CATALOG mode, to avoid depending on the availability of a geographically distant database. In such a case you could connect to the catalog as often as feasible and run the RESYNC CATALOG command.
Assume that a target database runs in ARCHIVELOG mode. Also assume that you do the following:
Back up the database infrequently (for example, hundreds of redo logs are archived between database backups)
Generate a high number of log switches every day (for example, 1000 switches between catalog resynchronizations)
In this case, you may want to manually resynchronize the recovery catalog regularly because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived. The database stores metadata about redo log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog.
How frequently you need to resynchronize the recovery catalog depends on the rate at which the database archives redo logs. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resynchronization. If no records have been inserted or changed, then the cost of resynchronization is very low; if many records have been inserted or changed, then the resynchronization is more time-consuming.
You can create or change an RMAN configuration for a standby database even when not connected to this database as TARGET. You perform this task with the CONFIGURE DB_UNIQUE_NAME or CONFIGURE ... FOR DB_UNIQUE_NAME command. As explained in "Manually Resynchronizing the Recovery Catalog", you can resynchronize the standby database manually to update the control file of the standby database.
Your goal is to ensure that the metadata in the recovery catalog is current. Because the recovery catalog obtains its metadata from the target control file, the currency of the data in the catalog depends on the currency of the data in the control file. You need to make sure that the backup metadata in the control file is recorded in the catalog before it is overwritten with new records.
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum number of days that records are retained in the control file before they are candidates for being overwritten. Thus, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. You should perform either of the following actions at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting:
Make a backup, thereby performing an implicit resynchronization of the recovery catalog
Manually resynchronize the recovery catalog with the RESYNC CATALOG command
Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances.
Caution:
Never setCONTROL_FILE_RECORD_KEEP_TIME to 0. If you do, then backup records may be overwritten in the control file before RMAN is able to add them to the catalog.One problem can arise if the control file becomes too large. The size of the target database control file grows depending on the number of:
Backups that you perform
Archived redo logs that the database generates
Days that this information is stored in the control file
If the control file grows so large that it can no longer expand because it has reached either the maximum number of blocks or the maximum number of records, then the database may overwrite the oldest records even if their age is less than the CONTROL_FILE_RECORD_KEEP_TIME setting. In this case, the database writes a message to the alert log. If you discover that this situation occurs frequently, then reducing the value of CONTROL_FILE_RECORD_KEEP_TIME and increase the frequency of resynchronizations.
See Also:
Oracle Database Reference for more information about the CONTROL_FILE_RECORD_KEEP_TIME parameter
Oracle Database Administrator's Guide for more detailed information on other aspects of control file management
"Preventing the Loss of Control File Records" to learn how to monitor the overwriting of control file records
Use RESYNC CATALOG to force a full resynchronization of the recovery catalog with a target database control file. Note that you can specify a database unique name with RESYNC FROM DB_UNIQUE_NAME or ALL, depending on whether you want to resynchronize a specific database or all databases in the Data Guard environment. Typically, you would perform this operation when you have the CONFIGURE command for a standby database, but have not yet connected to this standby database.
Start RMAN and connect to the target database and recovery catalog.
Connect RMAN to the target and recovery catalog databases, and then mount or open the target database if it is not already mounted or open:
STARTUP MOUNT;
Resynchronize the recovery catalog.
Run the RESYNC CATALOG command at the RMAN prompt as follows:
RESYNC CATALOG;
The following example resynchronizes the control file of standby1:
RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;
The following variation resynchronizes the control files for all databases in the Data Guard environment that have a DBID of 234325:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
See Also:
Oracle Database Backup and Recovery Reference for RESYNC CATALOG command syntax
Oracle Data Guard Concepts and Administration to learn how to configure the RMAN environment for use with a standby database
You may decide to change the DB_UNIQUE_NAME of a database in a Data Guard environment. In this case, you can run the CHANGE DB_UNIQUE_NAME command to associate the metadata stored in recovery catalog for the old DB_UNIQUE_NAME to the new DB_UNIQUE_NAME. Note that the CHANGE DB_UNIQUE_NAME command does not actually change the DB_UNIQUE_NAME of the database itself. Instead, it updates the catalog metadata for the database whose unique name has been or will be changed.
The following procedure assumes that the DB_UNIQUE_NAME of the primary database is prodny, and that you have changed the DB_UNIQUE_NAME of a standby database from prodsf1 to prodsf2. You can use the same procedure after changing the DB_UNIQUE_NAME of a primary database, except in step 1 connect RMAN as TARGET to a standby database instead of a primary database.
To update the recovery catalog after a DB_UNIQUE_NAME is changed:
Connect RMAN to the primary database and recovery catalog. For example, enter the following commands:
% rman RMAN> CONNECT CATALOG catowner/password@catdb RMAN> CONNECT TARGET SYS/password@prodny
List the DB_UNQUE_NAME values known to the recovery catalog.
Execute the following LIST command:
LIST DB_UNIQUE_NAME OF DATABASE;
Change the DB_UNIQUE_NAME in the RMAN metadata.
The following example changes the database unique name from prodsf1 to prodsf2:
CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
You can use the UNREGISTER DATABASE command to unregister a database from the recovery catalog. When a database is unregistered from the recovery catalog, all RMAN repository records in the recovery catalog are lost. The database can be registered again, but the recovery catalog records for that database are then based on the contents of the control file at the time of reregistration. Records older than the CONTROLFILE_RECORD_KEEP_TIME setting in the target database control file are lost. Stored scripts, which are not stored in the control file, are also lost.
This scenario assumes that you are not using the recovery catalog to store metadata for primary and standby databases.
To unregister a database:
Start RMAN and connect to the target database, that is, the database that you want to unregister. Also connect to the recovery catalog. For example, enter:
% rman TARGET / CATALOG rman/password@catdb
connected to target database: RDBMS (DBID=1237603294)
connected to recovery catalog database
It is not necessary to connect to the target database, but if you do not, then you must specify the name of the target database in the UNREGISTER command. If more than one database has the same name in the recovery catalog, then you must create a RUN block around the command and use SET DBID to set the DBID for the database.
Make a note of the DBID as displayed by RMAN at startup.
If more than one database is registered in the recovery catalog with the same name, then you need the DBID to uniquely identify the database.
As a precaution, it may be useful to list all of the backups recorded in the recovery catalog using LIST BACKUP SUMMARY and LIST COPY SUMMARY. This way, you can recatalog backups not known to the control file if you later decide to reregister the database.
If your intention is to actually delete all backups of the database completely, then run DELETE statements to delete all existing backups. Do not delete all backups if your intention is only to remove the database from the recovery catalog and rely on the control file to store the RMAN metadata for this database.
The following commands illustrate how to delete backups:
DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK; DELETE COPY;
RMAN lists the backups that it intends to delete and prompts for confirmation before deleting them.
Run the UNREGISTER DATABASE command. For example:
UNREGISTER DATABASE;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database name is "RDBMS" and DBID is 931696259 Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database unregistered from the recovery catalog
The UNREGISTER command supports a DB_UNIQUE_NAME clause for use in a Data Guard environment. You can use this clause to remove metadata for a specific database.
The recovery catalog associates a backup with a particular database. When you unregister a database, RMAN updates the database name for these backup files to null. Thus, the backups are still recorded but have no owner. You can execute the CHANGE ... RESET DB_UNIQUE_NAME command to associate ownership of the currently ownerless backups to a different database. If you specify INCLUDING BACKUPS on the UNREGISTER command, then RMAN removes the backup metadata for the unregistered database as well.
In this scenario, assume that primary database lnx3 has associated standby databases standby. You want to unregister the standby database.
To unregister a standby database:
Start RMAN and connect to the recovery catalog and target database. The target database is the primary database.
For example, enter the following commands:
% rman RMAN> CONNECT TARGET SYS/password@lnx3 RMAN> CONNECT CATALOG rman/password@catdb
List the database unique names.
For example, execute the LIST command as follows:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 1 LNX3 781317675 STANDBY STANDBY 1 LNX3 781317675 PRIMARY LNX3
Run the UNREGISTER DB_UNIQUE_NAME command.
For example, execute the UNREGISTER command as follows:
UNREGISTER DB_UNIQUE_NAME standby;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database db_unique_name is "standby", db_name is "LNX3" and DBID is 781317675 Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database with db_unique_name testsby2 unregistered from the recovery catalog
As explained in "Database Incarnations", you create a new incarnation of the database when you open the database with the RESETLOGS option. You can access a record of the new incarnation in the V$DATABASE_INCARNATION view.
If you open the database with the RESETLOGS option, then a new database incarnation record is automatically created in the recovery catalog. The database also implicitly and automatically issues a RESET DATABASE command, which specifies that this new incarnation of the database is the current incarnation. All subsequent backups and log archiving done by the target database is associated with the new database incarnation.
Whenever RMAN returns the database to an SCN before the current RESETLOGS SCN, either by means of RESTORE and RECOVER or FLASHBACK DATABASE, the RESET DATABASE TO INCARNATION command is required. However, you do not need to execute RESET DATABASE TO INCARNATION explicitly in the following scenarios because RMAN runs the command implicitly.
You use FLASHBACK DATABASE to rewind the database to an SCN in the direct ancestral path (see "Database Incarnations" for an explanation of the direct ancestral path).
You use FLASHBACK DATABASE to rewind the database to a restore point.
The following procedure explains how to reset the database incarnation when recovering through a RESETLOGS.
To reset the recovery catalog to an older incarnation for media recovery:
Determine the incarnation key of the desired database incarnation. Obtain the incarnation key value by issuing a LIST command:
LIST INCARNATION OF DATABASE trgt; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- ------- ------ ------- ---------- ---------- 1 2 TRGT 1224038686 PARENT 1 02-JUL-02 1 582 TRGT 1224038686 CURRENT 59727 10-JUL-02
The incarnation key is listed in the Inc Key column.
Reset the database to the old incarnation. For example, enter:
RESET DATABASE TO INCARNATION 2;
If the control file of the previous incarnation is available and mounted, then skip to step 6 of this procedure. Otherwise, shut down the database and start it without mounting. For example:
SHUTDOWN IMMEDIATE STARTUP NOMOUNT
Restore a control file from the old incarnation. If you have a control file tagged, then specify the tag. Otherwise, you can run the SET UNTIL command, as in this example:
RUN
{
SET UNTIL 'SYSDATE-45';
RESTORE CONTROLFILE; # only if current control file is not available
}
Mount the restored control file:
ALTER DATABASE MOUNT;
Run RESTORE and RECOVER commands to restore and recover the database files from the prior incarnation, then open the database with the RESETLOGS option. For example, enter:
RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;
See Also:
Oracle Database Backup and Recovery Reference forRESET DATABASE syntax, Oracle Database Backup and Recovery Reference for LIST syntaxThis section explains what a recovery catalog upgrade is and when you need to do it.
If you use a version of the recovery catalog schema that is older than that required by the RMAN client, then you must upgrade it. The compatibility matrix in Oracle Database Backup and Recovery Reference explains which schema versions are compatible with which versions of RMAN. For example, you must upgrade the catalog if you use an Oracle Database 11g RMAN client with a release 10.2 version of the recovery catalog schema.
Note that 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 when it did not include the CREATE TYPE privilege, then you must grant CREATE TYPE to this user explicitly before upgrading the catalog.
You receive an error when issuing UPGRADE CATALOG if the recovery catalog is already at a version greater than that required by the RMAN client. RMAN permits the UPGRADE CATALOG command to be run if the recovery catalog is current and does not require upgrading, however, so that you can re-create packages at any time if necessary. Check the message log for error messages generated during the upgrade.
Assume that you upgrade the recovery catalog schema to Oracle Database 11g in a Data Guard environment. When RMAN connects to a standby database, it automatically registers the new database information and resynchronizes to obtain the filenames from the control file.
During the resynchronization, RMAN associates the names with the target database name. Because the recovery catalog contains historical metadata, some records in the catalog will not be known to the control file. For example, the standby1 control file will not know about all backups made on primary1. The database unique names for these old records will be null. As explained in "About Recovery Catalog Maintenance", you can use CROSSCHECK to fix these records.
The schema version of the recovery catalog is stored in the recovery catalog itself. The information is important in case you maintain multiple databases of different versions in your production system, and need to determine whether the catalog schema version is usable with a specific target database version.
To determine the schema version of the recovery catalog:
Start SQL*Plus and connect to the recovery catalog database as the catalog owner. For example:
% sqlplus rman/cat@catdb
Query the RCVER table to obtain the schema version, as in the following example (sample output included):
SELECT * FROM rcver; VERSION ------------ 10.02.00
If the table displays multiple rows, then the highest version in the RCVER table is the current catalog schema version. The table stores only the major version numbers and not the patch numbers. For example, assume that the rcver table displays the following rows:
VERSION ------------ 08.01.07 09.00.01 10.02.00
These rows indicate that the catalog was created with a release 8.1.7 executable, then upgraded to release 9.0.1, and finally upgraded to release 10.2.0. The current version of the catalog schema is 10.2.0.
See Also:
Oracle Database Backup and Recovery Reference for the complete set of compatibility rules governing the RMAN environmentThis scenario assumes that you are upgrading a recovery catalog schema to the current version.
To upgrade the recovery catalog:
If you created the recovery catalog owner in a release before 10gR1, and if the RECOVERY_CATALOG_OWNER role did not include the CREATE TYPE privilege, then grant it. For example:
% sqlplus
SQL> CONNECT SYS/password@prod AS SYSDBA
SQL> GRANT CREATE TYPE TO rman;
SQL> EXIT;
Connect RMAN to the target and recovery catalog databases. For example, enter:
% rman
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman/password@catdb
connected to recovery catalog database
Issue the UPGRADE CATALOG command:
UPGRADE CATALOG; recovery catalog owner is rman enter UPGRADE CATALOG command again to confirm catalog upgrade
Enter the UPDATE CATALOG command again to confirm:
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
See Also:
Oracle Database Backup and Recovery Reference for UPGRADE CATALOG command syntax
Oracle Database Backup and Recovery Reference for information about recovery catalog compatibility
Oracle Database Upgrade Guide for complete compatibility and migration information
You can use the IMPORT CATALOG command in RMAN to merge one recovery catalog schema into another. This command is useful in the following situations:
You have multiple recovery catalog schemas for different versions of the database. You want to merge all existing schemas into one without losing backup metadata.
You want to move a recovery catalog from one database to another database.
When using IMPORT CATALOG, the source catalog schema is the catalog schema that you want to import into a different schema. The destination catalog schema is the catalog schema into which you intend to import the source catalog schema.
By default, RMAN imports metadata from all target databases registered in the source recovery catalog. Optionally, you can specify the list of database IDs to be imported from the source catalog schema.
By default, RMAN unregisters the imported databases from the source catalog schema after a successful import. To indicate whether the unregister was successful, RMAN prints messages before and after unregistering the merged databases. You can also specify the NO UNREGISTER option to specify that the databases should not be unregistered from the destination catalog.
A stored script is either global or local. It is possible for global scripts, but not local scripts, to have name conflicts during import because the destination schema already contains the script name. In this case, RMAN renames the global script name to COPY OF script_name. For example, RMAN renames bp_cmd to COPY OF bp_cmd.
If the renamed global script is still not unique, then RMAN renames it to COPY(2) OF script_name. If this script name also exists, then RMAN renames the script to COPY(3) OF script_name. RMAN continues the COPY(n) OF pattern until the script is uniquely named.
As shown in compatibility matrix in Oracle Database Backup and Recovery Reference, a target database, recovery catalog database, and recovery catalog schema can be at different database versions. The recommended practice is to import all existing recovery catalogs into a single recovery catalog at the latest version of the recovery catalog schema. "Determining the Schema Version of the Recovery Catalog" explains how to determine the catalog version. Check the compatibility matrix to determine which schema versions are compatible in your environment.
When using IMPORT CATALOG, the version of the source recovery catalog schema must be equal to the current version of the RMAN executable with which you run the command. If the source catalog schema is a lower version, then upgrade it to the current version before importing the schema. "Upgrading the Recovery Catalog" explains how to upgrade. If the source recovery catalog schema is a higher version, then retry the import with a higher version RMAN executable.
No database can be registered in both the source and destination catalog schema. If a database is currently registered in both catalog schemas, then unregister the database from source catalog schema before performing the import.
When importing one recovery catalog into another, no connection to a target database is necessary. RMAN only needs connectivity to the source and destination catalogs.
In this example, database srcdb contains a 10.2 recovery catalog schema owned by user 102cat, while database destdb contains an 11.1 recovery catalog schema owned by user 111cat.
To import a recovery catalog:
Start an RMAN session and connect to the destination recovery catalog schema. For example:
% rman
RMAN> CONNECT CATALOG 111cat/password@destdb;
Import the source recovery catalog schema, specifying the connection string for the source catalog.
For example, enter the following command to import the catalog owned by 102cat on database srcdb:
IMPORT CATALOG 102cat/oracle@srcdb;
A variation is to import metadata for a subset of the target databases registered in the source catalog. You can specify the databases by DBID or database name, as shown in the following examples:
IMPORT CATALOG 102cat/oracle@srcdb DBID=1423241, 1423242; IMPORT CATALOG 102cat/oracle@srcdb DB_NAME=prod3, prod4;
Optionally, connect to a target database to check that the metadata was successfully imported. For example, the following commands connect to database prod1 and list all backups for this database:
CONNECT TARGET SYS/password@prod1;
LIST BACKUP;
The procedure for moving a recovery catalog from one database to another is a variation of the procedure for importing a catalog. In this scenario, the source database is the database containing the existing recovery catalog, while the destination database will contain the moved recovery catalog.
To move a recovery catalog from the source database to the destination database:
Create a recovery catalog on the destination database, but do not register any databases in the new catalog.
"Creating a Recovery Catalog" explains how to perform this task.
Import the source catalog into the catalog created in the preceding step.
"Importing a Recovery Catalog" explains how to perform this task.
The DROP CATALOG command removes those objects that were created as a result of the CREATE CATALOG command. If the user who owns the recovery catalog also owns objects that were not created by CREATE CATALOG, then the DROP CATALOG command does not remove these objects.
If you drop a catalog, and if you have no backups of the recovery catalog schema, then backups of all target databases registered in this catalog may become unusable. The control file of every target database will still retain a record of recent backups of this database.
The DROP CATALOG command is not appropriate for unregistering a single database from a recovery catalog that has multiple target databases registered. Dropping the catalog deletes the recovery catalog record of backups for all target databases registered in the catalog.
To drop the recovery catalog schema:
Use RMAN to connect to the target and recovery catalog databases.
% rman TARGET / CATALOG rman/password@catdb
Issue the DROP CATALOG command twice to confirm:
DROP CATALOG; recovery catalog owner is rman enter DROP CATALOG command again to confirm catalog removal DROP CATALOG;
Note:
Even after you drop the recovery catalog, the control file still contains records about the backups. To purge RMAN repository records from the control file, re-create the control file.See Also:
Oracle Database Backup and Recovery Reference forDROP CATALOG command syntax, and "Unregistering a Target Database from the Recovery Catalog" to learn how to unregister a database from the catalog