Re: Upgrade Plan
Date: Mon, 19 Jan 2009 09:40:41 +0000 (UTC)
Message-ID: <gl1hqo$539$2_at_solani.org>
On Sun, 18 Jan 2009 11:12:36 -0800, hpuxrac wrote:
> Email me individually and I can give my a phone number.
>
> The topic of to RAC or not really has been nailed by Moans Nogood ( a
> former Oracle employee ) ( he has a real name ) ... try searching for
> moans nogood ( and the words ) why you probably don't need RAC.
>
> He has written and framed the overall picture much better than I could.
> His experience and breadth of knowledge is not to be underestimated.
That was one of the most ground-breaking pieces of writing ever done about RAC. It was a reaction to the fact that Oracle removed all information about functional partitioning from the RAC manuals claiming that it's no longer valid and that RAC can no longer be wrecked by a bad design. Jonathan Lewis also had an article about "wrecking the RAC", toned much less provocatively then the one by Moans but still reaching the same conclusion: RAC is a great improvement over OPS but still susceptible to bad design.
I happen to agree with the fact that a decent SMP machine or even NUMA will beat RAC hands down when using your average home brewed OLTP application. RAC, in my opinion, is primarily an availability option, not a throughput option. In other words, there are reasons for buying a big P595 and no, you can not get a performance of P595 out of sufficient number of DL580's. Even if you manage to stack up sufficient number of DL580's and somehow beat a P595, it will be much costlier then it would have been with the P595.
RAC is a dream come true for the data warehouse developers, but for OLTP, you need to have a very experienced DBA and developers, in order to make things work. Here is the basic issue:
No matter how fast your network is, an access to the local RAM is still several orders of magnitude faster then a network copy. In particular, that means that locking things is much more expensive and it takes much more time when network is involved than it is to lock things locally. The best performance advice for the developers of the RAC applications is "avoid global locks at all costs". That, in particular, includes the vast majority of home-grown OLTP stuff. OLTP does locking and that's an expensive operation when RAC is involved. Unless you partition your application well, there will be nothing but problems for you. The trick in partitioning your application across servers so that global locking is almost never done.
People who know how to manage RAC and how to develop for RAC are quite a bit more expensive then a "generic Java programmer" who does things by using EJB, Hibernate, Tapestry, Maven and WebLogic or JBoss. In the time of crisis and cutting costs everywhere, I doubt that any CIO would like to have several $120k or more priced people on the payroll then he really needs. Enter "DBA 2.0" and you can have a chimp with OEM plus diagnostics and tuning package manage your average Oracle database. That chimp would be tragically lost and unable to accomplish anything with a RAC database.
If bigger and cheaper systems are needed, I would take a very serious look at NUMA servers, like SGI Altix.
-- Mladen Gogala http://mgogala.freehostia.comReceived on Mon Jan 19 2009 - 03:40:41 CST