数据库每天晚上10点后业务性能很卡，大量的insert被堵塞，查询等待事件发现有大量的“library cache lock”和“cursor: pin S wait on X”。

22:00数据库的统计信息开始收集， Sql Tuning Advisor堵塞了统计信息的收集，等待事件是“library cache lock”，Sql Tuning Advisor的等待事件是ON CUP。后续导致insert大量堵塞。

查询ash记录：

select sample_time,
       instance_number,
       session_id,
       session_serial#,
       sql_id,
       top_level_sql_id,
       sql_opname,
       sql_exec_id,
       sql_exec_start,
       event,
       session_state,
       seq#,
       blocking_session,
       blocking_session_serial#,
       blocking_inst_id,
       p1text,
       p1,
       p2text,
       p2,
       p3text,
       p3,
       top_level_call_name,
       program,
       in_hard_parse
  from dba_hist_active_sess_history
 where sample_time >
       to_date('2024-03-20 22:00:00', 'yyyy-MM-dd HH24:mi:ss')
   and sample_time <
       to_date('2024-03-20 22:20:00', 'yyyy-MM-dd HH24:mi:ss')
   and event = 'library cache lock'
 order by sample_time;

检查等待事件：

sql_id:b6usrg82hwsa3，正在执行统计信息收集，dbms_stats.gather_database_stats_job_proc ( )

查看业务卡顿时的blocking_session,主要发生在dbms_sqltune.execute_tuning_task('SYS_AUTO_SQL_TUNING_TASK')

11g之后 的三个自动job

除了收集统计信息有必要保留之外，另外两个其实用处不大，SQL tuning advisor虽然可以帮助我们诊断、分析和优化SQL语句的性能问题，但也只是收集。

所以可以禁用：

exec DBMS_AUTO_TASK_ADMIN.disable(client_name=>'sql tuning advisor',operation=>NULL,window_name=>NULL);
exec DBMS_AUTO_TASK_ADMIN.disable(client_name=>'auto space advisor',operation=>NULL,window_name=>NULL);

官方文档里也有提到这可能是个bug：

ORA 7445 [qcuatc] from SQL Tuning Advisor job. (Doc ID 2506947.1)