About Oracle 11gR2 RAC One Node and RAC Patching

RAC One Node represents an Oracle RAC database that runs only one active Oracle database and can be managed using Server Control Utility (SVRCTL) as any Oracle RAC database. You can add nodes that can be used for failover, but you cannot add additional instances without first converting Oracle RAC One Node to Oracle RAC. You can convert from single instance to RAC One Node or RAC using Oracle’s Database Configuration Assistant (DBCA) at any time. The RAC One Node database can give you the High-Availability (HA) benefits of failover protection.

Oracle uses Online Database Relocation using SVRCTL, which you can use to perform a live migration of database instances and connections to the other available cluster nodes. Please see the documentation for full details and use.

Another benefit is if a node becomes overloaded, you can move the database to another node in the cluster using the simple relocation command listed here (rac10 is the unique name for this database and node17 is the target node; see documentation before using this and ensure you test things fully):

 

 

Consider a RAC One Node use case. Let’s say you’re consolidating many small to medium databases into a smaller number (N) of servers. While these databases may be mission-critical, they are small and can comfortably run on a single node. So they don’t need the scalability of RAC, but they do need the High Availability (HA) and flexibility that RAC provides. You can create a cluster of N or N+1 servers. You then create as many single-node RAC databases on the servers as you need (in this case, N of them). You can also use the new 11.2 instance caging, which limits the number of cores that each database can utilize on a server. Here are some use cases for RAC One Node:

• Failover If a server fails, use cluster failover to switch to an idle server in the cluster (your N+1 server or one of the extra ones). This server is like a spare disk, but instead, it’s a spare node.
• Live migration If a server needs maintenance, temporarily add a second node to the RAC database during the high-use timeframe. While the application is live, move the users via standard load balancing to the second node. Then shut down (transactional) the first node to move over the remaining users. Do your maintenance, and then perform the same procedure in reverse to move the users back to the first node if desired.
• Rolling upgrade If you want to upgrade your database software, temporarily add a second node to the RAC cluster that already has the new version of the database software. Then move users to the second node using live migration and upgrade the first node using RAC rolling upgrade. Move users back to first node if desired.
• Scale out If your database load grows beyond one server, add a node and run full RAC (of course, then and only then, you must license RAC).

On the application side, the 11gR2 release has a new feature called Edition-based Redefinition. This is a huge feature that allows developers to implement online upgrades for their applications (think Siebel 8.0 to 8.1 upgrade). Oracle uses private editions (for the developers) of the application, which can be published when developers are fully ready. See the documentation for more information on these features, but for availability, they are both huge!

Lastly, Oracle Database 11gR2 Real Application Clusters has been improved to offer zero downtime patching. The patching of Oracle Clusterware and Oracle Real Application Clusters can now be accomplished without taking the cluster down. This improvement is huge for overall database availability and offering further capability for keeping critical database environments up to date.