Database Reference
In-Depth Information
Each of the numbered steps is explained below. Items with dotted lines in the picture indicate the state after the
block transfer.
1.
A foreground (FG) process (also known as a server process) tries to access a database
block and the data block is not in the local buffer cache. A hashing algorithm
1
is applied
on the resource_name protecting the block to calculate the resource master instance. In
Figure
10-1
, the resource master instance for this resource is 2.
a.
The FG process retrieves the network address of a remote LMS background process
running on the resource master instance.
b.
The FG process constructs a message for the block access and sends that message to
the remote LMS process.
c.
The FG process must wait until a response is received from the remote LMS process.
FG process cannot predict the LMS response since the block could be in a remote
buffer cache or the block may not be resident in any buffer cache. So, the FG process
waits on a
placeholder
wait event.
2.
LMS process in the resource master instance receives the message, identifies the block,
and accesses GRD to identify the current state of the resource.
a.
For CURRENT mode request, if the block is not in any buffer cache, the LMS process
allocates a new resource in GRD; then allocates a lock on the resource;
2
and then
sends a message back to the FG process with a
grant
to read the block from the disk.
b.
For CR mode requests, GRD representation of resource is not required. The block may
be simply reconstructed without requiring additional lock conversion.
3.
In Figure
10-1
, the block is resident in the buffer cache of instance 1. So, an LMS process
running on the
resource master
instance sends a request to the LMS process running on
the
owning
instance (instance 1).
4.
LMS process running in owning instance constructs a block and sends the block to the
FG process running in instance 3.
3
5.
The FG process receives the block, copies the block to the instance 3 buffer cache, and
continues processing further.
After the transfer of a block, LMS process running on the resource master instance also modifies the resource
and adds a lock indicating that the block is now resident in both instances 1 and 3. Obviously, the LMS background
process plays a critical role in the cache fusion process and it is the workhorse process behind cache fusion
processing.
1
This algorithm is a variant of hashing algorithm. In a nutshell, in a three-instance database, the first contiguous 256 blocks of a
data file will be mastered by instance 1, the next 256 blocks will be mastered by instance 2, the third 256-block range is to be
mastered by instance 3, and the fourth 256-block range is to be mastered by instance 1, in a cyclic way. This blocking factor is
controlled by _lm_contiguous_res_count parameter and defaults to 256 in 11g (in 10gR2, defaults to 128). DRM is a feature that
alters the round-robin mastership and is discussed later in this chapter.
2
Note that this algorithm is a rough outline; the actual algorithm is more complicated. The action depends upon the request type CR
or current mode, whether the buffer is in buffer cache of resource master, whether the buffer is in another instance buffer cache,
whether downgrade is possible or not, etc.
3
The Wireshark utility is a great tool to trace this activity. You can see that FG (server process) receives the blocks directly from
LMS process from 10gR2 onward.
