第一个case
客户说晚上10点的时候做业务很卡，遂取对应时段awr
非常明显的library cache lock事件。这个事件是元数据锁，一旦泛滥对数据库的影响范围很大。
因此，他的泛滥第一时间应该想到会有大量持有元数据的动作。对sql进行检查
这个自动任务收集是最可疑的
参考官方文档1952395.1
| 我们看到统计信息收集的调度是DBMS_SCHEDULER做的 |
用以下sql查询window
select window_name,repeat_interval,duration from dba_scheduler_windows;
调整window到1点
BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE(
name=>'"SYS"."FRIDAY_WINDOW"',
attribute=>'REPEAT_INTERVAL',
value=>'freq=daily;byday=FRI;byhour=1;byminute=0; bysecond=0');
END;经过测试，问题解决，然后将修改范围延伸到所有window
第二个case
祸不单行，另一个库也出现了library cache lock的问题
检查数据库等待事件，有大量的library cache lock和cursor pin s wait on x
这时候要检查事件为library cache lock的blocking session
因为library cache lock是有可能有blocking session的，它属于元数据的锁，是有可能存在锁关系的。而其他的library cache lock是有可能因为某一个library cache lock的大面积持有，从而产生堆积
查询到仅有一个blocking session，而且状态为killed。尝试将进程干掉，状态短暂停滞后恢复。
该等待事件是一个空闲类的事件，属于等待客户端反馈。经过排查该sql是一个查询，且有dblink跨库。
但是这还不具有完整的证据链，单这个sql是不会导致大面的library cache lock和cursor pin s wait on x
我们再查找当时blocking_session为这个session的那个session在干嘛
因为现象持续了一定时间，session是应该有被抓取的，可以从dba_hist_active_session中找
select session_id,sql_id,event
from DBA_HIST_ACTIVE_SESS_HISTORY
where sample_time > to_date('2022-12-20 20:15:00','yyyy-mm-dd hh24:mi:ss')
and sample_time < to_date('2022-12-20 20:20:00','yyyy-mm-dd hh24:mi:ss')
and blocking_session =3449;抓到了对应的session，只有他这一个，干的是dbms_stats.gather_database
这样证据链就完整了。3449的异常不返回并没有直接导致库的大面积library cache lock，但是定时window启动了，做了全库的统计信息收集，持有了大量的library cache，然后遇到了这个session，收集统计信息扩大了library cache lock的范围，导致了系统的不可使用。
