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.

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 Dr. 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 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.