RE: Q. To RAC or go vertical

Hi Jared

Yes I have read his article and also Dave Ensor's thoughts in it. I personally am not convinced and am looking for reasons why I should go with RAC other than fault tolerance given the risk involve in being one of the 1st few genuine pigs.

I probably say, I would go with single instance with lots of CPU in the 1st instance and then reconsider my options in about 12 months time.

Hi Mogens, if you are reading, Tony here from melb. Do you have any thoughts on this and would you have an 'alternative' version of the article that you wouldn't mind sharing.

ta
tony

At 09:04 AM 05/08/2003 -0700, Jared.Still_at_radisys.com wrote:

>... though now that I've read the original post ( missed it somehow ) I
>would say
>that you may just want a bigger box.
>
>See Mogen's article "You Probably Don't Need RAC" at selectonline.org.
>
>You may want to ask Mogens for an alternative version of the article, in
>fact, I think you should.
>
>Jared
>
>
>
>
>
>
>Jared Still <jkstill_at_cybcon.com>
>Sent by: ml-errors_at_fatcity.com
> 08/05/2003 08:44 AM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> cc:
> Subject: RE: Q. To RAC or go vertical
>
>
>
>While fault tolerance is certainly one of the features of RAC,
>it isn't correct to say that it is not also for scalability.
>
>Buy a bigger box? That works fine until you're in the biggest
>box you can get, then what? I realize that it's a small market
>segment that requires that kind of hardware, but it still exists.
>
>Sun has been testing a cluster of 15k servers with RAC, ostensibly
>for scalability. Some nodes are populated with 78 CPU's and 288
>Gig of RAM. ( yes, that is correct ).
>
>Jared
>
>
>On Tue, 2003-08-05 at 07:54, Stephen Lee wrote:
>>
>> 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: Jared Still
> INET: jkstill_at_cybcon.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).