Cloning is the act of creating an identical copy of an existing Oracle E-Business Suite system. The system to be cloned is referred to as the source system, and the newly created system is referred to as the target system.
Cloning has various uses, such as:
Creating a copy of a production system for patch testing
Creating a staging area to reduce the downtime required for patching
Refreshing a test system from a production system
Moving an existing system to a different machine or platform
Simply copying the existing components to a new location will not provide a working Oracle E-Business Suite installation. For example, there are numerous configuration files in the file system that must be modified, depending on the physical configuration of the target environment. In addition, the Oracle E-Business Suite installation process utilizes the Oracle Universal Installer, which maintains key information about the installation. Copying the installation to a new location would invalidate this information, preventing the application of patches to components maintained by the Installer.
Cloning an Oracle E-Business Suite Release 12 system can be accomplished by running the Rapid Clone tool. This tool can be employed with Oracle E-Business Suite Release 12, or any AutoConfig-enabled earlier releases.
Alternatively, you can license Oracle Application Management Pack for Oracle E-Business Suite, which extends Enterprise Manager 10g Grid Control to help monitor and manage an Oracle E-Business Suite system. The pack integrates Oracle Applications Manager with Grid Control to provide a consolidated E-Business Suite management solution.
Note: See Chapter 7 for further details of cloning features and options.
When cloning from one machine to another, the simplest case is where the two machines are running the same version of the same operating system.
A slightly more complex case occurs where the two operating systems are binary compatible, and the source system is running an earlier version of the same operating system that is being used on the target system. While Rapid Clone can often be used successfully in such cases, you should generally aim to clone between machines that are running identical versions of an operating system. This minimizes the risk of problems arising because of differences between the versions.
Warning: It is not supported to clone from a later version of an operating system to an earlier one.
The following list summarizes the cloning options currently available with Rapid Clone.
Note: In this context, node refers to a logical collection of Oracle E-Business Suite processes, and not necessarily a physical machine.
Single node to Single node
Recloning (of database only)1
Clone existing Clone2
Multi-node to Multi-node
Single node to Multi-node3
Multi-node to Single node 4
Footnotes on List
Recloning of the database only can be useful if the source system has changed, and the target system needs to be updated with these changes. However, if any Oracle E-Business Suite patches have been applied to the source system, the rest of the components (APPL_TOP, COMMON_TOP and ORACLE_HOMEs) must also be cloned, in order to keep the file system and database synchronized.
A cloned system created with Rapid Clone can be used as the source system for another round of cloning.
If moving to a multi-node system, it is preferable to implement a shared APPL_TOP rather than clone from a single node to multiple nodes. See Chapter 9 for details.
This procedure is often referred to as merging APPL_TOPs.
Note: For further details of cloning options and strategies, see My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone.
Rapid Clone does not modify the source system. The adpreclone.pl script prepares the source system to be cloned by collecting information about the database, and creating generic templates from existing files that contain source-specific hard-coded values. The template files are located in <RDBMS_ORACLE_HOME>/appsutil/template on the database tier.
Important: Rapid Clone requires all the expected binary files to be in place on the source system, and may fail to operate correctly if any are missing.
After running adpreclone.pl, you copy the relevant files and directories from the source system files to the target system, and then run the adcfgclone.pl configuration script. The values for various parameters are required to create the context file that will be used to configure the target system. A few of these values are calculated from the current target system, and adcfgclone.pl will prompt for the others.
For example, you will be prompted to specify a port pool, to use a particular range of predefined server ports. There are 100 port pools, so if, for example, you select pool port 3, the default database port number (1521) is replaced by 1524.
Note: If you are cloning to the same machine, you must specify a different port pool from the source system.
If desired, it is possible to set a specific port to a value other than the one assigned from the port pool. This requires editing the context file on the target system after adcfgclone.pl completes, then running AutoConfig to update the system with the new value.
The Oracle Universal Installer's global inventory is simply a list of pointers to each local inventory location. There is one local inventory per ORACLE_HOME, located in <ORACLE_HOME>/inventory, which contains all the patch information for the ORACLE_HOME in question.
Rapid Clone first ensures that the source system local inventory is in XML format, converting it from the older binary format if necessary. The local inventory (inside the ORACLE_HOME to be cloned) is then copied to the target system and reconfigured with the new values for the target system. Rapid Clone subsequently attaches the reconfigured local inventory to the target system global inventory. If the target system does not have a global inventory, a new global inventory is created when Rapid Clone goes to attach the local inventory.
Several features are designed to make cloning more straightforward, and give greater flexibility in response to issues such as:
Whether cloning is being used to add a node to an existing installation, or to create an entirely new installation. In the former case, there will be fewer ancillary changes.
Types of table modification that need to take place. For example, when using Rapid Clone to add a node, a new row is inserted into FND_NODES, whereas when creating a new installation, FND_NODES is purged and a completely new set of rows inserted.
Whether services should be set to start automatically after cloning is complete.
Whether any data alteration is needed after cloning.
In essence, Rapid Clone does the following on the target system.
Database tier:
Creates the Database context file
Registers the ORACLE_HOME in the Global Inventory
Relinks the ORACLE_HOME
Configures the ORACLE_HOME
Recreates the database control files
Starts the database
Configures the database
Starts the database listener
Application tier:
Creates the Applications context file
Registers the OracleAS 10.1.2 and OracleAS 10.1.3 ORACLE_HOMEs in the Global Inventory
Relinks the OracleAS ORACLE_HOMEs
Configures the OracleAS ORACLE_HOMEs
Configures the APPL_TOP
Creates the INST_TOP
Starts application tier server processes
In addition, there are a number of associated actions relating to the database.
Note: For further details of Rapid Clone capabilities and operation, see My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone. For details of cloning options in general , see My Oracle Support Knowledge Document 783188.1, Certified RAC Scenarios for E-Business Suite Cloning.