背景： 2017-04-11 19:20收到開發員反饋，在某庫db1上執行update語句很快，但commit很慢，至少執行了5分鐘commit都沒有返回。 問題： 是什麼原因導致commit被掛起/阻塞呢？ 分析： 1）當前正在執行什麼後臺作業呢？備份？還是之前發現的一個從18:00跑到21點的後臺作業呢？ 2）確認備份完成時間，發現在18:51完成，不在本次事件發生時間內。排除備份的影響。 3）查詢後臺作業dba_scheduler_running_jobs 發現作業job1正在執行，並根據該檢視的session_id統計該作業執行時資訊，具體語句如下： select sql_id,event,count(*) from gv$active_session_history where session_id=1719 and session_serial#=45465 group by sql_id,event order by 3 desc; select sql_opname,count(*) from gv$active_session_history where session_id=1719 and session_serial#=45465 group by sql_opname order by 2 desc; 4） 根據以上結果發現執行的sql語句以update,insert為主。 5） 生成awr報告，發現有大量的log file sync的等待，竟然佔db time 95%，每秒處理的事務3295次，即user commit 3295次/s <<<<<<<<<<==============從這一刻開始，懷疑重點是“頻繁commit形成佇列，令其它事務commit時在佇列未端，最終像掛起一樣”，證據如下：


6）再檢視AWR的SQL語句部份，發現有三條update語句，共執行2400萬次。 7）根據sql語句的內容查詢dba_source表，確認程式碼項： select * from dba_source where text LIKE '%UPDATE XXXX%'; 最終檢查程式碼發現： for v in (select id from t1 ) loop update t2 set price=price*1.1 where id=v.id commit; end loop; 結論： 找出問題程式碼，建議由每次commit改為批量commit，問題解決！ 補充： log file sync等待：有可能是頻繁commit導致，也有可能redo logfile size太少導致，也有可能是io太慢導致。