Re: Real Application Cluster

From: joel garry <joel-garry_at_home.com>
Date: Thu, 8 Dec 2011 09:26:53 -0800 (PST)
Message-ID: <25099e20-bbca-4b2e-99ff-edb11136d4fb_at_18g2000prn.googlegroups.com>



On Dec 7, 9:49 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> I noticed that every DB forum discussing RAC is dealing mostly with the
> installation issues. How to install RAC on this or that. There are very
> few posts about the managing of RAC, yet those issues somehow do not find
> their way into the public light.
> Logic dictates that installing RAC is just the first and less painful
> part of managing RAC. There are many challenges with RAC, most of them
> stemming from the marketing image of RAC which pictures it as just the
> same as one big machine, but assembled from the cheap, off the shelf
> components. Nothing could be further from the truth. Coordinating access
> within a single machine requires inter-process communication using RAM
> access. Coordinating access within a RAC configuration requires inter
> process communication over the network. Network is still two order of
> magnitudes slower, which means that lock manipulation within RAC is two
> orders of magnitude slower.
> There are many advanced tricks for dealing with RAC issues, ranging from
> functional partitioning to materialized views for reporting and
> strategies for reporting, in order to avoid ORA-01555. I noticed very
> flimsy understanding of events like "gc current block 3-way" or "gc cr
> block grant 2-way". RAC is very different from the single instance
> situation and there are many things that Oracle does under the hood, yet
> one rarely sees that stuff discussed. Am I the only one who notices this
> discrepancy? Are all those RAC system functioning flawlessly?
> I wonder what will the advent of NUMA technology do to RAC? NUMA
> technologies like HP Superdome and SGI Altix are still expensive, but the
> new generation of AMD motherboards are getting really cheap and powerful.
>
> --http://mgogala.byethost5.com

It's common to see generalizations like "RAC will magnify existing design problems." I think the installation issues got a lot of press because installation projects are usually short temporary things, and customers expected it to be like, well, the new appliance stuff. Managers would be watching it closely, any little thing going wrong means managerial yelling and escalation and other useless things that don't fix technical problems. Ongoing performance issues often only show up with an increase in load, and are handled by lower level people, at least initially. So you see lots of questions on forums where they ask about ratios, and don't even mention it's RAC. Those types of systems might even have flaws that no one knows about because no one is complaining about the right thing. The only clue might be an obscure AWR statistic, and asking about that just leads to OTD warnings.

Don't forget the logic here is filtered through management and marketing. In reality, the ongoing technical management issues are site-dependent. Some configurations may have been a toss-up in the first place as to whether they need RAC.

jg

--
_at_home.com is bogus.
http://www.computing.co.uk/ctg/news/2130913/rackspace-cto-oracle-sap-starting-panic
Received on Thu Dec 08 2011 - 11:26:53 CST

Original text of this message