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

 

 


 

 

 

        
 

 Scalability in a Oracle RAC Multi-Node Environment
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.

Scalability

There are two ways to scale hardware: vertically and horizontally.  Vertical scaling means to build up.  Add CPUs, RAM, and such until the system is full.  To visualize scaling vertically, think of Manhattan.  There is no more room on the horizontal plane.  There is no room to build new buildings.  However, adding new stories to existing buildings is possible.  This is scaling up.

 

Scaling horizontally is the practice of adding new systems to the cluster.  In an area with ample open land, when new developments are needed, building taller buildings is unnecessary.  Building out is more practical, scaling upon the horizontal plane.

 

Oracle, vendors, and consultants may mention that RAC is good because of the price.  At first glance, it seems expensive because of the added cost per CPU on top of what is already being paid for Oracle.  However, it can actually decrease costs by decreasing hardware requirements.

 

RAC allows the use of multiple low cost machines together in order to provide the same capability of a single large system with the added benefit of high availability.  For instance, four 16-CPU systems instead of a single 64-CPU server could be used.  Now new servers can be added as needed.

 

In addition, a single system may have underutilized resources.  If the system is waiting on a RAM resource, but the CPUs are at only 50% capacity, half of the CPUs are wasted.  In a RAC environment, every server can be utilized to the max.  The concurrent processes will be balanced across all the nodes of the cluster, and will therefore have a better chance to use otherwise unclaimed resources.

 

The addition of an instance creates the opportunity to support a larger number of concurrent users. Any instance introduced into the RAC system opens up new memory buffers and permits more user connections without affecting the performance of the other instances.

 

A RAC database system provides excellent scalability options for the users. As the need arises, DBAs can expand or add the number of nodes in the cluster. This enhances the total database engine computing power when the need for high performance arises. With the additional nodes and instances in the database cluster, the system is able to accommodate demands. Consider the following statements:

  • If the application will scale by adding RAM and CPUs, it should scale on RAC.

  • If the application will not scale by adding RAM and CPUs, it typically will not scale on RAC.

  • RAC can expose application design issues that were not exposed on a single instance non-RAC system.

  • A poorly designed application could work fine on a non-RAC single instance but might not work very well on RAC.

When one thinks about database scalability on RAC, one needs to visualize the data blocks.  Constantly having to ship a large number of the same data blocks back and forth via cache fusion may not be scalable.

 

Bert Scalzo, Ph.D has a great document online called “RAC Be Nimble RAC Be Quick.”  The image below originates from his document.  Remember, the application should be built so that an instance can run full throttle without worrying what the other instances are doing.  Oracle RAC can provide near linear scalability.

 

Figure 7.2: Multi-node Capability of RAC (Source:  Bert Scalzo

     

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.