RE: 64 node Oracle RAC Cluster (The reality of...)

From: Kevin Closson <kevinc_at_polyserve.com>
Date: Wed, 22 Jun 2005 10:47:58 -0700
Message-ID: <B9782AD410794F4687F2B5B4A6FF3501FAA9C6@ex1.ms.polyserve.com>

>Because if you have a single, shared ORACLE_HOME, you can't do rolling
upgrades with RAC.
>John Smiley
>Technical Management Consultant
>TUSC, Inc

Nobody can do rolling upgrades with RAC, shared home or otherwise.

I'm finding that Oracle literature/marketing is confusing a lot of people lately - although mostly around RAC and Linux platform issues. If anyone has done a rolling upgrade (e.g., 10.1.0.3 -> 10.1.0.4), stop me now...ok, that's overwith...

What people have been misreading (because this is only a misunderstanding of the oracle marketing story) is how 10g supports "Rolling Upgrade". Yes, it does, if you leave the quotes in place.

The "Rolling Upgrade" involves 2 clusters in data guard with a sprinkling of SQL Apply.

That has nothing to do with whether Oracle Home is shared or not. It is 2 different clusters with 2 different databases - either 2 different single Shared Oracle Homes, or a myriad of non-shared homes. The problem with the whole idea is that there is no transparent failover from one cluster to the other. So there will be a total outage at some point anyway. Our customers choose to implement RAC in a fashion that makes the upgrade as lightweight as possible ( only have 1 Oracle Home to upgrade). As always, when I directly counter a point from a poster, I provide reference, after all, the little guy has only the facts on his side to counter the bully pulpit of large marketing outfits... See figure 7 (interesting, using and oracle.com URL to bring a glimmer of truth to a marketing misrepresentation):

http://www.oracle.com/technology/deploy/availability/htdocs/HA_Overview. htm

Now, one-off patches are another thing. In **theory** these can be applied in a rolling fashion. However, you have to look far and wide for the patches that prove the theory. For instnace, the Jan 5 Critical Patch Update (CPUJan2005) explicitly states in the FAQ that it cannot be applied in a rolling fashion as seen in Note:293955.1:

"4. Can the Critical Patch Update January 2005 be used in a Rolling Upgrade?

No, unless otherwise noted in the patch readme file, the Critical Patch Update January 2005 cannot be used in a Rolling Upgrade. There is a defined set of rules to determine whether a patch is 'rolling installable'. Oracle is investigating the criteria required to certify future security patches to be 'rolling installable'. "

So, the truth of the matter is that the "shared-home- disqualifies-rolling-upgrade" red herring has been thrown out there largely by the factions who cannot implement a shared RAC home due to technical shortcomings in the stack of their choice.

And choice is crucial. After all, when was the last time lack of choice helped anyone solve an I.T. problem?

Kevin Closson
Chief Architect, Database Solutions
PolyServe
www.polyserve.com

	From: John Smiley [mailto:jrsmiley_at_gmail.com] 
	Sent: Wednesday, June 22, 2005 9:44 AM
	To: peter.sharman_at_oracle.com
	Cc: kevinc_at_polyserve.com; mwf_at_rsiz.com;
Rich.Jesse_at_quadtechworld.com; oracle-l_at_freelists.org; Peter Ross Sharman
	Subject: Re: 64 node Oracle RAC Cluster (The reality of...)
	
	
	Because if you have a single, shared ORACLE_HOME, you can't do

rolling upgrades with RAC.

	John Smiley
	Technical Management Consultant
	TUSC, Inc.
	
	 
	On 6/21/05, Pete Sharman <peter.sharman_at_oracle.com> wrote: 

		Nope, sorry, this is determined by whether the ***OS***

(i.e. not the database) supports a clustered file system or not. I suspect this is something you already know, since you sell one. :)

Sorry, couldn't resist.

Seriously, where a CFS is supported by the OS, why would you do anything else for the ORACLE_HOME?

Pete

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

Received on Wed Jun 22 2005 - 13:53:22 CDT