Clarification on RAC environments?
Is this the down side to RAC?
Oracle RAC has internal complexity that can become overwhelming without expenditure on appropriate resources. While database automation makes sense for single-instance databases, it becomes even more necessary for clustered databases because of their increased complexity.
As with many other database clustering technologies, Oracle RAC can not support a high number of database write transactions when many nodes (typically more than 4) participate in one cluster. The node performing the write-transaction must take ownership of the relevant area of the database. Typically this involves a request across the cluster interconnection (local IP network) to transfer the data block ownership from another node to the one wishing to do the write. This takes a relatively long time (tens to hundreds of milliseconds) compared to single database node using memory operations. Conversely, high read-transactional databases (such as data warehousing applications) work very well under RAC, as no need for ownership-transfer exists.
Last edited by Chintz; 10-10-2007 at 01:33 PM.
might help to say where you read it so it can be put in context
Originally Posted by Chintz
On top of my head, The Inerconnect performance of RAC depends on
(1) How many Indexes are created on a table
(2) the SEQUENCES if used to populate the indexed colummns are CACHED or not.
(3) table under question is partitioned o NOT. HASH Partition improves the cluter interconnect performace.
(4) Nic teaming/Bonding is used ot not.
(5) Jumbo frames are used or not.
...and may be more.
There is always a way to improve Database performance.
Simply diverting the writes on a only one node in RAC and have rest of the nodes for READ purposes only. In this solution, You may need to have higer cores/memory on write node as all the writes are coming to this one.
That's too complicated, are you or work you for a consulting firm?
Originally Posted by ora11g
Let me break the news for you.
Interconnect performance depends on DB Block size and the quality of the application, as simple as that.
If you have a poorly written application -kinda 90% of the cases- you are gonna see a lot of chatter on the interconnect which, will hurt your performance.
If you have a larger than needed DB Block size you are gonna be moving more data than needed over the interconnect which, will hurt your performance.
Anything else you can think about will just attempt to minimize these two flaws.
Pablo (Paul) Berzukov
Author of Understanding Database Administration
available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Not sure where did you get the four node note from but blocks in RAC does not travel more than three ways no matter the number of nodes,
Originally Posted by Chintz
Latency in a interconnect is typically between 3 to 10 milliseconds and not hundreds or thousands! If you are concerned with interconnect ever heard of Infiniband? The latency is in microseconds.
Obviously there are other mechanism to minimize blocks travelling, node affinity, ASSM etc.
Last edited by pando; 10-12-2007 at 07:45 AM.
Click Here to Expand Forum to Full Width