Cache Fusion
The topics that will be covered in this section
include the nature, internals, and working
mechanism of cache fusion technology along with
the following subjects:
-
Virtualization of multiple caches into a
single cache
-
How the data blocks are moved across among
multiple SGAs in a multi-node environment
-
Synchronization of resource access
-
Resource coordination methodology
-
Re-mastering of resources in the event of
unforeseen failure of any instance
Cache fusion is a diskless cache coherency
mechanism that provides copies of blocks
directly from a holding instance’s memory cache
(local SGA buffer cache) to a requesting
instance’s memory cache (remote SGA buffer
cache).
A RAC system equipped with low-latency and high
speed interconnect technology enables the buffer
cache of each node in the cluster to fuse and
form into a single virtual global cache, hence
the term cache fusion. The cache fusion
architecture creates a shared-cache and provides
a single cache image or view to the
applications. Internals are transparent to the
applications.
From a functional viewpoint, an instance in a
RAC system is equivalent to a single instance of
Oracle.
The extension of multiple cache buffers
into a single fused global cache improves
scalability, reliability, and availability.
While cache fusion provides Oracle users with an
expanded database cache for queries and updates
of I/O operations, the improved performance
depends greatly on the efficiency of the
inter-node message passing mechanism that
handles the data block transfers.
Evolution of Cache Fusion
Before looking deeper into the implementation of
cache fusion in Oracle 11g RAC, some time needs
to be taken to look at the implementation in the
8i release. Oracle Release 8i (Oracle Parallel
Server)
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 ping overhead of
data blocks. However, the partial implementation
of cache fusion in 8i could help only in certain
conditions, as indicated in Table 2.1.
|
REQUESTING INSTANCE
|
HOLDING INSTANCE
|
DIRTY BLOCK EXISTS IN HOLDING INSTANCE
|
CACHE COHERENCY METHOD
|
|
For Read
|
Read
|
Yes
|
Cache Fusion
|
|
For Read
|
Write
|
No
|
Soft
Ping
(read from disk)
|
|
For Read
|
Write
|
Yes
|
Cache Fusion
|
|
For Write
|
Write
|
Does Not matter
|
Ping
(force disk write)
|
Table 2.1:
The Methods of Maintaining Cache Coherency
Oracle 8i (Oracle Parallel Server)
had a background process called the Block Server
Process
(BSP), which facilitated cache fusion. BSP was
responsible for transferring the required blocks
directly from the owning instance to the buffer
cache of the requested instance.
For read/write operations, if the block was
already written to disk by the holding instance,
the requested block was read from the disk. It
involved a soft ping or an I/O-less ping. If the
block was available on the holding instance
buffer, the BSP process prepared a consistent
read
(CR) image of the data block. It was then sent
to the requesting instance.
A write/write operation invariably involved the
ping of the data block. When the ping occurred,
the holding instance wrote to disk and
downgraded the lock mode. Then, the requesting
instance acquired the necessary lock mode and
read from the disk. This frequent pinging hurt
the performance of the OPS database. With the
full implementation of cache fusion in release
9i, 10g, and 11g, all these ping, soft ping, and
false ping issues have been solved. Cache fusion
now fully resolves write/write conflicts using
the new architecture of resource coordination
and global cache service.
