Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation







 Oracle 11g Benefits of Real Application Clusters (RAC)
Oracle Tips by Burleson Consulting

Oracle 11g Grid & Real Application Clusters by Rampant TechPress is written by four of the top Oracle database experts (Steve Karam, Bryan Jones, Mike Ault and Madhu Tumma).  The following is an excerpt from the book.

Benefits of Real Application Clusters (RAC)

The benefits of Real Application Clusters:

  • Ability to spread CPU load across multiple servers

  • Continuous Availability / High Availability (HA)

- Protection from single instance failures

- Protection from single server failures

  • RAC can take advantage of larger SGA sizes than can be accommodated by a single instance commodity server

  • Scalability

There are cases where RAC may not be an appropriate option:

  • If RAC is being used as a cost savings solution, be sure to analyze both hardware and software costs

  • Do not expect RAC to scale if the application will not scale on SMP

  • Be realistic about the latency difference between local only memory-cache instance communication and inter-node network based multi-instance Cache Fusion communication

RAC is not always the best option

Solutions such as RAC are not always the best option.  If high performance is the only requirement and the single server can consistently deliver the necessary power needed, then a single instance server may be the best choice.  If High Availability (HA) is the only requirement, and less complex solutions such as Data Guard are adequate, then Data Guard without RAC might be the best choice.

RAC Evolution

Evolution from OPS

The biggest performance robber in the OPS architecture was the DB block ping. A DB block ping would occur when an instance participating in an OPS database had a block in its cache required by another participating instance. In OPS, if another instance required the block in the cache of a second instance, the block would have to be written out to disk, the locks transferred, and then the block re-read into the requesting instance.


Oracle 8i OPS implementation brought in many significant changes. The significant new feature was the introduction of cache fusion technology. Cache fusion, as examined earlier, is a concept where cache, or SGA, from the multiple instances coordinates the buffers and manages the database access.


Oracle 8i (OPS) introduced the initial phase of cache fusion. The data blocks were transferred from the SGA of one instance to the SGA of another instance without the need to write the blocks to disk. This was aimed at reducing the ping overhead of data blocks. However, the partial implementation of cache fusion in Oracle 8i could help only in certain conditions.


Remote DBA Service

Oracle Tuning Book


Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software










BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.