OracleDBA.co.

in
Sharing Knowledge on Oracle E-Business Suite Applications, Database Administration !!!
Top of Form

Bottom of Form

• About Us
• Home

FAQs of Cloning Oracle Applications Release

11i
Posted in September 13th, 2010
by Siva.Karanam in Cloning FAQs
1. What is cloning?
Cloning is the process of creating an identical copy of an already existing Oracle Applications
system.
2. How can I clone an Oracle Applications system?
• Cloning Oracle Applications Release 11i
• Cloning Oracle Applications Release 11i with Rapid Clone
3. What are the differences between the two cloning methods?
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.
4. What is the AD Cloning utility?
AD Cloning utility (adclone.pl) is the name of the cloning command line utility. This utility is
used to preserve and apply configuration information to the cloned target system.
5. What is 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
Note 230672.1 (Cloning Oracle Applications 11i with Rapid Clone) for instructions on installing
and enabling Rapid Clone.
6. How do I determine if my system is Rapid Clone enabled?
First, verify that your system is AutoConfig enabled. Then, verify that you have applied the latest
Rapid Clone patch documented in OracleMetaLink Note 230672.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.
7. What is AutoConfig?
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 Note 165195.1 for details on installing and
migrating to AutoConfig.
8. How do I determine if my system is AutoConfig enabled?
There are several identifiers for when the system is AutoConfig enabled. The following are two
common indicators:
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.
9. We are running Release 11.5.7 (or any prior release), which cloning method can we use?
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 the Cloning Oracle Applications Release 11i with Rapid
Clone white paper.
10. We are running Release 11.5.8 (or any later release), which cloning method can we use?
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.
11. Our Oracle Applications system is on Windows, which cloning method can we use?
If your system is on a release prior to 11.5.7 and is not AutoConfig enabled, use the method
documented in the Cloning Oracle Applications Release 11i white paper. If your system is on
any AutoConfig-enabled 11i release, use the method documented in the Cloning Oracle
Applications Release 11i with Rapid Clone white paper.
12. We have a Platinum installation of Oracle Applications. Can we clone our system?
Yes, cloning a Platinum system using the Rapid Clone method is no different than cloning a non-
Platinum installed system.
13. Can I clone from one operating system version to another?
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:
AIX 4.3.3 to AIX 5.1 (32-bit)
HP-UX 11.0 to HP-UX 11i
Windows NT to Windows 2000
14. Can I clone from one platform to a different platform?
Yes, you can clone or migrate the Applications middle tier from any platform to Linux or any
supported UNIX platform using the procedure described in document 238276.1 “Migrating to
Linux with Oracle Applications Release 11i”.
15. Can I reclone just the database?
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.
16. Can I clone a single-node system to a multi-node system?
The Rapid Clone cloning method allows for cloning a single-node system to a multi-node
system. See the Cloning Oracle Applications Release 11i with Rapid Clone white paper for
details.
18. Can I clone a multi-node system to a single-node system?
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 document 233428.1 on
OracleMetaLink.
19. Does Rapid Clone modify the source system?
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 document 165195.1 (Section 4: Migrating to AutoConfig on the Database Tier) on
how to preserve customizations to these files.
20. What is the port pool? What if I want to give a specific value to a Server Port?
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
22. Does Rapid Clone preserve the patch history?
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.
23. Can I clone a clone?
Yes, a cloned system created with Rapid Clone can then be used as the Source System in the
next cloning. Rapid Install itself is now a clone of a clone using the Rapid Clone technology.
24. Can I change the database dbf files layout while cloning?
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.
25. What is the oraInventory?
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
26. What is a binary oraInventory? Is my Inventory binary?
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
27. What is a XML oraInventory? Is my 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
28. What is the Global (or Central) Inventory?
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.
29. What is the Local (or Home) Inventory?
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.
30. How does Rapid Clone deal with the oraInventory?
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.
31. Why don’t I need to manually copy the oraInventory when cloning?
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).
32. What does OUISetup.pl do?
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
Digg It Add To Delicious Stumble This Add to Technorati