Database Reference
In-Depth Information
block with file_id=4, block_id=180. This block transfer is a 2-way block transfer, as the owning instance is same as the
resource master instance (instance 2).
SYS@ORCL1:1> @tc_one_row.sql
N1 FNO BLOCK OBJ V1
---------- ---------- ---------- ---------- ----------
100 4 180 75742 250
Trace file:
nam='gc current block 2-way' ela= 629 p1=4 p2=180 p3=1 obj#=75742 tim=1350440823837572
Next, I will create conditions for a 3-way wait event, but first let me flush buffer cache in all three instances to start
with a clean buffer cache. In the following example,
1.
I will query the row connecting to instance 1 (which would load the block into the buffer
cache of instance 1).
2.
I will connect to an instance and query the same row from instance 3. The FG process for
my session will request LMS process running in instance 2 for the block (as instance 2 is
the resource master).
3.
Instance 2 LMS process forwards the request to LMS process in instance 1.
4.
An LMS process in instance 1 will send the block to the FG process in instance 3.
Essentially, three instances participate in a block transfer; hence, this is a 3-way block transfer.
-- alter system flush buffer_cache; from all instances
RS@ORCL1:1> @tc_one_row.sql
N1 FNO BLOCK OBJ V1
---------- ---------- ---------- ---------- ----------
100 4 180 75742 250
RS@ORCL3:3> @tc_one_row.sql
N1 FNO BLOCK OBJ V1
---------- ---------- ---------- ---------- ----------
100 4 180 75742 250
Trace file:
nam='gc current block 3-way' ela= 798 p1=4 p2=180 p3=1 obj#=75742
Reviewing locks on the resource connecting to instance 2, we see that there are two locks on the resources held
for instance 1 and instance 3 (owner_node equals to 0 and 2).
RS@ORCL2:2> SELECT resource_name1, grant_level, state, owner_node
FROM v$ges_enqueue
WHERE resource_name1 LIKE '[0xb4][0x4],[BL]%';
