Oracle9i Recovery Manager User's Guide Release 1 (9.0.1) Part Number A90135-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:
"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
See Also:
When you use a recovery catalog, RMAN requires that you maintain a recovery catalog schema. Oracle Corporation suggests you put the recovery catalog schema in its own tablespace. However, you can put it in the SYSTEM
tablespace if necessary. Note that SYS
cannot be the owner of the recovery catalog.
You must allocate space to be used by the catalog schema. The size of the recovery catalog schema:
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.
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.
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 change_on_install
has SYSDBA
privileges on the recovery catalog database rcat
.
cattbs
on the recovery catalog database rcat
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:
SQL> CONNECT SYS/change_on_install@rcat AS SYSDBA
CREATE USER rman IDENTIFIED BY rman TEMPORARY TABLESPACE temp DEFAULT TABLESPACE cattbs QUOTA UNLIMITED ON cattbs;
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.
To create the recovery catalog:
% rman CATALOG rman/rman@rcat
You can also connect from the RMAN prompt:
% rman RMAN> CONNECT CATALOG rman/rman@rcat
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;
If the catalog tablespace is not the user's default tablespace, then you must specify it explicitly, as in this example:
# cattbs is not the catalog owner's default tablespace CREATE CATALOG TABLESPACE cattbs;
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 target database, 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 rcat1
. 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 is multiple catalogs. For example, you can register target database prod1
in catalog schema rcat1
and in catalog schema rcat2
.
Each database registered in a given catalog must have a unique database identifier (DBID), but not necessarily a unique database name. Consequently, you cannot clone a database manually and then register it in the same catalog with its parent. Instead, use the DUPLICATE
command to create a test database with a unique identifier.
To register the target database:
rcat
as RMAN:
% rman TARGET / CATALOG rman/rman@rcat
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 204800 SYSTEM YES /ade/lashdown_main/oracle/dbs/tbs_01.f 2 2930 SYSTEM YES /ade/lashdown_main/oracle/dbs/tbs_02.f 3 2930 TBS_1 NO /ade/lashdown_main/oracle/dbs/tbs_11.f 4 2930 TBS_1 NO /ade/lashdown_main/oracle/dbs/tbs_12.f 5 2930 TBS_2 NO /ade/lashdown_main/oracle/dbs/tbs_21.f 6 2930 TBS_2 NO /ade/lashdown_main/oracle/dbs/tbs_22.f
CATALOG
command. For example:
CATALOG DATAFILECOPY '/os_backup/df1.bak'; CATALOG ARCHIVELOG '/backup/log1.arc', '/backup/log2.arc', '/backup/log3.arc';
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:
Oracle9i Recovery Manager Reference for
See Also:
REGISTER
syntax, and Oracle9i Database Migration for issues relating to database migration
Oracle uses an internal, uniquely generated number called the DBID to distinguish one database from another. Oracle generates this number when you create the database.
Typically, each database has a unique identifier. However, an exception occurs with databases that you create by non-RMAN techniques (for example, disk mirroring or 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. Avoid this problem by using the DUPLICATE
command, which copies the database from backups and generates a new database identifier.
If a failure occurs because of duplicate database identifiers, you can create a second recovery catalog in another user's schema by re-executing the CREATE CATALOG
command with a different Oracle username. Then, you can register the database with a duplicate DBID into the newly created recovery catalog in the new schema.
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 SYS/change_on_install@prod1 CATALOG rman/rman@rcat 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 ------- -- -- - ----------- --------------- ------- ------- --- 224 B 0 A DISK 15-SEP-00 1 1 228 B 0 A DISK 15-SEP-00 1 1 232 B 0 A DISK 15-SEP-00 1 1 236 B 0 A DISK 15-SEP-00 1 1 260 B 0 A DISK 15-SEP-00 1 1 265 B 0 A SBT_TAPE 15-SEP-00 1 1 269 B 0 A SBT_TAPE 15-SEP-00 1 1 293 B 0 A SBT_TAPE 15-SEP-00 1 1
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/rman@rcat 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)
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. This incarnation record indicates the that the target database has a new "incarnation," that is, the database has reset its online redo logs. 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
statement, then 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 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 undo the effects of opening with the RESETLOGS
option by restoring backups of a prior incarnation of the database, use the RESET DATABASE TO INCARNATION
key
command to change the current incarnation to an older incarnation.
To reset the recovery catalog to an older incarnation:
LIST
command:
LIST INCARNATION; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- ------- ------ --- ---------- ---------- 1 2 PROD1 1224038686 NO 1 02-JUL-00 1 582 PROD1 1224038686 YES 59727 10-JUL-00
RESET DATABASE TO INCARNATION 2;
SHUTDOWN IMMEDIATE; STARTUP NOMOUNT PFILE=initPROD1.ora
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:
Oracle9i Recovery Manager Reference for |
In some cases, you may want to remove records corresponding to a previous incarnation. For example, if you perform an incomplete recovery of prod1
and open with the RESETLOGS
option, then the backups of prod1
made before the RESETLOGS
are not valid on the new incarnation. If you know that you are not going to reset the prod1
to the previous incarnation, then you can delete the backups as well as the incarnation records for the old incarnation.
To remove incarnation records from the recovery catalog:
DELETE
commands to remove unwanted backup pieces, archived redo logs, and image copies. If you have a retention policy configured, then you can just run the following command:
DELETE OBSOLETE;
If you do not have a retention policy configured, then you can delete backups and copies completed before the RESETLOGS
occurred. For example:
DELETE BACKUP COMPLETED BEFORE 'SYSDATE-10'; DELETE COPY COMPLETED BEFORE 'SYSDATE-10';
rcat
as owner rman
:
% sqlplus rman/rman@rcat
DBINC_KEY
values for the incarnations whose records you want to delete by querying the RC_DATABASE_INCARNATION
recovery catalog view:
SQL> SELECT * FROM RC_DATABASE_INCARNATION;
key_value
is the value of DBINC_KEY
:
SQL> DELETE FROM dbinc WHERE DBINC_KEY=key_value;
The SQL statement removes the specified incarnation records from the recovery catalog.
See Also:
Oracle9i Recovery Manager Reference for more information about the |
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.
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
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.
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
mode
In 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. Thus, you can perform this operation frequently--for example, hourly--without incurring undue costs.
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:
SQL> STARTUP PFILE=initRCAT.ora
% rman TARGET sys/change_on_install@prod1 CATALOG rman/rman@rcat RMAN> STARTUP MOUNT;
RESYNC CATALOG
command at the RMAN prompt:
RMAN> RESYNC CATALOG;
This section contains these topics:
"Printing Scripts Stored in the Recovery Catalog" to learn how to query RMAN stored scripts
See Also:
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.
With RMAN, you can:
Use the CREATE
SCRIPT
command to create an RMAN script and store it in the recovery catalog. A recovery catalog is required for this command.
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
Use the EXECUTE
SCRIPT
command to run an RMAN script that you have stored in the recovery catalog. A recovery catalog is required for this command.
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.
Use the REPLACE
SCRIPT
command to rewrite a catalog script. You cannot use this command 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; }
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';
The recovery catalog is dependent on the target database control file for information. Consequently, the currency of the information in the control file determines the effectiveness of the recovery catalog.
The size of the target database's control file grows depending on the number of:
You can use the CONTROL_FILE_RECORD_KEEP_TIME
parameter to specify the minimum number of days that Oracle keeps this information in the control file. Entries older than the number of days specified are candidates for overwrites by newer information. The larger the CONTROL_FILE_RECORD_KEEP_TIME
setting, the larger the control file.
At intervals less than the CONTROL_FILE_RECORD_KEEP_TIME
setting, do either of the following:
You should perform one of these actions because after the number of days specified in CONTROL_FILE_RECORD_KEEP_TIME
, Oracle overwrites the information in the control file with the most recently created information. If you have not resynchronized the recovery catalog, and Oracle has overwritten the information, then this information cannot be propagated to the recovery catalog.
See Also:
|
Include the recovery catalog in your backup and recovery strategy. If you do not back up the recovery catalog and a disk crash 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.
Make sure to set the CONTROL_FILE_RECORD_KEEP_TIME
initialization parameter to a value that is high enough to store an adequate amount of historical backup data for the catalog. In the event that the catalog database and control file are destroyed, you can restore a control file autobackup and then use it to restore the catalog database.
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 rcat
are on different hosts.
rcat
contains the recovery catalog repository for target database prod1
.
You decide to use a catalog to back up rcat
, but are not sure where to create it. If you create the catalog containing the repository for rcat
in database rcat
, then if you lose rcat
due to a media failure, you will have difficulty restoring rcat
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:
CATALOG
command
CROSSCHECK
command
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 cat_owner
owns the recovery catalog on database rcat1
, and you want to export the recovery catalog on rcat1
and import it into database rcat2
, then cat_owner
should not already own a recovery catalog on rcat2
. You should either create a new recovery catalog owner on rcat2
, or drop the current cat_owner
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 prod1
is rman
, you can issue the following at the UNIX command line to export the catalog to file cat.dmp
:
% exp rman/rman@prod1 FILE=cat.dmp OWNER=rman
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
.
new_cat
is rcat
.
cat.dmp
.
The command is then as follows:
% imp USERID=rcat/rcat_pwd@new_cat FILE=cat.dmp FROMUSER=rman TOUSER=rcat
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.
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/rman@rcat
RCVER
catalog table. For example, run this query:
SQL> SELECT * FROM RCVER; VERSION ------------ 09.00.01
Use the RMAN UPGRADE
CATALOG
command to change the catalog to a newer release.
To upgrade the recovery catalog:
% rman TARGET / CATALOG rman/rman@rcat 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.00.00 DBMS_RCVMAN package upgraded to version 09.00.00 DBMS_RCVCAT package upgraded to version 09.00.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/rman@rcat
DROP CATALOG
command twice to confirm:
DROP CATALOG; recovery catalog owner is rman enter DROP CATALOG command again to confirm catalog removal DROP CATALOG;
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 CATALOG
CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT, PRINT SCRIPT
LIST
STORED
FILES
LIST INCARNATION
REGISTER DATABASE
REPORT SCHEMA AT TIME
RESET DATABASE
RESYNC CATALOG
When 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
.
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.
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 enable the control file autobackup feature.
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-2001, Oracle Corporation. All Rights Reserved. |
|