Re: Real Application Cluster
From: Mark D Powell <Mark.Powell2_at_hp.com>
Date: Thu, 8 Dec 2011 05:49:54 -0800 (PST)
Message-ID: <84f8f3e8-d77a-49c3-a7e9-42efc3fc0e3b_at_f11g2000yql.googlegroups.com>
On Dec 8, 12:49 am, 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
Date: Thu, 8 Dec 2011 05:49:54 -0800 (PST)
Message-ID: <84f8f3e8-d77a-49c3-a7e9-42efc3fc0e3b_at_f11g2000yql.googlegroups.com>
On Dec 8, 12:49 am, 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
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 -- Received on Thu Dec 08 2011 - 07:49:54 CST