1. RAC One Node – The “Always On” Single Instance Database
Hello and welcome to the RAC ONE Node overview webcast. Over the next few minutes, we’ll introduce you to this new database option, RAC One Node, and identify some of key customer situations where RAC One Node would be a successful solution.
RAC One Node – The “Always On” Single Instance Database

2. RAC One Node The “Always On” Single Instance Database
New in 11.2
RAC One Node The “Always On” Single Instance Database
Always On Single Instance Database
Online replacement of servers and storage
Online patching and upgrades of operating system and infrastructure software
Online database patching
Automated cluster failover
Better consolidation
Extreme consolidation of servers & storage
Load balancing to protect service levels
Enhanced virtualization
Extends and improves database availability and flexibility when running in a virtual server
RAC One Node provides 3 key benefits that map to sales opportunities. The first is always on high availability—protection from both planned and unplanned outages. The second is better consolidation—more efficient consolidation than you get with simple server virtualization. And lastly, when used in a server virtualization environment, it provides for enhanced virtualization—improving on the availability characteristics of the database running in a virtual machine.

3. RAC One Node Database Option primarily targets the failover market
Option to Oracle Database 11g Release 2 Enterprise Edition
$10,000 per processor
Eligible for list-to-list upgrade credit when upgrading to full RAC
All nodes on which RAC One Node is installed must be licensed for RAC One Node
Exception: One spare node for cold failover/Online Database Relocation need not be licensed under the 10-day use rule
Example: In a two-node cluster, customers can license RAC One Node on ONE node; 10-day rule applies for spare node
RAC One Node capabilities also bundled with RAC
Oracle Real Application Clusters One Node
High Availability Database Essentials
Oracle Database 11g Enterprise Editon
Database
Oracle Grid Infrastructure
Cluster and Storage Management 3 3 3 3

4. RAC One Node deployment
Key Attributes:
Instance Caging
Single Cluster
Shared storage
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
OK, let’s look at a typical RAC One Node deployment. In this case, we have a single cluster with 3 servers, server A, B and C. Notice that each server can host one or more databases—in this case server A hosts databases 1 and 2, server B hosts database 3, and server C hosts databases 4 and 5. All servers share a common pool of storage, which provides access to all database files from any server in the cluster.
Common Shared Storage
Single Cluster

5. RAC One Node deployment Instance Caging
Key Attributes:
Instance Caging
Single Cluster
Shared storage
Server A
Server B
Server C
DB1
DB2
DB1
DB2
DB3
DB4
DB5
In the past, some customers have been reluctant to running multiple databases on a single server for fear one database could consume all the resources and starve out the other databases. In Oracle Database 11g Release 2, we introduce a new feature called Instance Caging that addresses that concern. Instance Caging limits the cpu resources that anyone database can consume, preventing one database from starving out others.
Common Shared Storage
5 core limit
3 core limit
Single Cluster

6. Online Database Relocation
Client Connections
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
Now let’s look at Online Database Relocation, a key feature that enables much of the value RAC One Node provides. It allows a customer to move a running database from one server to another, without downtime. In this example, imagine that Server A is heavily loaded. To free up resources for database 1, we are going to migrate database 2 to another server that has headroom—in this case server B. We will leverage the capability of RAC to concurrently run multiple instances of a single database, and…
Common Shared Storage
Single Cluster

7. Online Database Relocation
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Start a second instance of database 2 on server B…
Common Shared Storage
Single Cluster

8. Online Database Relocation
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Then, by relocating the services clients are using to connect from server A to server B, we cause connections to be gracefully migrated, as they are returned to the pool…
Common Shared Storage
Single Cluster

9. Online Database Relocation
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Eventually, all connections are migrated, and…
Common Shared Storage
Single Cluster

10. Online Database Relocation
Client Connections
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
We can shutdown the instance running on server A. At this point, we have migrated database 2 from server A to server B while the database was online and performing work.
I’ve just described a load balancing use case for Online Database Relocation, but we can do much more. Had we moved both database 1 and 2 off server A, we could then shutdown that server for maintenance, perhaps for an OS upgrade or patch.
Common Shared Storage
Single Cluster

11. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
Also, since we actually migrated from one database instance to another, we’ve left behind the binaries, or Oracle Home, that was used by the old instance on server A.
Database Binaries
Common Shared Storage
Single Cluster

12. Online Rolling Patches
Client Connections
Server A
Server B
Server C
Patch
DB1
DB2
DB3
DB4
DB5
We can apply a patch to that DB Home. Similarly, if there was nothing else running on Server A, we could upgrade or patch the Operating System and cycle the server.
Database Binaries
Common Shared Storage
Single Cluster

13. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
Patched Database Binaries
Now we have a patched DB home. Since RAC supports instances running at different patch levels for the purposes of performing a rolling patch, we can now migrate database 2 back to Server A from Server B – all without taking an outage.
Common Shared Storage
Single Cluster

14. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Patched Database Binaries
Again, we invoke online database relocation, db2 goes into “active-active” mode and connections are migrated back to Server A.
Common Shared Storage
Single Cluster

15. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Patched Database Binaries
Common Shared Storage
Single Cluster

16. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB2
DB3
DB4
DB5
Patched Database Binaries
Once the connections have migrated or 30 minutes (or some shorter time interval the user selects) elapses, the database instance on Server B is shut down.
Common Shared Storage
Single Cluster

17. Online Rolling Patches
Client Connections
Server A
Server B
Server C
DB1
DB2
DB3
DB4
DB5
Patched Database Binaries
Now we are back to a single instance database that has just gone through a db patch – all without taking an outage and all done with minimal dba involvement.
Common Shared Storage
Single Cluster

18. Cluster Failover DB1 DB2 DB3 DB4 Server A Server B Server C
Of course, it’s just as important to avoid unplanned outages as it is to avoid planned outages. RAC One Node automatically monitors the health of the servers and databases, and if there is a failure, it restarts or fails over the affected databases.
Common Shared Storage
Single Cluster

19. Cluster Failover DB1 DB2 DB3 DB4 Server A Server B Server C
Server B suffers an outage – could be anything – hardware failure, software failure etc.
Common Shared Storage
Single Cluster

20. Cluster Failover DB1 DB2 DB3 DB4 Server A Server B Server C
Key Capabilities:
Database failover
Fast storage failover
Server A
Server B
Server C
DB1
DB2
DB3
DB4
RAC One Node, which is based upon and relies upon Oracle Clusterware, would detect that database failure. It would first try to restart the DB on that server and after that was not successful, would restart that database on another pre-determined server within the cluster. All of this happens automatically and without the DBA or sys admin having to be directly involved or even aware that this is occurring.
Common Shared Storage
Single Cluster

21. Create RAC One Node Database with DBCA

22. RAC One Node Demo… Workload RACOne Server dadzaa07 Server dadzaa08
Common Shared Storage
Single Cluster

23. Demo

24. Summary – RAC One Node The “Always On” Single Instance Database
New in 11.2
Summary – RAC One Node The “Always On” Single Instance Database
Always On Single Instance Database
Online replacement of servers and storage
Online patching and upgrades of operating system and infrastructure software
Online database patching
Automated cluster failover
Better consolidation
Extreme consolidation of servers & storage
Load balancing to protect service levels
Enhanced virtualization
Extends and improves database availability and flexibility when running in a virtual server

25. 25