Oracle RMAN 11g Backup and Recovery (154 page)

Chapter 19: Duplication: Cloning the Target Database
471

Restoring Datafiles to a Different File Location

After mounting the new control file, RMAN moves forward with the datafile restore. If you are duplicating your database to the same server that your target resides on, it is obviously necessary to change the location to which the files will be restored.

Even when restoring to a different server, differences in mount points and directory structures can require a new file location. The datafile restore step of the duplication process can be modified to point to a new file location in three ways.

First, you can use the
configure
command to configure the auxname for any (or all) datafiles that need a new location. These configurations are stored in the target database control file.

configure auxname for datafile 1 to '/u04/oradata/aux1/system01.dbf';

configure auxname for datafile 2 to '/u04/oradata/aux1/undo01.dbf';

...

Second, you can specify the new datafile names in a
run
command, as you would in previous versions:

run {allocate channel c1 type 'sbt tape';

set newname for datafile 1 to '/u04/oradata/aux1/system01.dbf';

set newname for datafile 2 to '/u04/oradata/aux1/undo01.dbf';

duplicate target database to aux1;}

Finally, you can use a parameter in your auxiliary database’s init.ora file to set a new location for the files. The parameter is DB_FILE_NAME_CONVERT, and you pass two strings to it: first, the old location of the file on the target, and second, the new location for the file in your auxiliary instance. You can do this in matched file pairs, like this:

db file name convert (

'/u02/oradata/prod/system01.dbf', '/u02/oradata/aux1/system01.dbf',

'/u03/oradata/prod/prd data 01.dbf', '/u03/oradata/aux1/prd data 01.dbf')
NOTE

In 11
g
R2, the SET NEWNAME function has been

significantly improved to make scripting even simpler.

Now you can do a SET NEWNAME for an entire

tablespace, or for the entire database. For instance:

SET NEWNAME for tablespace USERS01 to '/u01/%U';

This will rename all datafiles to the new location, with unique naming as defined by the variable %U. This greatly simplifies the duplication scripting in situations where the new location will have a different, but consistent, file location.

In addition, there is a Metalink note for those with Oracle Support access that provides methods for dynamic SQL to generate the SET NEWNAME commands for user-managed files, or for converting files to Oracle’s Automatic Storage Manager (ASM) and Oracle Managed Files (OMF) infrastructure. This is Note 549972.1, “RMAN: SET NEWNAME Command SQL.”

472
Part IV: RMAN in the Oracle Ecosystem

This is a simple string conversion parameter, so you can simply pass a single directory name to be changed. For instance, let’s say you have your files spread over four mount points, but they all have prod in the directory structure, so that a
select
from V$DATAFILE looks like this: Select name from v$datafile;

-----------------------------------------------------------

/u02/oradata/prod/system01.dbf

/u03/oradata/prod/prd data 01.dbf

/u04/oradata/prod/indx prd01.dbf

/u05/oradata/prod/temp01.dbf

Instead of pairing up each file, you can simply do the following:

db file name convert ('prod' , 'aux1')

This works, so long as everything else about the file location is the same for your auxiliary database, such as the mount point.

Creating the New Control File

The new control file is created for the auxiliary instance after all the files have been restored.

RMAN just issues a
create controlfile
command at the auxiliary instance, using the parameters you outlined in your
duplicate
command. After creating the control file, the auxiliary database is mounted. Now, RMAN performs a switch operation to switch to the new files. The switch is the means by which RMAN modifies the new control file at the auxiliary site to point to the new location of the datafiles.

Recovery and Archive Logs

After the files are restored and switched, it is time to perform recovery on the database, either to bring it to the current point in time or to bring it to the time specified in the
until time
clause.

To perform recovery, RMAN needs access to the archive logs. If they have been backed up by RMAN, then RMAN can simply restore them from the backup location to the LOG_ARCHIVE_

DEST specified in the init.ora file of the auxiliary database. You can also manually move archive logs to the location required by the new instance so that they are found on disk by RMAN and no restore is required. If you are duplicating to the same server as the one that the target currently resides on, RMAN can find the archive logs in the LOG_ARCHIVE_DEST of the target.

Once the archive logs are restored, RMAN performs the required amount of recovery. If you did not specify a point in time to end the recovery, RMAN restores up to the last available archive log (as found in the view V$ARCHIVED_LOG) and then stops. During duplication, RMAN cannot check the online redo log files for further recovery information. After it hits the end of the archive logs, it stops recovery. After recovery has completed, if RMAN restored any archive logs from backup, they are deleted.

Changing the Database ID (DBID)

After media recovery is complete, the database is in a consistent state, and it is time for RMAN

to change the database ID of the new clone. RMAN has to wait until all other activity in the database has completed, as all operations to this point required the clone database to have the same DBID as the target. The archive logs would not apply to the clone during media recovery if the control file had a different DBID.

Chapter 19: Duplication: Cloning the Target Database
473

The process of changing the DBID is simple. RMAN has at its disposal a little procedure called dbms_backup_restore.zerodbid( ). With the database in a mounted state (not open), this package goes into the file headers and zeros out the DBID in each file header. Then, RMAN shuts down the database and re-creates the auxiliary control file again. When the control file is rebuilt, Oracle checks the file headers for the DBID. When it does not find one, Oracle generates a new one and broadcasts it to every file header.

Log File Creation at the Auxiliary Site

When RMAN issues the final
open resetlogs
command at the completion of the duplication process, it must build brand-new log files for the auxiliary database. This always happens when you issue a
resetlogs
command, but with a
duplicate
command, you need to take into consideration what you want the new redo log files to look like. If you are duplicating to the same system as your target, at a minimum you will have to rename your log files.

The zerodbid Procedure: Warning! Achtung!

As you can imagine, the following is a very vulnerable state for a database to be in: shut down without a DBID in the file headers and with a control file that is being rebuilt. In the RMAN duplication process, however, elements that could go wrong are tightly controlled, so you don’t have to worry too much. We point this out because it is possible to execute this package against any database to generate a new DBID. You just mount the database and run the following code:

execute sys.dbms backup restore.zerodbid(0);

Then, you shut down the database and rebuild the control file using the
set
parameter: create controlfile SET database resetlogs…

And voilà! You have a new DBID. Seems simple enough, doesn’t it?

However, a lot can go wrong if you are trying to do this without the complete control over the environment that RMAN has during duplication. For instance, if you did not get a clean shutdown and you need to perform media recovery before you can open reset logs, you are out of luck. The archive logs have a different DBID. There is no way you will be able to open the database—it is stuck in an inconsistent state, and you cannot fix it. The same thing can happen if a file was accidentally left offline—it won’t get the new DBID when you do an
open resetlogs
command, and therefore you will not be able to bring it online. Ever. You will get the following error:

ORA-01190: control file or datafile is from before the last RESETLOGS

The moral of the story is to be very careful if you decide to use this procedure manually.

There is a better way. As of Oracle9
i
Release 2, Oracle has a utility called DBNEWID, which is a safe and secure way of generating a new ID for a database without making a manual call to the DBMS_BACKUP_RESTORE package. We talk about DBNEWID at the end of this chapter in the section “Incomplete Duplication: Using the DBNEWID Utility.”