R12 - Cloning from an RMAN backup using duplicate database

Since most DBA's are using rman for their backup strategy I thought I would put together the steps to clone from an rman backup. The steps you follow are pretty much the same as described in Appendix A: Recreating the database control files manually in Rapid Clone in Note 406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone.

Here are the steps:
  1. Execute preclone on all tiers of the source system. This includes both the database and application tiers. (For this example, TEST is my source system.)

    For the database execute: $ORACLE_HOME/appsutil/scripts/<context>/ dbTier
    Where context name is of the format <sid>_<hostname>

    For the application tier: $ADMIN_SCRIPTS_HOME/ appsTier

  2. Prepare the files needed for the clone and copy them to the target server.
    • Take a FULL rman backup and copy the files to the target server and place them in the identical path. ie. if your rman backups go to /u01/backup on the source server, place them in /u01/backup on the destination server. To be safe, you may want to copy some of the archive files generated while the database was being backed up. Place them in an identical path on the target server as well.
    • Application Tier: tar up the application files and copy them to the destination server. The cloning document referenced above ask you to take a copy of the $APPL_TOP, $COMMON_TOP, $IAS_ORACLE_HOME and $ORACLE_HOME. Normally I just tar up the System Base Directory, which is the root directory for your application files.
    • Database Tier: tar up the database $ORACLE_HOME.

      ex. from a single tier system. The first tar file contains the application files and the second is the database $ORACLE_HOME

      [oratest@myserver TEST]$ pwd
      [oratest@myserver TEST]$ ls
      apps db inst
      [oratest@myserver TEST]$ tar cvfzp TEST_apps_inst_myserver.tar.gz apps inst
      [oratest@myserver TEST]$ tar cvfzp TEST_dbhome_myserver.tar.gz db/tech_st

      Notice for the database $ORACLE_HOME I only added the db/tech_st directory to the archive. The reason is that the database files are under db/apps_st and we don't need those.
    • Copy the tar files to the destination server, create a directory for your new environment, for example /u01/DEV. (For the purpose of this article I will be using /u01/DEV as the system base for the target envrionment we are building and myserver is the server name.)
    • Extract each of the tar files with the command tar xvfzp

      Ex. tar xvfzp TEST_apps_inst_myserver.tar.gz

  3. Configure the target system.
    • On the database tier execute with the dbTechStack parameter.

      For example. /u01/DEV/db/tech_st/10.2.0/appsutil/clone/bin/ dbTechStack

      By passing the dbTechStack parameter we are tell the script to configure only the necessary $ORACLE_HOME files such as the init file for the new environment, listener.ora, database environment settings file, etc. It will also start the listener.

      You will be prompted the standard post cloning questions such as the SID of the new environment, number of DATA_TOPS, Oracle Home location, port settings, etc.

      Once this is complete goto /u01/DEV/db/tech_st/10.2.0 and execute the environment settings file to make sure your environment is set correctly.

      [oradev@myserver 10.2.0] . ./DEV_myserver.env

  4. Duplicate the source database to the target.
    • In order to duplicate the source database you'll need to know the scn value to recover to. There are two wasy to do this. The first is to login to your rman catalog, find the Chk SCN of the files in the last backupset of your rman backup and add 1 to it.

      Ex. Output from a rman> List backups
      List of Datafiles in backup set 55729
      File LV Type Ckp SCN Ckp Time Name
      ---- -- ---- ---------- --------- ----
      7 1 Incr 5965309363843 15-JUN-09 /u02/TEST/db/apps_st/data/owad01.dbf

      So in this case the SCN we would be recovery to is 5965309363843 + 1 = 5965309363844.

      The other method is to login to the rman catalog via sqlplus and execute the following query:

      select max(absolute_fuzzy_change#)+1,
      from rc_backup_datafile;

      Use which ever value is greater.
    • Modify the db_file_name_convert and log_file_name convert parameters in the target init file. Example:

      db_file_name_convert=('/u02/PROD/db/apps_st/data/', '/u02/DEV/db/apps_st/data/',
      '/u01/PROD/db/apps_st/data/', '/u02/DEV/db/apps_st/data/')

      log_file_name_convert=(/u02/PROD/db/apps_st/data/', '/u02/DEV/db/apps_st/data/',
      '/u01/PROD/db/apps_st/data/', '/u02/DEV/db/apps_st/data/')

    • Verify you can connect to source system from the target as sysdba. You will need to add a tns entry to the $TNS_ADMIN/tnsnames.ora file for the source system.
    • Duplicate the database. Before we use rman to duplicate the source database we need to start the target database in nomount mode.

      Start rman:

      rman target sys/<syspass>@TEST catalog rman/rman@RMAN auxiliary /

      If there are no connection errors duplicate the database with the following script:

      run {
      set until scn 5965309363844;
      allocate auxiliary channel ch1 type disk;
      allocate auxiliary channel ch2 type disk;
      duplicate target database to DEV }

      The most common errors at this point are connection errors to the source database and rman catalog. As well, if the log_file_name_convert and db_file_name_convert parameters are not set properly you will see errors. Fix the problems, login with rman again and re-execute the script.

      When the rman duplicate has finished the database will be open and ready to proceed with the next steps.

    • Execute the library update script:

      cd $ORACLE_HOME/appsutil/install/DEV_myserver where DEV_myserver is the <context_name> of the new environment.

      sqlplus "/ as sysdba"@adupdlib.sql

      If your on linux replace with so, HPUX with sl and for windows servers leave blank.

    • Configure the target database

      cd $ORACLE_HOME/appsutil/clone/bin/ dbconfig

      Where is $ORACLE_HOME/appsutil/DEV_myserver.xml

  5. Configure the application tier.

    cd /u01/DEV/apps/apps_st/comn/clone/bin
    perl appsTier

    You will be prompted the standard cloning questions consisting of the system base directories, which services you want enabled, port pool, etc. Make sure you choose the same port pool as you did when configuring the database tier in step 3.

    Once that is finished, initialize your environment by executing

    . /u01/DEV/apps/apps_st/appl/APPSDEV_myserver.env

  6. Shutdown the application tier.

    ./ apps/<source apps pass>

  7. Login as apps to the database and execute:

    exec fnd_conc_clone.setup_clean;

    I don't believe this step is necessary but if you don't do this you will see references to your source environment in the FND_% tables. Every time you execute this procedure you need to run autoconfig on each of the tiers (db and application). We will get to that in a second.

  8. Change the apps password. Chances are you don't want to have the same apps password as the source database, so its best to change it now while the environment is down.

    With the apps tier environment initialized:

    FNDCPASS apps/<source apps pass> 0 Y system/<source system pass>> SYSTEM APPLSYS <new apps pass>

  9. Run autoconfig on both the db tier and application tier.

    db tier:
    cd $ORACLE_HOME/appsutil/scripts/DEV_myserver

    Application Tier

  10. If there are no errors with autoconfig start the application. Your already in the $ADMIN_SCRIPTS_HOME so just execute:

    ./ apps/<new apps pass>

  11. Login to the application and perform any post cloning activities. You may want to override the work flow email address so that notifications goto a test/dev mailbox instead of users. We always change the colors and site_name profile options, etc. More details can be found in Section 3: Finishing tasks of the R12 cloning document referenced earlier.

Thats it, hopefully now you have successfully cloning an EBS environment using rman duplicate.


ibnhussain said...

good luck for good work.
I hope if your test instance is at the same level of patchset and your database too, you do not need to run adconfig scripts. am i right? since we usually apply patches on our test environments before we go to prod i am only concerned about clone database only. my question is if can i clone only database using rman duplicate feature. if yes what else i have to do?

Kindly suggest.

Dave said...

Hey, if you are cloning from PROD to TEST and the patch levels are different you need to clone the entire environment. If everything is identical you can refresh just the database. There is another post on my site which talks about refreshing the database if your interested in that.

Jitender Mehta said...

Thanks Dave.

and How can I find post
"which talks about refreshing the database if your interested in that."

Dave said...

The refreshing database post is here:

But I am going to change it to use dbConfig, i'll update the post or create a new one shortly.

david said...

excellent note. one additional thing. when running apps tier cloning a ran into issue of jmestmpl.drv and other drv files at 50% (only on screen not in log file) and found solution in note i.d 391295.1. this in my case was due to ATG RUP 4

Rehan said...

If directory structure on our clonned server is different than source server then how we can follow this doccument ?

Dave said...

Sorry for the late reply, I was on vacation. For the database modify the db_file_name_convert and log_file_name convert parameters in the target init file to point to the new location. For the apps tier you can change it when running the rapid clone scripts, when prompted for the base system directory.

Anonymous said...

when i run command

. /opt/oracle/db/tech_st/11.1.0/appsutil/clone/bin/ dbTechStack ( putty window gets closed ).

i try to do the same thing with other method like

cd /opt/oracle/db/tech_st/11.1.0/appsutil/clone/bin/
perl dbTier

it asks for parametrs like sid , top directories path etc and when the process reaches at 50% control file creation failed message appears and the process ends.

please reply how to resolve.

i also want to tell you that before making tarfile of db/tech_st i also ran on dbTier.

Dave said...

I would have to see the adcfgclone logs to see why it was erroring out.

Anonymous said...

i can email you logs . please provide me email id.


Dave said...

Email address is on the right hand side in the about me section..

Rehan said...

when dupliicate command is ended we have to do

recover database until cancel using backup controlfile: ( provide archive logs here generated after rman backup)

alter database open resetlogs;

then shutdown database and listener.

then run perl adcfgclone dbconfig

dave am i right ?

Dave said...

I'm pretty sure the duplicate takes care of that.

Sridevi Koduru said...
This comment has been removed by the author.
Sridevi Koduru said...

Sridevi Koduru (Senior Oracle Apps Trainer
LinkedIn profile -
Please Contact for One to One Online Training on Oracle Apps Technical, Financials, SCM, Oracle Manufacturing, OAF, ADF, SQL, PL/SQL, D2K at | +91 - 9581017828.