This bulletin describes how to manage the RMAN information repository. It assumes that you are using a recovery catalog. If you use a control file as the exclusive repository for RMAN metadata, then most RMAN maintenance commands continue to work. Topics:
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:
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.
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