请教间歇式的library cache lock等待解决思路

laobu

请教各位：
对于间歇式的library cache lock有什么思路？
环境及版本：aix5.3+10.2.0.4.12+rac
现象：每隔几分钟（有规律但并不是严格周期性的），会出现一批library cache lock，相关的一些实时业务会超时几秒钟，然后恢复正常、再反复。
不同于那种DDL或编译存储过程引起的library cahce lock会引起长时间的挂起，只要找到根源杀掉进程就OK；
这次的情况不同，查询x$kgllk、systemstate都没有线索，我想是因为等待转瞬即逝抓不到
需要补充的是，只有library cache lock，没有library cache pin，没有shared_pool
10天前，该问题出现过，逐一重启了所有应用，无效；打算重启库，但现象自动消失了，历时大约11小时，最后还是重启了库；今天问题重现。

Maclean Liu(刘相兵

ASH!

laobu

Maclean Liu(刘相兵 发表于 2013-1-6 17:00
ASH!

上传了两个节点的ash,awr,alert.log
谢谢

444560.1提到：
How can Library cache lock be reduced?
In general , high contention on library cache lock is usually a result of an under-sized shared pool or non-sharing of sql. Some ways of reducing the contention are:
    Reduce the reloads by increasing the shared pool size as the locks may take a long time if the pool is undersized.
    Increase sharing by setting the cursor_sharing to similar or force.
    Be aware this may change the execution plan; so setting the parameter should be thoroughly tested.
我试着做过：
cursor_sharing从exact改到similar/force，无效，而且并没有shared pool事件，看来与解析无关
另外，没有使用SGA自动管理，shared_pool手工设置为6G

laobu

OEM chart:  average active sessions

Liu Maclean(刘相兵

laobu 发表于 2013-1-6 18:07
OEM chart:  average active sessions

说ASH不是让你看一个 ASH的视图

ASH每秒采样一次
ASH的历史数据 DBA_HIST_ACTIVE_SESS_HISTORY 记录了大量历史的等待信息，其中可能就有历史的library cache lock信息 ， 这对针对是最好的资源

psufnxk2000

压力山大的库， 关注

laobu

Liu Maclean(刘相兵 发表于 2013-1-6 22:03
说ASH不是让你看一个 ASH的视图

ASH每秒采样一次

谢谢，明白这个意思
我贴那个图，是因为图表能够很好地表达该问题间歇发作的特征

这次问题的特殊之处就在于，涉及的session/sql/object/handler都不固定
试图通过ash找到些规律，最终还是没头绪
       
故障历时比较长了，brief一下：
1、故障现象总是在业务繁忙的时段才出现，上午开始，晚上业务减少后故障现象自动消失，中午业务略少，等待事件也略少
2、第一次出现的当晚重启了数据库，之后几天一直正常
3、大概10天后第二次出现，到第六天现象神秘消失，至今仍正常

开了SR，support分析了一些systemstate后（上传大文件真艰难啊），发现一些特殊的blocker:DBMS_STANDARD
据此认为与BUG有关
Bug 11768116 : MANY 'CURSOR: PIN S WAIT ON X'
The bug is closed as duplicate to
Bug 6196596 : GES LOCK OPERATION FOR A RESOURCE CAN HANG
But for 10.2.0.4 we don't have any patch released for 10.2.0.4 ,it only fixed on version 10.2.0.5 for Aix

排查期间，各方支持力量提出过各种怀疑：
1、SGA自动管理的问题？否定，是手动管理的
2、SQL共享相关？把cursor_sharing改为force，无效
3、interconnect问题？oswatcher显示互联没问题，且千兆卡流量峰值在80MB左右，还没到性能瓶颈
4、version_count相关BUG？ BUG是有且没打相关补丁，但做了检查脚本一旦发现有version_count>20000即执行flush，实际上每天每实例会执行一到两次。每次flush之后是会有些latch等待，但不论flush之前还是之后、version_count是大是小，library cache lock的现象没变化
5、audit trigger引发DBMS_STANDARD？检查trigger排除
5、CPU/MEM资源都很充分，盘阵的IO能力更是潜力巨大

最后，问题神秘消失了。
10.2.0.5暂且不升，除非问题重现且影响严重。
年内已有调整硬件顺便升11.2的计划。

继续观察