Block Transfers Using Cache Fusion - Example

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 following is another example of how block shipping takes place. Assume that in a 3-node RAC cluster a typical block (of table ?salesman?) is brought into instance 3 by a select operation of user C. Initially, the instance acquires SL0 (shared lock with no past image) and the same Block/Lock-element undergoes many conversions, as different users at different instances handle it. The following operations show a clear movement of the blocks among the instances using cache fusion. It also shows the complexity involved. Refer to Figures 7.6 (a) and (b).

Assumption: Transactions update with commit, but there is no checkpoint until the end.

In Stage (1), the data block is read into the buffer of instance 3, and it opens with an SL0 mode (Shared Local without any past image):

select sales_rank from salesman where salesid = 10;

This gives a value of 30. Thus, the data block is protected by a resource in shared mode (S) and its role is local (L). This indicates that the block only exists in the local cache of instance 3.

Figure 7.6 (a) Data Block Shipping using Cache Fusion

In Stage (2), user B issues the same select statement against the salesman table. Instance 2 will need the same block; therefore, the block is shipped from instance 3 to instance 2 via the cache fusion interconnect. There is no disk read at this time. Both instances are in shared (S) mode and the role is local (L). So far, no buffer is dirtied.

In Stage (3), user B decides to update the row and commit at instance 2. The new sales rank is 24. At this stage, instance 2 acquires XL0 (Exclusive Local) at instance 2 and the share lock is removed on instance 3.

Update salesman set sales_rank = 24
Where salesid = 10;

In Stage (4), user A decides to update on instance 1 the same row (and therefore the block) with the salesrank value of 40. It finds that the block is dirty in instance 2. Therefore, the data block is shipped to instance 1 from instance 2, however, a past image of the data block is created on instance 2 and the lock mode is also converted to Null with a global role. Instance 2 now has a NG1 (Null Global with past image). At this time, instance 1 will have exclusive lock with global role (XG0).

In Stage (5), user C executes a select on instance 3 on the same row. The data block from instance 1 being the most recent copy, it is shipped to instance 3. As a result, the lock on instance 1 is converted to shared global with past image (SG1). On the requesting instance (Instance 1), the SG0 lock resource is created.

Select sales_rank from salesman
Where salesid = 10;

Figure 7.6 (b) Data Block Shipping using Cache Fusion

In Stage (6), user B issues the same select against the salesman table on instance 2. Instance 2 will request a consistent read copy of the buffer from another instance, which happens to be the current master.

Therefore, instance 1 will ship the block to instance 2, where it will be acquired with SG1. Then, at instance 1, the lock will be converted to SG1.

In Stage (7), user C on instance C updates the same row. Therefore, instance 3 acquires an exclusive lock and instances 1 and 2 will be downgraded to NG1 (Null global with past image). Instance 3 will have exclusive mode with a global role.

In Stage (8), the checkpoint is initiated and a write to disk takes place at instance 3. Instance 1 and instance 2 will discard their past images. At instance 3, the lock mode will become exclusive with a local role.

The stages above illustrate that consistency is maintained even though the same block is requested at different levels. These operations are transparent to the application. All the mode and role conversions are handled by Oracle without any human configuration.

If there are considerable cross-instance updates and queries for the same set of blocks, blocks are moved across without resorting to disk read or disk writes. However, there will be considerable lock conversions, which may be expensive, though they are less expensive than disk read/writes.