20090520 cloning an oracle 10g as environment - plembo/onemoretech GitHub Wiki

title: Cloning an Oracle 10g AS environment link: https://onemoretech.wordpress.com/2009/05/20/cloning-an-oracle-10g-as-environment/ author: lembobro description: post_id: 320 created: 2009/05/20 16:19:41 created_gmt: 2009/05/20 16:19:41 comment_status: open post_name: cloning-an-oracle-10g-as-environment status: publish post_type: post

Cloning an Oracle 10g AS environment

Please note: this is not recommended by me. It’s a very clever kludge put together by someone who knows more about 10g AS than I ever will, but it’s a kludge nontheless. At present there is still no Oracle supported way to clone an Oracle 10g AS environment. For good reason. If we all started doing this the ensuing support calls would crash MetaLink… er, “My Oracle Support” (that “My” thing is soooo 90’s).

In-Depth: Cloning OracleAS 10g + E-Business Suite Environments

From the body of the article:

The Easy Part

The E-Business Suite Release 11i was architected to support cloning. Experienced Apps DBAs know that the easiest way to create clones of their environments is to use the Rapid Clone utility introduced in 11.5.8. Creating a n E-Business Suite clone is as simple as copying your application-tier and database-tier files to the new target system and then running the perl-based Rapid Clone (adcfgclone.pl) utility.

The Not-So Easy Part

Oracle Application Server 10g was designed with different goals in mind. Consequently, there are no Oracle tools available today to clone an entire OracleAS 10g environment in a single step. In other words, OracleAS 10g does not have the equivalent of a Rapid Clone utility.

If you read through the piece carefully you’ll find one problematic step, at least if you’re in the business of maintaining the 10g AS infrastructure side of things:

“4. Create a fresh install of Single Sign-On and Oracle Internet Directory 10g on your new server.”

Right.

In an environment where EBS cloning is only done occasionally or in a small lab setting, this might not be an issue. It becomes positively impractical in a big enterprise environment where it’s being done constantly. And don’t get me started on everything that can go wrong here. Especially where the OID in question also happens to be the primary configuration and user store for an integrated Portal environment…

Here’s my best practice tip of the day:

If you’re faced with an aggressively cloned EBS environment don’t try anything fancy like this. Instead, do your best to keep the user accounts on EBS in sync with the user entries on OID. Pre-clone make sure the deintegration scripts have been run and that all the EBS config stuff has been cleaned out of OID. Post clone make sure the dereferencing scripts are run against EBS before you start reintegrating. This would also be a good place to null all the USER_GUIDs in FND_USER for the newly cloned EBS instance. I’d also recommend level-setting everything by changing the EBS system profile settings to reflect a nonintegrated configuration. Restart the EBS web server.

Once you’ve done all this, go ahead and do the reintegration. Once the integration has tested good, you can go sync the target OID with the source OID using a script or a combination of LDIF dumps (make sure to exclude operational attributes like authpassword) from each that can be diffed for the target (I use ldifdiff.pl for this).