Oracle RAC encounters gc buffer busy

Database Version: Oracle 10.2.0.5-64
Number of nodes: 2
Operating system version: centos 5.6-64

Awr report today finds gc buffer busy wait time

Gc buffer busy
This wait event, also known as global cache buffer busy prior to Oracle 10g, specifies the time the remote instance locally has Ds accessing the requested data block. this wait event is very similar to the buffer busy waits wait event inSingle-instanceDatabase and are often the result:

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

First, we should basically exclude: After finishing the table, we first find the SQL statement that caused the problem.
1. First, view all types of last waiting events

1. SQL>Select Min(Begin_interval_time)Min,Max(End_interval_time)Max FromDba_hist_snapshotWhereSnap_id between 204 and 228;
2. SQL>SelectWait_class_id, wait_class, count (*) cnt
3. FromDba_hist_active_sess_history
4. WhereSnap_id between 204 and 228
5. Group ByWait_class_id, wait_class
6. Order By3;
7. The result is as follows:
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. 3386400367Commit24
15. 4108307767 System I/O 54
16. 1893977003 Other 66
17. 3871361733 Cluster 104
18. 3543

2. View All last wait events

1. SQL>SELECTEvent_id, event, COUNT (*) cnt
2. FROMDba_hist_active_sess_history
3. WHERESnap_id BETWEEN 204 AND 228 AND wait_class_id = 3871361733
4. GROUP BYEvent_id, event
5. ORDER BY3;
6. The result is as follows:
7. EVENT_ID EVENT CNT
8. --------------------------------------------------
9. 2277737081 gcCurrent GrantBusy 1
10. 512320954 gc cr request 1
11. 3897775868 gcCurrentMulti block request 4
12. 737661873 gc cr block 2-way 5
13. 111015833 gcCurrentBlock 2-way 6
14. 2701629120 gcCurrentBlock busy 7
15. 1520064534 gc cr block busy 9
16. 1478861578 gc buffer busy 71

3. query the SQL statements that cause the wait event

1. SQL>SELECTSQL _id, COUNT (*) cnt
2. FROMDba_hist_active_sess_history
3. WHERESnap_id BETWEEN 204 AND 228 AND event_id IN (1520064534,147 8861578)
4. GROUP BYSQL _id
5. HAVINGCOUNT (*)> 1
6. ORDER BY2;
7. The result is as follows:
8. SQL _ID CNT
9. -----------------------
10. Fuzy096ka7sca 2
11. 9mdnmqu9vhht6 4
12. Btb1g900q18u3 5
13. 1y4rsrmg1m8u9 5
14. G421_cxm2jsmb 8
15. 8knuwvx47gdsz 16
16. Bp92nqubvbpdq 40

4. query specific SQL statements

1. SELECT*
2. FROMDba_hist_sqltext d
3.  WHERESQL _id IN
4. ('Bp92nqubvbpdq ',
5. '8knuwvx47gdsz ',
6. 'G421_cxm2jsmb ',
7. '1y4rsrmg1m8u9 ',
8. 'Btb1g900q18u3 ',
9. '9mdnmqu9vhht6 ',
10. 'Fuzy096ka7sca ');

Finally, we can see that it is mainly because of the cause of an inserted SQL statement. below is how to solve this problem with the developer volume.