|
今天早上在巡檢數(shù)據(jù)庫(kù)時(shí)，發(fā)現(xiàn)報(bào)表數(shù)據(jù)庫(kù)DB
Time有些異常，獲取當(dāng)時(shí)AWR報(bào)告，發(fā)現(xiàn)一個(gè)新的等待事件buffer
busy waits，記錄一下排查分析過(guò)程，詳細(xì)信息如下：
從數(shù)據(jù)庫(kù)負(fù)載和會(huì)話數(shù)量上看，數(shù)據(jù)庫(kù)沒(méi)什么問(wèn)題，但是從TOP 5上我們看到了一個(gè)新的等待事件
該等待事所點(diǎn)時(shí)間百分比不高，這也是為什么從數(shù)據(jù)庫(kù)負(fù)載和會(huì)話數(shù)量上沒(méi)有體現(xiàn)出來(lái)的原因，但是作為DBA我們需要做的是做異常殺死在搖籃里，DBA救火是必備技能，但是做好消防監(jiān)控也是必備能力，回到該等等事件上來(lái)，先說(shuō)說(shuō)該等待事件原理：當(dāng)一個(gè)會(huì)話獲取數(shù)fuffer
cache中一個(gè)數(shù)據(jù)塊時(shí)，因?yàn)閎uffer是繁忙的，無(wú)法獲取，官方給出了兩個(gè)常見(jiàn)產(chǎn)生該等等事件的原因：
1.其它會(huì)話正在將數(shù)據(jù)塊讀入buffer
2.其它會(huì)話以排它模式持有buffer
有點(diǎn)不太好理解，說(shuō)的簡(jiǎn)單的，后來(lái)經(jīng)過(guò)自己的理解，我給出一種解釋，可以簡(jiǎn)單理解為熱塊問(wèn)題，通常發(fā)生在頻率插入或更新的情況，因?yàn)椴迦霑r(shí)數(shù)據(jù)可以多次往同一塊寫(xiě)入，特別是索引，插入引起塊的分裂，產(chǎn)生熱塊，是不是這樣的呢？我們做一下查詢我后和AWR中的TOP
SQL進(jìn)行驗(yàn)證。
--查詢快照期間發(fā)生該等待事件的SQL和BLOCKING SQL
SELECT sql_id,
blocking_session,
blocking_session_serial#,
blocking_session_status,
p1
"File",
p2
"Block",
p3
"Reason"
FROM dba_hist_active_sess_history
WHERE event = 'buffer busy waits'
and snap_id in (5283,
5284)
產(chǎn)生該等待事件的SQL_ID為：cw6a7w8u5awwf，然后跟據(jù)BLOCKING_SESSION信息查詢SQL_ID
select distinct sql_id
from dba_hist_active_sess_history
where session_id = '1494'
and session_serial# =
'6076'
and snap_id in (5283,
5284)
結(jié)果顯示SQL_ID為：404qaurwrsnva
看來(lái)我們只需要找到
cw6a7w8u5awwf、404qaurwrsnva兩個(gè)SQL到底在做什么就可以了，現(xiàn)在我們來(lái)看AWR報(bào)告中TOP
SQL部分
很顯然，兩條都在多次進(jìn)行插入操作，驗(yàn)證了我們前面的分析，另外，此類等待事件我們需要關(guān)注AWR中的如下模塊：
綜合分析來(lái)看，兩條SQL執(zhí)行的操作剛好就是這部分中的表，和該表上的兩個(gè)索引，至此問(wèn)題就分析出來(lái)了，難點(diǎn)是怎么去解決掉它？
因?yàn)槲疫@個(gè)案例是邏輯DG，受到操作限制，那么我想避免該類等待事件的操作有兩種方法
第一：將普通表做成分區(qū)表
第二：將定期將索引刪除并重建
第三：調(diào)整表和索引pctfree參數(shù)，減少同一塊中數(shù)據(jù)記錄行數(shù)
引起該等待事件的原因可能有多種，詳細(xì)分類分析請(qǐng)參考DAVE博客：
http://blog.csdn.net/cymm_liu/article/details/7968537
|
