RE: RAC newbie question

From: Yavor Ivanov <>
Date: Tue, 7 Oct 2008 17:45:11 +0300
Message-ID: <BD17E2E69E17C64A9684C940EB580E03010D7D55B224@stemodc1.stemo.local>

        Hello, Dan
        Yes, I see I did not explain myself to clearly... I haven't done 10g -> 11g RAC upgrades, but as far as I remember, 9i to 10g RAC upgrade requires downtime for the whole cluster during the upgrade (or "migration", on Oracle terms) of the clusterware. Are you sure it is possible to make rolling upgrade from 10g to 11g (or 11 to 12...) of the clusterware without downtime?
        I'm not talking about the possibility to use the standby database to minimize downtime.

Yavor Ivanov
Oracle Certified Master

-----Original Message-----
From: Dan Norris [] Sent: Tuesday, October 07, 2008 4:35 PM
To: Yavor Ivanov
Cc:; Mercadante, Thomas F (LABOR); Subject: Re: RAC newbie question


I'm not sure I am clear on your recommendation. You said you'd use a single 9-node cluster too, but then seem to bring up topics that appear to suggest that a single cluster is a Bad Thing.

To clarify, there is no planned downtime I can foresee that would affect the entire cluster. Clusterware upgrades are rolling. New ORACLE_HOMEs would just be added (no downtime) along side the existing ORACLE_HOMEs so that some databases could run on a newer version. Assuming all databases are either multi-instance or single-instance but could afford a short failover outage, no applications should have any extended outages. Obviously, if a database patch/upgrade is required then those databases would have planned outages to apply the patches (if the patch isn't rolling upgradable too). Of course, this is no different than if you were in 3, 3-node clusters.

In short, I can't find any reason to "break up" the nodes into multiple clusters. I'd put all of them in a single cluster which I think will ultimately increase the overall availability of the total environment.


Yavor Ivanov wrote:
> Usualy I would go with single 9-node cluster too. Same reasons. But there are some more things to consider here.
> Think about cluster upgrades. If you have one cluster to upgrade, this sounds like single downtime window. But what if one database needs a newer version (and newer clusterware), and the other cannot afford downtime at that moment? This is something rare, but it's not bad to think of it.
> Also, some influences may come from your backup / DR strategy. But this goes too deep, and gives too little value.
> But as I've said, I'd usually go to 9-node with every app running on different nodes.
> Regards,
> Yavor Ivanov
> Oracle Certified Master

Received on Tue Oct 07 2008 - 09:45:11 CDT

Original text of this message