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 CPU...it's still pining).

I manage about 30 RAC DB's.

-- 
..
David



> 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.


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