Benefits of Real Application Clusters (RAC)
The benefits of Real Application Clusters:
- Protection from single instance failures
- Protection from single server failures
There are cases where RAC may not be an
If RAC is being used as a cost savings
solution, be sure to analyze both hardware
and software costs
Do not expect RAC to scale if the
application will not scale on SMP
Be realistic about the latency difference
between local only memory-cache instance
communication and inter-node network based
multi-instance Cache Fusion communication
RAC is not always the best option
Solutions such as RAC are not always the best
If high performance is the only
requirement and the single server can
consistently deliver the necessary power needed,
then a single instance server may be the best
If High Availability (HA) is the only
requirement, and less complex solutions such as
are adequate, then Data Guard without RAC might
be the best choice.
Evolution from OPS
The biggest performance robber in the OPS
architecture was the DB block ping.
A DB block ping would occur when an instance
participating in an OPS database had a block in
its cache required by another participating
instance. In OPS, if another instance required
the block in the cache of a second instance, the
block would have to be written out to disk, the
locks transferred, and then the block re-read
into the requesting instance.
Oracle 8i OPS implementation brought in many
significant changes. The significant new feature
was the introduction of cache fusion technology.
as examined earlier, is a concept where cache,
or SGA, from the multiple instances coordinates
the buffers and manages the database access.
Oracle 8i (OPS) introduced the initial phase of
cache fusion. The data blocks were transferred
from the SGA of one instance to the SGA of
another instance without the need to write the
blocks to disk. This was aimed at reducing the
overhead of data blocks. However, the partial
implementation of cache fusion in Oracle 8i
could help only in certain conditions.