The primary goal of RMAN tuning is to create an adequate flow of data between disk and storage device. Tuning RMAN backup and restore operations involves the following tasks discussed in this chapter:
Tuning Recovery Manager: Overview
RMAN backup and restore operations have the following distinct components:
- Reading or writing input data
- Processing data by validating blocks and copying them from the input to the output buffers
The slowest of these operations is called the bottleneck. RMAN tuning is the task of identifying the bottleneck (or bottlenecks) and attempting to make it more efficient by using RMAN commands, initialization parameter settings, or adjustments to physical media. The key to tuning RMAN is understanding I/O.(使用rman命令，初始化参数设置，调整物理介质)
调整rman的关键是理解i/o
RMAN's backup and restore jobs use two types of I/O buffers: DISK and tertiary storage (usually tape). When performing a backup, RMAN reads input files using disk buffers and writes the output backup file by using either disk or tape buffers. When performing restores, RMAN reverses these roles.（backup时，input file—read ---disk buffers----write
Backup file---disk or tape buffers)
Besides being divided into DISK and sbt, I/O is also divided into synchronous and asynchronous. Synchronous devices only perform one I/O task at a time.(
某个时刻只能执行一个i/o任务） Hence, you can easily determine how much time backup jobs require. In contrast to synchronous I/O, asynchronous I/O can perform more than one task at a time.（某个时刻能够执行多个i/o操作）
To tune RMAN effectively, you must thoroughly understand concepts such as synchronous and asynchronous I/O, disk and tape buffers, and channel architecture. When you understand these concepts, then you can learn how to use fixed views to monitor bottlenecks, and use the techniques described in "Improving RMAN Backup Performance" to solve problems.
This section contains these topics:
- Disk Buffer Allocation
- Tape Buffer Allocation
- Synchronous and Asynchronous I/O
- Factors Affecting Backup Speed to Tape
- Channel Tuning Options
- Backup Tuning Options
RMAN I/O uses two different types of buffers: disk and tape. These buffers are typically different sizes. To understand how RMAN allocates disk buffers, you must understand how RMAN multiplexing works, as described in "Multiplexed Backup Sets". Review this section before proceeding.
RMAN multiplexing is the number of files in a backup read simultaneously and then written to the same backup piece. The degree of multiplexing depends on the FILESPERSET parameter of the BACKUP command as well as the MAXOPENFILES parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands.
For example, assume that you back up two datafiles with one channel. You set FILESPERSET to 3 and set MAXOPENFILES to 8. In this case, the number of files in each backup set is 2 (the lesser of FILESPERSET and the files read by each channel), and so the level of multiplexing is 2 (the lesser of MAXOPENFILES and the number of files in each backup set).
When RMAN backs up from disk, it uses the algorithm described in Table 14-1 to determine how many buffers to allocate and how large to make the buffers.
Table 14-1 Disk Buffer Allocation Algorithm
In the example shown in Figure 14-1, "Disk Buffer Allocation", one channel is backing up four datafiles on a robust striped disk configuration. MAXOPENFILES is set to 4 and FILESPERSET is set to 4. Hence, the level of multiplexing is 4. So, the total size of the buffers for each datafile is 4 MB.
Figure 14-1 Disk Buffer Allocation
Text description of the illustration rcmug011.gif
To calculate the total size of the buffers allocated in a backup set, multiply the total bytes for each datafile by the number of datafiles being concurrently accessed by the channel, and then multiply this number by the number of channels.
Assume that you use one channel to back up four datafiles, and use the settings shown in Figure 14-1. In this case, multiply as follows to obtain the total size of the buffers allocated for the backup:
4 MB/datafile x 1 channel x 4 datafiles/channel = 16 MB
Set the MAXOPENFILES parameter so that the number of files read simultaneously is just enough to utilize the output device fully. This consideration is especially important when the output device is tape.
If you make a backup to an sbt device, then Oracle allocates four buffers for each channel for the tape writers (or reads if doing a restore). Oracle allocates these buffers only if the channel is an sbt channel. Typically, each tape buffer is 256 KB. To calculate the total size of buffers used during a backup or restore, multiply the buffer size by 4, and then multiply this product by the number of channels.
As illustrated in Figure 14-2, assume that you use one tape channel and each buffer is 256 KB. In this case, the total size of buffers used during a backup is as follows:
256 KB/buffer x 4 buffers/channel x 1 channel = 1024 KB
RMAN allocates the tape buffers in the SGA or the PGA, depending on whether I/O slaves are used. If you set the initialization parameter BACKUP_TAPE_IO_SLAVES = true, then RMAN allocates tape buffers from the SGA or the large pool if the LARGE_POOL_SIZE initialization parameter is set. If you set the parameter to false, then RMAN allocates the buffers from the PGA.
If you use I/O slaves, then set the LARGE_POOL_SIZE initialization parameter to set aside SGA memory dedicated to holding these large memory allocations. Hence, the RMAN I/O buffers do not compete with the library cache for SGA memory.
Figure 14-2 Tape Buffer Allocation
Text description of the illustration rcmug013.gif
Synchronous and Asynchronous I/O
When RMAN reads or writes data, the I/O is either synchronous or asynchronous. When the I/O is synchronous, a server process can perform only one task at a time. When it is asynchronous, a server process can begin an I/O and then perform other work while waiting for the I/O to complete. It can also begin multiple I/O operations before waiting for the first to complete.
You can set initialization parameters that determine the type of I/O. If you set BACKUP_TAPE_IO_SLAVES to true, then the tape I/O is asynchronous. Otherwise, the I/O is synchronous. It is recommended that you always set BACKUP_TAPE_IO_SLAVES to true.
Some operating systems support native asynchronous I/O, and Oracle takes advantage of this feature if it is available. On operating systems that do not support native asynchronous I/O, Oracle can simulate it by using special I/O slave processes that are dedicated to performing I/O on behalf of another process. You can control disk I/O slaves by setting the DBWR_IO_SLAVES parameter to a nonzero value. Oracle allocates four backup disk I/O slaves for any nonzero value of DBWR_IO_SLAVES.
Figure 14-3 shows synchronous I/O in a backup to tape. The following steps occur:
- The tape process writes data to tape. The server process must remain idle while the media manager copies data from the Oracle buffers to the media manager's internal buffers.
Text description of the illustration stu81178.gif
Figure 14-4 shows asynchronous I/O in a tape backup. The following steps occur:
- The tape process writes data to tape. While the tape process is writing, other server processes are free to process more input blocks and fill more output buffers.
Text description of the illustration stu81175.gif
Factors Affecting Backup Speed to Tape
The following factors affect the speed of the backup to tape:
The tape native transfer rate is the speed of writing to a tape without compression. This speed represents the upper limit of the backup rate. The upper limit of your backup performance should be the aggregate transfer rate of all of your tape drives. If your backup is already performing at that rate, and if it is not using an excessive amount of CPU, then RMAN performance tuning will not help.
The level of tape compression is very important for backup performance. If the tape has good compression, then the sustained backup rate is faster. For example, if the compression ratio is 2:1 and native transfer rate of the tape drive is 6 MB/s, then the resulting backup speed is 12 MB/s.
One of the most interesting issues for backup performance is tape streaming. Almost all tape drives currently on the market are fixed-speed, streaming tape drives. In other words, these drives can only write data at one speed. As a result, when they run out of data to write to tape, they must slow down and stop. For example, when the drive's buffer empties, the tape is moving so quickly that it actually overshoots and must rewind past the point where it stopped writing.
The physical tape block size can affect backup performance. The block size is the amount of data written by media management software to a tape in one write operation. The common rule is that a larger tape block size leads to a faster backup. Note that physical tape block size is not controlled by RMAN or the Oracle server, but by media management software. Larger physical tape block size leads to a faster backup. The physical tape block size is controlled by media management software.
You can set various channel limit parameters that apply to operations performed by the allocated server session in the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands.
You can use these parameters to do the following:
- Limit the size of backup pieces.
- Prevent RMAN from consuming too much disk bandwidth.
- Determine the level of multiplexing for each channel.
You can specify the channel parameters described in Table 14-2.
Table 14-2 Tuning RMAN Channel Parameters
Specifies the maximum size of a backup piece. Use this parameter to force RMAN to create multiple backup pieces in a backup set. RMAN creates each backup piece with a size no larger than the value specified in the parameter. | |
Specifies the bytes/second that RMAN reads on this channel. Use this parameter to set an upper limit for bytes read so that RMAN does not consume excessive disk bandwidth and degrade online performance. For example, set RATE=1500K. If each disk drive delivers 3 MB/second, then RMAN leaves some disk bandwidth available to the online system. | |
Determines the maximum number of input files that a backup or copy can have open at a given time (default value is 8). As explained in "Disk Buffer Allocation", the level of RMAN multiplexing partially determined by MAXOPENFILES. As explained in Table 14-1, the level of multiplexing in turn determines how RMAN allocates disk buffers. Multiplexing is the number of input files simultaneously read and then written into the same backup piece. |
|
The BACKUP command lets you set parameters that influence how RMAN selects files for input into backup sets. You can set these parameters to do the following:
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9599/viewspace-472899/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9599/viewspace-472899/
扫一扫
1442
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
