Les 03 Catalog

Editor's Notes

• #3: Oracle Database 11 g : Administration Workshop II 3 -
• #4: RMAN Repository Data Storage: Comparison of Options The RMAN repository data is always stored in the control file of the target database. But it can also, additionally, be stored in a separate database called a recovery catalog. A recovery catalog preserves backup information in a separate database, which is useful in the event of a lost control file. This allows you to store a longer history of backups than what is possible with a control file–based repository. A single recovery catalog is able to store information for multiple target databases. The recovery catalog can also hold RMAN stored scripts, which are sequences of RMAN commands. If you have very simple backup management requirements, Oracle recommends that you use the control file option rather than a recovery catalog. Having a recovery catalog means you need to manage and back up another database. Therefore, use a recovery catalog only if you can take advantage of the benefits it offers, such as longer backup retention.
• #5: Storing Information in the Recovery Catalog RMAN propagates information about the database structure, archived redo logs, backup sets, and data file copies into the recovery catalog from the target database’s control file after any operation that updates the repository, and also before certain operations.
• #6: Oracle Database 11 g : Administration Workshop II 3 - Reasons to Use a Recovery Catalog Although you can use the control file as the sole repository for RMAN, it has finite space for records of backup activities. When you use a recovery catalog, you can store a much longer history of backups. This enables you to perform a recovery that goes back further in time than the history in the control file. If you want to use RMAN stored scripts, you must use a recovery catalog. When you use a recovery catalog, the backup and recovery information for all registered targets is contained in one place allowing you to create customized reports by connecting as the recovery catalog owner and querying the various RC_ views. If you do not use a recovery catalog, you must connect to each target database instance separately and query the V$ views for the RMAN information in the target control file. You can use the BACKUP ... KEEP command to create a backup that is retained for a different period of time from that specified by the configured retention policy. The KEEP FOREVER clause specifies that the backup or copy never expires and requires the use of a recovery catalog so that the backup records can be maintained indefinitely. The REPORT SCHEMA command lists the tablespaces and data files in the target database. If you add the option of AT [ time | scn | logseq ] , you can see that information at some time in the past. You can use the AT option only if you are using a recovery catalog.
• #7: Creating the Recovery Catalog: Three Steps To create a recovery catalog, perform the following three steps: 1. Configure the database in which you want to store the recovery catalog . 2. Create the recovery catalog owner . 3. Create the recovery catalog .
• #8: Oracle Database 11 g : Administration Workshop II 3 - Configuring the Recovery Catalog Database Determine the database in which you will install the recovery catalog schema. Be sure to consider your backup and recovery procedures for this database. Backing up the recovery catalog is covered later in this lesson. The amount of space required by the recovery catalog schema depends on the number of databases monitored by the catalog. The space increases as the number of archived redo log files and backups for each database increases. If you use RMAN stored scripts, space must be allocated for those scripts. The typical space requirement is 15 MB for each database registered in the recovery catalog.
• #9: Creating the Recovery Catalog Owner Create a user to serve as the recovery catalog owner. Set the default tablespace for this user to the tablespace you created for the recovery catalog. Be sure to provide UNLIMITED quota on this tablespace for the user. After you have created the user, grant the RECOVERY_CATALOG_OWNER role to the user. The RECOVERY_CATALOG_OWNER role provides privileges for the owner of the recovery catalog. The role includes the following system privileges: ALTER SESSION , CREATE CLUSTER , CREATE DATABASE LINK , CREATE PROCEDURE , CREATE SEQUENCE , CREATE SESSION , CREATE SYNONYM , CREATE TABLE , CREATE TRIGGER , CREATE TYPE , and CREATE VIEW . You can use SQL commands or Enterprise Manager to create the user and grant the role.
• #10: Oracle Database 11 g : Administration Workshop II 3 - Creating the Recovery Catalog After creating the catalog owner, use the RMAN CREATE CATALOG command to create the catalog tables in the default tablespace of the catalog owner. Note: As with any database, if the ORACLE_SID environment variable is set to the SID for the recovery catalog database, then there is no need to supply the net_service_name in the CONNECT statement.
• #11: Oracle Database 11 g : Administration Workshop II 3 - Managing Target Database Records in the Recovery Catalog Although most information is automatically propagated from the control file to the recovery catalog, there are a few operations you may need to perform to maintain target database records in the recovery catalog.
• #12: Oracle Database 11 g : Administration Workshop II 3 - Registering a Database in the Recovery Catalog After creating the recovery catalog, you must register the target databases in the recovery catalog. To register your target database, perform the following steps: 1. Invoke RMAN and connect to the recovery catalog database and to the target database as shown in the following example: % rman TARGET / CATALOG rman/rman@reccatdb 2. Ensure that the target database is mounted or open. 3. Issue the REGISTER command to register the target database in the recovery catalog: RMAN> REGISTER DATABASE;
• #13: Using Enterprise Manager to Register a Database To register a database with a recovery catalog in EM, you must first add the recovery catalog to the EM configuration. Running EM on the target database, you then select that recovery catalog to be the recovery catalog for the target database. If you use RMAN to register the database, and do not perform the steps in the slide, then any backup and recovery operations performed using EM will not use the recovery catalog. So, if you plan to use EM, perform the registration steps described here even if you have executed the RMAN REGISTER DATABASE command.
• #14: Using Enterprise Manager to Register a Database (continued) From the Database home page, navigate to Availability > Recovery Catalog Settings. Click Add Recovery Catalog to specify the host, port, and SID of a database with an existing recovery catalog. Note: If no recovery catalogs have been added yet, you see a message to that affect in the Recovery Catalog drop-down list. It is possible that you see several to choose from, if they have already been added.
• #15: Using Enterprise Manager to Register a Database (continued) After you have defined the recovery catalog database, select “Use Recovery Catalog” on the Recovery Catalog Setting page to register the database in the recovery catalog database. When you click OK, the database is registered with the catalog.
• #16: Oracle Database 11 g : Administration Workshop II 3 - Registering a Duplicated Database It is common to duplicate an existing database, and then proceed to register it in the same recovery catalog where the original database is registered. If you do this, and the database ID (DBID) still matches the original, you will receive an error saying that the database is already registered in the catalog. There cannot be two databases with the same DBID registered in the same recovery catalog. To correct this, you can use the DBNEWID utility to change the DBID of the duplicate database, as described in the following slide.
• #17: Oracle Database 11 g : Administration Workshop II 3 - Changing the DBID of a Database Use the DBNEWID utility to change the DBID and/or the database name for a database. This solves the problem with needing to register a duplicated database in the same recovery catalog as the source copy of the database. The syntax for the utility is shown in the slide. This changes the DBID, after it prompts you for confirmation. After you have done this, you must realize that the database must be reopened using the RESETLOGS option, and that any backups or archive redo log files that belong to the database are now unusable. You should take a backup of the database after this operation. Note: If you want to change only the database name and not the DBID, then use the SETNAME parameter. See details about this utility in the Oracle Database Utilities documentation.
• #18: Oracle Database 11 g : Administration Workshop II 3 - Unregistering a Target Database from the Recovery Catalog When you unregister a database from the recovery catalog, all RMAN repository records in the recovery catalog are lost. You can reregister the database. The recovery catalog records for that database are then based on the contents of the control file at the time of re-registration. Typically, you would unregister a target database only if you no longer want to use the recovery catalog for that database or the database no longer exists. Note: If you have used Enterprise Manager Database Control to register your database, you must use it again to unregister your database.
• #19: Oracle Database 11 g : Administration Workshop II 3 - Cataloging Additional Backup Files If you have additional control file copies, data file copies, backup pieces , or archived redo log files on disk, you can catalog them in the recovery catalog by using the CATALOG command. If backups have aged out of the control file, you can catalog them so that RMAN can use them during a restore operation. Examples of cataloging a control file, data file, archived redo log file, and backup piece follow: RMAN> CATALOG CONTROLFILECOPY '/disk1/controlfile_bkup/2006_01_01/control01.ctl'; RMAN> CATALOG DATAFILECOPY '/disk1/datafile_bkup/2006_01_01/users01.dbf'; RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.log', '/disk1/arch_logs/archive1_732.log'; RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp'; You can catalog all files in the currently enabled Flash Recovery Area as follows: RMAN> CATALOG RECOVERY AREA NOPROMPT; The START WITH Option Use the START WITH option to catalog all files found in the directory tree specified. Provide a prefix that indicates the directory and possibly a file prefix to look for. You cannot use wildcards; this is only a prefix.
• #20: Oracle Database 11 g : Administration Workshop II 3 - Cataloging Additional Backup Files (continued) The START WITH Option (continued) All types of backup files that are found in and under the specified directory are cataloged. Suppose you have several backup files in the /tmp/arch_logs directory. The following command catalogs all of them: RMAN> CATALOG START WITH '/tmp/arch_logs/'; Suppose you want to be sure to catalog only those files in the /tmp directory whose file names start with the string bset . The following accomplishes that: RMAN> CATALOG START WITH '/tmp/bset';
• #21: Oracle Database 11 g : Administration Workshop II 3 - Recovery Catalog Resynchronization: Concepts When RMAN performs a resynchronization , it compares the recovery catalog to either the current control file of the target database or a backup control file and updates the recovery catalog with information that is missing or changed. There are two types of resynchronization: partial and full. For partial resynchronization, RMAN compares the control file to the recovery catalog and updates the recovery catalog with any metadata concerning backups, archived redo logs, data file copies, and so on. For a full synchronization, RMAN first creates a control file snapshot, which is simply a temporary copy of the control file. It uses the snapshot to make the comparison to the recovery catalog. It compares and updates all the data that a partial resynchronization does, but it also includes any database structure changes. For example, table schema changes or new tablespaces are included in a full resynchronization. If the only changes to the control file are those records that are governed by CONTROL_FILE_RECORD_KEEP_TIME , then a partial resynchronization is done. Otherwise, a full resynchronization is done. A full resynchronization is also done when you issue the RESYNC CATALOG command, which is described in the next slide.
• #22: Oracle Database 11 g : Administration Workshop II 3 - Manually Resynchronizing the Recovery Catalog Perform a manual resynchronization of the recovery catalog in the following situations: If the recovery catalog was unavailable when you issued RMAN commands that cause a partial resynchronization If you perform infrequent backups of your target database because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived After making any change to the physical structure of the target database Note: Refer to the Backup and Recovery User’s Guide for detailed information about records that are updated during resynchronization.
• #23: Oracle Database 11 g : Administration Workshop II 3 - Using RMAN Stored Scripts You can use RMAN stored scripts as an alternative to command files for managing frequently used sequences of RMAN commands. Unlike command files that are available only on the system on which they are stored, a stored script is always available to any RMAN client that can connect to the target database and recovery catalog. Stored scripts can be defined as global or local. A local stored script is associated with the target database to which RMAN is connected when the script is created, and can be executed only when you are connected to that target database. A global stored script can be executed against any database registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a target database.
• #24: Oracle Database 11 g : Administration Workshop II 3 - Creating RMAN Stored Scripts Connect to the desired target database and the recovery catalog and execute the CREATE SCRIPT command to create a stored script.
• #25: Oracle Database 11 g : Administration Workshop II 3 - Executing RMAN Stored Scripts Connect to the target database and recovery catalog, and use the EXECUTE SCRIPT command to execute a stored script. Note that the EXECUTE SCRIPT command requires a RUN block. If an RMAN command in the script fails, subsequent RMAN commands in the script do not execute. When you execute the script, it uses the automatic channels configured at the time. Use ALLOCATE CHANNEL commands in the script if you need to override the configured channels as shown in the following example: RMAN> RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK; ALLOCATE CHANNEL ch2 DEVICE TYPE DISK; ALLOCATE CHANNEL ch3 DEVICE TYPE DISK; EXECUTE SCRIPT full_backup; }
• #26: Oracle Database 11 g : Administration Workshop II 3 - Displaying RMAN Stored Script Information Connect to the target database and recovery catalog and use the PRINT SCRIPT command to display a stored script or write it out to a file. Use the LIST SCRIPT NAMES command to display the names of scripts defined in the recovery catalog. This command displays the names of all stored scripts, both global and local, that can be executed for the target database to which you are currently connected.
• #27: Oracle Database 11 g : Administration Workshop II 3 - Updating and Deleting RMAN Stored Scripts Connect to the target database and recovery catalog and use the REPLACE SCRIPT command to update stored scripts. RMAN creates the script if it does not exist. To delete a stored script from the recovery catalog, connect to the catalog and a target database, and use the DELETE SCRIPT command.
• #28: Backing Up the Recovery Catalog The recovery catalog is an Oracle database, so it needs to be backed up as any database should. Oracle recommends using RMAN to back it up and, of course, use the control file as the RMAN repository, instead of a recovery catalog. 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. A recovery catalog is effective only if it is separated from the data that it is designed to protect. Configure control file autobackup so that the control file is backed up every time a backup is made of the recovery catalog. Any time you make a backup in the target database, back up the recovery catalog right afterward. This protects the record of the latest backup. Below is a summary of how to configure the backup and recovery environment for your recovery catalog: Run the recovery catalog in ARCHIVELOG mode. Set the retention policy to a REDUNDANCY value greater than one. Back up the recovery catalog to disk and tape. To make the backups, use the BACKUP DATABASE PLUS ARCHIVELOG command. Use the control file ( NOCATALOG ), not another recovery catalog, as the RMAN repository. Configure control file autobackup to be ON .
• #29: Oracle Database 11 g : Administration Workshop II 3 - Re-Creating an Unrecoverable Recovery Catalog 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. You can use the following commands to partially repopulate the contents of the recovery catalog: RESYNC CATALOG : Use this command to update the recovery catalog with any RMAN repository information from the control file of the target database or a control file copy. Note that any metadata from control file records that aged out of the control file is lost. CATALOG START WITH... : Use this command to recatalog any available backups.
• #30: Oracle Database 11 g : Administration Workshop II 3 - Exporting and Importing the Recovery Catalog You can use Export and Import to move the recovery catalog from one database to another. You can also create an export of the recovery catalog to serve as a logical backup. Perform the following steps to export a recovery catalog from one database and import the catalog into a second database: 1. Use one of the Oracle Export utilities to export the catalog data from the database. 2. Create a recovery catalog user on the database you are exporting to and grant the user necessary privileges. 3. Use the corresponding Import utility to import the catalog data into the schema created in step 2. You should not execute the CREATE CATALOG command before or after importing the catalog into the database. The import operation creates the catalog in the second database. Note: The recovery catalog can be backed up and moved to another database as a transportable tablespace by using Export and Import or Data Pump, as well as using logical methods.
• #31: Oracle Database 11 g : Administration Workshop II 3 - Upgrading the Recovery Catalog If you use a version of the recovery catalog that is older than that required by the RMAN client, then you must upgrade it by executing the UPGRADE CATALOG command. Note: To install the new recovery catalog schema, the recovery catalog user must have TYPE privilege. You must be connected to the catalog database, and the catalog database must be open. You do not have to be connected to the target database. You must enter the UPGRADE command a second time to confirm the upgrade. You receive an error if the recovery catalog is already at a version greater than that needed by the RMAN executable. However, RMAN permits the command to be run if the recovery catalog is current, so that the packages can be re-created if necessary. RMAN displays all error messages generated during the upgrade in the message log.
• #32: Oracle Database 11 g : Administration Workshop II 3 - Dropping the Recovery Catalog If you no longer want to maintain a recovery catalog, you can drop the recovery catalog schema from the tablespace with the DROP CATALOG command. Dropping the catalog deletes the recovery catalog record of backups for all target databases registered in the catalog. Note: Execute this command only at the RMAN prompt. You must be connected to the recovery catalog database through the CATALOG command-line option or the CONNECT CATALOG command. The catalog database must be open. You do not have to be connected to the target database. Enter the command twice to confirm that you want to drop the schema.
• #33: Using a Virtual Private Catalog A recovery catalog is also referred to as a base recovery catalog. If separation of duties is a security requirement in your database, then it may also be a requirement regarding the data found in your recovery catalog. To help meet that requirement, you can create a virtual private catalog. A virtual recovery catalog essentially separates the recovery catalog into distinct catalogs, but only virtually. This is done with a set of views and synonyms on the base recovery catalog. A base recovery catalog can be sliced up into virtual private catalogs that serve specific groups of databases and users. The catalog owner creates the base catalog, and grants RECOVERY_CATALOG_OWNER to the owner of the virtual catalog. The catalog owner can either grant access to a registered database to the virtual catalog owner or grant REGISTER to the virtual catalog owner. For the former, the virtual catalog owner can then connect to the catalog for a particular target. For the latter, he or she can register a target database. After the virtual private catalog is configured, the virtual private catalog owner uses it just like he or she would a base recovery catalog. This feature allows a consolidation of RMAN repositories while maintaining a separation of responsibilities. Note: For more information about separation of duties, refer to the Oracle Database Vault Administrator’s Guide .
• #34: Using a Virtual Private Catalog (continued) The catalog owner can access all the registered database information in the catalog. The catalog owner can also see a listing of all databases registered, using the following SQL statement: SELECT DISTINCT db_name FROM DBINC; The virtual catalog owner can see only those databases to which he or she has been granted access. Note: If the catalog owner has not been granted SYSDBA or SYSOPER on the target database, then most RMAN operations cannot be performed.
• #35: Creating an RMAN Virtual Private Catalog You create virtual private RMAN catalogs for groups of databases and users. 1. The catalog owner creates the base catalog. 2. The DBA on the catalog database creates the user that will own the virtual private catalog (VPC) and grants RECOVERY_CATALOG_OWNER to the owner of the virtual catalog. 3. The catalog owner can grant access for previously registered databases to the virtual catalog owner or grant REGISTER to the virtual catalog owner. The GRANT CATALOG command is: GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner; The GRANT REGISTER command is: GRANT REGISTER DATABASE TO vpcowner; The virtual catalog owner can then connect to the catalog for a particular target or register a target database. After the VPC is configured, the VPC owner uses it just like a (non-virtual) base recovery catalog.
• #36: Creating an RMAN Virtual Private Catalog (continued) Create a virtual private catalog. If the target database is an Oracle Database 11 g database and the RMAN client is an 11g client, you can use the RMAN command: CREATE VIRTUAL CATALOG; If you plan to use an RMAN version of 10 g Release 2 or earlier with this virtual catalog, then you must execute this stored procedure: base_catalog_owner.dbms_rcvcat.create_virtual_catalog; Connect to the catalog using the VPC owner login, and use it as a normal catalog. This feature allows a consolidation of RMAN repositories and maintains a separation of responsibilities. The catalog owner can access all the registered database information in the catalog. The catalog owner can see a listing of all databases registered with the SQL*Plus command: SELECT DISTINCT db_name FROM DBINC; The virtual catalog owner can see only the databases that have been granted. If the catalog owner has not been granted SYSDBA or SYSOPER on the target database, then most RMAN operations cannot be performed by the catalog owner.
• #37: Oracle Database 11 g : Administration Workshop II 3 -
• #38: Oracle Database 11 g : Administration Workshop II 3 -