Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 






  Oracle Tips by Burleson

10g Grid Computing with RAC
Real Application Cluster Architecture

RAC Database Nodes

The next main component is the host or node where the database instance resides. This is the place where data-actual database processing takes place. RAC Database system provides scalability and high availability. In order to provide large database computing power and maintain large workload, you need to extend the number of nodes. Most cluster frameworks today differ in terms of the maximum number of nodes they can handle. Most can support a minimum of 4 nodes today, and some can support hundreds. This will also be driven by your scalability objectives and capacity requirements.

The nodes themselves may or may not need to be scalable to provide additional capacity in terms of CPU or memory. Unless one uses an expensive SMP server, scalability will be an issue. The ability to scale both within a machine as well as across machines is often desirable.

Oracle RAC can be implemented on a wide range of servers from a clustered group of single CPU Windows boxes to a cluster of 32-CPU SUN E10000 boxes. One of the more promising architectures for RAC is blade architecture.

In blade architecture, the servers are inserted into a pre-configured RAC similar to NIM (Nuclear Instrumentation Modules) in a NIM bin. Rather than a horizontal orientation, they have a vertical one. Blade servers are essentially self-contained servers that rest on a single backplane. The backplane in a blade array provides power, network, and management connections, reducing cabling and overall component expense. Many blade architectures are hot-pluggable, allowing online addition and removal of servers from the cluster.

Linux machines are now able to scale up to 8 CPUs, but the majority of systems are 2 or 4 CPU nodes. SMP scalability in Linux beyond 4 CPU’s is not well proven, so the current Oracle recommendation is to stick with 4-CPU machines. The Blade Servers provide low cost 4-way or 2-way servers for building the large cluster environment.

At the same time, Oracle RAC can also run on platforms that allow sub-setting of CPUs, such as the SUN E10000, E15000, and the HP Superdome. In the case of CPU sub-setting, the single server is divided into multiple nodes, each running an instance of Oracle9i RAC.

Server Redundancy

The database resides within a server. The server or host is an important component in the provision of the data service. Any failure in the host system causes the database to go down.

Clustered servers utilize two or more nodes, essentially keeping the extra nodes as standby or sometimes as extra computing power, as in the case of the RAC system. With the help of the additional nodes, we ensure that the standby node can provide the same database service to the user community. However, when in standby, it loses the performance and scalability level for which it is intended.

Clustering servers assures the administrators and the application users that at least one node is alive. A cluster, in its most general form, comprises two or more interconnected computers that are viewed and used as a single, unified computing resource. By using multiple systems, the impact of the failure of any individual system is kept low by passing the failed system’s workload to the remaining members of the cluster.

The standby node becomes functional, or becomes the primary host, when the failed host is unable to provide any host services. When some of the internal components fail and the failure is non-recoverable without intervention, the server is declared not available or simply ‘failed’. This indicates that there is a lot of scope for keeping the internal components safe or redundant.

Before losing the server and resorting to the use of the clustered backup node, there are many things we can do to keep the components from failing. Let us examine these methods, which act as the first level of redundancy. Some people call it ‘high availability without clustering’. In contrast to clustering, system availability can be improved without adding additional servers.

Redundancy Features

There are many features or options that add value to the redundancy at the server level. Taking advantage of such features helps avoid failures, and avoids degraded cluster performance in systems like the RAC system. These features address different subsystems of the server, such as the memory and processors. Redundant components such as fans, power supplies, and adapters can also provide higher availability, particularly when used with software that provides monitoring and alerting capability to the system administrators.

To make the servers more reliable, we should use high-reliability components and best-system practices.

The above text is an excerpt from:

Oracle 10g Grid & Real Application Clusters
Oracle 10g Grid Computing with RAC
ISBN 0-9744355-4-6

by Mike Ault, Madhu Tumma


Remote DBA Services

Burleson Consulting can offer world-class remote Oracle database support at super-affordable prices.

Our remote Oracle DBA service provides 100% of the remote Oracle database administration needs for your company, and includes 24x7 access to our staff of 100% OCP Certified Oracle DBAs. 

We require a 12 month service commitment and include the following services:

  • Initial configuration review and problem identification
  • Installation of Oracle statistics collection mechanisms and quarterly database growth summaries
  • Hourly monitoring of your Oracle database for pending problems
  • Periodic performance analysis & identification of tuning activities
  • Twenty Four hour Oracle emergency support
  • Reporting and resolving all serious Oracle alert log messages
  • Free use of the BC TablePack, ServerPack and AuditPack services
  • Quick response emergency support for production database outages
  • Four hours of free remote DBA support every month. You can use these free hours for any DBA activity, including database analysis, system design, production migrations or personal mentoring.

For more information, please visit or email

Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.