Database Reference
In-Depth Information
Handling Unplanned Node and Cluster Reboots
Here is a delicate question for your consideration: how do you deal with unplanned server outages? Perhaps you are
using a cold-failover technology from a third-party vendor, a technology such as IBM's HACMP, HP's Serviceguard, or
Veritas' Cluster Server. Although this software provides a solution to handle unplanned outages, you are still required
to have an administration team—composed of either DBAs or operating system administrators—to intervene to
manage the situation. This could mean that it takes a while to complete the failover. Even if you can automate the
process to handle unplanned node outages, how do you deal with the problem of hung and unresponsive databases?
A RAC One Node database requires no DBA or operating system administrator intervention to complete the
activities for recovering from unplanned server outages. RAC One Node automatically performs cold failover without
administrator intervention. If you suspect that a failover has occurred, you can execute the previously mentioned
srvctl status
command to verify the node on which the database is currently active.
Unlike the third-party cold-failover technologies, Oracle RAC One Node is tightly integrated with Oracle
Clusterware and is closely monitored by the cluster. When a node suffers an unplanned outage, Oracle Clusterware
will detect the failure and try to bring the database up on the same server in the first attempt. If the server
is inaccessible for any reason, Oracle Clusterware will automatically relocate the impacted database onto a
predetermined alternate server within the cluster. This is all managed automatically and avoids any DBA intervention.
Figure
14-7
depicts the cluster node reboot scenario in a two-node cluster environment where the RONDB
database automatically fails over from Node A to Node B. As you can see in the following picture, once Node A
became unavailable for some reason, the RONDB_1 instance switched automatically to Node B as RONDB_2, and at
this point in time, Node B had two instances running, namely, RONDB_2 and the other database instance.
Figure 14-7.
The cluster node reboot scenario
Although there is very little application downtime involved, Oracle RAC One Node's ability to manage automatic
restart and relocate the impacted database services onto a survival node puts Oracle RAC One Node technology far
ahead of traditional third-party cold-failover solutions and virtualization solutions.
Converting Between RAC One Node and Standard RAC
With Oracle RAC One Node, you can easily scale out the database to a fully functional, traditional RAC database,
subject to the licensing terms, to meet and serve increased business workload demands. With RAC One Node, these
scaling changes can be made online. No application downtime is needed.
