[異常等待事件latch undo global data]分析

 

大量latch:undo global data的爭用，導致資料庫整體效能下降

 

資料庫整體響應下降

 

 

本文件主要針對某客戶核心系統早上6點55分左右出現效能異常，應用響應超時持續長達10分鐘，詢問後得知由於雙十一，日結推遲兩小時，完成時間為11號早上7點。在仔細診斷過程中，結合相應時間段的Oracle效能報告，定位相關SQL，最終結論為同時高併發的insert和delete相同表格ACCOUNT_JNLS引起大量latch:undo global data的爭用，導致資料庫整體效能下降。具體分析如下。

 

故障原因分析

報告對比

資料庫整體會話數

11 月9、10日6:50:~7:00

11 月11日6:50:~7:00

從資料庫整體會話數看 11 號當天明顯高於 9 、 10 號兩天，近 5~6 倍。

 

 

 

11 月9、10日6:50:~7:00

11 月11日6:50:~7:00

從資料庫Top User Events來看11號當天等待事件相對於9、10號兩天較為異常，資料庫大部分等待都花費latch:undo global data爭用上。

 

等待

11 月9、10日6:50:~7:00

11 月11日6:50:~7:00

對比9、10日，11號當天相同SQL語句執行次數明顯上升，除此之外 、 兩條insert和for update

語句在前兩天是不曾出現的並且產生了大量的latch: undo global data、enq: TX - row lock contention等待,佔據了整體的40%之多。

備註： 對應SQL語句INSERT INTO account_jnls ( serial_no , account_jnls_no , trans_jnls_no ,……)

對應SQL語句SELECT area_code , account_no , product_code , gl_class , virtual_flag , real_flag , collect_flag , balance_type , balance_ctrl , sync_flag , cur_type , spot_type , close_flag , max_acc_cycle_no , max_clearing_times , dayend_cycle_no , TO_CHAR(acc_date, :"SYS_B_0") , TO_CHAR(last_acc_date, :"SYS_B_1") , TO_CHAR(open_date, :"SYS_B_2") , TO_CHAR(close_date, :"SYS_B_3") , detail_cnt , debit_amt , credit_amt , debit_cnt , credit_cnt , balance , pre_clearing_times , pre_times_balance , pre_times_dcnt , pre_times_damt , pre_times_ccnt , pre_times_camt , pre_cycle_no , pre_balance , pre_debit_cnt , pre_credit_cnt , pre_debit_amt , pre_credit_amt , dac FROM account_dynamic WHERE account_no = :account_no__0 FOR UPDATE

 

結合ash報告初步判定由於併發insert引起大量latch:undo global data的爭用，但是理論上單一insert是不會引起undo爭用，進一步排查awr。

報告對比

資料庫top 5

11 月9、10日6:00:~7:00

11 月11日6:00:~7:00

從資料庫整體awr報告來看出現了異常latch: undo global data等待，DB CPU所佔的時間也從原來的50%左右下降到30%。

 

TOP SQL

從AWR latch: undo global data 為資料庫TOP 5 wait event, 檢視了該語句就是一條簡單的insert values語句（9、10日的報告中並未發現相同SQL），執行頻率每小時63620次，單條的執行速度還可以，但是為什麼會這麼多的latch undo 呢？

進一步檢視undo相關的latch

KSLBEGIN 是一種get latch時的非常快的宏，在取得latch後呼叫KSLEND，ktudba 像是一種從usn 轉換data block address的宏

@ Latch Miss Sources

@ ——————

@ undo global data ktudba: KSLBEGIN 0 117,271,003 115,396,045
@ .@ .@ ktu.h:

@ ——

@ #define ktudba(usn, dbap, scnp, arspp) \

@ ktuGetUsegDba((usn), (dbap), (scnp), (arspp), \

@ NULLP(ub2), NULLP(ksqn), NULLP(uword))

@ .

@ ktuGetUsegDba – Kernel Transaction Undo convert from usn to DBA

從latch統計來看存在爭用，並非insert單獨引起，此時猜測相同表格上存在delete操作，進一步檢視sql統計部分，如下：

此時相同表格上確實存在delete操作，透過SQL*Plus客戶端連線執行。到此時整個現象已經很明顯了

 

綜合上述分析判斷，本次效能故障主要原因是相同表格上同時執行delete和insert操作引起latch:undo global data爭用，導致整體效能下降。建議排查應用是否由於日結延遲引起此類問題的出現。