Oracle RMAN 11g Backup and Recovery (76 page)

SQL> Create user farouka identified by password

Default tablespace catalog tbs

Quota unlimited on catalog tbs;

SQL> Grant recovery catalog owner to farouka;

Step 2.
Log into RMAN and grant access to the database PROD, as well as the ability to register any new databases.

Rman CATALOG rcat user/rcat password@recover

RMAN> Grant catalog for database PROD to farouka;

RMAN> Grant register database to farouka;

Step 3.
Exit RMAN, log back in as farouka, and create the VPC.

Rman CATALOG farouka/password@recover

RMAN> create virtual catalog;

Step 4.
Log back into the database, and explicitly enable management of 10.2 and earlier database versions.

Sqlplus rcat user/rcat password

SQL> execute rcat user.DBMS RCVCAT.create virtual catalog;

214
Part II: Setup Principles and Practices

Merging Multiple Recovery Catalogs

The other primary headache, once we overcome the inability to adequately share the recovery catalog via virtual private catalogs, is to vanquish catalog sprawl. For whatever reason, sometimes you end up with multiple catalogs, and there has historically been no way to import records from one catalog to the next in a way that didn’t make matters worse.

In 11
g,
RMAN introduced a cleaner merge experience through the use of the new
import
catalog
command. You can utilize this functionality to import one catalog into another. This import can include all databases in the source catalog, or only a subset that you specify at the time of import. This functionality provides the mechanism of sorting through the records and ensuring the correct records are brought in without creating dependency issues or duplicate rows.

The
import
command in RMAN can merge two catalogs; it cannot be used as an upgrade mechanism. Before you can import a lower version of the catalog into a newer version, you will have to use the
upgrade
command first against the source catalog, and then import it. While we are on the matter of versions, it should be noted that the source catalog, destination catalog, and RMAN executable version must all be the same version for the import to work.

The
import
command can also be used to move an exiting catalog to a new database or to a new schema. In such a case, you would create the new catalog in the new location, then use that new catalog as the destination catalog in an import operation.

RMAN Workshop:
Merge Two Recovery Catalogs

Workshop Notes

In this workshop, we will import a subset of databases from the catalog RCAT1 into the destination catalog RCAT2.

Step 1.
Connect to the destination catalog in RMAN.

Rman catalog rcvcat user/password@RCAT2

Step 2.
Run the
import
command by specifying a connect string to the source catalog.

RMAN> import catalog rcvcat user@RCAT1 DB NAME TEST, DEV, PROD;

Step 3.
Confirm that the metadata for the databases was imported.

RMAN> CONNECT TARGET SYS/PASSWORD@TEST

RMAN>list backup of database;

Recovery Catalog Maintenance

Use of the recovery catalog involves some additional maintenance activities, which include upgrading the catalog during a database upgrade or migration, manually resetting the database incarnation, and resynchronizing the recovery catalog after certain database operations. This section describes those activities, as well as other maintenance considerations, including removing a database from the recovery catalog and using the Oracle EXP/IMP utilities to back up the recovery catalog. Finally, this section reviews the different recovery catalog views and what they are used for.

Chapter 10: Using the Recovery Catalog
215

Unregistering a Database in RMAN

Prior to Oracle Database 10
g,
unregistering a database from the recovery catalog was a manual process. Now, Oracle makes removing a database from the recovery catalog as easy as issuing the command
unregister database
. Here is an example:

RMAN> Unregister database mydb;

Note that the backup files for this database are not deleted by this command; only the recovery catalog references to those backup files are deleted. Also note that you only need to be connected to the recovery catalog to issue this command.

Database Migration/Upgrade Issues

As you upgrade your Oracle databases, you need to upgrade your recovery catalog as well. As you saw in Chapter 9, some strict rules apply with regard to the version of the database you are using, the version of RMAN, and the version of the recovery catalog.

You can determine what version your recovery catalog is by querying the VERSION column of the RCVER view in the recovery catalog–owning schema:

% sqlplus rman/rman @catdb

SQL > SELECT * FROM rcver;

VERSION

------------

11.01.00

If the table displays multiple rows, then the highest version in the RCVER table is the current catalog schema version. For example, assume that the RCVER table displays the following rows: VERSION

------------

08.01.07

09.02.00

10.02.00

As long as the version of the recovery catalog is at the same level or higher than your database, you will be in good shape. Thus, if you are storing multiple databases in the same recovery catalog, it’s okay to upgrade the catalog to a higher version, even if only one of the databases stored in the recovery catalog is being upgraded.

To upgrade your recovery catalog, simply issue the command
upgrade catalog
from RMAN.

RMAN will prompt you to enter the
upgrade catalog
command again. RMAN will then upgrade the recovery catalog for you.

Manually Resetting the Database Incarnation (reset catalog)

As we have already covered in earlier chapters, each time the
resetlogs
parameter is used when you open an Oracle database, a new incarnation of the database is created. If this is done during an RMAN operation, then the recovery catalog will be correctly updated. However, if you manually issue a
resetlogs
command (through SQL*Plus, for example), you need to reset the database incarnation in the recovery catalog. This is done with the
reset database
command: reset database to incarnation 5;

216
Part II: Setup Principles and Practices

Manually Resynchronizing the Recovery Catalog

(resync catalog)

When RMAN uses a recovery catalog, it uses a resynchronization process to ensure that the recovery catalog is consistent with the target database control file. Generally, Oracle performs database resynchronization itself after RMAN operations such as backups and recoveries, so you really don’t need to resync the recovery catalog often. One example of the need to resync the recovery catalog is if you are running backups sometimes with and sometimes without a recovery catalog. To manually get Oracle to resync the recovery catalog, use the
resync catalog
command: resync catalog;

When Oracle synchronizes the recovery catalog, it first creates a snapshot control file and compares it with the recovery catalog. Once that comparison is complete, Oracle will update the recovery catalog so it is in sync with the database control file.

Purging Recovery Catalog Records

You might have noticed that very few records get removed from the recovery catalog. Unmaintained, old backups will sit forever in the recovery catalog with a DELETED status flag associated with them.

We have seen this cause significant delays in processing a backup operation, often putting the backup window in jeopardy and leading to high-pressure late-night calls to Oracle Support.

So, how do you fix this problem? Oracle provides the solution with the $ORACLE_HOME/

rdbms/admin/prgrmanc.sql script, which will remove all records in your recovery catalog with a DELETED status. We recommend that you run this script periodically to control the size of your recovery catalog.

If you want to remove old incarnation records from the recovery catalog, then you will want to remove these incarnations from the DBINC table. Use the RC_DATABASE_INCARNATION