Release 2 (9.2)
Part Number A96566-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Recovery Manager User's Guide Release 2 (9.2) Part Number A96566-01 |
|
This chapter describes how to manage the RMAN repository. Depending on how you implement RMAN, you can store this data either in the recovery catalog or exclusively in the control file. This chapter contains these topics:
This section contains these topics:
| See Also:
"Using Basic RMAN Commands" to learn how to connect to RMAN, and "Choosing an RMAN Authentication Method" to learn about the advantages and disadvantages of maintaining a recovery catalog |
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:
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 more realistic estimate.
After either creating a new catalog database or finding an existing database to host the catalog, allocate disk space for the following:
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 16-1 describes typical space requirements.
|
Caution: Ensure that the recovery catalog and target databases do not reside on the same disk. If they are on the same disk and you lose one database, then you will probably lose the other. |
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 on the recovery catalog database catdb stores the recovery catalog. Note that to use a reserved word as a tablespace name, you must enclose it in quotes and put it in uppercase font.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 privileges to maintain and query the recovery catalog.
SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
SQL> GRANT CONNECT, RESOURCE TO rman;
After creating the catalog owner, create the catalog itself 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. If the catalog tablespace is this user's default tablespace, then you can run this command:
CREATE CATALOG;
Note that the creation of the catalog can take several minutes.
SQL> SELECT TABLE_NAME FROM USER_TABLES;
| See Also:
Oracle9i SQL Reference for the SQL syntax for the |
This section describes how to register, unregister, and reset target database records in the recovery catalog.
This section contains these topics:
Before using RMAN with a recovery catalog, you must register the target database in the recovery catalog. RMAN obtains all information it needs to register the target database from the database itself.
As long as each target database has a distinct DBID, you can register more than one target database in the same recovery catalog. For example, you can register target databases prod1, prod2, and prod3 in catalog schema rman1. Note that you cannot register a specific database multiple times in the same recovery catalog: registration occurs only once. However, you can register a target database in multiple recovery catalog schemas. For example, you can register target database prod1 in catalog schema rman1 and in schema rman2.
Each database registered in a given catalog must have a unique database identifier (DBID), but not necessarily a unique database name. When you copy a database with user-managed methods, the copy database has the same DBID as the original database. You can use the DBNEWID utility to change the DBID and database name of manually copied databases. However, the recommended method is to copy a database with the DUPLICATE command, because RMAN gives it a new DBID.
|
Note: If you use Oracle Enterprise Manager, then you can use also the Maintenance wizard to register the database. |
To register the target database:
catdb as user rman (who owns the catalog schema):
% rman TARGET / CATALOG rman/cat@catdb
STARTUP MOUNT;
The recovery catalog database must be open.
REGISTER DATABASE;
After you run REGISTER DATABASE, RMAN creates rows in the repository that contain information about the target database. Then, RMAN performs a full resynchronization with the catalog in which it transfers all pertinent data about the target database from the control file and saves it in the catalog.
REPORT SCHEMA. This command shows the database structure as it is stored in the repository. For example:
RMAN> REPORT SCHEMA; Report of database schema File K-bytes Tablespace RB segs Datafile Name ---- ---------- -------------------- ------- ------------------- 1 307200 SYSTEM *** /oracle/oradata/trgt/system01.dbf 2 20480 UNDOTBS *** /oracle/oradata/trgt/undotbs01.dbf 3 10240 CWMLITE *** /oracle/oradata/trgt/cwmlite01.dbf 4 10240 DRSYS *** /oracle/oradata/trgt/drsys01.dbf 5 10240 EXAMPLE *** /oracle/oradata/trgt/example01.dbf 6 10240 INDX *** /oracle/oradata/trgt/indx01.dbf 7 10240 TOOLS *** /oracle/oradata/trgt/tools01.dbf 8 10240 USERS *** /oracle/oradata/trgt/users01.dbf
CATALOG command. For example:
CATALOG DATAFILECOPY '/tmp/users01.dbf'; CATALOG ARCHIVELOG '/tmp/archive1_731.dbf', '/tmp/archive1_732.dbf';
In some cases, datafile copies made of an Oracle7 database with operating systems can be cataloged. To be usable, the copies must not require any Oracle7 redo to be recovered, that is, they must be either of the following:
|
Note: 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 |
See Also:
|
Oracle uses an internal, uniquely generated number called the DBID to distinguish one database from another. Oracle generates the DBID at database creation. RMAN uses the DBID to distinguish one database from another. A problem can occur when you create a database by non-RMAN techniques (for example, user-managed backup and restore) instead of with a CREATE DATABASE statement or DUPLICATE command. In such cases, RMAN detects the duplicate database identifiers and the REGISTER DATABASE command fails.
To be able to register a copied database with the same DBID as an already registered database, use the DBNEWID utility to change the DBID of the copy database. You can also use this utility to change the database name. However, the best solution is to avoid the problem altogether by using the DUPLICATE command, which generates a new database identifier automatically.
See Also:
|
RMAN can unregister a database as well as register it. Make sure this procedure is what you intend, because if you make a mistake, then must reregister the database. In this case, you lose any metadata that is 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
LIST BACKUP SUMMARY; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Tag ------- -- -- - ----------- --------------- ------- ------- --- 19 B A A DISK 08-FEB-02 1 1 TAG20020208T155239 20 B F A DISK 08-FEB-02 1 1 TAG20020208T155242 21 B A A DISK 08-FEB-02 1 1 TAG20020208T155331 22 B A A DISK 08-FEB-02 1 1 TAG20020208T155604
DELETE statements to delete all existing physical backups (refer to "Deleting Backups and Copies"). For example:
DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK;
RMAN will list the backups that it intends to delete and prompt for confirmation before deleting them.
DB table, setting DB_ID equal to the value you obtained from step 1. For example, enter:
% sqlplus rman/cat@catdb SQL> SELECT DB_KEY, DB_ID FROM DB WHERE DB_ID = 1237603294;
This query should return exactly one row.
DB_KEY DB_ID ---------- ---------- 1 1237603294 1 row selected.
DB_KEY and DB_ID are the corresponding columns from the row you got from the query in step 4:
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id)
For example, enter:
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(1, 1237603294)
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 see a record of the new incarnation in the V$DATABASE_INCARNATION view of the target database.
If you run the RMAN command (not the SQL statement) ALTER DATABASE OPEN RESETLOGS, then RMAN automatically creates a new database incarnation record in the recovery catalog. RMAN implicitly and automatically issues a RESET DATABASE command, which specifies that this new incarnation of the database is 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 SQL statement (not the RMAN command) ALTER DATABASE OPEN RESETLOGS, then RMAN does not automatically run a RESET DATABASE command. Hence, RMAN cannot access the recovery catalog because it cannot distinguish between a RESETLOGS command and an accidental restore of an old control file. To solve this problem, you must manually run the RESET DATABASE command in RMAN after executing the SQL statement ALTER DATABASE OPEN RESETLOGS. The RESET DATABASE command updates the repository to indicate that the target database has been opened with the RESETLOGS option.
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.
|
Note: If you use Oracle Enterprise Manager, then you can use also the Maintenance wizard to reset the database incarnation. |
To reset the recovery catalog to an older incarnation:
LIST command:
LIST INCARNATION; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- ------- ------ --- ---------- ---------- 1 2 TRGT 1224038686 NO 1 02-JUL-01 1 582 TRGT 1224038686 YES 59727 10-JUL-01
RESET DATABASE TO INCARNATION 2;
SHUTDOWN IMMEDIATE STARTUP NOMOUNT
SET UNTIL command, as in this example:
RUN { SET UNTIL 'SYSDATE-45'; RESTORE CONTROLFILE; }
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:
|
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.
This section contains the following topics:
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, on the other hand, 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. |
When resynchronizing, RMAN does the following:
RMAN performs partial or full resynchronizations automatically as needed when you execute certain commands, including BACKUP and COPY. For this reason, you should not need to run RESYNC CATALOG very often, because the BACKUP and COPY commands automatically resynchronize the catalog for you. However, you may want to run your backups in NOCATALOG mode most of the time, and then connect to the catalog only periodically. To ensure a full resynchronization in this case, run a RESYNC CATALOG command.
|
Note: If you use Oracle Enterprise Manager, then you can use also the Maintenance wizard to perform catalog resynchronizations. |
See Also:
|
Table 16-2 describes the types of records that RMAN resynchronizes.
RMAN automatically performs full or partial resynchronizations as needed in certain situations. Most RMAN commands such as BACKUP, COPY, 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. Perform manual resynchronizations in the following scenarios.
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. In this case, you do not want to make a daily backup of the target database in CATALOG mode because it depends on the availability of a database that is geographically distant. One solution is to connect to the catalog once a 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. 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; 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 when a physical schema change is made.
A physical schema change occurs after:
Issue the RESYNC CATALOG command to force a full resynchronization of the recovery catalog.
To perform a full resynchronization of the recovery catalog:
STARTUP
STARTUP MOUNT;
RESYNC CATALOG command at the RMAN prompt:
RESYNC CATALOG;
| See Also:
Oracle9i Recovery Manager Reference for |
If you maintain a recovery catalog, then use the RMAN RESYNC CATALOG command to resynchronize the catalog before control file records are reused. In this way, RMAN never loses records because they are propagated from the control file to the recovery catalog. Note that RMAN automatically resynchronizes the catalog when making backups and copies.
To ensure that control file records are not overwritten before they are added to the recovery catalog, set the CONTROLFILE_RECORD_KEEP_TIME to a value that is slightly longer (perhaps a week) than the interval between backups or resynchronizations. For example, if you back up the database during the first and third week of every month, and if you run RESYNC CATALOG during the second and fourth week of every month, then consider setting CONTROLFILE_RECORD_KEEP_TIME to 10 or 14.
This section contains these topics:
| See Also:
"Printing Scripts Stored in the Recovery Catalog" to learn how to query RMAN stored scripts |
A stored script is a sequence of RMAN commands stored within the recovery catalog. It provides a common repository of frequently executed RMAN commands.
For example, you can collect the RMAN commands needed to perform nightly backups into a single script called nightly_bkup. Storing the script in the recovery catalog instead of in an operating system text file has the advantage that it is accessible to any DBA that uses RMAN, regardless of which machine RMAN is executed on.
If you have a recovery catalog, then you can use RMAN to do the following:
Note the following important aspects of stored script creation:
Use the CREATE SCRIPT command to create an RMAN script and store it in the recovery catalog.
To create a stored script:
CREATE SCRIPT. For example, this script backs up the database and the archived redo logs:
CREATE SCRIPT b_whole
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
RMAN-08085 message, then the script was successfully created and stored in the recovery catalog:
created script b_whole
Note that this script is associated with the target database that you were connected to when you created the script.
Use the EXECUTE SCRIPT command to run an RMAN script that you have stored in the recovery catalog.
To execute a stored script:
After connecting to the recovery catalog and target database, issue a RUN command to execute the desired script. For example, enter:
RUN { EXECUTE SCRIPT b_whole; }
RMAN inserts the contents of the script between the brackets of RUN. Note that you do not need to run ALLOCATE CHANNEL if you already did so within the script or if you have automatic channels configured.
| See Also:
Oracle9i Recovery Manager Reference for |
Use the REPLACE SCRIPT command to rewrite a catalog script. If the script does not already exist, then RMAN creates it. Note that you cannot use REPLACE SCRIPT to replace a single line of a script: you must rewrite everything.
To replace a stored script:
After connecting RMAN to the recovery catalog, issue a REPLACE SCRIPT command to replace a stored script with another. For example, this command replaces script b_whole with the following:
REPLACE SCRIPT b_whole { BACKUP DATABASE PLUS ARCHIVELOG; }
| See Also:
Oracle9i Recovery Manager Reference for |
Use the DELETE SCRIPT command to remove a script from the recovery catalog.
To delete a stored script:
After connecting RMAN to the recovery catalog, issue a DELETE SCRIPT command to delete the specified stored script:
DELETE SCRIPT 'b_whole';
| See Also:
Oracle9i Recovery Manager Reference for |
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 "Setting the CONTROLFILE_RECORD_KEEP_TIME Value", 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's control file grows depending on the number of:
As explained in "Monitoring the Overwriting of Control File Records", 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 Oracle may overwrite the oldest records even if their age is less than the CONTROL_FILE_RECORD_KEEP_TIME setting. In this case, Oracle 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 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. Avoid this unpleasant scenario by deciding how to back up and recover the recovery catalog.
This section contains these topics:
When developing a strategy for backing up the recovery catalog, you should follow some general guidelines. This section contains these topics:
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. The backed up catalog contains a record of the target backup preceding it, so if you need to restore the catalog you can use it to restore a target backup.
When backing up the recovery catalog database, you can use RMAN to make the backups. As illustrated in Figure 16-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 is needed.REDUNDANCY value greater than 1.BACKUP COPIES 2 when making backups.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.
| See Also:
Oracle9i User-Managed Backup and Recovery Guide to learn how to back up the control file with SQL statements, and "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 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 catalog to use in a restore scenario. Hence, you should never store the recovery catalog for a target database in the target database itself: this tactic completely defeats the purpose of having a recovery catalog.
If you use RMAN to recover the catalog, then the procedure differs depending on where you stored the metadata for backups of the catalog. Refer to "Performing Basic RMAN Media Recovery" for a table describing the recovery options.
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 catalog:
CATALOG commands to recatalog archived redo logs, backup control files, and datafile copies. Because the CATALOG command does not support recataloging of backup pieces or backup sets, you can re-create information about backup sets only by using the RESYNC CATALOG command.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, run the Import and Export utilities. 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.
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 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 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.
Refer to Oracle9i Database Utilities for concepts and procedures relating to the Export utility.
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.
If you used Export to make a logical backup of the recovery catalog, then use the Import utility to import it into another database.
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 16-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.
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:
Oracle9i 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 executable, then you must upgrade it. For example, you must upgrade the catalog if you use a release 8.1 version of the RMAN executable 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 executable. 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 determine the current release of the catalog schema, you must run a SQL query. Note that the catalog version does not necessarily change with every new release of RMAN. It changes when incompatibilities between catalogs are found. Hence, the best strategy is to let RMAN tell you when you need to upgrade.
To determine the current release of the recovery catalog:
% sqlplus rman/cat@catdb
RCVER catalog table. For example, run this query:
SELECT * FROM RCVER; VERSION ------------ 09.02.00
Use the RMAN UPGRADE CATALOG command to change the catalog to a newer release.
To upgrade the recovery catalog:
% 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 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 has multiple target databases registered. If you try to delete the metadata for one target database by dropping the catalog, then you delete the metadata for all target databases.
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 these records, re-create the control file. |
| See Also:
Oracle9i Recovery Manager Reference for |
RMAN works perfectly well without a recovery catalog. In fact, the recovery catalog receives all its information from the control file. If you choose not to use a recovery catalog, however, you must perform some additional administrative tasks. This section contains these topics:
See Also:
|
If you choose not to use a recovery catalog, then you can still use RMAN very effectively. RMAN obtains the information it needs from the control file of the target database. Nevertheless, some commands are not available when you use the control file as the sole repository of RMAN metadata. The following commands are only available when you use a recovery catalog:
CREATE CATALOG, UPGRADE CATALOG, DROP CATALOGCREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT, PRINT SCRIPTLIST INCARNATIONREGISTER DATABASEREPORT SCHEMA AT TIMERESET DATABASERESYNC CATALOGWhen you do not use a recovery catalog, the control file is the sole source of information about RMAN backups and copies. As you make backups and copies, Oracle adds new records to the control file. These records are circularly reused, which means that Oracle overwrites older records.
The following initialization parameter determines the minimum age in days of a record before it can be overwritten:
CONTROL_FILE_RECORD_KEEP_TIME = integer
For example, if the parameter value is 14, then any record aged 14 days and older is a candidate for reuse. Information in an overwritten record is lost.
What happens when Oracle needs to add new records to the control file, but the oldest record is less than the value specified in CONTROL_FILE_RECORD_KEEP_TIME? The following steps occur:
CONTROL_FILE_RECORD_KEEP_TIME value--and logs this action in the alert.log.Hence, if you are not using a recovery catalog, then set the CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file that you need to keep. For example, if you back up the database once a week, then you need to keep every backup at least a week. Set CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14.
Assume the following scenario:
CONTROL_FILE_RECORD_KEEP_TIME is set to 14.You make a backup of the database. Because Oracle cannot expand the control file beyond the operating system file size limit, it begins overwriting records in the control file, starting with those records aged 13 days. For each record that it overwrites, it records an entry in the alert.log that looks something like the following:
krcpwnc: following controlfile record written over: RECID #72 Recno 72 Record timestamp 07/28/00 22:15:21 Thread=1 Seq#=3460 Backup set key: stamp=372031415, count=17 Low scn: 0x0000.3af33f36 07/27/00 21:00:08 Next scn: 0x0000.3af3871b 07/27/00 23:23:54 Resetlogs scn and time scn: 0x0000.00000001 08/05/99 10:46:44 Block count=102400 Blocksize=512
To guard against this type of scenario, use a recovery catalog. If you cannot use a catalog, then do the following if possible:
alert.log to make sure that Oracle is not overwriting control file records.
| See Also:
"Types of Records in the Control File" for a conceptual overview of control file records |
RMAN provides several commands that allow you to check and delete records of backups as well as physically remove backups and copies.
See Also:
|
If you use the control file as the sole repository of the RMAN metadata, maintain alternate control files through multiplexing or operating system mirroring and back up the control file frequently. If you lose the control file and do not have a backup, you lose all information about RMAN backups and copies contained in the file. For this reason, you should set CONFIGURE CONTROLFILE AUTOBACKUP to ON.
So long as a control file autobackup is available, RMAN can mount and restore the database. After the control file is mounted, you can restore the remainder of the database. Note that you lose persistent configuration settings stored in the control file, but after you restore the autobackup the configuration settings are returned.
See Also:
|
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|