EBS 12.2 Cloning Interview Questions with Scenarios

These are very Important questions and should be known if you are going for Interview

1. What is cloning and why is it required?

Cloning is the process of creating an identical copy of the Oracle application system.

It is required due to following reasons:

Creating a test copy of your production system before upgrading.

Moving an existing system to a different machine.

To test some patches.

Creating a development copy of your environment to be used by the developers.

Different Copies of the Production System to be used by Testing/Development Team with latest set of data.

2. What is the location of adpreclone.pl in oracle database?

$ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME

3. What is the location of adcfgclone.pl in oracle database?

$ORACLE_HOME/appsutil/clone/bin

4. What is the location of adpreclone.pl in oracle application?

$INST_TOP/admin/scripts

5. What is the location of adcfgclone.pl for applmgr user?

$COMMON_TOP/clone/bin

6. How often do you clone?

Cloning happens weekly,monthly,Halfyearly or on-demand depending on the organisation/client's requirement.

7. When do you run adpreclone on Production?

If you apply a new Rapid Clone or AutoConfig update to the system, you must execute adpreclone.pl again on the database tier and application tier to apply the new files into the clone directory structures to be used during the cloning configuration stage. Furthermore, if you patch Oracle Fusion Middleware or make configuration changes to the Oracle E-Business Suite WebLogic Domain, you must execute adpreclone.pl again on the application tier to rebuild the Oracle Fusion Middleware home.

8. When we run perl adpreclone.pl dbTier why it requires apps password?

It requires a database connection to validate apps schema.

9. When we run perl adpreclone.pl on Application Tier , what happens in terms of FMW Home?

It creates a complete compressed archive of the Oracle Fusion Middleware and its components.

Details:

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

The adpreclone log files are created in the <INST_TOP>/admin/log/clone directory.

10. What happens when doing prepare adpreclone on database

On Source system, run following as ORACLE user:-

cd RDBMS O_H/apps util/scripts/<Sid>_<hostname>

perl ./adpreclone.pl dbTier

➢ There are two stages to db Tier:

➢ DBTechStack

➢ Database

Usage:

perl adpreclone.pl <component>

➢ Where:

➢ <component> on Apps Node : { appsTier | appltop | atTechStack

➢ <component> on DB Node : { dbTier | database | dbTechStack

➢ Note:

On DB Node, adpreclone.pl will prompt for the APPS password.

$ perl adpreclone.pl dbTier

What does this do?

➢ Creates the transfer clone stage area

➢ $ORACLE_HOME/appsutil/clone

➢ This contains the following directories

➢ data, main clone directory

➢ Jre, 1.7 for 12c, 1.8 for 19c

➢ bin, Cloning Executables

➢ Jlib, Java Classes

➢ dbts, Empty Directory, not used.

➢ html, Empty Directory, not used.

➢ Context, context file and template

Prepare db Tech Stack

➢ Converts DB OraInventory - binary to XML (if req.)

$ORACLE_HOME/inventory

➢ Changes static path links to relative path links

➢ Creates templates of files containing hardcoded source system values

(covers oraInventory and rdbms)

$ORACLE_HOME/appsutil/template

➢ Creates the Rapid Clone DB Tech stack driver file

$ORACLE_HOME/appsutil/driver/regclone.drv

Prepare database

➢ Generates Database Creation Driver file.

$O_H/appsutil/clone/data/driver/data.drv

➢ Copies the JDBC Libraries into the clone stage area

$O_H/appsutil/clone/jlib/ojdbc6.jar

➢ Generates Database Create Control File script templates.

➢ $O_H/app sutil/clone/context/data/stage/addbhomsrc.xml

➢ $O_H/app sutil/clone/context/data/stage/adcrdb.zip

➢ adcrdbclone.sql

➢ dbinfo.lst

➢ adcrdb.sh

11. What adpreclone.pl does on appsTier?

It will collects all the information about the source system, creates a cloning stage area, and generates templates and drivers. All of these are to reconfigure the instance on a Target machine.

cd $ADMIN_SCRIPTS_HOME

perl adpreclone.pl appsTier

➢ There are two stages to apps Tier:

➢ atTechstack

➢ appltop

Usage:

perl adpreclone.pl <component>

➢ Where:

<component> on Apps Node : { appsTier | atTechStack | dev10ghome |

fmwHome | wlsConfig | ohsConfig | appltop }

<component> on DB Node : { dbTier | database | dbTechStack}

➢ Note:

On DB Node, adpreclone.pl will prompt for the APPS password

$ perl adpreclone.pl appsTier

What does this do?

➢ Perform Pre-clone steps, pre-Reqs etc

➢ Run “perl adpreclone.pl appsTier”

➢ Creates the transfer clone stage area containing the templates, drivers,

scripts and java code required for Rapid Clone

➢ $COMMON_TOP/clone

➢ Creates XML inventory

➢ Creates Clone stage area

➢ Creates FMW and OHS binaries archive

➢ FMW_Home.jar

➢ cloningclient.jar

➢ OHS

➢ ohsarchive.jar

➢ moveplan.xml

➢ WLS

➢ EBSdomain.jar

➢ Deployments plans

This contains the following directories

➢ appl – Empty Directory, not used.

➢ appsts – Empty Directory, not used.

➢ jre – JRE 1.7.x

➢ bin –scripts : adcfgclone.pl, adchkutl.sh (Check system for ld, ar, cc, and

make), adclone.pl, adclonectx.pl

➢ jlib –Rapid Clone java source

➢ FMW – contains packed FMW and OHS home binaries

➢ html – Empty Directory, not used.

➢ context–contains the source APPL_TOP XML Context File and the template

XML context file.

Prepare at Tech Stack

➢ Changes static path links to relative path links

➢ Creates templates of files containing hardcoded source system values

$ORACLE_HOME/appsutil/template

➢ Creates the Tech stack driver files

$ORACLE_HOME/appsutil/driver/preclone.drv

12. When we run adcfgclone.pl which script it will call?

It will call adclone.pl which is located at $AD_TOP/bin .

13. Does clone preserve the patch history?

Yes, Rapid Clone will preserve the Patch History of the complete Applications

Stack:

➢ RDBMS ORACLE_HOME – OraInventory

➢ FMW Homes (ORACLE_COMMON)–OraInventory

➢ FMW Homes (webtier) – OraInventory

➢ FMW Home (Oracle EBS App) – OraInventory

➢ Forms & Reports (10.1.2)ORACLE_HOME-OraInventory

➢ APPL_TOP- patch level and history tables

14) What are the important pre-requisites when cloning on a new Server?

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

a) Verify disk space requirements on Target System

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

b) Verify OS requirements on Target System

Ensure the Target System meets all the requirements for Oracle E-Business Suite as we do for fresh installation.

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

c) Verify Inventory Requirements

A global (central) inventory is generally recommended for all Oracle E-Business Suite Release 12.2 application tier nodes and database tier nodes.

However, starting AD/TXK.Delta.7, support for using an 'EBS Installation Central Inventory' has also been introduced for application tier. This inventory will be specific to an E-Business Suite instance and will be identified by '<s_base>/oraInventory/oraInst.loc'.

This is useful in cases for multiple E-Business Suite installations on the same host. In such setups, having this inventory helps to avoid issues when FS_CLONE is run simultaneously on the different instances.

Note: The 'EBS Installation Central Inventory' is supported only for the application tier and only for UNIX platforms.

Requirements for Global Inventory:

Following are the requirements for using a global inventory:

A global (central) inventory is required for all Oracle E-Business Suite Release 12.2 application tier nodes and database tier nodes..

The central inventory location must be identified by the value defined in oraInst.loc file.

On a shared file system, the global inventory location must be shared and used by all participating nodes.

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

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

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 location must 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 a line such as inst_group=oracle.

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

d) Apply the latest AD/TXK patches

You are strongly encouraged to be on the latest AD/TXK codelevel.

e) Apply additional patches

Update the Oracle E-Business Suite file system by applying other additional patches to all application tier server nodes.

f) Run AutoConfig on the application tier

g) Synchronize appsutil on the database tier nodes

To copy AutoConfig and Rapid Clone files to each database node with the admkappsutil.pl utility, follow the steps under the "Copy AutoConfig to the RDBMS ORACLE_HOME" section in Patching AutoConfig of Oracle E-Business Suite Setup Guide.

h) Run AutoConfig on the database tier

i) Run EBS Technology Codelevel Checker (ETCC) on the database tier

On the database tier, run the EBS Technology Codelevel Checker (ETCC) described in My Oracle Support Knowledge Document 1594274.1, Oracle E-Business Suite Release 12.2: Consolidated List of Patches and Technology Bug Fixes to confirm that all required database patches have been applied.

EBS Technology Codelevel Checker (ETCC) is available via Patch 17537119 and analyzes an Oracle Database Oracle Home, and warns of any missing database bug fixes required for Oracle E-Business Suite Release 12.2. It is run with the command checkDBpatch.sh (on UNIX) or checkDBpatch.cmd (on Windows). Further instructions are available in the patch readme. Ensure to install the latest version of ETCC into <RDBMS_ORACLE_HOME>/appsutil/etcc directory.

j) Maintain snapshot information

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

15. What is high level steps of cloning

a) Prepare the Source System for database tier and application tier.

Log on to the Source System as the oracle user.

Source the database tier environment file.

Execute the following commands:

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

$ perl adpreclone.pl dbTier

Prepare the Source System application tier for cloning

Log on to the primary node of the Source System as the applmgr user.

Source the environment file of the Run Edition File system.

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

$ echo $FILE_EDITION

It should return the value:

run

Execute the following commands:

$ cd <INST_TOP>/admin/scripts

$ perl adpreclone.pl appsTier

b) Copy both database tier and application tier nodes from the Source System to Target System.

If you are using RMAN(hot Cloning), please use DB method to copy backup pieces.

For application file system copy only we need Source RUN file system (EBSapps folder to be copied)

You always clone and copy the Source Run Edition File System to create the Target Run Edition File 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 base directory.

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 System application tier node:

<APPL_TOP>

<COMMON_TOP>

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

c) Configure the Target System for both database tier and application tier.

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

The log file is created in <RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME> directory.

Note: If the database version is 12c Release 1, ensure to add the following line in your sqlnet_ifile.ora after adcfgclone.pl execution completes:

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8 (if the initialization parameter SEC_CASE_SENSITIVE_LOGON is set to FALSE)

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10 (if SEC_CASE_SENSITIVE_LOGON is set to TRUE)

On target System Copy create empty fs1,fs2 and fs_ne directory.

Make sure you have copied the source run file system for appropiate directory.

Example: If my source RUN file system was fs2 then copy the EBSapps folder from Source fs2 to Target fs2 only.

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

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier dualfs

At the prompt:

"Do you want to add a node (yes/no)", enter the value as 'no'.

At the prompt:

"Target System Base Directory", enter the location of the base directory. For example: /u02/r122.

Provide:

the new port pools for the Run Edition File System and the Patch Edition File System.

When asked the question:

"Do you want to startup the Application Services for <TWO_TASK>? (y/n)" you should answer 'y' if you do not need to perform any further actions and 'n' if there are other pending actions which need the Application services to be down.

Different logs are created for Run Edition and Patch Edition Cloning. The log files are created in the following directories in the Run Edition File System:

<INST_TOP>/admin/log/clone/run

<INST_TOP>/admin/log/clone/patch

16. What are some post clone tasks in EBS?

a) Copy the jar signing files from the source instance

Copy the adsign.txt and adkeystore.dat files from the <APPL_TOP_NE>/ad/admin directory of the source instance to the <APPL_TOP_NE>/ad/admin directory of the target instance.

b) Update profile options

Rapid Clone updates only site level profile options. You must manually update any other profile options set to instance specific values.

c) Update directory objects

Review and update the paths for the directory objects if they point to the source instance. For example, the directory objects APPS_DATA_FILE_DIR and FND_DIAG_DIR may need to be recreated to have paths specific to the target instance.

d) Update printer settings

If the new cloned system needs to utilize different printers, update the Target System with the new printer settings now.

e) Update Workflow configuration settings

Cloning an Oracle E-Business Suite instance does not update the host and instance-specific information used by Oracle Workflow.

Workflow Configuration Settings

Table Name Column Name Column Value Details

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 file directory.

FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the Target System.

f) Verify the APPLCSF variable setting

Source the APPS environment and confirm that the variable APPLCSF (identifying the top-level directory for concurrent 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.

g) Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS

If the Target System is in a different domain name from the Source System and SESSION_COOKIE_DOMAIN is not null in the Source System, update the value of SESSION_COOKIE_DOMAIN to reflect the new domain name.

h) Re-Implement SSL and SSO configuration

If the Source System is Secure Sockets Layer (SSL) or Oracle Access Manager-enabled, and you want the Target to be SSL or Oracle Access Manager-enabled, reconfigure the Target according to the SSL or Oracle Access 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 Access Manager setup.

17. 12.2 E-Business Suite Applications Manager Adpreclone Fails When Creating WLS Config Archive With 'START: Creating WLS config archive. ERROR: Script failed, exit code 255'

When attempting to run adpreclone in R12.2 we might see this error.

The issue is caused by some remaining active sessions in WLS (WebLogic Server)

Stop All services from patch and run

You can use EBSapps.env to ensure that you are on the correct file edition.

Restart the environment and run adpre-clone again.

18. Error while cloning the target saying as already registered.(Very Common Know issues which is majorly asked in interview)

When we are cloning an instance in EBS application regulary, we need to make sure that the tech home os deregistered from Ora Inventory.

If any of the above ORACLE_HOME entries are already registered in Oracle Inventory, execute the following command to de-register or detach that ORACLE_HOME:

$ ./runInstaller -detachhome ORACLE_HOME=<Oracle Home Location> [-invPtrLoc <s_invPtrLoc>]

Here,

-invPtrLoc argument needs to be specified only if the 'EBS installation central' inventory is being used.

s_invPtrLoc is the context variable that stores the inventory pointer 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

19. Can we pass Context file while running adcfgclone as we used to do in Previous Versions of EBS?

Yes! If we are regularly doing cloning ,we can preserve the Context file before clone and use it during confirguration.

Details Below

Configure the Target System database server as follows

$ 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

Execute the following SQL command to truncate all entries in the ADOP_VALID_NODES table.

SQL> truncate table ADOP_VALID_NODES;

Configure the Target System application tier node by logging in to the Target System

cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier <APPL_TOP Target context file> dualfs

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

This will clone and configure both the Run and Patch file systems of the application tier node.

20. How to do cloning on a Multi-Node Application System

a) Perform the standard prerequisite tasks.

b) Carry out these steps on all Source and Target nodes.

c) Perform a full clone (including the prepare, copy and configure steps) of the database tier node.

d) Clone the primary application tier node from the Source Run Edition File System to the Target Run Edition File System.

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

$ perl adpreclone.pl appsTier

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

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

<APPL_TOP>

<COMMON_TOP>

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

echo $RUN_BASE

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

Configure the Target Run and Patch Edition File Systems by running:

$ perl adcfgclone.pl appsTier dualfs

e) Adding a New Application Tier Node to an Existing System

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

21. How to add a secondary Node in the Application

Run adpreclone.pl on both the Run and Patch Edition File Systems in the primary application tier node of the E-Business Suite instance.

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

Copy the Run Edition File System to the Target secondary node.

Only the following directories should be copied:

<APPL_TOP>

<COMMON_TOP>

The secondary node must be on a different host.

If the primary node's Run Edition File System is in fs1, then the secondary node's Run Edition File System should also be in fs1. If the primary node's Run Edition File System is in fs2, then the secondary 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 tier nodes. This should be taken care of while copying the the Run and Patch Edition File Systems to the Target secondary node.

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

Note: Before executing these steps, ensure the AdminServer on both the Run Edition File System and the Patch Edition File System is running. This is required for adcfgclone.pl to properly register the new node on the Oracle E-Business Suite instance.

Running adcfgclone.pl in the interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier dualfs

When asked the questions:

"Do you want to add a node (yes/no)" you should answer 'yes'

"Do you want to startup the Application Services for <TWO_TASK>? (y/n)" you should answer 'y' if the Application services are to be started up. Otherwise, you should answer 'n'.

Running adcfgclone.pl in the non-interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl component=appsTier pairsfile=<PAIRSFILE> addnode=yes dualfs=yes

The sample pairsfile for application tier is delivered under INST_TOP of each file system in the location <INST_TOP>/appl/admin/<CONTEXT_NAME>.txt. It should be updated to have values corresponding to the node being added.

Note:

Ensure the following while setting values in the pairs file:

The value of 's_shared_file_system' should be set to 'false' and the value of 's_atName' should be set to the hostname of the node being added.

The port pool provided for the Run Edition File System is different from the port pool of the Patch Edition File System of the primary node. Otherwise, it will result in errors during execution of fs_clone. As mentioned earlier, the function (run or patch) of the two file systems is not static, and their values switch every time when a cutover phase is complete. Hence, refer to the environment variables $RUN_BASE and $PATCH_BASE to determine the Run Edition File System and Patch Edition File System respectively.

The value of 'patch_s_port_pool' for the port pool of the Patch Edition File System is provided correctly.

Different logs are created for Run Edition and Patch Edition node addition. The log files are created in the following directories in the Run Edition File System:

<INST_TOP>/admin/log/clone/run

<INST_TOP>/admin/log/clone/patch

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

Source the Run Edition File System.

The OHS configuration files mod_wl_ohs.conf and apps.conf will contain entries of managed servers from all application tier nodes. If any of these managed servers are not desired to be part of the cluster configuration on the current node, execute the following command to delete details of these managed servers from the OHS configuration 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>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:

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

For example, to delete references of managed servers oacore_server1 on 'testserver1' and forms_server2 on host 'testserver2' on the domain 'example.com' with ports 7201 and 7601 respectively, 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

Perform the following steps on the other application tier nodes participating in the same cluster where this node is added:

Source the Run Edition File System.

If any of the managed servers from the newly added node are desired to be part of the cluster configuration on the current node, execute the following command to add details of these managed servers into the OHS configuration files mod_wl_ohs.conf and apps.conf on the 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>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws accept a comma-separated list of managed server details in the following format:

host and domain are the hostname and domain name of the newly added node

port is the port of the new managed server whose reference is to 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 7605 respectively, 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=testserver1.example.com:7605

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

Source the Run Edition file system.

Run AutoConfig.

On Unix:

$ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

Reload the application tier TNS Listener (FNDFS listener) as follows:

$ lsnrctl reload APPS_<TWO_TASK>

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

Shut down the Admin Server and the Node Manager on the Patch Edition File System of the primary node as follows:

On UNIX:

$ <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop

$ <ADMIN_SCRIPTS_HOME>/adnodemgrctl.sh stop

Perform the following steps on all database tier nodes to add the newly added node to the Access Control List.

Source the database environment file.

Run AutoConfig as follows:

On UNIX:

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

22. How to delete secondary Node from Application Tier

Note: These steps are ONLY for deletion of secondary application tier nodes. The primary application tier node cannot 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 secondary application 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 some other node before starting with deletion of the node.

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

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

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

Note: Deletion of nodes may need to be performed in two scenarios - when the node is still accessible (users are able to login to the node) and in the remote case when the node is not accessible due to some issues ( the node may not be physically present and/or login to the node is not possible).

In the first scenario, all information related to the node has to be cleaned up altogether (including removal of references from the WebLogic domain and EBS topology as well as removal of the file system and inventory references). Case 1 describes the steps to be performed in this scenario.

In the second scenario, references to the node can be cleaned up only from the WebLogic domain and the EBS topology. The steps for deletion of secondary nodes in this scenario are described in Case 2 below. Please note that this option has been introduced in R12.TXK.C.DELTA.6 and is not available in the earlier releases.

In order to keep the E-Business Suite instance in a consistent state, steps should be followed strictly based on the scenario.

Case 1: If the secondary node to be deleted is accessible, execute the following steps:

Source the run file system.

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

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 the run file system WebLogic domain.

If the node is a non-shared node, verify and remove the following Oracle Home entries of both the Run and Patch file systems from the Oracle Inventory:

<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 the following command to de-register or detach that Oracle Home:

$ cd <Oracle Home>/oui/bin

$ ./runInstaller -detachhome ORACLE_HOME=<Oracle Home Location> [-invPtrLoc <s_invPtrLoc>]

Here,

-invPtrLoc argument needs to be specified only if the 'EBS installation central' inventory is being used.

s_invPtrLoc is the context variable that stores the inventory pointer 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 Inventory before trying to remove the Oracle Home <FMW_HOME>/oracle_common.

If the node is a non-shared node, verify and remove the following Oracle Home entry from the Oracle Inventory:

If the above Oracle Home entry is registered in Oracle Inventory, you can execute the following command to de-register the Oracle Home:

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

Here,

-invPtrLoc argument needs to be specified only if the 'EBS installation central' inventory is being used.

s_invPtrLoc is the context variable that stores the inventory pointer location.

For example:

$ cd /u02/r122/fs1/EBSapps/10.1.2/oui/bin

$ ./runInstaller -removeHome \

ORACLE_HOME=/u02/r122/fs1/EBSapps/10.1.2 -silent

Case 2: If the secondary node to be deleted is not accessible, execute the following steps to remove the node from the FND topology and the EBS domain:

Source the run file system.

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> -hostname=<HOSTNAME OF NODE TO BE DELETED> -logfile=<LOG_FILE>

This will delete all information corresponding to the specified node from the Weblogic domain like the managed servers, OHS instances and Node Manager of the specified node from both the run and patch file system WebLogic domain. In addition, it will also remove the node from the list of active nodes registered in the topology.

Note: Since the steps mentioned in Case 2 take care of only partial cleanup of the node, these steps should be performed only in case the node to be deleted is not accessible due to some issues. In all other scenarios, the nodes should be deleted by following steps mentioned in Case1. Otherwise, this may lead to the E-Business Suite instance being in an inconsistent state.

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

Perform the following steps on the other nodes:

Source the run file system.

If any of the managed servers from the deleted node are part of the cluster configuration defined on the current node, execute the following command to delete details of these managed servers from the OHS configuration 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>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:

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

For example, if the deleted node was on host 'testserver1' and domain 'example.com' and it contained managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the following command 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

Review and update the value of the context variable 's_shared_file_system' on the master node ( required only while deleting a shared file system node).

If the deleted node was the only node sharing the file system with a 'master' application tier node, execute the following steps on the 'master' node:

Set the value of the context variable 's_shared_file_system' in the run context file of the master node to 'false' via the Oracle Applications Manager.

Source the run file system.

Run AutoConfig as follows:

On Unix:

$ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

Run AutoConfig on the database tier.

Log into the database tier node.

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

For UNIX:

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

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

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>

Notes:

Execution of ebs-delete-node option as mentioned above will not delete the contents of the file system. This has to be done manually by the customer once the above steps to delete the node are 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 Patch Edition File System should be deleted.

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

23. Error unable to find appltop_id for the host

If the application tier of the target instance is on the same host (say 'testserver1') as the application tier of the source instance, the following error may be reported while running adop.

[UNEXPECTED]Unable to find appltop_id for the host testserver1 from database

[UNEXPECTED]Invalid appltop id:

If this issue is encountered, verify the AD_APPL_TOPS table to ensure that the entry for application tier node is correct. The AD_APPL_TOPS table contains the column NAME and APPLICATIONS_SYSTEM_NAME for each non-shared Application node. The value of NAME is derived from the value of the context variable 's_atName' while the APPLICATIONS_SYSTEM_NAME is the value of the context variable 's_dbSid'.

If the entry for the application tier of the target instance is not correct, delete the entry for node by executing the following SQL commands:

SQL> delete from ad_appl_tops where name='<s_atName>';

SQL> commit;

Thereafter, run AutoConfig on the Run edition file system of the application tier node as follows:

On UNIX:

$> sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

24. Error Port conflicts reported by T2P domain clone during cloning of multinode source instance

When the source is a multi-node Oracle E-Business instance, Rapid Clone may fail on the primary node of the target Oracle E-Business instance due to port conflicts reported during domain cloning.

In that case, you should check if the port conficts are being reported for the managed servers which were part of the secondary node(s) of the source Oracle E-Business instance. If so, the environment variable T2P_JAVA_OPTIONS should be set with the -Dt2p.temporary.port.range parameter as follows before running adcfgclone.

$ T2P_JAVA_OPTIONS="-Dt2p.temporary.port.range=5001-5050"

$ export T2P_JAVA_OPTIONS

This has to be done temporarily only

25. Error EBS R12.2: FS_CLONE Failing With ERROR: Update Moveplan Fail

When attempting to run fs_clone after a successful clone the following error might occur.

FSCloneApplyAppsTier_08081620.log shows

+++++++++++++++++++++++++

configProperty id = Machine2

Count for NodeIterator nextNode = 3

ERROR: Machine configurations are not in sync between file system context and DB context

ERROR: Update Moveplan Fail

After performing RapidClone, Domain Structure appears to have a old/invalid machine host information from the source system that conflicted with what was set in the context file and moveplan.xml.

1. Log on to the WebLogic Server Administration Console.

2. In the left panel for 'Domain Structure', click on the Environments->'Machines' link.

Examine the page that gives a summary of all machines. Look to see if there are any invalid/old hosts.

3. Click on the Lock & Edit Button in the 'Change Center' panel.

4. Select the machine name that is not correct and delete it.

5. Click the 'Save' button to save the configuration changes.

6. Click on the 'Activate Changes' button in the 'Change Center' panel to activate the changes.

7. Retry adop phase=fs_clone force=yes."

26. Please refer below for some Post on Cloning Practical Step by Step Scenarios

Cloning EBS R12.2.5 Environment Step by Step

Clone an EBS R12.1.3 application along with Database 12.1.0.2 using adcfgclone.pl

Cloning an EBS instance R12.2.10 from OEL 6.10 to OEL 7.9 using adcfgclone and RMAN