row cache lock一則案例

官網解釋為：This event is used to wait for a lock on a data dictionary cache specified by "cache id" (P1).

從解釋可以看出這個等待時間是資料欄位上面的等待,通過p1可以查詢到等待的資料字典。

昨天接到使用者反饋說系統異常緩慢，需要緊急最佳化一下，從使用者給出的時間段拉取了awr報告進行分析。

top 10中94%的都是row cache lock的等待，說明問題就是這個row cache lock引起的。需要找到這個時間點的cache資訊。

可以通過ash或者dba_hist_active_sess_history查詢

SELECT event,p1,p1text
    FROM v$active_session_history ash
   WHERE     ash.sample_time > '22-JUN-16 14.00.00.00 PM'
         AND ash.sample_time < '22-JUN-16 16.00.00.00 PM'
         and event='row cache lock'

因為系統一直還很緩慢所以可以通過當前的v$session 去查詢

SYS@jktoa1> selectdistinct p1,p1text from v$session t where t.event='row cache lock';

       P1 P1TEXT

--------------------------------------------------------------------------

       13 cache id

SYS@jktoa1> selectparameter,gets,getmisses,MODIFICATIONS from v$rowcache where cache#=13;

PARAMETER                             GETS  GETMISSES MODIFICATIONS

------------------------------------------ ---------- -------------

dc_sequences                     220656516   42531729     220656171

可以看出是sequence引起的，在從這段時間的awr報告中看到對應的sql。可以看到8ctzwy7jhquhz這個sql執行時間上很多，而且還是sequnece。

sql內容為：selectseq_mobile_pigeon_msg_id.nextval from dual

基本可以確定就是這個sequence的因為訪問次數過多（每秒要請求54次），引起sequence分配時在系統的中爭用。

sequence的指令碼如下：

createsequence SEQ_MOBILE_PIGEON_MSG_ID

minvalue 1

maxvalue999999999999999999999999999

start with55051

increment by 1

nocache;

看到sequence的定義，可以肯定是因為sequence因為nocache加上並發調用引起的。

但是因為資料庫是rac環境，如果調整為cache，如果應用對序列有順序要求的這種，調整就會有問題。

比如cache 40，

instance 1 使用1-40

instance 2使用41-80

和開發問過應用對序列順序要求後，確認應用對sequence的順序沒有太大依賴，所以可以調整sequence的cache。

調整後應用訪問正常。

row cache lock還有很多，比如dc_users，dc_segments這些處理起來就比較麻煩，需要通過debug跟蹤session找到具體出現row cache lock的原因。才能從根本上解決問題。