数据库每天晚上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_parsefrom dba_hist_active_sess_historywhere 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)