RE: Q. To RAC or go vertical

The point of RAC is both fault tolerance AND scalability. More specifically, the ability to recover from a multi-node failure as well as use commodity hardware and scale on demand are the major motivating factors. Besides that, the cost difference between a mid-size SSI server and a RAC cluster is simply stunning.

We've done the TCO analysis over and over again, and there's simply no fiscal justification in today's world to put a mid-size database instance on anything _besides_ RAC. If you look at the hardware cost difference alone between an 8-way sun box and two 4-way linux boxes, its more than a 10-fold cost difference. That's before you take into account you often need a volume manager, a cluster server, and a whole second node to cluster it with to achieve the same level of reliability you get with a RAC cluster.

As always, full disclosure says I should say that I have a vested interest in the success of RAC, but I'm not even including our product in the cost comparison. Just vanilla RAC-on-linux vs. big-UNIX is a pretty compelling story in and of itself.

Now, I said there's no _fiscal_ justification. RAC is obviously not a hammer for every nail. There are both applications and workloads that either require special tuning or are just not optimal for message-passing clusters. Also, there are scalability limitations due to interconnect latency in terms of the number of nodes you can have in a cluster - this is something we're working on addressing here.

RAC's other big problem is that Oracle's RAC documentation is....artistic...by which I mean misleading, difficult to understand, and sometimes just wrong. This keeps organizations off of RAC or convinces them to hire consultants, and the vast majority of RAC consultants out there are even worse than the vast majority of Oracle/Sun consultancy practices - cookie cutter solutions and ill-informed consultants.

The above notes and my company aside, I would be shocked if I ever implemented a large single-image Oracle instance ever again.

*clambers off soapbox*

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com



> -----Original Message-----

> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On 

> Behalf Of Stephen Lee

> Sent: Tuesday, August 05, 2003 10:54 AM

> To: Multiple recipients of list ORACLE-L

> Subject: RE: Q. To RAC or go vertical

> 

> 

> 

> I think the point of RAC is fault tolerance, not scalability. 

>  If it's performance you want then you want a bigger box, not 

> more boxes.  8 CPUs is not big.  You sure don't need the 

> expensive hardware if all you want to run is 8 CPUs.  It 

> would be better to go with a smaller frame and use the money 

> you save to get more CPUs and additional I/O capacity.  For 

> example, instead of E12K with 8 CPUs, get 4810 with 12 CPUs 

> -- unless you have definite plans to push the E12K out to its 

> limits in the future.  Don't forget to consider the backup 

> requirements of a 5 - 10 TByte database.  Another 

> consideration, I think, is that those big, fancy boxes 

> require additional sys admin skills.

> 

> -----Original Message-----

> Hi All

> 

> I would like to ask for your thoughts on whether to RAC or 

> just go vertical (more cpu)

> 

> Background

> 

> Txn - OLTP like txn during day but batch extracts at night and 

>         very big batch extract periodically

> Data Volume - 5-10 TByte

> Data volatility - 99 % of data is very much like a ware house 

> (unchanged)

>                 other 1% is read/update/delete/insert

> 

> Options

> 1.  Say a very large server like a HP Superdome or SUN E12000

>         with 8 CPUs

>         Server already exist so cost is in obtaining 

> additional CPU/Blades

>         ie Traditional Server using plain old vanilla Oracle EE

>         - can still increase head room.  

>         - batch programs can utilise all 8 CPUs

>         - storage system need not cater for clustering

> 

> 2,  Same large server like a HP Superdome or SUN E12000 but 

> partitioned

>         into two. Each with 4 CPU.

>         Oracle RDBMS + RAC option

>         - storage server need to cater for cluster config

>         - max performance for batch is with 4 CPUs only

> 

> 

> Which would you prefer and why.  I am not convinced with the 

> RAC option. Now if I was going with cheaper Intel servers 

> like Dell servers with 4 CPUS each, and purchase say 4 nodes 

> of 4 cpus each, that would be a different story.  In this 

> case I have the equipment and ability to grow vertically.

> 

> ta

> tony

> -- 

> Please see the official ORACLE-L FAQ: http://www.orafaq.net

> -- 

> Author: Stephen Lee

>   INET: Stephen.Lee_at_DTAG.Com

> 

> Fat City Network Services    -- 858-538-5051 http://www.fatcity.com

> San Diego, California        -- Mailing list and web hosting services

> ---------------------------------------------------------------------

> To REMOVE yourself from this mailing list, send an E-Mail message

> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') 

> and in the message BODY, include a line containing: UNSUB 

> ORACLE-L (or the name of mailing list you want to be removed 

> from).  You may also send the HELP command for other 

> information (like subscribing).

> 


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Matthew Zito
  INET: mzito_at_gridapp.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).