Re: add node , oracle software a bit error

  • From: "Alex Gorbachev" <ag@xxxxxxxxxxxx>
  • To: "Dan Norris" <dannorris@xxxxxxxxxxxxx>
  • Date: Tue, 10 Jul 2007 23:34:45 -0400

Dan, see few notes inline.

On 7/10/07, Dan Norris <dannorris@xxxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 07-2007