Mantain recovery catalogs
Configure Recovery Manager
Use Recovery Manager to perform database backups
Use Recover Manager to perform complete database restore and recovery operations
Configure RMAN
Create different types of RMAN backups to cater for different performance and retention requirements
Set Flashback Database parameters
Configure a Fast Recovery Area
Perform various recovery operations using Flashback technology
Oracle® Database Backup and Recovery User’s Guide
11g Release 1 (11.1)
12 Managing a Recovery Catalog
This chapter explains how to manage an RMAN recovery catalog. The catalog is a database schema that contains the RMAN repository data for one or more target databases. This chapter contains the following topics:
- Overview of the Recovery Catalog
- Creating a Recovery Catalog
- Registering a Database in the Recovery Catalog
- Cataloging Backups in the Recovery Catalog
- Creating and Managing Virtual Private Catalogs
- Protecting the Recovery Catalog
- Managing Stored Scripts
- Maintaining a Recovery Catalog
- Dropping a Recovery Catalog
For this practice, I have created 2 new VM machines and installed Oracle 11.2.0.3 on the. the first one will be my test server where I will do all the backup/recovery and the other will work as a recovery catalog.
What is the recovery catalog? Oracle maintains all of the metadata related to RMAN operations in the RMAN repository.
The RMAN repository is always stored in the control file of the target database. In some cases, you might want to store the
RMAN repository in another location. This location is called RMAN recovery catalog.
The test database should be in archivelog mode. Only in this mode we will be able to do the online backups.
Here are the steps, to put your DB in archivelog mode:
SQL> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/flash_recovery_area/RCAT/archivelog' scope=both; System altered. SQL> shu immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 234356736 bytes Fixed Size 1344088 bytes Variable Size 146804136 bytes Database Buffers 83886080 bytes Redo Buffers 2322432 bytes Database mounted. SQL> alter database archivelog; Database altered. SQL> alter database open; Database altered. SQL> select log_mode from v$database; LOG_MODE ------------ ARCHIVELOG
Creating the Recovery Catalog
First, we should create a new tablespace in the DB.
SQL> create tablespace catalog datafile '/oracle/oradata/catalog01.dbf' size 100M;
Tablespace created.
Now, we can create a new user account for the RMAN:
SQL> create user rcat identified by testOra1 default tablespace catalog;
User created.
SQL> alter user rcat quota unlimited on catalog;
User altered.
SQL> grant connect,resource,recovery_catalog_owner to rcat;
Grant succeeded.
Creating the Recovery Catalog Schema Objects
connect to the catalog and create the schema objects:
[oracle@rcat oracle]$ rman catalog rcat/**********
Recovery Manager: Release 11.2.0.3.0 - Production on Mon Dec 5 15:18:49 2011
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to recovery catalog database
RMAN> create catalog tablespace "CATALOG";
recovery catalog created
Register the Database with the Recovery Catalog
On the target DB, run this commands: [oracle@btest oracle]$ rman target / catalog rcat/*********@rcat Recovery Manager: Release 11.2.0.3.0 - Production on Mon Dec 5 15:43:22 2011 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: BTEST (DBID=4236471253) connected to recovery catalog database RMAN> register database; database registered in recovery catalog starting full resync of recovery catalog full resync complete Unregistering a Database from the Recovery Catalog If you want to unregister a database, you have just to connect to the DB and recovery catalog and issue: [oracle@btest oracle]$ rman target / catalog rcat/******@rcat Recovery Manager: Release 11.2.0.3.0 - Production on Tue Dec 6 08:33:41 2011 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: BTEST (DBID=4236471253) connected to recovery catalog database RMAN> unregister database; database name is "BTEST" and DBID is 4236471253 Do you really want to unregister the database (enter YES or NO)? YES database unregistered from the recovery catalog If your database was deleted, you have to connect to the recovery catalog and specify the DB name: [oracle@rcat oracle]$ rman catalog rcat/*********@rcat Recovery Manager: Release 11.2.0.3.0 - Production on Tue Dec 6 08:32:11 2011 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to recovery catalog database RMAN> unregister database BTEST; database name is "BTEST" and DBID is 4236471253 Do you really want to unregister the database (enter YES or NO)? Y database unregistered from the recovery catalog If you have more databases with same name, you should set dbid before unregistering the database: RMAN> set dbid 4236471253; executing command: SET DBID database name is "BTEST" and DBID is 4236471253 RMAN> unregister database; database name is "BTEST" and DBID is 4236471253 Do you really want to unregister the database (enter YES or NO)? Y database unregistered from the recovery catalog Manually Resynchronizing the Recovery Catalog: Normaly, the RMAN using resymchrozation after every backup to ensure, taht the rpository is synchronized with the control file. If you, from time to time, running backups with nocatalog, you shold manually synchronize catalog with control file: [oracle@btest oracle]$ rman target / catalog rcat/testOra1@rcat Recovery Manager: Release 11.2.0.3.0 - Production on Tue Dec 6 09:24:53 2011 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: BTEST (DBID=4236471253) connected to recovery catalog database RMAN> resync catalog; starting full resync of recovery catalog full resync complete Recovery catalog views: RC_ARCHIVED_LOG (V$ARCHIVED_LOG) - information about all archived logs that have been generated by target DB. on the target DB: [oracle@btest oracle]$ sqlplus "/ as sysdba" SQL> set lines 200 col name for a50 col completion_time for a25 select name,sequence#,status,completion_time from v$archived_log; NAME SEQUENCE# S COMPLETION_TIME -------------------------------------------------- ---------- - ------------------------- /oracle/oarch/1_14_769077077.dbf 14 A 06-DEC-11 on Recovery manager: [oracle@rcat oracle]$ sqlplus SQL*Plus: Release 11.2.0.3.0 Production on Tue Dec 6 09:33:43 2011 Copyright (c) 1982, 2011, Oracle. All rights reserved. Enter user-name: rcat Enter password: SQL> set lines 200 col name for a50 col completion_time for a25 select name,sequence#,status,completion_time from rc_archived_log; NAME SEQUENCE# S COMPLETION_TIME -------------------------------------------------- ---------- - ------------------------- /oracle/oarch/1_14_769077077.dbf 14 A 06-DEC-11
RC_BACKUP_CONTROLFILE (V$BACKUP_DATAFILE) – info about backups of controlfile
SQL> select file#,creation_time,resetlogs_time,blocks,block_size,controlfile_type from v$backup_datafile where file#=0;
RC_BACKUP_CORRUPTION (V$BACKUP_CORRUPTION) – list the corruption that exists in datafile backups
RC_BACKUP_DATAFILE (V$BACKUP_DATAFILE) – This view has extensive information about datafiles that exists in backup
sets.
RC_BACKUP_FILES (V$BACKP_FILES) – This view most completely corresponds to the information provided by the commands
list backup and list copy from the RMAN command-line interface.
To use this view, you have to call dbms_rcvman.setdatabase to indicate which DB you want to use:
call dbms_rcvman.setdatabase(null,null,null,2283997583,null)
RC_BACKUP_PIECE (V$BACKUP_PIECE) – view information about specific backup pieces that have been created during
normal backup operation.
RC_BACKUP_REDOLOG (V$BACKUP_REDOLOG) – list archive logs that exists in backup sets.
RC_BACKUP_SET (V$BACKUP_SET) – information in this view refers to each logical backup set.
RC_BACKUP_SPFILE (V$BACKUP_SPFILE) – information about spfile backups.
RC_CONTROLFILE_COPY (V$CONTROLFILE_COPY) – information about controlfile backup created by copy command or
cataloged with the catalog command.
RC_COPY_CORRUPTION (V$COPY_CORRUPTION) – info about blocks that are corrupt in copies.
RC_DATABASE (V$DATABASE) – basic info about each database registered in the catalog.
RC_DATABASE_BLOCK_CORRUPTION (V$DATABASE_BLOCK_CORRUPTION) – This view provides the corruption list that is
populated when a backup or backup validate operation discovers corrupt block.
RC_DATABASE_INCARNATION (V$DATABASE_INCARNATION) – this view contains a record for each incarnation of each
database registered in catalog
RC_DATAFILE (V$DATAFILE) – info about datafiles
RC_DATAFILE_COPY (V$DATAFILE_COPY) – metadata about datafile copies created by the copy command
RC_LOG_HISTORY (V$LOG_HISTORY) – historical info about online redo logs
RC_OFFLINE_RANGE (V$OFFLIE_RANGE) – when datafiles came online/offline/read only
RC_REDO_LOg (V$REDO_LOG) – info about redologs
RC_REDO_THREAD (V$REDO_THREAD) – important only in RAC environment
RC_RESYNC – info for each resync operation that occurs
RC_RMAN_CONFIGURATION (V$RMAN_CONFIGURATION) – equivalent for the show all command
RC_TABLESPACE (V$TABLESPACE) – ifo about tablesapces
RC_TEMPFILE (V$TEMPFILE) – info about tempfiles
Ref
Cataloging Backups in the Recovery Catalog
If you have datafile copies, backup pieces, or archived logs on disk, then you can catalog them in the recovery catalog with 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.
CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
You can also catalog multiple backup files in a directory at once by using the CATALOG START WITH command, as shown in the following example:
CATALOG START WITH '/disk1/backups/';
For example, assume that a group of directories /disk1/backups, /disk1/backups-year2003, /disk1/backupsets, and /disk1/backupsets/test and so on, all contain backup files. The following command catalogs all files in all of these directories, because /disk1/backups is a prefix for the paths for all of these directories:
CATALOG START WITH '/disk1/backups';
To catalog only backups in the /disk1/backups directory, the correct command would be as follows:
CATALOG START WITH '/disk1/backups/';
Creating and Managing Virtual Private Catalogs
The recommended practice is to create one recovery catalog that serves as the central RMAN repository for all your databases.
The recovery catalog as a whole is also termed the base recovery catalog. It can contain zero or more virtual private catalogs.
A virtual private catalog is a set of synonyms and views that refer to a base recovery catalog.
About Virtual Private Catalogs
By default, only the owner of a base recovery catalog has access to its metadata.
As the owner of a base recovery catalog, you can use the RMAN GRANT command to grant restricted access to the recovery catalog
to other database users.
The owner of the base recovery catalog decides which database users can share a recovery catalog and which databases they can access.
When you grant a catalog user restricted access, you give this user full read/write access to his own RMAN metadata, which is the virtual private catalog.
Note that a virtual private catalog owner can create a local stored script, but only has read-only access to a global stored script.
The set of views and synonyms that makes up the virtual private catalog is stored in the schema of the virtual private catalog owner.
The mechanisms for virtual private catalogs exist in the recovery catalog schema itself. Security is provided by the recovery catalog database, not by the RMAN executable.
The basic steps for creating a virtual private catalog are as follows:
Note:-
Assume that the following databases are registered in the base recovery catalog: prod1, prod2, and prod3.
The database user who owns the base recovery catalog is catowner.
You want to create database user vpc1 and grant this user access privileges only to prod1 and prod2.
By default, a virtual private catalog owner has no access to the base recovery catalog.
To create and grant privileges to a virtual private catalog owner:
SQL> CREATE TABLESPACE vpcusers; SQL> CREATE USER vpc1 IDENTIFIED BY password DEFAULT TABLESPACE vpcusers QUOTA UNLIMITED ON vpcusers; SQL> GRANT recovery_catalog_owner TO vpc1;
Start RMAN and connect to the recovery catalog database as the base recovery catalog owner (not the virtual private catalog owner).
The following example connects to the base recovery catalog as catowner:
% rman
RMAN> CONNECT CATALOG catowner@catdb;
recovery catalog database Password: password
connected to recovery catalog database
(e.g. $rman target sys/******@ORCL catalog rcat/rcat@RCAT )
Grant desired privileges to the virtual private catalog owner.
The following example gives user vpc1 access to the metadata for prod1 and prod2 (but not prod3):
RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1; RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;
You can also use a DBID rather than a database name.
Note that the virtual private catalog user does not have access to the metadata for any other databases registered in the recovery catalog.
You can also grant the user the ability to register new target databases in the recovery catalog. For example:
RMAN> GRANT REGISTER DATABASE TO vpc1;
Creating a Virtual Private Catalog
Start RMAN and connect to the recovery catalog database as the virtual private catalog owner (not the base recovery catalog owner).
The following example connects to the recovery catalog as vpc1:
% rman
RMAN> CONNECT CATALOG vpc1@catdb;
Create the virtual private catalog.
The following command creates the virtual private catalog:
RMAN> CREATE VIRTUAL CATALOG;
If you intend to use a 10.2 or earlier release of RMAN with this virtual private catalog,
then execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog):
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
Revoking Privileges from a Virtual Private Catalog Owner
Note:-
Assume that two databases are registered in the base recovery catalog: prod1 and prod2.
As owner of the base recovery catalog, you have granted the vpc1 user access privileges to prod1.
You have also granted this user the right to register databases in his virtual private catalog.
Now you want to revoke privileges from vpc1.
To revoke privileges from a virtual private catalog owner:
Start RMAN and connect to the recovery catalog database as the recovery catalog owner (not the virtual private catalog owner).
The following example connects to the recovery catalog as catowner:
% rman RMAN> CONNECT CATALOG catowner@catdb;
Revoke specified privileges from the virtual private catalog owner.
The following command revokes access to the metadata for prod1 from virtual private catalog owner vpc1:
REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
You can also revoke the privilege to register new target databases in the recovery catalog. For example:
REVOKE REGISTER DATABASE FROM vpc1;
Dropping a Virtual Private Catalog
This section assumes that you have already created a virtual private catalog and now want to drop it.
When you drop a virtual private catalog, you do not remove the base recovery catalog itself, but only
drop the synonyms and views that refer to the base recovery catalog.
To drop a virtual private catalog:
Start RMAN and connect to the recovery catalog database as the virtual private catalog owner (not the base recovery catalog owner).
The following example connects to the recovery catalog as user vpc1:
% rman
RMAN> CONNECT CATALOG vpc1@catdb;
Drop the catalog.
If you are using an Oracle Database 11g or later RMAN executable, then drop the virtual private catalog
with the DROP CATALOG command:
RMAN> DROP CATALOG;
If you are using an Oracle Database 10g or earlier RMAN executable, then you cannot use the DROP CATALOG command.
Instead, connect SQL*Plus to the catalog database as the virtual private catalog user, then execute the following
PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog):
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.DELETE_VIRTUAL_CATALOG;
Protecting the Recovery Catalog
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. Without the recovery catalog contents, recovery of your other databases
is likely to be more difficult.
A single recovery catalog is able to store metadata for multiple target databases.
Consequently, loss of the recovery catalog can be disastrous.
You should back up the recovery catalog frequently.
This section provides general guidelines for developing a strategy for protecting 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 a target database.
For example, if you make a weekly whole database backup of a target database, then back up the recovery catalog after the backup of the target database. This backup of the recovery catalog can help you in a disaster recovery scenario.
Even if you have to restore the recovery catalog database with a control file autobackup,
you can use the full record of backups in your restored recovery catalog database to restore the target database.
Choosing the Appropriate Technique for Physical Backups
When backing up the recovery catalog database, you can use RMAN to make the backups.
Start RMAN with the NOCATALOG option so that the repository for RMAN is the control file in the catalog database.
Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database:
Run the recovery catalog database in ARCHIVELOG mode so that you can do point-in-time recovery if needed.
Set the retention policy to a REDUNDANCY value greater than 1.
Back up the database to two separate media (for example, disk and tape).
Run BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if available, or just to disk.
Do not use another recovery catalog as the repository for the backups.
Configure the control file autobackup feature to 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.
Separating the Recovery Catalog from the Target Database
A recovery catalog is only effective when separated from the data that it is designed to protect.
Thus, you should never store a recovery catalog containing the RMAN repository for a database in the same database as the target database.
Also, do not store the catalog database on the same disks as the target database.
To illustrate why data separation is advised, assume that you store the catalog for database prod1 in prod1. If prod1 suffers a total media failure, and if the recovery catalog for prod1 is also stored in prod1, then if you lose the database you also lose the recovery catalog. At this point the only option is to restore an autobackup of the control file for prod1 and use it to restore and recover the database without the benefit of any information stored in the recovery catalog.
Exporting the Recovery Catalog Data for Logical Backups
Logical backups of the RMAN recovery catalog created with the Data Pump Export utility can be a useful supplement for physical backups.
In the event of damage to a recovery catalog database, you can use Data Pump Import to quickly reimport the exported recovery catalog
data into another database and rebuild the catalog.
Recovering the Recovery Catalog
Restoring and recovering the recovery catalog database is much like restoring and recovering any other database with RMAN.
You can restore the control file and server parameter file for the recovery catalog database from an autobackup,
then restore and perform complete recovery on the rest of the database.
Managing Stored Scripts
As explained in “About Stored Scripts”, you can store scripts in the recovery catalog. This section explains how to create and manage stored scripts.
About Stored Scripts
You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file system.
Stored scripts can be local or global.
A local 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.
The commands allowable within the brackets of the CREATE SCRIPT command are the same commands supported within a RUN block.
Any command that is legal within a RUN command is permitted in the stored script.
The following commands are not legal within stored scripts: RUN, @, and @@.
if the script name passed as an argument is not the name of a script defined for the connected target instance,
then RMAN looks for a global script by the same name.
For example, if the global script global_backup is in the recovery catalog,
but no local stored script global_backup is defined for the target database,
then the following command deletes the global script:
DELETE SCRIPT global_backup;
Note that to use commands related to stored scripts, even global scripts,
you must be connected to both a recovery catalog and a target database instance.
Creating Stored Scripts
To create a stored script:
local script:-
CREATE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
global script:-
CREATE GLOBAL SCRIPT global_full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
Optionally, you can 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;
}
You can also create a script by reading its contents from a text file.
The file must begin with a left brace ({) character, contain a series of commands valid within a RUN block, and end with a right brace (}) character.
CREATE SCRIPT full_backup FROM FILE '/tmp/my_script_file.txt';
Replacing Stored Scripts
To update stored scripts, use the REPLACE SCRIPT command.
If you are replacing a local script, then you must be connected to the target database
that you connected to when you created the script.
If the script does not already exist, then RMAN creates it.
Replace Local Script:-
REPLACE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
Replace Global Script-I:-
REPLACE GLOBAL SCRIPT global_full_backup
COMMENT 'A script for full backup to be used with any database'
{
BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
}
Replace Global Script-II:-
REPLACE GLOBAL SCRIPT global_full_backup
FROM FILE '/tmp/my_script_file.txt';
Executing Stored Scripts
Use the EXECUTE SCRIPT command to run a stored script.
If GLOBAL is specified, then a global script with this name must already exist in the recovery catalog;
otherwise, RMAN returns error RMAN-06004.
If GLOBAL is not specified, then RMAN searches for a local stored script defined for the current target database.
If no local script with this name is found, then RMAN searches for a global script by the same name and executes it if one is found.
Run EXECUTE SCRIPT. This command requires a RUN block, as shown in the following example:
RUN
{
EXECUTE SCRIPT full_backup;
}
You can also use EXECUTE GLOBAL SCRIPT to control which script is invoked if a local and a global script have the same name.
If 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;
}
Printing Stored Scripts
Run the PRINT SCRIPT command as follows:
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 '/tmp/my_script_file.txt';
For global scripts, the analogous syntax would be as follows:
PRINT GLOBAL SCRIPT global_full_backup;
PRINT GLOBAL SCRIPT global_full_backup
TO FILE '/tmp/my_script_file.txt';
Listing Stored Script Names
commands that work when RMAN is connected to a recovery catalog without connecting to a target instance;
LIST SCRIPT NAMES; LIST GLOBAL SCRIPT NAMES; LIST ALL SCRIPT NAMES;
Deleting Stored Scripts
DELETE SCRIPT 'global_full_backup'; DELETE GLOBAL SCRIPT 'global_full_backup';
Executing a Stored Script at RMAN Startup
% rman TARGET / CATALOG rman@catdb SCRIPT '/tmp/fbkp.cmd';
Note:- If local and global stored scripts are defined with the same name, then RMAN always executes the local script.
Maintaining a Recovery Catalog
- About Recovery Catalog Maintenance
- Resynchronizing the Recovery Catalog
- Updating the Recovery Catalog After Changing a DB_UNIQUE_NAME
- Unregistering a Target Database from the Recovery Catalog
- Resetting the Database Incarnation in the Recovery Catalog
- Upgrading the Recovery Catalog
- Importing and Moving a Recovery Catalog
About Recovery Catalog Maintenance
After you have created a recovery catalog and registered your target databases, you need to maintain this catalog.
For example, you need to run RMAN maintenance commands
To update backup records as well as to delete backups that are no longer needed
Resynchronizing the Recovery Catalog
When RMAN performs a resynchronization, it compares the recovery catalog to either the current or backup control file of the
target database and updated the catalog with metadata that is missing or changed.
Most RMAN commands perform a resynchronization automatically when the target control file is mounted
and the catalog is available
In a Data Guard environment, RMAN can perform a reverse resynchronization to update a database control file with metadata from
the catalog.
About Resynchronization of the Recovery Catalog
Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.
Resynchronization can be full or partial.
In a partial resynchronization, RMAN reads the current control file of the target database to update changed metadata above new
backups,new archive redo logs and so on.
RMAN does not resynchronize metadata about the database physical schema.
In a full resynchronization, RMAN updates all changed records, including those of the database schema.
RMAN performs a full resynchronization after structural changes to database(adding or dropping database files,creating new incarnation and so on)
or after changes to the RMAN persistent configuration.
RMAN creates a snapshot control file, which is a temporary backup control file, when it performs a full resynchronization.
The database ensures that only one RMAN session accesses a snapshot control file at any point in time.
RMAN creates the snapshot control file in an os specific location on the target database host.
This snapshot control file ensures that RMAN has a consistent view of the control file.
RMAN records the control file checkpoint in the recovery catalog to indicate the currency of the catalog.
Recovery Catalog Resynchronization in a Data Guard Environment
RMAN only automatically resynchronizes the recovery catalog with a database when connected to this database as TARGET.
Thus, RMAN does not automatically resynchronize every database in a Data Guard environment when connected as TARGET to one database in the environment.
You can use the RESYNC CATALOG FROM DB_UNIQUE_NAME command to manually resynchronize the recovery catalog with a database in the Data Guard environment.
For an example of a manual resynchronization, assume that RMAN is connected as TARGET to production database prod, and that you have used CONFIGURE to create a configuration for dgprod3. If you run RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3, then RMAN resynchronizes the recovery catalog with the dgprod3 control file. In this case RMAN performs both a normal resynchronization, in which metadata flows from the dgprod3 control file to the catalog, and a reverse resynchronization. In a reverse resynchronization, RMAN uses the persistent configurations in the recovery catalog to update the dgprod3 control file.
Deciding When to Resynchronize the Recovery Catalog
RMAN automatically resynchronizes the recovery catalog when RMAN is connected to a target database and
recovery catalog and you have executed RMAN commands. Thus, you should not need to manually run the
RESYNC CATALOG command very often.
The following sections describe situations requiring a manual catalog resynchronization.
Resynchronizing After the Recovery Catalog is Unavailable
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.
Example:-
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 and run the RESYNC CATALOG command.
Resynchronizing in ARCHIVELOG Mode When You Back Up Infrequently
Assume that a target database runs in ARCHIVELOG mode. Also assume that you do the following:
Back up the database infrequently (for example, hundreds of redo logs are archived between database backups)
Generate a high number of log switches every day (for example, 1000 switches between catalog resynchronizations)
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.
The database stores metadata about redo 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
Resynchronizing After Configuring a Standby Database
You can create or change an RMAN configuration for a standby database even when not connected to this database as TARGET.
You perform this task with the CONFIGURE DB_UNIQUE_NAME or CONFIGURE … FOR DB_UNIQUE_NAME command.
you can resynchronize the standby database manually to update the control file of the standby database.
Resynchronizing the Recovery Catalog Before Control File Records Age Out
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.
Thus, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. You should perform either of the following actions at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting:
Make a backup, thereby performing an implicit resynchronization of the recovery catalog
Manually resynchronize the recovery catalog with the RESYNC CATALOG command
Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog.
Caution:
Never set CONTROL_FILE_RECORD_KEEP_TIME to 0. If you do, then backup records may be overwritten in the control file before RMAN is able to add them to the catalog.
Manually Resynchronizing the Recovery Catalog
Use RESYNC CATALOG to force a full resynchronization of the recovery catalog with a target database control file.
Start RMAN and connect to a target database and recovery catalog.
Mount or open the target database if it is not already mounted or open:
STARTUP MOUNT;
Resynchronize the recovery catalog.
Run the RESYNC CATALOG command at the RMAN prompt as follows:
RESYNC CATALOG;
The following example resynchronizes the control file of standby1:
RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;
The following variation resynchronizes the control files for all databases in the Data Guard environment:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
Updating the Recovery Catalog After Changing a DB_UNIQUE_NAME
Connect RMAN to the primary database as TARGET and also to the recovery catalog.
For example, enter the following commands:
% rman RMAN> CONNECT CATALOG catowner@catdb recovery catalog database Password: password connected to recovery catalog database RMAN> CONNECT TARGET SYS@prodny target database Password: password connected to target database: PRODNY (DBID=39525561)
List the DB_UNQUE_NAME values known to the recovery catalog.
Run the following LIST command:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
Change the DB_UNIQUE_NAME in the RMAN metadata.
The following example changes the database unique name from standby database prodsf1 to prodsf2:
RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
Unregistering a Target Database from the Recovery Catalog
Start RMAN and connect as TARGET to the database that you want to unregister.
Also connect to the recovery catalog.
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.
Make a note of the DBID as displayed by RMAN at startup.
For example, RMAN outputs a line of the following form when it connects to a target database that is open:
connected to target database: PROD (DBID=39525561)
As a precaution, it may be useful to list all of the backups recorded in the recovery catalog
using LIST BACKUP SUMMARY and LIST COPY SUMMARY.
This way, you can recatalog backups not known to the control file if you later decide to reregister the database.
If your intention is to actually delete all backups of the database completely, then run DELETE statements to delete all existing backups. Do not delete all backups if your intention is only to remove the database from the recovery catalog and rely on the control file to store the RMAN metadata for this database.
The following commands illustrate how to delete backups:
DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;
RMAN lists the backups that it intends to delete and prompts for confirmation before deleting them.
Run the UNREGISTER DATABASE command. For example:
UNREGISTER DATABASE;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database name is "RDBMS" and DBID is 931696259
Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database unregistered from the recovery catalog
Unregistering a Standby Database
To unregister a standby database:
Start RMAN and connect as TARGET to the primary database. Also, connect RMAN to a recovery catalog.
For example, enter the following commands:
% rman
RMAN> CONNECT TARGET SYS@lnx3
target database Password: password
connected to target database: LNX3 (DBID=781317675)
RMAN> CONNECT CATALOG rman@catdb
List the database unique names.
For example, execute the LIST DB_UNIQUE_NAME command as follows:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
List of Databases
DB Key DB Name DB ID Database Role Db_unique_name
------- ------- ----------------- --------------- ------------------
1 LNX3 781317675 STANDBY STANDBY
1 LNX3 781317675 PRIMARY LNX3
Run the UNREGISTER DB_UNIQUE_NAME command.
For example, execute the UNREGISTER command as follows to unregister database standby:
RMAN> UNREGISTER DB_UNIQUE_NAME standby;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database db_unique_name is "standby", db_name is "LNX3" and DBID is 781317675
Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database with db_unique_name standby unregistered from the recovery catalog
Resetting the Database Incarnation in the Recovery Catalog
To reset the recovery catalog to an older incarnation for media recovery:
Determine the incarnation key of the desired database incarnation.
Obtain the incarnation key value by issuing a LIST command:
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- ------- ------ ------- ---------- ----------
1 2 TRGT 1224038686 PARENT 1 02-JUL-02
1 582 TRGT 1224038686 CURRENT 59727 10-JUL-02
The incarnation key is listed in the Inc Key column.
Reset the database to the old incarnation. For example, enter:
RESET DATABASE TO INCARNATION 2;
If the control file of the previous incarnation is available and mounted,
then skip to step 6 of this procedure. Otherwise, shut down the database and start it without mounting.
For example:
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
Restore a control file from the old incarnation. If you have a control file tagged,
then specify the tag. Otherwise, you can run the SET UNTIL command, as in this example:
RUN
{
SET UNTIL 'SYSDATE-45';
RESTORE CONTROLFILE; # only if current control file is not available
}
Mount the restored control file:
ALTER DATABASE MOUNT;
Run RESTORE and RECOVER commands to restore and recover the database files from the prior incarnation, then open the database with the RESETLOGS option. For example, enter:
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
Upgrading the Recovery Catalog
To determine the schema version of the recovery catalog:
Start SQL*Plus and connect to the recovery catalog database as the catalog owner.
Query the RCVER table to obtain the schema version, as in the following example (sample output included):
SELECT *
FROM rcver;
VERSION
------------
10.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 10.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 10.2.0. The current version of the catalog schema is 10.2.0.
This scenario assumes that you are upgrading a recovery catalog schema to the current version.
To upgrade the recovery catalog:
If you created the recovery catalog owner in a release before 10gR1,
and if the RECOVERY_CATALOG_OWNER role did not include the CREATE TYPE privilege, then grant it.
For example, start SQL*Plus and connect to the recovery catalog database with administrator privileges.
You can then execute the following GRANT statement:
SQL> GRANT CREATE TYPE TO rman;
SQL> EXIT;
Start RMAN and connect RMAN to the recovery catalog database.
Run the UPGRADE CATALOG command:
RMAN> UPGRADE CATALOG;
recovery catalog owner is rman
enter UPGRADE CATALOG command again to confirm catalog upgrade
Run the UPDATE CATALOG command again to confirm:
RMAN> UPGRADE CATALOG;
recovery catalog upgraded to version 11.01.00
DBMS_RCVMAN package upgraded to version 11.01.00
DBMS_RCVCAT package upgraded to version 11.01.00
Importing and Moving a Recovery Catalog
To import a recovery catalog:
Start RMAN and connect as CATALOG to the destination recovery catalog schema. For example:
% rman
RMAN> CONNECT CATALOG 111cat@destdb;
Import the source recovery catalog schema, specifying the connection string for the source catalog.
For example, enter the following command to import the catalog owned by 102cat on database srcdb:
IMPORT CATALOG 102cat@srcdb;
A variation is to import metadata for a subset of the target databases registered in the source catalog.
You can specify the databases by DBID or database name, as shown in the following examples:
IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242;
IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4;
Optionally, connect to a target database to check that the metadata was successfully imported.
For example, the following commands connect to database prod1 as TARGET and list all backups for this database:
LIST BACKUP;
To move a recovery catalog from the source database to the destination database:
Create a recovery catalog on the destination database, but do not register any databases in the new catalog.
- “Creating a Recovery Catalog” explains how to perform this task.
- Import the source catalog into the catalog created in the preceding step.
“Importing a Recovery Catalog” explains how to perform this task.
Dropping a Recovery Catalog
Note:-
The DROP CATALOG command is not appropriate for unregistering a single database from a recovery catalog that has multiple target databases registered. Dropping the recovery catalog deletes the recovery catalog record of backups for all target databases registered in the catalog.
To drop a recovery catalog schema:
Start RMAN and connect to a target database and recovery catalog.
Connect to the recovery catalog as the owner of the catalog schema to be dropped.
The following example connects to a recovery catalog as user catowner:
% rman TARGET / CATALOG catowner@catdb
Run the DROP CATALOG command:
DROP CATALOG;
recovery catalog owner is catowner
enter DROP CATALOG command again to confirm catalog removal
Run the DROP CATALOG command again to confirm:
DROP CATALOG;
Getting Started with RMAN
Use Recovery Manager to perform database backups
Use Recover Manager to perform complete database restore and recovery operations
Configure RMAN
Create different types of RMAN backups to cater for different performance and retention requirements
Set Flashback Database parameters
Configure a Fast Recovery Area
Perform various recovery operations using Flashback technology
Technology Blog 