oracle 高峰期谨慎编译业务对象 引起library cache lock/pin
当我们编译存储过程、函数或视图的时候,Oracle就会在这些对象的handle上获得一个“ library cache lock”,然后在这些 对象的heap上获得pin,这样就能保证在编译的时候其他进程不会来更改这些对象。 有了以上的理论基础,当高峰期编译对象出现会话堵塞的问题时,我们应该如何处理呢?这里就会用到基表 DBA_KGLLOCK,其包含如下两个字段。 ·kgllkuse字段:“ Address of the user session that holds the lock or pin”,主要用于记录持有lock或pin的用户地址。 ·kgllkhdl字段:“ Address of the handle for the KGL object”,主要用于记录handle的对象地址。 故障发生时,首先查看后台等待事件,命令及输出具体如下: SQL> select inst_id,sid, event, p1,p1text,p1raw,p2,p2text,p2raw from gv$session where wait_class<>'Idle'; INST_ID SID EVENT P1 P1TEXT P1RAW ------- ---- ------------------ ------------------------- ---------------- 1 33 library cache pin 2081944584 handle address 000000007C17F408 根据等待事件“ library cache pin”获取“ p1 handle address 000000007C17F408”。 关联视图“ dba_kgllock dk,v$session”获取锁信息,命令及输出如下: SQL> select s.sid,s.sql_id,s.event,dk.* from dba_kgllock dk,v$session s where s.saddr = dk.KGLLKUSE and KGLLKHDL='000000007C17F408'; SID SQL_ID EVENT KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL --- ------------ ------------- ------------------- ---------------- -------- -------- ---- 33 087rrdjwc2act library cache pin 00000000A92FC040 000000007C17F408 3 0 Lock 33 087rrdjwc2act library cache pin 00000000A92FC040 000000007C17F408 0 3 Pin 从以上返回结果中可以看出,我们并没有找到pin的持有者,KGLLKREQ表示当前会话需要申请的锁模式, KGLLKMOD表示当前系统中持有的锁模式,由于该系统为RAC,各节点之间的内存结构不同,handle地址不能公用,因此 我们需要定位出owner和object_name在其他节点持有pin的会话。命令及输出如下: SQL> select ADDR,INDX,INST_ID,KGLHDADR,KGLNAOWN,KGLNAOBJ from x$kglob where KGLHDADR='000000007C17F408'; ADDR INDX INST_ID KGLHDADR KGLNAOWN KGLNAOBJ ---------------- ---- ------- ---------------- ---------- --------- 00007FE9B0B45850 4979 1 000000007C17F408 SYS DUMMY 其中,x$kglob为“ library cache object”对象的视图。 RAC节点2根据object_name查找对应的handle地址信息,命令及输出如下: SQL> select ADDR,INDX,INST_ID,KGLHDADR,KGLNAOWN,KGLNAOBJ from x$kglob where KGLNAOBJ='DUMMY' ADDR INDX INST_ID KGLHDADR KGLNAOWN KGLNAOBJ ---------------- ---- ------- ---------------- --------- --------- 00007F987B1D8ED0 4150 2 00000000AA193870 SYS DUMMY 查看锁的持有情况,命令及输出如下: SQL> select s.sid,s.sql_id,s.event,dk.* from dba_kgllock dk,v$session s where s.saddr = dk.KGLLKUSE and KGLLKHDL='00000000AA193870'; SID SQL_ID EVENT KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL --- ------------ ----------------- ---------------- ---------------- -------- -------- ---- 424 d4wnj5j8y1mq7 PL/SQL lock timer 00000000A9787DA0 00000000AA193870 1 0 Lock 424 d4wnj5j8y1mq7 PL/SQL lock timer 00000000A9787DA0 00000000AA193870 2 0 Pin 最终定位节点2上的会话424持有的模式为2(即共享模式)的锁,堵塞了KGLLKREQ 3排它锁的申请,为了能够顺利 编译,我们只需要杀掉节点2上的会话424即可。
本文来自博客园,作者:蚌壳里夜有多长,转载请注明原文链接:https://www.cnblogs.com/dbahrz/p/17390365.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库