Oracle Database Tips by Donald Burleson

Oracle10g Grid Computing with RAC
Chapter 7 - Cache Fusion and Inter Instance Coordination

Evolution of Cache Fusion

Requesting Instance  Dirty Block exists in Holding Instance    Cache Coherency Method
Instance     Holding
---------    --------  -------------------------------------      --------------------------
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 7.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, all these ping, soft ping, and false ping issues have been solved. With the RAC system release in 9i, cache fusion fully resolves write/write conflicts using the new architecture of resource coordination and global cache service.

Nature of Cache Fusion

Multi-node Oracle RAC systems are comprised of multiple instances with each instance residing on an individual node or server. Each Oracle instance in the cluster has a dedicated set of memory structures including background processes and system global areas (SGA) that exist irrespective of another node's instance. Thus, each node's instance has its local 'buffer cache.' When applications or users connect and process their SQL operations, they primarily connect to one of the nodes. When the user processes fetch and access data blocks, the scope of such activity is confined to the SGA of the connected instance.

However, as the database is mounted with multiple instances, data blocks may exist on any of the instances or any instance may fetch the data blocks as needed by the user processes. In other words, when a user process is looking for a set of data blocks to satisfy the SQL operation requirement, the same set of blocks or some of the blocks may already be available in another node's instance. This highlights an important fact of a RAC system. As opposed to a single stand-alone Oracle instance, there are multiple server locations in a RAC system where data blocks reside. Thus, there are several cache buffers dealing with the same physical database objects.