Section 1: 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. For the latest installation guidelines refer to My Oracle Support Knowledge Document 405565.1.
2. Verify source and target system software components and versions
In addition to the Oracle Applications software requirements (see Oracle Applications Installation Guide: Using Rapid Install), the following software component versions must exist on the source or target nodes as applicable. The 'Location' column indicates the node where the software component must reside.
3. Apply the latest AD patch
Refer to My Oracle Support to obtain the latest AD patch. At the time of writing this note, the following patches were available:
For Release 12.0:
Apply patches as listed in Table 2.a.
Table 2.a: Release 12.0 AD patches
Patch Description
6510214
R12.AD.A.DELTA.4
For Release 12.1:
Apply patches as listed in Table 2.b.
Table 2.b: Release 12.1 AD patches
Patch Description
9239089
R12.AD.B.DELTA.3
4. 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. Refer to My Oracle Support Knowledge Document 387859.1 for details of the latest AutoConfig Template rollup patch.
5. 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.
o For Release 12.0:
Apply patches as listed in Table 3.a.
Table 3.a: Release 12.0 Rapid Clone patches
Patch Description
5484000
Oracle E-Business Suite 12.0.2 Release Update Pack (RUP2) or higher
9171651:R12.OAM.A
12.0 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
9833058:R12.OAM.A
HOT CLONE FAILS WITH ORA-00201 DURING RECOVERY MANAGER
o For Release 12.1:
Apply patches as listed in Table 3.b.
Table 3.b: Release 12.1 Rapid Clone patches
Patch Description
9171651:R12.OAM.B
12.1 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
9833058:R12.OAM.B
HOT CLONE FAILS WITH ORA-00201 DURING RECOVERY MANAGER
o Other Patches (All releases):
Apply patches as listed in Table 3.c.
Table 3.c: Other Patches
Patch Description
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.
6. Note: If new Rapid Clone or AutoConfig updates are applied to the system, steps 6, 7, and 8 below must be executed again in order to apply the new files to the database node.
7. Run AutoConfig on the application tiers
Follow the steps under section " Run AutoConfig on the Application Tiers " in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on all application tier nodes.
8. Synchronize appsutil on the database tier nodes
Follow the steps under section "Copy AutoConfig to the RDBMS ORACLE_HOME" in My Oracle Support Knowledge Document 387859.1 to copy AutoConfig and Rapid Clone files to each database node via the admkappsutil.pl utility.
9. Run AutoConfig on the database tier
Follow the steps under section "Run AutoConfig on the Database Tier" in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on the database tier nodes.
10. Maintain snapshot information
Log in to each application tier node as the APPLMGR user, and run "Maintain Snapshot information" in AD Administration. Refer to Oracle Applications Maintenance Utilities for more information (this is the Release 12.1 version; versions for earlier releases are also available from the Oracle E-Business Suite Online Documentation Library).
Section 2: Cloning Tasks
Use Rapid Clone to create template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings.
Note: Rapid Clone never changes the source system configuration.
The cloning process consists of three phases, each of which is made up of several logical sections and their steps.
1. Prepare the source system
Execute the following commands to prepare the source system for cloning:
a. 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
b. 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
Note: If new Rapid Clone or AutoConfig updates are applied to the system, adpreclone.pl must be executed again on the dbTier and on the appsTier in order to apply the new files into the clone directory structures that will be used during the cloning configuration stage.
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.
Note: In the copying tasks below, UNIX/Linux users should ensure that the symbolic links (soft links) are preserved when copying. On most UNIX platforms, this can be accomplished 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, the tar command can be used to compress the directories into a temporary staging area. If you use this command, you may require the -h option to follow symbolic links, as following symbolic links is not the default behavior on all platforms. Consult the UNIX man page for the tar command.
Additionally, verify the permissions of the executables under ORACLE_HOME/bin that can potentially be owned by root (i.e. nmo, nmhs, nmb, etc).
a. 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]
b. 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
3. 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.
a. 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
b. 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
Section 3: 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 in Table 4 to check for any instance-specific data in the Workflow configuration on the target system.
Table 4: 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
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. For the latest installation guidelines refer to My Oracle Support Knowledge Document 405565.1.
2. Verify source and target system software components and versions
In addition to the Oracle Applications software requirements (see Oracle Applications Installation Guide: Using Rapid Install), the following software component versions must exist on the source or target nodes as applicable. The 'Location' column indicates the node where the software component must reside.
3. Apply the latest AD patch
Refer to My Oracle Support to obtain the latest AD patch. At the time of writing this note, the following patches were available:
For Release 12.0:
Apply patches as listed in Table 2.a.
Table 2.a: Release 12.0 AD patches
Patch Description
6510214
R12.AD.A.DELTA.4
For Release 12.1:
Apply patches as listed in Table 2.b.
Table 2.b: Release 12.1 AD patches
Patch Description
9239089
R12.AD.B.DELTA.3
4. 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. Refer to My Oracle Support Knowledge Document 387859.1 for details of the latest AutoConfig Template rollup patch.
5. 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.
o For Release 12.0:
Apply patches as listed in Table 3.a.
Table 3.a: Release 12.0 Rapid Clone patches
Patch Description
5484000
Oracle E-Business Suite 12.0.2 Release Update Pack (RUP2) or higher
9171651:R12.OAM.A
12.0 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
9833058:R12.OAM.A
HOT CLONE FAILS WITH ORA-00201 DURING RECOVERY MANAGER
o For Release 12.1:
Apply patches as listed in Table 3.b.
Table 3.b: Release 12.1 Rapid Clone patches
Patch Description
9171651:R12.OAM.B
12.1 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
9833058:R12.OAM.B
HOT CLONE FAILS WITH ORA-00201 DURING RECOVERY MANAGER
o Other Patches (All releases):
Apply patches as listed in Table 3.c.
Table 3.c: Other Patches
Patch Description
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.
6. Note: If new Rapid Clone or AutoConfig updates are applied to the system, steps 6, 7, and 8 below must be executed again in order to apply the new files to the database node.
7. Run AutoConfig on the application tiers
Follow the steps under section " Run AutoConfig on the Application Tiers " in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on all application tier nodes.
8. Synchronize appsutil on the database tier nodes
Follow the steps under section "Copy AutoConfig to the RDBMS ORACLE_HOME" in My Oracle Support Knowledge Document 387859.1 to copy AutoConfig and Rapid Clone files to each database node via the admkappsutil.pl utility.
9. Run AutoConfig on the database tier
Follow the steps under section "Run AutoConfig on the Database Tier" in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on the database tier nodes.
10. Maintain snapshot information
Log in to each application tier node as the APPLMGR user, and run "Maintain Snapshot information" in AD Administration. Refer to Oracle Applications Maintenance Utilities for more information (this is the Release 12.1 version; versions for earlier releases are also available from the Oracle E-Business Suite Online Documentation Library).
Section 2: Cloning Tasks
Use Rapid Clone to create template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings.
Note: Rapid Clone never changes the source system configuration.
The cloning process consists of three phases, each of which is made up of several logical sections and their steps.
1. Prepare the source system
Execute the following commands to prepare the source system for cloning:
a. 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
b. 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
Note: If new Rapid Clone or AutoConfig updates are applied to the system, adpreclone.pl must be executed again on the dbTier and on the appsTier in order to apply the new files into the clone directory structures that will be used during the cloning configuration stage.
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.
Note: In the copying tasks below, UNIX/Linux users should ensure that the symbolic links (soft links) are preserved when copying. On most UNIX platforms, this can be accomplished 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, the tar command can be used to compress the directories into a temporary staging area. If you use this command, you may require the -h option to follow symbolic links, as following symbolic links is not the default behavior on all platforms. Consult the UNIX man page for the tar command.
Additionally, verify the permissions of the executables under ORACLE_HOME/bin that can potentially be owned by root (i.e. nmo, nmhs, nmb, etc).
a. 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]
b. 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
3. 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.
a. 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
b. 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
Section 3: 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 in Table 4 to check for any instance-specific data in the Workflow configuration on the target system.
Table 4: 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
Comments
Post a Comment