Five Errors Customers Make When Cloning E-Business Suite 12 (Part 2)

This is the second in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, patching, migrations, upgrades, and maintenance. This article discusses cloning. Subsequent articles will cover patching, migrating, upgrading, and general maintenance.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day-to-day maintenance and upgrade of a typical E-Business Suite environment.

: Assuming that use of the Rapid Clone utility is optional when cloning your Apps environment.

ORACLE’S RECOMMENDATION: Rapid Clone greatly simplifies the process of cloning your E-Business Suite environment. Simply copying your E-Business Suite environment to new host machines, editing the context files to reflect the new environment and then running AutoConfig is not a supported cloning method. Devising your own cloning methodology that bypasses Rapid Clone is a dangerous strategy. If Rapid Clone does not work for you, then raise a Service Request and ask for help in fixing the issue. Do not create an alternative cloning method that you hope will sidestep whatever issue you are seeing.

: Assuming that the preclone scripts only need to be run once on an environment.

ORACLE’S RECOMMENDATION: You must run the preclone scripts immediately before each clone, prior to shutting down the application and database tiers in order to copy the files for cloning (or RMAN backup). It’s also good practice to remove or rename the database tier $ORACLE_HOME/appsutil/clone and application tier $COMMON_TOP/clone before running the preclone script. Always check the cloning documentation for the latest patches before each clone.

: Mistakenly using Rapid Clone to migrate from 32 bit Linux to 64 bit Linux.

ORACLE’S RECOMMENDATION: Although these platforms are binary compatible, cloning your E-Business Suite from 32 bit Linux to 64 bit Linux will only produce a 32 bit E-Business Suite environment on your 64 bit operating system. In order to fully exploit your 64 bit operating system you should follow specific migration documentation for your E-Business Suite environment. The same applies to other certified operating systems available as both 32 and 64 bit.

:  Mistakingly forgetting to update the central inventory when overwriting a previous clone with a new clone in the same location.

ORACLE’S RECOMMENDATION: If you regularly repeat a clone to the same location on a target node, you must ensure the central inventory entries for the previous clone are removed before configuring the new clone. As with a repeated installation, when deleting an E-Business Suite environment prior to cloning to the same location, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new clones may fail.

COMMON ERROR #5: Assuming that the clone is not a completely accurate copy.

ORACLE’S RECOMMENDATION: A system created using Rapid Clone is the most genuine and supported copy you can create. It has an identical database, application tier and technology stack as the source environment it was created from. The only significant difference between a source and target clone environment is the data specific to the new hardware (node names, directory locations etc.). It is supported to clone your production environment, apply patches to the clone and then clone the patched system back to become your new production environment. Assuming the cloning documentation is followed correctly, an E-Business Suite environment does not degrade through being repeatedly cloned.


Related Articles


Can you clarify “COMMON ERROR #3: Mistakenly using Rapid Clone to migrate from 32 bit Linux to 64 bit Linux.” further? Our environment is currently running Linux 64bit database server with two application servers running Linux 32bit. We plan to upgrade our application servers to Linux 64bit as part of our upcoming server replacements. The notes available for this type of migration are not very clear, at least to me, and note "Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit [ID 471566.1]" implies to me that you do migrate the application servers with Rapid Clone. Our plan is to ignore the sections about the database migration, since we are already at 64bit database, but to use Rapid Clone on our application servers. Are you saying that this will not work? If not, can you point us to a note that is clear on how to migrate just our application servers? Thanks!

Posted by guest on July 16, 2012 at 11:40 AM PDT #

Hi Guest

The migration issue I was referring to is primarily about the migration of the database tier. You're correct, you should follow Note 471566.1 to migrate your application server tiers which means you perform a clone but then there are the additional steps in Note 471566.1 which are not in the normal cloning documentation and are required specifically because you're going to a different o/s. You could also take this opportunity to upgrade to the latest 10.1.2 and 10.1.3 by following Note 437878.1 and Note 454811.1.



Posted by Nick Quarmby on July 17, 2012 at 01:16 AM PDT #

I have a suggestion based on what was said in the blog post.

At the end of the blog post there's this "A system created using Rapid Clone is the most genuine and supported copy you can create. "

Given that Oracle fully supports running Oracle EBS in a virtualized environment (OracleVM, VMware, whatever), I'd like to suggest that Oracle should create additional documentation in Section 4: Advanced Cloning Options of Cloning Oracle Applications Release 12 with Rapid Clone [ID 406982.1]

around cloning the VM(s) themselves. You would still leverage rapid clone, but after cloning the VMs themselves and changing the hostname, IPs, etc then running postclone steps - now in addition to having "an identical database, application tier and technology stack as the source environment it was created from" you also have all the custom scripts, environmental settings, software DLLs / RPMs, scheduled OS jobs, etc.

*That* would be "the most genuine and supported copy you can create. "

Posted by Jay Weinshenker on July 17, 2012 at 01:27 PM PDT #

Hi Jay

Thanks for your suggestion. Where Oracle VM is concerned, I hope what you are looking for is discussed in Note 1355641.1. A link to this Note from Note 406982.1 could certainly be helpful.

I think we're unlikely to produce anything similar for other virtualised platforms (such as VMWare) as we do not actually certify the E-Business Suite on these.



Posted by Nick Quarmby on July 18, 2012 at 01:26 AM PDT #

Surely mistake number 6 has to be hiring people that make mistakes 1 - 5? Those are pretty fundamental errors, and I wouldn't have anyone in my team that made those!

Posted by guest on September 26, 2012 at 05:34 AM PDT #


Is there any automated cloning scripts of R12 Instance (unix environment) available?

Posted by Amudan on February 04, 2013 at 05:03 AM PST #

Hi Amudan

You can use the Oracle Application Management Pack (AMP) to automate the cloning process. You can find more details about AMP in Note 1434392.1 and also at...

There is no documented process for automating the scripts when run from the command line.



Posted by Nick Quarmby on February 04, 2013 at 06:20 AM PST #

Post a Comment:
Comments are closed for this entry.


« January 2017