Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









RAC Block Access Modes and Buffer States

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.

The buffer state indicates the status of a buffer in the local cache of an instance. Information about the buffer state can be seen in the dynamic performance view v$bh. The buffer state of a block relates to the access mode of the block. For example, if a buffer state is in exclusive current (XCUR) state, it indicates that the instance owns the resource in exclusive mode.

To see a buffer?s state, query the STATUS column of the v$bh dynamic performance view. The v$bh view provides information about the block access mode and their buffer state names as follows:

* Buffer state ?CR? indicates that the block access mode is NULL. It means the owning instance can perform a consistent read of the block, if the instance holds an older version of the data.

* Buffer state ?SCUR? indicates that the block access mode is S (shared). It means the instance has shared access to the block and can only perform reads.

* Buffer state ?XCUR? indicates that access mode is X (exclusive). It means the instance has exclusive access to the block and can modify it.

* Buffer state ?PI? indicates that block access mode is NULL. It means that the instance has made changes to the block but retains copies of past images.






Instance has exclusive access to the block and therefore can modify the block.



Instance has shared access to the block and can only perform reads.



Contains an older version of the data. Can perform consistent read



Past Image Exist  (useful for recovery)

Table 7.3: Buffer States shown in v$bh view.

Only the SCUR and PI buffer states are real application cluster-specific. There can be only one copy of any block buffered in the XCUR state at any time. To perform modifications on a block, a process must assign an XCUR buffer state to the buffer containing the data block.

For example, if another instance requests a read access to the most current version of the same block, then Oracle changes the access mode from exclusive to shared, sends the current read version of the block to the requesting instance, and keeps a PI buffer if the buffer contained a dirty block

At this point, the first instance has the current block and the requesting instance also has the current block in shared mode. Therefore, the role of the resource becomes global. There can be multiple shared current (SCUR) versions of this block cached throughout the cluster database at any given point of time.

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 7.5 (a) 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 7.5(a): 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 7.5(b), 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 7.5 (b): 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 7.5(c), 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 7.5 (c):  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.


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational