Managing RMAN Repository

1. Registering a Database with the Recovery Catalog
2. Unregistering a Database from the Recovery Catalog
3. Resetting the Recovery Catalog
4. Changing the Availability of a Backup or File Copy
5. Crosschecking the RMAN Repository
6. Deleting Backups and Copies and Updating Their Status in the RMAN Repository
7. Validating the Restore of Backups and Copies
8. Resynchronizing the Recovery Catalog
9. Managing Records in the Control File
10. Cataloging Operating System Backups
11. Backing Up and Recovering the Recovery Catalog
12. Drop the Recovery Catalog
 

1. Registering a Database with the Recovery Catalog
Before using RMAN with a target database, register the target database in the recovery catalog. If you do not, RMAN cannot use the recovery catalog to store information about the target database. RMAN obtains all information it needs to register the target database from the database itself. You can register more than one target database in the same recovery catalog, but you can register a database only once in the same catalog.You need connect to the target database and catalog database in the RMAN session before you launch register database command. The target database must be in mount or open state. For example:
man rcvcat rman/rman target sys/change_on_install@target
register database;
 

2. Unregistering a Database from the Recovery Catalog
Make sure this procedure is what you intend, because afterwards RMAN can longer recover all the backups for the unregistered database.

To unregister a database:
2.1 Start RMAN and connect to your target database. Note down the DBID value that is displayed when you use RMAN to connect to your target database. For example, enter:
rman target sys/change_on_install@target nocatalog

2.2 List the copies and backup sets recorded in the control. For example, enter:
list backup of database;

List of Backup Sets
Key     Recid      Stamp      LV Set Stamp  Set Count  Completion Time
------- ---------- ---------- -- ---------- ---------- ----------------------
88      5          429706461  0  429706444  5          14-MAY-01

    List of Backup Pieces
    Key     Pc# Cp# Status      Completion Time        Piece Name
    ------- --- --- ----------- ---------------------- ------------------------
    89      1   1   AVAILABLE   14-MAY-01              /backup/RMAN-DIEGO/archRMAN_DIEGO_5

    List of Datafiles Included
    File Name                                  LV Type Ckp SCN    Ckp Time
    ---- ------------------------------------- -- ---- ---------- -------------
    1    /u01/oradata/DIEGO/system01.dbf       0  Full 19709105   14-MAY-01
    2    /u02/oradata/DIEGO/rbs01.dbf          0  Full 19709105   14-MAY-01
    3    /u03/oradata/DIEGO/temp01.dbf         0  Full 19709105   14-MAY-01
    4    /u01/oradata/DIEGO/users01.dbf        0  Full 19709105   14-MAY-01
    5    /u02/oradata/DIEGO/radar01.dbf        0  Full 19709105   14-MAY-01

2.3 Issue change ... delete statements to delete all backups from the operating system. For example, enter:
allocate channel for maintenance type disk;
change backupset 88 delete;

2.4 Execute another list command to confirm that RMAN removed all backups:
list backup;

2.5 Use SQL*Plus to connect to your recovery catalog database and execute the following query in the recovery catalog to find the correct row of the DB table, setting DB_ID equal to the value you obtained from step 1. For example, enter:
SQL SELECT db_key, db_id FROM db WHERE db_id = 429706461;

This query should return exactly one row.
   DB_KEY     DB_ID
--------- ---------
       38 4.283E+09

While still connected to the recovery catalog, enter the following, where DB_KEY and DB_ID are the corresponding columns from the row you got from the query in step 5:
SQL EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id)

For example, enter:
SQL EXECUTE dbms_rcvcat.unregisterdatabase(1 , 429706461)

Note:
Above procedure is valid for all 8i releases, however, 8.1.7 introduced a new command to simplify purging backup sets. For example, enter:
DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
 

3. Resetting the Recovery Catalog
Before you can use RMAN again with a target database that you have opened with the RESETLOGS option, notify RMAN that you have reset the database incarnation. The reset database command directs RMAN to create a new database incarnation record in the recovery catalog. This new incarnation record indicates the current incarnation. RMAN associates all subsequent backups and log archiving done by the target database with the new database incarnation.
If you issue the ALTER DATABASE OPEN RESETLOGS statement but do not reset the database, then RMAN cannot access the recovery catalog because it cannot distinguish between a RESETLOGS command and an accidental restore of an old control file. By resetting the database, you inform RMAN that the database has been opened with the RESETLOGS option. The RESETLOGS statement cycles the log sequence numbers, hence, we would not be able to distinguish archive log files without the concept of incarnation.
In the rare situation in which you wish to undo the effects of opening with the RESETLOGS option by restoring backups of a prior incarnation of the database, use the reset database to incarnation key command to change the current incarnation to an older incarnation.

To reset the recovery catalog to an older incarnation:
3.1 Specify the primary key of the desired database incarnation. Obtain the incarnation key value by issuing a list command:
list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            CUR Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
38      39      DIEGO    4283267716       YES 19688901   10-MAY-01
1       582     PROD1    1224038686       YES 59727      10-JAN-01

3.2 Reset the database to the old incarnation. For example, enter:
reset database to incarnation 582;

3.3 After resetting the database, issue restore and recover commands to restore and recover the database files from the prior incarnation, then open the database with the RESETLOGS option. You need start from restoring a previous incarnation control file when the database is in nomount state. When the database is reset to the previous incarnation, the catalog will automatically picks up a right control file. After restoring the control file, the database must be mounted for datafiles restore.
 

4. Changing the Availability of a Backup , File Copy, Archiveredo Log
The unavailable option provides for cases when a backup or copy cannot be found or has migrated offsite. A file that is marked UNAVAILABLE is not used in a restore or recover command. If the file is later found or returns to the main site, then you can mark it available again by using the available operand. Note that you do not need to allocate a channel of type maintenance for this operation.
Note: You must use a recovery catalog when executing change ... unavailable and change ... available.

To mark a backup piece, copy, or archive redo log as available or unavailable:
4.1 Issue a change ... unavailable command to mark a backup or copy as UNAVAILABLE. For example, enter:
change datafilecopy '/oracle/backup/cf_c.f' unavailable;
change backupset 12 unavailable;
change archivelog '/u01/oradata/V816//arch/_410.arc' unavailable

4.2 If a previously unavailable file is reinstated, issue change ... available to change its status back to AVAILABLE.
change datafilecopy '/oracle/backup/cf_c.f' available;
change backupset 12 available;
change archivelog '/u01/oradata/V816/arch/_410.arc' available

Note:
The common mistake is migrating or removing archived redo log files without using RMAN which rises error RMAN-6089 during the backup or restore operation. It may be not feasible to make archived redo logs unavailable with above approach after massive file deletion. To notify the recovery catalog about missing archived redo logs, a change archivelog all validate command will be more suitable.
change archivelog all validate;
 

5. Crosschecking the RMAN Repository (valid for 8i releases)
Because backups and copies can disappear from disk or tape or become corrupted, the RMAN metadata repository can contain outdated information. To ensure that data about backup sets and image copies in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog, perform a crosscheck.
Use either the change ... crosscheck or crosscheck backup command to check the specified files. Note that these commands do not delete operating system files or remove repository records; you must use separate commands for those operations.

Crosschecking Backups
Use the crosscheck feature to check the status of a backup on disk or tape. If the backup is on disk, the change backupset ... crosscheck and crosscheck backup commands determine whether the header of the backup piece is valid; if on tape, the commands simply check that the backups exist.
If a backup piece is unreadable or absent, then RMAN marks the backup piece EXPIRED in the output of the list command and the recovery catalog views. If it was marked EXPIRED but is now available, RMAN marks the backup piece as AVAILABLE in the output of the list command and the recovery catalog views.

Use change backupset ... crosscheck when you want to provide a list of backup sets or pieces to check; use crosscheck backup when you wish to restrict the crosscheck to a specified device type, object type, or date range and let RMAN generate the list of backup sets or pieces.

Note:
The change command operates only on files that are recorded in the recovery catalog or the control file. The same is true for other commands except catalog and resync from controlfilecopy. The change ... croscheck command needs catalog for the backupset and backuppiece options.

To provide a list of backups for a crosscheck:
5.1 Allocate a channel of type maintenance:
allocate channel for maintenance type 'sbt_tape';

5.2 Identify the desired backup piece, backup set, or proxy copy that you want to check by issuing a list command:
list backup;

5.3 Check whether the specified backup sets exist. This example checks whether backup sets with the primary keys of 1338, 1339, and 1340 still exist:
change backupset 1338, 1339, 1340 crosscheck;
RMAN-03022: compiling command: change
RMAN-08074: crosschecked backup piece: found to be 'EXPIRED'
RMAN-08517: backup piece handle=/oracle/dbs/2eafnuj3_1_1 recid=77
stamp=352057957
RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE'
RMAN-08517: backup piece handle=/oracle/dbs/2dafnuj2_1_1 recid=78
stamp=352057957
RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE'
RMAN-08517: backup piece handle=/oracle/dbs/2fafnuj3_1_1 recid=79
stamp=352057960

If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.

5.4 Release the allocated maintenance channel:
release channel;

To let RMAN generate the list of backups for a crosscheck:
5.1 Allocate a channel of type maintenance:
allocate channel for maintenance type 'sbt_tape';

5.2 Check for the backups of the specified database, tablespace, datafile, control file, or archived redo log. Limit the crosscheck according to the time sequence.
For example, check all backups of datafile tbs_8.f over the last six months:
crosscheck backup of datafile "/oracle/dbs/tbs_8.f" completed after 'SYSDATE-180';
If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.

5.3 Release the allocated maintenance channel:
release channel;

Crosschecking Image Copies
Use the change ... crosscheck command to determine whether image copies of datafiles, control files, or archived redo logs on disk or tape are valid. If RMAN is unable to find the specified image copy or archived redo log, it updates its status to DELETED.
RMAN considers archived redo logs as image copies. If for some reason one or more archived redo logs becomes unavailable, issue a change archivelog all crosscheck command so that RMAN updates the STATUS column of the absent logs to DELETED. You do not need to use a recovery catalog to execute this command.

To crosscheck image copies:
5.1 Connect to RMAN either with or without a recovery catalog. For example, enter one of the following:
rman target / nocatalog
rman target / catalog rman/rman@catalogt

5.2 Identify the image copy that you want to check by issuing a list command. This example lists all recorded image copies and archived redo logs:
list copy of database archivelog all;

List of Datafile Copies
Key File S Completion time Ckp SCN Ckp time Name
------- ---- - --------------- ---------- ---------- ------
1262 1 A 18-AUG-98 219859 14-AUG-98 /oracle/dbs/copy/tbs_01.f

List of Archived Log Copies
Key Thrd Seq S Completion time Name
------- ---- ------- - --------------- ------------------------------------
789 1 1 A 14-JUL-98 /oracle/work/arc_dest/arcr_1_1.arc
790 1 2 A 11-AUG-98 /oracle/work/arc_dest/arcr_1_2.arc
791 1 3 A 12-AUG-98 /oracle/work/arc_dest/arcr_1_3.arc

5.3 Use change ... crosscheck to check whether the specified copy exists. If not, RMAN updates its status to DELETED. This example checks whether the datafile copy with primary key 1262 exists:
change datafilecopy 1262 crosscheck;

RMAN-03022: compiling command: change
RMAN-06154: validation succeeded for datafile copy
RMAN-08513: datafile copy filename=/oracle/dbs/copy/tbs_01.f recid=1
stamp=351194732

If RMAN is unable to validate the copy, you will see:
RMAN-06153: validation failed for datafile copy

To update the RMAN repository after archived redo logs have been removed:
5.1 Connect to RMAN with or without a catalog. For example, enter either:
rman target / nocatalog
rman target / catalog rman/rman@rcat

5.2 Issue a change ... crosscheck command to update the repository records for the absent archived redo logs. This example crosschecks all archived redo logs:
change archivelog all crosscheck;
 

6. Deleting Backups and Copies and Updating Their Status in the RMAN Repository
You can use RMAN to delete backups, copies, and archived logs and update their status in the repository to DELETED status or remove the records entirely.
Note:
Note that backup and copies with DELETED status do not appear in the list command output: query the recovery catalog views instead.

To update the catalog record for a backup or copy deleted with an operating system utility:
6.1 Allocate a channel of type maintenance (valid in 8.i releases):
allocate channel for maintenance type disk;

6.2 Issue a change ... uncatalog command for the backups or copies that you deleted from the operating system using operating system commands. This example removes references to copies of the control file and datafile 1 from he repository:
change controlfilecopy '/oracle/backup/cf_c.f' uncatalog;
change datafilecopy '/oracle/backup/df_1_c.f' uncatalog;

6.3 Release the allocated channel:
release channel;

To physically delete backups and image copies and remove their repository records:
This procedure does not require the use of a recovery catalog.
The behavior of change ... delete differs depending on what you are deleting. If you are deleting backups and image copies (but not archived logs), then change ... delete deletes the physical files and removes the records for these files from the repository.
If you are deleting archived redo logs and you use a catalog, then the outcome of the following procedure depends on the compatibility setting of the recovery
catalog:

 
6.1 Check for the expired backup sets and copies. Use the list output to obtain their primary keys.
list backup of database archivelog all; # lists backups of database files and logs
list copy;

6.2 Allocate a channel of type delete:
allocate channel for delete type disk;

6.3 Issue a change ... delete command to eliminate the specified physical files and the repository records. If you are deleting archived logs, then depending on the compatibility setting of the recovery catalog, this command either changes the recovery catalog record to status DELETED or removes the record altogether.
This example deletes the backup piece with key 101, the control file copy with key 63, and all archived logs through log sequence 300 from disk:
change backuppiece 101 delete;
change controlfilecopy 63 delete;
change archivelog until logseq = 300 delete;

6.4 Release the allocated maintenance channel:
release channel;

To physically delete obsolete backups and copies and remove their repository records:
This procedure does not require the use of a recovery catalog.

6.1 Change into the $ORACLE_HOME/rdbms/demo directory and edit the following shell script as needed:
vi rman1.sh

6.2.Execute the script:
rman1.sh

6.3 If desired, check deleted.log to see the command output.

To remove EXPIRED backup records in the catalog (and delete any existing expired backups in 8i release):
This procedure requires the use of a recovery catalog.

6.1 Optionally, perform a crosscheck operation to mark all inaccessible or absent backups as EXPIRED. The delete expired backup command only operates on expired backups.

6.2 Allocate a channel of type delete:
allocate channel for delete type disk;

6.3 Issue a delete expired backup command to check for backups marked EXPIRED and remove their catalog records. This example updates all backups registered in the recovery catalog that are expired:
delete expired backup;
If the expired pieces exist, RMAN removes them from the operating system.

6.4 Release the allocated channel:
release channel;

To remove image copy and archived redo log records from the recovery catalog (without physically deleting the files):
This procedure requires the use of a recovery catalog.

6.1 Check for the expired datafile copies, control file copies, or archived redo logs. Use the list output to obtain their primary keys. For example, enter:
list copy;

6.2 Issue a change ... uncatalog command to remove references to the specified copies from the recovery catalog. Note that this command does not remove records of backup sets and backup pieces.
This example removes records of copies of the control file and of the datafile copy with the primary key 4833:
change controlfilecopy '/oracle/backup/cf_c.f' uncatalog;
change datafilecopy 4833 uncatalog;
Note that change ... uncatalog does not remove files from the operating system; it only removes recovery catalog records.

6.3 View the relevant recovery catalog view, for example, RC_DATAFILE_COPY or RC_CONTROLFILE_COPY, to confirm that a given record was emoved.
For example, this query confirms that the record of copy 4833 was removed:
SQL SELECT cdf_key, status FROM rc_datafile_copy WHERE cdf_key = 4833;
CDF_KEY S
---------- -
0 rows selected.

To remove all copy and backup records from the recovery catalog:
You can remove all recovery catalog records of deleted backups and copies at once using the $ORACLE_HOME/rdbms/admin/prgrmanc.sql script (available in 8.i release). Only perform this operation if you do not want a historical record of what you have backed up.

6.1 Allocate a channel of type maintenance:
allocate channel for maintenance type 'sbt_tape';

6.2 Issue change ... delete commands to update the desired records to DELETED status and remove the file from the operating system or media manager. Issue list
commands or query the recovery catalog views to obtain primary keys for archived redo logs, backup sets, control file copies, or datafile copies.
change backupset 100, 101, 102, 103 delete;

6.3 Release the allocated maintenance channel:
release channel;

6.4 Start a SQL*Plus session and connect to the recovery catalog. This example connects to the database CATALOG as user RMAN:
% sqlplus rman/rman@catalog

6.5 Run the script prgrmanc.sql script, which is stored in the $ORACLE_HOME/rdbms/admin directory:
SQL @prgrmanc.sql
RMAN removes all records with status DELETED from the recovery catalog.
To remove incarnation records from the recovery catalog:

This procedure is valid for 8.1.6 release and onwards.
6.1 Allocate a channel of type maintenance:
allocate channel for maintenance type 'sbt_tape';

6.2 Issue change ... delete commands to remove unwanted backup pieces, archived redo logs, and image copies. Issue list commands or query the recovery catalog views to obtain primary keys for archived redo logs, backup sets, control file copies, or datafile copies.
change backupset 100, 101, 102, 103 delete;

6.3 Release the allocated maintenance channel:
release channel;

6.4 Start a SQL*Plus session and connect to the recovery catalog. This example connects to database CATALOG as user RMAN:
% sqlplus rman/rman@catalog

6.5 Obtain the DBINC_KEY values for the incarnations whose records you want to delete by querying the RC_DATABASE_INCARNATION recovery catalog view:
SQL SELECT * FROM rc_database_incarnation;

6.6 Execute the following DML statement, where key_value is the value of DBINC_KEY:
SQL DELETE FROM dbinc WHERE dbinc_key=key_value;

RMAN will remove the specified incarnation records from the recovery catalog.
Note:
The allocate channel for maintenance ... syntax is valid for 8i releases. For releases prior 8.1.5, the allocate channel for delete will work with the most of the change ... delete commands.
 
 

7. Validating the Restore of Backups and Copies
A restore validation executes a restore test run without actually restoring the files. Test the restore of the entire database or individual tablespaces, datafiles, or control files. The restore ... validate and validate backupset commands test whether you can restore backups or copies. You should use:
- restore ... validate when you want RMAN to choose which backups or copies should be tested.
- validate backupset when you want to specify which backup sets should be tested.

To let RMAN choose which backup sets or copies to validate:

7.1 If you want to validate the whole database, close it. If you want to validate individual files, then either close the database or take the individual datafiles offline. This example checks the status of the database, aborts the instance, and then mounts it:
SQL SELECT status FROM v$instance;
STATUS
-------
OPEN

SQL STARTUP FORCE MOUNT;

7.2 Start RMAN and connect to the target database and optional recovery catalog database:
% rman target / catalog rman/rman@catalog

7.3 If you do not want to validate the whole database, identify the backup sets and copies that you want to validate by issuing list commands, noting primary keys:
list backupset;
list copy;

7.4 Validate the restore of the backup sets and copies. This example validates the restore of the backup control file, SYSTEM tablespace, and all archived redo logs from disk:
run {
allocate channel ch1 type disk;
allocate channel ch2 type tape;
restore controlfile validate;
restore tablespace 'system' validate;
restore archivelog all validate;
}

7.5 Check the output. If you see an error message stack and then the following, you do not have a backup or copy of one of the files that you are validating:
RMAN-06026: some targets not found - aborting restore

If you see an error message stack and output similar to the following, for example, then there is a problem with the restore of the specified file:
RMAN-03002: failure during compilation of command
RMAN-03013: command type: restore
RMAN-03007: retryable error occurred during execution of command: IRESTORE
RMAN-07004: unhandled exception during command execution on channel c1
RMAN-10035: exception raised in RPC: ORA-19505: failed to identify file
"oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
RMAN-10031: ORA-19624 occurred during call to DBMS_BACKUP_RESTORE.RESTOREBACKUPPIECE

If you do not see an error stack, then RMAN successfully validated the files.

To specify which backup sets to validate:
7.1 Start RMAN and connect to the target database and optional recovery catalog database:
% rman target / catalog rman/rman@catatalog

7.2 Identify the backup sets that you want to validate by issuing list commands:
list backup of database archivelog all;

7.3 Validate the restore of the backup sets. This example validates the restore of the backup control file, SYSTEM tablespace, and all archived redo logs from disk:
run {
allocate channel ch1 type disk;
validate backupset 1121;
}

7.4 Check the output. If you see the RMAN-08024: channel ch1: restore complete message then RMAN successfully validated the restore of the specified backup set.
 

8. Resynchronizing the Recovery Catalog
When RMAN performs a resynchronization, it compares the recovery catalog to either the current control file of the target database or a backup control file and updates it with information that is missing or changed. Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed information, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including those for the database schema.
Note: Although RMAN performs partial resynchronizations when the control file is a backup, it does not perform full resynchronizations.

To ensure a full resynchronization, issue a resync catalog command.
The resynchronization updates records regarding: log history, archived redo logs, backup history, physical schema.
RMAN automatically performs full or partial resynchronizations as needed in certain situations. Execution of the following commands performs a full or partial resynchronization (depending on whether the schema metadata has changed) automatically when the target database control file is mounted and the recovery catalog database is available when the command is executed:
    backup, copy, crosscheck, delete, expired, backupset, duplicate, list, recover, report restore, switch.

Perform manual resynchronizations in the following scenarios.
8.1 Resynchronizing when the Recovery Catalog is Unavailable
If the recovery catalog is unavailable when you issue backup or copy commands, then open the catalog database later and resynchronize it manually using the resync catalog command.

8.2 Resynchronizing when You Run in ARCHIVELOG Mode
If you are running in ARCHIVELOG mode, 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. Instead, Oracle stores information about log switches and archived redo logs in the control file. You must propagate this information periodically into the recovery catalog.
How frequently you resynchronize the recovery catalog depends on the rate at which Oracle 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. Thus, you can perform this operation frequently--for example, hourly--without incurring undue costs.

8.3 Resynchronizing After Physical Database Changes
Resynchronize the recovery catalog after making any change to the physical structure of the target database. As with redo log archive operations, the recovery catalog is not updated automatically when a physical schema change is made.
A physical schema change occurs when you:
- Add or drop a tablespace.
- Add a new datafile to an existing tablespace.
- Add or drop a rollback segment.

When resynchronizing from the current control file, RMAN automatically detects the records in the control file that have been updated and resynchronizes only those records. If the target database is open, then RMAN also updates information about rollback segments in the recovery catalog (this information is used for TSPITR). When resynchronizing from a backup control file, RMAN does not verify that the backup pieces or file copies actually exist. Thus, you may need to use the change ... crosscheck and crosscheck commands to remove records for files that no longer exist.

To force a full resynchronization of the recovery catalog, issue the resync catalog command.
8.1.Open the recovery catalog database (if it is not already open) and mount the Target DB (if is not already mounted)

8.2.Use RMAN to connect to the target and recovery catalog databases.

8.3 Issue the resync catalog command:
resync catalog;
 

9. Managing Records in the Control File
The recovery catalog is dependent on the target database control file for information. Consequently, the currency of the information in the control file determines the effectiveness of the recovery catalog.
The size of the target database's control file grows depending on the number of:
- Backups that you perform.
- Archived redo logs that Oracle generates.
- Days that this information is stored in the control file.
You can use the CONTROL_FILE_RECORD_KEEP_TIME parameter to specify the minimum number of days that Oracle keeps this information in the control file. Entries older than the number of days specified are candidates for overwrites by newer information. The larger the CONTROL_FILE_RECORD_KEEP_TIME setting, the larger the control file.

Note:
At a minimum, resynchronize your recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, because after the number of days specified in this parameter, Oracle overwrites the information in the control file with the most recently created information. If you have not resynchronized the recovery catalog, and Oracle has overwritten the information, then this information cannot be propagated to the recovery catalog.
 
 

10. Cataloging Operating System Backups
You can make RMAN aware of the existence of file copies that are created through means other than RMAN. If you do not make backups or image copies by using RMAN commands, then the recovery catalog has no record of them. You must manually notify RMAN when you make backups with an operating system utility. Use the RMAN catalog command to:

Whenever you make a cold operating system backup, for example, by using the UNIX cp command to copy a datafile, make sure to catalog it. Oracle8i supports the ALTER TABLESPACE ... BEGIN/END BACKUP command, which allows open database operating system backups. Although RMAN does not create such backups, you can add them to the recovery catalog so that RMAN is aware of them.

To catalog an operating system backup:
10.1 Make a backup via an operating system utility. This example backs up a datafile.
% cp $ORACLE_HOME/dbs/sales.f $ORACLE_HOME/backup/sales.bak';

10.2 Use RMAN to connect to the target and recovery catalog databases. For example, enter:
% rman target change_on_install@target rcvcat rman/rman@catalog

10.3 Issue the catalog command. For example, enter:
catalog datafilecopy '$ORACLE_HOME/backup/sales.bak';
 
 

11. Backing Up and Recovering the Recovery Catalog
Include the recovery catalog in your backup and recovery strategy. If you do not back up your recover catalog and a disk crash occurs, you may lose some or all of your data.

Back up the recovery catalog with the same frequency that you back up your target database. For example, if you make a weekly whole database backup of your target database, then back up your recovery catalog immediately after each target database backup. The backed up catalog will have a record of the target backup preceding it, so if you are forced to restore the catalog you will also be able to use it to restore the target database backup.

Use the Appropriate Method for Physical Backups
When backing up the recovery catalog, you have a choice of making operating system or RMAN backups. The advantage of making operating system backups is that you can restore them using operating system methods without relying on RMAN or a recovery catalog.
If you use RMAN to back up the recovery catalog database, consider how you will restore the recovery catalog in case of failure. For example, you can:
Back up the recovery catalog database using RMAN, but start RMAN with the nocatalog option so that the backup repository for the recovery catalog is the control file in the catalog database. Make frequent backups of this control file using SQL. Remember to set the CONTROL_FILE_RECORD_KEEP_TIME
initialization parameter to a value that is high enough to store an adequate amount of historical backup data for the catalog.

Create a second recovery catalog in a separate database. The main catalog is kept synchronized as normal, while the secondary catalog is synchronized manually by periodically issuing the resync catalog command.

Make Logical Backups
Use the Export utility to make convenient backups of your recovery catalog data. An export of the catalog allows the most flexibility when the recovery catalog must be restored. For example, if the owner of the catalog in database PROD1 is RMAN, you can issue the following at the UNIX command line to export the catalog to file cat.dmp:
% exp rman/rman@prod1 file=cat.dmp owner=rman

Then to recover use:
% imp userid=rcat/rcat_pwd@new_cat file=cat.dmp fromuser=rman touser=rcat
 

Drop the Recovery Catalog
If you do not want to maintain a recovery catalog, then you can drop the recovery catalog schema from the tablespace. The drop catalog command deletes all information from the recovery catalog. Hence, if you have no backups of the recovery catalog schema, then all backups of all target databases managed by this catalog become unusable.
The drop catalog command is not appropriate for "unregistering" a single database from a catalog that registers multiple target databases. If you try to delete the information for one target database by dropping the catalog, you delete the information for all target databases.
To drop the recovery catalog schema:
Use RMAN to connect to the target and recovery catalog databases.
% rman target / catalog rman/rman@rcat

Issue the drop catalog command twice to confirm:
RMAN drop catalog