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

On Dec 8, 12:49*am, Mladen Gogala <gogala.mla... (AT) gmail (DOT) com> wrote:
We ran OPS on Sequenct NUMA boxes without any more issues that we have
faced on prior SMP hardware.

We have not found any additional tricks being necessary to avoid
ORA-01555 errors.


HTH -- Mark D Powell --

On Dec 7, 9:49*pm, Mladen Gogala <gogala.mla... (AT) gmail (DOT) com> wrote:
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
--
@home.com is bogus.
http://www.computing.co.uk/ctg/news/...starting-panic

On Dec 9, 4:26*am, joel garry <joel-ga... (AT) home (DOT) com> wrote:

Well, how about a simple question: do you really need RAC?
Moans asked it quite a few years ago, but afaik few actually provided
an answer.

I'm continually told by the "experts" that I need to have RAC in my
DW.
Our DW had 0 (that is Z-E-R-O!) unscheduled downtime in the last 3
years.
Scheduled outages, two were for Oracle patches that needed to be
installed (20 minutes in total) and one was for an Aix upgrade and
patching of our Power6 box - the whole system, not just the DW lpars
(half a day).
Our DW does 8TB of I/O per day - that's 100MB/s continuous sustained
24/7, in case maths fail anyone - so it's most definitely not a toy
setup.

Now, I know that a bank here in NSW has installed a monster RAC system
at a cost of hundreds of millions and since then had at least three
unscheduled outages that were publicly reported, let alone all the
niggly patching they had to go through to get the blessed thing
working.

I kinda think that three scheduled outages in 3 years and 0 (zero)
unscheduled beats all that RAC paraphernalia any day, at orders of
magnitude lesser cost. But who am I to claim such? Heck: I'm not
even an "ace" - and will never be one! - so what credibility do I
have?


Amen!

On Thu, 08 Dec 2011 05:49:54 -0800, Mark D Powell wrote:

The question is not whether it's possible to run RAC on NUMA, the
question is why would you do it. Modern NUMA machines behave like very
large SMP boxes, for all intents and purposes, while providing the
failure resistance and redundancy of a RAC configuration. In other words,
RAC is not necessary with NUMA. NUMA machines are assembled in Lego like
fashion, just like clusters, only the nature of the connection is
different.
This is also a "fashion problem", not just Oracle's direction. There are
other technologies, like Hadoop, that have also adopted the same cluster
approach, just like Oracle. The early NUMA systems, like the one you have
been working with, probably Sequent or Pyramid Nile, have existed for a
number of years, alongside with the early parallel "maspar" machines like
nCube or the Connection Machine. Those early MP machines have evolved
into modern cluster systems while Sequent and Nile machines have evolved
into the second generation of NUMA, like the HP SuperDome or SGI Altix.
These are still prohibitively expensive but modern AMD chips are coming
with NUMA primitives for accessing "remote" memory, the one attached to
another CPU, with only around 10% of speed penalty. For some reason
beyond my understanding, server manufacturers like Dell, HP or IBM are
not mass producing and selling cheapo NUMA boxes, but I don't think that
we will have to wait very long time before they start doing just that.
When that happens, the old article by Moans Nogood will be even more
relevant than today.
The things that RAC excels at are fault tolerance redundancy and scale
ability, at a price of $10k/CPU thread. NUMA architecture can give you
those same benefits, so my question is fairly logical. Unfortunately, the
large NUMA boxes are much more expensive than $10k/CPU thread, so there
isn't much competition yet, but I do believe that a clash is inevitable.
Oracle must be aware of it because the latest SUN "supercluster" machine
is a NUMA machine which can accommodate up to 128 CPU sockets..

PS:
---
I was exaggerating when I said that I have no clue why are cheap NUMA
systems not being mass produced. At present stage, those systems still
need a massive central "directory", sort of global page tables, which
must be extremely fast, partially associative and have rather large
capacity, which is still expensive. So called commodity NUMA
implementations, based on BIOS extensions and modern AMD/Intel chips
cannot deliver fault tolerance and scalability, it's just a method of
making cheapo SMP boxes, without an expensive crossbar switch buss design.

--
http://mgogala.byethost5.com

Joel:

# Some configurations may have been a toss-up in the first place as to
whether they need RAC.

Joel this is not like you to be so understated ...

Words like "some" "may have been" "whether they need RAC" ...

What is the average reliability and/or uptime of a modern server
running linux or solaris? Pretty dang high probably 99.99 something.

You start adding RAC into the configuration equation and your uptime
usually goes down.

It takes a deep and talented staff that are highly available to keep a
RAC system running when odd incidents start popping up.

On Dec 9, 2:43*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:

I would state that RAC is more for availability and [ONLY] if the app
is written correctly, scalability . Scalability is not linear,
especially when using a certain vendors SAN equipment. Could have
been some configuration, but was not a real fan of that vendor any
way... I have seen many cases where going RAC actually made things
worse - primarily due to poor application AND database logical design
issues. Amazing how many development teams allow the developers to
create the schema - and they most frequently botch the normalization
(either too much (4th-5th) normal form or not enough - as in none)...