When you use a recovery catalog, it’s possible to create the recovery catalog user in the same database, on the same server, as your target database. However, that approach isn’t recommended because you don’t want the availability of your target database or of the server on which the target database resides to affect the recovery catalog. Therefore, you should create the recovery catalog database on a server different from that of your target database.
Creating a Recovery Catalog
When I use a recovery catalog, I prefer to have a dedicated Oracle database that is used only for the recovery catalog. This ensures that the recovery catalog isn’t affected by any maintenance or downtime required by another application (and vice versa).
Listed next are the steps for creating a recovery catalog:
- Create a database on a server different from that of your target database, to be used for the recovery catalog. Make sure the database is adequately sized. I’ve found that Oracle’s recommended sizes are usually much too small. Here are some adequate recommendations:
SYSTEM tablespace: 500MB
SYSAUX tablespace: 500MB
TEMP tablespace: 500MB
UNDO tablespace: 500MB
Online redo logs: 25MB each; three groups, multiplexed with two members per group
RECCAT tablespace: 500MB
- Create a tablespace to be used by the recovery catalog user. I recommend giving the tablespace a name such as RECCAT so that it’s readily identifiable as the tablespace that contains the recovery catalog metadata:
CREATE TABLESPACE reccat
DATAFILE '/u01/dbfile/O12C/reccat01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128k
SEGMENT SPACE MANAGEMENT AUTO; - Create a user that will own the tables and other objects used to store the target database metadata. I recommend giving the recovery catalog user a name such as RCAT so that it’s readily identifiable as the user that owns the recovery catalog objects. Also, grant the RECOVERY_CATALOG_OWNER role to the RCAT user as well as CREATE SESSION:
CREATE USER rcat IDENTIFIED BY foo
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE reccat
QUOTA UNLIMITED ON reccat;
--
GRANT RECOVERY_CATALOG_OWNER TO rcat;
GRANT CREATE SESSION TO rcat; - Connect through RMAN as RCAT, and create the recovery catalog objects:
$ rman catalog rcat/foo - Now, run the CREATE CATALOG command:
RMAN> create catalog;
RMAN> exit; - This command may take a few minutes to run. When it’s finished, you can verify that the tables were created with the following query:
$ sqlplus rcat/foo
SQL> select table_name from user_tables; - Here is a small sample of the output:
TABLE_NAME
------------------------------
DB
NODE
CONF
DBINC
Registering a Target Database
Now, you can register a target database with the recovery catalog. Log in to the target database server. Ensure that you can establish Oracle Net connectivity to the recovery catalog database. For instance, one approach is to populate the TNS_ADMIN/tnsnames.ora file with an entry that points to the remote database. On the target database server, register the recovery catalog, as follows:
$ rman target / catalog rcat/foo@rcatWhen you connect, you should see verification that you’re connecting to both the target and the recovery catalog:
connected to target database: O12C (DBID=3423216220)
connected to recovery catalog database
Next, run the REGISTER DATABASE command:
RMAN> register database;Now, you can run backup operations and have the metadata about the backup tasks written to both the control file and the recovery catalog. Make sure you connect to the recovery catalog, along with the target database, each time you run RMAN commands:
$ rman target / catalog rcat/foo@rcat
RMAN> backup database;
Backing Up the Recovery Catalog
Make certain you include a strategy for backing up and recovering the recovery catalog database. For the most protection, be sure the recovery catalog database is in archivelog mode, and use RMAN to back up the database.
You can also use a tool such as Data Pump to take a snapshot of the database. The downside to using Data Pump is that you can potentially lose some information in the recovery catalog that was created after the Data Pump export.
Keep in mind that if you experience a complete failure on your recovery catalog database server, you can still use RMAN to back up your target databases; you just can’t connect to the recovery catalog. Therefore, any scripts that instruct RMAN to connect to the target and the recovery catalog must be modified.
Also, if you completely lose a recovery catalog and don’t have a backup, one option is to re-create it from scratch. As soon as you re-create it, you reregister the target databases with the recovery catalog. You lose any long-term historical recovery catalog metadata.
Synchronizing the Recovery Catalog
You may have an issue with the network that renders the recovery catalog inaccessible. In the meantime, you connect to your target database and perform backup operations. Sometime later, the network issues are resolved, and you can again connect to the recovery catalog.
In this situation, you need to resynchronize the recovery catalog with the target database so that the recovery catalog is aware of any backup operations that aren’t stored in it. Run the following command to ensure that the recovery catalog has the most recent backup information:
$ rman target / catalog rcat/foo@rcat
RMAN> resync catalog;
Keep in mind that you have to resynchronize the catalog only if, for some reason, you’re performing backup operations without connecting to the catalog. Under normal conditions, you don’t have to run the RESYNC command.
Recovery Catalog Versions
I recommend that you create a recovery catalog for each version of the target databases that you’re backing up. Doing so will save you some headaches with compatibility issues and upgrades. I’ve found it easier to use a recovery catalog when the database version of the rman client is the same version used when creating the catalog.
Yes, having multiple versions of the recovery catalog can cause some confusion. However, if you’re in an environment in which you have several different versions of the Oracle database, then multiple recovery catalogs may be more convenient.
Dropping a Recovery Catalog
If you determine that you’re not using a recovery catalog and that you no longer need the data, you can drop it. To do so, connect to the recovery catalog database as the catalog owner, and issue the DROP CATALOG command:
$ rman catalog rcat/foo
RMAN> drop catalog;
You’re prompted as follows:
recovery catalog owner is RCAT
enter DROP CATALOG command again to confirm catalog removal
If you enter the DROP CATALOG command again, all the objects in the recovery catalog are removed from the recovery catalog database.
The other way to drop a catalog is to drop the owner. To do so, connect to the recovery catalog as a user with DBA privileges, and issue the DROP USER statement:
$ sqlplus system/manager
SQL> drop user rcat cascade;
SQL*Plus doesn’t prompt you twice; it does as you instructed and drops the user and its objects. Again, the only reason to do this is when you’re certain you don’t need the recovery catalog or its data any longer. Use caution when dropping a user or the recovery catalog: I recommend that you take a Data Pump export of the recovery catalog owner before dropping it.
