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 11g RAC Provisioning Pack tips

Oracle11g Tips by Burleson Consulting

These are work in progress excerpts from the book "Oracle 11g New Features" authored by John Garmany, with Oracle ACE's Steve Karam, Lutz Hartmann, V.J. Jain and Brian Carr.

Oracle RAC is the Cadillac of high-availability utilities, and Oracle 11g has now made it easier to implement a robust Grid solution.

A pragmatic approach to Oracle scalability

While RAC is the obvious choice for high availability, many Oracle professionals misunderstand the best way to plan for fast scalability.  These tips on Oracle scalability note that savvy Oracle shops start with a "scale up" approach, adding computing resources within a large monolithic server, and only using Oracle Grid computing (scale out, a.k.a. horizontal scaling) only after a single server has been saturated. 

In general, the following are competing approaches to scaling:

Scale Up (vertical scaling)

Oracle hardware vendors promise on-demand computing resources, lower TCO, and easy scalability. Their huge servers offer savings from CPU and RAM consolidation, far less human management costs, and seamless allocation of resources.

In the "scale up" approach, server resources (CPU, RAM, Disk) can be added into a single, monolithic server.  Examples include the HP Superdome (64 CPU), the Unisys ES7000 (32 Processors), the Sun Microsystems SunFire and the IBM X Series.  The "scale up" approach has several benefits over horizontal scaling for Oracle databases:

  • RAC is not required
  • Machine resources (especially CPU) are instantly available for sharing
  • A single-server requires less overhead and management

Scale Out (horizontal scaling)

Grid vendors offer solutions where server blades can be added to Oracle as processing demand increases. While Grid computing offers infinite scalability, no central point of failure, and the use of fast cheap server blades, it does have the same in-the-box parallelism that is found within a monolithic server. Unlike the scale up approach, Oracle10g Grid computing is not automatic and requires additional costs, additional training, as well as sophisticated monitoring and management software.

The "scale out" approach is designed for super large Oracle databases that support many thousands of concurrent users. Unless the system has a need to support more than 10,000 transactions per second, it is likely that the system will benefit more from a scale up approach.

In the real world, savvy corporations combine vertical scalability and horizontal scalability. They start with a large vertical architecture server, adding resources as-needed. If continuous availability is also required, they may have a mirrored server using long-distance RAC or Oracle Streams.

When the single server is approaching capacity, they the "scale out" with the horizontal scalability, employing RAC and adding additional servers, each with a vertical scaling architecture.

For these huge shops that rely on on-demand server allocation with Oracle Grid control we see the ability to gen-in new servers on an as-needed basis.  They keep a server farm of ready-to-go servers:

In problem is that a new Grid server must have the software pre-installed before it can be genned-into a RAC cluster or Oracle application server cluster.  Running the Oracle installer is tedious and time-consuming, and Oracle has solved this issue by allowing for instant provisioning of new servers:


Inside 11g Grid provisioning

The Oracle grid control provisioning pack allows you to "blow-out" a RAC node without the time-consuming install, using a pre-installed "footprint". Prior to 11g, the DBA could simply install a binary footprint for the software (which is tar'ed to the server blade), without a cumbersome install process.  The pre-configured footprint is link edited and ready to go, making it easy to deploy new Grid servers.

This paper titled Provisioning RAC and AS using OEM, we see that RAC provisioning has several sub-components:

"Behind the scenes, provisioning a RAC system is a combination of the following technologies:

Cloning of ORACLE_HOME

Cloning of a single instance database

Converting a single instance database to RAC".


Bare Metal and Gold provisioning for Oracle RAC

We see several new terms in the Oracle 11g documentation referring to "gold" and "bare metal" provisioning.  In Oracle jargon, all ?gold images? are pre-installed, tested and approved software images that can be patched to any level before deployment.  We see that "gold images" are a play on words from Linux "bare metal" provisioning:

"On Linux machines the operating system and the agent software can also be deployed using the Bare Metal provisioning process introduced in 10gR2. The Bare Metal provisioning process makes use of the PXE technology to boot a?kickstart image? of the operating system."

This RAC provisioning features started within OEM in 10gr3, and it allows a Grid DBA to add a new RAC node with a single mouse click. Oracle notes that you can provision a new node with just a mouse click, but only after the procedure has been set-up:

"All the complexities of provisioning and configuring the agent, Clusterware, storage, network and the database software are automated and hidden from the end user. One can retire the node entirely or relocate the node with a similar single click effort."

The Oracle 11g clusterware deployment guide notes that only a few steps are required to provision a new server:

0 - Specify the kernel parameters.

1 - Configure block devices for Oracle Clusterware devices.

2 - Ensure you have set the block device permissions correctly.

3 - Use short, nondomain-qualified names for all names in the Hosts file.

4 - Test whether or not the interconnect interfaces are reachable using the ping command.

5 - Verify that the VIP addresses are not active at the start of the cloning process by using the ping command (the ping command of the VIP address must fail).

6 - Run the Cluster Verification Utility (CVU) to verify your hardware and operating system environment.










If you like Oracle tuning, you may enjoy my new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



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 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational