8
Monitoring and Tuning RMAN
CERTIFICATION OBJECTIVES
8.01 Monitoring RMAN sessions and jobs
8.03 Configure RMAN for Asynchronous I/O
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’d need to optimize your backup and recovery operations because they take up only about 4 hours of your time every week. This logic seems to make sense, until 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. Even though this relatively short chapter on RMAN tuning is the last chapter on RMAN, consider this information last but not least. 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 that 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 itself offers you a lot of flexibility by letting you control the size of each backup piece, determine how many files to put into a backup set, and decrease the load on the system by defining a desired backup duration.
Finally, you’ll see some pros and cons of using asynchronous versus synchronous I/O for RMAN tape and disk operations. Ideally, you can use asynchronous I/O to maximize throughput. Even if the tape subsystem or operating system cannot leverage asynchronous I/O, you can still use initialization parameters and RMAN settings to maximize throughput.
CERTIFICATION OBJECTIVE 8.01
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 CPU or 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 also 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 first exercise.
EXERCISE 8-1
Monitor RMAN Channels
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 8-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 the USERS and CHGTRK 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.
RMAN populates two different types of rows in V$SESSION_LONGOPS: detail rows and aggregate rows. Detail rows contain information about a single RMAN job step, such as creating a single backup set. Aggregate rows apply to all files referenced in a single RMAN command, such as BACKUP DATABASE. As you might expect, aggregate rows are updated less frequently than detail rows.
|
The initialization parameter This example initiates a full database backup, and while the backup is running, both detail and aggregate rows for active RMAN jobs are shown:
The SID and SERIAL# are the same columns you see in V$SESSION. The OPNAME column is a text description of the operation monitored in the row, and for RMAN, it contains the prefix RMAN:. The CONTEXT column contains a value of 7 for aggregate operations, 2 for backup output operations, and 1 for everything else.
The column SOFAR is, as you might expect, a measure of the progress of a step. Its value differs depending on the type of operation:
For image copies, it is the number of blocks read.
For backup input rows, it is the number of blocks read from the files being backed up.
For backup output rows (backup set or image copy), it is the number of blocks written so far to the backup piece.
For restore operations, it is the number of blocks processed so far to the destination files.
For proxy copies (copy operations from a media manager to or from disk), it is the number of files that have been copied so far.
The column TOTALWORK has a similar definition, except that it estimates the total amount of work required during the step:
For image copies, it is the total number of blocks in the file.
For backup input rows, it is the total number of blocks to be read from all files in the step.
For backup output rows, it is always zero because RMAN does not know how many blocks will be written into a backup piece until it is done.
For restore operations, it is the total number of blocks in all files restored in a single job step or aggregate.
For proxy copies, it is the total number of files to be copied in the job step.
To calculate the progress of an RMAN step as a percent complete, you can divide SOFAR by TOTALWORK as follows and add this expression to the SELECT statement:
Leveraging RMAN Error Logs and Messages
When something goes wrong, RMAN debugging information can be found in several places. The following sections show you where you can find debugging information. When you don’t have enough information, you can turn on additional debugging output using the RMAN DEBUG command.
Identifying RMAN Message Output
When disaster strikes your RMAN backup and recovery operations, you can find information in many locations, such as the following:
RMAN command output The interactive output you see when you execute RMAN commands at the RMAN< prompt.
User-specified RMAN trace file The output saved to a user-specified trace file when you use the rman . . . debug trace command at the operating system prompt.
Alert log The standard Oracle alert log location defined by the initialization parameter DIAGNOSTIC_DEST or USER_DUMP_DEST.
Oracle trace file Detailed diagnostic output from Oracle errors generated during RMAN commands, located in DIAGNOSTIC_DEST or USER_DUMP_DEST.
Vendor trace files The file sbtio.log or other vendor-assigned filenames containing media-management software errors in DIAGNOSTIC_DEST or USER_DUMP_DEST.
RMAN-specific error messages have a prefix with the format RMAN-nnnn, and this message can be preceded or followed by ORA-nnnnn messages or vendor-specific messages, depending on the type of error.
Using the RMAN DEBUG Command
Turning on RMAN debugging generates a lot of output, so Oracle recommends that you specify a file to contain debugging output. To turn on debugging, you use the debug option on the RMAN executable’s command line. Add the trace option to specify a file for the debugging output. Here is an example:
When RMAN starts, debugging information is sent to the specified trace file. Within an RMAN session, you can turn on or turn off debugging using the DEBUG ON or DEBUG OFF command. For example, you might want to trace the errors when backing up one problematic datafile but not the others.
EXERCISE 8-3
Debug Part of an RMAN Session
In this exercise, you’ll turn on RMAN debugging, back up the USERS and CHGTRK tablespaces, but debug only the backup of the CHGTRK tablespace.
1. Start RMAN with the debug option:
2. Turn off debugging temporarily for the USERS tablespace but turn it back on for the CHGTRK tablespace:
3. Verify the size of the trace file:
Note that even for a single tablespace backup, the trace file is larger than 350K bytes.
Note that the DEBUG command at the RMAN< command line does not do anything unless you specify debug when starting the RMAN executable at the operating system command line.
CERTIFICATION OBJECTIVE 8.02
Tuning RMAN
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 (which is almost always). 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:
1. Read phase: The channel reads data blocks into the input buffers.
2. 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.
3. 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 Backup Sets
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. Here is the default RMAN configuration for disk device channels:
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.
Note that you cannot multiplex image copies.
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 backup set. If a single channel backs up 10 datafiles and the value of FILESPERSET is 4, RMAN will back up only four files per backup set. 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 backup set. The default value for MAXOPENFILES is 8. Here is an equation that may make the calculation easier to understand:
This example backs up 10 datafiles in one channel, the value for MAXOPENFILES is 12, and the value for FILESPERSET is at the default value of 64. Therefore, the multiplexing level is calculated as follows:
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 using the aforementioned equation, you can use the information in Table 8-1 to find out how many and what size buffers RMAN needs to perform the backup.
TABLE 8-1 RMAN Datafile Buffer Sizing
Level of Multiplexing |
Size of Input Disk Buffer |
>= 4 |
16 buffers of 1MB each divided among all input files |
5–8 |
A variable number of 512MB buffers to keep total buffer size under 16MB |
< 8 |
Total of 4 buffers of 128KB for each (512KB) for each input file |
Oracle recommends that the value FILESPERSET should be 8 or less to optimize recovery performance. In other words, putting too many input files into a single backupset will slow down a recovery operation because the RESTORE or RECOVER command will still have to read a large number of unneeded blocks in the backupset when you recover a single datafile.
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 Decrease or increase 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 MINIMIZE LOAD to use the entire timeframe 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 due to time constraints. For example, to limit a full database backup to 2 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.
Configuring LARGE_POOL_SIZE
You can adjust the value of the initialization parameter LARGE_POOL_SIZE to improve RMAN backup performance. If you do not set LARGE_POOL_SIZE, the RMAN server processes use memory from the shared pool. This may cause contention with many other processes that use the shared pool. If RMAN’s request for memory from the shared pool cannot be fulfilled, RMAN uses memory from the Program Global Area (PGA), writes a message to the alert log, and uses synchronous I/O for this backup. But synchronous I/O can be inefficient; therefore, you can resize the value of the large pool for disk backups using this calculation:
If you are backing up to tape, add memory to account for the size of the tape driver buffer (equivalent to the RMAN channel parameter BLKSIZE):
Note also that RMAN will only use memory from the large pool if DBWR_IO_SLAVES is set to a value greater than zero. You will learn how to set this initialization parameter later in this chapter.
CERTIFICATION OBJECTIVE 8.03
Configure RMAN for Asynchronous I/O
Whether you use synchronous or asynchronous I/O in your RMAN environment depends on several factors. These factors include the type of device you use for backupsets (disk or tape) and whether the output device or host operating system supports synchronous or asynchronous I/O. Even if the host operating system or device does not support native asynchronous I/O, you can configure RMAN to simulate asynchronous I/O using initialization parameters such as DBWR_IO_SLAVES.
After you review the key differences between asynchronous and synchronous I/O, you will learn how to monitor the performance of each type of I/O using dynamic performance views, identify where the throughput bottleneck is, and adjust RMAN parameters accordingly.
Understanding Asynchronous and Synchronous I/O
When RMAN reads or writes data, the I/O operations are either synchronous or asynchronous. A synchronous I/O operation limits a server process from performing more than one operation at a time. It must wait for one operation to finish before another can start. As you might expect, an asynchronous operation can initiate an I/O operation and immediately perform other operations including initiating another I/O operation.
You can use initialization parameters to control the type of I/O operations. For tape backups, you can set BACKUP_TAPE_IO_SLAVES to TRUE to configure backups for asynchronous operations. Otherwise, set it to FALSE for synchronous operations. The default is FALSE.
For disk backups, most modern operating systems support native asynchronous I/O. However, if your operating system does not support it, you can still set BACKUP_TAPE_IO_SLAVES to TRUE and direct Oracle to simulate asynchronous I/O by setting DBWR_IO_SLAVES to a nonzero value. This allocates four backup disk I/O slaves to simulate RMAN asynchronous I/O operations.
Monitoring Asynchronous I/O
To monitor asynchronous I/O operations, you use the dynamic performance view V$BACKUP_ASYNC_IO. The key columns to watch are the following:
IO_COUNT Number of I/Os performed on the file.
LONG_WAITS Number of times the backup or restore process had to tell the OS to wait for the I/O to complete.
SHORT_WAIT_TIME_TOTAL Total time, in hundredths of a second, taken for nonblocking polling for I/O completion.
LONG_WAIT_TIME_TOTAL Total time, in hundredths of a second, taken while blocking waits for I/O completion.
The largest ratio of LONG_WAITS to IO_COUNT is a likely bottleneck in the backup process. SHORT_WAIT_TIME_TOTAL and LONG_WAIT_TIME_TOTAL are also indicators of a bottleneck if they are nonzero.
This example identifies two input files with nonzero ratios:
For these two files, you may consider increasing the multiplexing to decrease or eliminate the wait times when backing them up.
Monitoring Synchronous I/O
The dynamic performance view V$BACKUP_SYNC_IO will help you identify bottlenecks in synchronous I/O operations, as well as the progress of backup jobs. You use the column DISCRETE_BYTES_PER_SECOND to view the I/O rate of the operation. You then compare that rate to the maximum rate of the output device, such as a tape drive. If the rate is significantly lower, you can tune the process to improve the throughput of the backup operation by parallelization or increasing the level of multiplexing for the channel.
|
CERTIFICATION SUMMARY
This chapter provided a short but important list of tips to help you effectively tune your RMAN operations to maximize the throughput of your backup and recovery operations. First, you learned how to monitor the progress of RMAN jobs using the dynamic performance views V$SESSION, V$PROCESS, and V$SESSION_LONGOPS.
When disaster strikes, even if it’s a small disaster, you can look in several places to debug backup or recovery problems. If the solution to the problem is not obvious from the command line output, you can use the alert log or standard Oracle trace files. You can create RMAN-specific trace files with the DEBUG option as well. If you are using tape devices, the file sbtio.log can provide clues, along with any other vendor-specific trace or dump files.
After you learned about the steps RMAN performs during a backup or restore operation, you saw several ways to tune your RMAN backups. This included increasing the multiplexing level for one or more channels, tuning the BACKUP command with its command line options, and configuring the LARGE_POOL_SIZE for large RMAN memory buffer requests.
Finally, the chapter compared and contrasted synchronous and asynchronous I/O. Both methods record backup and recovery progress in the dynamic performance views V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO, which can help you identify bottlenecks for specific files in the backup.
TWO-MINUTE DRILL
Monitoring RMAN Sessions and Jobs
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 to distinguish processes for different backup jobs in V$SESSION.
Use V$SESSION_LONGOPS to monitor status of RMAN jobs that run for more than 6 seconds.
The view V$SESSION_LONGOPS contains both detail rows and aggregate rows for each RMAN job.
You must set the initialization parameter STATISTICS_LEVEL to TYPICAL or ALL before RMAN will record job status information in V$SESSION_LONGOPS.
RMAN debugging information appears in command line output, RMAN-specific trace files, the alert log, Oracle trace files, and vendor-specific trace files.
Add the debug option to the operating system command line to turn debugging on and optionally specify a file to contain the debugging output.
Use the DEBUG ON or DEBUG OFF command to turn on or turn off RMAN debugging within an RMAN session.
Tuning RMAN
RMAN backup or recovery jobs perform tasks in three main phases: read, copy, and write.
The RMAN copy phase is further broken down into three subphases: validation, compression, and encryption.
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 can calculate the level of multiplexing by using this formula: min(MAXOPENFILES, min(FILESPERSET, files_per_channel))
You tune RMAN channels by using the MAXPIECESIZE, RATE, and MAXOPENFILES parameters.
You tune the BACKUP command by using the MAXPIECESIZE, FILESPERSET, MAXOPENFILES, and the BACKUP DURATION parameters.
The BACKUP parameter BACKUP DURATION can be set to MINIMIZE TIME to perform the backup as quickly as possible or MINIMIZE LOAD to reduce the I/O demands on the database.
You can configure the initialization parameter LARGE_POOL_SIZE to reduce contention on the shared pool for RMAN backups.
Configure RMAN for Asynchronous I/O
Synchronous backup operations must wait until completion before initiating another I/O request. Asynchronous backup operations do not have to wait.
You set the initialization parameter BACKUP_TAPE_IO_SLAVES to TRUE to configure tape backups for asynchronous operations.
Setting the initialization parameter DBWR_IO_SLAVES allocates four backup disk I/O slave process to simulate RMAN asynchronous I/O operations.
Use the dynamic performance view V$BACKUP_ASYNC_IO to monitor asynchronous RMAN operations.
The ratio of LONG_WAITS to IO_COUNT in V$BACKUP_ASYNC_IO should be as low as possible to reduce or eliminate bottlenecks.
If either the V$BACKUP_ASYNC_IO column SHORT_WAIT_TIME_TOTAL or LONG_WAIT_TIME_TOTAL is not zero, then the associated file should be tuned.
You use the dynamic performance view V$BACKUP_SYNC_IO to identify bottlenecks in synchronous RMAN backup or recovery operations.
The column DISCRETE_BYTES_PER_SECOND in V$BACKUP_SYNC_IO can be compared to the maximum rate of a tape output device to identify opportunities for tuning.
SELF TEST
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.
Monitoring RMAN Sessions and Jobs
1. Which of the following two dynamic performance views can you use to identify the relationship between Oracle server sessions and RMAN channels?
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
2. 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
3. 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$
Tuning RMAN
4. The initialization parameters in your database are set as follows:
Identify the correct statements regarding where RMAN allocates the memory buffers for tape backup:
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.
5. 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
6. Which RMAN parameter(s) control 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
Configure RMAN for Asynchronous I/O
7. Identify the types of rows in V$BACKUP_SYNC_IO during an RMAN backup operation. (Choose all that apply.)
A. One row for each datafile
B. One row for each tablespace
C. One row for each backup piece
D. One row for each channel
E. One row for each input or output device type
8. You can use V$BACKUP_ASYNC_IO to monitor asynchronous RMAN I/O. What column or columns do you use to determine which file is the bottleneck during a backup?
A. A large value for LONG_WAITS / IO_COUNT
B. A large value for LONG_WAITS
C. A large value for IO_COUNT
D. A large value for IO_COUNT / LONG_WAITS
9. You set the initialization parameter BACKUP_TAPE_IO_SLAVES to TRUE. What effect does this have on the type of I/O that the server processes perform for RMAN if you are using tape? (Choose the best answer.)
A. If LARGE_POOL_SIZE is set to a nonzero value, tape I/O is automatically synchronous.
B. If LARGE_POOL_SIZE is set to a nonzero value, tape I/O is automatically asynchronous.
C. Tape I/O is automatically synchronous.
D. Tape I/O is automatically asynchronous.
SELF TEST ANSWERS
Monitoring RMAN Sessions and Jobs
1. 
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 is wrong because there is no such view V$BACKUP_SESSION. C, D, and E are wrong because you use V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO to monitor performance of RMAN jobs for asynchronous and synchronous I/O, respectively.
2. 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 is wrong because the values for CLIENT_INFO are in the wrong order. C is wrong because the actual RMAN command is not included in CLIENT_INFO. E is wrong because CLIENT_INFO is, in fact, in the view V$SESSION.
3. 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 wrong. RMAN does not record any debugging or error information in the view V$PROCESS or in the table SYS.AUDIT$.
Tuning RMAN
4. 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.
5. A, B, C, and D. All of these options are potential bottlenecks.
E is wrong. The location of the RMAN data buffers is not a factor that can cause a bottleneck and reduce RMAN throughput.
6. B. Both FILESPERSET and MAXOPENFILES control the level of multiplexing during an RMAN backup operation.
A is wrong because MAXOPENFILES in the CONFIGURE command also controls the level of multiplexing, not just FILESPERSET. C is wrong because FILESPERSET is not a valid option for the CONFIGURE command and MAXOPENFILES is not a valid option for the BACKUP command. D is wrong because MAXOPENFILES of the CONFIGURE command is not the only parameter that controls the level of multiplexing.
Configure RMAN for Asynchronous I/O
7. A and C. The view V$BACKUP_SYNC_IO contains a row for each datafile and a row for each backup piece. In addition, V$BACKUP_SYNC_IO contains an aggregate row for all datafiles.
B is wrong because the tracking in V$BACKUP_SYNC_IO is at the datafile level. D is wrong because individual channels are not tracked in V$BACKUP_SYNC_IO. E is wrong because individual devices are not tracked in V$BACKUP_SYNC_IO.
8. A. The file with the largest value for the ratio of LONG_WAITS to IO_COUNT indicates that the file is the bottleneck.
B is wrong because a large value for LONG_WAITS doesn’t by itself indicate a bottleneck. Similarly, C is wrong because a large value for IO_COUNT doesn’t by itself indicate a bottleneck. D is wrong because a small value for IO_COUNT / LONG_WAITS identifies a bottleneck, not a large value.
9. D. If you set BACKUP_TAPE_IO_SLAVES to TRUE, tape I/O is automatically asynchronous.
A and B are wrong because LARGE_POOL_SIZE has no effect on whether the I/O is synchronous or asynchronous. C is wrong because tape I/O is synchronous if BACKUP_TAPE_IO_SLAVES is set to FALSE.