Re: [new info] Redhat Advanced Server Dev Edition - RAC

Thanks, Mark. Any email helps. Wherever I've taught a class around the world while I was still with Oracle, or later after doing the Miracle thing, I've always given out my email address and phone numbers to everybody in the room - and on average have received two emails even when I was presenting for 100 people.

But the Unix SIG meeting in London changed that. I've gotten about 7 or 8 mails from the 110 attendees there, so I'm feeling like a rock star right now...

RAC is on sale (at least in the US) currently, which means it only costs 25% on top of EE instead of the normal 50%.

But if you're paying $60K (or perhaps only $50K :) ) per CPU for Oracle, why is it important to have extremely cheap hardware to run it? Why would you want to run very expensive software on very cheap hardware? Yes, the total price will go down, but just like when we're looking at databases and try to find where the time goes, we might here want to look at where the money goes and then try to cut the cost by looking at, say, the most expensive part of the configuration first :).

One important thing to realise is that Oracle is selling this and managers and directors are buying it, while many DBA's and system admins are asking the right questions (to absolutely no avail), namely: Why? Are there cheaper and/or simpler and/or better alternatives to our real needs here? The dream of having all those wonderful things (HA, scaling, workload partitioning, happier marriages, more uniforms, faster cars, and such) is easily sold to the political levels but not to the twisted and bitter old men and women in the technical world.

The result is of course that RAC will pop up here and there and perhaps one day everywhere.

But RAC, clusters, CFS, what have you, all make the environments even more complex. Which is good for me, since I run a high-end consulting outfit. Should be good for all of us. But then we all have to stop questioning the wisdom of buying and implementing RAC and instead endorse it every time we get the chance.

The only downside I can think of is that if all the techies start shouting "We will, we will, RAC you" and "RAC over Bethoven" everywhere and at all times, managers and directors might think that RAC is some kind of nerdy thing that they'd better stay away from. Action and reaction.

Best regards,

Mogens

Mark Leith wrote:

>I heard Mogens talk about this at the UKOUG Unix SIG in London at the end of
>last month ("You Probably Don't Need RAC, or: pRos And Cons"). It was truly
>an eye opener! The upshot was, if you don't have a requirement to be up from
>a failure within 5 minutes, then you don't need RAC. As has already been
>pointed out, in the case of a SAN failure, then even this may not count.
>
>Mogens also mentioned some pretty interesting up time statistics. A single
>Unix box can have an availability of 99.9%. A two node Unix cluster has an
>availability of 98% (due to software patching/upgrades). There is also still
>a "brown out" period with RAC when a node fails, whilst the other node or
>nodes play "catch up" to re-assign the resources and recover any work that
>the failed node was doing at the point of failure.
>
>Of course, there are also pros to having RAC, workload partitioning (running
>batch on one node, OLTP type work on another), you can scale your CPUs as
>and when the increase is needed.
>
>There seemed to be far more cons than pros imo though. Mogens goes through a
>lot more in his talk, it is certainly worth your time! It certainly helps to
>widen your perspective from the constant marketing jargon ;)
>
>I really must remember to send Mogens an email, he loves email, send it to
>him directly, I'm sure he'll be ecstatic! :D
>
>Mark
>
>-----Original Message-----
>Sent: 11 February 2003 23:34
>To: Multiple recipients of list ORACLE-L
>
>
>FYI, I am headed to Mogens RAC or Not to RAC presentation at the hotsos
>symposium, let you know what I learn!
>
>-----Original Message-----
>Sent: Tuesday, February 11, 2003 10:30 AM
>To: Multiple recipients of list ORACLE-L
>
>
>
>This is all cool technology, and fun stuff to play with.
>
>It all begs the questions,
>
>"How many of us work for a business that actually need this?"
>
>"Are they willing to pay $400/user $20k/CPU above the cost
>of Oracle 9i EE to use it?"
>
>"Are they willing to pay the extra overhead required to maintain it?"
>
>I'm not sure the ROI is there for many of us. Though downtime
>at our business is somewhat expensive, I think that a failover
>system or even standby database will provide adequate coverage
>for us, which is indeed a hot topic here right now, after our Dell
>SAN put us out of business for 36 hours.
>
>RAC wouldn't have helped much there. Niether would a cluster
>for that matter. Standby DB would have been perfect.
>
>This whole push of RAC by Oracle reminds me very much of the
>mlife phone campaign by ATT. Do you really need to take pictures
>with your phone? And what is the point of sending text messages
>to someone elses phone when you could just call them?
>
>ATT needs you to buy this stuff, because they have it for sale.
>
>I see RAC in a similar light. Do you need RAC? Oracle needs
>you to 'need' it, because they need some reason for you to
>spend more money on their product.
>
>Jared
>
>
>
>On Saturday 08 February 2003 21:23, Richard Ji wrote:
>
>
>>To those who are interested in running RAC on Linux.
>>I know we have been talking about RAC on linux lately. This is great news
>>Redhat has made a special developer's edition for their Advanced Server
>>which
>>only costs $60! So we don't have to shell out $699 for a copy of RHAS 2.1
>>to play with RAC.
>>
>>http://www.redhat.com/software/advancedserver/developer/
>>
>>Have fun.
>>
>>Richard Ji
>>
>>
>--
>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: Post, Ethan
> INET: Ethan.Post_at_ps.net
>
>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: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
  INET: mln_at_MiracleAS.dk

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