2019年10月15日 星期二
自動分析 dbms_stats.gather_database_stats_job_proc 引起的 library cache lock
環境 RAC 11.2.4
每天凌晨 0100 執行的 自動維護作業
1.automatic SQL Tuning Advisor
2.dbms_stats.gather_database_stats_job_proc
有蠻大機會會在此時間區間出現,DB insert 時間過長導致 session 卡住的狀況
簡單看一下 EM狀況
0100 開始可以看到一個是 insert ,另外一個是 dbms_stats.gather_database_stats_job_proc
卡住
看了一下 trc 檔案
*** 2019-10-16 01:25:49.032
*** SESSION ID:(430.29037) 2019-10-16 01:25:49.032
*** CLIENT ID:() 2019-10-16 01:25:49.032
*** SERVICE NAME:(SYS$USERS) 2019-10-16 01:25:49.032
*** MODULE NAME:(DBMS_SCHEDULER) 2019-10-16 01:25:49.032
*** ACTION NAME:(ORA$AT_OS_OPT_SY_5981) 2019-10-16 01:25:49.032
ORA-04021: timeout occurred while waiting to lock object
*** 2019-10-16 01:25:49.032
DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"LX"','"USER_NAME"','""', ...)
DBMS_STATS: ORA-04021: timeout occurred while waiting to lock object
WARNING:io_submit failed due to kernel limitations MAXAIO for process=128 pending aio=0
查了一下 mos 還真得是 BUG
bug:Bug 19790972 – “library cache lock” waits due to DBMS_STATS gather of stats for a subpartition
不過查了蠻多資料都說自動維護的 sql tuning 會跟 dbms_stats 衝突
sql tuning 會拿 table 的 S lock
dbms_stats 會拿table 的X lock , S 跟X lock 不兼容 所以才會造成此狀況
建議是關掉自動 sql tuning , 或者 上 patch
訂閱:
文章 (Atom)