Tuning I/O for RMAN Backups when using Tape Device

Tuning I/O for RMAN Backups when using Tape Device

Tuning the BLKSIZE parameter in an Oracle RMAN backup script is a key aspect of optimizing backup and restore performance, particularly when backing up to tape (SBT) devices.

The BLKSIZE parameter determines the size of the I/O buffers used by RMAN, and a larger block size can significantly improve performance by allowing more data to be transferred in a single I/O operation.

How to Set the BLKSIZE Parameter

You can set the BLKSIZE parameter within your RMAN script using the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. The BLKSIZE is specified in bytes.

Here are examples of how to set it:

 

1. Using CONFIGURE CHANNEL (for persistent settings):

This command configures the BLKSIZE for all future RMAN sessions for the specified device type.

CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='BLKSIZE=1048576';

In this example, the BLKSIZE is set to 1MB (1024 * 1024 bytes).

2. Using ALLOCATE CHANNEL (for the current RMAN job):

This command sets the BLKSIZE only for the channels allocated within the current RUN block.

RUN {

  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='BLKSIZE=524288';

  BACKUP DATABASE;

}

Here, the BLKSIZE is set to 512KB (512 * 1024 bytes) for channel c1.

           Best Practices and Considerations for Tuning BLKSIZE

• Backup to Tape (SBT): The BLKSIZE parameter is primarily effective for backups to tape devices. For disk backups, RMAN's default buffer sizes are generally adequate, and other tuning methods are more effective.
• Match Media Manager Settings: For optimal performance, the BLKSIZE in your RMAN script should match the block size configured in your media management software (e.g., NetBackup, Commvault). A mismatch can lead to performance degradation.
• Recommended Values: While the optimal BLKSIZE can vary depending on your hardware and environment, a common starting point is 256KB, with many administrators finding success with values of 512KB, 1MB, or even larger.
• LARGE_POOL_SIZE: When you increase the BLKSIZE, you may also need to increase the LARGE_POOL_SIZE in your database's initialization parameters. This is because RMAN allocates I/O buffers from the Large Pool when using I/O slaves.
• Asynchronous I/O: To prevent I/O from becoming a bottleneck, ensure that asynchronous I/O is enabled at the operating system level. If it's not supported, you can simulate it by setting the DBWR_IO_SLAVES and BACKUP_TAPE_IO_SLAVES initialization parameters.
• Monitoring and Testing: The key to successful tuning is to monitor your backup performance and test different BLKSIZE values. You can use V$ views like V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO to identify bottlenecks.

 

Tune RMAN output buffer size

Ø Output buffers => blocks written to DISK as copies or backup pieces or to SBT as backup pieces

Ø Four buffers allocated per channel

Ø Default buffer sizes

o   DISK: 1 MB

o   SBT: 256 KB

Ø Adjust with BLKSIZE channel parameter

Ø Set BLKSIZE >= media management client buffer size

Ø No changes needed for Oracle Secure Backup

 

Other RMAN Performance Tuning Factors

While BLKSIZE is important, it's just one piece of the puzzle. For comprehensive RMAN performance tuning, consider these additional factors:

• Multiplexing: Adjusting the level of multiplexing, which is the number of input files read simultaneously, can improve performance, especially when tape drives are not being kept busy.
• Number of Channels: Allocating an appropriate number of channels, typically between 50% and 75% of the number of CPU cores, can help parallelize the backup process.
• RATE Parameter: The RATE parameter can be used to limit the I/O bandwidth that RMAN consumes, which can be useful to avoid impacting other database operations. However, for maximum backup speed, this parameter should generally be removed.
• The RATE parameter on a channel is intended to reduce, rather than increase, backup throughput so that more disk bandwidth is available for other database operations. If the backup is not streaming to tape, then confirm that the RATE parameter is not set.
• FILESPERSET: This parameter controls the number of files in each backup set. Finding the right balance can optimize performance and media usage.

 

•  Enable Asynchronous I/O (or I/O Slaves)
• Why it's critical for SBT: This is arguably the most important setting for tape backups. Asynchronous I/O allows RMAN to write data to the tape buffer without waiting for the I/O operation to complete. While one buffer is being written to tape by the media manager, RMAN can be filling the next buffer with data from the database. This creates a smooth, continuous data stream that keeps the tape drive constantly spinning, which is exactly what you want for maximum throughput.
• What happens without it: With synchronous I/O, RMAN fills a buffer, sends it to the media manager, and then waits for the write to complete before it starts filling the next buffer. This pause is often long enough for the tape drive to stop, leading to poor performance.
• Increase LARGE_POOL_SIZE
• Why it's critical for SBT: The buffers used by asynchronous I/O are allocated from the Large Pool. If the Large Pool is too small to hold all the buffers for all your channels, RMAN will fail to allocate them and may revert to synchronous I/O (using the PGA), completely negating the benefits. A generously sized Large Pool is the foundation for high-speed tape backups.
• Calculation: A rough formula to estimate the required size is: LARGE_POOL_SIZE = (number_of_channels * (4 * BLKSIZE)) + overhead for example, with 4 channels and a 1MB BLKSIZE: 4 * (4 * 1048576 bytes) ≈ 16 MB. It's wise to add a significant buffer (e.g., 50-100MB or more) on top of this for other Large Pool uses. Starting with 256MB or 512MB is a safe bet for most environments.
• Increase Parallelism (Channels)
• Why it's critical for SBT: A single CPU core might not be able to read data from the database files fast enough to keep a modern, high-speed tape drive busy. By allocating multiple channels, you parallelize the work of reading data blocks and feeding them to the media manager. This helps ensure the data pipeline is always full.
• Consideration: The number of channels should not exceed the number of physical tape drives you intend to use for the backup, unless your media manager can multiplex multiple streams to a single drive. The goal is to match RMAN's output rate to the tape drive's write capacity.
• Tune BLKSIZE
• Why it's critical for SBT: This parameter is specifically designed for tape devices. Tape drives are block devices that perform best with large I/O operations. A larger BLKSIZE (e.g., 256KB, 512KB, 1MB) means RMAN sends more data in a single I/O call, which is far more efficient for tape.
• Crucial Alignment: It is vital that the BLKSIZE you set in RMAN matches the block size configured in your media management software (e.g., NetBackup, Commvault, etc.). A mismatch can force the media manager to re-buffer the data, adding overhead and slowing down the backup. Check your media manager's documentation for its recommended or default block size.

 

Conclusion for SBT Backups

For SBT backups, these recommendations are not just "good," they are the standard best practices for achieving high performance. Failing to implement them, especially asynchronous I/O and a properly sized Large Pool, will almost certainly result in backups that are significantly slower than what your hardware is capable of.

By systematically evaluating and adjusting these parameters, including BLKSIZE, you can significantly improve the efficiency of your Oracle RMAN backup and recovery operations.

Monitoring & Troubleshoot

Query V$BACKUP_ASYNC_IO and Check EFFECTIVE_BYTES_PER_SECOND column (EBPS) for row where TYPE = 'AGGREGATE'.

    If EBPS < storage media throughput, run BACKUP VALIDATE

  

Ø Case 1:

 BACKUP VALIDATE time ~= actual backup time, then read phase is the likely bottleneck.

Refer to RMAN multiplexing and buffer usage guidelines

Investigate ‘slow’ performing files: find data file with highest (LONG_WAITS / IO_COUNT) ratio

    If ASM, add disk spindles and/or re-balance disks

    Move file to new disk or multiplex with another ‘slow’ file.

  

Ø Case 2:

     If BACKUP VALIDATE time << actual backup time, then buffer copy or write to storage media phase is the likely bottleneck.

Refer to backup compression and encryption guidelines

If tape backup, check media management (MML) settings

§  TCP/IP buffer size

§  Media management client/server buffer size

§  Client/socket timeout

§  Media server hardware, connectivity to tape

§  Enable tape compression (but not RMAN compression)

 

Write Phase for System Backup Tape (SBT)

When backing up to SBT, RMAN gives the media manager a stream of bytes and associates a unique name with this stream. All details of how and where that stream is stored are handled entirely by the media manager. Thus, a backup to tape involves the interaction of both RMAN and the media manager.

RMAN Component of the Write Phase for SBT

The RMAN-specific factors affecting the SBT write phase are analogous to the factors affecting disk reads. In both cases, the buffer allocation, slave processes, and synchronous or asynchronous I/O affect performance.

Allocation of Tape Buffers

If you back up to or restore from an SBT device, then by default the database allocates four buffers for each channel for the tape writers. The size of the tape I/O buffers is platform-dependent. You can change this value with the PARMS and BLKSIZE parameters of the ALLOCATE CHANNEL or CONFIGURE CHANNEL command.

Allocation of Tape Buffers

Tape I/O Slaves

RMAN allocates the tape buffers in the System Global Area (SGA) or the Program Global Area (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. Tape devices can only be accessed by one process at a time, so RMAN starts as many slaves as necessary for the number of tape devices. If the LARGE_POOL_SIZE initialization parameter is also set, then RMAN allocates buffers from the large pool. If you set BACKUP_TAPE_IO_SLAVES=false, then RMAN allocates the buffers from the PGA.

If you use I/O slaves, then set the LARGE_POOL_SIZE initialization parameter to dedicate SGA memory to holding these large memory allocations. This parameter prevents RMAN I/O buffers from competing with the library cache for SGA memory. If I/O slaves for tape I/O were requested but there is not enough space in the SGA for them, slaves are not used, and a message appears in the alert log.

The parameter BACKUP_TAPE_IO_SLAVES specifies whether RMAN uses slave processes rather than the number of slave processes. Tape devices can only be accessed by one process at a time, and RMAN uses the number of slaves necessary for the number of tape devices.

Synchronous and Asynchronous I/O

When an SBT channel reads or writes data to tape, the I/O is always synchronous. For tape I/O, each channel allocated (whether manually or automatically) corresponds to a server process, called here a channel process.

Synchronous Tape I/O

 

 

*****************************************************************