Oracle RMAN 11g Backup and Recovery (166 page)

recover database using backup controlfile until cancel;

If you will be mounting the Oracle database on the split mirror volume for reporting purposes, you may want to use the
using backup controlfile
command, even if you will not be applying any archive logs, just so the control file is flagged as a backup. We discuss this later in the section

“Benefits of the Split Mirror Backup.”

Redo Log Files

Split mirror copies of the online redo logs are useless in every way, shape, and form. If possible, don’t even bother putting them on the volume that is going through the sync and split. There is no mechanism in the online redo logs to account for writes to the file during the split operation.

Archive Logs

Archive logs are an excellent candidate to be put on a sync and split volume. Doing so gives you a backup of existing archive logs on disk in a second location. Of course, if you split the archive log volume at the same time as the datafile volume, you do not get all the redo that you need to properly recover your database from the split volume. We suggest that you keep your archive logs on a separate set of sync and split volumes from the set on which you keep your datafiles and Chapter 22: RMAN in Sync and Split Technology
523

control files. That way, you can split the datafiles, take the database out of hot backup mode, force a log switch, and then split the archive log volumes. Then the split mirror volume with the archive logs contains all of the redo required to start the split mirror copy of the database.

One last note on archive logs on split mirror volumes. When the database begins to create an archive log on disk, the split operation may leave behind an unfinished archive log on the split mirror volume. This archive log would be unusable during any recovery operation. This poses a problem only for human-managed backup and recovery operations, where it is unknown if the archive log that is on-disk is complete or only half-written. Here’s why it doesn’t pose a problem for RMAN: When an archive log is being generated, the control file is not updated with a record that such an archive log exists until the archive log is complete. Therefore, in a split mirror scenario, if half of an archive log is generated on the split volume, the control file on the split volume has no record of that archive log. During an RMAN operation, then, the control file would be consulted for archive log records, and the half-written file would not exist in the metadata. To RMAN, the half-written file doesn’t really exist.

Benefits of the Split Mirror Backup

We’ve discussed briefly the primary benefit of using the sync and split architecture: a nearly instantaneous fallback recovery point for all files on a particular set of disks. This benefit expands beyond the scope of this book (the Oracle database) to include a fallback point for all files that exist on the volume. There are also other primary benefits of the sync and split, which are discussed next.

Fast Point-In-Time Recovery

From the database perspective, sync and split provides a point-in-time recovery option that can take minutes instead of hours. You simply change the primary disk group to the split mirror, and the datafiles are ready. Then, apply archive logs up to the point where the failure occurred, and you can open the database.

Speedy-Looking Backups

Another benefit of the sync and split architecture is the relative speed of the backup operation itself. Properly generating copies of the database files at the split mirror side takes only a few moments with the database in hot backup mode. After that, a backup is ready to be pressed into service very quickly. Of course, there’s no magic involved with sync and split. I/O is I/O is I/O. It might look like the backup is taking no time at all, but in reality the backup is being taken all the time at the hardware level, because prior to the split operation, the files are being written to simultaneously. However, handing the backups over to the hardware architecture can prove to be extremely powerful in many organizations, where the hardware can be responsible for backing up more than just the database.

Mounting a Split Mirror Volume on Another Server

Beyond the simplistic restore and recovery features, much of the true power of sync and split solutions currently in the marketplace comes from what you can do with the split copy of the database. Because the underlying hardware is likely to be a storage array with many computers connected to it, any volume on that storage array can theoretically be associated with any computer connected to it.

524
Part IV: RMAN in the Oracle Ecosystem

For example, let’s take a database, PROD. PROD resides on disks in volume A, which is mirrored on volume B. Both volume A and B are connected to server Dex. Volumes A and B both exist on storage array Newton. At 2 P.M., volume B is split from volume A and disassociated from server Dex. Immediately after this, volume B is mounted on a different server, Proto, which is also connected to storage array Newton. After volume B is mounted on Proto, a copy of the database PROD that resided on Dex now resides on Proto, with almost real-time amounts of data. The database copy that is on volume B, and mounted by server Proto, can be recovered and then opened for testing, development, or reporting. Later, at 6 P.M., when it is time to resilver volume B with volume A, Proto can dismount volume B, and then it can be remounted by Dex. The sync operation takes place, overwriting any changes that occurred on volume B after the split at 2 P.M.

Note that before you can open a split mirror copy of the database on a different node, a new backup control file should be taken and used. When you resilver volume B with volume A, this new copy will be overwritten by the correct file on A.

Taking Backups from the Split Mirror

Another benefit of sync and split backups, within the framework of this book about RMAN, is the ability to mount the split volume on a different server and, from there, back up the database to tape for long-term backup storage. This allows you to offload the memory, CPU, and I/O operations of the RMAN backup to a completely different server and ensure that there is no impact to your production database.

RMAN and Sync and Split

There are a few different contact points that RMAN has with a sync and split implementation:

■ If you use RMAN for recovery, you must make RMAN aware of the datafile copies that are created by the split operation.

■ You can use RMAN to take backups from the split mirror volume instead of from the production database itself.

Registering Split Mirror Copies with RMAN

If you are a dedicated RMAN user, then you probably understand the benefits that come from executing all recovery statements from within RMAN, instead of from SQL*Plus or elsewhere.

RMAN recovery provides access to the information in the control file so that you are not scrambling to uncover which backups exist where and trying to ensure that you are not missing any files. The control file also aids in archive log management during recovery. When a sync and split system is in place, RMAN doesn’t know about everything. The act of splitting the mirror volumes effectively gives you a full datafile copy of every datafile in the database that can be used during a restore/

recovery operation, but RMAN has no idea these copies exist.

So, you have to make RMAN aware. You do this by registering the datafile copies with RMAN

via the
catalog
command. The
catalog
command can be used against a single datafile copy: catalog datafilecopy '/volumeA/oradata/system01.dbf';

Or, starting with 10
g,
you can catalog an entire directory by the directory name: catalog start with '/volumeA/oradata';

Chapter 22: RMAN in Sync and Split Technology
525

By using the
catalog
command, you take the split mirror copies and make them part of any future restore or recovery operation that might be required.

You might be asking yourself, “Why do I need to make RMAN aware of the split mirror copies when I can just remount the entire volume as the primary volume and be up and running without RMAN’s help?” A valid question. But what if it makes more sense to switch to only a single copy of the file? Perhaps doing a full database point-in-time recovery would be too expensive, but you still want to leverage the split mirror copy of a subset of files. Beyond that, RMAN also greatly simplifies the recovery stage of any operation, so it makes sense to make RMAN aware of the copies of the archive logs, as well.

Taking RMAN Backups from the Split Mirror

With increasing frequency, DBAs are realizing that with split mirror investments, an additional layer of protection is required, in the form of RMAN backups of the database. The split mirror backup is by definition a short-lived copy—sooner or later, it will be lost when the volume is resilvered with the primary database volume. But what about restoring from last night? Or last week? As you can see, a full-fledged media backup is still required.

With an idle copy of the database simmering on the back burner of the split mirror, a light bulb appears above the DBA’s head: “I should just mount the split mirror drive onto a different server, and take the RMAN backup from the split mirror directly to tape (or to a different disk volume that can be mounted on the primary).” Great idea! Sounds simple enough, right? Well, a few tricky points need to get worked out first; otherwise, you will have the case of the mysteriously disappearing backups.

Here’s the problem: RMAN accesses the control file to determine what to back up, and after the backup is complete, it updates the control file with the details of the backup. If you are connected to a split mirror copy of the control file, that copy gets updated with the details about the backup. So then, of course, when you go to resilver the split volume with the primary, the control file is overwritten with the data in the primary control file, and the backup data is lost forever.

The solution, you figure, is to use a recovery catalog when you back up at the split mirror.

That is a sound, logical decision: after the backup is complete, the split volume control file is updated with the backup records, which are then synchronized to the catalog. Then, it’s simply a matter of syncing the catalog with the primary volume so that the backups can be used. Too cool!

So, suppose that you back up from the secondary volume, you sync the backup records to your recovery catalog, and then, you connect RMAN to the primary volume database and to the catalog. You perform a resync. This is where things get really, really weird. Sometimes, when you try to perform an operation, you get this error:

RMAN-20035: invalid high recid

Other times, things work just fine, it seems, but the backups you took at the split mirror database have disappeared from the recovery catalog.

The problem, now, has become the internal mechanism of how RMAN handles record building in the control file and the recovery catalog. Every record that is generated gets a record ID (RECID), which is generated at the control file. When the backup occurs at the split mirror database, the control file gets its high RECID value updated, and this information gets passed to the catalog. But the RECID at the primary database control file has not been updated, necessarily.