library cache lock等待事件-优快云博客

昨天下午快下班的时候，通过oem界面突然发现一大片的血红色，直觉告诉我，估计又是几个sp同时跑造成的，否则并发不应该突然间这么高的，查询相关信息，发现，有一个会话等待，类型就是library cache lock，是一个包里面的过程，网站下单的时候会实时调用，再仔细观察发现，同时还有2个过程也在跑，一个是订单分发的过程，job每隔半小时跑一次，还有一个是订单取消的过程，也是实时跑的.....眼看着血红色越来越高，紧急处理，只能在操作系统层面杀了一些会话，现在回想起来，为什么会出现这种事情，产生library cache lock等待事件的原因无外乎一下几种：

第一种情况，当会话1（session 1）在对一个表执行DML 或者 DDL，与此同时还有另一个会话（session 2），这个会话2也在对这个表执行DDL（如ALTER TABLE），当会话2的完成需要很长时间时（依操作的具体的数据量而定），会话1就会hang住，这时，你查询会话1的等待事件就是'Library cache lock'。

第二种情况，当会话1（session 1）在修改一个package，与此同时还有另一个会话（session 2），这个会话2正在执行会话1所修改的package中的Procedure或者Function，会话1就会hang住，这时，你查询会话1的等待事件就是'Library cache lock'。

因此，在对Package/Procedure/Function/View进行编译和分析的时候，我们必须确定此时没有人正在编译和分析相同的对象，即确保没有人也在此时改变这些需要重定义（drop和recreate）的对象。

有一点需要说明的是，这几个过程都是在同一个包里的，但是一直以来都没出什么问题啊，因此可以排除第一种情况，难道是那个时间点有人在重新编译包里的某个过程？我们DBA团队现在5个人，有2个新手，没权限做这种操作，还有我，我们主管以及经理，但是那时候我和我们主管都一直在监控数据库的运行，并没有做相关操作，有了这个疑问之后，今天抽烟的时候跟我们主管提了下，之后他问了我们经理，确实，那时候她正在编译包里的一个过程（开发出生的，不大了解管理方面的），原因应该就是这个了。

但是这个包里的过程，会频繁的被程序调取，改动也非常多，看来需要把相关的过程都独立出来，不放到同一个包里，因为在同一个包里的过程和函数，无论其中任何一个只要在执行中，编译这个包里的任何一个过程或者函数，都会锁住整个包，从而造成library cache lock这样的等待事件，接下来的工作就是商量如何修改这个包了，根据不同功能分别独立出来，相关截图如下：

lcl.jpg