Cloning Oracle Applications Release 12 with Rapid Clone

Prerequisite Tasks

Before cloning, prepare the source system by applying any required patches and running AutoConfig.

1. Verify OS requirements on target system
   Before cloning to a new server, ensure the target system meets all the requirements for Oracle Applications Release 12 stated on the Oracle Applications Release Notes, and on the Oracle Applications Installation and Upgrade Notes for each Platform.
2. Apply the latest AD patch
   Apply patch 6510214 (R12.AD.A.DELTA.4) or higher.
3. Apply the latest AutoConfig template patch
   Update the Oracle Applications file system with the latest AutoConfig template files by applying the TXK AutoConfig Template rollup patch to all application tier server nodes.
4. Apply the latest Rapid Clone patches
   Update the Oracle Applications file system with the latest Rapid Clone files by applying the following patches to all Applications nodes. For Release 12.0: 5484000 Oracle E-Business Suite 12.0.2 Release Update Pack (RUP2) or higher and 9171651:R12.OAM.A - 12.0 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
   For Release 12.1: 9171651:R12.OAM.B -12.1 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
   Other Patches (All releases): 8246709 - Required for Microsoft Windows if using OracleAS 10.1.3.4. This patch must be re-applied to the OracleAS 10.1.3.4 ORACLE_HOME before every cloning operation.
5. Run AutoConfig on the application tiers
6. Synchronize appsutil on the database tier nodes
7. Run AutoConfig on the database tier
8. Maintain snapshot information

Log in to each application tier node as the APPLMGR user, and run "Maintain Snapshot information" in AD Administration.  

Cloning Tasks

1. Prepare the source system
   Execute the following commands to prepare the source system for cloning:
1. Prepare the source system database tier for cloning
   Log on to the source system as the ORACLE user, and run the following commands:

$ cd [RDBMS ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME]
$ perl adpreclone.pl dbTier

2. Prepare the source system application tier for cloning
   Log on to the source system as the APPLMGR user, and run the following commands on each node that contains an APPL_TOP:

$ cd [INST_TOP]/admin/scripts
$ perl adpreclone.pl appsTier

2. Copy the source system to the target system
   Copy the application tier file system from the source Applications system to the target node by executing the following steps in the order listed. Ensure the application tier files copied to the target system are owned by the target APPLMGR user, and that the database node files are owned by the target ORACLE user.For example: cd /target_dest_dir/db cp -RH /source_dir/db/*. Alternatively, the tar command can be used to compress the directories into a temporary staging area. 

1. Copy the application tier file system
   Log on to the source system application tier nodes as the APPLMGR user and shut down the application tier server processes. Copy the following application tier directories from the source node to the target application tier node:
• [APPL_TOP]
• [COMMON_TOP]
• Applications Technology Stack:
• [OracleAS Tools ORACLE_HOME]
• [OracleAS Web IAS_ORACLE_HOME]
2. Copy the database node file system
   Log on to the source system database node as the ORACLE user, and then:

1.     Perform a normal shutdown of the source system database

2.     Copy the database (.dbf) files from the source system to the target system

3.     Copy the source database ORACLE_HOME to the target system

4.     Start the source Applications system database and application tier processes

Configure the target system

Run the following commands to configure the target system. You will be prompted for specific target system values such as SID, paths, and ports.

Configure the target system database server
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

Configure the target system application tier server nodes
Log on to the target system as the APPLMGR user and enter the following commands:

$ cd [COMMON_TOP]/clone/bin
$ perl adcfgclone.pl appsTier

Finishing Tasks

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

1. Update profile options
   Rapid Clone updates only site level profile options. If any other profile options are set to instance specific values, you must update them manually.
2. Update printer settings
   If the new cloned system needs to utilize different printers, update the target system with the new printer settings now.
3. Update Workflow configuration settings
   Cloning an Oracle Applications instance will not update the host and instance-specific information used by Oracle Workflow. Review the tables and columns listed below to check for any instance-specific data in the Workflow configuration on the target system.

Workflow configuration settings

Table Name	Column Name	Column Value Details
WF_NOTIFICATION_ATTRIBUTES	TEXT_VALUE	Value starts with http://[old web host]: Update to new web host.
WF_ITEM_ATTRIBUTE_VALUES	TEXT_VALUE	Value starts with "http://[old web host]: Update to new web host.
WF_SYSTEMS	GUID	Using the Workflow Administrator Web Applications responsibility, create a new system defined 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 global name.
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 logfile directory.
FND_CONCURRENT_REQUESTS	OUTFILE_NAME	Update with the new directory path on the target system.

4. Verify the APPLCSF variable setting
   Source the APPS environment and review that the variable APPLCSF (identifying the top-level directory for concurrent manager log and output files) points to a suitable directory. To modify it, 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_PARAMETERS
   If the target system is in a different domain name than the source system and SESSION_COOKIE_DOMAIN was not null in the source system, update that value to reflect the new domain name.
6. Re-Implement SSL and SSO configuration
   If the Source System was SSL or SSO enabled, reconfigure the Target by following the SSL/SSO documentation.

Advanced Cloning Options

Refreshing a Target System

You may need to refresh the target system periodically to synchronize it with changes to the source system.

1. Prepare the source system.
2. Copy the source system to the target system.
• If the application tier file system if the APPL_TOP, COMMON_TOP, or technology stack needs to be refreshed, copy the portion of the application tier file system that has been updated
• If the RDBMS ORACLE_HOME or the database needs to be refreshed, copy the database node file system. If refreshing the database, the ORACLE_HOME should be refreshed at the same time.
3. Configure the target system.
   Specify the existing target system context file when running adcfgclone.pl commands.
1. Configure the target system database server by logging on to the target system as the ORACLE user and entering 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 on to the target system as the APPLMGR 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

4. Perform the standard finishing tasks mentioned above.

Cloning a Multi-Node System

This procedure allows the source system or target system to be a multi-node system. As of Release 12, all APPL_TOPs are unified APPL_TOPs. This means that all files required for all application tier services are installed on every application tier node. Thus, only one copy of the applications tier node files needs to be copied to the target system, regardless of whether a shared file system is being used on the source or target system. Multiple application tier nodes are distinguished from each other by the services running.

1. Perform the standard prerequisite tasks.
   Carry out these steps on all source and target nodes.
2. Carry out the cloning tasks mentioned above
   Prepare, copy and configure the cloned Applications system. When creating more than one application tier node on the target system, follow these steps:
• Perform a full clone (Prepare, copy and configure steps) of the database node and primary application tier node.
• To add shared application tier nodes on the target system, follow the instructions in My Oracle Support Knowledge Document 384248.1, Section 4: Adding a node to a Shared Application Tier File System.
• To add non-shared application tier nodes, execute the copy and configure steps as on the primary node.
• Specify the services to start on each target Applications tier node when responding to the prompts during the configuration step.
3. Perform the required finishing tasks mentioned above.

Adding a New 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 scale up or scale out. The new node can run the same services as the source node, or different services. Follow the instructions in the Application tier part of Cloning Tasks.

1. Prepare the source system, copy it to the new node and configure it.
2. After adcfgclone.pl completes, source the Applications environment and run the following commands on the target system:

$ cd [COMMON_TOP]/clone/bin
$ perl adaddnode.pl

Note: After adding new nodes, do the set up for load balancing.

Cloning the Database Separately

Some situations require the database to be recreated separately, without using Rapid Clone. Typical scenarios are when system downtime is not feasible, or advanced database replication tools like RMAN are being used to copy the database in hot backup mode.

1. Log on to the target system as the ORACLE user
2. Configure the [RDBMS 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, Flash Copy, Snap View, or Mirror View.
4. Start the target database in open mode
5. 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.

6. 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.

Cheers!!!

Related Posts by Categories