Column p3 (id#/block#) in v$session_wait/v$active_session_history

Question

The environment is 10.2.0.3 in AIX 5.3.0.0 in a two node cluster.
In v$session_wait/v$active_session_history, the column p3 is reffered as
For gc buffer busy waits - id#
and
For buffer busy waits - Class#
(1)Could somebody please explain what exactly these values mean id#/class# and how can we associate them with other statitistics availble to troublshoot the issue?
In my system when I made a query in v$active_session_history it is found that file#(p1) with block# (p2) 287724 is having high count of "gc buffer waits" with tow different values in id# (p3) (pls find below result) The file 16 with block 287724 is having most number of counts for gc buffer busy (with two different id#(??))
EVENT P1 P2 P3 COUNT(*)
gc buffer busy 18 1091724 65537 2
gc buffer busy 16 287724 131073 58
gc buffer busy 7 575153 65537 2
gc buffer busy 13 1528666 65537 1
gc buffer busy 14 843396 65537 2
gc buffer busy 12 1157771 65537 1
gc buffer busy 16 287724 65537 86
gc buffer busy 12 12231 65537 1
gc buffer busy 18 1091732 65537 1
gc buffer busy 11 1642482 65537 2
gc buffer busy 10 1527484 65537 2
EVENT P1 P2 P3 COUNT(*)
gc buffer busy 11 1642497 65537 1
gc buffer busy 14 843396 131073 1
And I found that this is a primary key index with the segment_statistics as follows (from V$SEGMENT_STATISTICS)
OBJECT_NAME STATISTIC_NAME VALUE
PROCESS_LOCK_PK logical reads 18176
PROCESS_LOCK_PK buffer busy waits 33
PROCESS_LOCK_PK gc buffer busy 776
PROCESS_LOCK_PK db block changes 6624
PROCESS_LOCK_PK physical reads 2
PROCESS_LOCK_PK physical writes 64
PROCESS_LOCK_PK physical reads direct 0
PROCESS_LOCK_PK physical writes direct 0
PROCESS_LOCK_PK gc cr blocks received 1991
PROCESS_LOCK_PK gc current blocks receive 2771
PROCESS_LOCK_PK ITL waits 0
OBJECT_NAME STATISTIC_NAME VALUE
PROCESS_LOCK_PK row lock waits 0
PROCESS_LOCK_PK space used 0
PROCESS_LOCK_PK space allocated 0
PROCESS_LOCK_PK segment scans 0
with these available informations how can I solve this problem of "gc buffer busy" waits.
I am not able to find from anywhere what exactly this "id#" is and how can we use it to solve this problem.
Any help will be highly appreciated.
Thanks
N. Sethi
Message was edited by:
user623256

Answer 1

Hi,
gc buffer busy
This wait event, also known as global cache buffer busy prior to Oracle 10g, specifies the time the remote instance locally spends accessing the requested data block. This wait event is very similar to the buffer busy waits wait event in a single-instance database and are often the result of:
Hot Blocks - multiple sessions may be requesting a block that is either not in buffer cache or is in an incompatible mode. Deleting some of the hot rows and re-inserting them back into the table may alleviate the problem. Most of the time the rows will be placed into a different block and reduce contention on the block. The DBA may also need to adjust the pctfree and/or pctused parameters for the table to ensure the rows are placed into a different block.
Inefficient Queries ? as with the gc cr request wait event, the more blocks requested from the buffer cache the more likelihood of a session having to wait for other sessions. Tuning queries to access fewer blocks will often result in less contention for the same block.
Please find the below link.. I hope it will help out for you..Since I did not have much idea on RAC ..
http://www.ardentperf.com/2007/09/12/gc-buffer-busy-waits-in-rac-finding-hot-blocks/
Thanks
Pavan Kumar N