Database Reference
In-Depth Information
Instance 1
(R)
Instance 1
(R)
Instance 4
(M)
Instance 4
(M)
Instance 3
(H)
Instance 1
(R)
Local cache
1
Master
2
Message
Blk Transfer
GRD Lookup
3
Holder
4
Message
Requestor
5
Blk Transfer
6
Message
Figure 14-1.
Sequence diagram for a block request
Figure
14-1
illustrates the sequence of steps to get a data block to the requestor:
1.
A user accesses data and the server process tries to find the data in the local buffer cache
of the instance to see if the block is present. If the block is found in the local cache (not
illustrated), the data is fetched and there is no inter-instance communication involved.
2.
If the block is not found in the local buffer cache, the GCS makes a request to determine
whether another instance has the data cached. To make this request, GCS sends a
message to the instance, which “masters” the block: in this case, Instance 4. The message
containing the request is sent from Instance 1 to Instance 4 across the interconnect.
3.
Instance 4 determines the current global state to find the current holder (holding instance)
of the block.
4.
Instance 4 sends a message to the current holder of the block (Instance 3), authorizing it to
send the block to the requestor.
5.
Instance 3 receives the request from the master and prepares the process to transfer the
block to the requestor. Instance 3 transfers the block to the requestor Instance 1 via the
interconnect.
6.
Instance 1, on receipt of the block, sends an acknowledgement message to the master
(not illustrated).
In the entire process, there are two types of operations that involve the interconnect: sending/receiving messages
and block transfer.
When more than two instances are participating in the clustered configuration, the block transfer may require 3
hops to complete the operation. Also, if the master or the block is located in the local cache of the instance where the
user session had originally made the request, messaging and data transfer requests are reduced.
Search WWH ::
Custom Search