Oracle RMAN 11g Backup and Recovery (153 page)

Chapter 19: Duplication: Cloning the Target Database
467

same DBID. If you try to register your clone in the same catalog as your production system, you will get an error:

rman-20002: target database already registered in recovery catalog

This error can be a little misleading: you haven’t registered the database! If you shrug your shoulders at this and go ahead and try to back up your database, it will give you an even stranger error:

rman-20011: target database incarnation is not current in recovery catalog

“Whoa,” you say, “what does that mean?” So you go ahead and issue a
reset database
, as you think you should, and this works. You can now back up your database. Sweet. However, you have caused bigger problems. Now, you connect RMAN to your original production server and try to back it up. But when you do, you get a hauntingly similar error:

rman-20011: target database incarnation is not current in recovery catalog The reason for this error is that RMAN considers your clone no more than a restored version of your production system, so it now thinks the clone is the current incarnation of your production server, and it has no idea what your production server is. You can reset the incarnation back to the one that actually matches your production database, but you’ve essentially corrupted your catalog and should unregister your database and reregister it in the catalog (see Chapter 3). It should be noted, of course, that the Oracle documentation clearly states in each release that you should never connect RMAN to a test database and the recovery catalog because of this very problem.

If you don’t use a catalog, nonduplicated clones can wreak havoc, as well. Let’s lay it out in an example. You clone your database to the same system as your primary database. You are using RMAN to back up both databases to tape, and because you aren’t using a catalog, you have automatic control file backups turned on for both instances. One day, you lose a disk array, and your entire system goes belly up. Both databases, and all of their control files, are lost. “No problem,” you think, “I’ve got control file autobackup turned on. I’ll just use one of those to restore my systems.”

But here’s the stickler: the command
restore controlfile from autobackup
uses the DB_ID to track down the control file autobackup. Because both of your databases back up to the same tape, it may try to restore the control file from the wrong database, giving you the wrong files with the wrong data.

A third reason, new to environments where you are using Oracle Enterprise Manager Grid Control, also comes to the surface. Grid Control needs to understand all of its managed targets as unique snowflakes. If you clone a database, and you leave the metadata the same for both databases, and then try to use Grid Control to manage both databases, you give Grid Control brain damage. It will either refuse to discover one of the databases, or make you go through some gyrations to rectify how the new clone registers itself with the listener (note: this problem can occur even if your clone database is on a different server).

Obviously, any of these scenarios can be fixed, and they don’t cause a loss of data. But they cause a loss of time. They can potentially extend your downtime past your agreement levels. In addition to these problems, using duplication in RMAN provides the power of the RMAN

interface to keep things as simple as possible. And simple is good. Simple is wise.

468
Part IV: RMAN in the Oracle Ecosystem

Different Types of RMAN Duplication

Oracle 11
g
offers multiple ways to perform database cloning using RMAN. In the past, you always needed a few critical things to perform duplication: access to the target database (the one you want to copy) and access to existing backups. In different situations, both of these dependencies have been stripped, allowing for more flexibility in how you plan and execute a clone operation with RMAN.

Duplicate Using RMAN Backups and with Access to the Target Database

This is the “traditional” RMAN duplication from versions 9
i
and 10
g
: we leverage our existing RMAN backups to create a copy of an existing target database to a new location. To understand how far, and what, to duplicate, RMAN connects to the existing database’s control file throughout the duplication operation.

Duplicate Using RMAN Backups and No Access to the Target

New to 11
g,
now you have the option of performing a duplication when the target is not available.

This is useful in situations where the target database is in a different incarnation, is in an inaccessible network location, or is simply not at your disposal for the duplication. In this case, RMAN can pull what it needs from the recovery catalog, a few additional parameters you will pass to the
duplicate
command. We cover this near the end of the chapter, in the section “Target-Less Duplication in 11
g.
”

Duplicate an Active Database Without Using Backups

Duplicating an active database sounds new, but this operation was actually introduced in Enterprise Manager in the 10
g
timeframe. At that time, Enterprise Manager would clone a database by calling the package dbms_backup_restore directly, instead of using the RMAN client command syntax, and it would make a live copy of each datafile in the database in real time, and then would move that datafile to the new location.

Now, in 11
g,
this is codified in the RMAN command syntax, but it’s the same operation.

Instead of relying on an existing RMAN backup, RMAN simply connects to the target database, runs a backup operation directly against the database in real time, and writes the file to the specified location. So, nothing all that special, other than a syntactic difference in what you call the operation.

All three of these duplication types rely on the same underlying architecture. We will walk through the operations for the backup-based, target database–connected duplication so that the underlying principles can be observed.

The Duplication Architecture

Here’s how duplication works. RMAN connects to your target database or to the catalog, if you use one. This connection is necessary to gain access to the target database control file for details about where to locate backups. After you connect to the target or catalog, you must connect to your auxiliary instance (the instance that will house your cloned database). Before duplication starts, you must have already built an init.ora file for the auxiliary instance, and have started it in NOMOUNT mode. This way, the memory segment has been initialized, and therefore RMAN can make a SYSDBA connection to it. The auxiliary instance does not have a control file yet (duplication will take care of that), so you cannot mount the auxiliary instance, even if you want to.

Chapter 19: Duplication: Cloning the Target Database
469

With these connections made, you can issue your
duplicate
command. It can look as simple as this:

duplicate target database to aux1;

or it can be complicated, depending on where the auxiliary instance is

run {

set until time '08-JUL-2002:16:30:00';

duplicate target database to aux1 pfile /u02/oracle/admin/aux1/pfile/init.ora nofilenamecheck

device type sbt parms "env (nb ora serv rmsrv)"

logfile

'/u04/oracle/oradata/aux1/redo01.log' size 100m,

'/u05/oracle/oradata/aux1/redo02.log' size 100m,

'/u06/oracle/oradata/aux1/redo03.log' size 100m;}

The duplication process can be broken down into its distinct phases:

1.
RMAN determines the nature and location of the backups.

2.
RMAN allocates an auxiliary channel at the auxiliary instance.

3.
RMAN restores the datafiles to the auxiliary instance.

4.
RMAN builds a new auxiliary control file.

5.
RMAN restores archive logs from backup (if necessary) and performs any necessary recovery.

6.
RMAN resets the DBID for the auxiliary instance and opens the auxiliary database with
open resetlogs
.

First, RMAN sets any runtime parameters, such as an
until time
clause on the
duplicate
command. Then, based on these parameters, it checks the target database control file (or recovery catalog) for the appropriate backups. It then builds the RPCs for how to access the backups, and which ones to access, but it does not execute the code at the target. Instead, RMAN creates a channel process at the auxiliary instance, referred to as the
auxiliary channel,
and to this channel, RMAN passes the call to DBMS_BACKUP_RESTORE. The auxiliary instance, then, accesses the backups and restores all necessary datafiles. Figure 19-1 illustrates how this takes place for both disk backups and tape backups.

Auxiliary Channel Configuration

For duplication to work, RMAN must allocate one or more channel processes at the auxiliary instance. From Oracle9
i
onward, you do not need to manually allocate an auxiliary channel at the time of duplication, because one will automatically be created using permanent configuration parameters stored in the target control file. The makeup of the auxiliary channel mainly comes from parameters you established for target channels: the default device type and the degree of parallelism both get set using the same persistent parameters that set the target channels.

Therefore, if you are duplicating using backups taken to disk, you need not do anything to configure your auxiliary channels. However, if you are duplicating your database using backups

470
Part IV: RMAN in the Oracle Ecosystem

FIGURE 19-1
A bird’s-eye view of duplication

taken to tape, you need to configure your auxiliary channels to contain any media manager environment parameters that your target channels have. For example, the following code sets the default device type to tape, sets the default level of parallelism to 2, and then configures two auxiliary channels with the correct parameters:

configure default device type to sbt;

configure device type sbt parallelism 2;

configure auxiliary channel 1 device type sbt parms

"env (nb ora serv mgtserv, nb ora class oracle)";

configure auxiliary channel 2 device type sbt parms

"env (nb ora serv mgtserv, nb ora class oracle)";