Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation







 Cache Fusion - Global Cache Service Processing
Oracle Tips by Burleson Consulting

Oracle 11g Grid & Real Application Clusters by Rampant TechPress is written by four of the top Oracle database experts (Steve Karam, Bryan Jones, Mike Ault and Madhu Tumma).  The following is an excerpt from the book.

Cache Fusion Scenarios

The GCS plays a key role in performing the necessary block transfers. Three scenarios are presented to explain the concept of cache fusion:

Scenario 1 - Read/Read

Scenario 2 - Write/Write

Scenario 3 - Disk Write

Scenario 1: Read/Read

Figure 2.11 shows Scenario 1, where a typical data block is requested from another instance where it is in shared access mode with a local role. Instance 1 desires to read a data block and it makes a request to the GCS, which keeps track of the resources, location, and status. The GCS in turn forwards the request to owning Instance 2.


Figure 2.11:  Read/Read Cache Fusion – GCS Processing


The holding instance (Instance 2) transmits a copy of the block to the requesting instance (Instance 1), but keeps the resource in shared mode and also retains the local role.


Instance 2 now informs the GCS of its own resource disposition (S, L) and also that of the instance that sent the block (S, L). Thus, there is no disk read involved. The block transfer took place through the high-speed private interconnect.

Scenario 2: Write/Write

As shown in Figure 2.12, instance 1 intends to modify or update the data block and submits a request to GCS. The GCS transmits the request on to the holder (Instance 2).


Upon receiving the message, Instance 2 sends the block to Instance 1. Before sending the block, the resource is downgraded to null mode and the changed (dirty) buffer is kept as a PI. Thus, the role changes to global (G) because the block is dirty.


Along with the block, Instance 2 informs the requestor that it retained a PI copy and a null resource. The same message also specifies that the requestor can take the block held in exclusive mode and with a global role (X, G).


Figure 2.12:  Write/Write Cache Fusion – GCS Processing

Upon receipt of the block and the resource dispositions, Instance 1 informs the GCS of the mode and role (X, G). Note that the data block is not written to disk before the resource is granted to the other instance. That is, DBWR is not involved in the cache coherency scheme at this stage.

Scenario 3: Disk Write

As shown in Figure 2.13, Instance 2 first sends a write request to the GCS. This might be due to a user-executing checkpoint on Instance 2. Note that there is a past image for the block on Instance 2. The GCS forwards the request to Instance 1 (the current block holder). The GCS remembers that a write at the system change number (SCN) is pending and it also remembers that it has to notify the nodes that have PIs of the same block.


Instance 1 then receives the write request and writes the block to disk. Instance 1 completes the write and notifies the GCS. Instance 1 also informs the GCS that the resource role can become local because the instance has completed the write of the current block. After completion of the protocol, all PIs of the block should be discarded.


Figure 2.13: Write Blocks to Disk – GCS Processing


Upon receipt of the notification, the GCS orders all PI holders to discard, or flush, their PIs. Discarding, in this case, means that upon receipt of the message the PI holder records that the current block has been written and the buffer is released. The PI is no longer needed for recovery. The buffer is essentially free and the resource previously held in null mode is closed.

Remote DBA Service

Oracle Tuning Book


Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software










BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.