Comments on: EBS advanced topologies: Sharing APPL_TOP, ORACLE_HOMEs, err… heck, why don't we share it all?

By: Arnoud Roth

Arnoud Roth — Mon, 07 May 2007 13:35:48 +0000

Let me guess, did you use Metalink note 362135.1?
Can you tell me more about what exactly went wrong?

By: jason smith

jason smith — Thu, 03 May 2007 23:51:26 +0000

Have you been successful in using rapid clone to convert Oracle E-Business Suite 11.5.10.2 environment, single instance, multi-tier, which needed to be converted to a two-node RAC? Could you elaborate on the detailed steps that you followed- I have been trying to do the same with little luck.
Thanks

By: Arnoud Roth

Arnoud Roth — Wed, 02 May 2007 15:06:43 +0000

Nigel,
I am almost sure this won’t do (setting the TNS_NAMES the way you propose). As far as I know, racgwrap is only used by srvctl, which initiates a secure shell connection to wichever machine, even the local machine. Regardless, what if you would start instance PROD2 from node1? This will start the database instance from node2, but you didn’t login to node2, you are on node1. Under the surface, a secure shell (ssh) is initiated that immediately runs the scripts to start the instance. This ssh connection will not source the environment, so ORACLE_SID will not be set. I am not even convinced of this when it comes down to starting instance PROD1 from node1. Srvctl will initiate ssh even for the local node, bypassing the sourcing of the environment file. Adding the environment file to your .profile or equivalent I believe will not do, because .profile is bypassed when you run a command using ssh. Additionally, what if you have multiple databases running on your nodes (PROD, TEST, etc)? How to determine the ORACLE_SID? You might have dedicated users per environment, but you cannot have multiple Clusterware (used by srvctl) installations per node.
About your “bigger” question: My opinion is that with an application like EBS, downtime should be minimized as much as possible. That implies minimizing the risks for (unplanned) downtime as well. Especially with upgrades or patches (as already stated in the post), when having shared everything, the risks of downtime due to damage being done to the code is significant. When you would dedicate the code to the node it is running on, there is the possibility to upgrade the code locally, test it out, and if necessary fall back to the not yet patched node.
There is one major issue here (as allways is the case when you are using EBS). Patching the EBS software (APPL_TOP, etc), most of the times changes are made to the database as well. So it is allways necessary to have a proper backup of the database (DUH?).

By: Nigel Thomas

Nigel Thomas — Wed, 02 May 2007 09:53:52 +0000

Arnaud

Small point; you should be able to simplify your setting of TNS_ADMIN to a single line:

TNS_ADMIN=$ORACLE_HOME/network/admin/${ORACLE_SID}_`hostname`

I’m assuming of course that you’ve already set ORACLE_SID in a node-specific way. Bigger question: what happens when you upgrade (Oracle, Apps, CRS, etc) in this scenario? that’s maybe as big an issue as human errors (don’t most human errors happen during upgrades?)

Regards Nigel