Ace2oracle | Rman Practices Part 5 Back To Basics

Category - RMAN

RMAN Practices - PART 5- Back to Basics

RMAN Practices - PART 5- Back to Basics

Managing a Recovery Catalog

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.

Purpose of the RMAN 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 capability is useful if you must 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.
Basic Concepts for the RMAN Recovery Catalog

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:

Data file and archived redo log backup sets and backup pieces

Data file copies

Archived redo logs and their copies

Database structure (tablespaces and data files)

Stored scripts, which are named user-created sequences of RMAN commands

Persistent RMAN configuration settings

About RMAN Recovery Catalog Resynchronization

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.

Recovery Catalog 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 do not need to use the RESYNC command to manually resynchronize very often.

Basic Steps of Managing a Recovery Catalog

Managing a recovery catalog consists of creating the catalog and then registering your target databases with the catalog.

The basic steps for setting up a recovery catalog for use by RMAN are as follows:

Create the recovery catalog.

    This step enables RMAN to store metadata for the target databases in the recovery catalog.

    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, and increase its availability.

====

Creating the Recovery Catalog Schema Owner

After choosing the recovery catalog database and creating the 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:

A tablespace called TOOLS in the recovery catalog database CATDB stores the recovery catalog.
If you use an RMAN reserved word as a tablespace name, you must enclose it in quotes and put it in uppercase.

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 connect with administrator privileges to the database containing the recovery catalog. In this example, the database is catdb.
Create a user and schema for the recovery catalog. For example, you could enter the following SQL statement (replacing password with a user-defined password):

CREATE USER rco IDENTIFIED BY password
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;

Note:

Create a password that is secure.
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 rco;

(Optional) Enable the VPD model for the recovery catalog by running the dbmsrmanvpc.sql script with the –vpd option.
The following command enables the VPD model for the recovery catalog owned by the user rco:

SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;

To ensure that the recovery catalog schema owner can control virtual private catalogs using the VPD model, specify the ORACLE_HOME path that corresponds to the exact database version used by the recovery catalog schema. For example, specify the 19c ORACLE_HOME path if the recovery catalog is connected to Oracle Database 19c.

===
Running the CREATE CATALOG Command

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.

Note:Starting with Oracle Database 12c Release 1 (12.1.0.2), the recovery catalog database must use the Enterprise Edition of Oracle Database.

To create the recovery catalog:

    Enable Oracle Partitioning for the recovery catalog database.
    Start RMAN and connect to the database that will contain the catalog. Connect to the database as the recovery catalog owner.
    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:

RMAN> CREATE CATALOG;

You can specify the tablespace name for the catalog in the CREATE CATALOG command. For example:

RMAN> CREATE CATALOG TABLESPACE cat_tbs;

Note:

If the tablespace name 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;
===

Registering a Database in the Recovery Catalog

Registering a target database in the recovery catalog maintains the database’s records in the recovery catalog.
About Registration of a Database in the Recovery Catalog

The process of 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. 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 RMAN 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.

You can use the UNREGISTER command to unregister a database from the recovery catalog.
About Standby Database Registration

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 automatically 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 if its primary database is registered.

Related Topics

Oracle Data Guard Concepts and Administration
Oracle Database Utilities

Registering a Database with the REGISTER DATABASE Command

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:

Start RMAN and connect to a target database and recovery catalog. The recovery catalog database must be open.

For example, issue the following command to connect to the catalog database with the net service name catdb as user rco (who owns the catalog schema):

% rman TARGET / CATALOG rco@catdb;

If the target database is not mounted, then mount or open it:

STARTUP MOUNT;

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 for database with db_unique_name TRGT

List of Permanent Datafiles===========================
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

List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 200 TEMP 32767 /oracle/oradata/trgt/tbs_tmp.dbf

====

About Resynchronization of the Recovery 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.

About RMAN Recovery Catalog Resynchronization in a Data Guard Environment

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

Manually Resynchronizing the Recovery Catalog

Use RESYNC CATALOG to force a full resynchronization of the recovery catalog with a target database control file.

You can specify a database unique name with RESYNC CATALOG FROM DB_UNIQUE_NAME or ALL, depending on whether you want to resynchronize a specific database or all databases in the Data Guard environment. To use DB_UNIQUE_NAME ALL, you must connect to the target database using password file authentication and as the SYS user. Typically, you perform this operation after you run the CONFIGURE command for a standby database, but have not yet connected to this standby database.

Start RMAN and connect to a target database and recovery catalog.
Mount or open the target database:

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, when connected to the target database as the SYS user and using password file authentication, resynchronizes the control files for all databases in the Data Guard environment:

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

Updating the Recovery Catalog After Changing a DB_UNIQUE_NAME

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.

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 DB_UNIQUE_NAME is changed:

Connect RMAN to the primary database as TARGET and also to the recovery catalog. For example, enter the following commands:

% rman
RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> CONNECT TARGET sbu@prodny

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

List the DB_UNQUE_NAME values known to the recovery catalog.

Run the following LIST command:

RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

Change the DB_UNIQUE_NAME in the RMAN metadata.

The following example changes the database unique name from standby database prodsf1 to prodsf2:

RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;

Unregistering a Target Database from the Recovery Catalog

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.
Unregistering a Target Database When Not in a Data Guard Environment

Use the UNREGISTER DATABASE command to unregister a target database.

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 as TARGET to the database to unregister. Also connect to the recovery catalog.

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 multiple databases have 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.

For example, RMAN outputs a line of the following form when it connects to a target database that is open:

connected to target database: PROD (DBID=39525561)

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

Unregistering a Standby Database

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 database standby1. You want to unregister the standby database.

To unregister a standby database:

Start RMAN and connect as TARGET to the primary database. Also, connect RMAN to a recovery catalog.

For example, enter the following commands:

% rman
RMAN> CONNECT TARGET "sbu@lnx3 AS SYSBACKUP";

target database Password: password
connected to target database: LNX3 (DBID=781317675)

RMAN> CONNECT CATALOG rco@catdb;

List the database unique names.

For example, execute the LIST DB_UNIQUE_NAME 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         STANDBY1
1       LNX3    781317675         PRIMARY         LNX3

Run the UNREGISTER DB_UNIQUE_NAME command.

For example, execute the UNREGISTER command as follows to unregister database standby:

RMAN> UNREGISTER DB_UNIQUE_NAME standby1;

RMAN displays the database name and DBID, and prompts you for a confirmation:

database db_unique_name is "standby1", 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 standby1 unregistered from the recovery catalog

Unregistering a Target Database in a Recovery Appliance Environment

In a Zero Data Loss Recovery Appliance (Recovery Appliance) environment, the UNREGISTER DATABASE command cannot be used to unregister a protected database from the Recovery Appliance catalog. Instead, use the DBMS_RA.DELETE_DB procedure.

To unregister a target database from the Recovery Appliance recovery catalog:

Obtain the DB_NAME of the protected database that you want to unregister.
(Optional) To delete all the backups associated with this protected database, perform the following steps:

Connect to the protected database as a user with the SYSDBA or SYSBACKUP privilege.

Use the following commands to delete all 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.

Start SQL*Plus and connect to the Recovery Appliance metadata database as RASYS (Recovery Appliance catalog owner).
Unregister the protected database from Recovery Appliance using the DBMS_RA.DELETE_DB procedure.

    begin
          DBMS_RA.DELETE_DB('TEST_DB');
    end;
    /

RMAN prompts you to confirm the unregister database operation.

===
Resetting the Database Incarnation in the Recovery Catalog

You create an 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 with 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 with Flashback.

You use FLASHBACK DATABASE to rewind the database to an SCN in 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.

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-12
1       582       TRGT      1224038686 CURRENT    59727        10-JUL-12

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;

====

Upgrading the Recovery Catalog

This section explains what a recovery catalog upgrade is and when you must do it.
About Recovery Catalog Upgrades

If you are upgrading to Oracle Database 12c Release 1 (12.1.0.2) or later, then the recovery catalog database must use the Enterprise Edition of Oracle Database.

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.

The Oracle Database 10g Release 1 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 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.
Special Considerations for Upgrading the Recovery Catalog in a Data Guard Environment

Assume that you upgrade the recovery catalog schema to Oracle Database 11g or later in a Data Guard environment. When RMAN connects to a standby database, it automatically registers the new database information and resynchronizes to obtain the file names 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 are not known to the control file. For example, the standby1 control file does not know about all backups made on primary1. The database unique name for these old records is null. You can use CROSSCHECK to fix these records.

Related Topics

About Recovery Catalog Maintenance

Determining the Schema Version of the Recovery Catalog

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 you must 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.
Query the RCVER table to obtain the schema version, as in the following example (sample output included):

SELECT *
FROM rcver;

    VERSION
    ------------
    12.01.00.01

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
------------
10.02.00
11.02.00
12.01.00.01

These rows indicate that the catalog was created with a release 10.2.0 executable, then upgraded to release 11.2.0, and finally upgraded to release 12.1.0.1. The current version of the catalog schema is 12.1.0.1.

Using the UPGRADE CATALOG Command

This scenario assumes that you are upgrading a recovery catalog schema to the current version.

Note:Starting with Oracle Database 12c Release 1 (12.1.0.2), the recovery catalog database must use the Enterprise Edition of Oracle Database.

To upgrade the recovery catalog:

Enable Oracle Partitioning for the recovery catalog database.

If the recovery catalog database uses the Standard Edition, then use one of the following techniques:

Migrate the recovery catalog database from Standard Edition to Enterprise Edition.

Move the recovery catalog into an Oracle Enterprise Edition database and then use the IMPORT CATALOG command to import the recovery catalog into this database.

Use SQL*Plus to connect to the recovery catalog database as the SYS user with the SYSDBA privilege.

Run the dbmsrmansys.sql script to grant additional privileges that are required for the RECOVERY_CATALOG_OWNER role.

SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql

(Optional) Enable the VPD model for the recovery catalog by running the dbmsrmanvpc.sql script with the –vpd option..

The following command enables the VPD model for the recovery catalog owned by the user rco:

SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;

Exit SQL*Plus.

Start RMAN and connect RMAN to the recovery catalog database.

Run the UPGRADE CATALOG command:

RMAN> UPGRADE CATALOG;

recovery catalog owner is rman
enter UPGRADE CATALOG command again to confirm catalog upgrade

Run the UPDATE CATALOG command again to confirm:

RMAN> UPGRADE CATALOG;

recovery catalog upgraded to version 12.01.00.01
DBMS_RCVMAN package upgraded to version 12.01.00.01
DBMS_RCVCAT package upgraded to version 12.01.00.01

Note:

To bypass this step, add the NOPROMPT option after the UPGRADE CATALOG command in step 8.

====

Dropping a Recovery Catalog

The DROP CATALOG command removes those objects that were created by 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 recovery 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. However, the control file of every target database still retains 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 recovery catalog deletes the recovery catalog record of backups for all target databases registered in the catalog.

To drop a recovery catalog schema:

Start RMAN and connect to a target database and recovery catalog. Connect to the recovery catalog as the owner of the catalog schema to be dropped.

The following example connects to a recovery catalog as user rco:

% rman TARGET / CATALOG rco@catdb

Run the DROP CATALOG command:

DROP CATALOG;

recovery catalog owner is rco
enter DROP CATALOG command again to confirm catalog removal

Note:

To bypass the next confirmation step, add the NOPROMPT option with the DROP CATALOG command in this step.
Run the DROP CATALOG command again to confirm:

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.

===

Importing and Moving a Recovery Catalog

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.

About Recovery Catalog Imports

When using IMPORT CATALOG, the source catalog schema is the catalog schema 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 is not unregistered from the source 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.
About Importing Recovery Catalogs in a Recovery Appliance Environment

In a Recovery Appliance environment, a single, centrally-managed Recovery Appliance catalog residing on the Recovery Appliance is shared by all the protected databases. This catalog must be used by all protected databases that send backups to Recovery Appliance.

When you move protected databases to a data protection strategy that uses Recovery Appliance, you can choose to migrate existing backups and backup metadata to Recovery Appliance. To migrate backup metadata, you must import the RMAN recovery catalog into the Recovery Appliance catalog.

The Recovery Appliance documentation contains an overview of the Recovery Appliance catalog and describes how to migrate backups and backup metadata.

Related Topics

Zero Data Loss Recovery Appliance Administrator's Guide
Zero Data Loss Recovery Appliance Protected Database Configuration Guide

Prerequisites for Importing a Recovery Catalog

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.

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

Related Topics

Determining the Schema Version of the Recovery Catalog
Upgrading the Recovery Catalog

Importing a Recovery Catalog

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 RMAN and connect as CATALOG to the destination recovery catalog schema. For example:

% rman
RMAN> CONNECT CATALOG 111cat@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@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@srcdb DBID=1423241, 1423242;
IMPORT CATALOG 102cat@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 as TARGET and list all backups for this database:

CONNECT TARGET "sbu@prod1 AS SYSBACKUP";
LIST BACKUP;

sbu is a user who is granted the SYSBACKUP privilege in the target database.

Moving a Recovery Catalog

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 contains 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.
Import the source catalog into the catalog created in the preceding step.

Category - RMAN

RMAN Practices - PART 5- Back to Basics

Follow us on: