Database Reference
In-Depth Information
to implement the rolling database upgrade between the primary database and standby database and thus reduce
database upgrade downtime. In this case, the database can be either a RAC or a non-RAC single-node database. Refer
to MOS note ID 949322.1 for a detailed configuration of this method.
Oracle RAC One Node to Achieve HA
Oracle RAC One Node is a single-node RAC database. It provides an alternative way to protect the database against
both unplanned and planned downtime. Unlike Oracle RAC Database with multiple database instances to provide an
active-active cluster database solution, Oracle RAC One Node database is an active-passive cluster database. At any
given time, only one database instance is running on one node of the cluster for the database. The database instance
will be failed over to another node in the cluster in case of failure of the RAC node. This database instance can also be
relocated to another node. This relocation is called online migration, as there is no database service downtime during
the relocation. This online migration eliminates the planned downtime of maintenance.
Oracle RAC One Node is based on the same Grid Infrastructure as Oracle RAC Database. Oracle Clusterware in
the Grid Infrastructure provides failover protection for Oracle RAC One Node. Since Oracle RAC One Node runs only
one database instance, you can scale up the database server only by adding more CPU and memory resources to the
server instead of scaling out by running multiple database instances. If the workloads expand beyond the capacity
of a single server, you can easily upgrade the RAC One Node database to a fully functional multi-node Oracle RAC.
Compared with Oracle RAC, Oracle RAC One Node has a significant advantage in its software license cost. Chapter 14
discusses Oracle RAC One Node technology in detail.
RAC Scalability
Oracle RAC offers an architecture that can potentially increase database capacity by scaling out the database across
multiple server nodes. In this architecture, the multi-node cluster combines the CPU and memory computing
resources of multiple RAC nodes to handle the workloads. Oracle cache fusion makes this scale-out solution possible
by coordinating shared access to the database from multiple database instances. This coordination is managed through
communication over the high-speed interconnect. One of the key components of the coordination is GCS data block
transfer between database instances. Heavy access to the same data block by multiple database instances leads to
high traffic of the data transfer over the interconnect. This can potentially cause interconnect congestion, which easily
becomes a database performance bottleneck. The following considerations may help maintain RAC database scalability:
1.
Segregate workloads to different RAC nodes to reduce the demand for sharing the same
data block or data object by multiple RAC nodes. This segregation can also be done
through application affinity or instance affinity. For example, for the Oracle E-Business
application, we can assign each application module to a specific RAC instance so that all
applications that access the same set of tables are from the same instance.
2.
Reduce potential block transfers between instances. One way is to use a big cache value
and NOORDER option for the sequence creation in a RAC database. This will ensure that
each instance caches a separate range of sequence numbers and the sequence numbers
are assigned out of order by the different instances. When these sequence numbers are
used as the index key values, different key values of the index are inserted depending
on the RAC instance in which the sequence number is generated. This creates instance
affinity to the index Leaf blocks, and helps reduce pinging of the index Leaf blocks
between instances.
3.
Reduce the interconnect network latency by using a high bandwidth, high-speed network
such as InfiniBand or 10GB Ethernet.
