Real Application Cluster
From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Thu, 8 Dec 2011 05:49:41 +0000 (UTC)
Message-ID: <pan.2011.12.08.05.49.41_at_gmail.com>
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.
Date: Thu, 8 Dec 2011 05:49:41 +0000 (UTC)
Message-ID: <pan.2011.12.08.05.49.41_at_gmail.com>
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.comReceived on Wed Dec 07 2011 - 23:49:41 CST