核心系统 数据库出现sql超时现象，具体sql如下：

通过观察数据库等待事件图发现等待大量的 library cache lock 和 cursor: pin S wait on X' 等待 ，具体如下图：

通过问题 sql的等待溯源，发现锁源sql为如下

数据库日志对应的信息

原因分析：

数据库在 2023.8.25 22:00:00 开始做统计信息的收集，目前数据库是开启 S ql  Tuning Advisor （ sql 优化工具），所以做统计信息收集时也同时做了 S ql Tuning Advisor ， 从上面图可以看出 ，在对上面 SQL 做 S ql  Tuning Advisor 时 ，以 S 模式持有了目标表 tbl_txn_log_a 上的 library cache lock ，而另外一个收集统计信息的 job 需要以 X 模式来  获取 tbl_txn_log_a 上的 library cache lock ， S 和 X 不兼容导致阻塞，

此时有大量的 insert 的操作，同样在 tbl_txn_log_a 上的 hard parse 都需要以 S 模式申请表上的 library cache lock ，这就造成大量的 library cache lock 和 cursor: pin S wait on X 等待 ， insert 操作也被堵塞，在 2023.8.25 22:16:00 数据库收集统计信息的 job 超时被 kill ，目标表 tbl_txn_log_a 的 library cache lock X 锁被释放后， insert 操作顺利获得到目标表 library cache lock 后，执行成功。

临时方案： 因数据库每次等待事件都伴随着锁源 sql以及该目标表统计信息收集，现手工收集该表统计信息，绕过数据库优化器 SQL Tuning Advisor 的收集规则。优化后可以看到数据库等待事件明显消失。

后续方案：

1、 数据库中该目标表以及该目标表的碎片率极高，直接路径读非常严重，需要重建

tbl_txn_log_a 以及 tbl_txn_log_a _his 表

2、 部署定时脚本，定时自动收集表的 tbl_txn_log_a 统计信息，避免自动收集触发 SQL tuning advisor 导致堵塞 ；

3、 SQL tuning advisor 是一个 新特性，数据库自带的一个 SQL 优化工具，可以帮助我们诊断、分析和优化 SQL 语句的性能问题，在 12c 中发生类似情况，官方有建议关闭 SQL tuning advisor   [qcuatc] from SQL Tuning Advisor job. (Doc ID 2506947.1)

建议考虑关闭S ql  tuning advisor 。

具体语句

sqlplus / as sysdba

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);