CHAPTER 23

Back Up with RMAN

Exam Objectives

• 63.1.1.1    Explain Oracle Backup and Recovery Solutions

• 63.1.2.1    Back Up and Recover a NOARCHIVELOG Database

• 63.1.3.1    Configure and Manage RMAN Settings

• 63.1.4.1    Create and Use an RMAN Recovery Catalog

• 63.1.5.1    Use Various RMAN Backup Types and Strategies

• 63.1.6.1    Perform Full and Incremental Backups

• 63.1.6.2    Manage Backups

• 63.1.7.1    Use Techniques to Improve Backups

Even though the list of exam objectives for this chapter is long, most of the objectives involve adding just one or two keywords to your BACKUP command. Using the Recovery Manager (RMAN) tool is straightforward, and with a little practice you will become familiar with all its functions.

Backup Theory and Basic Syntax

There are a few simple choices to be made when performing a database backup, including what you want to back up and how you will do it. Then to perform the backup, you must run the appropriate RMAN commands. It is possible to perform backups without using RMAN. Such techniques are known as user-managed backups as opposed to RMAN’s server-managed backups. User-managed backups are perfectly valid and fully supported but are not covered in the examinations because Oracle’s approved tool for backup and recovery is RMAN.

Using RMAN can be simple or somewhat complex. To reduce the complexity, most database administrators (DBAs) will make use of stored configuration parameters. These set defaults for all operations and means that complex jobs can be performed with simple commands.

Backup Concepts

The database on which backup or restore operations are to be carried out is known as the target. In some environments there will be many databases and therefore many RMAN targets. You will connect to each database in turn. Every backup of a target will have certain attributes:

•  Open or closed

•  Whole or partial

•  Full or incremental

•  To disk or to tape

•  Copy or backupset

Any combination of these attributes is possible, but depending on the environment and configuration, you may be limited to only a subset of these attributes. In all cases, the backup is accomplished by Oracle server processes launched in response to commands issued within the RMAN executable user process.

RMAN Architecture

The RMAN executable is a user process like any other. It logs on to an Oracle database (the target database) either locally using interprocess communication (IPC) or remotely using Transmission Control Protocol (TCP) and a database listener. Once connected, the user can issue commands to carry out backup and restore operations. These operations are performed by additional Oracle server processes launched as necessary, known as channels. A channel is a server process like any other, but its function is restricted to copying files.

A major feature of RMAN is its use of a repository. The RMAN repository consists of metadata regarding backups. This includes details of what has been backed up, where the backup files are, what archive logfiles exist, what persistent configuration settings have been made, and everything RMAN will ever need to understand the database and the backups such that restore and recovery operations can be fully automated. The repository exists in either one or two places. A copy of the repository is always stored on the target database controlfile. Relying solely on this can potentially have two issues. First, information can be stored for only a limited period. Specifically, this is the number of days specified by the CONTROLFILE_RECORD_KEEP_TIME instance parameter, which defaults to seven days. If you are using only the controlfile-based repository, you will probably want to adjust this to allow RMAN to “remember” information for a longer period. For example, to raise this period to a month, you’d use the following:

RMAN can also use a secondary storage location for the repository in the form of an Oracle database. This requires creating a schema in the database known as the RMAN catalog. The catalog should be created in a database used solely for this purpose. The catalog can record metadata for many targets and acts as a central repository of all backup information. When using a catalog, there is no effective limit to the time frame for which backup information can be stored. Using a catalog also enables some of the more advanced RMAN features.

An RMAN backup can be directed to a disk location or to a tape location. Backup to disk is always available and requires no configuration. To use a tape device, RMAN needs assistance from the hardware manufacturer. This is in the form of a dynamically linked library, provided (and almost certainly charged for) by the hardware vendor. For example, if you are going to use an automated tape library manufactured by IBM, you will need to buy IBM’s Tivoli Storage Manager agent for Oracle. This code will allow RMAN to drive the tape library. Within the RMAN environment, there is minimal difference when using tape devices. RMAN conceals all the complexity of managing third-party hardware from the DBA.

RMAN can create two types of backup: image copies and backupsets. An image copy backup generates an output file that is byte-for-byte identical to the input file. A backupset is a more intelligent structure. It can combine several input files into one output file, it will not include blocks of the input files that have never been used, it can be compressed and encrypted, and it can be divided into multiple pieces. The pieces are the physical files that make up the backupset.

Backing Up in One Page

An open (aka hot or inconsistent) backup is performed while the database is in use. It is impossible to perform an open backup unless the database is in archivelog mode. This is because any backup of an open file will be inconsistent. It will take an appreciable period of time to read the file and write the copy, and during this time the file is being updated. Therefore, the copy will not represent a stable version of the file. In archive log mode, this is not a problem because the redo log stream will have a record of all changes applied to the file in the form of the change vectors that were applied to the Oracle blocks while the backup was in progress. If it is ever necessary to restore the file from the backup, the information in the redo stream can be used to make the inconsistent backup usable by applying these changes. If the database were not in archivelog mode, the redo from the time the backup was made would not be available. A closed (aka cold or consistent) backup is performed while the database is in mount mode. The controlfile must be mounted for RMAN to have access to its repository. Closed backups are consistent; the datafiles are stable. Closed backup is the only type of backup possible if the database is in noarchivelog mode.

A whole backup is the entire set of datafiles and the controlfile. A partial backup is a subset of the database. Whole backup is the only type of backup possible in noarchivelog mode. This is because to open a database, all datafiles must be consistent up to the same system change number (SCN). If the backup consists of several partial backups, each partial backup will be at a different SCN, and following a restore, redo data is required to bring all the backups up to the same SCN. This redo data would not be available in noarchivelog mode.

A full backup contains every used block of every file. An incremental backup has only those blocks that have been changed since the last backup. An incremental backup strategy must start with a full backup, followed by as many incrementals as you like, but a restore will always require first restoring the full backup (known as the level 0 backup) and then applying the incremental backups to bring the files up to date. Only after a new level 0 backup is taken can any of the previous backups be discarded.

RMAN Basic Syntax

The RMAN executable connects to the target database and (optionally) to a catalog database, if it has been configured. Consider these commands, executed from an operating system prompt:

All three will log on to a target database as user SYS with the SYSDBA privilege. In the first case, the target will be a local database instance running on the same machine, identified by the ORACLE_SID environment variable, and the user is authenticated by their operating system account. The second example also connects to a local database instance but authenticates using the database password file. The third example connects to a remote database across a network using a tnsnames service name and will also use password file authentication.

Once connected, you can issue ad hoc SQL commands against the target database just as you would within a SQL*Plus session (though the display of results may not be the same, and some SQL*Plus commands, such as those for formatting columns, are not available) or issue RMAN commands for backup and restore operations.

Backing Up in Noarchivelog Mode

Backing up in noarchivelog mode can be accomplished only in mount mode. Consider the example in Figure 23-1.

Figure 23-1    A closed, whole, full backup with RMAN

In the figure, from a Windows operating system prompt the user launches the RMAN executable, connecting to a local database using operating system authentication. Once connected and at the RMAN> prompt, the user shuts down the database with the IMMEDIATE option and restarts in mount mode. Then the BACKUP DATABASE command (which is run completely on defaults) automatically launches a channel process named ORA_DISK_1 that will generate backupsets on disk, identifies the five datafiles that make up the database, backs them up into a single piece located in the Fast Recovery Area, and backs up the controlfile and the spfile into a second backupset. Then the user opens the database and exits from the tool. This is an example of a whole-closed full backup. Incremental backup is a possibility, but all noarchivelog mode backups must be whole and closed.

Backup Possibilities in Archivelog Mode

The following are some simple backup commands:

A partial backup specification can be a list of one or more datafiles (identified either by filename or by file number), one or more tablespaces, or the controlfile. A whole backup is the entire database. Archive logfiles can (and should) also be backed up, meaning either all of the archive logfiles or a subset of the archive logfiles. It is also possible (as in the example following) to remove the archive logfiles as they are backed up. The default backup destination is to disk, specifically, to files (the backup pieces of backupsets) in the Fast Recovery Area.

Usually single-line commands will not be sufficient. To chain several commands together, you must group them into a block. A block is preceded by RUN and enclosed with {}. Consider the example in Figure 23-2.

Figure 23-2    An open, whole, full backup—including archive logfile backup and deletion

The first two commands in the run block are ALLOCATE CHANNEL. Allocating a channel launches a server process. Each channel needs a name (just an arbitrary string, in this example D1 and D2) and must specify whether it will be using tape or disk as the backup destination (in the example, disk). Launching multiple channels enables parallelism for the backup. RMAN will distribute the workload across the channels, as shown later in the output: Datafiles 3, 1, and 6 are being backed up by channel D1, while channel D2 backs up datafiles 7 and 5. The third line in the run block specifies a whole database backup, using FORMAT to nominate the output piece name. The fourth line specifies that all the archive logfiles should be backed up and deleted. The FORMAT specification includes %U. This is a variable that will be expanded into a name that includes an eight-character random string to ensure that if the block is run many times, different piece names will always be generated. The type of backup is COMPRESSED BACKUPSET. Compression will generally not only reduce the size of the backup pieces but also improve the speed of the operation. In most circumstances, the bottleneck in backup is writing the backup pieces, and compression means that there is much less data to write.

The default backup type is a backupset. The alternative is the image copy. To create copies, use commands such as these:

The first command shown copies one datafile to a named destination. The second command copies the entire database to the default destination, which is the Fast Recovery Area.

Any backup command (whether creating backupsets or image copies) can be parallelized if it is executed within a run block that launches multiple channels. Note that the parallelism is only within a backup command, not across backup commands. So in Figure 23-2, the backup of the database is parallelized, and only when that is completed will the archive logfiles be backed up, again by two processes in parallel. If multiple files are specified for one channel, the files are read concurrently and interleaved in the backupset, but there is no parallelism at that level; the channel process cycles through its list of files, reading blocks from each in turn.

Backing up to tape rather than to a disk destination requires configuring the Media Management Layer (MML). This is the dynamic link library provided by the hardware manufacturer and will be product specific. Then within RMAN, you must launch tape channels. For example:

This block will launch two tape channels (the SBT keyword stands for System Backup to Tape and instructs RMAN to link the MML library into the channel process) that will back up the database to the tape library. You would usually relate the number of channels to the number of tape drives in the library. In most cases, using tape devices is considerably more complicated than this, with many platform-specific options that must be specified.

Persistent RMAN Settings

RMAN run blocks (and stored scripts) can get quite long and awkward, if the defaults are not adequate. The ability to store persistent configuration settings lets the DBA modify the defaults. They can then run simple commands, which RMAN will automatically modify at run-time.

Setting and Clearing Default Values

To see the default settings, use the SHOW ALL command. For example:

Consider these defaults in order:

•  RETENTION POLICY specifies what backups RMAN should attempt to create and when they can be deleted. The default is one copy of every file.

•  OPTIMIZATION determines whether RMAN should back up files on request, even if sufficient backups already exist. The default is to back them up anyway.

•  DEFAULT DEVICE TYPE TO DISK means that unless directed otherwise, RMAN will launch only disk channels and will not write to tape.

•  CONTROLFILE AUTOBACKUP OFF prevents RMAN from automatically backing up the controlfile as part of any other backup operation.

•  AUTOBACKUP FORMAT generates a name and location for the controlfile autobackups, if they have been enabled.

•  DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET means that by default only one channel will be launched when performing a backup to disk and that the backup will be to an uncompressed backupset.

•  BACKUP COPIES specifies how many copies of backupsets should be generated when backing up datafiles and archive logfiles.

•  MAXSETSIZE can restrict the size of each backupset. If this size is reached, the backupset piece(s) will be closed, and the backup will continue into a new backupset.

•  ENCRYPTION of backupsets is disabled by default.

•  COMPRESSION (if requested) will use the BASIC algorithm, which is license free.

•  RMAN OUTPUT controls how long to keep the results of an RMAN job in tables in the RMAN repository.

•  ARCHIVELOG DELETION POLICY allows RMAN to delete automatically archivelogs that are no longer needed, according to various criteria.

•  SNAPSHOT CONTROLFILE specifies a name and location to be used for a temporary copy of the controlfile created as part of the controlfile backup mechanism.

When designing a backup strategy, an example of the requirements could be as follows: It must always be possible to restore the database to any time in the last two weeks; do not create any more backups than are needed to achieve this goal; backups will go to disk, using degree of parallelism of four channels; the controlfile must always be included with any backup; backups will be as compressed backupsets, stored in the directory c:db_backups; backupset pieces will be named according to the name of the database, the date of the backup, and a unique string; and archivelogs will be deleted when they have been backed up to disk twice. To configure this requirement, these are the commands to run:

Using SHOW ALL will then display the new values. These two simple commands are now all that is necessary to meet the requirement:

Persistent configuration settings are configured for each target database and stored in the RMAN repository, specifically, in the target database’s controlfile and the recovery catalog if one has been created. To return them to the defaults, connect to the target and issue CLEAR commands.

Using a Retention Policy

Backups can be automatically retained and managed using a recovery window or using 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 you are using a Fast Recovery Area and disk space is needed for new backups.

In contrast, a redundancy retention policy directs RMAN to retain the specified number of backups. 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 the Fast Recovery Area is used. Otherwise, you can use the DELETE OBSOLETE command to manually remove 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. By default, the retention policy is a single copy (with the retention policy set to 1). You can set the retention policy to two copies using the following RMAN command:

The following example sets the retention policy to a recovery window of four days:

Oracle best practices recommend using a recovery window (a period of time in which it is possible to uncover any problems with the database, such as an inadvertently dropped table or deleted rows in a table) and performing a point-in-time recovery at just before the error occurred.

In some environments, you may want to disable the retention policy completely. This is useful in an environment where a backup system outside of RMAN stores the disk backups to tape and deletes them. As a result, RMAN does not need to decide when a backup is obsolete, and therefore no retention policy is needed. As a result, the details of RMAN backups are maintained up to the time specified by the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. Here is how you can disable the retention policy:

Format Specifiers

Usually, you will want to automate the naming of backupset pieces. This will allow you to run the same scripts repeatedly, generating different output filenames every time. You will not know the names (though you can decode them), but RMAN will. This is an important part of automating the backup process. To generate names, configure persistent format specifiers, using a combination of literals (such as directory names) and variables. The variables are as follows:

•  %d    Database name.

•  %e    Archived log sequence number.

•  %f    Absolute file number.

•  %F    Combines the database identifier (DBID), day, month, year, and sequence number, separated by dashes.

•  %c    Copy number for multiple copies in a duplexed backup.

•  %I    DBID.

•  %N   Tablespace name padded to eight characters.

•  %t    Backupset timestamp.

•  %p    Piece number within the backupset.

•  %s    Backupset number.

•  %t    Backupset timestamp.

•  %u    In effect, eight random characters. This is derived from the backupset number and the time.

•  %U   System-generated unique filename (the default). For a backupset, it is equivalent to %u_%p_%c; for a datafile image copy, it is data-D-%d_id-%I_TS-%N_FNO-%f_%u; for an archivelog image copy, it is arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u; and for a controlfile image copy, it is cf-D_%d-id-%I_%u.

Exercise 23-1: Configure RMAN and Perform a Backup    For this exercise, it is assumed that the database is in archivelog mode. Should it not be, complete the exercises in Chapter 22.

1.  Connect to the database using the RMAN executable client, from the operating system command line.

2.  Show the configured parameters. They should all be on their defaults.

3.  From the RMAN prompt, set some parameters as you might on a production system. When nominating the directory for the default backup destination, be sure to nominate a directory on which the oracle user has full privileges.

4.  Back up the database and archivelogs.

Observe the automatic channel allocation and the manner in which files are apportioned to channels, the filenames of the output pieces, and the autobackup of the controlfile and spfile. Note that the deletion of archive logfiles does not occur until you run the archive logfile backup command a couple more times.

5.  Override the configured defaults.

Run a backup that does not permit RMAN to use the configured defaults by specifying some values and using a run block.

Note the names of the output files and compare their sizes with each other and with the source datafile.

Some Advanced RMAN Capabilities

To get the best out of RMAN, most sites will want to use a recovery catalog for the RMAN repository. While not essential, a catalog enhances RMAN’s capabilities significantly. RMAN has many other backup capabilities beyond the basic functionality described so far.

The Recovery Catalog

If you manage more than one database in your environment and you want to keep your recovery information for a longer time than CONTROLFILE_RECORD_KEEP_TIME, then you need a recovery catalog to store the RMAN repository. A single recovery catalog can store RMAN information for a virtually unlimited number of target databases.

Using stored scripts is another reason to use a recovery catalog; you cannot store scripts in the target database’s controlfile. 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, the RC_ views, such as RC_ARCHIVED_LOG, RC_BACKUP_FILES, and RC_DATABASE, are created in the recovery catalog database to retrieve metadata for all target databases. Otherwise, when you’re using the target database controlfile, you must connect to each target database separately and query the V$ views based on the target database’s controlfile.

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.

Configure the Recovery Catalog Database

Connect to the repository database (in this case the RCAT 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, you 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

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.

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 controlfile to the recovery catalog; however, a few operations require you to update the metadata manually in the recovery catalog.

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 connects 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:

In some situations, you need to resynchronize the metadata in the target database’s controlfile 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 controlfile. RMAN always records backup information in the controlfile even when the recovery catalog is unavailable!

In addition, you may perform infrequent backups and rely on archived redo logfiles for a recovery scenario. This is not a problem per se, but the list of recent archived redo logfiles 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 controlfile 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:

Create and Use RMAN Stored Scripts

Stored scripts help you automate repetitive groups of RMAN commands. The scripts are stored in the recovery catalog. A stored script can be tied to a single target database or be visible to all target databases registered in the recovery catalog.

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 (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 logfiles:

If you wanted the script to be available to only 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:

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 like you would in a SQL*Plus script.

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:

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.

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.

Incremental Backups

An incremental backup can be one of two types: level 0 or level 1. A level 0 incremental backup includes all blocks in the specified datafiles except for blocks that have never been used. A level 0 backup is physically identical to a full backup of the same datafiles, except that a full backup cannot be used in an incremental backup strategy—it stands alone. A level 1 backup can be one of two types: either a differential backup that backs up changed blocks since the last backup at level 0 or level 1 or a cumulative backup that backs up all changed blocks since the last level 0 backup. A level 0 backup can be either a backupset or an image copy; a level 1 can be only a backupset.

You use the following keywords in the RMAN BACKUP command to specify an incremental level 0 or level 1 backup:

You’ll learn how to set up an incremental backup strategy for the USERS tablespace in the following sections.

Level 0 Incremental Backups

A level 0 backup includes all blocks in a database object except for blocks that were never used above the high water mark (HWM). Subsequent level 1 backups use the most recent level 0 backup as the base for comparison when identifying changed blocks.

How often you perform a level 0 backup depends on how much the database object, such as a tablespace, changes between backups. A tablespace containing tables that are completely replaced on a weekly basis would most likely have more frequent level 0 backups than a tablespace containing tables that your applications change infrequently—for example, only 5 percent of the table’s rows every week, but the changes might depend on the block distribution of those rows.

In this example, you perform the first level 0 backup of the USERS tablespace in your incremental backup strategy:

Subsequent level 1 backups will use this backup as the starting point for identifying changed blocks.

Differential Incremental Backups

A differential backup is the default type of incremental backup that backs up all changed blocks since the last level 0 or level 1 incremental backup. Again using the USERS tablespace, here’s how you perform an incremental backup:

Cumulative Incremental Backups

Cumulative incremental backups back up all changed blocks since the last level 0 incremental backup. You perform a cumulative incremental level 1 backup the same way you perform a differential level 1 backup, except that you specify the CUMULATIVE keyword, as in this example:

The decision whether to use a cumulative or differential backup is based partly on where you want to spend the central processing unit (CPU) cycles and how much disk space is available. Using cumulative backups means that each incremental backup will become progressively larger and take longer until another level 0 incremental backup is performed. This can be beneficial in that only two backupsets will be required during a restore and recovery operation. On the other hand, differential backups record only the changes since the last backup, so each backupset might be smaller or larger than the previous one, with no overlap in data blocks backed up. However, a restore and recovery operation can take longer if you have to restore from several backupsets instead of just two.

Exercise 23-2: Take an Incremental Backup    In this exercise, you will investigate the use of incremental backups.

1.  Connect to the database using the RMAN executable client, from the operating system command line.

2.  It is not possible to perform a level 1 backup if there is no level 0. So far, all you have is a full backup. Attempt to perform a level 1 backup.

3.  Study the output of step 2. What type of backup was carried out?

4.  Repeat the command from step 2. What type of backup do you get this time?

Other Capabilities

RMAN provides a number of options to make multiple copies of your backup simultaneously, to create backups of your existing backupsets, and to skip unnecessary backups of read-only tablespaces. As your database grows in size, you inevitably have some really big datafiles that will take a long time to back up as part of a full database backup if backed up as a whole. Therefore, RMAN supports multisection backups so that a large datafile can be backed up in pieces in parallel. Archival backups give you the flexibility to take a snapshot of the database and retain it indefinitely or for a specific period of time. Lastly, read-only tablespaces may require special consideration.

Creating Duplexed Backupsets

To make multiple backups of the same backupset simultaneously, you can configure RMAN to make up to four duplexed copies of each backup piece. As with most RMAN commands, you can specify a default value for the COPIES parameter using the CONFIGURE command, as in this example:

Duplexing has a few restrictions. You cannot duplex backups to the fast recovery area, and you cannot duplex image copies—only backupsets. For duplexed disk backups, you specify multiple locations for a backup using the FORMAT clause. You can specify multiple locations either in the BACKUP command or when setting default values for device type DISK in the CONFIGURE command.

In this example, you back up the USERS tablespace to two different disk locations simultaneously:

Note that even though you have the same format for each copy of the backupset, RMAN’s format specifier %U will generate unique names for each piece.

Creating Backups of Backupsets

One option for creating a second copy of a backup is to create a backup of existing backupsets. If your backupsets are on disk (you cannot back up existing backupsets that are on tape), you can use the BACKUP . . . BACKUPSET command to copy all backupsets on one disk to another disk or to tape. This command copies all existing disk-based backupsets to the default tape device and channel:

If you want to keep recent backupsets on disk and older backupsets on tape, you can use the COMPLETED and DELETE INPUT options. In the following example, all backupsets older than two weeks are backed up to tape and deleted from the disk:

Backing Up Read-Only Tablespaces

As you might expect, backing up a read-only tablespace needs to happen often enough to satisfy the retention period configured in RMAN. You can force RMAN to skip a read-only tablespace by using the SKIP READONLY option of the BACKUP command. If you have configured RMAN for backup optimization, RMAN backs up read-only tablespaces only when there are not enough backups of the tablespace to satisfy the retention policy.

Use of read-only tablespaces may be particularly important in a data warehouse environment, where a high proportion of the data is static. Careful use of partitioning (typically range partitioning based on date) may mean that many table segments (and index segments, if the indexes are locally partitioned) can be moved to read-only tablespaces, hugely reducing the time and space needed for backup.

Creating Archival Backups

By default, RMAN keeps your backups and archived logfiles not only to satisfy the configured retention policy but also to provide a mechanism to restore your database to any point in time between the backup and the present. RMAN uses a combination of full backups, incremental backups, and archived redo logfiles.

In certain situations, you may want only a snapshot of the database at a certain point in time for archival or regulatory purposes. This causes two complications with the default RMAN configuration. First, your snapshot will most likely fall outside of your retention policy, and you certainly don’t want your yearly database snapshot to disappear before the end of the week. Second, you don’t want RMAN to maintain one, two, or more years’ worth of archived redo logfiles if you are not going to restore your database to a point in time between the snapshot and the current time.

RMAN addresses the need for a database snapshot by supporting an archival backup. If you label a backup as an archival backup, RMAN does not consider the backup to be obsolete using the configured retention policy; instead, RMAN marks an archival backup as obsolete after the amount of time you specify. Alternatively, you can specify that RMAN keep the archival backup indefinitely.

A restriction for archival backups is that you cannot use the fast recovery area to store an archival backup. If you have a fast recovery area configured, you will have to use the FORMAT parameter to specify an alternative disk location for the backup. Additionally, a tape device might be the best option for long-term storage of archival backups.

This example creates an archival backup to be retained for one year using the KEEP UNTIL clause:

Since the RPT12C database has a fast recovery area defined, you use the FORMAT clause to specify a location in which to store the archival backup. Note also that RMAN backs up any archived logs, which would be required to use the backup in a possible future recovery scenario.

Alternatively, you can perform the same backup but retain it indefinitely.

In some situations, you might want to change the status of a backup. For example, you might want to change an archival backup’s retention period, change an archival backup to a standard backup, or change a consistent backup to an archival backup. As you might expect, you can use the CHANGE command to accomplish this task. Although the CHANGE command has many other uses (such as to change the availability of a backup or to change the priority of failures in the database), the CHANGE command in relation to archival backups is covered here.

This example changes the backup created earlier with the tag SAVEFOREVER to fall under the existing retention policy instead:

Depending on the retention policy and the other older or newer backups for this database, the backup could be deleted the next time RMAN starts. The backup could be retained longer if the configured retention policy needs this backup to fulfill the retention policy.

You can also use the CHANGE command to change all backups of a certain type. For example, if you want to remove the archive flag from all image copies of the database, you use the NOKEEP parameter.

Creating a Multisection Backup

Creating a multisection backup is easy, but you must specify the section size with each BACKUP command. In addition, you can run the RMAN VALIDATE command by section. New data dictionary views, both the V$ and RC_ views, help you to identify which backups are multisection and how many blocks are in each section of a multisection backup.

To create a multisection backup, you add the SECTION SIZE parameter to the BACKUP command. The section size can be specified in kilobytes, megabytes, or gigabytes. Here is the general syntax for specifying a multisection backup:

In this example HR database, the USERS tablespace is approximately 250MB, and you want to back it up with a section size of 100MB:

This backup created three backup pieces; the first two were 100MB each, and the third piece was approximately 50MB, which is the remainder of the datafile. Multisection backups permit parallelism for the backup of a single datafile. If the operation is performed by multiple channels (as in the previous example), then sections will be read and written concurrently.

Compressing Backups

In addition to skipping unused blocks during a backup, RMAN can also apply a compression method to the used blocks in a backup when you specify the COMPRESSED parameter with one of four values:

•  BASIC    Similar to MEDIUM compression but uses more CPU

•  LOW    Fastest but lower compression ratios

•  MEDIUM    Moderate CPU usage; good for network bandwidth constraints

•  HIGH    Most CPU usage; ideal for network bandwidth constraints

The default compression level is set to BASIC.

All compression methods except for BASIC require the Advanced Compression option.

The HIGH algorithm, as you might expect, creates much smaller backups but requires more CPU time to compress the blocks. If not too many other server processes are demanding CPU resources when your backups run, use MEDIUM or HIGH. On the other hand, if a lot of disk space is available and the network path from the database to your backup location is not congested, it might take less time overall not to use compression.

Regardless of what compression method you use, restoring a compressed backup requires no knowledge of the compression method used during the original backup. RMAN automatically detects the compression method used and decompresses accordingly.

Verifying that the Repository Is Up to Date

The RMAN repository is crucial for the automation of backup and restore operations. It is therefore important that it should be accurate: that the backupsets and archive logfiles that are registered in the repository do in fact exist. When a backup is made or an archive logfile is created following a log switch, this information is, of course, registered automatically. If a backup piece or an archive logfile is subsequently removed by an operating system utility rather than by an RMAN operation, the repository will no longer be correct. A typical reason for this sort of event is that the files are stored on a device such a tape library that has its own automatic file deletion policy. This script will first perform a reality check with CROSSCHECK commands, and then delete references to files that no longer exist with the DELETE EXPIRED command:

The CROSSCHECK commands pass through the repository checking whether files registered within it do in fact exist. If any files are found to be missing, they are flagged as being EXPIRED. The DELETE EXPIRED command removes the detail of any expired files from the repository. If there is any possibility that files could be removed without RMAN's knowledge, it is important to run a maintenance script such as that above regularly in order to update the repository.

Two-Minute Drill

Create Consistent Database Backups

•  Consistent (aka closed or cold) backups are taken by RMAN when in mount mode.

•  A full closed backup is the complete set of datafiles plus the controlfile.

Back Up Your Database Without Shutting It Down

•  Open (aka hot) backups are taken by RMAN while the database is in use.

•  Open backups are possible only if the database is running in archivelog mode.

•  Archive logfiles must also be backed up or an open backup of the database will be useless.

Create Incremental Backups

•  A level 0 incremental backup consists of the whole datafile and can be used as the base for subsequent level 1 backups.

•  A level 1 incremental backup consists of all blocks changed since the last level 1 backup or the level 0 backup if no level 1 has yet been taken.

•  A level 1 cumulative backup consists of all blocks changed since the last level 0 backup.

Automate Database Backups

•  Enterprise Manager can schedule automatic backups.

•  Scheduled backups use RMAN, invoked by the Enterprise Manager agent.

Manage Backups and the RMAN Repository

•  RMAN uses a repository. This is stored in the target database controlfile and (optionally) in a recovery catalog database.

•  The repository stores information regarding all backups that have been made and is vital for automating restore and recovery operations.

•  The repository can be written out to a catalog database, which permits long-term storage of backup metadata.

•  The catalog schema is created and owned by a catalog owner who must be granted the RECOVERY CATALOG OWNER role.

Use Various RMAN Backup Types and Strategies

•  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 fast recovery area for RMAN has two advantages: RMAN automatically names backup files in the fast recovery area, and it automatically deletes obsolete backup files when there is space pressure in the fast recovery area.

•  More than one database can use the fast 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 controlfile exists after each backup.

Perform Full and Incremental Backups

•  RMAN backups are either backupsets or image backups.

•  Backupsets can be created only by RMAN and can be read only by RMAN.

•  The FORMAT clause of the BACKUP command specifies the substitution variables for the destination backup filename.

•  You can create image copies of datafiles, archived redo logfiles, and controlfiles.

•  Image copies can be written only to disk.

•  You can use the SWITCH command to quickly and easily switch between a datafile and its image copy during a recovery operation.

•  A whole-database backup includes all datafiles plus the controlfile.

•  A full backup of a datafile is a logical subset of a whole-database backup.

•  A full backup cannot be used as the basis for an incremental backup strategy.

•  An incremental backup is level 0 or level 1.

•  An incremental level 0 backup can be used as the basis for an incremental backup strategy.

•  Differential backups back up all changed blocks since the last level 0 or level 1 incremental backup.

•  Cumulative incremental backups back up all changed blocks since the last level 0 backup.

•  An archival backup is a snapshot of the database at a certain point in time created to satisfy archival or regulatory purposes.

•  Archival backups make it easy to migrate a copy of the database to another system without affecting the retention policy of the original database.

•  To create an archival backup, you specify either the KEEP UNTIL TIME or KEEP FOREVER option in the BACKUP command.

•  An RMAN archival backup also includes any archived logs required to use the backup in a recovery scenario.

•  You can use the CHANGE command to change the status of an archival backup.

•  Multisection RMAN backups can significantly reduce the time it takes to back up large datafiles to multiple destinations.

•  You can run the VALIDATE command in multisection mode.

•  The SECTION SIZE parameter determines the size for each section of a file to be read in a multisection backup. Sections can be read in parallel.

•  RMAN can compress backups of used blocks using four compression levels: BASIC, LOW, MEDIUM, and HIGH.

•  All compression methods except for BASIC require the Advanced Compression option.

Use Techniques to Improve Backups

•  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.

•  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

1.  What file types can be backed up by RMAN? (Choose all correct answers.)

A.  Archive logfiles

B.  Controlfile

C.  Online logfiles

D.  Password files

E.  Permanent tablespace datafiles

F.  Server parameter files

G.  Static parameter files

H.  Temporary tablespace tempfiles

2.  Why are RMAN backupsets smaller than RMAN image copies? (Choose the best answer.)

A.  They always use compression.

B.  They always skip unused blocks.

C.  They never include tempfiles.

D.  They can be written directly to tape.

3.  Which of the following statements is correct about RMAN offline backup? (Choose all correct answers.)

A.  The database must be in NOMOUNT mode.

B.  The database must be in MOUNT mode.

C.  The backup will fail if the shutdown mode was SHUTDOWN IMMEDIATE.

D.  Noarchivelog databases can be backed up only offline.

E.  Archivelog databases cannot be backed up offline.

F.  Offline backups can be incremental.

4.  You need to back up the controlfile while the database is open. What will work? (Choose the best answer.)

A.  The controlfile can be included in an RMAN backupset but not backed up as an image copy.

B.  The ALTER DATABASE BACKUP CONTROLFILE TO TRACE command will make an image copy of the controlfile.

C.  You cannot back up the controlfile while it is in use—it is protected by multiplexing.

D.  None of the above.

5.  You are setting up an incremental backup strategy. Which of these statements is correct? (Choose the best answer.)

A.  Before running an incremental level 1 backup, you must run an incremental level 0 backup.

B.  Either a full backup or an incremental level 0 backup can be the basis for an incremental level 1 backup.

C.  When restoring and recovering with incremental backups, archive logfiles are not needed.

D.  You cannot make an incremental backup of a database in NOARCHIVELOG mode.

E.  Running an incremental level 1 backup will automatically perform an incremental level 0 if none exists.

6.  What processes must be running if an RMAN backup scheduled within the Oracle environment is to run? (Choose all correct answers.)

A.  The database instance must be started.

B.  The Cloud Control management server must be running.

C.  The Enterprise Manager agent must be running.

D.  The operating system scheduler must be running.

7.  What is true about the crosscheck command? (Choose the best answer.)

A.  Crosscheck will check the validity of the backup pieces.

B.  Crosscheck will delete references to files that no longer exist.

C.  Crosscheck will verify the existence of backupset pieces.

D.  Crosscheck works only with backupsets, not image copies.

8.  If the volume of data in the fast recovery area has reached the limit defined by DB_RECOVERY_FILE_DEST_SIZE, what will happen when RMAN attempts to write more data to it? (Choose the best answer.)

A.  If AUTOEXTEND has been enabled and the MAXSIZE value has not been reached, the fast recovery area will extend as necessary.

B.  The operation will fail.

C.  This will depend on whether warning and critical alerts have been enabled for the fast recovery area.

D.  RMAN will automatically delete OBSOLETE backups.

E.  RMAN will automatically delete EXPIRED backups.

9.  You run the following RMAN command:

RMAN> configure controlfile autobackup on;

Under what conditions does RMAN back up the controlfile 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 fast recovery area

H.  When you add a tablespace

10.  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

11.  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.

12.  Which of the following is the default substitution variable for the FORMAT clause of the BACKUP command? (Choose the best answer.)

A.  %t

B.  %d

C.  %u

D.  %U

E.  %I

13.  Which of the following are candidates for RMAN image copies? (Choose two answers.)

A.  Datafiles

B.  Archived redo logfiles

C.  Online redo logfiles

D.  Password files

14.  You run the following command to create a whole-database backup: RMAN> backup as copy database spfile plus archivelog delete input; What does the DELETE INPUT clause do? (Choose the best answer.)

A.  After the backup completes, RMAN deletes the archived logfiles from all archived logfile destinations except for the fast recovery area.

B.  After the backup completes, RMAN deletes the archived logfiles from the fast recovery area only.

C.  After the backup completes, RMAN deletes the archived logfiles from the fast recovery area and any other archived logfile destinations.

D.  RMAN deletes all obsolete copies of database backups after the backup completes.

15.  What is the difference between a full backup and a whole-database backup? (Choose the best answer.)

A.  A whole-database backup can be used as the basis for an incremental backup strategy, but a full database backup cannot.

B.  A full database backup can be used as the basis for an incremental backup strategy, but a whole-database backup cannot.

C.  A whole-database backup can be only an image copy. A full backup can be an image copy or a backupset.

D.  A full backup consists of a backup of one or more datafiles or tablespaces, whereas a whole-database backup contains all datafiles for all tablespaces plus the controlfile.

16.  What is true about a level 0 incremental backup? (Choose all correct answers.)

A.  A level 0 backup includes all blocks in a datafile, including blocks that have never been used.

B.  A level 0 backup includes all blocks in a datafile, except for blocks that have never been used.

C.  A level 0 backup can be used with a level 1 cumulative backup.

D.  A level 0 backup can be used with a level 1 differential backup.

E.  A level 0 backup of a datafile has additional information that differentiates it from a full backup of the same datafile.

17.  Identify the true statement regarding incremental and differential backups. (Choose the best answer.)

A.  A differential backup is the default type of incremental backup and backs up all changed blocks since the last level 0 or level 1 incremental backup.

B.  A cumulative backup is the default type of incremental backup and backs up all changed blocks since the last level 0 or level 1 incremental backup.

C.  A differential backup is the default type of incremental backup and backs up all changed blocks since the last level 0 incremental backup.

D.  A cumulative backup is the default type of incremental backup and backs up all changed blocks since the last level 1 incremental backup.

18.  When you want to create a duplexed backupset, what is the maximum number of copies of each backup piece you can create with one BACKUP command? (Choose the best answer.)

A.  Two for disk locations and four for tape destinations.

B.  A maximum of four.

C.  Two for tape locations and four for disk locations.

D.  The maximum is limited only by the number of destination disks or tape drives.

19.  Identify the true statements regarding archival backups. (Choose all correct answers.)

A.  Archival backups can be retained indefinitely.

B.  You can drop an archival backup using the CHANGE . . . DROP command.

C.  Archival backups include all archived redo logs from the archival date to the present.

D.  Once you create an archival backup, you must either keep it for the retention period specified or drop it.

E.  You can use an archival backup to migrate a copy of the database without affecting the retention policy.

F.  You can change the retention period of an archival backup once it has been created.

20.  You have a datafile from the smallfile tablespace USERS that has a size of 90MB, and you run the following RMAN command:

RMAN> backup tablespace users section size 40m;

How many sections does this backup create? (Choose the best answer.)

A.  The command does not run because multisection backups apply only to bigfile tablespaces.

B.  Two sections of 45MB each.

C.  Two sections of 40MB each and one section of 10MB.

D.  The command does not run because you can back up the entire database only as a multisection backup.

21.  What happens when you run the following RMAN commands?

RMAN> run
{ configure channel ch2 device type disk;
    backup database; }

(Choose the best answer.)

A.  A full database backup is created in the Fast 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.

22.  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

1.      A, B, E, and F. These are the database file types that the Recovery Manager can back up and restore.
    C, D, G, and H are incorrect. RMAN will never back up online redo logs or tempfiles because it is not necessary to back them up, and it cannot back up a static parameter file or the external password file.

2.      B. A backupset will never include blocks that have never been used.
    A, C, and D are incorrect. A is incorrect because compression is an option, not enabled by default. C is incorrect because it applies to image copies as well as backupsets. D is incorrect because it is not relevant; an image copy can’t go to tape; if it did, it wouldn’t be an image.

3.      B, D, and F. Offline backups must be done in mount mode. This is the only backup type for a noarchivelog mode database, but it can be incremental.
    A, C, and E are incorrect. A is incorrect because the database must be mounted; otherwise, RMAN won’t be able to connect to its repository or find the location of the datafiles. C is incorrect because an IMMEDIATE shutdown is clean—it is only an ABORT that would cause problems. E is incorrect because an archivelog mode database can certainly be backed up offline—it just isn’t necessary.

4.      D. In this case, none of the answers will work.
    A, B, and C are incorrect. A is incorrect because a copy of the controlfile can be created while the database is open, via a read-consistent snapshot. B is incorrect because this command will generate a CREATE CONTROLFILE script, not a file copy. C is incorrect because the file multiplexing is an additional precaution, not the only one.

5.      E. RMAN will detect the absence of a suitable backup on which to base the incremental and will therefore make a level 0 backup.
    A, B, C, and D are incorrect. A is incorrect because this will occur automatically. B is incorrect because FULL cannot be used as the base for any incremental backup. C is incorrect because redo is required to fill the gap between the last incremental backup and the current time. D is incorrect because an incremental strategy can be used with NOARCHIVELOG mode, so long as the backup is made while the database is closed.

6.      A, B, and C. Enterprise Manager will instruct the agent to run the backup. The database instance must be running, or the agent will not be able to contact it and start RMAN.
    D is incorrect. Oracle-scheduled backups do not use the operating system scheduler.

7.      C. The crosscheck command verifies that the repository does accurately reflect reality.
    A, B, and D are incorrect. A is incorrect because crosscheck does not validate whether the backups are good—only whether they exist. B is incorrect because crosscheck doesn’t delete references to missing backups; it only flags them as expired. D is incorrect because crosscheck confirms the existence of both backupsets and image copies.

8.      D. Backups that are OBSOLETE according to RMAN’s retention policy will be removed.
    A, B, C, and E are incorrect. A is incorrect because this describes datafiles, not the fast recovery area. B is incorrect because the operation will not necessarily fail—it may be possible to free up space automatically. C is incorrect because the alert system will only report the problem; it won’t fix it. E is incorrect because EXPIRED refers to the status of the backup record in the repository, not the backup itself.

9.      A, E, and H. RMAN backs up the current controlfile 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 incorrect. RMAN does not back up the controlfile under any of these circumstances.

10.      C, H, and I. INSTANCE cannot be backed up because RMAN backs up databases; an instance comprises the Oracle memory structures and cannot be backed up. CONTROLFILE cannot be backed up because it is not a valid option; you must use CURRENT CONTROLFILE to back up the controlfile. REDOLOG cannot be backed up because you should never back up the online redo logfiles, and therefore BACKUP REDOLOG is syntactically incorrect.
    A, B, D, E, F, and G are incorrect because they can all be backed up. All other objects listed (the current controlfile, the spfile, the entire database, an individual datafile, an individual tablespace, or one or more archived redo logfiles) can be backed up by RMAN.

11.      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, C, and E are incorrect. B is incorrect because CONFIGURE . . . CLEAR resets the configuration setting to its default value. C is incorrect because SHOW ALL works only when you are connected to a target database. E is incorrect since SHOW ALL lists all configuration values regardless of whether they have been changed from the default.

12.      D. %U is the default and is a system-generated unique filename that is equivalent to %u_%p_%c.
    A, B, C, and E are incorrect. These choices are valid in the FORMAT command but are not the default.

13.      A and B. In addition to datafiles and archived redo logfiles, you can create image copies of controlfiles.
    C and D are incorrect because they cannot be backed up as image copies. In fact, they cannot be backed up using RMAN.

14.      C. When the backup completes successfully, RMAN deletes all archived redo logfiles from all destinations, including the fast recovery area.
    A, B, and D are incorrect. A and B are incorrect because RMAN deletes archived redo logfiles from all destinations. D is incorrect because the DELETE INPUT command applies only to archived redo logfiles that apply to this backup.

15.      D. A whole-database backup can also include archived redo logfiles and the spfile.
    A, B, and C are incorrect. A and B are incorrect because either of these can be the basis for an incremental backup strategy as long as you use the INCREMENTAL LEVEL 0 parameter in the BACKUP command. C is incorrect because both a whole-database backup and a full backup can be image copies or backupsets.

16.      B, C, and D. A level 0 backup includes all blocks in a datafile, except for blocks that have never been used. It also can be used with both cumulative and incremental level 1 backups.
    A and E are incorrect. A is incorrect because a level 0 backup excludes blocks that have never been used. E is incorrect because a level 0 backup is physically identical to a full backup of the same datafile; the differentiation is the metadata stored in the recovery catalog.

17.      A. A differential backup is the default and backs up all changed blocks since the last level 0 or level 1 backup. You cannot specify the DIFFERENTIAL keyword, which is the default.
    B, C, and D are incorrect. B is incorrect because a cumulative backup is not the default and it backs up only changed blocks since the last level 0 backup. C is incorrect because differential backups also back up changed blocks from the last level 1 incremental backup. D is incorrect because a cumulative backup is not the default type of incremental backup and it backs up only changed blocks since the last level 0 backup.

18.      B. RMAN creates a maximum of four copies for disk or tape locations.
    A, C, and D are incorrect. There is no differentiation between tape and disk for duplexed backups, and the range is from two to four.

19.      A, E, and F. Archival backups can be kept for an indefinite period of time or retained for a specific period of time using the KEEP UNTIL clause. In addition, you can use an archival backup to migrate a database, and you can change the retention period as many times as you need to after you create it.
    B, C, and D are incorrect. B is incorrect since the correct clause is CHANGE . . . NOKEEP. C is incorrect because only the archived redo logs necessary for the snapshot are included in the backup. D is incorrect because you can easily change the retention period for any archival backup.

20.      C. RMAN backs up the datafile in multiples of the section size, and any remainder resides in the last section.
    A, B, and D are incorrect. A is incorrect because you can use multisection backups for any type of tablespace. B is incorrect because RMAN does not round up the section size to create equal section sizes in the output. D is incorrect because you can back up either an individual tablespace or the entire database as a multisection backup.

21.      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, B, and D are incorrect. A is incorrect because the CONFIGURE command cannot be used within a run block. B is incorrect for the same reason; additionally, any channels allocated within a run block override the default channel. D is incorrect since you can use BACKUP either as a stand-alone command or within a run block.

22.      B. Backup optimization is not used for backing up individual tablespaces.
    A, C, and D are incorrect. Backup optimization is used for all of these commands.