DBAsupport.com Forums - Powered by vBulletin
Results 1 to 5 of 5

Thread: Clarification on RAC environments?

  1. #1
    Join Date
    Dec 1999
    Posts
    217

    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.

    Regards,
    Chintz
    Last edited by Chintz; 10-10-2007 at 01:33 PM.

  2. #2
    Join Date
    Sep 2002
    Location
    England
    Posts
    7,334
    might help to say where you read it so it can be put in context

  3. #3
    Quote Originally Posted by Chintz
    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.

    Regards,
    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.

    OR,

    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.

    HTH,

  4. #4
    Join Date
    Mar 2007
    Location
    Ft. Lauderdale, FL
    Posts
    3,555
    Quote Originally Posted by ora11g
    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.
    That's too complicated, are you or work you for a consulting firm?

    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.

  5. #5
    Join Date
    Jun 2000
    Location
    Madrid, Spain
    Posts
    7,447
    Quote Originally Posted by Chintz
    Is this the down side to RAC?

    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.

    Regards,
    Chintz
    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,

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width