ITPub博客

首页 > Linux操作系统 > Linux操作系统 > library cache lock等待事件

library cache lock等待事件

原创 Linux操作系统 作者:skuary 时间:2011-12-30 11:54:56 0 删除 编辑

昨天下午快下班的时候,通过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

addm.jpg

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25618347/viewspace-714241/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 下一阶段
请登录后发表评论 登录
全部评论

注册时间:2011-03-31

  • 博文量
    88
  • 访问量
    317173