FreeLists / oracle-l / RE: 64 node Oracle RAC Cluster (The reality of...)

["Kevin Closson" <kevinc@xxxxxxxxxxxxx>]

>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@xxxxxxxxx] 
        Sent: Wednesday, June 22, 2005 9:44 AM
        To: peter.sharman@xxxxxxxxxx
        Cc: kevinc@xxxxxxxxxxxxx; mwf@xxxxxxxx;
Rich.Jesse@xxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx; 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@xxxxxxxxxx> 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