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 







RAC One Node tips

IT Tips by Donald BurlesonSeptember 6,  2015

Traditionally, Oracle RAC is used in a multi-node architecture, with many separate instances of RAC residing on separate servers.  This protects against unplanned server outages because transparent application failover will re-direct to another server, and also aids the RAC goal of scalability, when a new server instance is genned-in to the RAC cluster.

Now in Oracle 11g r2, we see a new feature dubbed "RAC One Node".  RAC One Node claims to be a multiple instances of RAC running on a single node in a cluster, and has a fast "instance relocation" feature in cases of catastrophic server failure.

Both RAC and RAC One Node protect against server and hardware failure (except disk failure), but they do it in different ways:

- RAC failover:  RAC uses multiple servers (nodes) and the tnsnames.ora file directs failover to a surviving server when a node crashes.

- RAC One Node failover:  RAC One Node uses "instance relocation", and when an instance fails, RAC One Node re-starts a failed instance on another node, by re-mounting the disk on the new server and using the pfile/spfile to re-start the instance.

This instance relocation uses a new featured dubbed Oracle Omotion.

While RAC One node will not protect you in a case of server failure (unlike regular RAC, running nodes on many servers), RAC One Node does offer instance duplication within a single server environment.

Oracle Corporation is now embracing the IT industry concept of "instance consolidation", a movement to collected together instances from the bad old days of client server computing where we had a one instance/one server architecture.  This is a Back to the Future approach, a movement back to the monolithic server environments of the 1980's, with all of their benefits:

  • Centralized patching and software maintenance.

  • Redundant instances mean zero outages during patches and upgrades.

  • On-demand RAM and CPU sharing within the single large server.

  • Less Oracle DBA resources required to manage dozens of instances.

See my notes here on Oracle server consolidation and the 2nd age of mainframe computing.

RAC One Node and VMware

Oracle says that RAC One Node is useful in VMware environments.  For details on using Oracle on VMware see, the book "Oracle on VMware: expert tips for Oracle virtualization" by Bert Scalzo.

"Using Oracle RAC or Oracle RAC One Node with Oracle VM increases the benefit of Oracle VM with the high availability and scalability of Oracle RAC.

If your VM is sized too small, you can migrate the Oracle RAC One instance to another larger Oracle VM node in the cluster (using Omotion) or move the Oracle RAC One instance to another Oracle VM node, and then resize the Oracle VM.

When you move the Oracle RAC One Node instance to the newly resized Oracle VM node, you can dynamically increase any limits programmed with Resource Manger Instance Caging."

Fast Recovery vs. Continuous availability

In RAC we achieve continuous availability because that is little or no latency as TAF redirects transactions to surviving server when a server crashes or a node become unavailable.  What makes Oracle RAC One Node special is that it performs quick clone of the instance to a new node:

"If the node fails, Oracle Clusterware will automatically restart the Oracle RAC One Node instance on another server in the cluster."

This is a similar approach to instance relocation that was first introduced by Savantis Systems with their DB-Switch invention, an offshoot of the Database Area Network (DAN) approach.

Instance relocation for Oracle using Omotion

To understand how RAC One Node might do a fast instance relocation, lets examine similar offerings by 3rd party vendors.  Savantis Systems uses a high-speed database switch (dbSwitch™) which is placed between the application layer and the database layer.

This database switch enables Oracle databases to be transparently relocated onto new servers without the need to modify applications connections to the database. The database servers, in turn, are connected to a shared storage such as SAN, such that database files can be quickly remapped onto a different server.

In Oracle RAC One Node, it appears that the Omotion software component uses VMware for the high speed instance relocation.  See here for details on how Oracle instance relocation works using DAN and SAN technology. 

        Virtualization allows for instance relocation between servers

Here is how instance relocation worked in earlier offerings by 3rd parties.  Using IP address masks enables virtualization of database addresses. To the database clients, each database is identified by a unique virtual IP address (VIP). These VIPs are not defined on any specific machine on the network, and are routable by the dbSwitch™ using Network Address Translation (NAT). This allows the Database Area Network to move Oracle instances without affecting the application server layer.

The Database Area Network (DAN) architecture.

The internal mechanism in Omotion for fast Oracle instance relocation may be quite complex, but the idea is simple. In the olden days, we did this with a SAN environment, using the following steps:

1. The Oracle instance or the server crashes.

2. A dead connection probe (DCD) detects the outage and we un-mount the SAN data file systems from the source server (if it's awake).

3. We then mount the database files onto the failover server using SAN.

4. We re-start the instance on the new server, using a pre-loaded init.ora file.

5 We use a failover routing mechanism like transparent application failover (TAF) to redirect transactions accessing the database (VIP) to the new server.

A typical time for an Oracle instance relocation is less than 20 seconds, not true continuous availability, but certainly better than a catastrophic unplanned outage.

Again, Oracle has not published the internal machinations of their instance relocation strategy, but it's a safe bet that it happens very quickly over SAN storage.


Oracle RAC One Node Utilities

Oracle RAC One Node introduces several new utilities:

  • Oracle Database Resource Manager Instance Caging - The new instance caging features is part of the database resource manager in RAC One Node, a tool to allocate server resources to multiple instances running on the same server.

  • Omotion online migration utility - This is a new RAC One Node utility that allows for a RAC instance to be quickly "lifted" and copied to a new server node.

In sum, Oracle RAC One Node is a solution aimed at smaller shops and systems that need fast failover, not not necessarily 100% continuous availability.  Oracle RAC One Node also buys in to the industry-wide server consolidation movement, whereby instances are consolidated for better quality management and resource sharing. 

The hardware industry is also embracing this "scale up" approach by providing servers with lots of slots for future expansion.  For example, the Sun Fire X4640 Server, allows from 12 to 48 processors and up to 512 gig RAM, allowing the DBA to add server resources just-in-time to meet increases in processing demands.

Oracle Grid and Real Application Clusters

See working examples of Oracle Grid and RAC in the book Oracle Grid and Real Application Clusters.

Order directly from Rampant and save 30%. 



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.