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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Create RAC One Node Database with DBCA

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

Demo

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