Oracle RAC 碰到 gc buffer busy

資料庫版本：Oracle 10.2.0.5-64
節點數：2
作業系統版本：CentOS 5.6 -64

今天做awr報告發現gc buffer busy等待時間

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 asingle-instance database and are often the result of:

1. 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.

2. 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.

第一點應該基本排除：我剛剛整理完表，我們首先找到造成次問題的sql
1、首先查看上次所有的等待事件種類

1. SQL> select min(begin_interval_time) min, max(end_interval_time) max from dba_hist_snapshot where snap_id between 204 and 228;  
2. SQL> select wait_class_id, wait_class, count(*) cnt  
3. from dba_hist_active_sess_history  
4. where snap_id between 204 and 228  
5. group by wait_class_id, wait_class  
6. order by 3;  
7. 結果如下：  
8. WAIT_CLASS_ID WAIT_CLASS                            CNT  
9. ------------- ------------------------------ ----------   
10.    4217450380 Application                             1  
11.    1740759767 User I/O                                3  
12.    2000153315 Network                                 7  
13.    3875070507 Concurrency                             8  
14.    3386400367 Commit                                 24  
15.    4108307767 System I/O                             54  
16.    1893977003 Other                                  66  
17.    3871361733 Cluster                               104  
18.                                                    3543  

2、查看上次所有的等待事件

1. SQL> SELECT event_id, event, COUNT (*) cnt  
2.     FROM dba_hist_active_sess_history  
3.    WHERE snap_id BETWEEN 204 AND 228 AND wait_class_id = 3871361733  
4. GROUP BY event_id, event  
5. ORDER BY 3;  
6. 結果如下：                                             
7.   EVENT_ID EVENT                                 CNT  
8. ---------- ------------------------------ ----------   
9. 2277737081 gc current grant busy                   1  
10.  512320954 gc cr request                           1  
11. 3897775868 gc current multi block request          4  
12.  737661873 gc cr block 2-way                       5  
13.  111015833 gc current block 2-way                  6  
14. 2701629120 gc current block busy                   7  
15. 1520064534 gc cr block busy                        9  
16. 1478861578 gc buffer busy                         71  

3、查詢造成等待事件的sql

1. SQL> SELECT sql_id, COUNT (*) cnt  
2.     FROM dba_hist_active_sess_history  
3.    WHERE snap_id BETWEEN 204 AND 228 AND event_id IN (1520064534, 1478861578)  
4. GROUP BY sql_id  
5.   HAVING COUNT (*) > 1  
6. ORDER BY 2;  
7. 結果如下：  
8. SQL_ID               CNT  
9. ------------- ----------   
10. fuzy096ka7sca          2  
11. 9mdnmqu9vhht6          4  
12. btb1g900q18u3          5  
13. 1y4rsrmg1m8u9          5  
14. g42h7cxm2jsmb          8  
15. 8knuwvx47gdsz         16  
16. bp92nqubvbpdq         40  

4、查詢具體的sql

1. SELECT *  
2.   FROM dba_hist_sqltext d  
3.  WHERE sql_id IN  
4.           ('bp92nqubvbpdq',  
5.            '8knuwvx47gdsz',  
6.            'g42h7cxm2jsmb',  
7.            '1y4rsrmg1m8u9',  
8.            'btb1g900q18u3',  
9.            '9mdnmqu9vhht6',  
10.            'fuzy096ka7sca');  

最後看到，主要是因為一個插入的sql產生的原因，下面就是和開發商量怎麼解決這個問題了。