Re: Oracle RAC cost justification?

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.

-- 
Mladen Gogala
Oracle DBA
Ext. 121


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