RAC等待事件：gc buffer busy acquire

gc buffer busy release：是在本地實例session 1之前已經(jīng)有遠程實例session 2請求訪問了本地實例的相同buffer，并且沒有完成，那么本地實例的session 1就是在等待gc buffer busy release。

P1                 File #
P2                 Block #
P3                 Mode requested/mode held/block class
SECONDS_IN_WAIT    Amount of time waited for the current event
file#              This is the file# of the file that Oracle is trying to read from.
block#             This is the starting block number in the file from where Oracle starts reading the blocks.
blocks             This parameter specifies the number of blocks that Oracle is rying to read from the file# starting at block#
Inst_id            instance number
To determine the root blocker for sessions waiting on the gc wait events use the below options
1.system state dump at cluster level
2. oratop displays waiters/blockers
3. v$wait_chains can be used to find the root blocker for sessions that are blocked,Troubleshooting Database Contention With V$Wait_Chains (Doc ID 1428210.1)
4. Using v$hang_info, v$hang_session_info, etc
5. Oracle Hang Manager (Doc ID 1534591.1)
Using the above information we can find the sessions waiting for specific gc events with their final blockers at instance level

如果等待緩沖區(qū)花費的時間較長，則需要根據(jù)以下內(nèi)容確定哪個段遭受爭用:
SELECT inst_id,
       sid,
       event,
       wait_class,
       P1,
       P2,
       P3 Mode requested / mode held / block class,
       seconds_in_wait
  FROM gv$session_wait
 WHERE event LIKE 'gc buffer%';
從前面的輸出中，使用P1和P2中的數(shù)據(jù)，可以使用以下命令獲得相關的對象信息以下查詢：
SELECT segment_name
  FROM dba_extents
 WHERE file_id = &file
   AND &block BETWEEN block_id AND block_id + blocks - 1
   AND ROWNUM = 1;

2）gc block busy、enq: TX - row lock contention以及其他等待可能會影響阻止會話或者LMS進程。

3）高網(wǎng)絡延遲或網(wǎng)絡問題

4）繁忙的服務器或活動的頁面調(diào)度/交換（由于可用內(nèi)存不足）

5）低效SQL語句

7）Oracle  Bug

Solution is to reorganize the index in a way to avoid the contention or hot spots using the below options
I. Global Hash partition the index
CREATE INDEX hgidx ON tab (c1,c2,c3) GLOBAL
     PARTITION BY HASH (c1,c2)
     (PARTITION p1  TABLESPACE tbs_1,
      PARTITION p2  TABLESPACE tbs_2,
      PARTITION p3  TABLESPACE tbs_3,
      PARTITION p4  TABLESPACE tbs_4);
II. Recreate the index as reverse key index (not suitable for large table, could require buffer cache increased accordingly)
III. If index key is generated from a sequence, increase cache size of the sequence and make the sequence 'no order' if application supports it.
Refer the doc link: http://docs.oracle.com/database/121/VLDBG/GUID-BF3F38E1-62BB-4EE3-86C1-A2EF8A258B1F.htm#VLDBG1089

對于enq: TX - row lock contention：

Mode 4-Related to ITL waits
從AWR報告或使用以下SQL查找具有較高ITL等待的段:
SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
  FROM V$SEGMENT_STATISTICS
 WHERE STATISTIC_NAME = 'ITL waits'
   AND VALUE > 0
 ORDER BY VALUE;
增加這些高ITL等待的segment的inittrans值
Mode 6-Primarily due to application issue:
這是一個應用程序問題，需要應用程序開發(fā)人員來調(diào)查所涉及的SQL語句。 以下文檔可能有助于進一步深入研究：
Note:102925.1 - Tracing sessions: waiting on an enqueue
Note:179582.1 - How to Find TX Enqueue Contention in RAC or OPS
Note:1020008.6 - SCRIPT: FULLY DECODED LOCKING
Note:62354.1 - TX Transaction locks - Example wait scenarios
Note:224305.1 -Autonomous Transaction can cause locking

How to Validate Network and Name Resolution Setup for the Clusterware and RAC (Doc ID 1054902.1)

How to Validate Network and Name Resolution Setup for the Clusterware and RAC (Doc ID 1054902.1).pdf