Oracle RMAN 11g Backup and Recovery (149 page)

Another issue to consider is the impact of your backup strategy on your recovery. One of the more painful problems with RMAN is that, depending on the platform (Unix is one example; the following three paragraphs do not apply to Oracle on Windows NT), if you restore an entire database with the
restore database
command, you must be careful to ensure that enough space is available for the restore. Everything is just fine as long as you have enough disk space, but consider for a moment a true disaster recovery situation where you do not have enough disk space in the right places. In this case, RMAN is going to spend perhaps an hour or more recovering your database. Once it runs out of disk space, you would assume that RMAN would just stop at that point, alert you to the lack-of-space problem, and then just stop the restore at that position. The truth, however, is a bit more painful.

If the datafile restore process fails, RMAN removes every incompletely restored file from that restore session. Thus, if you spend two hours restoring all but one database datafile and then you run out of space during that restore, you are in deep trouble, because RMAN is now going to remove that one datafile, and you will have to restore it again. This equates to a very unhappy DBA.

One solution to this problem is to restore specific tablespaces with different
restore
commands for each tablespace (or for a number of tablespaces). This allows you to restore your database datafiles in a bit more granular fashion, and the failure of one operation will not cause you to lose hours. Of course, if you use this type of operation, you will want to parallelize the restores and utilize multiple tape or disk devices to reduce contention and tape streaming issues. In this case, you need to run parallel RMAN sessions, each restoring its own set of tablespace data. Note that this type of restore operation is another reason why it’s important to try to back up clusters of files that you will likely need to restore on the same channel. That way, you can stream the data off the tape quickly.

Note that some platforms, such as Windows NT, do check for available space before you actually start an RMAN database, datafile, or tablespace restore. In this case, the issue of running out of space, while still a problem, is not as much of a time waster.

Chapter 18: Performance Tuning RMAN Backup and Recovery Operations
451

Tuning RMAN

As we stated at the beginning of the chapter, RMAN out of the box really works pretty well. Still, you can do a few things to tune it so that you get better performance, which is what this section is all about. First, we discuss the tuning options in RMAN itself. Then, we discuss some MML tuning issues.

Tuning RMAN Settings

There are a few ways to tune RMAN, which we discuss in this section. Tuning RMAN itself can involve tuning parallel operations and also configuring RMAN to multiplex (or not to multiplex, that is the question). This section also covers some things that you can do to actually tune down RMAN.

Parallel Channel Operations

Perhaps the biggest impact you can make when tuning your database backups is to parallelize them by using multiple RMAN channels. Typically, you configure a channel for each device you are going to back up to. Thus, if you back up to three different disks, configure three different channels. You will see little or no benefit of paralleling backups on the same device, of course; so if you have a D: drive and an E: drive on your Windows NT system but both are just partitioned on the same disk, you will derive no benefit from paralleling backups to those two devices.

NOTE

The memory buffering on tape systems may well make the allocation

of additional channels worthwhile, so you should always do some

timing tests to decide exactly how many channels you need to use on

your system.

Paralleling backups is accomplished by allocating channels to the backup. Channels can have default values configured for them (along with the default degree of parallelization that will determine how many of the channels are used) with the
configure
command, discussed in Chapter 3. For example, if we have two tape devices that we are going to back up to, we’d likely configure two default channels and a default level of parallelization, as shown here: CONFIGURE DEVICE TYPE DISK PARALLELISM 2;

CONFIGURE CHANNEL 1 DEVICE TYPE sbt FORMAT PARMS

'ENV (NB ORA CLASS RMAN rs100 tape)';

CONFIGURE CHANNEL 2 DEVICE TYPE sbt FORMAT PARMS

'ENV (NB ORA CLASS RMAN rs100 tape)';

This would serve to ensure that each
backup
or
recover
command is automatically allocated two channels to parallelize the process.

Of course, depending on your device, you may well be able to run parallel streams to the device. The best thing to do is run several tests and determine from those tests the performance of a varying number of backup streams from both a backup and a recovery point of view. It may be that a different number of streams will be more efficient during your backup than during your recovery, and only testing will determine this.

452
Part III: Using RMAN Effectively

We have already discussed the multiplexing of backups in RMAN and how to tune this feature. Tuning multiplexing can have significant performance impacts on your backups and recoveries. As we also discussed earlier, how you configure your multiplexing will impact the amount of memory that is allocated to the RMAN backup process. The more memory the better, as long as you do not start to induce swapping back and forth to disk.

Also, properly configuring multiplexing can make streaming to tape devices more efficient.

The more memory you can allocate to RMAN, the more data that can be streamed to your I/O

devices. Finally, tape streaming is rarely an issue with newer-generation tape drives. Generally, they have a great deal of onboard buffer memory that is used to ensure that the tape is written to at a constant rate.

RMAN Multiplexing

Before we dive headfirst into performance considerations, we should take a moment to discuss multiplexing in RMAN.
Multiplexing
allows a single RMAN channel to parallelize the reading of database datafiles during the backup process and to write the contents of those datafiles to the same backup set piece. Thus, one backup set piece may contain the contents of many different datafiles.

Note that the contents of a given datafile can reside in more than one backup set piece (which is evidenced by the fact that you can set
maxpiecesize
to a value smaller than that of any database datafile, but
maxsetsize
must be at least the size of the largest tablespace being backed up). However, in a given backup, a given datafile will only be backed up through one channel (or one backup set). Thus, if you allocate two channels (and, as a result, have two backup sets) and your database consists of one large datafile, the ability of RMAN to parallelize that datafile’s backup will be greatly limited.

The level of RMAN’s multiplexing is determined by the lesser of two RMAN parameters.

The first is the
filesperset
parameter (established when you issue the
backup
command), and the second is the
maxopenfiles
parameter (established when the channel is allocated).

The
filesperset
parameter establishes how many datafiles should be included in each backup set. The number of datafiles in a given backup set will be some number less than or equivalent to
filesperset
. When you do a backup, RMAN will assign a default value for
filesperset
of either 64

or the number of input files divided by the number of allocated channels, whichever is less. You can use a nondefault value for
filesperset
by using the
filesperset
parameter of the
backup
command, as shown in this example:

backup database filesperset 4;

The
maxopenfiles
parameter establishes a limit on how many datafiles RMAN can read in parallel (the default is 8). You establish the
maxopenfiles
limit on a channel-by-channel basis.

Here is an example of the use of
maxopenfiles
:

CONFIGURE CHANNEL 1 DEVICE TYPE DISK MAXOPENFILES 3 FORMAT

"d:\backup\recover\%U";

For example, if you created a backup set with
filesperset
set to 6 and
maxopenfiles
set to 3, RMAN would only be able to back up three datafiles in parallel at a time. The backup sets created would still contain at most six datafiles per backup set (assuming one channel is allocated and a degree of parallelism of 1), but only three datafiles would be written to the backup set at any time.