Oracle RMAN 11g Backup and Recovery (163 page)

Chapter 21: RMAN and Real Application Clusters
507

your volume manager for all your RAC files. Then, you can create a second disk group and deploy your flash recovery area (FRA) to the disk group. With an FRA on an ASM disk group, managing archive logs in RAC is essentially the same as managing them in a single-thread environment. If you configure the database to archive to the FRA, both nodes will deposit the logs in a single location where they are visible to both nodes at all times. Managing archive logs during cleanup operations is no different than managing them on a single-thread database.

RAC Recovery Challenges

Perhaps more confusing than getting backups done is getting restore and recovery tasks taken care of in a RAC environment. Again, this is due to the complex nature of a database that has multiple instances. The challenges can be roughly divided into three areas: restore operations, media management considerations, and recovery challenges.

Restore Operations

When performing a restore from RMAN, we must point out again that RMAN can connect to only one node, but then can allocate channels at each node. This should sound pretty familiar by now; but that’s not the tricky part. The part that hangs people up is keeping track of where files were backed up from.

File accessibility is the key to restore success on an RAC node. If you have been backing up to disk using channels allocated at each node, you must allocate the same channels at each node during a restore operation. This is not a problem, unless you’ve lost a node. If the node is down, your disk backups on that node are inaccessible and restore operations will fail. The lesson is, if you’re spending all this time and money on RAC so that you don’t have a single point of failure, make sure you apply this philosophy to your backup and recovery strategy, as well. If you back up to disk, duplex the backup to more than one node. This might mean overriding the default autolocate feature so that you can specify where exactly you want your backups to be backed up from. You do this by specifying the channel for datafile sets:

configure default device type disk;

configure device type sbt parallelism 2;

configure channel 1 device type disk

connect 'sys/password@prod1';

configure channel 2 device type disk

connect 'sys/password@prod2';

backup (datafile 1,2,3,4,5 channel ORA DISK 1)

(datafile 6,7,8,9,10 channel ORA DISK 2);

# then switch the channels for the datafiles

backup (datafile 1,2,3,4,5 channel ORA DISK 2)

(datafile 6,7,8,9,10 channel ORA DISK 1);

Here, again, ASM will save you time and energy. More to the point, running an FRA on a shared ASM disk volume makes disk backups in a RAC environment simple and requires little configuration beyond what you normally do for a single-thread database. Using an FRA on ASM

allows you to take advantage of job multiplexing across your nodes, yet still to have all the backups end up in a location that is always accessible by other nodes during restore. So you no longer need to fear that a disk backup might be left inaccessible on a downed node. Nor do you need to fear a single point of failure, because ASM comes with automatic redundancy, so you can mirror your FRA and have a duplexed copy of your backup without any additional work.

508
Part IV: RMAN in the Oracle Ecosystem

Media Management Considerations During a Restore

Another way to make your backups available to all nodes during a restore is to back up to tape and to use a centralized media management server to house your tape backups. If you have tape devices at each node and use them all for tape backup, you’re increasing the degree of complexity unnecessarily. If you lose a node in your cluster, you then lose the media management catalog for all backups taken from that node. Chances are that your media management product has an automatic catalog backup, but then you have another restore to do, and where do you do it, and when? You need the catalogs at both of your other nodes for their backup information. So, you have a disaster that is fixable, but valuable minutes are racing by as you stick your nose in manuals, trying to figure it all out.

We prefer to use a centralized media management system, so that all nodes can back up to tape devices that are all managed by the same media manager server, so that there is a single media management catalog. That way, when a node is lost, you can simply specify the client name in your RMAN channel and do the restores to a different node. This brings us to the most important note to remember when you use RMAN to restore your backup from tape: you must consider the node from which RMAN made the backup when doing the restore.

As an example, suppose that in our two-node cluster, we have lost node winrac2, and the disaster that took it out also corrupted some of our datafiles. We’ve been employing a backup strategy that allocates channels at both nodes to perform the backup, so our restore is going to have to allocate channels from both nodes. Oops! No chance of that! Instead, we can allocate two kinds of channels at winrac1: normal tape channels and channels that specify the client as winrac2. It would look something like this:

configure default device type sbt;

configure device type sbt parallelism 2;

configure channel 1 device type sbt

parms "env (nb ora serv rmsrv)";

configure channel 2 device type disk

parms "env (nb ora serv rmsrv, nb ora client winrac2)";

restore datafile 5,12,13,18;

This is obviously a very simple example of what can be a complex headache. We recommend a backup approach that takes datafile backups from only a single node in the cluster. If the size of your database prohibits such a simplistic approach, try to at least restrict RMAN to a small subset of your nodes. By doing so, you keep the complexity down when it comes time to perform restore operations.

Another option is to first stage your backups to a disk location using an FRA on an ASM disk volume. If you have the space on the disk array to stage your backups to disk first, your ultimate move to tape can happen from one or more nodes at a more controlled time. Using the
backup
recovery area
command would allow you to take a consolidated set of backups from the FRA and move them all to tape in a separate operation. This tape operation could occur from any node or any combination of nodes. If you did the tape backup from a single node, then the SBT channel parameters would be simplified during the restore, even if a different node were responsible for the restore.

Recovery Considerations After a Restore

After you get your files restored, it’s time to perform media recovery by applying archive logs.

Media recovery in a RAC environment has one rule that you must never forget:
only one node

Chapter 21: RMAN and Real Application Clusters
509

can perform recovery.
Burn it into your brain. This means that one node must have access to all the archive logs on disk. So, if you have been using an archive log strategy that has each node holding its own archive logs in a local disk, you must make that local disk available to the recovery node. You can do this via NFS, if you followed the guidelines specified in “Archive Log Backups” earlier in this chapter. You simply mount the archive log destination of the other node and issue your recover statement from within RMAN. If you’re using CFS, this is not a problem, and you can ignore all this. If you are using an FRA on ASM, again, access to all archive logs is not an issue.

If you have archive logs that you need to restore from RMAN backups, the same rules and guidelines apply to archive logs that apply to datafile restores. If you allocated channels at each node for the backup, then you need to do so for the restore as well. If you are missing a node, you have to allocate a channel that includes the client name so that the media manager can find the proper backups (see the preceding section, “Media Management Considerations During a Restore”).

In addition, you may have to restore the archive logs to a directory that exists locally if the LOG_

ARCHIVE_DEST parameter that existed on the missing node does not exist on the node doing the restore operation:

restore archivelog like '%prod2%' to '/u04/prod1/arch%';

While only one node can perform recovery with RMAN, RMAN does media recovery in parallel. You cannot control this level of parallelism, other than to turn it off: rman> Recover database noparallel;

By default, though, RMAN automatically selects the degree of recovery parallelism based on the number of available CPUs on the node performing recovery.

Advanced RMAN/RAC Topics

Once you have determined what your backup and recovery strategies will be for your RAC database, you can consider many of the same benefits that RMAN offers you in a single-node database environment: block corruption checking, null compression, block media recovery—all of these benefits are yours in a RAC environment. Advanced functionality such as database duplication exists as well. RMAN backups of RAC databases work for duplication and standby database creation, just as they would for a single-node system. We have some caveats, however, which we discuss next.

Duplication to a Single-Node System

If you administer a RAC cluster and aren’t convinced yet that RMAN is the right tool for you, here’s a little something to seal the deal: you can use your RMAN backups of your RAC database to create a clone of your RAC database on a single-node database. This gives you a copy of your production database without having to purchase and administer a second RAC cluster. Instead, you have a single-node database running on a cooked file system.

In fact, RMAN cannot actually duplicate from one RAC cluster to another RAC cluster. It can duplicate only to a single-thread database. However, once the database is duplicated, you can easily turn the clone database into a RAC database. Just make sure that you duplicate to an ASM

disk group on a node that already has CRS installed.

510
Part IV: RMAN in the Oracle Ecosystem

RMAN Workshop:
Duplicating a RAC Database

to a Single-Node Database

Workshop Notes

This workshop creates a single-node clone of a two-node database. You can do this either to a new server or to a cooked file system on one of the nodes of the RAC cluster. This example duplicates to a file system on one of the nodes in the RAC cluster. Because duplication must perform recovery, you must remember that a recovery session has access only to the node on which the recovery is being performed, so that node must have access to all the nodes’ archive logs. This workshop assumes that you have NFS mounted the archive destination of each node on each other node so that a full copy of each archive log stream is available at every node.

The two nodes of our cluster are opcbs01 and opcbs02, with instances of V112A and V112B, respectively. We will be connecting to V112B for all RMAN operations.

Step 1.
Build your auxiliary database directory structures:

mkdir /u02/32bit/app/oracle/oradata/aux1