Frequently Asked Questions
Cloning Oracle Applications
Cloning Oracle Applications Release 11i was originally published in conjunction with Release 11.5.5 and is applicable for all 11i releases up to 11.5.5 that are not AutoConfig enabled. Cloning Oracle Applications Release 11i with Rapid Clone is applicable for all 11i systems that have migrated to AutoConfig and enabled Rapid Clone. This method contains steps to install AutoConfig and Rapid Clone.
Rapid Clone is the new cloning utility introduced in Release 11.5.8. Rapid Clone leverages the new installation and configuration technology utilized by Rapid Install. See Oracle MetaLink Note230672.1 (Cloning Oracle Applications 11i with Rapid Clone) for instructions on installing and enabling Rapid Clone.
First, verify that your system is AutoConfig enabled. Then, verify that you have applied the latest Rapid Clone patch documented in OracleMetaLink Note230672.1 (Cloning Oracle Applications 11i with Rapid Clone). See Searching the Patch History Database in the AD Procedures Guide for instructions on searching for patches applied to your system.
AutoConfig is a configuration tool that supports automated configuration of an Oracle Applications Instance. All of the information required for configuring an Applications instance is collected into a central repository, called the Applications Context. When the AutoConfig tool runs, it uses information from the Applications Context file to generate configuration files and update database profiles. See OracleMetaLink Note165195.1 for details on installing and migrating to AutoConfig.
Open the environment file APPSORA.env in your APPL_TOP. If the top of the file says that it is maintained by Auto Config, then your system is probably using AutoConfig. Check if there is an Applications Context file in the APPL _TOP /admin directory. This file will typically be named <SID>.xml or <SID>_<HOSTNAME>.xml. Check if there is an Applications Context file in the RDBMS ORACLE_HOME under the appsutil directory. This file will typically be named <SID>.xml or <SID>_<HOSTNAME>.xml.
Due to the advancements in the cloning solution with Rapid Clone, all customers are now recommended to move to using Rapid Clone. if you are on release 11.5.7 or any release before 11.5.7, you will need to first enable AutoConfig on your system, if not already done, before you can use Rapid Clone as documented in theCloning Oracle Applications
In 11.5.8 AutoConfig is enabled on the middle tier out of the box. In 11.5.9 and any later release, AutoConfig is enabled by default on both the database tier and the middle tier. Update AutoConfig and Rapid Clone code to the latest code line and use Rapid Clone to clone your system. Full instructions are in Cloning Oracle Applications Release 11i with Rapid Clone document 230672.1 on Oracle Metalink.
Yes, if the target system platform is binary compatible with the source system platform. For example, if you have an existing single-node Oracle Applications system on Solaris 2.6, you could clone it to a node running Solaris 8, but not to a node running HP-UX. Note that cloning from a higher version of a platform to a lower version is not supported, for example, from Solaris 8 to Solaris 2.6. Other examples of binary compatibility for Oracle Applications are:
Yes, if the source system has changed and you want to update the target system with these changes, you can reclone just the changed database. If Applications patches were applied to the source system, the APPL_TOP and the database must be cloned to keep the file system and database synchronized. See the Recloning section in the white papers for details.
You can use Rapid Clone to merge multiple APPL_TOP and COMMON_TOP file systems into a single APPL_TOP and COMMON_TOP file system. For more details about this procedure, see "Section 3: Merging existing APPL_TOPs into a shared APPL_TOP" in document233428.1 on OracleMetaLink.
No, Rapid Clone does not modify the source system. adpreclone.pl prepares the source system to be cloned by collecting information about the database and creating generic templates of files containing source specific hardcoded values. These templates are stored in the appsutil/template directory leaving the original files untouched. This process usually takes a few minutes to complete the first time. Migrating to Autoconfig on the database node (pre-req to Rapid Clone), however, will update the RDBMS init.ora and network listener files. See the instructions in the Autoconfig
If you are cloning on the same machine or want to redefine the server ports, you will be prompted for a port pool. The port pool provides a way to use a set of predefined server ports. There are 100 port pools. For example, if you select 3, the default database port number (1521) becomes 1524. The following table lists all the server ports. To see how the port pool calculation works, enter a number between 0 and 99(both inclusive) in the form and click "Get Ports". If you want to give a specific value to a port on the target system, independently from the port pool, you must first complete the Target System configuration with adcfgclone.pl (temporarily select a value for the port pool). Once adcfgclone.pl completes successfully, edit the new target context file with editcontext or OAM and modify
Yes, Rapid Clone preserves the patch history of the complete Applications Stack:
RDBMS ORACLE_HOME: preserve the OUI oraInventory.
iAS ORACLE_HOME: preserve the OUI oraInventory.
806 ORACLE_HOME: preserve the patch level and ORCA inventory.
APPL_TOP and Database: preserve the patch level and history tables.
Yes, Rapid Clone allows adding or removing database mount points or redistribute dbf files among mount points in the target system. As long as all the source system dbf files are present in the target system database mount points specified during the adcfgclone prompts (see question "How does adcfgclone.pl know the target system values?"), Rapid Clone will find them and re-create the database control file accordingly.
The oraInventory is the location for the OUI (Oracle Universal Installer)'s bookkeeping. The inventory stores information about: All Oracle software products installed in all ORACLE_HOMES on a machine Other non-Oracle products, such as the Java Runtime Environment (JRE). In a 11i Application system the RDBMS and iAS ORACLE_HOMEs are registered in
the oraInventory. The 806 ORACLE_HOME, which is not managed through OUI, is not. On Unix/Linux, the location of the oraInventory is defined by the content of oraInst.loc, at:/var/opt/oracle/oraInst.loc on Solaris, HP-UX and Tru64 - /etc/oraInst.loc on Linux and AIX. On Windows, the location of the oraInventory is defined by the value of the registry key HKEY_LOCAL_MACHINE|Software\Oracle\INST_LOC or if this value is not defined, at C:\ProgramFiles\Oracle\ Inventory
Before OUI 2.X, the oraInventory was binary. A binary oraInventory centralizes, in a binary format, the location of every Oracle products on the machine and the detail of their patch level. The oraInventory location is defined by the content of oraInst.loc. You will have a binary inventory only if ALL of the following conditions are met: you are on 11.5.7 or earlier (11.5.8+ install XML inventory out of the box) you have never installed OUI 2.X or higher (Install converts the inventory to XML) you have never run Rapid Clone (Rapid Clone converts the inventory to XML) If the following file exists, the oraInventory is NOT binary: <oraInventory location as pointed by oraInst.loc>/ContentsXML/inventory.xml
Starting with OUI 2.X and 11.5.8, the information in the inventory is stored in Extensible Markup Language (XML) format. The XML format allows for easier diagnosis of problems and faster loading of data Rapid Clone requires the inventory to be in XML format in order to clone it, and will take care of performing the binary to XML convertion if necessary. Unlike the binary oraInventory, The XML inventory is divided into 2 distinct components:
The Global inventory (or Central inventory), The Local inventory (or Home inventory) More information about these components is available under other questions in this FAQ. The inventory is XML if the following file exists: $ORACLE _HOME /inventory/ContentXML/comps.xml
The Global Inventory is the part of the XML inventory that contains the high level list of all oracle products installed on a machine. There should therefore be only one per machine. Its location is defined by the content of oraInst.loc. The Global Inventory records the physical location of Oracle products installed on the machine, such as ORACLE_HOMES (RDBMS and IAS) or JRE. It does not have any information about the detail of patches applied to each ORACLE_HOMEs. The Global Inventory gets updated every time you install or de-install an ORACLE_HOME on the machine, be it through OUI Installer, Rapid Install, or Rapid Clone. Note: If you need to delete an ORACLE_HOME, you should always do it through the OUI de-installer in order to keep the Global Inventory synchronized.
There is one Local Inventory per ORACLE_HOME. It is physically located inside the ORACLE_HOME at $ORACLE_HOME/ inventory and contains the detail of the patch level for that ORACLE_HOME. The Local Inventory gets updated whenever a patch is applied to the ORACLE_HOME, using OUI.
Rapid Clone requires OUI 2.2 to be installed in the ORACLE_HOME as a prerequisite and will performs all the actions necessary to clone the inventory: Converts the Global inventory to xml format when it was binary on either the source system or the target system Registers the cloned ORACLE_HOME in the target system Global Inventory Updates the Local Inventory of the target ORACLE_HOME to reflect the new machine, paths, users, etc.
The local inventory is automatically copied from the source system to the target system as part of copying the ORACLE _HOME itself. The Global Inventory is machine specific and therefore should not be copied. If you are cloning from one machine to a different machine, Rapid Clone will simply register the target ORACLE_HOME in the target machine Global Inventory (This action will automatically create the Global Inventory if it did not exist on that machine).
OUISetup.pl is shipped with the OUI patch, listed as a prerequisite to Rapid Clone (see Metalink Node 230672.1). It should be run as part of the OUI patch installation and will perform the following tasks: Register the OUI program in the Global Inventory. Register the JRE in the Global Inventory. Ensure that the ORACLE_HOME in which the patch is install is properly registered in the Global Inventory. In doing so, it will attempt to automatically fix Inventory corruptions that are known to cause problem while cloning, such as - Home indexes out of sync between the Global and Local Inventory - Duplicate Home Names entries - Duplicate Home Path entries
Frequently Asked Questions about
Using AutoConfig with Oracle Applications
AutoConfig is a configuration tool that automates the configuration of an Oracle Applications system. The information required for configuring an Applications system is collected into a repository, called the Applications Context; there is one Applications Context for each application tier, and one for the database tier. When AutoConfig runs, it uses information from the Applications Context file to generate all configuration files and update database profiles.
Before we can answer that, let's define a few terms in the context of the Release 11i architecture: A node or machine is a computer. A server is a collection of one or more computer processes that perform a specific function. A tier is a logical grouping of one or more servers or computer processes. Now let's answer the question. The application tier (also called the middle tier) consists of a number of servers, such as the concurrent processing server, web server, forms
This action might not be possible to undo. Are you sure you want to continue?