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 2.14 and
2.15.
Note:
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 2.14:
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 sales rank 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 2.15:
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.
