Re: add node , oracle software a bit error

Hi Alex,

Thanks for the notes.

While I agree that keeping a number of OHs more than 1 and less than the number of nodes creates complexity, I don't think that I'd advocate one OH per node in a "large" cluster. I do know that managing CRS can be complicated by the fact that you need to keep careful track of the OH for each instance somehow, but CRS won't have any problems with that configuration--the admins will just have to keep careful track of the configuration. I don't think that's any more complicated than doing rolling upgrades with a new OH and "switching" the OH configuration in CRS to the new OH.

To the point about rolling upgrades, I know that when I think about rolling upgrades, I think of a process involving a) shut down an instance, b) apply a patch, c) start instance, d) repeat on the next node. To use a new OH changes things quite a bit and requires some manipulation of CRS that isn't required in what I'd consider the "normal" process for rolling upgrades.

Ultimately, I think we're saying essentially the same things--just different ways. The main difference I perceive is that, for "large" numbers of nodes, I would advocate more than one OH and less than one OH per node. I don't think that the CRS management is really that serious of an issue in an environment that's already fairly complex.

I welcome your additional thoughts and any others from the list.

Dan

• Original Message ---- From: Alex Gorbachev <ag_at_oracloid.com> To: Dan Norris <dannorris_at_dannorris.com> Cc: oracle-l_at_freelists.org Sent: Tuesday, July 10, 2007 10:34:45 PM Subject: Re: add node , oracle software a bit error

Dan, see few notes inline.

On 7/10/07, Dan Norris <dannorris_at_dannorris.com> wrote:
> In the scenarios involving larger numbers of nodes, I would advocate *some*
> sharing of OHs, but never a single OH for the whole cluster. In discussions

Well, it's a bit confusing to keep OH1 for nodes 1 and 2 and OH2 for nodes 2 and 4.
In fact, CRS configuration for a RAC database with instances running from different homes will be a mess.
When you register RAC database with CRS you specify Oracle home with in "srvctl add database ...". When you later add instances - you don't have an option to specify oracle home again using "srvctl add instance".
It will work when you do it manually but CRS would most probably be "confused".

> I'd offer a clarification on the last point about rolling patches.
> You said that it is easier to apply rolling patches--I think you mean to say
> that it is *possible* to apply rolling patches with non-shared OHs. I
> suppose that you could apply rolling patches with a shared home, but, at
> least for part of the process, you don't have a shared OH.

You can do that by installing a completely new Oracle home and apply the patch there. Then you would switch databases there one by one. You shouldn't forget CRS configuration issue I mentioned above. At the end we will need to remove all resources from CRS and re-register with the new home. Possibly you can update it using "crs_stat -p" + "crs_register" but I noticed that for databases and instances it's not just registering .cap files -- srvctl does something else somewhere so it should be used instead.

> So, I still haven't found a compelling reason to use shared OHs. I'm all
> eyes for anyone that can make the good case for it.

Well, on development system and relatively low profile production systems. Also with certain architectures that are centered around simple provisioning of additional nodes. However, they still suffer from all limitations mentioned.

Cheers,
Alex

-- 
Alex Gorbachev, Oracle DBA Brewer, The Pythian Group
http://www.pythian.com/blogs/author/alex http://www.oracloid.com
BAAG party - www.BattleAgainstAnyGuess.com





--
http://www.freelists.org/webpage/oracle-l