Cloning Oracle E­Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1)

This document describes how to create a copy of an Oracle E­Business Suite Release 12.2 system using Rapid Clone.

The most current version of this document can be obtained in My Oracle Support Knowledge Document 1383621.1,Cloning Oracle E­Business Suite with Rapid Clone.

Note: This knowledge document supersedes Chapter 17 of Oracle E­Business Suite Setup Guide, Part No. E22953,and should be used instead of that chapter.

There is a change log at the end of this document.

In This Document

This document is divided into the following sections:

Section 1: Introduction to CloningSection 2: Prerequisite TasksSection 3: Standard Cloning TasksSection 4: Finishing TasksSection 5: Advanced Cloning OptionsSection 6: Automating Rapid CloneSection 7: Other Cloning ProceduresSection 8: Known Issues

Conventions used in this document include the following:

Term orUsage Meaning or Action

Source System Oracle E­Business Suite system being cloned.

Target System Oracle E­Business Suite system being created as a copy of the Source.

applmgr User that owns the application tier file system (APPL_TOP and application tier technology stack).

oracle User that owns the database tier file system (RDBMS ORACLE_HOME and database files).

CONTEXT_NAMEThe CONTEXT_NAME variable refers to the name of the applications context file. By default,CONTEXT_NAME is <SID>_<HOSTNAME>.

Monospacetext

Represents command line, directory and file name text. Type this exactly as shown.

< > Text enclosed in brackets represents a variable. Substitute a value for the variable text. Do not typethe brackets.

Section 1: Introduction to Cloning

Cloning is the process of creating a copy of an existing Oracle E­Business Suite system. The cloning methodologydescribed in this document covers the process used to clone an Oracle E­Business Suite Release 12.2 system.

Note: An Oracle E­Business Suite system can only be cloned to the same, or a higher, major release of a platform(operating system). For example, you can clone a system running on Oracle Solaris 10 to run on Oracle Solaris 11,but it is not supported to clone a system running on Solaris 11 to run on Solaris 10.

There are various scenarios that require cloning an Oracle E­Business Suite system:

Standard cloning ­ Copying an existing Oracle E­Business Suite system, for example, to test updates against aduplicate of a production system.  

Note: Be aware that standard cloning is different from file system cloning. Standard cloning is creating acopy of an Oracle E­Business Suite system using Rapid Clone (for example, cloning a complete Oracle E­Business Suite system to create a test copy from your production environment). In contrast, file systemcloning is copying the run file system to the patch file system in online patching, and can only be undertakenwith the adop phase=fs_clone command.

System scale­up ­ Adding new machines to an Oracle E­Business Suite system to provide capacity forprocessing increased workloads. 

System transformations ­ Altering system data or file systems, including actions such as platform migration,provisioning of high availability architectures, and data scrambling (or the preferred alternative of data masking,as described in My Oracle Support Knowledge Document 1437485.1, Using Oracle E­Business Suite Release12.1.3 Template for the Data Masking Pack with Oracle Enterprise Manager 11g). 

Patching and upgrading ­ Delivering new versions of Oracle E­Business Suite components, and providing amechanism to create rolling environments that minimize downtimes.

An important principle in Oracle E­Business Suite cloning is that the system is cloned, rather than the topology.Producing an exact copy of the patch level and data is much more important than creating an exact copy of topology,as a cloned system must be able to provide the same output to the end user as the Source System. However, while acloned system does not need to have the full topology of its Source, it must have available all of the topologycomponents that are available to the Source.

Note: When cloning, ensure that you specify the actual locations for the directories involved, so that AD utilitiescan properly identify the directories afterward. Do not use symbolic links to specify directory locations.

Section 2: Prerequisite Tasks

Note: If your E­Business Suite Release 12.2 Source instance is integrated with Oracle Access Manager 11gR2(11.1.2) and Oracle E­Business Suite AccessGate, refer to My Oracle Support Knowledge Document 1614793.1,Cloning Oracle E­Business Suite Release 12.2 Environments integrated with Oracle Access Manager 11gR2 (11.1.2)and Oracle E­Business Suite AccessGate.

Note: Before cloning a system with Rapid Clone, be sure to allow any active online patching cycles to run all theway through the final (cleanup) phase. Then run fs_clone to synchronize with the other file system, to avoid theneed for synchronization to be performed in the next patching cycle. For more information, refer to Oracle E­Business Suite Maintenance Guide.

Before cloning to a new system, you must first prepare the Source System by following the below steps:

1.  Verify disk space requirements on Source System Ensure the Source System has enough free disk space. Oracle Fusion Middleware cloning tools require 6GB in/tmp and 6GB under $COMMON_TOP. 

2.  Verify OS requirements on Target SystemEnsure the Target System meets all the requirements for Oracle E­Business Suite Release 12.2 as stated in MyOracle Support Knowledge Document 1320300.1, Oracle E­Business Suite Release Notes, Release 12.2, andOracle E­Business Suite Installation and Upgrade Notes for each platform.  

Note: For Microsoft Windows, Rapid Clone is not currently certified for use from Domain User Accounts.

3.  Verify Global Inventory RequirementsA global (central) inventory is required for all Oracle E­Business Suite Release 12.2 application tiernodes.The central inventory location must be identified by the /oracle/oraInventory.loc file.On a shared file system, the global inventory location must be shared and used by all participating nodes.The use of a local inventory per Oracle E­Business Suite installation is not currently supported.

If you are using a UNIX platform, you should verify the existence and contents of the oraInst.loc file, whichspecifies the location of the oraInventory.loc file global inventory file.

1.  Check that oraInst.loc exists in the correct directory for your platform:

Platform oraInst.loc Location

Oracle Solaris SPARC (64­bit) /var/opt/oracle

Linux x86­64 /etc

IBM AIX on Power Systems (64­bit) /etc

HP­UX Itanium /var/opt/oracle

2.  Confirm that the contents of oraInst.loc look like this:

inventory_loc=/oracle/oraInventory

where /oracle/oraInventory points to the directory where the central inventory is located. This locationmust be writable by the user account that is to run Rapid Clone. 

Incorrect permissions on oraInventory may cause issues while cloning a system with Rapid Clone. 

Note: If your system has separate installation user accounts for the database and the applications,both users must be in the same install group (inst_group) in oraInst.loc, which will need to contain aline such as inst_group=oracle.

If the oraInst.loc file does not exist, create it in the correct directory with contents as shown above.

4.  Verify Source and Target System software components and versionsIn addition to the Oracle E­Business Suite software requirements (see Oracle E­Business Suite InstallationGuide: Using Rapid Install), the following software component versions in Table 1 below must exist on theSource or Target nodes, as applicable. The 'Required Location' column indicates the node where the softwarecomponent must reside. 

Table 1: Software Requirements

Software Minimum Required

Component Version Location Comments

Zip 2.3 (orhigher)

All SourceSystemnodes

Download from InfoZip. Zip must be in your $PATH. If using fileslarger than 2GB, you should use InfoZip ZIP 3.0 or higher.

Unzip 5.52 (orhigher)

All SourceSystemnodes

Download from InfoZip. Unzip must be in your $PATH. If using fileslarger than 2GB, you should use InfoZip UNZIP 5.52 or higher.

Operationsystemutilities

N/AAll TargetSystemnodes

The required operating system utilities for your platform must be inyour $PATH when running adcfgclone.pl. For example, make, ld,and ar are required utilities for UNIX. Refer to Oracle E­BusinessSuite Installation Guide: Using Rapid Install.

Perl 5.10.x (orhigher)

All TargetSystemnodes

Use the version of Perl shipped with Oracle Fusion Middleware 11gand Oracle Database 11g, or download from Perl.com. Perl must be inyour $PATH and $PERL5LIB must be set correctly before cloning.

5.  Apply required patches  

1.  Apply the latest AD/TXK patches You are strongly encouraged to be on the latest AD/TXK codelevel. Refer to My Oracle SupportKnowledge Document 1583092.1, Oracle E­Business Suite Release 12.2: Suite­Wide Rollup and AD/TXKDelta Information, and apply the most recent delta patches.

It is important to read the release notes for those patches, since they may require other patches. Referto My Oracle Support Knowledge Document 1617461.1, Applying the Latest AD and TXK Release UpdatePacks to Oracle E­Business Suite Release 12.2.

2.  Apply additional patches Update the Oracle E­Business Suite file system by applying other additional patches to all application tierserver nodes. 

There are no additional patches at this time. 

Note: After applying any new patches, ORACLE_HOME(s) on the Source System must be updatedwith the files included in those patches. To synchronize the Rapid Clone and AutoConfig files withinthe RDBMS ORACLE_HOME using the admkappsutil.pl utility, refer to Oracle E­Business Suite Release12.2 Setup Guide and follow the instructions in section Patching AutoConfig, Applying the LatestAutoConfig Updates. Failing to use the latest code may jeopardize the success of the cloningoperation. If new AD, AutoConfig or Rapid Clone updates are applied to the system, prerequisite taskSteps 4, 5, 6, and 7 must be executed again in order to apply the new files to the database node.

Refer to Section 8: Known Issues of this document for up­to­date information on known problems andavailable workarounds.

  6.  Run AutoConfig on the application tier 

Follow the steps in the section "Run AutoConfig on the Application Tier" in Using AutoConfig Tools for SystemConfiguration of Oracle E­Business Suite Setup Guide to run AutoConfig on all application tier nodes. 

7.  Synchronize appsutil on the database tier nodes To copy AutoConfig and Rapid Clone files to each database node with the admkappsutil.pl utility, follow thesteps under the "Copy AutoConfig to the RDBMS ORACLE_HOME" section in Patching AutoConfig of Oracle E­Business Suite Setup Guide. 

8.  Run AutoConfig on the database tier Follow the steps under the "Run AutoConfig on the Database Tier" section in Using AutoConfig Tools for SystemConfiguration of Oracle E­Business Suite Setup Guide to run AutoConfig on the database tier nodes. 

9.  Maintain snapshot information Log in to each application tier node as the applmgr user, and run "Update current view snapshot" in ADAdministration. Refer to Oracle E­Business Suite Maintenance Guide for more information.

Section 3: Standard Cloning Tasks

Use Rapid Clone to create template files for cloning on the Source System. After copying the Source System to theTarget System, Rapid Clone updates these templates to include the new Target System configuration settings. RapidClone never changes the Source System configuration.

The cloning process consists of the following three phases, each of which is made up of several logical sections andtheir steps.

1.  Prepare the Source System for database tier and application tier. 2.  Copy both database tier and application tier nodes from the Source System to Target System. 3.  Configure the Target System for both database tier and application tier.

Note: Before following the steps of this section, review Section 8: Known Issues.

3.1 High Level Standard Cloning Process for Application Tier3.2 Standard Cloning Steps

3.1 High Level Standard Cloning Process for Application Tier

In addition to cloning the database tier node, the standard cloning process for application tier basically involves thefollowing two key processes:

1.  Copy the application tier node from the Source Run Edition File System to the Target Run Edition File System. 

2.  Copy the application tier node from the Target Run Edition File System to the Target Patch Edition File System.

This high level cloning process specific to application tier can be illustrated in the following diagram:

Diagram 1: Process of Standard Cloning Tasks in Application Tier

 

3.2 Standard Cloning Steps

The following steps are to perform standard cloning tasks:

1.  Prepare the Source System for database tier and application tier

Execute the following commands to prepare the Source System for cloning:  

Note: Ensure all the processes in the Source System are up before proceeding with the following twosteps.

1.  Prepare the Source System database tier for cloning 1.  Log on to the Source System as the oracle user.2.  Source the Database tier environment file.3.  Execute the following commands:

$ cd <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME> $ perl adpreclone.pl dbTier

2.  Prepare the Source System application tier for cloning

1.  Log on to the primary node of the Source System as the applmgr user.2.  Source the environment file of the Run Edition File system.

You can use the following command to confirm that the environment variable FILE_EDITIONpoints to the Run Edition File System:

$ echo $FILE_EDITION

It should return the value:

run

3.  Execute the following commands:

$ cd <INST_TOP>/admin/scripts$ perl adpreclone.pl appsTier

Note: If you apply a new Rapid Clone or AutoConfig update to the system, you must executeadpreclone.pl again on the database tier and applications tier to apply the new files into the clonedirectory structures to be used during the cloning configuration stage. Furthermore, if you patchOracle Fusion Middleware or make configuration changes to the Oracle E­Business Suite WebLogicDomain, you must execute adpreclone.pl again on the applications tier to rebuild the Oracle FusionMiddleware home.

As of Release 12.2, the adpreclone.pl process on the application tier creates a complete compressedarchive of the Oracle Fusion Middleware and its components as follows:

A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilitieshome, 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

3.  Shut down the application processes (Windows platform only) 

Log on to Run Edition File System in the Source System as the applmgr user, and shut down all theapplication processes.

2.  Copy both database tier and application tier nodes from the Source System to the Target System  Copy the application tier file system from the Source node to the Target node by executing the following steps inthe order listed. Ensure the application tier files copied to the Target System are owned by the Target applmgruser, and that the database node files are owned by the Target oracle user.  

Note: In the copying tasks below, UNIX users should ensure that the symbolic links (soft links) arepreserved when copying. On most UNIX platforms, you can accomplish this with the cp ­RH command.Consult the UNIX man page for the cp command to check the parameters available on your platform.

For example:

$ cd /Target_dest_dir/db $ cp ­RH /Source_dir/db/

Alternatively, you can use the tar command to compress the directories into a temporary staging area. UNIXusers should ensure that the symbolic links (soft links) are preserved when compressing. On most UNIXplatforms, this is the default behavior of the tar command. Consult the UNIX man page for the tar commandto check the parameters available on your platform.

In addition, verify the permissions of the executables under ORACLE_HOME/bin that can potentially be owned byroot, such as nmo, nmhs, and nmb. 

1.  Copy the database node file system

Log on to the Source System database node as the oracle user, and then: 

1.  Perform a normal shut down of the Source System database. 

2.  Copy the database (.dbf) files from the Source System to the Target System. 

3.  Copy the Source System database ORACLE_HOME to the Target System. 

4.  Start the Source applications system database and application tier processes. 

2.  Copy the application tier file system from the Source "Run Edition File System" to the Target"Run Edition File System"

Log on to Run Edition File System in the Source System application tier nodes as the applmgr user. 

Copy the following application tier directories from the Source Node to the Target Run Edition File Systemapplication tier node:

<APPL_TOP> 

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

The same operating system user must own both the Run Edition and Patch Edition File Systems.  

Note: In Release 12.2, you can set the base directory to any desired location. However, thesubdirectory structure cannot be changed because of dependencies on both the WLS domain and thedual file system required for online patching. Also, the base directory must be the same across allnodes in multi­node configurations.

Dual File System Directory Structure 

In Release 12.2, the following directory structure exists to support the Run Edition and Patch Edition FileSystems: 

Note: <s_base> and <sid> are user­defined values. 

<s_base>/<sid>/fs1 (for example, /u01/122/prod/fs1) 

<s_base>/<sid>/fs2 (for example, /u01/122/prod/fs2)

Two environment variables, $RUN_BASE and $PATCH_BASE, store these locations. The function (run orpatch) of these two file systems is not static, and their values switch every time when a cutover phase iscomplete.  

Note: As Rapid Clone will create a replica of the Source Node, if the Source Run Edition File Systemis the first file system (fs1), the Target Run Edition File System will also be the first file system (fs1).Similarly, if the Source Run Edition File System is the second file system (fs2), then the Target RunEdition File System will also be the second file system (fs2). Therefore, when you perform a cloningtask, you always clone and copy the Source Run Edition File System to create the Target Run EditionFile System, but the directory location of the Run Edition File System can be pointing either to<s_base>/<sid>/fs1 or <s_base>/<sid>/fs2 based on the Source Run Edition File System basedirectory.

When copying the files, use the values of $RUN_BASE and $PATCH_BASE variables to determine if the RunEdition File System should be copied to fs1 or fs2. 

For example, the Source Run Edition File System has the following values: 

$RUN_BASE=/u01/122/prod/fs2 $PATCH_BASE=/u01/122/prod/fs1

The Target <s_base> directory will be /d05/test. Copy the Source Run Edition File System into theTarget /d05/test/fs2 directory to initially act as Run Edition File System. 

3.  Configure the Target System

Run the following commands to configure the Target System. You will be prompted for specific Target Systemvalues such as SID, paths, and ports.

1.  Configure the Target System database server

1.  Log on to the Target System as the oracle user and enter the following commands:

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin $ perl adcfgclone.pl dbTier

2.  Run EBS Technology Codelevel Checker (ETCC) 

Note: This step is needed only if the source instance has Patch 18288881(R12.TXK.C.Delta.5) and Patch 20043910 (November Bundle Patches for TXK Delta 5) orhigher, applied.

Run the EBS Technology Codelevel Checker (ETCC) described in My Oracle Support KnowledgeDocument 1594274.1, Oracle E­Business Suite Release 12.2: Consolidated List of Patches andTechnology Bug Fixes to confirm that all required database patches have been applied.

EBS Technology Codelevel Checker (ETCC) is available via Patch 17537119 and analyzes anOracle Database Oracle Home, and warns of any missing database bug fixes required for OracleE­Business Suite Release 12.2. It is run with the command checkDBpatch.sh (on UNIX) orcheckDBpatch.cmd (on Windows). Further instructions are available in the patch readme. Pleaseensure to install the latest version of ETCC.

2.  Configure the Target System application tier server nodes 

1.  Log on to the Run Edition File System in the Target System as the applmgr user and enter thefollowing commands:

$ cd <COMMON_TOP>/clone/bin$ perl adcfgclone.pl appsTier

At the prompt "Target System Base Directory", enter the location of the base directory. Forexample: /u02/r122.

When asked the question: 

"Do you want to startup the Application Services for mult35? (y/n)" you should answer 'y'.

2.  Source the environment file of the Run Edition File System and run adpreclone.pl on the RunEdition File System. 

3.  Copy Oracle E­Business Suite application directories from the Run Edition File System to the PatchEdition File System. 

Note: Make sure you pay attention to symbolic links under <OracleAS Tools 10.1.2ORACLE_HOME> and <COMMON_TOP> directories when copying files.

4.  Log on to the Patch Edition File System in the Target System as the applmgr user and enter thefollowing commands:

$ cd <COMMON_TOP>/clone/bin$ perl adcfgclone.pl appsTier

The Patch Edition File System must be aware of the location of the Run Edition File System thatwill be configured in the next step. At the prompt "Location of Run System Context File", enter theabsolute path to the context file for the Run Edition File System that was created in the previousstep. 

For example: /u02/r122/fs1/inst/apps/PROD_atgserver/appl/admin/PROD_atgserver.xml.

Note: If adcfgclone.pl fails during the configuration process, review the following beforeany new cloning attempt:

Complete Oracle Fusion Middleware Home. 

Complete INST_TOP directory.

Verify if Oracle Inventory contains the following Oracle Home entries:

<FMW_HOME>/oracle_common <FMW_HOME>/webtier<FMW_HOME>/Oracle_EBS­app1

If any of the above Oracle Home entries are already registered in OracleInventory, you can execute the following command to de­register or detachthat Oracle Home:

$ ./runInstaller ­detachhome \ORACLE_HOME=<Oracle Home Location>

For example:

$ cd /u02/r122/fs1/FMW_Home/oracle_common/oui/bin$ ./runInstaller ­detachhome \ORACLE_HOME=/s0/r122/at1/FMW_Home/oracle_common

In addition to the deregistration process, be sure to delete the FMW_HOME directory structure asfollows:

$ rm ­rf <FMW_HOME>

Section 4: Finishing Tasks

This section lists tasks that may be necessary, depending on your implementation and intended use of the clonedsystem.

1.  Update profile optionsRapid Clone updates only site level profile options. You must manually update any other profile options set toinstance specific values. 

2.  Update printer settingsIf the new cloned system needs to utilize different printers, update the Target System with the new printersettings now. 

3.  Update Workflow configuration settingsCloning an Oracle E­Business Suite instance does not update the host and instance­specific information used byOracle Workflow. Review the table and column names listed in Table 2 below to check for any instance­specificdata in the Oracle Workflow configuration of the Target System.

Table 2: Workflow Configuration Settings 

Table Name Column Name Column Value Details

WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE If value starts with "http://<old web host>:",update to new web host.

WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE If value starts with "http://<old web host>:",update to new web host.

WF_SYSTEMS GUIDUsing the Workflow Administrator WebApplications responsibility, create a new systemdefined as the new global database name.

WF_SYSTEMS NAME Replace value with the database global name.

WF_AGENTS ADDRESS Update database link with the new database globalname.

FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name.

FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PL/SQL listener name.

FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the log filedirectory.

FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the TargetSystem.

4.  Verify the APPLCSF variable setting Source the APPS environment and confirm that the variable APPLCSF (identifying the top­level directory forconcurrent manager log and output files) points to a suitable directory. To modify, change the value of the<s_applcsf> variable in the context file and then run AutoConfig.

5.  Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERSIf the Target System is in a different domain name from the Source System and SESSION_COOKIE_DOMAIN isnot null in the Source System, update the value of SESSION_COOKIE_DOMAIN to reflect the new domain name. 

6.  Re­Implement SSL and SSO configurationIf the Source System is Secure Sockets Layer (SSL) or Oracle Access Manager­enabled, and you want theTarget to be SSL or Oracle Access Manager­enabled, reconfigure the Target according to the SSL or OracleAccess Manager documentation. Otherwise, if you do not want the Target to be SSL or Oracle Access Manager­enabled, follow the same SSL or Oracle Access Manager documentation to undo the SSL or Oracle AccessManager setup.

Section 5: Advanced Cloning Options

This section describes various advanced cloning options provided to meet particular needs.

5.1 Refreshing a Target System5.2 Cloning a Multi­Node System5.3 Adding a New Application Tier Node to an Existing System5.4 Deleting an Application Tier Node5.5 Cloning an Oracle RAC System5.6 Adding/Deleting a Node from an Existing Oracle RAC Cluster5.7 Cloning the Database Separately

5.1 Refreshing a Target System

You may need to refresh the Target System periodically to synchronize it with changes to the Source System.

Note: Back up the Target context file on the Target System before refreshing the database or application tiers.

To refresh the Target System, perform the following steps as described in previous sections:

Note: The tasks in this section must be executed on both Run Edition and Patch Edition File Systems.

1.  Prepare the Source System. 

2.  Copy the Source System to the Target System.

1.  If the application tier file system in the APPL_TOP, COMMON_TOP, or technology stack needs to berefreshed, copy the portion of the application tier file system that has been updated.

2.  If the RDBMS ORACLE_HOME or the database needs to be refreshed, copy the database node filesystem. If refreshing the database, be sure to refresh the ORACLE_HOME at the same time. 

3.  If any of the above ORACLE_HOME entries are already registered in Oracle Inventory, execute the followingcommand to de­register or detach that ORACLE_HOME:

$ ./runInstaller ­detachhome ORACLE_HOME=<Oracle Home Location>

For example:

$ cd /u02/r122/fs1/FMW_Home/oracle_common/oui/bin $ ./runInstaller ­detachhome \ORACLE_HOME=/s0/r122/at1/FMW_Home/oracle_common ­silent

4.  Configure the Target System.

Specify the existing Target System context file when running adcfgclone.pl commands. 

Note: Ensure that you review additional customized WLS and OHS configuration parameters from theFusion Middleware Console in the Target System.

1.  Configure the Target System database server by logging in to the Target System as the oracle user andentering the following commands to configure and start the database:

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin$ perl adcfgclone.pl dbTier <Database Target context file>

Where database Target context file is <RDBMS ORACLE_HOME>/appsutil/<Target CONTEXT_NAME>.xml. 

2.  Configure the Target System application tier server nodes by logging in to the Target System as theapplmgr user and entering the following commands:

$ cd <COMMON_TOP>/clone/bin$ perl adcfgclone.pl appsTier <APPL_TOP Target context file>

Where APPL_TOP Target context file is <INST_TOP>/appl/admin/<Target CONTEXT_NAME>.xml. 

5.  Perform the standard finishing tasks.

5.2 Cloning a Multi­Node System

This procedure allows the Source System or Target System to be a multi­node system. The essence of cloning a multi­node system involves the following major steps:

1.  Clone the database tier node. 

2.  Clone the primary application tier node from the Source Run Edition File System to the Target Run Edition FileSystem. 

3.  Clone the primary application tier node from the Target Run Edition File System to the Target Patch Edition FileSystem. 

4.  Add further application nodes to the secondary application tier Run Edition File System.

This is achieved by cloning the primary application tier node from the Target Run Edition File System to thesecondary application tier node in the Target Run Edition File System. 

5.  Add additional application tier nodes in the secondary application tier node Patch Edition File System.

This is achieved by cloning the primary application tier node from the Target Patch Edition File System to thesecondary application tier node in the Target Patch Edition File System.

 

Note: Steps 4 and 5 can be repeated until all desired nodes are added to the Target System.

The high level process of cloning a multi­node system in application tier as described above from Step 2 to Step 5 canbe illustrated in the following diagram:

Diagram 2: Process of Cloning a Multi­Node System in Application Tier

Note: Make sure Secure Shell (SSH) is set on all of your application tier nodes if the adop utility is used to handlemultiple nodes. For information on how to set up Secure Shell, see the Patching Procedures chapter of Oracle E­Business Suite Maintenance Guide.

Instructions on Cloning a Multi­Node System

Detailed instructions on how to perform each task described earlier are as follows:

Note: The steps mentioned below are valid for both shared and non­shared file systems.

1.  Perform the standard prerequisite tasks.

Carry out these steps on all Source and Target nodes. 

2.  Perform a full clone (including the prepare, copy and configure steps) of the database tier node. Refer to 3.2Standard Cloning Steps.

3.  Clone the primary application tier node from the Source Run Edition File System to the Target Run Edition FileSystem.

1.  Log on to the primary application tier node in the Source Run Edition File System, source the Run EditionFile System and run the following command:

$ perl adpreclone.pl appsTier

2.  Choose the Target machine. Target system should be on a new host other than any of the Source Nodes.

3.  Copy the following directories from the Source Run Edition File System (fs1 or fs2) to the Target RunEdition File System (fs1 or fs2). 

<APPL_TOP><COMMON_TOP><OracleAS Tools 10.1.2 ORACLE_HOME> 

1.  To determine which file system (fs1 or fs2) is currently the Run Edition File System, run thecommand:

echo $RUN_BASE

2.  If the Source Run Edition File System is under fs1, you should configure the Target Run EditionFile System under fs1 as well. Similarly, if the Source Run Edition File System is under fs2, youshould configure the Target Run Edition File System under fs2.

4.  Configure the Target Run Edition File System by running:

$ perl adcfgclone.pl appsTier

There are some restrictions on the port pool due to limitations of the native WebLogic Server tools usedfor cloning the WebLogic domain.

If you are on R12.TXK.C.DELTA.4 (Patch 17893964) or lower, ensure that the port pool providedfor the Target Run Edition File System is different from the Run Edition File System port pools ofany of the secondary nodes of the Source instance.If you are on R12.TXK.C.Delta.5 (Patch 18288881) and if the Target instance is on the same hostas any of the application tier nodes of the Source instance, ensure that the port pool provided forthe Target Run Edition File System is different from the Run Edition File System port pool of thatSource node.

4.  Clone the primary application tier node from the Target Run Edition File System to the Target Patch Edition FileSystem.

1.  Source the Target Run Edition File System which was configured in the previous step and run thefollowing command there:

$ perl adpreclone.pl appsTier

2.  Copy the following Oracle E­Business Suite applications from the Target Run Edition File System to theTarget Patch Edition File System.

3.  Run the following command to configure the Target Patch Edition File System:

$ perl adcfgclone.pl appsTier

4.  Ensure that the port pool provided for Target Patch Edition File System is different from that of TargetRun Edition File System.

5.  Add the additional application tier secondary node. 

Follow the instructions in the next section, "5.3 Adding a New Application Tier Node to an Existing System," toadd a new node in the Run Edition File System and then in the Patch Edition File System of the Target System. 

6.  Repeat Step 5 to add the desired number of secondary nodes.

Note: If you are using a load balancer to distribute processing across all the application tier nodes, each nodeshould have the value of the s_webentryhost context variable set to be that of the load balancer's hostname.

5.3 Adding a New Application Tier Node to an Existing System

You can use Rapid Clone to clone a node and add it to the existing Applications system, a process also known as scaleup or scale out. The new node may run the same services as the Source node or different services.

Before adding a new node, you should update the tcp.invited_nodes parameter of sqlnet.ora on the database tierto include the host.domain of the new node being added.

Note: The addition of nodes should not be done during an active adop cycle.

5.3.1 Steps for adding a node on a shared file system

Refer to Section 4 of My Oracle Support Knowledge Document 1375769.1, Sharing the Application Tier File System inOracle E­Business Suite Release 12.2, for detailed instructions on adding nodes on a shared file system.

5.3.2 Steps for adding a node on a non­shared file system

1.  Run adpreclone.pl on both the Run and Patch Edition File Systems in the primary application tier node of theTarget System. 

Note: Before executing this step, ensure the AdminServer on both the Run Edition File System and thePatch Edition File System is running. The AdminServer on the Patch Edition File System can be shut downafter completion of adpreclone.pl.

2.  Copy both Run and Patch Edition File Systems to the Target secondary node.

Only the following directories within each File System should be copied:<APPL_TOP> <COMMON_TOP><OracleAS Tools 10.1.2 ORACLE_HOME> 

The secondary node must be on a different host.

If the Target primary node's Run Edition File System is in fs1, then the secondary node's Run Edition FileSystem should also be in fs1. If the Target primary node's Run Edition File System is in fs2, then thesecondary node's Run Edition File System should also be in fs2.

Note: In Release 12.2, the base directory location needs to be set to the same value on all Application tiernodes. This should be taken care of while copying the the Run and Patch Edition File Systems to the Targetsecondary node.

3.  Configure both Run and Patch Edition File Systems in the Target node. 

Note: Before executing these steps, ensure the AdminServer on both the Run Edition File System and thePatch Edition File System is running. This is required for adcfgclone.pl to properly re­register the newnode on the Target System.

1.  Log in as the applmgr user to the Run Edition File System in the Target node and enter the followingcommands: 

Note: Ensure that you enter the correct password for "WebLogic AdminServer." Although RapidClone will not be able to validate the password at this stage, it will fail later if the password isincorrect.

$ cd <COMMON_TOP>/clone/bin$ perl adcfgclone.pl appsTier

When asked the questions: 

"Target System File Edition type [run] :", you should answer 'run'"Do you want to add a node (yes/no)" you should answer 'yes'"Do you want to startup the Application Services for mult35? (y/n)" you should answer 'y'

Note: Ensure that the port pool provided is different from the port pool of the Patch EditionFile System of the primary node. Otherwise, it will result in errors during execution offs_clone.

2.  Log in as applmgr to the Patch Edition File System in the Target node and enter the followingcommands: 

Note: Ensure that you enter the correct password for "WebLogic AdminServer." Although RapidClone will not be able to validate the password at this stage, it will fail later if the password isincorrect.

$ cd <COMMON_TOP>/clone/bin$ perl adcfgclone.pl appsTier

When asked the question:

"Target System File Edition type [run] :", you should answer 'patch'"Do you want to add a node (yes/no)" you should answer 'yes'

4.  Register the new topology from the newly added application tier node.

1.  If OHS is enabled on the newly added node, perform the following steps on that node:

1.  Source the Run Edition File System.

2.  The OHS configuration files mod_wl_ohs.conf and apps.conf will contain entries of managedservers from all Application tier nodes. If any of these managed servers are not desired to be partof the cluster configuration on the current node, execute the following command to delete detailsof these managed servers from the OHS configuration files mod_wl_ohs.conf and apps.conf onthe current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \  ­contextfile=<CONTEXT_FILE> \  ­configoption=removeMS \  ­oacore=<host>.<domain>:<port>  \    ­oafm=<host>.<domain>:<port> \  ­forms=<host>.<domain>:<port> \   ­formsc4ws=<host>.<domain>:<port> \  ­ekanban=<host>.<domain>:<port> \  ­accessgate=<host>.<domain>:<port> \  ­yms=<host>.<domain>:<port>

whereThe argument contextfile accepts the complete path to the context file.The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate andyms accept a comma­separated list of managed server details in thefollowing format:<host>.<domain>:<port>

host, domain and port are the hostname, domain and port of themanaged server whose reference is to be deleted.

For example, to delete references of managed servers oacore_server1 on 'testserver1' andforms_server2 on host 'testserver2' on the domain 'example.com' with ports 7201 and 7601respectively, the following command should be executed:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl ­contextfile=<CONTEXT_FILE> \  ­configoption=removeMS ­oacore=testserver1.example.com:7201 ­forms=testserver2.example.com:7601

2.  Perform the following steps on the other application tier nodes participating in the same cluster wherethis node is added: 

1.  Source the Run Edition File System.

2.  If any of the managed servers from the newly added node are desired to be part of thecluster configuration on the current node, execute the following command to add details ofthese managed servers into the OHS configuration files mod_wl_ohs.conf and apps.conf onthe current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \  ­contextfile=<CONTEXT_FILE> \  ­configoption=addMS \  ­oacore=<host>.<domain>:<port> \  ­oafm=<host>.<domain>:<port> \  ­forms=<host>.<domain>:<port> \  ­formsc4ws=<host>.<domain>:<port>

whereThe argument contextfile accepts the complete path to the contextfile.

The arguments oacore, oafm, forms, formsc4ws accept a comma­separated list of managed server details in the following format:<host>.<domain>:<port>

host and domain are the hostname and domain name of the newlyadded nodeport is the port of the new managed server whose reference isto be added 

For example, if the newly added node on host 'testserver1' and domain 'example.com'contains managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605respectively, the following command should be executed: 

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl ­contextfile=<CONTEXT_FILE> \­configoption=addMS ­oacore=testserver1.example.com:7205 ­oafm=testserver2.example.com:7605

3.  On all Application tier nodes, perform the following steps to register the newly added Application tiernode with the Application tier TNS Listener (FNDFS listener) on each node:

1.  Source the Run Edition file system.

2.  Run AutoConfig. On Unix:

$ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

On Windows:

$ <ADMIN_SCRIPTS_HOME>\adautocfg.cmd

3.  Reload the Application tier TNS Listener (FNDFS listener) as follows:

$ lsnrctl reload APPS_<TWO_TASK>

5.  If the Node Manager service is up on the Patch Edition File System of the newly added Application tier node,shut it down as follows:

On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adnodemgrctl.sh stop

On Windows:

C:\> <ADMIN_SCRIPTS_HOME>\adnodemgrctl.cmd stop

6.  Shut down the Admin Server and the Node Manager on the Patch Edition File System of the primary node asfollows:

On UNIX:

$ <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop$ <ADMIN_SCRIPTS_HOME>/adnodemgrctl.sh stop

On Windows:

C:\> <ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stopC:\> <ADMIN_SCRIPTS_HOME>\adnodemgrctl.cmd stop

7.  Perform the following steps on all Database tier nodes to add the newly added node to the Access Control List.1.  Source the database environment file.2.  Run AutoConfig as follows: 

  On UNIX:

$> <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

On WIndows:

C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd

3.  Reload the Database listener as follows:

C:\> lsnrctl reload <ORACLE_SID>

After adding new nodes, refer to My Oracle Support Knowledge Document 1375686.1, Using Load­Balancers withOracle E­Business Suite Release 12.2, for details on how to set up load balancing.

Note: If SQL*Net access security is enabled in the existing system, you first need to authorize the new node toaccess the database through SQL*Net. Refer to the Oracle Applications Manager online help for instructions onhow to accomplish this.

5.4 Deleting an Application Tier Node

Note: These steps are ONLY for deletion of secondary Application tier nodes. The primary Application tier nodecannot be deleted using these steps.

The following steps should be performed to delete a secondary application tier node from an existing Oracle E­Business Suite Release 12.2 multi­node instance. The steps described in this section are applicable to secondaryapplication tier nodes with shared and non­shared file systems.

Note: In case OHS is enabled only on the secondary node being deleted, OHS needs to first be enabled on someother node before execution of Step 5.4.1.

Before performing the following steps, ensure that the WebLogic administration server is running from both the Runand Patch Edition File Systems of the primary application tier node.

Note: Do not perform a 'delete node' operation when a patching cycle is active.

1.  Delete the run file system and patch file system configuration of the secondary application tier node.

On the secondary node to be deleted, log in and complete the following steps:

1.  Source the run file system.

2.  Ensure that all application tier services from the run and patch file system for the node to be deleted areshut down.

3.  Execute the ebs­delete­node option of the adProvisionEBS.pl script as follows:

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs­delete­node \­contextfile=<CONTEXT_FILE> ­logfile=<LOG_FILE>

This will delete the managed servers, OHS instances and Node Manager on the current node from therun file system WebLogic domain.

4.  If the node is a non­shared node, verify and remove the following Oracle Home entries from the OracleInventory:

<FMW_HOME>/webtier<FMW_HOME>/oracle_common<FMW_HOME>/Oracle_EBS­app1

If any of the above Oracle Home entries are already registered in Oracle Inventory, you can execute thefollowing command to de­register or detach that Oracle Home:

$ ./runInstaller ­detachhome ORACLE_HOME=<Oracle Home Location>

For example:

$ cd /u02/r122/fs1/FMW_Home/oracle_common/oui/bin$ ./runInstaller ­detachhome \ORACLE_HOME=/u02/r122/fs1/FMW_Home/oracle_common ­silent

Note: The Oracle Home <FMW_HOME>/webtier should be de­registered from the Oracle Inventorybefore trying to remove the Oracle Home <FMW_HOME>/oracle_common.

5.  If the node is a non­shared node, verify and remove the following Oracle Home entry from the OracleInventory:

<OracleAS Tools 10.1.2 ORACLE_HOME>

If the above Oracle Home entry is registered in Oracle Inventory, you can execute the followingcommand to de­register the Oracle Home:

$ ./runInstaller ­removeHome ORACLE_HOME=<s_tools_oh> ­silent

For example:

$ cd /u02/r122/fs1/EBSapps/10.1.2/oui/bin$ ./runInstaller ­removeHome \ORACLE_HOME=/u02/r122/fs1/EBSapps/10.1.2 ­silent

6.  Source the patch file system. 

7.  Execute the ebs­delete­node option of the adProvisionEBS.pl script from the patch file system asfollows (this step should be performed only if you are on R12.TXK.C.Delta.4 or lower):

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs­delete­node \­contextfile=<PATCH_CONTEXT_FILE> ­logfile=<LOG_FILE>

This will delete the managed servers, OHS instances and Node Manager on the current node from thepatch file system WebLogic domain. 

8.  If the node is a non­shared node, verify and remove the following Oracle Home entries from the OracleInventory:

<FMW_HOME>/webtier<FMW_HOME>/oracle_common<FMW_HOME>/Oracle_EBS­app1

Refer to Step 4 above for complete details. 

9.  If the node is a non­shared node, verify and remove the following Oracle Home entry from the OracleInventory:

<OracleAS Tools 10.1.2 ORACLE_HOME> 

Refer to Step 5 above for complete details. 

2.  Sync the configuration on the other nodes to remove references of the deleted node.

Perform the following steps on the other nodes:

1.  Source the Run Edition File System.

2.  If any of the managed servers from the deleted node are part of the cluster configuration defined on thecurrent node, execute the following command to delete details of these managed servers from the OHSconfiguration files mod_wl_ohs.conf and apps.conf on the current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \  ­contextfile=<CONTEXT_FILE> \  ­configoption=removeMS \  ­oacore=<host>.<domain>:<port> \  ­oafm=<host>.<domain>:<port> \  ­forms=<host>.<domain>:<port> \  ­formsc4ws=<host>.<domain>:<port> \  ­ekanban=<host>.<domain>:<port> \   ­accessgate=<host>.<domain>:<port> \  ­yms=<host>.<domain>:<port>

whereThe argument contextfile accepts the complete path to the context file.The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and ymsaccept a comma­separated list of managed server details in the followingformat:<host>.<domain>:<port>

host, domain and port are the hostname, domain and port of the managedserver whose reference is to be deleted.

For example, if the deleted node was on host 'testserver1' and domain 'example.com' and it containedmanaged servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the followingcommand should be executed to remove references to these managed servers:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl ­contextfile=<CONTEXT_FILE>­configoption=removeMS ­oacore=testserver1.example.com:7205 ­oafm=testserver1.example.com:7605

3.  Run AutoConfig on the database tier.

1.  Log into the database tier node.

2.  Run AutoConfig on the database tier by executing the following command:

For UNIX:

$ <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

For Windows:

C:>\ <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd

This step is required to sync­up the tcp.invited_nodes attribute in sqlnet.ora to remove the deletednode from the value of this attribute.  

3.  Bounce the database listener by executing the following command:  For UNIX:

$> sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh stop <ORACLE_SID>$> sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh start <ORACLE_SID>

For Windows:

C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd stop <ORACLE_SID>C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd start <ORACLE_SID>

Notes:

Execution of ebs­delete­node option as mentioned above will not delete the contents of the file system. Thishas to be done manually by the customer once Step 5.4.1 is completed successfully.

For non­shared node, the following directories can be deleted:

<NE_BASE><RUN_BASE><PATCH_BASE>EBSapps.env

For a shared file system node, only the <INST_TOP> directory of the Run Edition File System and the PatchEdition File System should be deleted.

On all OHS enabled nodes, patch file system OHS configuration will automatically be synced up during nextadop prepare phase.

5.5 Cloning an Oracle RAC System

For details on RAC cloning, please refer to My Oracle Support Knowledge Document 1679270.1, Cloning Oracle E­Business Suite Release 12.2 RAC Enabled Systems with Rapid Clone.

5.6 Adding/Deleting a Node from an Existing Oracle RAC Cluster

As of Release 12, Rapid Clone no longer supports the migration of a database tier to Oracle RAC. Refer to My OracleSupport Knowledge Document 1570554.1, Adding and Deleting Oracle RAC Nodes for Oracle E­Business Suite Release

12.2.x on Oracle Database 11gR2, for instructions on how to perform this task.

5.7 Cloning the Database Separately

Some situations require the database to be recreated separately, without using Rapid Clone. A typical scenario may bewhen system downtime is not feasible, or an advanced database replication tool such as RMAN is being used to copythe database in hot backup mode.

This section documents the steps that allow manual creation of the Target database control files within the Rapid Cloneprocess. You should use this method for databases located on raw partitions, or when cloning a hot backup. Follow allthe steps in Section 3: Standard Cloning Tasks, but replace Step 1 of steps to configure the Target System databaseserver with the following steps:

1.  Log in as oracle to the Target System.

2.  Configure the database Oracle Home.

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin$ perl adcfgclone.pl dbTechStack

3.  Create the Target database control files manually.

In this step, you copy and recreate the database using your preferred method, such as RMAN restore, FlashCopy, Snap View, or Mirror View.

4.  Start the Target database in open mode.

5.  Run AutoConfig in the INSTE8_SETUP mode on the database tier as follows:

On UNIX:

$ sh <RDBMS_ORACLE_HOME>/appsutil/bin/adconfig.sh contextfile=<CONTEXT_FILE>run=INSTE8_SETUP

On Windows:

C:\> <RDBMS_ORACLE_HOME>\appsutil\bin\adconfig.cmd contextfile=<CONTEXT_FILE>run=INSTE8_SETUP

6.  Run the library update script against the database.

$ cd <RDBMS ORACLE_HOME>/appsutil/install/<CONTEXT NAME>$ sqlplus "/ as sysdba" @adupdlib.sql <libext>

Where <libext> should be set to sl for HP­UX, so for any other UNIX platform, or dll for Windows.

7.  Configure the Target database.

The database must be running and open before performing this step.

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin$ perl adcfgclone.pl dbconfig <Database Target Context File>

Where "Database Target Context File" is: <RDBMS ORACLE_HOME>/appsutil/<Target CONTEXT_NAME>.xml. 

Note: The dbconfig option will configure the database with the required settings for the new Target, but it

will not recreate the control files.

Section 6: Automating Rapid Clone

This section describes various cloning procedures that can be automated while cloning Oracle E­Business Suite withRapid Clone. These procedures include:

6.1 Cloning the Context File Only6.2 Cloning the Context File in Non­Interactive Mode6.3 Running adcfgclone.pl in Non­Interactive Mode

Note that directory names /u04/SOURCE and /u04/TARGET used in the command lines later in each procedure aregiven as examples. You should execute the commands with directory names suitable to your business.

6.1 Cloning the Context File Only

Run the following commands to automate the context file cloning procedure. These commands will not affect theSource System.

Database tier

$ perl adclonectx.pl \contextfile=/u04/SOURCE/db/tech_st/11.2.0/appsutil/SOURCE_testserver.xml \outfile=/u04/TARGET/db/tech_st/11.2.0/appsutil/TARGET_testserver.xml

This command will create /u04/TARGET/db/tech_st/11.2.0/appsutil/TARGET_testserver.xml.

Applications tier

$ perl adclonectx.pl \contextfile=/u04/SOURCE/inst/apps/SOURCE_testserver/appl/admin/SOURCE_testserver.xml \outfile=/u04/TARGET/inst/apps/TARGET_testserver/appl/admin/TARGET_testserver.xml

This command will create/u04/TARGET/inst/apps/TARGET_testserver/appl/admin/TARGET_testserver.xml.

6.2 Cloning the Context File in Non­Interactive Mode

You can automate context file cloning in non­interactive mode by running the following commands:

Note: Ensure that you use a normal interactive session to supply all the variables prompted. You might need torun the commands several times until there are no issues.

Database tier

$ perl adclonectx.pl \contextfile=/u04/SOURCE/db/tech_st/11.2.0/appsutil/SOURCE_testserver.xml \outfile=/u04/TARGET/db/tech_st/11.2.0/appsutil/TARGET_testserver.xml \pairsfile=/d01/stage/pairsfile.txt noprompt

Applications tier

$ perl adclonectx.pl \contextfile=/u04/SOURCE/inst/apps/SOURCE_ testserver/appl/admin/SOURCE_testserver.xml \outfile=/u04/TARGET/inst/apps/TARGET_testserver/appl/admin/TARGET_testserver.xml \

pairsfile=/u04/TARGET/pairsfile.txt noprompt

The pairsfile is a text file only contains variables and values. 

The sample pairsfile for application tier is delivered under INST_TOP of each file system in the below location:<INST_TOP>/appl/admin/<SID>_<hostname>_run.txt

For example:s_base=/u04/TARGETs_at=/u04/TARGET/apps/apps_st/appl

6.3 Running adcfgclone.pl in Non­Interactive Mode

Run the following commands to execute adcfgclone.pl using a pre­created context file:

Database tier

$ perl adcfgclone.pl dbTier \/u04/TARGET/db/tech_st/11.2.0/appsutil/TARGET_testserver.xml

Applications tier

$ perl adcfgclone.pl appsTier \/u04/TARGET/inst/apps/TARGET_testserver/appl/admin/TARGET_testserver.xml

Section 7: Other Cloning Procedures

This section describes the cloning procedures that can be executed separately. All cloning procedures described herecan also be run in non­interactive mode.

Note: If you have installed Oracle E­Business Suite Extensions for Oracle Endeca, see My Oracle SupportKnowledge Document 1574273.1, Installing Oracle E­Business Suite Extensions for Oracle Endeca, for informationabout cloning the integrated Oracle Endeca instance.

Cloning Procedures

Available cloning procedures can be summarized as follows:

Database tierCloning the technology stack on the database tier (dbTechStack)See: Cloning the Technology Stacks Only

Cloning the database (database)See: Cloning the Database Only

Configuring the database onlySee: Configuring the Database Only

Applications tierCloning the technology stack on the application tiers (atTechStack)See: Cloning the Technology Stacks Only

Cloning and configuring the APPL_TOP (appltop)See: Cloning the APPL_TOP Only

7.1 Cloning the Technology Stacks Only

Run the following commands to clone and configure the relevant technology stack components:

Database tier

Run this command to clone the database tier technology stack:

$ perl adcfgclone.pl dbTechStack

Applications tier

Run this command to clone the applications tier technology stack, namely the OracleAS 10.1.2 Oracle CloningProcedures Home, Oracle Fusion Middleware (FMW) Home, Oracle WebLogic Server domain configuration, andOracle HTTP Server configuration:

$ perl adcfgclone.pl atTechStack

Run this command to clone the OracleAS 10.1.2 Oracle Home only:

$ perl adcfgclone.pl dev10gHome

Run this command to clone the FMW Home binaries only:

$ perl adcfgclone.pl fmwHome

Run this command to clone the Oracle WebLogic Server domain configuration only:

$ perl adcfgclone.pl wlsConfig

Run this command to clone the Oracle HTTP Server configuration only:

$ perl adcfgclone.pl ohsConfig

Important Restrictions on Application Tier Cloning

The wlsConfig and ohsConfig cloning commands will work only if a context file is passed in as an argument.In other words, for the wlsConfig and ohsConfig commands the context file will not be cloned.The fmwHome cloning command should be performed before the wlsConfig command is performed.The ohsConfig cloning command cannot be performed before the wlsConfig command is performed.Even though the ohsConfig cloning command will work without WebLogic Admin Server running, it is advisableto ensure WebLogic Admin Server has been started before performing the ohsConfig cloning command.

7.2 Cloning the Database Only

Run the following command to re­create the control file and configure the database. This command will not reconfigurethe database Oracle Home.

$ perl adcfgclone.pl database

7.3 Configuring the Database Only

Run the following command to clean the topology data model and nodes, as well as to reconfigure the Oracle E­Business Suite data for the new Target. Ensure that the database is running and open before executing this command.

$ perl adcfgclone.pl dbconfig

7.4 Cloning the APPL_TOP Only

Run the following command to only clone and configure the APPL_TOP only. This command will not clone or configurethe applications tier technology stack.

$ perl adcfgclone.pl appltop

Section 8: Known Issues

Bug 12960775: Force usage of passing ignorediskwarning option to FMW cloning toolT2P tools cloning copyBinary/pasteBinary had constraints performing disk space calculations when Source orTarget Systems are NFS mounted on a different file system such as Data ONTAP (Bug 12680165) which causesFusion Middleware cloning to fail. As a workaround, before cloning, set the environment variableIGNORE_FMW_DISK_WARNING to "true".

For example:

$ IGNORE_FMW_DISK_WARNING=true$ export IGNORE_FMW_DISK_WARNING

Bug 12959323: T2P cloning tools require 10GB of free space in /tmpIn order to run the T2P Tools successfully, you must have at least 10GB of free space in /tmp, which issufficient to store a complete copy of the FMW_Home (bug 12856307). This applies for all the cloning actions inthe Source (preclone) and Target (adcfgclone). 

Alternatively, you can also set the environment variable T2P_JAVA_OPTIONS with the directory of your choiceas mentioned in Bug 12856307. 

For example:

$ T2P_JAVA_OPTIONS="­Djava.io.tmpdir=/home/t2p/temp"$ export T2P_JAVA_OPTIONS

Note: Setting T2P_JAVA_OPTIONS will not work correctly on Oracle Solaris platforms.

Bug 14732226 ­ PasteBinary logic to set JRE_LOCATION of generic Oracle home needs to beenhancedDue to the issue with the T2P tool "pasteBinary", the JRE_LOCATION in the <FMW_HOME>/Oracle_EBS­app1/oui/oraparam.ini file of the cloned R12.2 instance is being incorrectly set incase 32­bit jdk beingused in a 64­bit platform. As a result cloning an Oracle E­Business Suite Release 12.2 64­bit environment using32­bit jdk, <FMW_HOME>/Oracle_EBS­app1/oui/bin/runInstaller fails to launch as 32­bit jdk is being used tolaunch a 64­bit runInstaller.

On a cloned Oracle E­Business Suite Release 12.2 instance having split JDK configuration (i.e., Release 12.2Oracle E­Business Suite on a 64­bit platform using a 32­bit JDK), use the following commands to manually de­register or re­register <FMW_HOME>/Oracle_EBS­app1:

For de­registering <FMW_HOME>/Oracle_EBS­app1: 

<FMW_HOME>/Oracle_EBS­app1/oui/bin/detachHome.sh ­jreLoc<FMW_HOME>/Oracle_EBS­app1/jdk

For re­registering <FMW_HOME>/Oracle_EBS­app1:

<FMW_HOME>/Oracle_EBS­app1/oui/bin/attachHome.sh ­jreLoc<FMW_HOME>/Oracle_EBS­app1/jdk

Bug 12680165 ­ T2P close is not checking the space correctlyIn Release 12.2, it is not supported to have symbolic links in the Oracle E­Business Suite file system. The systemtemporary directory (typically, /tmp) must also be on a local file system and must not be a symbolic (soft) link. 

Bug 18913244 ­ Add new node ends with exception in shared file system configurationOn AIX Platforms, the following exception may be displayed on the console or in the log file at the end of addinga node on the Run Edition File System and the Patch Edition File System. 

java.io.IOException: Interrupted system call        at java.io.FileInputStream.readBytes(Native Method)        at java.io.FileInputStream.read(FileInputStream.java:284)        atjava.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:465)        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:322)        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:364)        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:210)        at java.io.InputStreamReader.read(InputStreamReader.java:205)        at java.io.BufferedReader.fill(BufferedReader.java:165)        at java.io.BufferedReader.readLine(BufferedReader.java:328)        at java.io.BufferedReader.readLine(BufferedReader.java:393)        atweblogic.management.scripting.utils.WLSTProcess.run(WLSTProcess.java:80)        at java.lang.Thread.run(Thread.java:795)NMProcess: Stopped draining NMProcess

This exception will be seen if your instance is at R12.TXK.C.Delta.5 level which delivers code to shutdown theNode Manager at the end of node addition. This exception is thrown only because of a difference in the wayNode Manager shutdown is handled on AIX platform and can be ignored.

Change Log

Date Description

03 Dec 2014 Rephrased the section containing instructions for running ETCC.

02 Dec 2014Added the step to run ETCC after database tier clone.Added Global Inventory Requirements in Section 2.Added known issues and updated the content to have more clarity.

15 Jul 2014 Modified the content in Section 5.3.Updated the title of Note 1617461.1.

18 Jun 2014 Corrected prompts referenced in Section 5.3Added information to Bug 12680165 in Section 8

17 Jun 2014 Updated Section 8 bug information

04 Jun 2014 Inserted updated content from Cloning chapter in Oracle E­Business Suite Setup Guide

28 Feb 2014 Added new required patches AD/TXK.DELTA.3

My Oracle Support Knowledge Document 1383621.1 by Oracle E­Business Suite Development.

Documentation Notices

Copyright © 2013, 2014, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use anddisclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement orallowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit,perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, ordecompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error­free. If you findany errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf ofthe U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programsinstalled on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computersoftware" pursuant to the applicable Federal Acquisition Regulation and agency­specific supplemental regulations. Assuch, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system,integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license termsand license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is notdeveloped or intended for use in any inherently dangerous applications, including applications that may create a risk ofpersonal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to takeall appropriate fail­safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and itsaffiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of theirrespective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are usedunder license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo,and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registeredtrademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and servicesfrom third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties ofany kind with respect to third­party content, products, and services. Oracle Corporation and its affiliates will not beresponsible for any loss, costs, or damages incurred due to your access to or use of third­party content, products, orservices.

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website athttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visithttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.