Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle RAC cost justification?

RE: Oracle RAC cost justification?

From: Marquez, Chris <>
Date: Thu, 2 Jun 2005 14:44:43 -0400
Message-ID: <B30C2483766F9342B6AEF108833CC84E0450BBF3@ecogenemld50.Org.Collegeboard.local>

(below)From a recent post on this list.
TAF is immediate session immediately move/reconnected to the surviving node, but SQL*Plus was the on support app at the time I tested it. Also as said in the post PS/SQL, and any I,U,D do not continue and you have to configure it for Selects to continue. I the world of middle tiers I find it easier just to let the reconnect and failover (using proper tns syntax)

||I manage about 30 RAC DB's.
30 RAC DB's on the 2 large servers or on 60 individual small servers? Run any in active-active mode with *real* busy app? Is your life with RAC more complex or not? Linux, IBM, Sun, HP?


>> -----Original Message-----
>> From: Marquez, Chris
>> Sent: Monday, May 23, 2005 5:34 PM
>> To:
>> Subject: RE: TAF AND connect time failover with RAC using JDBC thin driver on 9205
>> Further, in the many hours I spent researching, configuring,
>> testing,8i/9i TAF I found the very few,
>> I mean very few, apps that can take advantage of it,
>> not even Oracle the time was only SQL*Plus :0|
>> TAF is very cool I was able to make session failover automaticaly,
>> but for 8i/9i (don't know about 10g) not much use.
>> hth
>> Chris Marquez
>> Oracle DBA

Chris Marquez
Oracle DBA

-----Original Message-----
From: on behalf of David Sent: Thu 6/2/2005 2:31 PM
Cc:; Oracle Discussion List Subject: Re: Oracle RAC cost justification?  

Who is using TAF here?
Does it work seamlessy or transparantly? No issues? If you lose a node/instance, what happens next? Is there any impact on the others heads in terms of smon/eviction? How long does it take to get the application to start hitting an instance an another node?

Without RAC one can still have the ability to mount a DB on another head thaty ic connected to the same SAN. Use OCFS and all nodes can see the volumes still...without RAC. Use RAW or ext3 and simply unmount the volumes and mount on another head. The 2nd method has been done for years...quickly. The first option is now available to us with or without RAC and speeds up the process or moving LUN's.

What does RAC get you, that you cannot do anway in a way that is less complex and without the resource overhead of RAC(disk or's still pining).

I manage about 30 RAC DB's.


> Tim Gorman wrote:
>>Instead of arguing about whether RAC is good at scalability or HA or
>>cost-effectiveness, how about citing specifics?
> Tim, with RAC you must have several things in mind:
> 1) RAC is NOT a performance option, it's  a survivability option. The
>    price for tolerating a single hardware failure is quite hefty. There
>    is also a performance penalty to pay: 2 nodes with 8 CPUs each, will
>    perform significantly slower then a single node with 16 CPUs.
> 2) RAC complicates your application development. I know it's not a
>    politically correct thing to say and you know how much I care about
>    being PC, but the dreaded phrase "functional partitioning across
>    instances" still applies, even with cache fusion and creating a read
>    consistent version of the block by the node who currently owns the
>    GC lock. Even that will not help users doing DML against the same
>    object from different instances. Global locks will still need to be
>    acquired and locking blocks will still stifle concurrency. GC locks
>    are used to lock blocks, not rows.
> 3) It makes buying a 3rd party application much harder. Application
>    vendor can show off his application running on a gigantic brand new
>    HAL 9000 but when you come to the orbit of Jupiter or pay for the
>    application, then the real fun will begin. Of course, in real life
>    Dave Bowman (DBA) does not get the chance to kill the monster and
>    afterwards see the stars.


Received on Thu Jun 02 2005 - 14:55:20 CDT

Original text of this message