| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
This chapter describes how to manage an RMAN recovery catalog, which holds RMAN repository data for one or more databases in a separate database schema, in addition to using the control files of the databases.
This chapter contains these topics:
| See Also:
Oracle Database Backup and Recovery Basics to learn how to manage the RMAN control file repository without a recovery catalog |
Creating a recovery catalog is a three-step process: you must configure the database that will contain the recovery catalog, create the recovery catalog owner, and then create the recovery catalog itself.
When you use a recovery catalog, RMAN requires that you maintain a recovery catalog schema. The recovery catalog is stored in the default tablespace of the schema. Note that SYS cannot be the owner of the recovery catalog.
Decide which database you will use to install the recovery catalog schema, and also how you will back up this database. You should not install the catalog in the target database: this tactic defeats the purpose of the catalog. Also, decide whether to operate the catalog database in ARCHIVELOG mode, which is recommended.
You must allocate space to be used by the catalog schema. The size of the recovery catalog schema depends upon the number of databases monitored by the catalog, and the number and size of RMAN scripts stored in the catalog. The schema also grows as the number of archived redo log files and backups for each database grows.
For an example, assume that the trgt database has 100 files, and you back up the database once a day, producing 50 backup sets containing 1 backup piece each. If you assume that each row in the backup piece table uses the maximum amount of space, then one daily backup will consume less than 170 KB in the recovery catalog. So, if you back up once a day for a year, then the total storage in this period is about 62 MB. Assume approximately the same amount for archived logs. Hence, the worst case is about 120 MB for a year for metadata storage.
For a more typical case in which only a portion of the backup piece row space is used, 15 MB for each year is a realistic estimate.
If you plan to register multiple databases in your recovery catalog, remember to add up the space required for each one based on the previous calculation to arrive at a total size for the default tablespace of the recovery catalog schema.
If you are creating your recovery catalog in an already-existing database, add enough room to hold the default tablespace to the recovery catalog schema. If you are creating a new database to hold your recovery catalog, then, in addition to the space for the recovery catalog schema itself, you must allow space for other files in the recovery catalog database:
Most of the space used in the recovery catalog database is devoted to supporting tablespaces, for example, the SYSTEM, temporary, and rollback or undo tablespaces. Table 13-1 describes typical space requirements.
After choosing the recovery catalog database and creating necessary space, you are ready to create the owner of the recovery catalog and grant this user necessary privileges.
Assume the following background information for the instructions in the following sections:
SYS with password oracle has SYSDBA privileges on the recovery catalog database catdb.tools in the recovery catalog database catdb stores the recovery catalog. Note that to use an RMAN reserved word as a tablespace name, you must enclose it in quotes and put it in uppercase. (Refer to Oracle Database Recovery Manager Reference for a list of RMAN reserved words.)temp exists in the recovery catalog database.catalog.sql and catproc.sql have successfully run.To create the recovery catalog schema in the recovery catalog database:
CONNECT SYS/oracle@catdb AS SYSDBA
CREATE USER rman IDENTIFIED BY cat TEMPORARY TABLESPACE temp DEFAULT TABLESPACE tools QUOTA UNLIMITED ON tools;
RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user with all privileges required to maintain and query the recovery catalog.
SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
After creating the catalog owner, create the catalog tables with the RMAN CREATE CATALOG command. The command creates the catalog in the default tablespace of the catalog owner.
To create the recovery catalog:
% rman CATALOG rman/cat@catdb
You can also connect from the RMAN prompt:
% rman RMAN> CONNECT CATALOG rman/cat@catdb
CREATE CATALOG command to create the catalog. The creation of the catalog can take several minutes. If the catalog tablespace is this user's default tablespace, then you can run this command:
CREATE CATALOG;
If you specify the tablespace name in the CREATE CATALOG command, and if the tablespace name is an RMAN reserved word, then it must be uppercase and enclosed in quotes. For example:
CREATE CATALOG TABLESPACE 'CATALOG';
SQL> SELECT TABLE_NAME FROM USER_TABLES;
| See Also:
Oracle Database SQL Reference for the SQL syntax for the |
This section describes how to register, unregister, and reset target database records in the recovery catalog.
The first step in using a recovery catalog with a target database is registering the database in the recovery catalog. Use the following procedure:
catdb as user rman (who owns the catalog schema):
% rman TARGET / CATALOG rman/cat@catdb
RMAN> STARTUP MOUNT;
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 K-bytes 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.
Be careful when creating your prefix for CATALOG START WITH. RMAN scans all paths for all files on disk which begin with your specified prefix. The wrong prefix may include more files than you intend. 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 /disk1/backups is a prefix for the paths for all of these directories. In order to catalog only backups in the /disk1/backups directory, the correct command would be:
RMAN> CATALOG START WITH '/disk1/backups/';
To determine whether log records have aged out of the control file, compare the number of logs on disk with the number of records in V$ARCHIVED_LOG.
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:
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 register a single target databases in multiple recovery catalogs.
See Also:
|
RMAN can unregister a database as well as register it. The UNREGISTER DATABASE command is used to unregister a database from the recover catalog.
Make sure this procedure is what you intend, because if you make a mistake, then you must re-register the database. You will lose any RMAN repository records older than the CONTROLFILE_RECORD_KEEP_TIME setting in the target database control file.
To unregister a database:
% 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. 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 .
LIST BACKUP SUMMARY and LIST COPY SUMMARY.DELETE statements to delete all existing physical backupsets and image copies. 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.
UNREGISTER DATABASE command. For example:
UNREGISTER DATABASE;
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.
In the rare situation in which you wish to restore 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. For example, if you accidentally drop a table immediately after the most recent RESETLOGS, then you may want to recover the database to just before the time of the most recent RESETLOGS and then open it with the RESETLOGS option, thereby creating a new incarnation.
To reset the recovery catalog to an older incarnation:
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 DATABASE TO INCARNATION 2;
SHUTDOWN IMMEDIATE STARTUP NOMOUNT
SET UNTIL command, as in this example:
RUN { SET UNTIL 'SYSDATE-45'; RESTORE CONTROLFILE; # only if current control file is not available }
ALTER DATABASE MOUNT;
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 Recovery Manager Reference for |
Use the prgrmanc.sql script to remove recovery catalog records with status DELETED. In releases prior to Oracle9i, RMAN updated recovery catalog records to DELETED status after deleting the physical files rather than removing the records.
In Oracle9i and later, RMAN always removes catalog records and never updates them to status DELETED. However, 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.
To remove all backup records with status DELETED:
rcat as user rman:
% sqlplus rman/cat@catdb
prgrmanc.sql script, which is stored in an operating system specific location ($ORACLE_HOME/rdbms/admin on UNIX):
SQL> @prgrmanc
The script removes all records with status DELETED from 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 the recovery catalog with information that is missing or changed. When resynchronizing, RMAN does the following:
RMAN performs resynchronizations automatically as needed when you execute certain commands, including BACKUP. You can also manually perform a full resynchronization using the RESYNC CATALOG command.
Table 13-2 describes the types of records that RMAN resynchronizes.
Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed information about new backups, new archived logs, and so forth. However, RMAN 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.
| See Also:
Oracle Database Recovery Manager Reference for more information about the |
RMAN automatically performs full or partial resynchronizations in most situations in which they are needed. Most RMAN commands such as BACKUP, DELETE, and so forth perform 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. Thus, you should not need to manually run RESYNC CATALOG very often.
The following sections describe situations in which a manual resynchronization is required.
If the recovery catalog is unavailable when you issue RMAN commands that cause a partial resynchronization, then open the catalog database later and resynchronize it manually with the RESYNC CATALOG command.
For example, the target database may be in New York while the recovery catalog database is in Japan. You may not want to make daily backups of the target database in CATALOG mode, to avoid depending on the availability of a geographically distant database. In such a case you could connect to the catalog as often as feasible (for example, once each week) and run the RESYNC CATALOG command.
Assume that you do the following:
ARCHIVELOG modeIn this case, you may want to manually 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. The database stores information about log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog.
How frequently you need to resynchronize the recovery catalog depends on the rate at which the database 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; if many records have been inserted or changed, then the resynchronization is more time-consuming.
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 after physical schema change, including:
Use RESYNC CATALOG to force a full resynchronization of the recovery catalog.
STARTUP MOUNT;
RESYNC CATALOG command at the RMAN prompt:
RESYNC CATALOG;
| See Also:
Oracle Database Recovery Manager Reference for |
If you maintain a recovery catalog, then use the RMAN RESYNC CATALOG command often enough to ensure that control file records are propagated to the recovery catalog before they are reused.
Make sure that CONTROLFILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations, or else control file records could be lost. An extra week is a safe margin in most circumstances.
|
Caution: Never set |
| See Also:
Oracle Database Backup and Recovery Basics to learn how to monitor the overwriting of control file records |
Stored scripts offer an alternative to command files for managing frequently used sequences of RMAN commands.
The chief advantage of a stored script over a command file is that a stored script is always available to any RMAN client that can connect to the target database and recovery catalog, whereas command files are only available if the RMAN client has access to the file system on which they are stored.
Stored scripts can be global or local. A local stored script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to that target database. A global stored script can be run against any database registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a target database.
Note that to work with stored scripts, even global ones, you must be connected to both a recovery catalog and a target instance.
Make sure RMAN is connected to the right target database and the recovery catalog. Then run the CREATE SCRIPT command, as shown in this example:
CREATE SCRIPT full_backup { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; }
Examine the output. If no errors are displayed, then the script was successfully created and stored in the recovery catalog.
For a global script, the syntax is similar:
CREATE GLOBAL SCRIPT global_full_backup { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; }
You can also provide a COMMENT with descriptive information:
CREATE GLOBAL SCRIPT global_full_backup COMMENT 'use only with ARCHIVELOG mode databases' { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; }
Finally, you can create a local or global script, reading its contents from a text file:
CREATE SCRIPT full_backup FROM FILE 'my_script_file.txt';
The file must begin with a { character, contain a series of commands valid within a RUN block, and end with a } character. Otherwise, a syntax error is signalled, just as if the commands were entered at the keyboard.
To run a stored script, connect to the target database and recovery catalog, and use EXECUTE SCRIPT. EXECUTE SCRIPT requires a RUN block, as shown:
RUN { EXECUTE SCRIPT full_backup; }
This command invokes a local script if one is with the name specified. If no local script is found, but there is a global script with the name specified, RMAN will execute the global script. You can also use EXECUTE GLOBAL SCRIPT to control which script is invoked if a local and a global script have the same name. Assuming there is no local script called global_full_backup, the following two commands have the same effect:
RUN { EXECUTE GLOBAL SCRIPT global_full_backup; } RUN { EXECUTE SCRIPT global_full_backup; }
Executing a global script only affects the connected target database; to run a global script across multiple databases, you must connect the RMAN client to each one separately and execute the script.
Your script will use the automatic channels configured at the time you execute the script. Use ALLOCATE CHANNEL commands in the script if you need to override the configured channels. Note that, because of the RUN block, if an RMAN command in the script fails, subsequent RMAN commands in the script will not execute.
| See Also:
Oracle Database Recovery Manager Reference for |
The PRINT SCRIPT command displays a stored script or writes it out to a file. With RMAN connected to the target database and recovery catalog, use the PRINT SCRIPT command as shown here:
PRINT SCRIPT full_backup;
To send the contents of a script to a file, use this form of the command:
PRINT SCRIPT full_backup TO FILE 'my_script_file.txt';
For global scripts, the analogous syntax would be:
PRINT GLOBAL SCRIPT global_full_backup;
and
PRINT GLOBAL SCRIPT global_full_backup TO FILE 'my_script_file.txt';
| See Also: Oracle Database Recovery Manager Reference for PRINT SCRIPT command syntax |
Use the LIST SCRIPT NAMES command to display the names of scripts defined in the recovery catalog. This command displays the names of all stored scripts, both global and local, that can be executed for the currently connected target database:
LIST SCRIPT NAMES;
If RMAN is not connected to a target database when the LIST SCRIPT NAMES command is run, then RMAN will respond with an error.
To view only global script names, use this form of the command:
LIST GLOBAL SCRIPT NAMES;
To view the names of all scripts stored in the current recovery catalog, including global scripts and local scripts for all target databases registered in the recovery catalog, use this form of the command:
LIST ALL SCRIPT NAMES;
The output will indicate for each script listed which target database the script is defined for (or whether a script is global).
|
Note:
|
| See Also:
Oracle Database Recovery Manager Reference for |
To update stored scripts, connect to the target database and recovery catalog and use the REPLACE SCRIPT command. If the script does not already exist, then RMAN creates it.
This command updates stored script script full_backup with new contents:
REPLACE SCRIPT full_backup { BACKUP DATABASE PLUS ARCHIVELOG; }
Global scripts can be updated using the REPLACE GLOBAL SCRIPT command when connected to a recovery catalog, as follows:
REPLACE GLOBAL SCRIPT global_full_backup COMMENT 'A script for full backup to be used with any database' { BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG; }
As with CREATE SCRIPT, you can update a local or global stored script from a text file, with this form of the command:
REPLACE GLOBAL SCRIPT global_full_backup FROM FILE 'my_script_file.txt';
| See Also:
Oracle Database Recovery Manager Reference for |
To delete a stored script from the recovery catalog, connect to the catalog and a target database, and use the DELETE SCRIPT command:
DELETE SCRIPT 'full_backup';
To delete a global stored script, use DELETE GLOBAL SCRIPT:
DELETE GLOBAL SCRIPT 'global_full_backup';
If you use DELETE SCRIPT without GLOBAL, and there is no stored script for the target database with the specified name, RMAN will look for a global stored script by the specified name and delete the global script if it exists. So, if you were to enter the command
DELETE SCRIPT 'global_full_backup';
RMAN would look for a script 'global_full_backup' defined for the connected target database, and if it did not find one, it would search the global scripts for a script called 'global_full_backup' and delete that script.
| See Also:
Oracle Database Recovery Manager Reference for |
To run the RMAN client and start a stored script in the recovery catalog on startup, use the SCRIPT argument when starting the RMAN client.
% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb SCRIPT 'full_backup';
You must connect to a recovery catalog (which contains the stored script) and target database (to which the script will apply) when starting the RMAN client.
| See Also:
Oracle Database Recovery Manager Reference for full RMAN client command line syntax |
There are some issues to be aware of about how RMAN resolves script names, especially when a local and global script share the same name.
EXECUTE SCRIPT, DELETE SCRIPT and PRINT SCRIPT commands, if the script name passed as an argument is not the name of a script defined for the connected target instance, RMAN will look for a global script by the same name to execute, delete or print. For example, if the a stored script global_full_backup is in the recovery catalog as a global script, but no local stored script global_full_backup is defined for the target database, the following command will delete the global script:
DELETE SCRIPT global_full_backup;
Consider using some naming convetion to avoid mistakes due to confusion between global stored scripts and local stored scripts.
| See Also:
Oracle Database Recovery Manager Reference for the list of RMAN reserved words. |
Your goal is to ensure that the metadata in the recovery catalog is current. Because the recovery catalog obtains its metadata from the target control file, the currency of the data in the catalog depends on the currency of the data in the control file. You need to make sure that the backup metadata in the control file is recorded in the catalog before it is overwritten with new records.
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum number of days that records are retained in the control file before they are candidates for being overwritten. Hence, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. As described in "Resynchronizing the Recovery Catalog and CONTROLFILE_RECORD_KEEP_TIME", you should perform either of the following actions at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting:
RESYNC CATALOG commandSo, to ensure the currency of the information in the recovery catalog, the frequency of resynchronizations should be related to the value for the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter.
One problem can arise if the control file becomes too large. The size of the target database control file grows depending on the number of:
As explained in Oracle Database Backup and Recovery Basics, if the control file grows so large that it can no longer expand because it has reached either the maximum number of blocks or the maximum number of records, then the database may overwrite the oldest records even if their age is less than the CONTROL_FILE_RECORD_KEEP_TIME setting. In this case, the database writes a message to the alert log. If you discover that this situation occurs frequently, then reducing the value of CONTROL_FILE_RECORD_KEEP_TIME and increase the frequency of resynchronizations.
|
Note: The maximum size of the control file is port-specific. Typically, the maximum size is 20,000 Oracle blocks. Refer to your operating system-specific Oracle documentation for more information. |
See Also:
|
Include the recovery catalog database in your backup and recovery strategy. If you do not back up the recovery catalog and a disk failure occurs that destroys the recovery catalog database, then you may lose the metadata in the catalog.
Here are some general guidelines you should follow when developing a strategy for backing up the recovery catalog.
The recovery catalog database is a database like any other, and is also a key part of your backup and recovery strategy. Protect the recovery catalog as you would protect any other part of your database, by backing it up. The backup strategy for your recovery catalog database should be part of your overall backup and recovery strategy.
Back up the recovery catalog with the same frequency that you back up the target database. For example, if you make a weekly whole database backup of the target database, then back up the recovery catalog immediately after all target database backups, in order to protect the record of the whole database backup. This backup can help you in a disaster recovery scenario. Even if you have to restore the recovery catalog database using a control file autobackup, you can then use the full record of backups in your restored recovery catalog database to restore the target database without using a control file autobackup for the target database.
When backing up the recovery catalog database, you can use RMAN to make the backups. As illustrated in Figure 13-1, you should start RMAN with the NOCATALOG option so that the repository for the recovery catalog is the control file in the catalog database.
Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database:
ARCHIVELOG mode so that you can do point-in-time recovery if needed.REDUNDANCY value greater than 1.BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if available, or just to disk.ON.With this strategy, the control file autobackup feature ensures that the recovery catalog database can always be recovered, so long as the control file autobackup is available.
Exporting the Recovery Catalog Data for Logical Backups
Logical backups of the RMAN recovery catalog created with one of Oracle's export utilities can be a useful supplement for physical backups. In the event of damage to the recovery catalog database, you can quickly reimport the exported recovery catalog data into another database and rebuild the catalog this way.
Text description of the illustration bradv009.gif
| See Also:
"Performing Disaster Recovery" for more information for recovery with a control file autobackup |
Never store a recovery catalog containing the RMAN repository for a database in the same database as the target database or on the same disks as the target database. For example, do not store the catalog for database prod1 in prod1. A recovery catalog for prod1 is only effective if it is separated from the data that it is designed to protect.
If prod1 suffers a total media failure, and if the recovery catalog data for prod1 is also stored in prod1, then you have no catalog to aid in recovery. You will probably have to restore an autobackup of the control file for prod1 and use it to restore and recover the database.
Separating the target and catalog databases is especially important when you back up a recovery catalog database. The following example shows what you should not do. For example, consider the following:
prod1 and catalog database catdb are on different hosts.catdb contains the recovery catalog repository for target database prod1.You decide to use a recovery catalog to back up catdb, but are not sure where to create it. If you create the catalog containing the repository for catdb in database catdb, then if you lose catdb due to a media failure, you will have difficulty restoring catdb and will leave prod1 without a recovery catalog to use in a restore scenario.
Restoring and recovering the recovery catalog is much like restoring and recovering any other database, if you backed it up with RMAN.
You can restore the control file and SPFILE for the recovery catalog database from an autobackup, then restore and perform complete recovery on the rest of the database. The processes required are all described in Oracle Database Backup and Recovery Basics You can also use another recovery catalog to record metadata about backups of this recovery catalog database, if you are in a situation where you are using multiple recovery catalogs.
If the recovery catalog database is lost or damaged, and recovery of the recovery catalog database through the normal Oracle recovery procedures is not possible, then you must re-create the catalog. Examples of this worst-case scenario include:
You have these options for partially re-creating the contents of the missing recovery catalog:
CATALOG START WITH... commands to recatalog backups.RESYNC CATALOG command to extract metadata from a control file and rebuild the recovery catalog. Note that you automatically lose any metadata that was contained in old control file records that aged out of the control file.
Depending on the state of the target control file, you can:
See Also:
|
To move the recovery catalog from one database to another, export the catalog from the old database, and import it into the new one. You can only import the catalog into a supported version of the Oracle database server. In general, you can import the catalog into a database of the same release or later.
Exports can also serve as logical backups of the RMAN recovery catalog. If the recovery catalog database is damaged, you can quickly reimport the exported recovery catalog data into another database and rebuild the catalog.
This section contains the following topics:
You should only import the recover catalog into a schema that does not already contain a recovery catalog schema. In other words, the user who will own the imported recovery catalog schema should not already own a recovery catalog schema. For example, if user rman owns the recovery catalog on database catdb, and you want to export the recovery catalog on catdb and import it into database catdb2, then rman should not already own a recovery catalog on catdb2. You should either create a new recovery catalog owner on catdb2, or drop the current user rman on catdb2 and then re-create the user. You cannot merge a recovery catalog into an existing recovery catalog.
The basic steps for exporting a recovery catalog from a primary database and importing the catalog into a secondary database are as follows:
You should not run the CREATE CATALOG command either before or after the Import of the catalog into the secondary database. By importing the catalog data into the new schema, you effectively create the catalog in the secondary database.
|
Note: You cannot import data exported from two different recovery catalogs to merge them into one catalog. It is not currently possible to merge two or more recovery catalog schemas into one. |
This example uses the Original Export utility described in Oracle Database Utilities to create a logical export of the recovery catalog. Refer to Oracle Database Utilities for concepts and procedures relating to the Data Pump Export utility.
The following procedure creates a logical export of the recovery catalog.
For example, if the owner of the catalog in database catdb is rman, you can issue the following at the UNIX command line to export the catalog to file cat.dmp:
% exp rman/cat@catdb FILE=cat.dmp OWNER=rman
Export terminated successfully without warnings.
This example uses the Original Import utility described in Oracle Database Utilities to create a logical export of the recovery catalog. Refer to Oracle Database Utilities for concepts and procedures relating to the Data Pump Import utility.
To make a logical import of the recovery catalog from the command line:
FROMUSER parameter.TOUSER parameter.For example, assume the following:
prod1 is rman.catdb2 is rman2.cat.dmp.The command is then as follows:
% imp USERID=rman2/cat2@catdb2 FILE=cat.dmp FROMUSER=rman TOUSER=rman2
You may have a production system in which you want to maintain high availability for the catalog database. For example, you may have 100 target databases registered in the recovery catalog. In case the primary catalog database goes down, you can create redundancy by storing a secondary recovery catalog in a separate database, as illustrated in Figure 13-2. You must register the target database in the secondary catalog.
In this availability scenario, the main catalog is synchronized as normal during regular backups, while the secondary catalog is synchronized periodically with the RESYNC CATALOG command. If the primary catalog database goes down or requires routine maintenance, then you can resynchronize the secondary catalog and use it as the new primary catalog during the interim.
Text description of the illustration bradv008.gif
The LIST, REPORT, and SHOW commands should provide you with all the repository information that you require. Nevertheless, you can sometimes also obtain useful information from the recovery catalog views, which are views in the catalog schema prefixed with RC_.
| See Also:
Oracle Database Recovery Manager Reference for reference information about the recovery catalog views |
RMAN obtains backup and recovery metadata from the target database control file and stores it in the catalog tables. The recovery catalog views are derived from these tables. Note that these views are not normalized or optimized for user queries.
In general, the recovery catalog views are not as user-friendly as the RMAN reporting commands. For example, when you start RMAN and connect to a target database, you obtain the information for this target database only when you issue LIST, REPORT, and SHOW commands. If you have 10 different target databases registered in the same recovery catalog, then the catalog views show the information for all incarnations of all databases registered in the catalog. You often have to perform joins among the views to distinguish the specific incarnation of the target database that you are interested in.
Most of the catalog views have a corresponding dynamic performance view (or V$ view) in the database server. For example, RC_BACKUP_PIECE corresponds to V$BACKUP_PIECE. The primary difference between the recovery catalog view and corresponding server view is that each catalog view contains information about all the databases registered in the catalog, whereas the database server view contains information only about itself. The RC_ views and corresponding V$ views use different primary keys to uniquely identify rows.
Most of the catalog views contain the columns DB_KEY and DBINC_KEY. Each target database can be uniquely identified by either the primary key, which is the DB_KEY column value, or the DBID, which is the 32-bit unique database identifier. Each incarnation of each target database is uniquely identified by the DBINC_KEY primary key. When querying data about a specific incarnation of a target database, you should use these columns to specify the database. Then, you can perform joins with most of the other catalog views to obtain the desired information.
An important difference between catalog and V$ views is that a different system of unique identifiers is used for backup and recovery objects. For example, many V$ views such as V$ARCHIVED_LOG use the RECID and STAMP columns to form a concatenated primary key. The corresponding catalog view uses a derived value as its primary keys and stores this value in a single column. For example, the primary key in RC_ARCHIVED_LOG is the AL_KEY column. The AL_KEY column value is the primary key that RMAN displays in the LIST command output.
The DB_KEY value, which is the primary key for a target database, is used only in the recovery catalog. The easiest way is to obtain the DB_KEY is to use the DBID of the target database, which is displayed whenever you connect RMAN to the target database. The DBID, which is a unique system-defined number given to every Oracle database, is what distinguishes one target database from another target database in the RMAN metadata.
Assume that you want to obtain information about one of the target databases registered in the recovery catalog. You can easily determine the DBID from this database either by looking at the output displayed when RMAN connects to the database, querying V$RMAN_OUTPUT, or querying a V$DATABASE view as in the following:
SELECT DBID FROM V$DATABASE; DBID --------- 598368217
You can then obtain the DB_KEY for a target database by running the following query, where dbid_of_target is the DBID that you previously obtained:
SELECT DB_KEY FROM RC_DATABASE WHERE DBID = dbid_of_target;
To obtain information about the current incarnation of a target database, specify the target database DB_KEY value and perform a join with RC_DATABASE_INCARNATION by using a WHERE condition to specify that the CURRENT_INCARNATION column value is set to YES. For example, to obtain information about backup sets in the current incarnation of a target database with the DB_KEY value of 1, you can execute the following script:
SELECT BS_KEY, BACKUP_TYPE, COMPLETION_TIME FROM RC_DATABASE_INCARNATION i, RC_BACKUP_SET b WHERE i.DB_KEY = 1 AND i.DB_KEY = b.DB_KEY AND i.CURRENT_INCARNATION = 'YES';
You should use the DB_NAME column to specify a database only if you do not have more than one database registered in the recovery catalog with the same DB_NAME. RMAN permits you to register more than one database with the same database name, but requires that the DBID values be different. For example, you can have ten databases with the DB_NAME value of prod1, each with a different DBID. Because the DBID is the unique identifier for every database in the metadata, use this value to obtain the DB_KEY and then use DB_KEY to uniquely identify the database.
The schema version of the recovery catalog is stored in the recovery catalog itself. The information is important in case you maintain multiple databases of different versions in your production system, and need to determine whether the catalog schema version is usable with a specific target database version.
| See Also:
Oracle Database Recovery Manager Reference for the complete set of compatibility rules governing the RMAN environment |
To determine the schema version of the recovery catalog:
% sqlplus rman/cat@catdb
RCVER table to obtain the schema version, as in the following example (sample output included):
SELECT * FROM rcver; VERSION ------------ 09.02.00
If the table displays multiple rows, then the highest version in the RCVER table is the current catalog schema version. The table stores only the major version numbers and not the patch numbers. For example, assume that the rcver table displays the following rows:
VERSION ------------ 08.01.07 09.00.01 09.02.00
These rows indicate that the catalog was created with a release 8.1.7 executable, then upgraded to release 9.0.1, and finally upgraded to release 9.2.0. The current version of the catalog schema is 9.2.0.
If you use a version of the recovery catalog that is older than that required by the RMAN client, then you must upgrade it. For example, you must upgrade the catalog if you use a release 8.1 version of the RMAN client with a release 8.0 version of the recovery catalog.
You receive an error when issuing UPGRADE CATALOG if the recovery catalog is already at a version greater than that required by the RMAN client. RMAN permits the UPGRADE CATALOG command to be run if the recovery catalog is current and does not require upgrading, however, so that you can re-create packages at any time if necessary. Check the message log for error messages generated during the upgrade.
To upgrade the recovery catalog:
sqlplus> connect sys/oracle@catdb as sysdba; sqlplus> grant TYPE to rman;
% rman TARGET / CATALOG rman/cat@catdb connected to recovery catalog database PL/SQL package rcat.DBMS_RCVCAT version 08.00.04 in RCVCAT database is too old
UPGRADE CATALOG command:
UPGRADE CATALOG; recovery catalog owner is rman enter UPGRADE CATALOG command again to confirm catalog upgrade
UPDATE CATALOG command again to confirm:
UPGRADE CATALOG; recovery catalog upgraded to version 09.02.00 DBMS_RCVMAN package upgraded to version 09.02.00 DBMS_RCVCAT package upgraded to version 09.02.00
See Also:
|
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 backups of all target databases managed by this catalog may become unusable. (The control file of the target database will still retain a record of recent backups.)
The DROP CATALOG command is not appropriate for unregistering a single database from a recovery catalog that has multiple target databases registered. Dropping the catalog deletes the recovery catalog record of backups for all target databases registered in the catalog.
To drop the recovery catalog schema:
% rman TARGET / CATALOG rman/cat@catdb
DROP CATALOG command twice to confirm:
DROP CATALOG; recovery catalog owner is rman enter DROP CATALOG command again to confirm catalog removal DROP CATALOG;
|
Note: Even after you drop the recovery catalog, the control file still contains records about the backups. To purge RMAN repository records from the control file, re-create the control file. |
| See Also:
Oracle Database Recovery Manager Reference for |
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|