This Document describes the process of cloning an Oracle Applications Release 12 system. The most up-to-date version of this document can be obtained in OracleMetaLink Document 406982.1.
Cloning is the process used to create a copy of an existing Oracle Applications system. There are various rationales for cloning an Oracle Applications system, including:
* Standard cloning - Making a copy of an existing Oracle Applications system, for example a copy of a production system to test updates.
* System scale-up - Adding new machines to a system to provide the capacity for processing an increased workload.
* System transformations - Altering system data or file systems, including actions such as platform migration, data scrambling, and provisioning of high availability architectures.
* Patching and upgrading - Delivering new versions of Applications components, and providing a mechanism for creating rolling environments to minimize downtime.
An important principle in Applications 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 the topology, as a cloned system must be able to provide the same output to the end user as the source system. Additionally, while a cloned system need not have the full topology of its source, it must have available to it all the topology components that are available to the source.
* Section 1: Prerequisites
Tasks to perform before using Rapid Clone
* Section 2: Clone Oracle Applications Release 12
Tasks to prepare, copy, configure, and verify a cloned Applications system
* Section 3: Finishing Tasks
Tasks to complete the cloning process
* Section 4: Advanced Cloning Methods
Tasks for advanced options such as refreshing and multi-node cloning
Conventions
Convention Meaning
Source system Applications system being cloned.
Target system Applications system being created as a copy of the source.
APPLMGR User that owns the applications file system (APPL_TOP and application tier technology stack).
ORACLE User that owns the database file system (RDBMS ORACLE_HOME and database files).
CONTEXT_NAME The CONTEXT_NAME variable refers to the name of the Applications context file. CONTEXT_NAME will be typically set to
Monospace Text Represents command line text. Type this command exactly as shown.
< > Text enclosed in angle brackets represents a variable. Substitute a value for the variable text. Do not type the angle brackets.
Section 1: Prerequisites
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 OracleMetaLink Document 405565.1.
2. Verify source and target nodes software versions
In addition to the Oracle Applications software requirements (see Oracle Applications Installation Guide: Using Rapid Install, Release 12), the following software component versions must exist on the source and/or target nodes. The location column indicates the node where the software component must be present.
Software Minimum Version Location Details
Zip 2.3 All source nodes Download from InfoZip. Zip must be in your PATH for cloning.
Unzip 5.52 All source nodes Download from InfoZip. Unzip must be in your PATH for cloning.
OS utilities N/A All target nodes OS utilities (see Release 12 Install Guide) must be in the the PATH when running adcfgclone.pl (UNIX: make, ld, ar).
Perl 5.x All target nodes Use the Perl shipped with AS 10.1.3 and RDBMS 10G if available or download it from Perl.com..
Perl must be in the PATH and PERL5LIB must be correctly set before cloning.
3. Apply the latest AD patch
Apply patch 6510214 (R12.AD.A.DELTA.4) or higher. Refer to OracleMetaLink to obtain the latest AD patch available.
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 Document 387859.1 in OracleMetaLink 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:
* 5484000 : Oracle E-Business Suite 12.0.2 Release Update Pack (RUP2)
* 6776948 : R12 RAPIDCLONE CONSOLIDATED FIXES JUL/2008
Warning: 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 into the Database Node.
6. Run AutoConfig on the Application Tiers
Follow the steps under section " Run AutoConfig on the Application Tiers " in OracleMetaLink Document 387859.1 to Run AutoConfig on all application tier nodes.
7. Synchronize appsutil on the Database Tier Nodes
Follow the steps under section "Copy AutoConfig to the RDBMS ORACLE_HOME" in OracleMetaLink Document 387859.1 to copy AutoConfig and Rapid Clone files to each database node via the admkappsutil.pl utility.
8. Run AutoConfig on the Database Tier
Follow the steps under section "Run AutoConfig on the Database Tier" in OracleMetaLink Document 387859.1 to Run AutoConfig on the database tier nodes.
9. Maintain Snapshot information
Log in to each Applications Node as the APPLMGR user, and run "Maintain Snapshot information" in AD Administration.
See Oracle Applications Maintenance Utilities for more information.
Section 2: Clone Oracle Applications Release 12
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.
There are three phases to the cloning process:
1. Prepare the Source System
Execute the following commands to prepare the source system for cloning.
1. Prepare the source system database node for cloning
Log on to the source system as the ORACLE user. and run the following commands:
cd
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
perl adpreclone.pl appsTier
Warning: 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.
1. Copy the application tier file system
Log on to the source system application tier nodes as the APPLMGR user.
* Shut down the application tier server processes
* Copy the following application tier directories from the source node to the target application tier node:
o
o
o Tech Stack
+
+
2. Copy the database node file system
Log on to the source system database node as the ORACLE user, and then:
* Perform a normal shutdown of the source system database
* Copy the database (DBF) files from the source to the target system
* Copy the source database ORACLE_HOME to the target system
* Start the source Applications system database and application tier processes
Note: UNIX/Linux users should ensure that the symbolic links (soft links) are preserved when copying.
On most UNIX platforms, this can be accomplished with cp -RH command.
Please check the Unix man pages for the exact parameters for the cp command 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 are using this command, take into consideration that you may have to use the -h option to follow symbolic links as on some platforms, following symbolic links is not the default behavior.
3. Configure the Target System
Execute the following commands to configure the target system.
You will be prompted for the target system specific values (SID, paths, ports, etc.)
1. Configure the target system database server
Log on to the target system as the ORACLE user and enter the following commands to configure and start the database:
cd
perl adcfgclone.pl dbTier
2. Configure the target system application tier server nodes
Log on to the target system as the APPLMGR user and type the following commands:
cd
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 following tables and columns to verify there is no instance specific data in the Workflow configuration on the target system.
Table Name Column Name Column Value Details
WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http://
WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with "http://
WF_SYSTEMS GUID Create a new system defined as the new global database name using the Workflow Administrator Web Applications responsibility.
WF_SYSTEMS NAME Value needs to be replaced 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 PLSQL 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.
Section 4: Advanced Cloning Options
This section describes advanced cloning procedures.
1. Refreshing a target system
You may need to refresh the target system periodically to synchronize it with changes from the source.
Warning: Backup the target context file on the target system before refreshing the dbTier or appsTier.
To refresh the target system, perform the following steps as described in previous sections:
1. Prepare the Source System
2. Copy the Source System to the Target System
* Copy the application tier file system if the APPL_TOP, COMMON_TOP, or tech stack needs to be refreshed. Copy the portion of the application tier file system that has been updated.
* Copy the database node file system if the RDBMS ORACLE_HOME or the database needs to be refreshed. 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:
* perl adcfgclone.pl dbTier
where Database target context file is:
* perl adcfgclone.pl appsTier
where Appltop target context file is:
4. Finishing Tasks
2. Cloning multi-node systems
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 middle tier services are included with every Applications node. Thus, only one copy of the Applications 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 Applications nodes can be differentiated by the services started on each node.
1. Perform prerequisites
Perform these steps on all source and target nodes.
2. Clone Oracle Applications Release 12
Prepare, copy and configure the cloned Applications System. When creating more than one Applications node on the target system:
* Clone Oracle Applications Release 12
Perform a full clone (Prepare, copy and configure steps) of the database node and primary Applications node.
* To add shared Applications nodes on the target system, follow the instructions in Section 4: Adding a node to a Shared Application Tier file system in document 384248.1 in OracleMetalink.
* To add non-shared Applications nodes, execute the copy and configure steps as on the primary node.
* You can specify the services to start for each target Applications node while answering the prompts during the configuration step.
3. Finishing Tasks
3. 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 Clone Oracle Applications Release 12.
* Prepare the source system, copy it to the new node and configure it.
* After adcfgclone.pl completes, source the Applications environment and run the following commands on the target system:
o cd
o perl adaddnode.pl
Note: After adding new nodes, refer to Document 380489.1 in OracleMetaLink for details on how to set up Load Balancing.
Note: If the SQL*Net Access security is enabled in the existing system, you first need to authorize the new node to access the database through SQL*Net. See the Oracle Applications Manager on line Help for instructions on how to accomplish this.
4. Cloning an Oracle RAC system
For complete instructions on how to Clone RAC Enabled Systems with Rapid Clone, please refer to document 559518.1 in OracleMetaLink.
5. Adding a Node to an existing Oracle RAC Cluster
On Release 12, Rapid Clone is no longer used to migrate a dbTier to RAC. Please refer to document 388577.1 in OracleMetaLink for details on how to perform this task.
* Adding a RAC Node on an existing RAC System (Source), is being tracked by TXK Bug 7276544.
* Adding a RAC Node within the context of Cloning (Target ONLY), is being tracked by Bug 7275583.
Appendix A: Recreating database control files manually in Rapid Clone
This Appendix documents the steps to allow manual creation of the target database control files within the Rapid Clone process. This method is needed for databases on raw partitions, or cloning of a hot backup. Replace section 2.3a (Configure the target system database server) with the following steps:
* Log on to the target system as the ORACLE user
* Configure the
o cd
o perl adcfgclone.pl dbTechStack
* Create the target database control files manually
* Start the target system database in open mode
* Run the library update script against the database
o cd
o sqlplus "/ as sysdba" @adupdlib.sql
where
* Configure the target database (the database must be open)
o cd
o perl adcfgclone.pl dbconfig
where Database target context file is:
No comments:
Post a Comment