3
Creating and Maintaining an RMAN Catalog
CERTIFICATION OBJECTIVES
3.01 Identify situations that require RMAN recovery catalog
3.02 Create and configure a recovery catalog
3.03 Synchronize the recovery catalog
3.04 Create and Use RMAN stored scripts
3.05 Back up the recovery catalog
3.06 Create and use a virtual private catalog
3.07 Configure backup settings
3.08 Allocate channels to use in backing up
3.09 Configure backup optimization
If you’re ready to do some backups with RMAN, you’ll have to wait until the next chapter. This chapter lays the groundwork for performing RMAN backups by creating the recovery catalog. Without a recovery catalog, your backup information is limited to the RMAN information stored in the target database’s control file. You’ll learn how to do this at the command line and from Oracle Enterprise Manager.
Next, you’ll learn how to register and unregister a database from the recovery catalog. Once a database is registered with a recovery catalog, you’ll see scenarios for which you might need to resynchronize the RMAN backup information in the target database control file with the recovery catalog. In most cases, RMAN performs the synchronization automatically.
RMAN stored scripts makes your job easier by saving frequently used sequences of commands in a recovery catalog; using stored scripts is one of many advantages of using a recovery catalog for RMAN backups over a target database’s control file.
To subdivide the division of labor among several DBAs in your enterprise, the RMAN recovery catalog supports the concept of a virtual private catalog; each DBA can view and access only the backup information for which he or she is responsible. This catalog enables a single location for all target database backup information while maintaining a separation of duties, just as Oracle Database Vault can restrict a DBA to accessing only the part of the database for which he or she is responsible.
Next, you’ll review the configuration options available in RMAN when you are connected to a target database; each target database has its own set of configurable parameters, such as the compression level, automatic backups of the control file, and channel types.
Finally, the chapter briefly covers a couple of other topics: how to allocate channels for an RMAN backup, and how to skip over files that are identical to those already backed up in previous backup sets (to save on backup time).
CERTIFICATION OBJECTIVE 3.01
Identify Situations that Require RMAN Recovery Catalog
RMAN always stores its metadata (information about the database structure, backup sets, and image copies) in the target database’s control file. However, there are several advantages, and a few disadvantages, to storing this metadata in a recovery catalog stored in a separate database. The next two sections discuss the pros and cons of using a recovery catalog.
Using the Control File for RMAN Metadata
Oracle strongly recommends using a recovery catalog, but doing so has a few downsides. Whether you use a recovery catalog or not, the RMAN backup information is always stored in the control file of the target database. Although the RMAN information in the control file is aged out based on the value of the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME, this might not be a problem if you use an RMAN retention policy that has a RECOVERY WINDOW that is less than CONTROL_FILE_RECORD_KEEP_TIME. In addition, using your control file as the only repository for RMAN information is easier to manage, because you don’t need a second database, which in turn, needs to be backed up. Finally, if you are mirroring your control file in several locations and you create an offsite backup of your control file after every database structure change or RMAN backup, then you will likely never lose your control file and will always be able to restore your database successfully from any media failure, even a complete loss of the database. Using a recovery catalog database also means that you have another database to back up on a regular basis.
Using a Recovery Catalog for RMAN Metadata
If you manage more than one database in your environment, and you want to keep your recovery information for a much longer time, then using a recovery catalog might be justified. A single recovery catalog can store RMAN information for a virtually unlimited number of target databases. In addition, all information in the control file of the target database resides in the RMAN recovery catalog after you perform the first RESYNC CATALOG operation.
Using stored scripts is another reason to use a recovery catalog; you cannot store scripts in the target database’s control file. You can save a sequence of commands as a single script to make it easy to run the sequence of commands on demand, or perhaps on a specific schedule. A script can be tied to a specific target database (a local script), or it can be available to all target databases (a global script).
Because you can put the metadata from several databases into a single recovery catalog, you can use the RC_ views, such as RC_ARCHIVED_LOG, RC_BACKUP_FILES, and RC_DATABASE, in the recovery catalog database to retrieve metadata for all target databases. Otherwise, when you’re using the target database control file, you must connect to each target database separately and query the V$ views based on the target database’s control file.
Finally, using a recovery catalog permits you to use the following RMAN commands:
BACKUP...KEEP UNTIL TIME Keep a backup for a period of time that differs from the configured retention policy.
BACKUP...KEEP FOREVER Keep a backup indefinitely or until you manually remove it.
REPORT SCHEMA...AT Show the structure of the database at a specific time in the past.
CERTIFICATION OBJECTIVE 3.02
Create and Configure a Recovery Catalog
Whether you use a repository for the metadata from one database or a hundred, the repository setup is straightforward and needs to be done only once. The examples that follow assume that you have a default installation of an Oracle 11g database. The repository database itself can be used for other applications if no significant performance degradation occurs when RMAN needs to update metadata in the repository.
Using an RMAN target database for the repository is strongly discouraged. Loss of the target database prevents any chance of a successful recovery of the database using RMAN because the repository metadata is lost along with the target database. If both are lost, you will have to maintain manual backups of the target database for recovery of the repository.
The following sequence of commands creates a tablespace and a user to maintain the metadata in the repository database. In this and all subsequent examples, a database with a system ID (SID) of RCAT is used for all repository operations. Three basic steps are required: configure the recovery catalog database, create the recovery catalog owner, and create the recovery catalog itself.
Configure the Recovery Catalog Database
The tablespace that holds the repository database requires at least 125MB to hold recovery catalog entries; here are the minimum additional space requirements for the repository, by tablespace:
90MB in the SYSTEM tablespace
5MB in the TEMP tablespace
5MB in the UNDO tablespace
15MB in RMAN default tablespace for each database registered in the recovery catalog
1MB for each online redo log file
Starting out with available free space of 125MB will in most cases be sufficient for the first year, and enabling automatic extents of 50MB each will be sufficient in the long term depending on how many databases you manage in the recovery catalog. Overall, it’s a very small amount of disk space compared to your terabyte data warehouse!
Connect to the repository database with SYSDBA privileges and create the recovery catalog in the RMAN tablespace as follows:
Create the Recovery Catalog Owner
Creating the recovery catalog owner is as easy as creating any database user. In this example, we create the user RMAN to manage the recovery catalog. You could just as easily create a user called FRED to own the recovery catalog. Using RMAN as the catalog owner makes it easier to identify the purpose of the account:
The predefined role RECOVERY_CATALOG_OWNER includes these system privileges:
ALTER SESSION
CREATE CLUSTER
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE SEQUENCE
CREATE SESSION
CREATE SYNONYM
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
CREATE VIEW
Later in this chapter, you’ll learn how to create virtual catalog owners, each of which will own a virtual private catalog. This enables the division of responsibilities among many DBAs, allowing management of multiple databases using the same RMAN repository.
Create the Recovery Catalog
Now that the RMAN user account exists in the repository database, you can start RMAN, connect to the catalog, and initialize the repository with the CREATE CATALOG command:
From this point on, using a repository is as easy as specifying the repository username and password on the RMAN command line with the CATALOG parameter, or using the CONNECT CATALOG command in an RMAN session. Within Oracle Enterprise Manager, you can persist the repository credentials as demonstrated in Figure 3-1.
FIGURE 3-1 Persisting RMAN repository credentials
In future EM sessions, any RMAN backup or recovery operations will automatically use the recovery catalog.
CERTIFICATION OBJECTIVE 3.03
Synchronize the Recovery Catalog
Now that you’ve set up your recovery catalog, you can register one or more of your databases with the recovery catalog. The registration process propagates backup information and the target database structure to the recovery catalog. In general, RMAN saves most information from the control file to the recovery catalog; however, a few operations require you to update the metadata manually in the recovery catalog.
The following sections cover topics related to recovery catalog synchronization: registering a database, unregistering a database, and resynchronizing a recovery catalog. In addition, you’ll learn how to change the database identifier (DBID) of a duplicated database to permit you to register the duplicated database in the recovery catalog; the DBID of each database recorded in the recovery catalog must be unique.
Registering a Database
For each database for which RMAN will perform a backup or recovery, you must register the database in the RMAN repository; this operation records information such as the target database schema and the unique DBID of the target database. The target database needs to be registered only once; subsequent RMAN sessions that connect to the target database will automatically reference the correct metadata in the repository. The database must be in the MOUNT or OPEN state to be successfully registered.
The following example connects to the target database using operating system authentication, and to the repository with password authentication:
All databases registered with the repository must have unique DBIDs; trying to register the database again yields the following error message:
As you might expect, you can use Enterprise Manager (EM) to register the database; Figure 3-2 shows the Recovery Catalog Settings page where you can specify a recovery catalog and register the database. If you do not include this step in the registration process, any backups you perform using EM will not be recorded in the recovery catalog.
FIGURE 3-2 Specifying a repository and registering a database using EM
Changing the DBID of a Database
In the preceding section, you attempted to register the same database in the recovery catalog twice. RMAN prevented the duplicated registration because a database with the same DBID already existed in the recovery catalog. But what if you duplicate a database, and now want to use the same recovery catalog for both databases? You can use the DBNEWID utility, using the nid command at the command line prompt.
Running nid without any parameters shows you the possible parameters:
TARGET specifies the username and password of the database, as you might expect. You can optionally specify DBNAME to create a new database name in addition to the DBID; if you want to change only the database name, you specify SETNAME=Y.
Here is the DBID for the DW database before you change it:
The database whose name and DBID will be changed must be shut down cleanly and restarted in MOUNT mode, as in this example:
Next, you run the nid command at the command line prompt; you want to change only the DBID:
Finally, open the database with the RESETLOGS option:
Here is the DW database’s DBID after you change it:
Using the DBNEWID command has at least one downside. Since all backup files contain the old DBID, previous backups are unusable; after you change the DBID, you must open the database for the first time with the RESETLOGS option as shown in the preceding example. In addition, you should perform a full backup of the database, since you now have no usable previous backups.
Unregistering a Database
If you want to migrate your backup information from one recovery catalog to another, either because of space pressure on the existing catalog, or an erroneously registered database, you can unregister a database from a recovery catalog using, as you might expect, the UNREGISTER command. In this example, you connect to the target database and the recovery catalog, and then you execute the UNREGISTER command:
After you unregister a database, your backup metadata is still stored in the control file for the number of days specified by the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. If you reregister the database, Oracle populates the recovery catalog with the backup-related and database structure metadata from the control file. If you wish to add information about any backups not in the control file at the time you reregister the database, you can manually add the backup metadata with the CATALOG command, as you will see in the next section.
Cataloging Additional Backup Files
If you have created backups outside of RMAN, or you have registered your database and RMAN backups have already been aged out of the control file, you can use the CATALOG command to add these backups to the RMAN recovery catalog. The CATALOG command can add the following types of backup files to the recovery catalog with the associated keyword for the CATALOG command:
Data file copies DATAFILECOPY
Backup pieces BACKUPPIECE
Control file copies CONTROLFILECOPY
Archived redo log files ARCHIVELOG
For example, you might want to record an additional archived log file destination in the recovery catalog, in addition to the archived log files in the flash recovery area that are already recorded. If you want to catalog a number of backup files in a specific Automatic Storage Management (ASM) disk group location or a file system location, you can use the START WITH option. This example uses the START WITH option to catalog all backup files in the ASM disk group +DATA2:
The filename or file path specified in the START WITH clause is only a prefix, and no wildcards are allowed.
EXERCISE 3-1
Cataloging Additional Backup Files
In this exercise, the DW database has an additional archived log destination at /u02/oradata/archivelog, and these archived log files were created before the database was registered with the recovery catalog. Query the file system location using the Unix ls command, and add all archived log files in that location to the recovery catalog:
1. Query the file system for a list of backup files:
2. Connect to RMAN and use the CATALOG START WITH command to add these archived redo log files to the recovery catalog:
If you inadvertently or intentionally unregistered the database, you can reregister the database. However, some of your backup metadata might have been aged out of the control file because reregistration uses metadata from the control file. If you have a flash recovery area, you can easily recatalog all backups in the flash recovery area using the RECOVERY AREA option of the CATALOG command:
The NOPROMPT keyword, as you might expect, catalogs each backup without confirmation.
Manually Resynchronize the Recovery Catalog
In some situations, you need to resynchronize the metadata in the target database’s control file with the recovery catalog. For example, the recovery catalog database might be unavailable for one or more of your backups because of a network problem or because the recovery catalog database is down. In this situation, RMAN records the backup information only in the target database control file. RMAN always records backup information in the control file even when the recovery catalog is unavailable!
|
The RMAN recovery catalog records information about target database structures, archived redo logs, and backups when you run an RMAN In addition, you may perform infrequent backups and rely on archived redo log files for a recovery scenario. This is not a problem per se, but the list of recent archived redo log files is not recorded automatically in the recovery catalog.
Finally, you may occasionally make changes to the physical structure of the target database. This information is automatically recorded in the target database control file but not in the recovery catalog.
Manually resynchronizing the recovery catalog is a straightforward process. After you start RMAN (and connect to a recovery catalog, of course), run the RESYNC CATALOG command, as in this example:
CERTIFICATION OBJECTIVE 3.04
Create and Use RMAN Stored Scripts
As mentioned earlier in this chapter, RMAN stored scripts helps you automate repetitive groups of RMAN commands, easing the daily grind of being an Oracle DBA. Stored scripts are a good alternative to scripts you store on a traditional file system. Not only is the script stored with the recovery catalog (in other words, you won’t lose it when you move the recovery catalog database), you can also control access to stored scripts by restricting a script to a single target database or to all databases managed within the recovery catalog.
Creating RMAN Stored Scripts
You create an RMAN script with the CREATE SCRIPT or CREATE GLOBAL SCRIPT command. The GLOBAL parameter specifies that the script is available to all RMAN target databases sharing this recovery catalog. To create a script as either global or local, you must be connected to the target database and the recovery catalog. This example creates a global script called GLOBAL_BACKUP_DB that creates a full backup including archived log files:
If you wanted the script to be available only to one specific target database, you would omit the GLOBAL keyword. If you already have an RMAN script in a text file on a file system, you can import the script into an RMAN global or local script using this syntax:
Executing RMAN Stored Scripts
Running a global or local RMAN stored script is straightforward; however, you must execute the script within a RUN block. The syntax is as follows:
Here is how to run the global script you created in the previous section:
You can also use parameters within an RMAN stored script. In other words, if one or two values will change within a script, such as the value for a particular channel or the value of an object to back up, then you can use the & character as a substitution indicator, much as you would in a SQL*Plus script.
EXERCISE 3-2
Creating a Parameterized Stored Script
In this exercise, you’ll automate the backup of individual tablespaces. You will create an RMAN global script to accomplish this, with a parameter that will prompt you for a tablespace name.
1. Create a global stored script with the &1 parameter representing a tablespace name:
Notice that the default value for the tablespace parameter is USERS.
2. Run the stored script, and override the default value assigned for the tablespace when you created the script with the SYSTEM tablespace:
Retrieving RMAN Stored Script Metadata
You can retrieve the contents of RMAN stored scripts using the PRINT and LIST commands: the PRINT command shows the contents of an individual script, and the LIST command shows the names of global scripts or both global and local scripts.
This example uses the LIST SCRIPT NAMES command to show both the local and global scripts:
The LIST GLOBAL SCRIPT NAMES returns only the global script names.
To show the actual contents of a script, use the PRINT command. Because a global script and a local script can have the same name, you qualify the PRINT command with the GLOBAL option if you want to print the global version instead of the local version. This example retrieves the contents of the global_backup_db script:
You can spool the contents of a global or local script to a file using the TO FILE option of the PRINT command:
Managing RMAN Stored Scripts
It’s also easy to delete or replace stored scripts. To replace a stored script, use the REPLACE [GLOBAL] SCRIPT command. In this example, you want to modify the global script backup_ts to back up the SYSTEM tablespace in addition to the desired tablespace:
As you might expect, you use the DELETE SCRIPT command to delete a global or local script:
CERTIFICATION OBJECTIVE 3.05
Back Up the Recovery Catalog
Since the recovery catalog resides in an Oracle database, it must be backed up and restored just like any other database. You must know how to re-create a recovery catalog when your recovery catalog database backups are incomplete. In addition, you may be required to move the recovery catalog to another database and drop the recovery catalog from a database. These topics, in addition to upgrading a recovery catalog, are covered in the following sections.
Backing Up the Recovery Catalog
Even though this has already been mentioned in this chapter, and in other chapters—and for that matter, in other books—it’s worth another reminder: Don’t keep your recovery catalog in the same database as your target database. If you lose the target database, you also lose your recovery catalog, and you must rely on a backup or multiplexed copy of the target database control file to re-create the recovery catalog and restore the database, assuming that you have adequate backups and any structural changes to the target database were made within the window of the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME.
Now that you’ve been reminded to keep the recovery catalog in a separate database, you should also remember to back up the database containing the recovery catalog, using RMAN of course, to ensure that the recovery catalog metadata and backup information are recorded in the recovery catalog database’s control file. Here is the Oracle-recommended configuration for ensuring a recoverable recovery catalog database:
1. Configure the database for ARCHIVELOG mode.
2. Set the RMAN parameter RETENTION POLICY to REDUNDANCY greater than 1.
3. Back up the recovery catalog to disk and tape after each target database backup (in other words, two separate media types).
4. Use BACKUP DATABASE PLUS ARCHIVELOG when you back up the recovery catalog.
5. Use CONFIGURE CONTROLFILE AUTOBACKUP ON to ensure that the control file is backed up after every RMAN backup.
This configuration ensures that a complete loss of either a target database or a recovery catalog database is completely recoverable. If you lose both the target database and the recovery catalog database at the same time, it’s probably because you are using the target database for the recovery catalog. And, as a final reminder, do not do that!
Recovering from a Lost Recovery Catalog
In the event that you lose the recovery catalog database, the recovery operation is much the same as recovering any other database that has adequate backups (using RMAN) and is running in ARCHIVELOG mode. For example, you can restore a control file backup (or use a multiplexed control file), and then restore and perform a complete recovery using RMAN backups of the recovery catalog plus archived redo log files. If you have the luxury of having two recovery catalog databases, you can save the RMAN metadata for one recovery catalog in the database of the other recovery catalog.
If you have no backups of your recovery catalog database, your options are more limited, but not all hope is lost. Here are the steps to follow to retrieve most, if not all, of the metadata for your target database backups:
1. Re-create the recovery catalog database from scratch.
2. Register the target database with the new recovery catalog.
3. Perform a RESYNC CATALOG operation to copy all available backup information from the target database control file.
4. Use the CATALOG START WITH command to add information about any available backups of the target database to the recovery catalog.
Since the previous physical backup files for your target database contain the target DBID, and RMAN identifies each database in its recovery catalog with the DBID, the RMAN CATALOG START WITH command can easily assign each backup to its associated target database in the recovery catalog.
Exporting and Importing the Recovery Catalog
As you can with any database, you can use the Oracle Data Pump export and import utilities expdp and impdp to create logical backups of the recovery catalog. You can use this logical backup to move the recovery catalog to another database. Follow these general steps to move a recovery catalog to another database:
1. Use an export utility to copy the recovery catalog schema to an export dump file.
2. Create the recovery catalog owner on the target catalog database with the appropriate permissions; see “Create the Recovery CatalogOwner” earlier in this chapter.
3. Use the corresponding import utility to copy the recovery catalog schema to the target catalog database.
The next time you launch RMAN, you connect to the same target database but a different recovery catalog database. However, even though the recovery catalog database name is different, the target database’s metadata is identical to the metadata in the previous recovery catalog.
You can also use transportable tablespaces to move a recovery catalog schema from one database to another.
You do not need to run an RMAN CREATE CATALOG command in this scenario; the tables, columns, and views are already in place from the source database.
Dropping a Recovery Catalog
After you have successfully moved the recovery catalog, you can drop the catalog from the previous recovery catalog database. As you might expect, you use the DROP CATALOG command to remove the catalog from the previous recovery catalog database. In fact, you need to run the command twice as a way of confirming your desire to delete, as in this example:
Note that you do not need to connect to a target database to drop a recovery catalog. Also, to ensure that all traces of the recovery catalog owner are removed from the previous recovery catalog database, do not manually remove the recovery catalog owner’s schema. Use the DROP CATALOG command instead.
Upgrading the Recovery Catalog
To support a newer RMAN client (for example, your RMAN recovery catalog is at version 10g and a new RMAN client is at version 11g), you use the UPGRADE CATALOG command to update the local packages and schema. As with the DROP CATALOG command, you are prompted twice, and you do not need to be connected to a target database. Here is an example:
You receive an error message if you attempt to downgrade the recovery catalog version. However, if the version has not changed, the UPGRADE CATALOG command proceeds in case all required packages are not in place.
CERTIFICATION OBJECTIVE 3.06
Create and Use a Virtual Private Catalog
In many organizations, one DBA cannot manage the RMAN backups for all databases within the organization. In addition, the relatively recent Sarbanes-Oxley mandates require an IT shop to tighten up the security and access to each database so that a DBA can see only the databases and database backups for which they are responsible. As of Oracle Database 11g, you can create an RMAN virtual private catalog to facilitate and enforce these separations of duty. In the following sections, you’ll get more details about RMAN virtual private catalogs, learn how to create and manage a virtual private catalog, and see a virtual private catalog in action.
Understanding Virtual Private Catalogs
A virtual private catalog is functionally identical to the recovery catalog discussed throughout this chapter; from the perspective of an individual DBA, it appears to be a single catalog containing only his or her databases’ metadata and RMAN backup information. From this point on, the recovery catalog discussed earlier in the chapter will be called the base catalog. Each virtual private catalog is a logical partition of the base catalog. Each virtual catalog owner relies on a separate Oracle account and several views and synonyms in the recovery catalog database.
As was already done earlier in this chapter, the base recovery catalog owner creates the base catalog and grants the RECOVERY_CATALOG_OWNER role to each Oracle account that will own a virtual private catalog. If databases are already registered in the base recovery catalog, the base catalog owner can grant access to a registered database for a virtual private catalog owner; alternatively, the base recovery catalog owner can grant the REGISTER privilege to the virtual private catalog owner so he or she can register a new database in the virtual private catalog.
Creating and Managing a Virtual Private Catalog
The following sections show you how to set up a virtual private catalog, create the virtual private catalog owner, and then grant the appropriate privileges to the virtual private catalog owner. Next, the virtual private catalog owner will create a virtual private catalog and register one or more databases. Alternatively, the base catalog owner can grant catalog privileges for an already registered database to a virtual catalog owner.
For the examples in the following sections, the base catalog owner RMAN for the RCAT database will create a virtual private catalog owner VPC1 and grant the RMAN privilege REGISTER DATABASE to VPC1. The DBA of the HR database on the server srv04 will use VPC1 to create a virtual private catalog and register the HR database.
Creating Virtual Private Catalog Owners
On the recovery catalog database, the first step is to create an Oracle account that will own the virtual private catalog:1
Granting Permissions to Virtual Private Catalog Owners
Next, you will grant the RECOVERY_CATALOG_OWNER privilege to VPC1, the owner of the new virtual private catalog:
Note that the user VPC1 is not the owner of the entire recovery catalog; the role name is a bit misleading. Instead, it means that VPC1 can create his or her own private recovery catalog that is a logical subset of the base recovery catalog.
Optionally, the base recovery catalog owner can now grant permission on existing catalogs using the RMAN GRANT CATALOG command. In this example, the base catalog owner gives permission to VPC1 on the DW database that is already registered in the recovery catalog:
If the base recovery catalog owner wants the user VPC1 to register his or her own databases, the owner must grant the RMAN privilege REGISTER DATABASE to VPC1, as in this example:
Creating a Virtual Private Catalog
Now that the user VPC1 has the appropriate privileges to create and populate a virtual catalog, the next step is to connect to RMAN as the user VPC1 and create the catalog.
For convenience, the user VPC1 connected to the target database HR at the same time that he connected to the recovery catalog. The next step is to create the virtual private catalog itself (this needs to be done only once, just as you need to register a database only once):
If your RMAN client’s version is prior to Oracle Database 11g, you must instead use a SQL prompt to execute a stored procedure to create the virtual catalog, as follows:
Dropping a virtual private catalog is the same as dropping a base catalog; just make sure you do not execute the DROP CATALOG command as the base catalog owner!
Using a Virtual Private Catalog
Now that all the permissions are granted and the virtual catalog has been created, the user VPC1 can register a database:
To see which databases the user VPC1 can manage via the RMAN virtual private catalog, connect to the recovery catalog database and query the DBINC view:
Note that you have to use DISTINCT in the SELECT statement. The DBINC view has one row for each incarnation of a target database; without the use of DISTINCT, more than one row per database will often appear.
CERTIFICATION OBJECTIVE 3.07
Configure Backup Settings
RMAN configuration settings can appear daunting at first, until you realize that the “out-of-the-box” settings for RMAN don’t require many configuration changes to perform successful full and incremental backups to disk. The following sections reiterate some key RMAN concepts and capabilities, go into a bit more depth on how to specify alternative backup destinations, cover how to persist some RMAN settings, and show you how to ensure that the control file is backed up with every backup.
Types of RMAN Backups
RMAN supports a number of different backup methods, depending on your availability needs, the desired size of your recovery window, and the amount of downtime you can endure while the database or a part of the database is involved in a recovery operation.
Consistent and Inconsistent Backups
A physical backup can be classified as being a consistent or an inconsistent backup. In a consistent backup, all datafiles have the same System Change Number (SCN). In other words, all changes in the redo logs have been applied to the datafiles. Because an open database with no uncommitted transactions can have some dirty blocks in the buffer cache, it is rare that an open database backup can be considered consistent. As a result, consistent backups are taken when the database is shut down normally or in a mounted (MOUNT) state.
In contrast, an inconsistent backup is performed while the database is open and users are accessing the database. A recovery operation performed using an inconsistent backup must rely on both archived and online redo log files to bring the database into a consistent state before it is opened. This is because the SCNs of the datafiles typically do not match when an inconsistent backup takes place. As a result, a database must be in ARCHIVELOG mode to use an inconsistent backup method. Apart from that, backup mode tablespaces can produce a lot of redo log entries and recycled log entries could be lost.
Full and Incremental Backups
Full backups include all blocks of every datafile within a tablespace or a database; it is essentially a bit-for-bit copy of one or more datafiles in the database. Either RMAN or an operating system command can be used to perform a full backup, although backups performed outside of RMAN must be cataloged with RMAN before they can be used in an RMAN recovery operation. However, it is possible to recover a database manually without using RMAN.
In Oracle 11g, incremental backups can be level 0 or level 1. A level 0 backup is a full backup of all blocks in the database that can be used in conjunction with differential, incremental, or cumulative incremental level 1 backups in a database recovery operation. A distinct advantage to using an incremental backup in a recovery strategy is that archived and online redo log files may not be necessary to restore a database or tablespace to a consistent state; the incremental backups may have some or all of the blocks needed. Incremental backups can be performed only within RMAN.
Image Copies
Image copies are full backups created by operating system commands or RMAN BACKUP AS COPY commands. Although a full backup created with a Linux cp command can be later registered in the RMAN catalog as a database backup, doing the same image copy backup in RMAN has the advantage of checking for corrupt blocks as they are being read by RMAN and recording the information about the bad blocks in the data dictionary. Image copies are the default backup file format in RMAN.
This is a great feature of Oracle 11g’s RMAN for the following reason: If you add another datafile to a tablespace, you also need to remember to add the new datafile to your Linux script cp command. By creating image copies using RMAN, all datafiles will automatically be included in the backup. Forgetting to add the new datafile to a Linux script will make a recovery situation extremely inconvenient at best and a disaster at worst.
Backupsets and Backup Pieces
In contrast to image copies, which can be created in most any backup environment, backupsets can be created and restored only with RMAN. A backupset is an RMAN backup of part or all of a database, consisting of one or more backup pieces. Each backup piece belongs only to one backupset and can contain backups of one or many datafiles in the database. All backupsets and pieces are recorded in the RMAN repository, the same as any other RMAN-initiated backup.
Compressed Backups
For any Oracle11g RMAN backup creating a backupset, compression is available to reduce the amount of disk space or tape needed to store the backup. Compressed backups are usable only by RMAN, and they need no special processing when used in a recovery operation; RMAN automatically decompresses the backup. Creating compressed backups is as easy as specifying AS COMPRESSED BACKUPSET in the RMAN BACKUP command.
RMAN Backup Destinations
RMAN backup destinations include a file system disk directory, a tape-based media library, or the flash recovery area. Oracle best practices dictate that you use a flash recovery area for many reasons; Chapter 2 covered the details of configuring and using the flash recovery area and the initialization parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. One of the many benefits of a flash recovery area include automatic file naming for backup files. In addition, RMAN automatically deletes obsolete files in the flash recovery area when it’s pressed for space.
To facilitate a completely disk-based recovery scenario, the flash recovery area should be big enough for a copy of all datafiles, incremental backup files, online redo logs, archived redo logs not on tape, control file autobackups, and server parameter file (SPFILE) backups. Using a larger or smaller recovery window or adjusting the redundancy policy will require an adjustment in the size of the flash recovery area. If the area is limited in size due to disk space constraints, at a minimum enough room should be available to hold the archived log files that have not yet been copied to tape. The dynamic performance view V$RECOVERY_FILE_DEST displays information about the number of files in the flash recovery area, how much space is currently being used, and the total amount of space available in the area.
The flash recovery area automatically uses Oracle Managed Files (OMF). As part of Oracle 11g’s simplified management structure, you do not need to set any of the LOG_ARCHIVE_DEST_n initialization parameters explicitly if you need only one location for archived redo log files; if the database is in ARCHIVELOG mode, and a flash recovery area is defined, then the initialization parameter LOG_ARCHIVE_DEST_10 is implicitly defined as the flash recovery area.
As you have seen in many examples, RMAN uses the flash recovery area in a very organized fashion—with separate directories for archived logs, backupsets, image copies, block change tracking files, and automatic backups of the control file and SPFILE. In addition, each subdirectory is named with the date of the backup (for example, +RECOV/dw/autobackup/2008_09_28), making it easy to find a backupset or image copy when the need arises.
Multiple databases, even a primary and a standby database, can share the same flash recovery area. Even with the same DB_NAME, as long as the DB_UNIQUE_NAME parameter is different, no conflicts will occur. RMAN uses the DB_UNIQUE_NAME to distinguish backups between databases that use the same flash recovery area.
Persisting RMAN Settings
To make the DBA’s job easier, a number of RMAN settings can be persisted. In other words, these settings will stay in effect between RMAN sessions. In the example that follows, the SHOW ALL command is used to display the default RMAN settings:
Any parameters that are set to their default values have # default at the end of the configuration setting. These parameters are easy to review and change using EM, as demonstrated in Figure 3-3.
FIGURE 3-3 RMAN persistent parameters in EM
The next few sections review a few of the more common RMAN persistent settings.
Retention Policy
Backups can be automatically retained and managed using one of two methods: by a recovery window or by redundancy. Using a recovery window, RMAN will retain as many backups as necessary to bring the database to any point in time within the recovery window. For example, with a recovery window of seven days, RMAN will maintain enough image copies, incremental backups, and archived redo logs to ensure that the database can be restored and recovered to any point in time within the last seven days. Any backups that are not needed to support this recovery window are marked as OBSOLETE and are automatically removed by RMAN if a flash recovery area is used and disk space is needed for new backups.
In contrast, a redundancy retention policy directs RMAN to retain the specified number of backups or copies of each datafile and control file. Any extra copies or backups beyond the number specified in the redundancy policy are marked as OBSOLETE. As with a recovery window, obsolete backups are automatically removed if disk space is needed and a flash recovery area is used. Otherwise, you can use the DELETE OBSOLETE command to remove the backup files and update the catalog.
If the retention policy is set to NONE, no backups or copies are ever considered obsolete, and the DBA must manually remove unneeded backups from the catalog and from disk.
The following example sets the retention policy to a recovery window of four days (from a default redundancy policy of one copy):
Device Type
If the default device type is set to DISK and no pathname parameter is specified, RMAN uses the flash recovery area for all backups; you can easily override the disk backup location in EM, as you can see in Figure 3-4. As with many of the simplified administration tasks from Oracle 11g, there is no need to allocate or deallocate a specific channel for backups unless you’re using a tape device.
FIGURE 3-4 Configuring backup destination using EM
Although configuring a tape device is specific to your installation, in general terms you configure a tape device as follows:
sbt is the device type used for any tape backup subsystem, regardless of vendor.
Although you can use the flash recovery area to restore and recover your database entirely from disk, at some point it becomes inefficient to keep all your backups on disk, especially if you have a large recovery window. As a result, you can make copies of your backup files to tape, and RMAN will dutifully keep track of where the backups are in case you need to restore or recover the database from tape, or restore archived redo logs to roll forward an image copy in the flash recovery area.
Control File Autobackups
Because of the importance of the control file, you should back it up at least as often as it changes due to modifications in the structure of the database. By default, the backup of the control file does not occur automatically. This is a strange default, considering the importance of the control file and how little disk space it takes to back it up. Fortunately, RMAN can easily be configured to back up the control file automatically, either any time a successful backup must be recorded in the repository or when a structural change affects the contents of the control file (in other words, cases when a control file backup must occur to ensure a successful recovery if and when a recovery operation is required):
Every RMAN backup from this point on will automatically include a copy of the control file. The control file is also backed up whenever a new tablespace is created or another datafile is added to an existing tablespace.
CERTIFICATION OBJECTIVE 3.08
Allocate Channels to Use in Backing Up
You can allocate channels in two different ways in RMAN: you can set channels with the CONFIGURE command, or you can set them by using the ALLOCATE CHANNEL within a RUN block to override the default channel or if no default channel is defined. As mentioned earlier in the chapter, you don’t have to specify any channels if your destination is a disk location.
Here is the line from the SHOW ALL command that specifies the default device type. Note that no default channel is defined since the default device type is DISK:
CERTIFICATION OBJECTIVE 3.09
Configure Backup Optimization
In Oracle Database 11g, RMAN supports backup optimization. In other words, the RMAN BACKUP command skips backups of one or more files when identical files have already been backed up to the specified device, such as disk or tape. RMAN takes into consideration the retention policy and the backup duplexing capabilities of RMAN to determine whether enough backups of a particular file already exist.
By default, backup optimization is disabled, but you can enable it with this CONFIGURE command:
CERTIFICATION SUMMARY
This chapter started with an overview of the advantages and disadvantages of using an RMAN recovery catalog over using only the control file for backup information. Although there is some extra work to maintain another database to store the recovery catalog information, this disadvantage is relatively minor compared to the advantages of ease of use and more robust recovery capabilities.
Next, assuming that you will eventually need and want a recovery catalog, you stepped through the process of creating a recovery catalog and registering one or more target databases with the recovery catalog. In addition, you learned how to include the metadata for backups created outside of RMAN (in the recovery catalog), further increasing the value of a central backup metadata repository.
Stored scripts, another feature available only with a recovery catalog, helps you automate some routine tasks consisting of many steps or commands, all stored in a single command. Stored scripts can be either local (specific to one database) or available to all databases registered in the catalog.
In the event of a lost or corrupted recovery catalog (which should never happen because you back up your recovery catalog as often as you back up your target database), you reviewed a few different disaster recovery scenarios and learned ways to lessen the potential impact of a full or partial loss of the recovery catalog.
To facilitate the division of labor and responsibility when you have more than one DBA in your organization, you can use the concept of virtual private catalogs. Setting up a virtual private catalog for each DBA in your organization is straightforward and restricts access to only databases for which the DBA is responsible, while at the same time keeping all database backup information in the same recovery catalog.
Finally, you were introduced to RMAN backup types and configuration settings, including how to persist RMAN settings, such as device types and channels, and you also learned how to ensure that the control file is backed up on a regular basis. For those of you wondering when you’ll get to start performing some real backups now that the groundwork is laid, the BACKUP command is explored in depth in the next chapter.
TWO-MINUTE DRILL
Identify Situations that Require RMAN Recovery Catalog
If your backups are simple and your database is not mission-critical, the control file is probably sufficient for your RMAN metadata.
If you have several databases to back up, and you want to use stored scripts, then a recovery catalog is highly recommended based on Oracle best practices.
Having a centralized metadata repository permits easy backup reporting because you can use one set of RC_ views in one database to query backup information.
Several useful RMAN commands such as BACKUP ... KEEP FOREVER are available only when you use a recovery catalog.
Create and Configure a Recovery Catalog
The three basic steps for creating a recovery catalog are 1) configure a new or existing database, 2) create the recovery catalog owner, and 3) create the catalog itself.
Only about 125MB of disk space is required for the initial deployment of a recovery catalog.
The predefined role RECOVERY_CATALOG_OWNER includes all privileges necessary to manage a recovery catalog, such as ALTER SESSION, CREATE SESSION, and CREATE TABLE.
You use the CREATE CATALOG command to create the recovery catalog.
You can use Enterprise Manager to persist recovery catalog credentials.
Synchronize the Recovery Catalog
The initial synchronization of the recovery catalog uses the target database control file.
Each database to be backed up needs to be registered with the recovery catalog using the REGISTER DATABASE command.
The target database must be in the MOUNT or OPEN state to register successfully with the recovery catalog.
You can use the DBNEWID utility (enter nid at the command line), to change the value of the DBID for a database. You can also change the database name as an additional option.
After changing the DBID for a database, you must reopen it with RESETLOGS, and then you should perform a full backup of the database.
You can unregister a database from a recovery catalog using the UNREGISTER DATABASE command.
You can catalog several types of backup files with RMAN: data file copies, backup pieces, control file copies, and archived redo log files.
One of many advantages to using a flash recovery area is that it makes it easy for you to recatalog all backup files in the area by using the CATALOG RECOVERY AREA command.
Manual resynchronization of the recovery catalog is required when the recovery catalog is unavailable during an RMAN backup. This applies if you want to catalog archived redo log files or you make physical changes to the target database.
Create and Use RMAN Stored Scripts
You create stored scripts with either the CREATE SCRIPT or CREATE GLOBAL SCRIPT command.
Local scripts are available only for the target database.
Global scripts are available for any target database or even when you are not connected to any target database.
You execute a global or local script within a RUN block.
You execute scripts with the EXECUTE [GLOBAL] SCRIPT command.
The substitution character & permits a default value that can be overridden when the script runs.
The LIST [GLOBAL] SCRIPT NAMES shows a list of the global or global and local scripts in the repository.
The PRINT command shows the contents of a global or local script.
You can use REPLACE [GLOBAL] SCRIPT to replace the contents of a global or local script.
DELETE SCRIPT deletes a script from the recovery catalog.
Back Up the Recovery Catalog
The recovery catalog database is backed up like any other database in your environment.
The recovery catalog should be in ARCHIVELOG mode.
The utilities expdp and impdp can create logical backups of the recovery catalog that can be used in a disaster recovery situation or to move the recovery catalog to another database.
Using transportable tablespaces is another way to move the recovery catalog to another database.
Use the DROP CATALOG command to drop a recovery catalog. Do not manually drop schemas and packages in the recovery catalog database.
You run the UPGRADE CATALOG command to support an RMAN client that is at a later version than the recovery catalog database.
Create and Use a Virtual Private Catalog
A virtual private catalog facilitates the separation of duties among several DBAs.
One or more virtual private catalogs share the same base recovery catalog.
You grant the RECOVERY_CATALOG_OWNER role to each Oracle user account that will own a virtual private catalog.
The base recovery catalog owner can grant permissions on existing registered databases to virtual private catalog owners using the GRANT CATALOG command.
Once you grant a user the RECOVERY_CATALOG_OWNER role, the user creates the virtual catalog with the CREATE VIRTUAL CATALOG command.
The virtual private catalog owner uses REGISTER DATABASE to register a new database, just as a base recovery catalog user would.
You can query the DBINC data dictionary view to determine the databases accessible to the virtual private catalog owner.
Configure Backup Settings
RMAN backups can be full or incremental.
Incremental backups can be level 0 or 1. Level 0 backups are full backups that you can use as part of a differential, incremental, or cumulative incremental level 1 backup strategy.
RMAN image copies are exact copies of datafiles. Using RMAN to make copies of datafiles has the additional advantage of checking for corruption in each block read.
RMAN can use backup compression to save space on the destination device, and RMAN automatically decompresses the backup during a recovery operation.
Using a flash recovery area for RMAN has two advantages: RMAN automatically names backup files in the flash recovery area, and it automatically deletes obsolete backup files when there is space pressure in the flash recovery area.
More than one database can use the flash recovery area.
The RMAN command SHOW ALL lists all persistent RMAN settings.
Use CONFIGURE CONTROLFILE AUTOBACKUP ON to ensure that a backup copy of the target database control file exists after each backup.
Allocate Channels to Use in Backing Up
Channels can be persisted with the CONFIGURE command or assigned within the RUN block using the ALLOCATE CHANNEL command.
Using DISK as the default device type does not require any channel allocation.
Configure Backup Optimization
RMAN uses backup optimization to skip backups of one or more files if identical files have already been backed up to disk or tape.
Backup optimization takes into account duplexing and retention policies before skipping a source file.
You set backup optimization in RMAN with the command CONFIGURE BACKUP OPTIMIZATION ON.
SELF TEST
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.
Identify Situations that Require RMAN Recovery Catalog
1. Which of the following are good reasons to use a recovery catalog instead of the target database control file? (Choose three.)
A. You can keep stored scripts in the recovery catalog.
B. You save space in the control file of the target database used for RMAN backup information.
C. A recovery catalog is easier to maintain than a control file in each target database.
D. The recovery catalog can report on the tablespaces and datafiles in the target database at any point in time since the recovery catalog was created.
E. A recovery catalog can be used to manage RMAN information for more than one database.
2. If you do not use a recovery catalog, what data dictionary or dynamic performance views must you query to retrieve RMAN backup information? (Choose the best answer.)
A. The V$ views on each target such as V$BACKUP_SET and V$DATAFILE_COPY
B. The RC_ views on each target
C. The DBA_ views on each target
D. V$CONTROLFILE
Create and Configure a Recovery Catalog
3. The net service name of your target database is DW and the net service name of your recovery catalog database is RCAT. The environment variable ORACLE_SID has a value of RCAT. Which of the following sets of commands will successfully create a recovery catalog?
A. connect catalog rman/rmanpass
create catalog;
B. connect catalog rman/rmanpass@rcat
create catalog@rcat;
C. connect catalog rman/rmanpass@dw
create catalog;
D. create catalog rman/rmanpass@rcat;
4. Which of the following roles should you grant to the recovery catalog owner? (Choose the best answer.)
A. RECOVERY_CATALOG
B. CATALOG_OWNER
C. RECOVERY_CATALOG_OWNER
D. DBA
Synchronize the Recovery Catalog
5. Which of the following does not occur when you register a target database with the recovery catalog database using the REGISTER DATABASE command?
A. The recovery catalog is synchronized with the structure of the database from the control file.
B. Information about manual tablespace backups is registered in the recovery catalog.
C. Data about recent backups is copied from the control file to the recovery catalog tables.
D. Metadata rows are created for the target database in the recovery catalog.
6. What is the difference between a partial and a complete recovery catalog resynchronization? (Choose two answers.)
A. A partial resynchronization occurs when RMAN records have been aged out of the target database’s control file because of the value of CONTROL_FILE_RECORD_KEEP_TIME.
B. A partial resynchronization uses the current target database control file and a full resynchronization uses a backup control file.
C. A full resynchronization uses the current target database control file and a partial resynchronization uses a backup control file.
D. A full resynchronization includes information about the database structure and not just recent backups.
Create and Use RMAN Stored Scripts
7. What is the difference between an RMAN local script and an RMAN global script?
A. A local script is available only for a single target database.
B. A global script references a list of commands in an external file.
C. A local script references a list of commands in an external file.
D. A global script can execute commands against many target databases simultaneously.
E. A local script is available only to the user that created it. A global script is available to all users.
8. You create and execute a stored local script using the following commands:
What happens when you run these commands?
A. The script does not run because it must be executed within a RUN block.
B. A full backup occurs and all previous backups and archived redo logs outside of the retention period or retention policy are deleted.
C. The script creation step fails because you must explicitly allocate one or more channels with a stored script.
D. The script does not run because you must specify a target database when you use a local script.
Back Up the Recovery Catalog
9. You have lost the most recent archived redo log files from the recovery catalog database as well as the tablespace containing the RMAN catalog. You can do an incomplete restore of the recovery catalog database to a point in time after the target databases were registered with the recovery catalog. What commands can you use to resynchronize the target database’s metadata and backup information with the recovery catalog database?
A. Use the CREATE CATALOG command to re-create the recovery catalog database.
B. Use the REGISTER DATABASE command to reregister the target database control file records.
C. Use the RESYNC CATALOG command to update the recovery catalog with the latest records from the target database’s control file and the CATALOG START WITH command to record any additional backups that are no longer in the target database’s control file.
D. Use both the CREATE CATALOG and the REGISTER DATABASE commands to resynchronize the target database with the recovery catalog.
10. Under what circumstances would you use the RMAN command UPGRADE CATALOG?
A. When you have made structural changes to the recovery catalog database
B. When you are using a version of the recovery catalog that is older than that required by the RMAN target database client
C. When you are using a version of the RMAN target database client that is older than required by the recovery catalog
D. When you have made structural changes to the target database
Create and Use a Virtual Private Catalog
11. You have created a virtual private catalog to separate your RMAN administration duties among several DBAs for 20 different databases. Which role must you grant to each virtual catalog owner to allow the person to access existing registered databases?
A. SELECT_CATALOG_ROLE
B. REGISTER_CATALOG_OWNER
C. VPC_OWNER
D. RECOVERY_CATALOG_OWNER
12. The virtual catalog database owner VPC1 has the RECOVERY_CATALOG_OWNER privilege on the database CATDB2 in addition to the RMAN REGISTER DATABASE privilege. Which of the following sets of commands will allow an 11g RMAN client to create a virtual catalog, register a new database DW, and create a full database backup?
Configure Backup Settings
13. You run the following RMAN command:
Under what conditions does RMAN back up the control file and the SPFILE? (Choose all that apply.)
A. When an RMAN backup completes
B. When you start RMAN
C. When you connect to a target database
D. When you back up the SYSTEM tablespace
E. When you run the command BACKUP CURRENT CONTROLFILE;
F. When any of the DBA passwords change
G. When you change the size of the flash recovery area
H. When you add a tablespace
14. Which of the following objects cannot be backed up by RMAN using the RMAN BACKUP command? (Choose all that apply.)
A. DATAFILE
B. DATABASE
C. INSTANCE
D. CURRENT CONTROLFILE
E. SPFILE
F. TABLESPACE
G. ARCHIVELOG
H. CONTROLFILE
I. REDOLOG
15. Identify the statements in the following list that are true about managing RMAN persistent settings. (Choose all that apply.)
A. SHOW ALL lists all current settings for the connected target database.
B. You can use the CONFIGURE...CLEAR command to set a configuration value to an empty string.
C. SHOW ALL shows the configuration values that apply to all target databases.
D. You can use the CONFIGURE...CLEAR command to set a configuration value to its default value.
E. SHOW ALL lists all RMAN settings that are different from the default value.
Allocate Channels to Use in Backing Up
16. What happens when you run the following RMAN commands?
A. A full database backup is created in the flash recovery area.
B. The database is backed up to all default channels configured outside of the RUN block plus the additional channel within the RUN block.
C. The command fails because you cannot use CONFIGURE within a RUN block.
D. The command fails because you cannot use BACKUP within a RUN block.
Configure Backup Optimization
17. You have configured backup optimization for your database using CONFIGURE BACKUP OPTIMIZATION ON. For which of the following commands will RMAN not skip a backup if the files are identical?
A. BACKUP DATABASE;
B. BACKUP TABLESPACE USERS;
C. BACKUP ARCHIVELOG ALL;
D. BACKUP BACKUPSET ALL;
SELF TEST ANSWERS
Identify Situations that Require RMAN Recovery Catalog
1. 
A, D, and E. Using a recovery catalog allows you to create and maintain stored scripts. In addition, it keeps a running history of all changes to the database tablespaces and datafiles since the recovery catalog was created. Finally, you can store recovery information for more than one database in a recovery catalog.
B is not a good reason to use a recovery catalog because the RMAN repository information is always stored in the control file even if you use a recovery catalog. C is also not a good reason, because a recovery catalog requires more setup and maintenance in addition to a backup of another database. Also, the control file is simpler to manage, and its size can be controlled with the parameter CONTROL_FILE_RECORD_KEEP_TIME. It is much simpler to export a copy of the control file whenever the database structure changes using ALTER DATABASE BACKUP CONTROLFILE TO TRACE.
2. A. When you do not use a recovery catalog, information about RMAN backups is available on each individual target in dynamic performance views such as V$BACKUP_SET and V$DATAFILE_COPY. These views are sourced from the target database control file.
B is wrong because the RC_ views exist only in the database containing the recovery catalog. C is wrong because the DBA_ views do not maintain RMAN information. D is wrong because V$CONTROLFILE contains only the locations of each copy of the target database’s control file.
Create and Configure a Recovery Catalog
3. A. The environment variable ORACLE_SID is set. Thus, the RMAN command CONNECT automatically uses the value of ORACLE_SID to connect to the recovery catalog.
B is wrong because you do not need to specify the name of the recovery catalog database in the CREATE CATALOG command. C is wrong because it creates the recovery catalog in the target database. D is wrong because you cannot combine the CONNECT CATALOG and the CREATE CATALOG commands.
4. C. The predefined role RECOVERY_CATALOG_OWNER includes the 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.
A and B are wrong because the RECOVERY_CATALOG and CATALOG_OWNER roles do not exist. D is wrong because it provides the recovery catalog owner with more system privileges than necessary.
Synchronize the Recovery Catalog
5. B. Any manual backups performed outside of RMAN or that were aged out of the target database control file before you create the recovery catalog must be manually registered with the recovery catalog.
A, C, and D are all steps that occur when you register a database with a recovery catalog.
6. B and D. A full resynchronization creates a control file snapshot and synchronizes database structure information as well as information about backups in the target database control file that are not in the recovery catalog. A partial resynchronization compares the target database’s control file directly with the control file.
A is wrong because RMAN records aged out of the control file can be added to the recovery catalog manually. C is wrong because a full resynchronization uses a copy of the control file (a control file snapshot) for its comparison. A partial resynchronization does not.
Create and Use RMAN Stored Scripts
7. A. A local script is available only to the database that was connected when the script was created.
B and C are wrong because both global and local scripts are stored in the recovery catalog. D is wrong because any script operates on one database at a time. E is wrong because both local and global scripts are available to any user that authenticates with the recovery catalog.
8. A. Stored scripts, whether they are local or global, must be run within a RUN block as follows:
B is wrong because a script must be enclosed in a RUN block. C is wrong because you can include a channel allocation or use the default channel in the RUN command containing the EXECUTE SCRIPT command. D is wrong because both local and global scripts apply only to the currently connected target database.
Back Up the Recovery Catalog
9. C. The RESYNC CATALOG command synchronizes the target database’s control file information with the recovery catalog database, and the CATALOG START WITH command adds any backup information that is no longer in the target database control file.
A is wrong because you do not need to re-create the recovery catalog, you just need to resynchronize it. B is wrong because the database itself is already registered with the recovery catalog. D is wrong because you do not need to re-create the recovery catalog or reregister the target database.
10. B. When the recovery catalog schema version is less than the RMAN client version, you must use UPGRADE CATALOG.
A and D are wrong because structural changes to either database means you should back up your control file, but this does not trigger a recovery catalog upgrade. C is wrong because you can use RMAN clients that are older than the recovery catalog database version, although some features of the newer RMAN client will not be available, such as flashback database.
Create and Use a Virtual Private Catalog
11. D. To allow access to a virtual private catalog, you must grant the role RECOVERY_CATALOG_OWNER as a SQL command to each user that will access a virtual private catalog.
A is wrong because the SELECT_CATALOG_ROLE allows access to a database’s data dictionary and does not control access to RMAN virtual catalogs. B and C are wrong because these roles do not exist in a default installation of the database.
12. D. To create the virtual catalog, you connect to the base catalog, create the virtual catalog, connect to the target database, register the database, and finally back it up. You need to create the virtual catalog only once, and each target database needs to be registered only once. Subsequent backup operations can occur after connecting to the base catalog and the target database.
A is wrong because the base catalog and virtual catalog are on the instance with the service name CATDB2, not the target database DW. B is wrong because EXEC CATOWNER.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG is only for pre-11g clients and must be run by the virtual catalog owner at a SQL< prompt. C is wrong because GRANT CATALOG FOR DATABASE DW TO VPC1 must be run by the base catalog owner and only if the database is already registered in the base catalog.
Configure Backup Settings
13. A, E, and H. RMAN backs up the current control file and the SPFILE (if you use one) after a successful backup, when you explicitly back up the current controlfile, and when the structure of the database changes.
B, C, D, F, and G are wrong. RMAN does not back up the control file under any of these circumstances.
14. C, H, I. C is cannot be backed up because RMAN backs up databases; an instance comprises the Oracle memory structures and cannot be backed up. H cannot be backed up because CONTROLFILE is not a valid option; you must use CURRENT CONTROLFILE to back up the control file. I cannot be backed up because you should never, ever back up the online redo log files.
A, B, D, E, F, and G can all be backed up and are therefore incorrect. All other objects listed, the current control file, the SPFILE, the entire database, an individual datafile, an individual tablespace, or one or more archived redo log files can be backed up by RMAN.
15. A and D. The SHOW ALL command shows all settings for the connected target; you can use CONFIGURE...CLEAR to reset a configuration value to its default.
B is wrong because CONFIGURE...CLEAR resets the configuration setting to its default value. C is wrong because SHOW ALL works only when you are connected to a target database. E is wrong since SHOW ALL lists all configuration values regardless of whether they have been changed from the default.
Allocate Channels to Use in Backing Up
16. C. You can use CONFIGURE only at the RMAN command prompt to set default values, and it cannot be used within a RUN block.
A is wrong because the CONFIGURE command cannot be used within a RUN block. B is wrong for the same reason; additionally, any channels allocated within a RUN block override the default channel. D is wrong since you can use BACKUP either as a standalone command or within a RUN block.
Configure Backup Optimization
17. B. Backup optimization is not used for backing up individual tablespaces.
A, C, and D are wrong. Backup optimization is used for all of these commands.