| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
This section describes how to maintain target database records in the recovery catalog. It contains the following sections:
The first step in using a recovery catalog with a target database is registering the database in the recovery catalog. Use the following procedure:
After making sure the recovery catalog database is open, connect RMAN to the target database and recovery catalog database. For example, issue the following to connect to the catalog database catdb as user rman (who owns the catalog schema):
% rman TARGET / CATALOG rman/cat@catdb
If the target database is not mounted, then mount or open it:
RMAN> STARTUP MOUNT;
Register the target database in the connected recovery catalog:
RMAN> REGISTER DATABASE;
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:
RMAN> REPORT SCHEMA; Report of database schema 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
If you have datafile copies, backup pieces or archive logs on disk, you can catalog them in the recovery catalog using the CATALOG command. When using a recovery catalog, cataloging older backups that have aged out of the control file lets RMAN use the older backups during restore operations. For example:
RMAN> CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
You can also catalog multiple backup files in a directory at once, using the CATALOG START WITH command, as shown in this example:
RMAN> CATALOG START WITH '/disk1/backups/';
RMAN lists the files to be added to the RMAN repository and prompts for confirmation before adding the backups.
|
Note: Be careful when creating your prefix forCATALOG START WITH. RMAN scans all paths for all files on disk which begin with the specified prefix. The prefix is not just a directory name. Using the wrong prefix can cause the cataloging of the wrong set of files. For example, a group of directories /disk1/backups , /disk1/backups-year2003, /disk1/backupsets, and /disk1/backupsets/test and so on, all contain backup files. The command
RMAN> CATALOG START WITH '/disk1/backups'; catalogs all files in all of these directories, because RMAN> CATALOG START WITH '/disk1/backups/'; |
In general, only Oracle8 and higher files can be cataloged. Datafile copies from Oracle7 databases can also be cataloged, if they do not require the application of Oracle7 redo before they can be opened. Datafile copies made in the following circumstances satisfy this requirement:
Datafile copies made when the database was shut down consistently. The database must not have been opened again before migration to a higher version of Oracle.
Datafile copies made after a tablespace became offline normal or read-only. The tablespaces must not have been brought online or made read/write again before migration to a higher version of Oracle.
|
See Also:
|
You can register multiple target databases in a single recovery catalog, if they do not have duplicate DBIDs. RMAN uses the DBID to distinguish one database from another.
In general, if you use the DUPLICATE RMAN command or CREATE DATABASE SQL statement, the database created is assigned a unique DBID. If you create a database by some other means, such as a user-managed copy, then the new database may have the same DBID as the one from which it was copied. You will not be able to register both databases in the same recovery catalog until you change the DBID of the copied database using the DBNEWID utility.
Note that you can also register a single target databases in multiple recovery catalogs.
|
See Also:
|
The UNREGISTER DATABASE command is used to unregister a database from the recover catalog.
|
Note: 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 re-registration. Records older than theCONTROLFILE_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. |
To unregister a database:
Start RMAN and connect to the target database. For example, enter:
% rman TARGET / CATALOG rman/cat@catdb connected to target database: RDBMS (DBID=1237603294) connected to recovery catalog database
Make a note of the DBID as displayed by RMAN at startup. If there is more than one database registered in the recovery catalog, you will need the DBID to uniquely identify the database.
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 more than one database has 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 .
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 re-catalog backups not known to the control file if you later decide to re-register the database.
If your intention is to actually delete all backups of the database completely, rather than just removing the database from the recovery catalog and relying on the control file to store the RMAN repository for this database, then run DELETE statements to delete all existing backups. For example:
DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK; DELETE COPY;
RMAN will list the backups that it intends to delete and prompt 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
When you run either the RMAN command or the SQL statement ALTER DATABASE OPEN RESETLOGS, you create a new incarnation of the database. You can access a record of the new incarnation in the V$DATABASE_INCARNATION view of the target database.
If you run the RMAN command or the SQL statement ALTER DATABASE OPEN RESETLOGS, 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.
You may need to change the current incarnation of the database in the recovery catalog for some recovery tasks. The steps for changing the incarnation are described in the following procedure.
To reset the recovery catalog to an older incarnation:
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-02 1 582 TRGT 1224038686 CURRENT 59727 10-JUL-02
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;
|
See Also: Oracle Database Backup and Recovery Reference forRESET DATABASE syntax, Oracle Database Backup and Recovery Reference for LIST syntax |
In Oracle9i and later, RMAN always removes catalog records on deleting files, and never updates them to status DELETED. However, in releases prior to Oracle9i, RMAN updated recovery catalog records to DELETED status after deleting the physical files rather than removing the records. Thus, records with status DELETED can appear in the recovery catalog when you upgrade a recovery catalog created prior to Oracle9i to the current release. For this special case, you can run the prgrmanc.sql script, which is stored in an operating system specific location ($ORACLE_HOME/rdbms/admin on UNIX).
To remove all backup records with status DELETED:
Start a SQL*Plus session and connect to the recovery catalog. This example connects to the database rcat as user rman:
% sqlplus rman/cat@catdb
Run the script prgrmanc.sql script:
SQL> @?/rdbms/admin/prgrmanc.sql
The script removes all records with status DELETED from the recovery catalog.
