Oracle RMAN 11g Backup and Recovery (155 page)

474
Part IV: RMAN in the Oracle Ecosystem

You can specify completely new redo log file definitions when you issue the
duplicate
command. Do this if you want to change the size, number, and/or location of the redo logs for the new database. This would look something like the following:

duplicate target database to aux1

pfile /u02/oracle/admin/aux1/init.ora

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;

Alternatively, you can use the existing log file definitions from your target and simply move them to a new location using the init.ora parameter LOG_FILE_NAME_CONVERT. This parameter acts exactly like DB_FILE_NAME_CONVERT, so you can convert the log files in coupled pairs, or you can simply use string conversion to change a single directory name:

log file name convert ('/u02/oracle/oradata/redo01a.dbf',

'/u03/auxiliary/redo01a.dbf',…)

Duplication: Location Considerations

So far, we’ve completely glossed over one of the biggest stumbling blocks to understanding duplication. You must account for the location of your auxiliary instance in relation to the location of your target instance. Duplicating to the same server is very different from duplicating to a remote server. There are elements unique to each that you must understand before you proceed with duplication.

Duplication to the Same Server: An Overview

You must tread lightly when duplicating to the same server, so that you don’t walk all over your existing target database. If you were to simply make a copy of your target init.ora file and then run the following code:

duplicate target database to aux1;

you would run into a series of problems and errors. These errors would be related to the fact that you already have an instance running with the same name and have the same file locations for two databases.

Memory Considerations

The first memory consideration is the database name. Oracle references memory segments on the server based on the value of the init.ora parameter DB_NAME. Therefore, Oracle cannot allow two instances with the same DB_NAME to run on the same system. If you try to startup mount a second instance with the same name, you will get the following error:

ORA-01102: cannot mount database in EXCLUSIVE mode

Therefore, when duplicating to the same system, you need to change the DB_NAME

parameter in the auxiliary init.ora file to be different from the database name of your target: db name 'aux1'

instance name 'aux1'

Chapter 19: Duplication: Cloning the Target Database
475

File Location Considerations

Okay, you’ve squared away your memory problems, but you still have two databases that are trying to write to the same file locations. In fact, you have three different types of files that are all competing for the same name. If you don’t account for file locations, duplication will fail at the step of trying to rebuild the control file:

RMAN-00571:

RMAN-00569:

ERROR MESSAGE STACK FOLLOWS

RMAN-00571:

RMAN-03002: failure of Duplicate Db command at 07/02/2009 13:52:14

RMAN-06136: ORACLE error from auxiliary database:

ORA-01503: CREATE CONTROLFILE failed

ORA-00200: controlfile could not be created

ORA-00202: controlfile:

'/space/oracle user/OraHome1/oradata/sun92/control01.ctl'

ORA-27086: skgfglk: unable to lock file - already in use

SVR4 Error: 11: Resource temporarily unavailable

This is good news for you, because otherwise you would have overwritten your production control file. You must change the auxiliary init.ora parameter CONTROL_FILES to point to a new location on disk, as this is the means by which RMAN determines where to restore the control files to.

After we change the location of the control files, we must change the location of the datafiles.

We talked about this previously: your three choices are to use the
configure
command, use the DB_FILE_NAME_CONVERT parameter, or use a
run
block, Oracle8
i
-style. If you fail to change the datafile locations when duplicating to the same server, you will get an error very similar to the preceding control file error, telling you that the files are currently in use and cannot be overwritten.

Finally, you must change the redo log file location. We talked about this previously, when we discussed the different steps that duplication walks through. You can use the
logfile
keyword as part of the
duplicate
command to build completely different redo files, with different sizes, number of groups, and number of members. This option essentially rewrites the similar
logfile
parameter of the
create controlfile
stage of duplication. Alternatively, you can simply use the LOG_FILE_NAME_CONVERT parameter in the auxiliary init.ora file.

Duplication to the Same Server, Different ORACLE_HOME

It is common practice to clone the production database from its location to a different location on the same server but to have it be hosted by a different Oracle software installation. When you have a different ORACLE_HOME for the auxiliary instance, slightly different rules apply. All the rules about hosting on the same system apply as outlined previously. However, you must also consider the location of the backup pieces. If you are duplicating from disk backups, this won’t be a problem—just make sure you have your OS permissions worked out ahead of time. If you are duplicating from tape backups, however, you need to make sure that you have your MML file appropriately linked with the auxiliary ORACLE_HOME in the same way as it is linked in your target’s ORACLE_HOME. Otherwise, your tape backups will be inaccessible by the auxiliary instance, and duplication will fail because the media manager will be inaccessible.

Duplication to a Remote Server: An Overview

A successful duplication to an auxiliary instance on a different server from the target is no more or less complicated than duplication to the same server. It’s just complicated in different ways.

476
Part IV: RMAN in the Oracle Ecosystem

Memory Considerations

Unlike duplication to the same server, you do not have to worry about the DB_NAME parameter in the init.ora file. Because we are on a different server, Oracle has no hang-ups about the LOCK_

NAME used for memory.

Of course, it is good operational procedure to always be mindful of the DB_NAME parameter during a duplication process, and crosscheck all other instances running on the same server before beginning the duplication. That way you have no unexpected errors down the road. In addition, from a management perspective, it makes the most sense to always have every database in your ecosystem with a unique name.

File Location Considerations

Again, because we are on a new server, there is not quite the urgency to change any of the file location specifications for your auxiliary instance. No database already is running with the same files, so we can leave all file specifications the same as for the target instance, and thus avoid any possible errors in the configuration. Again, we can simplify much of this process when we are on a different system. If you do not change the location of the files, you must specify
nofilenamecheck
in the
duplicate
command. This tells duplication not to confirm that the filenames are different before performing the restore. If this is not specified, RMAN will give you an error.