Database Reference
In-Depth Information
You also can use the SRVCTL command to manage each individual resource. For example, to check the RAC
database status:
grid@k2r720n1 ~]$ srvctl status database -d khdb
Instance khdb1 is running on node k2r720n1
Instance khdb2 is running on node k2r720n2
Oracle Clusterware requires shared storage to store its two components: voting disk for node membership
and Oracle Clusterware Registry (OCR) for cluster configuration information. The private interconnect network is
required between the cluster nodes to carry the network heartbeat; among them, Oracle Clusterware consists of
several process components which provide event monitoring, high availability features, process monitoring, and
group membership of the cluster. In Chapter 2, we discuss more details of these components, including the process
structure of the Clusterware and OCR and voting disks, best practices for managing Clusterware, and related
troubleshooting methods.
Another component of the Oracle Grid Infrastructure is Oracle ASM, which is installed at the same time into
the same Oracle home directory as Oracle Clusterware. Oracle ASM provides the cluster-aware shared storage and
volume manager for RAC database files. It also provides shared storage for OCR and voting disks. Chapter 5 discusses
the Oracle ASM architecture and management practices.
Oracle RAC: Cache Fusion
Oracle RAC is an option that you can select during Oracle database software installation. Oracle RAC and Oracle Grid
Infrastructure together make it possible to run a multiple-node RAC database. Like the single-node database, each
RAC database instance has memory structure such as buffer cache, shared pool, and so on. It uses the buffer cache in
a way that is a little different from a single instance. For a single instance, the server process first tries to read the data
block from the buffer cache. If the data block is not in the buffer cache, the server process will do the physical I/O to
get the database block from the disks.
For a multi-node RAC database instance, the server process reads the data block from an instance's buffer cache,
which has the latest copy of the block. This buffer cache can be on the local instance or a remote instance. If it is on a
remote instance, the data block needs to be transferred from the remote instance through the high-speed interconnect.
If the data block is not in any instance's buffer cache, the server process needs to do the physical read from the disks to
the local cache. The instance updates the data block in the buffer cache and then the DBwriter writes the updated dirty
blocks to the disk in a batch during the checkpoint or when the instance needs to get free buffer cache slots.
However, in Oracle RAC, multiple database instances are actively performing read and write operations on the
same database, and these instances can access the same piece of data at the same time. To provide cache coherency
among all the cluster nodes, the writer operation is serialized across all the cluster nodes so that at any moment,
for any piece of data, there is only one writer. This is because if each instance acted on its own for the read and
update operations on its own buffer cache, and the dirty block wrote to the disk without coordination and proper
management among the RAC instances, these instances might access and modify the same data blocks independently
and end up by overwriting each others' updates, which would cause data corruption.
In Oracle RAC, this coordination relies on communication among RAC instances using the high-speed
interconnect. This interconnect is based on a redundant private network which is dedicated to communication
between the RAC nodes. Oracle Clusterware manages and monitors this private interconnect using the cluster
heartbeat between the RAC nodes to detect possible communication problems.
If any RAC node fails to get the heartbeat response from another RAC node within a predefined time threshold
(by default 30 seconds), Oracle Clusterware determines that there is a problem on the interconnect between these
two RAC nodes, and therefore the coordination between the RAC instances on these two RAC nodes may fail and
a possible split-brain condition may occur in the cluster. As a result, Clusterware will trigger a node eviction event
to reboot one of the RAC nodes, thus preventing the RAC instance from doing any independent disk I/O without
coordinating with another RAC instance on another RAC node. This methodology is called I/O fencing.
