说明
本文会介绍解决不同竞争的不同的方法。但是,很多时候这些现象都是由于 SQL 语句的version count造成的。 一旦看到了任何跟 library cache 相关的竞争,应该马上检查 AWR Report 确保没有版本数很高(比如几百)的 SQL 语句。官方文档296377.1有相应的troubleshooting,大家可以参考。
附上一张官方图供参考:

一、降低 library cache lock 等待的方法
这里提供一下排查思路:首先要确认的是 library cache 的竞争是整个系统层面的还是只发生在某个或某些 SQL 语句上?这个"library cache lock"是被一个特定的 SQL 持有很长的时间吗?或者总是在等待某个特定的对象?还是说这个锁在短时间内被请求的次数很多从而造成的竞争?
有两个排查方向:系统和SQL。
1.系统层
如果问题是在整个系统层面发生的,一般来说是由于 shared pool 太小或 SQL 语句不共享造成的。
解决竞争的方法:
(1)增大 shared pool 从而减少 reload 的次数,这是因为 shared pool 过小会造成获取锁的时间加长。
(2)通过将 cursor_sharing 设置为 similar 或 force 来使 SQL 语句共享。
需要小心的是这样做可能会改变SQL的执行计划,所以做之前需要做完整的测试。
(3)在系统不繁忙的时候做统计信息的收集或其它维护作业,从而降低invalidation的次数。
2. SQL层
如果是某条或某些SQL产生的问题,那么需要检查为什么它持有锁的时间会那么长,可参考官方文档122793.1有详细的排查步骤,这里不再赘述。
二、降低 library cache pin 等待的方法
1. 如果"library cache pin"等待的时间很长,就必须判断是只有一两个 process 在等待还是有很多的 process 都在等待。
2. 如果说只是一两个 process 被另一个 process 阻塞的话,那么需要检查持有这个 pin 的 process 为什么这么长时间不释放。
3. 如果说等待是大范围的那么说明 shared pool 需要优化。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/69992972/viewspace-2942453/ ,如需转载,请注明出处,否则将追究法律责任。