RE: Q. To RAC or go vertical

Thanks matt

Understand where you are coming from. But one of my issue is the performance required to carry out batch extracts. If RAC was able to slice the job up and share it across all nodes, that would be great ala Oracle10G (wont go there now).

WRT to TCO - RAC on Linux on Intel is the obvious way to go but it not an option for me at this point in time.

ta
tony

At 08:39 AM 05/08/2003 -0800, Matthew Zito wrote:

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: tjambu_fatcity_at_yahoo.com.au

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