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

Other related posts: