Oracle RMAN 11g Backup and Recovery (167 page)

So, when you connect to the catalog and the primary database, if the catalog’s high RECID is higher than the one in the control file, you get the “invalid high recid” error. If the RECID in the
526
Part IV: RMAN in the Oracle Ecosystem

catalog is lower than the RECID of the primary database control file, RMAN initiates an update of the catalog that effectively eliminates all the records since the last sync operation with the primary control file. Poof! Backup records from the split volume are gone.

The solution to this problem is to set the control file at the split mirror to become a backup control file. If RMAN detects that it is backing up from a noncurrent control file (backup or standby), it does not increment the RECID in the catalog, so that the records are available after a resync with the current control file at the primary database.

You cannot use the control file autobackup feature if you will be taking backups from the split mirror volume. Because the control file in use is a backup control file, autobackup is disallowed.

RMAN Workshop:
Configure RMAN to Back Up

from the Split Mirror

Workshop Notes

This workshop assumes that you put all the tablespaces into hot backup mode (a requirement) during the period of the split. After the split, you connect the split volume to a new server that has 10
g
installed, and you now want to take an RMAN backup. Because RMAN will give an error if files are in backup mode, you need to manually end backup for every file, as described in this workshop. It’s best to write a script for this. This workshop also assumes that you split the archive log destination and bring it across to the clone at the same time for archive log backup.

Step 1.
Mount the database on the clone server, and prepare the control file for RMAN backup: startup mount;

alter database end backup;

recover database using backup controlfile until cancel;

cancel

exit

Step 2.
Connect RMAN to the clone instance (as the target) and the recovery catalog, and run the datafile backup:

rman target /

rman> connect catalog rman/password@rman cat db

rman> backup database plus archivelog not backed up two times;

Step 3.
Connect RMAN to the production database (as the target) and the catalog, perform a sync operation and archive log cleanup, and then back up the control file: rman target /

rman> connect catalog rman/password@rman cat db

rman> delete archivelog completed before sysdate -7;

rman> backup controlfile;

rman> resync catalog;

Chapter 22: RMAN in Sync and Split Technology
527

Getting Sync and Split Functionality from Oracle Software

There is considerable upside to having a hardware solution provide the architecture described in this chapter. Typically, any operation that can be done purely at the hardware level will have performance increases over the same operation done by software. By the same token, a hardware solution is always going to cost you more than a software solution. Sync and split solutions are no different—the more work that is being done at the storage array, the faster it will go…and the more it will cost.

Starting with Oracle Database 10
g
Release 2, Oracle includes a full solution to provide sync and split functionality without paying for any third-party hardware or software solutions. All you need is Oracle Database 10
g
Enterprise Edition, two servers (with the same OS), and a storage array.

Using a Standby Database, Flashback Database, and

Incremental Apply for Sync and Split

To implement a sync and split solution using only Oracle software, you need to employ a different feature set within the RDBMS: a standby database, Flashback Database, and RMAN incremental backup and incremental apply. All of these features have already been discussed to some extent in previous chapters.

Here’s how it works. First, you create a standby database of your production database (see the workshops in Chapter 20). Once you have the standby database fully operational as a disaster recovery solution, you need to implement Flashback Database on both production and standby databases:

alter database flashback on;

With Flashback Database enabled, you can set a restore point on the primary server: create restore point chapter 20;

alter system switch logfile;

Apply changes through the restore point to the standby database. At this point, the standby database can be opened with reset logs for testing or reporting.

alter database activate standby database;

To resilver your standby database with the primary database, you need to take an incremental backup by using the
from scn
keywords to specify the SCN of the restore point. Once this backup is complete, move it to the standby database site.

backup database incremental from scn 120000;

At the standby database, shut down and then remount the database again. Perform a flashback database to the restore point specified before the standby database was opened: flashback database to restore point chapter 20;

Once the flashback completes, apply the incremental backup from the production database to the standby database, bringing it up to the point of the backup:

recover database until scn 1521321;

528
Part IV: RMAN in the Oracle Ecosystem

Then, the standby database can go back into managed standby mode and catch up to the production database. Or, it can simply be opened again for reporting, now with all of the latest data imported from the incremental backup. Figure 22-4 illustrates how this process might work.

Benefits of the Oracle Sync and Split Solution

Being less expensive isn’t the only thing going for the Oracle sync and split solution. While most likely there are performance drop-offs related to using the standby database/Flashback Database/

incremental apply solution, those drop-offs might be less dramatic than you think. This depends entirely on whether you are already using flashback logs for the inherent functionality provided by them. If you are, then you already have two journals of database changes: the flashback logs and the redo logs. Any more journaling at the file system level only adds additional—and redundant—journaling and can be eliminated.

In addition, you now have a standby database, which you can use for disaster recovery.

Although disaster recovery is inherent in the hardware sync and split model as well, having a
FIGURE 22-4
Using sync and split with a standby database and Flashback Database
Chapter 22: RMAN in Sync and Split Technology
529

standby database at your disposal means that much of the manual footwork involved in failing over during an actual disaster is automated and simplified.

Ultimately, deciding between a fully Oracle solution and a hardware solution will come down to other factors, as well. Is the sync and split architecture needed for things other than the Oracle databases? Do you have licensing for the additional Enterprise Edition database? Do you have the expertise to use one solution over the other? You would need to address these questions, obviously. More than anything else, though, you would want to test the solutions. The good news about the Oracle solution is that you probably already have all the requirements to test it right now.

Oracle-Integrated Shadow Copy Services

for Windows

An interesting example of the direction of sync/split type of hardware/OS integration can be seen in the integration Oracle 11
g
has down with the Volume Shadow Copy Service (VSS) functionality on the Windows platform. VSS is a capability that allows for background journaling, much like other vendors’ mirroring functions, which can then be split off as a separate volume and moved to a different location on a storage array. VSS as a component of the Windows OS offers the ability to coordinate activities between storage writers (the Oracle database) and storage providers (the storage array technologies). It can coordinate component-based shadow copies, meaning that it doesn’t have to understand the world only as a set of volumes; VSS can be informed of the components on the volume and act accordingly.