EBS 12.2 -- Cloning, How to Clone EBS 12.2

This article will be about cloning in EBS 12.2. 

Cloning is something we need to do periodically as Apps Dba s..  It was a little complex at first glance, but it becomes a routine when we begin to recognize our EBS environments.. That is , after the first or second clone, we see all the problem those may be encountered on the way.. So we prepare our cloning documents according to our environments , and by following it for the  next clones we do not have any difficulties in cloning until we upgrade our EBS environments to 12.2 :)   

As you know, recently we have started to use the new version EBS 12.2 in our Production environments and by looking the stats, we will use this version for at least 2 years more.. Therefore we need to know all the admin operations of EBS 12.2 in detail.. 

As you know, there are architectural changes in 12.2, which affect our cloning routines, too.

So lets have a closer look to the new cloning process in Apps Dba's world.

Generally speaking,  we prepare the Source System for Database Tier and Application Tier  and then copy both Database Tier and Application Tier nodes from the Source System to Target System. So , lastly we configure the Target System for both Database Tier and Application Tier. So the process flow is just like the old versions..

In the application tier cloning process,we clone the EBS's Run edition Filesystem to the Target, and then clone the copied target file system again to create the Patch Edition Filesystem in the Target. So we dont touch the Patch Edition File System of the source environment during our Clone process.

1) So we start by preparing our Source system;

     1a)For preparing our application tier; we basically run adpreclone.pl from the Run file system.     Adpreclone creates  compressed archives of Oracle Fusion Middleware components as follows;

A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home:<COMMON_TOP>/clone/FMW/FMW_Home.jar

A compressed archive of the Oracle E-Business Suite Weblogic domain:<COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar

The Oracle E-Business Suite Weblogic domain's configuration template:<COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml

A compressed archive of the Oracle Web Tier/Oracle HTTP Server configuration instance:<COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

The Oracle HTTP Server configuration instance's configuration template:<COMMON_TOP>/clone/FMW/OHS/moveplan.xml

So we run adpreclone.pl as follows;

·         Login as application owner (applmgr)

·         Source the run edition environment

·         $ cd <INST_TOP>/admin/scripts

·         $ perl adpreclone.pl appsTier

1b)For preparing our database tier; we basically run adpreclone.pl from the database node using database software owner OS account as follows;

$ cd <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>

$ perl adpreclone.pl dbTier

2)

After we complete running adpreclone.pl successfully, we copy our source environment   to the target.. Note that we clone our database and we copy the necessary application tier directories

2a)

For copying the database, we can use scp..

So, We can basically shutdown our source environment and use scp to copy our database files to the target system's server.

If our database is in ASM, we can use rman duplicate to duplicate our source db to the target server.. (we can duplicate it into a ASM running on the target server , or we can duplicate our source db into a cooked filesystem on the target server) 

Note that: we can duplicate our database when it is running..

Anyways, if we use offline copy, we can startup our source database and application services, right after our copy command, which is used for copy the database files from source to target,  is complete.

Also in this step, we copy our source system oracle home to the target system.. If our target system's database Home will be different than our source system's database Home, we may use relink all command to relink the binaries.

2b) For copying the application tier;

We login to the source application environment using application owner and source the Run filesystem..

So after sourcing the run filesystem we identify the following directories;

<APPL_TOP>

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

Then we copy them from source to target..

Note that: In 12.2 we have a dual file system. So we have fs1 and fs2. So we copy APPL_TOP,COMMON_TOP and 10.1.2 ORACLE_HOME from the run filesystem of the Source environment to the target.. So we need to maintain these dual directory structure in target system. I mean we need to have directories named fs1 and fs2 , accordingly. Also, In the target ,the copied directories will belong to our run filesystem .. 

For example: If our Run filesystem is ; /u01/erman/fs2 ->

we need to copy $APPL_TOP, which is in /apps/fs2/EBSapps/appl  to the target servers as /ANY_NAMES_YOU_WANT/fs2/EBSapps/appl

3) Once we copy all the necessary application files  and copy/duplicate our database, we countinue with the configuration of the target environment.. Note that following commands should be run with the related OS accounts.. DB owner for db configuration, Application owner for the appsTier configuration.. Also we need to ensure that, all the directory permissions are set properly before executing the configuration scripts..

3a) We first configure our database tier using adcfgclone dbTier.

cd <RDBMS ORACLE_HOME>/appsutil/clone/bin

$ perl adcfgclone.pl dbTier

4a) Then we configure our application tier using adcfgclone appsTier

 cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier

Note that: when the script asks for  "Target System Base Directory",we enter the location of the base directory that we will use in the target system.

For example: /ANY_NAMES_YOU_WANT

When the adcfgclone appsTier is completed successfully, we continue by executing adpreclone.pl appsTier on the target system. This step is necessary, because we will clone our target run filesystem in order to have a patch filesystem, in the next steps..

cd <COMMON_TOP>/clone/bin

$perl  adpreclone.pl appsTier.

So after our preclone is finished, we are ready to copy our target Run edition filesystem to the patch edition.

We use cp -RH to accomplish that..

For example: Suppose our run filesystem in the target is /u01/erman/fs1

cp -RH /u01/erman/fs1 /u01/erman/fs2

Note that: -RH is needed for keeping the softlinks and copying the directory structure recursively...

-H     follow command-line symbolic links in SOURCE

-R, -r, --recursive

              copy directories recursively

Okay, after copying our run filesytem to patch filesystem in the target, we execute adcfgclone.pl once again, but this time in the Patch Edition environment..

So source the patch edition environment in the target and run the following as Application Owner;

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier

adcfgclone.pl will asks us to supply the associated Run Filesystem's Context File location:

We need to supply the location of the target system's Run Filesystem Context File Location(full path)..

For ex: /u01/erman/fs1 /inst/apps/PROD_atgserver/appl/admin/PROD_atgserver.xml.

Once, adcfgclone.pl is complete. Our clone work will be finished.

After this point we may continue with our post actions if needed..

So  even if you have a multi clone environment,  the logic is almost the same..

For example following flow describes a clone operation  from a single server source system to a multiple server target system . The only difference is we create our patch filesystems on the target servers using the patch filesystems of the first target server that we have cloned.

That's it. The cloning process in 12.2 is based on the same logic as previous releases : prepare, copy and configure.. Naturally, there are some differences in the process, as 12.2 have a quite new architecture.