The Latest Oracle E-Business Suite Technology News direct from
Oracle E-Business Suite Development & Product Management

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

Steven Chan
Senior Director

Guest Author: Nick Quarmby

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.

COMMON ERROR #1: 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.

COMMON ERROR #2: 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.

COMMON ERROR #3: 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.

COMMON ERROR #4:  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. References

Related Articles

Join the discussion

Comments ( 10 )
  • guest Monday, July 16, 2012

    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!

  • Nick Quarmby Tuesday, July 17, 2012

    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.



  • Jay Weinshenker Tuesday, July 17, 2012

    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. "

  • Nick Quarmby Wednesday, July 18, 2012

    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.



  • guest Wednesday, September 26, 2012

    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!

  • Amudan Monday, February 4, 2013


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

  • Nick Quarmby Monday, February 4, 2013

    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.



  • Benny Tate Friday, May 31, 2019

    Does Oracle offer instructions or DOC ID addressing RapidClone on an EBS environment that is using APEX? I understand rapid clone would clone the APEX schemas, objects etc that reside in the EBS database (such as the various APEX schemas APEX_190100 and any APEX related workspace schemas etc as long as not in a seperate database linked database).

    but what about file system apex folders or ords folders where I've unzipped the apex and ords zip files?

    For example, I've placed my apex install zip and ords install zip contents under the following two folders respectively on the database tier:
    /u01/BRTADEV1/apex (/u01/BRTADEV1 being our $ORACLE_BASE)

    I've been using simplest method of using ORDS Standalone mode.

    I imagine when doing rapid clone steps I would also tar the above two folders in addition to the other db tier and app tier folders I normally tar during a rapid clone.

    I'm curious though if Oracle has specific steps to address RapidClone steps for an EBS environment that has developed using APEX/ORDS.


  • Benny Tate Tuesday, June 11, 2019
    Hello again, to answer my previous question about how to address custom APEX apps on an EBS system after using RAPID CLONE. All I had to do was the following:
    - tar archived the source system's apex directory tree which originated from