第一个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的范围，导致了系统的不可使用。

记2个library cache lock故障case

第一个case

第二个case