By: Zach May, Cox Enterprises, Inc.
Everyone has a different way of cloning Oracle E-Business Suite (EBS) environments, and they're probably all correct in some way.
There are plenty of best practices for cloning 12.1 and 12.2 E-Business Suite environments, including both the database and application tiers. There is so much information out there on Autoconfig, Rapid Clone, RMAN restores, automatic and manual cloning methods, multi-node and RAC support, and various scripting options; how to make sense of it is the important part.
Whether you've been cloning for years or just starting, there are always things to learn and new methods to improve your process.
There are many reasons why you would want to clone an EBS environment. The biggest reason that I’ve seen in my career is to satisfy various projects’ needs by creating one or many test systems from your production environment. Projects want flexibility with dates, recent data and the ability to quickly recover or refresh a database.
You also may want to create a copy of your production system for patch testing. You may be asked to create a staging area to reduce downtime for patching. Or you may want to move from an existing system or server to a different server in production.
Cloning scenarios will vary based on what environment you’re using as your target and what you’re using as your source. If you want to copy a single-node system to another single-node system, that is the most straightforward. You could then clone the clone to spin off multiple environments, using the original clone as a gold copy, giving you quicker recovery time.
If you have a multi-node environment and want to clone it to another multi-node, it’s a little more complex, but definitely doable. It just takes more steps and documentation. This is usually done when going from a multi-node production to a multi-node UAT environment. What I usually do is create a single-node instance and then expand it horizontally, using the cloning tools and scripts.
A few different things happen during database cloning with Rapid Clone. First, you obviously have to copy your Oracle Home binaries to the new location. Then, you’ll create and execute a script, adcfgclone.pl dbTier, which does lots of handy tasks for you. It creates a new context file based on inputs that you provide. Then, it will register the Oracle Home and relink it. It will then configure the Oracle Home, recreate the database control file, configure the database and start the database listener. See Figure 1.
When you clone the application tier, after you’ve copied the files over, you have to make it work with the system in the target environment. The adcfgclone.pl appsTier clone script will create the context file, register the Oracle Homes and relink them, create the instance top, configure the APPL_TOP, run autoconfig and then start the apps processes if desired. See Figure 2. Usually, I choose to not start up the processes, because there are always post steps to perform (reset profile options, update database values, etc.).
To clone an EBS 12.1+ database, you’ll first prepare the source database by running adpreclone.pl dbTier (pre-clone scripts don’t change your source system). Next, either by using RMAN or doing a cold copy of the data files, you need to copy the Oracle Home and database files over to the target system.
The adcfgclone.pl script that comes next will perform all the clone-related steps on the database side, including recreating the database.
Note: I’ve also cloned using regular RMAN or third-party tools without running the clone script, but this makes things like autoconfig more difficult to set up.
On the application side, the process is similar: run the pre-clone, copy the source filesystem (excluding the INST_TOP) and run the post-clone script, which will configure your Oracle Home, create the new INST_TOP and get your instance ready to start up.
There are always post steps to perform after the clone process is done. But the basic steps are pretty straightforward and well documented.
The process of cloning EBS 12.2 isn’t much different than 12.1. The main difference is you will clone to the target system and then do a separate cloning process for the patch file system and run file system. See Figure 3. The good news is, in the newest version of EBS, there’s a “dualfs” option that does that step for you!
In the autoconfig log files, the most common error I’ve seen is ORA-12514: TNS:listener does not currently know of service requested in connect descriptor. This usually happens when the database isn’t listening on the correct service or SID, therefore not allowing your clone processes to connect.
Related to this error is when autoconfig can’t connect to the database. This mostly happens on RAC environments. Check your tnsnames file, the SCAN listener, VIPs or ifiles.
To add a node to an existing system using Rapid Clone, you can run the pre-clone script first and then copy the file system to the secondary node. Then run the adcfgclone script with the dualfs option. Finally, run autoconfig on db and application tiers. See Figure 4
You can leverage the Rapid Clone technology to actually clone and restore/recover your RAC database to another RAC system or a single-node system. See the documentation for in-depth instructions.
Autoconfig has many scripts it uses and builds dynamically to manage the application. You can even run the check config utility to preview what it will do in your environment. One thing to watch out for is after autoconfig is done, check your mod_wl_conf.conf and apps.conf files, because clustering in webgloc is dependent on those files. And make sure you run autoconfig on each node to correctly populate the tnsnames.ora file with all the node information present.
You can use Enterprise Manager’s Application Management Pack (AMP) for advanced cloning features like hot cloning, automated cloning and data scrambling. See Figures 5 and 6.
Custom scripts are always handy for cloning, especially when you want to automate the process.
In EBS 12.1 and 12.2, cloning with SSO enabled requires a few configuration steps after the cloning is complete. The main ones are to un-register and re-register the OID and OAM components from EBS.
I hope this has been a useful recap of EBS cloning and points you in the right direction no matter your situation.
Zach May graduated from Auburn University and has been an Oracle Applications DBA for the past 12 years. He currently works with various middleware applications for Cox Enterprises, Inc., in Atlanta, GA, where he enjoys outdoor adventures with his family.