第3个案例—云安（2022.03.05 6点，10点，14点出现死锁现象）

一、问题现象

云安在2022.03.05的6点，10点，14点出现车间无法报工现象。

二、分析原因

考虑到这天是周六，根据Oracle自动优化窗口，周六，周日全天进行优化，触发时间点是6点开始，约每隔4小时执行一次，每次执行时间约30分钟。

此期间，如果操作频繁，可能会导致sql死锁。

三、排查流程

1、查看alert日志

（1）早上6点开始执行优化sql任务，出现死锁现象；

（2）上午10点第二次SQL Tunning Advisor 任务，于10点19分再次死锁。

约10点17-20分，设备人员重启IIS，中断了这个锁进程

（3）下午2点，依然自动进行sql优化，管理员进行了重启IIS，未出现死锁。

2、查看awr

（1）6点-7点

主要以cursor: pin S wait on X，library cache lock ，row lock为主，是锁的一个标识。

耗费DB时间。

（2）10点-11点

同样各种锁出现了。

3、分析

通过查看awr，在这几个时刻，都出现了各种lock。说明资源存在争用，需要后续持续跟踪观察。

四、解决思路

1、首要方式：

关闭自动优化任务，并和管理员确认每天的空闲时间，设置这些时间点进行任务优化。

（1）关闭自动优化任务

BEGIN
dbms_auto_task_admin.disable(
client_name => 'auto optimizer stats collection',
operation => NULL,
window_name => NULL);
END;
/

BEGIN
dbms_auto_task_admin.disable(
client_name => 'sql tuning advisor',
operation => NULL,
window_name => NULL);
END;
/

BEGIN
dbms_auto_task_admin.disable(
client_name => 'auto space advisor',
operation => NULL,
window_name => NULL);
END;
/

（2）在其他空闲时间点开启优化（需要管理员确认）

五、后续跟踪

1、前期的自动任务显示

2、后续跟踪

根据上述查询，显示每天都在运行自动优化任务，但是前期并未出现当前的问题，需要后期继续跟踪查看，并协同开发排查此次出现问题的根本原因。

1、出现大量归档日志，一天有十几-20g，平时也就1-3G左右

2、alert.log中，归档时间特别短，几秒一个；平时是4-5分钟一个。

咨询开发，得出结论，昨天给他们开启了迁移，他们的数据迁移有问题，因为迁移过程有大量的删除和插入操作，所以1/2问题得到了解释。