Oracle RMAN 11g Backup and Recovery (148 page)

Backup media hardware will provide you with a given speed at which the device will read and write. Of course, the faster the device writes, the faster your backups. Also, the more devices you can back up to, the better your backup timing tests will be. This was clearly pointed out in Oracle’s RMAN performance white paper mentioned in the preceding section. The doubling of the number of drives that RMAN could write to causes an almost linear improvement in performance of both backup and restore operations. The ability to parallelize your backups across multiple channels (or backup devices) is critical to quickly backing up a large Oracle database.

RMAN will benefit from parallel CPU resources, but the return diminishes much quicker with the addition of CPUs, as opposed to the addition of physical backup devices. The bottom line, then, is that in most cases, having multiple backup devices will have a much greater positive impact on your backup and restore windows than adding CPUs will.

You will find that most backup devices are asynchronous rather than synchronous. An
asynchronous
device allows the backup server processes to issue I/O instructions without requiring the backup server processes to wait for the I/O to complete. An asynchronous operation, for example, allows the server process to issue a tape write instruction and, while that instruction is being performed, proceed to fill memory buffers in preparation for the next write operation. A
synchronous
device, on the other hand, would have to wait for the backup operation to complete before it could perform any other work. Thus, in our example, the synchronous process will have to wait for the tape I/O to complete before it can start filling memory buffers for the next operation. So, an asynchronous device is more efficient than a synchronous one.

Because asynchronous operations are preferred, you may want to know about a few of their parameters. First, the parameter BACKUP_TAPE_IO_SLAVES (which defaults to FALSE) will cause all tape I/O to be asynchronous in nature. We suggest you set this parameter to TRUE to enable asynchronous I/O to your tape devices (if that setting is supported). Once this parameter is established, you can define the size of the memory buffers that are used by using the
parms
parameter of the
allocate channel
command or
configure channel
command.

The tape buffer size is established when the channel is configured. The default value is OS

specific, but is generally 64KB. You can configure this value to be higher or lower by using the
allocate channel
command. For the best performance, we suggest that you configure this value to 256KB or higher, as shown here:

allocate channel c1 device type

sbt parms "blksize 262144, ENV (NB ORA CLASS RMAN db01)"

If you are backing up to disk, then you need to determine whether your OS supports asynchronous I/O (most do these days). If it does, then Oracle automatically uses that feature.

If it does not, then Oracle provides the parameter DBWR_IO_SLAVES, which, when set to a non-zero value, causes Oracle to simulate asynchronous I/O to disks by starting multiple DBWR processes.

When either DBWR_IO_SLAVES or BACKUP_TAPE_IO_SLAVES is configured, you may also want to create a large pool. This will help eliminate shared-pool contention and memory allocation error issues that can accompany shared-pool use when BACKUP_TAPE_IO_SLAVES is

448
Part III: Using RMAN Effectively

enabled. If you are using Automatic Shared Memory Management (ASMM) Oracle will manage the memory allocation of the shared pool for you. If you want to manually set the large pool, the total size of disk buffers is limited to 16MB per channel. The formula for setting the LARGE_

POOL_SIZE parameter for backup is as follows:

LARGE_POOL_SIZE = (number of allocated channels) * (16MB + (4 * size of tape buffer))
NOTE

If DBWR_IO_SLAVES or BACKUP_TAPE_IO_SLAVES is not configured,

RMAN will not use the large pool. Generally, you do not need to

configure these parameter settings to get good performance from

RMAN, unless your OS does not natively support asynchronous I/O.

Tune the Database

A badly tuned database can have a significant negative impact on your backup times. Certain database tuning issues can also have significant impact on your restore times. In this section, we briefly look at what some of these tuning issues are, including I/O tuning, memory tuning, and SQL tuning.

Tune I/O

Most DBAs understand the impact of I/O on basic database operations. Contention on a given disk drive for database resources (say, for example, that the online redo log and a database datafile are on the same device) can cause significant system slowdowns. Just as poor I/O distribution can impact your database performance, it can also affect your backup and restore times. This makes sense, because RMAN is going to be just another process (or, more likely, many processes due to parallel streams) that contends for I/O time on your devices.

Backing up is a read-intensive operation. If you have poor I/O distribution, not only will RMAN performance suffer, but also other users will suffer, if not even worse, during the backup operation. Recovery may be somewhat easier if all of your recoveries are full database recoveries.

However, if you are just recovering a datafile or a tablespace, while the database is open and in use, you may find that poor I/O distribution impacts your recovery window, and your users. The bottom line is that bad I/O distribution impacts not only your day-to-day database users, but also your backups and recoveries, causing them to take longer.

Much has been written on distribution of I/O on an Oracle database and how to do it properly. We suggest that you take a look at the Oracle white paper titled “Oracle Storage

Configuration Made Easy” (Juan Loaiza, Oracle Corporation, available at www.oracle.com/

technology/index.html). In this paper
, Mr. Loaiza makes a compelling argument for using an I/O

distribution known as Stripe and Mirror Everything (SAME), discusses current disk speeds and feeds, and then demonstrates the logic of his SAME methodology. This methodology recommends that you stripe your data among the largest number of disks possible and suggests this is a much better approach than striping across a few disks or using a parity disk approach, such as RAID-5

(mirroring is, of course, more expensive). Further, this paper recommends that a stripe size of about 1MB is generally optimal and demonstrates that such a configuration in Oracle’s testing resulted in a 13 percent better read/write from the disk than nonstriped systems, with an associated loss in CPU

overhead. This faster disk read/write will translate into faster backup timings.

Tune Memory Usage

Like any Oracle process, RMAN uses memory. When an RMAN operation is started, a buffer is allocated to the operation for RMAN to work out of. The size of the buffer allocated depends on a number of different factors, including the following:

Chapter 18: Performance Tuning RMAN Backup and Recovery Operations
449

■ RMAN backup and recovery multiplexing effects

■ The device type used

■ The number of channels allocated during the operation

Each of these factors affects how much memory RMAN will require. RMAN allocates memory buffers for operations. How it allocates these buffers depends on the type of device you are going to use. Let’s look at the different buffer allocation methods in a bit more detail next.

Allocating Memory Buffers for Disk Devices
When backing up to disk devices, RMAN will allocate up to 16MB of memory. This memory is allocated based on the level of multiplexing (based on the
filesperset
setting). If the level of multiplexing is 4 or less, then RMAN will allocate 16 buffers of 1MB each. These 1MB buffers are divided among the number of datafiles to be backed up. So, if
filesperset
is set to 2, then each datafile will be allocated eight 1MB buffers.

If
filesperset
is between 5 and 8, then 512MB buffers are allocated and distributed evenly between the different datafiles. This way, no more than 16MB of buffers will be allocated. Finally, if the level of multiplexing is greater than 8, four buffers of 128MB will be allocated to each datafile, which amounts to 512KB per datafile.

Allocating Memory Buffers for SBT Devices
When backing up to an SBT device, RMAN

allocates four buffers for each channel that is allocated. These buffers are 256KB in size generally, and thus the total memory allocated per channel is 1MB. The buffer sizes can be managed using the PARMS and BLKSIZE parameters of the
allocate
and
send
commands.

This memory is generally allocated from the PGA, but if the BACKUP_TAPE_IO_SLAVES

parameter is set to TRUE, then the SGA is used unless the large pool is allocated, in which case the large pool will be used. Thus, if you configure I/O slaves (and generally you should if you back up to SBT devices), then you should configure a large pool to reduce the overall memory requirements on the large pool.

Tune Your SQL

You might ask yourself what bad SQL running in your database has to do with performance tuning your backup and recovery times. It’s really quite simple. The negative performance impact of poor SQL statement operations has an overall negative performance impact on your database and the system the database is on. Anything that has a negative impact on your database is likewise going to have a negative impact on your backup operations. Tune your SQL operations such that they reduce the overall number of I/Os required (logical and physical), and schedule your backups to occur during times of typical low system usage (if that is possible).

Tune Your Environment

Carefully consider your backup schedules, and ensure that they do not conflict with I/O-intensive database operations such as data loads or reports. Also, if you find your backups are taking too long, consider an incremental backup strategy, and analyze your database to determine whether certain tablespaces might be made read-only, so you don’t have to continue to back them up often. Further, if you are running in ARCHIVELOG mode, you can consider staggering the backups of tablespaces on different days to reduce the overall timeframe of your backups (at the cost of somewhat longer recovery times, of course).

If you are running your database using Oracle Real Application Clusters, then RMAN can take advantage of the clustered environment to parallelize your RMAN operations.

450
Part III: Using RMAN Effectively

Tune Your Backup and Recovery Strategy

We already talked about tuning when you do your backups, but we also want to discuss tuning how you do your backups. If you have a large database, rather than just issuing a
backup database
command to back up the whole kit and caboodle, consider a more partitioned backup strategy.

Consider backing up related datafiles that you are likely to restore together using individual
backup
tablespace
or
backup datafile
commands, and assign those backups to one specific channel. Why do this? This reduces the need to swap tapes during recoveries and allows the recovery of related datafiles to occur as quickly as possible. Here is an example of such an operation: RMAN> backup (tablespace tools channel 'ORA DISK 1')

(tablespace system, undotbs, users, testrbs, indx);

We might want to do this if we are backing up a read-only tablespace that we might later want to recover, or perhaps we have a tablespace that we seem to do frequent tablespace pointin-time recoveries (TSPITRs) on. These would be good candidates for such backup strategies.

Oracle Database 11
g
offers a new feature that can be used to help tune your backup and recovery strategies. With normal RMAN backups, a given datafile can only be backed up via one channel. This means that if you have several smaller datafiles and one or two large datafiles, the single channel per backupset rule can cause the backup or restore to take longer. Using multisection backups, you can spread the I/O for the single datafile over more than one channel, which can significantly speed up the backup process.