The tape
native transfer rate is the write speed 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 the tape drives. If
the backup is performing at that rate, and an excessive amount of CPU is not
being used, then tuning RMAN does not help.
Tape
compression greatly affects 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 the native transfer rate of the tape drive is 6 MB
per second, then the resulting backup speed is 12 MB per second.
Almost all
tape drives currently in the market are fixed-speed, streaming tape drives—that
is, these drives can write data only 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 the backup performance. The block size is
the amount of data that is written by the 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. The physical tape block size is controlled by the media
management software.
If the tape
device is attached as a network device, then the network speed may affect tape
access speed also.
Tape
Subsystem Performance Rules
You can
speed up the backup and restore processes by buying more tape drives, faster
tape drives, or ideally a combination of the two. It is a waste of system
resources to allocate more than one channel per tape drive. If more channels
than physical drives are used, then the backup sets will be intermingled. This
can adversely affect the time it takes to restore selected files.
If a tape
drive is not streaming, increasing the number of files multiplexed together may
help. Remember that if a small subset of files in a backup set must be
restored, the restore will take longer if many files are multiplexed into the
backup set. Put just enough files into each backup set to keep the tape drives
streaming. It is better to store files that are likely to be restored together
in the same backup set.
If you
specify a smaller value for the FILESPERSET option when making your backup,
then the restore times are likely to be less, with the possible disadvantage of
the backup taking longer.
Controlling
Tape Buffer Size with BLKSIZE
If the tape
is not streaming, but the problem is not due to an incremental backup or by the
backing up of empty files, then try adjusting the block size of the tape
buffer. You can change the size of each tape buffer by using the PARMS
parameter of the ALLOCATE CHANNEL or CONFIGURE CHANNEL command. If the BLKSIZE
parameter for PARMS is supported on your platform, then you can set it to the
desired size of each buffer. For example, configure an SBT channel as follows:
RMAN> CONFIGURE CHANNEL
DEVICE TYPE SBT
> PARMS="BLKSIZE=1048576";
Tuning
RMAN Tape Streaming Performance Bottlenecks
To identify
and remedy bottlenecks that affect RMAN’s performance on tape backups, perform
the following actions :
•
Use
BACKUP... VALIDATE to determine whether tape streaming or disk I/O is the
bottleneck in a given backup job. Compare the time required to run backup tasks
with the time required to run BACKUP VALIDATE of the same tasks. BACKUP
VALIDATE of a backup to tape performs the same disk reads as a real backup but
performs no tape I/O. If the time required for the BACKUP VALIDATE to tape is
significantly less than the time required for a real backup to tape, then
writing to tape is the likely bottleneck.
•
Use
multiplexing to improve tape streaming with disk bottlenecks. In some
situations when RMAN is performing a backup to tape, it may not be able to send
data blocks to the tape drive fast enough to support streaming. For example,
during an incremental backup, RMAN backs up only blocks changed since a
previous data file backup as part of the same strategy. If you do not enable
change tracking, RMAN must scan entire data files for changed blocks, and fill
output buffers as it finds such blocks. If there are not many changed blocks,
RMAN may not fill output buffers fast enough to keep the tape drive streaming.
You can improve performance by increasing the degree of multiplexing used for
backups. This increases the rate at which RMAN fills tape buffers, which makes
it more likely that buffers are sent to the media manager fast enough to
maintain streaming.
•
Use
incremental backups to improve backup performance with tape bottlenecks. If
writing to tape is the source of a bottleneck for your backups, consider using
incremental backups as part of your backup strategy. Incremental level 1
backups write only the changed blocks from data files to tape, so that any
bottleneck on writing to tape has less impact on your overall backup strategy.
In particular, if tape drives are not locally attached to the node running the
database being backed up, then incremental backups can be faster.
