CHAPTER 28

Encrypting, Securing, Monitoring, and Tuning RMAN Backups

Exam Objectives

• 63.1.8.1    Create RMAN-Encrypted Backups

• 63.1.13.1    Configure and Use Oracle Secure Backup

• 63.1.18.1    Tune RMAN Performance

This chapter describes some advanced techniques for managing backups that relate to encryption and tuning. It also covers Oracle Secure Backup (OSB). Oracle Database 12c provides two types of encrypted backups to ensure that enterprise data is not compromised or seen by the wrong person. The backup method you use (via either Oracle Advanced Security or Oracle Secure Backup) depends on the types of data you’re backing up and its destination. As you’ve seen in previous chapters, Recovery Manager (RMAN) can back up large datafiles as a multisection backup, leveraging multiple output devices (multiple channels either to disk or to tape) to reduce dramatically the time it takes to back up the datafile, among other advantages. RMAN’s alternative compression techniques and encryption methods further reduce backup size and make the backups unavailable to unauthorized parties by using stand-alone passwords or the database’s encryption wallet.

Oracle Secure Backup is based on a global client-server model where both Oracle databases and file systems can be encrypted and backed up via an enterprise tape library system while still using the familiar RMAN interface. You use the command-line tool obtool in addition to a web interface to manage Oracle Secure Backup.

Create RMAN-Encrypted Backups

To ensure the security and privacy of your backups, you can encrypt them in one of three ways: transparent encryption, password encryption, or dual-mode encryption. By default, encryption is turned off.

In the following sections, you’ll learn how to enable each type of encryption (transparent or password). To create a successful backup and recovery strategy, you must first understand the types of failures and how Oracle responds to each of them. Some require no user or database administrator (DBA) intervention, and others do. Which backup and recovery solutions you leverage depends on many factors, including how fast you need to recover from a failure and how many resources you want to dedicate to the solution. Your investment in recovery infrastructure is proportional to the cost of lost productivity or business income if the database is unavailable for a day, an hour, or a minute.

Configuring and Using Transparent Encryption

You can set transparent (wallet-based) encryption as the default RMAN encryption method using the CONFIGURE command as follows:

Keep in mind that your database wallet must be open as well. If it is not open, you might think that everything is going as planned—until the encryption process attempts to start. This is shown by the backup failure error message in the following output:

Setting up an encryption wallet for the instance is easy. Your sqlnet.ora file points to the location of the encryption wallet with an entry similar to the following:

Within the $ORACLE_HOME/network/admin/wallet directory are the database encryption keys. Using an account with the SYSKM or ADMINISTER KEY MANAGEMENT system privilege, or via operating system (OS) authentication as in this example, create the keystore with the ADMINISTER KEY MANAGEMENT facility:

Don’t lose the contents of the files in the wallet directory—back it up. You won’t be able to decrypt encrypted tablespaces or encrypted RMAN backups without it.

Opening the wallet at the SQL> prompt (and, as of Oracle Database 12c, at the RMAN> prompt) and creating a master encryption key makes everything work a lot more smoothly.

As you might expect, even if transparent encryption is not the default, you can turn it on just for the duration of a single backup. As in the previous example, the database wallet must be open. Here is an example:

To restore or recover from an encrypted backup, the database wallet must be open, and either the encryption default must be ON or you must use SET ENCRYPTION ON before the recovery operation.

For password-based keystores, you had to specify WITH BACKUP in the earlier example when generating the master encryption key. A new master key needs to be generated only when you think that security has been compromised. Better yet, change it on a regular basis as a preventive measure.

If you need to restore an older copy of the keystore, you can recover old data only up to the point at which you changed the master encryption key.

Using Password Encryption

To enable password encryption for a specific backup, use the SET ENCRYPTION command as follows:

Password encryption is inherently less secure and reliable than transparent (wallet-based) encryption because a password can be lost, forgotten, or intercepted easily. Use password encryption only when backups must be transportable to a different database.

When you want to restore this backup, either to the same database (if wallet-based encryption is off) or to a different database, you must specify the decryption password with SET DECRYPTION.

If you are recovering one or more tablespaces or the entire database from backups that have different passwords, you can conveniently specify all the passwords at once with SET DECRYPTION.

RMAN will try each password in turn for every encrypted backup until it finds a match. RMAN will terminate with an error only if no passwords match any of the passwords in any of the backups.

Using Dual-Mode Encryption

You can use both transparent encryption and password encryption at the same time. This is useful if your backup might be used to restore or recover within the same database, and on occasion it can be used to recover another database. When both methods are in effect, you can use either the password or the database wallet to restore the backup. When recovering to a remote database, you must specify the password before recovering, as follows:

If you want to use only password-based encryption for a backup, add the ONLY clause to SET ENCRYPTION.

As a result, even if ENCRYPTION defaults to ON (and therefore uses the wallet), all subsequent backups use password encryption only until you turn off password encryption or exit RMAN altogether.

Configure and Use Oracle Secure Backup

Oracle Secure Backup enhances the privacy of the data in your backup by encrypting backups using several new methods. In addition, the range of objects you can back up goes beyond just the database files. OSB is a tool that can back up file systems on servers and on client PCs as well as databases.

The three main components in an OSB environment are as follows:

•  Administrative server    A server somewhere within the enterprise that has the OSB software installed. This could be installed on a database server, but is usually on a dedicated server.

•  Media server    A server that manages tiered storage such as disks, tape libraries, and optical media.

•  Client    The target for OSB backups. This can be an Oracle database or a file system on another server.

OSB can be leveraged in several ways: via Enterprise Manager Cloud Control, seamlessly through RMAN via the existing SBT (System Backup to Tape) interface, via the OSB web tool, and via the command-line obtool utility.

Installing and Configuring Oracle Secure Backup

To install OSB, start by downloading the latest version, which as of this writing is 12.1. Designate a directory on the server where you want to install OSB (must be done with a privileged account) and unzip the file. Then run the setup script. OSB must be installed on all nodes in the environment. During the run of the setup script, you specify which role the particular installation should fulfill: administrative server, media server, or client.

You can configure details of the tape libraries or disk pools to be used at install time or any time subsequently. Note that OSB comes with the capability to manage all of the commonly used devices on the market. OSB includes its own catalog, which is not an Oracle database but rather a structure proprietary to OSB. This catalog stores details of all devices, of all backups, and of OSB users and their passwords.

Included in the install is the command-line utility obtool, and the administrative install includes a web server hosting a Hypertext Markup Language (HTML) administration interface.

Using RMAN with Oracle Secure Backup

RMAN (or any other client that needs its data backed up) cannot automatically use OSB on the backup server and will not explicitly invoke the obtool command. Instead, RMAN will connect to OSB via the SBT interface. Here are the four requirements for using OSB via RMAN:

•  RMAN must be pre-authorized on that host using the obtool command.

•  The OS user identity of the Oracle instance must match the authorized user.

•  The RMAN user must be assigned the pertinent OSB classes to perform Oracle backups and restores.

•  The SBT library must be available.

For example, here is how you would use obtool to create an OSB user called pa_rman on the host oel63 to allow RMAN to perform backups under the OS user oracle:

From this point on, any RMAN job running under the oracle user on the server oel63 can perform backups of any database objects accessible by the RMAN session.

The SBT library is installed on the database server as part of the database installation. On Unix and Windows, the files are as follows:

To back up to OSB, use a script that specifies the library as a parameter to be passed to the channel allocation statement.

When an RMAN backup begins, the database name, content type, and copy number are sent to OSB, which translates to a given storage selector that defines the devices and media families to use for the backup.

Miscellaneous obtool Commands

Dozens of obtool commands are available, but only a handful will be used on a daily basis. Most of these commands look and act like a Linux command with similar switches. In fact, many of these commands begin with ls.

Here’s how to show OSB host information:

Here’s how to show detailed user information:

Here’s how to list dataset backup contents:

Monitor and Tune RMAN Performance

Tuning RMAN backup and recovery operations is frequently an afterthought. If you run a full backup once a week and incremental backups daily, you might not think you need to optimize your backup and recovery operations because they take up only about four hours of your time every week. This logic seems to make sense, until any of the following events occur in your organization:

•  Your company expands its offices worldwide, users will be accessing the database at all times of the day and night, and you don’t want a backup operation reducing response time.

•  New applications increase demand for the tape library system.

•  Management demands improvements in the database recovery time to meet service level agreements (SLAs).

Optimizing your RMAN backup and recovery operations will mitigate the effects of these events. You need to understand the importance of tuning RMAN and be able to identify bottlenecks in the different phases of an RMAN backup.

First, you’ll learn about the dynamic performance views you can use to monitor an RMAN backup in progress, such as V$SESSION and V$PROCESS. RMAN makes it easy to identify a specific backup job in V$SESSION.

Next, you’ll dive into some tuning exercises, using techniques such as multiple channel allocation to improve the performance of your backup operations. You’ll also learn where RMAN bottlenecks occur and how to measure a bottleneck with views such as V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO. The RMAN BACKUP command offers you a lot of flexibility by letting you control the size of each backup piece, determine how many files to put into a backupset, and decrease the load on the system by defining a desired backup duration.

Monitoring RMAN Sessions and Jobs

At any given point in time, you may have multiple backup jobs running, each with one or more channels. Each channel utilizes one operating system process. If you want to identify which channel is using the most central processing unit (CPU) or input/output (I/O) resources at the operating system level, you can join the dynamic performance views V$SESSION and V$PROCESS to identify the operating system processes associated with each RMAN channel.

In addition to identifying the processes associated with each RMAN job, you can determine the progress of a backup or restore operation. You can use the dynamic performance view V$SESSION_LONGOPS to identify how much work an RMAN session has completed and the estimated total amount of work.

Finally, RMAN provides troubleshooting information in a number of ways, above and beyond the command output at the RMAN> prompt, when something goes wrong. You can also enable enhanced debugging to help you and Oracle Support identify the cause of a serious RMAN problem.

In the following sections, you’ll be introduced to the dynamic performance views V$SESSION, V$PROCESS, and V$SESSION_LONGOPS that can help you identify and monitor RMAN backup and restore jobs. Also, you’ll learn where to look when a backup or restore job fails.

Using V$SESSION and V$PROCESS

The dynamic performance view V$PROCESS contains a row for each operating system process connected to the database instance. V$SESSION contains additional information about each session connected to the database, such as the current SQL command and the Oracle username executing the command. These sessions include RMAN sessions. As a result, you can monitor RMAN sessions using these views as well.

RMAN populates the column V$SESSION.CLIENT_INFO with the string rman and the name of the channel. Remember that each RMAN channel corresponds to a server process, and therefore V$SESSION will have one row for each channel.

To retrieve information from V$SESSION and V$PROCESS about current RMAN sessions, join the views V$SESSION and V$PROCESS on the PADDR and ADDR columns, as you will see in the exercise.

Exercise 28-1: Monitor RMAN Channel Processes    In this exercise, you’ll start an RMAN job that uses two or more channels and retrieve the channel names from V$SESSION and V$PROCESS.

1.  Create an RMAN job that backs up the USERS tablespace using two disk channels.

2.  While the RMAN job is running, join the views V$PROCESS and V$SESSION to retrieve the CLIENT_INFO column contents.

Note that RMAN’s user processes will still exist in V$SESSION until you exit RMAN or start another backup operation.

If you have multiple RMAN jobs running, some with two or more channels allocated, it might be difficult to identify which process corresponds to which RMAN backup or recovery operation. To facilitate the desired differentiation, you can use the SET COMMAND ID command within an RMAN run block, as in this example:

When this RMAN job runs, the CLIENT_INFO column in V$SESSION contains the string id=bkup users to help you identify the session for each RMAN job.

Exercise 28-2: Monitor Multiple RMAN Jobs    In this exercise, you’ll start two RMAN jobs and identify each job in V$SESSION and V$PROCESS using the SET COMMAND option in RMAN.

1.  Create two RMAN jobs (in two different RMAN sessions) that back up two tablespaces and use the SET COMMAND option.

2.  While the RMAN job is running, join the views V$PROCESS and V$SESSION to retrieve the CLIENT_INFO column contents.

Using V$SESSION_LONGOPS

The dynamic performance view V$SESSION_LONGOPS isn’t specific to RMAN either. Oracle records any operations that run for more than 6 seconds (in absolute time), including RMAN backup and recovery operations, statistics gathering, and long queries in V$SESSION_LONGOPS.

This example queries V$SESSION_LONGOPS while a datafile backup is in progress:

Tuning RMAN Performance

You can tune RMAN operations in many ways. You can tune the overall throughput of a backup by using multiple RMAN channels and assigning datafiles to different channels. Each channel is assigned to a single process, so parallel processing can speed the backup process. Conversely, you can multiplex several backup files to the same backup piece. For a particular channel, you can use the MAXPIECESIZE and MAXOPENFILES parameters to maximize throughput to a specific output device. The BACKUP command uses these parameters in addition to FILESPERSET and BACKUP DURATION to optimize your backup operation. You can also use BACKUP DURATION to minimize the effect of the backup on response time if your database must be continuously available and you have to contend with stringent SLAs. Finally, you can also use database initialization parameters to optimize backup and recovery performance, especially for synchronous I/O operations.

If you understand how each tuning method works, you can keep the user response time fast, optimize your hardware and software environment, and potentially delay upgrades when budgets are tight. A throughput bottleneck will almost always exist somewhere in your environment. A bottleneck is the slowest step or task during an RMAN backup.

The next section reviews the basic steps that a channel performs during a backup operation. The techniques presented in the following sections will help you identify where the bottleneck is within the channel’s tasks and how to minimize its impact on backup and recovery operations.

Identifying Backup and Restore Steps

RMAN backup performs its tasks within a channel in one of three main phases:

•  Read phase    The channel reads data blocks into the input buffers.

•  Copy phase    The channel copies blocks from the input buffers to the output buffers and performs additional processing, if necessary.

•  Validation    Check blocks for corruption, which is not CPU intensive.

•  Compression    Use BZIP2 or ZLIB to compress the block, which is CPU intensive.

•  Encryption    Use an encryption algorithm (transparent, password-protected, or both) to secure the data, which is CPU intensive.

•  Write phase    The channel writes the blocks from the output buffers to the output device (disk or tape).

Using dynamic performance views, you can identify which phase of which channel operation is the bottleneck and address it accordingly.

In some scenarios, you may want to increase the backup time to ensure that the recovery time will be short. Creating image copies and recovering the image copies on a daily or hourly basis will add to the backup time but will dramatically reduce recovery time.

Parallelizing Backupsets

One of the simplest ways to improve RMAN performance is to allocate multiple channels (either disk or tape). The number of channels you allocate should be no larger than the number of physical devices; allocating two or more channels (and therefore processes) for a single physical device will not improve performance and may even decrease performance. If you’re writing to a single Automatic Storage Management (ASM) disk group or a file system striped by the operating system, you can allocate more channels and improve throughput since the logical ASM disk group or striped file system maps to two or more physical disks. You can allocate up to 255 channels, and each channel can read up to 64 datafiles in parallel. Each channel writes to a separate backup copy or image copy.

If the number of datafiles in your database is relatively constant, you can allocate a fixed number of channels and assign each datafile to a specific channel. Here is an example:

Note also that you can specify the path name for a datafile instead of the datafile number, as in this example:

To automate this process further, you can use the CONFIGURE command to increase the parallelism for each device type.

Understanding RMAN Multiplexing

You can improve RMAN performance and throughput by multiplexing backup and recovery operations. Multiplexing enables RMAN to read from multiple files simultaneously and write the data blocks to the same backup piece. You cannot multiplex image copies. If you did, the output would not be an image of the input.

Using multiplexing as an RMAN tuning method is one way to reduce bottlenecks in backup and recovery operations. The level of multiplexing is primarily controlled by two parameters: FILESPERSET and MAXOPENFILES. The FILESPERSET parameter of the RMAN BACKUP command determines the number of datafiles to put in each backupset. If a single channel backs up ten datafiles and the value of FILESPERSET is 4, RMAN will back up only four files per backupset, and three sets will be generated. The parameter FILESPERSET defaults to 64.

The level of multiplexing (the number of input files that are read and written to the same backup piece) is the minimum of MAXOPENFILES and the number of files in each backupset. The default value for MAXOPENFILES is 8. RMAN allocates a different number and size of disk I/O buffers depending on the level of multiplexing in your RMAN job. Once the level of multiplexing is derived by RMAN using the FILESPERSET and MAXOPENFILES parameters, the number and size of buffers are as follows:

Tuning RMAN Channels

You can further tune your RMAN backup performance by tuning individual channels with the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands. Each CHANNEL command accepts the following parameters:

•  MAXPIECESIZE    The maximum size of a backup piece

•  RATE    The number of bytes per second read by RMAN on the channel

•  MAXOPENFILES    The maximum number of input files that a channel can have open at a given time

The MAXPIECESIZE parameter is useful when you back up to disk and the underlying operating system limits the size of an individual disk file or when a tape media manager cannot split a backup piece across multiple tapes.

Note that the RATE parameter doesn’t improve performance, but throttles performance intentionally to limit the disk bandwidth available to a channel. This is useful when your RMAN backups must occur during periods of peak activity elsewhere in the database.

MAXOPENFILES was reviewed in the preceding section, but it is worth revisiting when you want to optimize the performance of an individual channel. For example, you can use MAXOPENFILES to limit RMAN’s use of operating system file handles or buffers.

Tuning the BACKUP Command

Just like the CONFIGURE CHANNEL command, the BACKUP command has parameters that can help you improve performance or limit the computing resources that a channel uses for an RMAN backup. Here are the key tuning parameters for the BACKUP command:

•  MAXPIECESIZE    The maximum size of a backup piece per channel

•  FILESPERSET    The maximum number of files per backupset

•  MAXOPENFILES    The maximum number of input files that a channel can have open at a given time

•  BACKUP DURATION    The time to complete the backup

You’ve seen the parameters MAXPIECESIZE, FILESPERSET, and MAXOPENFILES before. Note that MAXPIECESIZE and MAXOPENFILES have the same purpose as in the CHANNEL commands, except that they apply to all channels in the backup.

BACKUP DURATION specifies an amount of time to complete the backup. You can qualify this option with MINIMIZE TIME to run the backup as fast as possible or with MINIMIZE LOAD to use the entire time frame specified in the BACKUP DURATION window. In addition, you can use the PARTIAL option, as you might expect, to save a partial backup that was terminated because of time constraints. For example, to limit a full database backup to two hours, run it as fast as possible, and save a partial backup, use this command:

If the backup does not complete in the specified time frame, the partial backup is still usable in a recovery scenario after a successive BACKUP command finishes the backup and you use the PARTIAL option.

Two-Minute Drill

Create RMAN-Encrypted Backups

•  Transparent encryption uses a database wallet to encrypt a backup, and the backup can be restored only to the source database.

•  Password encryption uses a password to encrypt a backup, and the backup can be restored either to the source database or to another database.

•  You can use both transparent encryption and password encryption on the same backup.

•  Transparent encryption can be enabled for a single backup using the SET ENCRYPTION command.

Configure and Use Oracle Secure Backup

•  Oracle Secure Backup is hosted on an administrative server and provides the interface between RMAN and media servers for both databases and file systems across the enterprise.

•  An OSB storage selector consists of a database name, content type, and copy number. RMAN passes the storage selector to OSB and processes the backup job.

•  OSB maintains its own backup catalog.

•  Typical OSB obtool commands perform tasks such as showing registered hosts (lshost), devices (lsdev), backup datasets (lsds), and volumes (lsvol).

Tune RMAN Performance

•  You can join V$SESSION with V$PROCESS to identify the operating system processes associated with each RMAN channel.

•  The RMAN command SET COMMAND ID helps you distinguish processes for different backup jobs in V$SESSION.

•  Use V$SESSION_LONGOPS to monitor the status of RMAN jobs that run for more than 6 seconds.

•  Parallelization (allocating multiple channels) can improve backup performance. You can allocate up to 255 channels per RMAN session, and each channel can read up to 64 datafiles in parallel.

•  Multiplexing is primarily controlled by the RMAN parameters FILESPERSET and MAXOPENFILES.

•  You tune RMAN channels by using the MAXPIECESIZE, RATE, and MAXOPENFILES parameters.

•  The BACKUP parameter BACKUP DURATION can be set to MINIMIZE TIME to perform the backup as quickly as possible, or can be set to MINIMIZE LOAD to reduce the I/O demands on the database.

Self Test

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

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

A.  The command does not run because multisection backups apply only when multiple channels are used.

B.  Two sections of 45MB each.

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

D.  It is not possible to predict the size of the sections.

2.  Which of the following attributes or characteristics are passed by RMAN to OSB when performing a backup? Assume that the RMAN client has already been registered with OSB. (Choose all that apply.)

A.  Content type

B.  Unique hostname

C.  Database ID

D.  Database name

E.  Copy number

F.  Requested media group number

3.  What RMAN retention policy should you use if the RMAN backups leverage OSB? (Choose the best answer.)

A.  RMAN inherits the OSB retention policy.

B.  RECOVERY WINDOW.

C.  COPIES.

D.  OSB inherits the RMAN retention policy.

4.  Which of the following two dynamic performance views can you use to identify the relationship between Oracle server sessions and RMAN channels? (Choose the best answer.)

A.  V$PROCESS and V$SESSION

B.  V$PROCESS and V$BACKUP_SESSION

C.  V$PROCESS and V$BACKUP_ASYNC_IO

D.  V$BACKUP_ASYNC_IO and V$SESSION

E.  V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO

5.  You create three RMAN sessions to back up three different tablespaces. Your third RMAN session runs this command:

What values does the column V$SESSION.CLIENT_INFO have for this command? (Choose all that apply.)

A.  rman channel=ORA_DISK_1, id=user bkup.

B.  id=user bkup, rman channel=ORA_DISK_1.

C.  id=user bkup, cmd=backup tablespace users.

D.  id=user bkup.

E.  The column CLIENT_INFO is in V$PROCESS, not V$SESSION.

6.  Identify the location where RMAN message output and troubleshooting information can be found. (Choose all that apply.)

A.  The Oracle server trace file

B.  The RMAN trace file

C.  The view V$PROCESS

D.  The database alert log

E.  RMAN command output

F.  The vendor-specific file sbtio.log

G.  The table SYS.AUDIT$

7.  These instance parameters in your database are set as follows:

BACKUP_TAPE_IO_SLAVES = TRUE
LARGE_POOL_SIZE = 200M
JAVA_POOL_SIZE = 200M
PGA_AGGREGATE_TARGET = 200M

Which is the correct statement regarding where RMAN allocates the memory buffers for tape backup? (Choose the best answer.)

A.  RMAN uses the Java pool in the SGA.

B.  RMAN uses the shared pool in the SGA.

C.  RMAN allocates memory from the large pool in the PGA.

D.  RMAN allocates memory from the large pool in the SGA.

8.  Which of the following are bottlenecks that affect RMAN backup and recovery operations? (Choose all that apply.)

A.  Reading data from the database

B.  Writing data to disk

C.  Writing data to tape

D.  Validating data blocks

E.  Using SGA memory buffers versus PGA memory buffers

9.  Which RMAN parameter controls multiplexing to disk and tape? (Choose the best answer.)

A.  FILESPERSET from the BACKUP command

B.  FILESPERSET from the BACKUP command and MAXOPENFILES from the CONFIGURE command

C.  FILESPERSET from the CONFIGURE command and MAXOPENFILES from the BACKUP command

D.  MAXOPENFILES from the CONFIGURE command

Self Test Answers

1.      D. The section size divides the input datafile, not the output backup piece.
    A, B, and C are incorrect. A is incorrect because you can use multisection backups without parallelism (though there may not be much point to this). B and C are incorrect because the size of the output pieces cannot be predicted because it will depend on how many blocks of the datafile sections actually contain data.

2.      A, C, D, and E. When RMAN sends a backup request to OSB, you must specify the database name (or ID), the content type, and the copy number. Given this information, OSB will use the stored backup storage selector and send the backup to the appropriate backup devices and media family.
    B and F are incorrect. B is incorrect because the hostname is used to register the RMAN client with the OSB administration server, but is not needed for each backup. F is incorrect because RMAN does not select the media group number; OSB does.

3.      B. You should use a RECOVERY WINDOW retention policy when using RMAN with OSB. You will use a certain amount of disk space in the Fast Recovery Area for meeting the recovery needs for a certain number of hours each day; longer recovery operations will also leverage tape backups managed by OSB. You will use an obtool command to create a media family for RMAN backups.
    A, C, and D are incorrect. A and D are incorrect because there is no inheritance of backup retention policies between RMAN and OSB. C is incorrect because you will not be able to leverage the contents of the Fast Recovery Area as much as you could with a recovery window-based policy.

4.      A. You join the views V$PROCESS and V$SESSION on the ADDR and PADDR columns and select rows where the beginning of the column CLIENT_INFO contains the string RMAN.
    B, C, D, and E are incorrect. B is incorrect because there is no such view V$BACKUP_SESSION. C, D, and E are incorrect because you use V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO to monitor the performance of RMAN jobs for asynchronous and synchronous I/O, respectively.

5.      B and D. The view V$SESSION has two rows for each backup process, both of them with the value specified in the RMAN command SET COMMAND ID.
    A, C, and E are incorrect. A is incorrect because the values for CLIENT_INFO are in the incorrect order. C is incorrect because the actual RMAN command is not included in CLIENT_INFO. E is incorrect because CLIENT_INFO is, in fact, in the view V$SESSION.

6.      A, B, D, E, and F. RMAN debugging information and other message output can be found in the Oracle server trace files, the RMAN trace file, the database alert log, output from the RMAN command itself, and the vendor-specific file sbtio.log (for tape libraries).
    C and G are incorrect. RMAN does not record any debugging or error information in the view V$PROCESS or in the table SYS.AUDIT$.

7.      D. If you set BACKUP_TAPE_IO_SLAVES to TRUE, then RMAN allocates tape buffers from the shared pool unless the initialization parameter LARGE_POOL_SIZE is set, in which case RMAN allocates tape buffers from the large pool.
    A, B, and C are incorrect. The parameters JAVA_POOL_SIZE and PGA_AGGREGATE_TARGET have no effect on the location of the RMAN buffers.

8.      A, B, C, and D. All of these options are potential bottlenecks.
    E is incorrect. The location of the RMAN data buffers is not a factor that can cause a bottleneck and reduce RMAN throughput.

9.      B. Both FILESPERSET and MAXOPENFILES control the level of multiplexing during an RMAN backup operation.
    A, C, and D are incorrect. A is incorrect because MAXOPENFILES in the CONFIGURE command also controls the level of multiplexing, not just FILESPERSET. C is incorrect because FILESPERSET is not a valid option for the CONFIGURE command, and MAXOPENFILES is not a valid option for the BACKUP command. D is incorrect because MAXOPENFILES of the CONFIGURE command is not the only parameter that controls the level of multiplexing.