P1,P2可与x$kglpn和x$kglob表相关 X$KGLOB (Kernel Generic Library Cache Manager Object) X$KGLPN (Kernel Generic Library Cache Manager Object Pins) -- 查询X$KGLOB,可找到相关的object,其SQL语句如下 (即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连) select kglnaown,kglnaobj from X...
2、 UPDATE操作SQL_ID "cn9fqrd5w0841" ,占用最高的等待事件为library cache lock和 "library cache: mutex X",需要通过AWR等其它手段继续排查 排查3 AWR和ASH报告 ASH部分: 对于library cache lock等待事件,这里的p3值是5373954,16进制为00520002,前面的4位0052代表namespace,后面的4位0002代表mode,而0052的10...
select a.sql_id,sql_fulltext from v$sql a,dba_hist_active_sess_history b where a.sql_id=b.sql_id and b.event='read by other session';往往read by other session伴随着db file sequential read事件的出现。 另外可以查看涉及对象信息,此处就是p1,p2,p3SELECTp1"file#",p2"block#",p3"class#"...
1、硬解析:latch: shared pool,硬解析需要所有类型的mutex,包括library cache: mutex,cursor: pin,HASH Table,cursor Parent 2、软解析:library cache: mutex,cursor: pin,HASH Table,cursor Parent 3、软软解析(将子游标堆6的信息,缓存在PGA中。子游标堆6:保存执行计划信息):两次cursor: pin S和一次library c...
1、这张表还有其他会话在用,然后就等待library cache lock,无效化相关cursor比较慢。 接下去是db file sequential read,可以看到p1,p2,p3一直在变化,所以会话不是hang,而是在运行。 经过进一步研究发现数据块等待的对象是 I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST,会话正在更新AWR报告相关视图的索引信息,所以比较慢。
Lock address: 锁的地址。 Mode: 被加载对象的数据片段。 Namespace: 被加载对象在v$db_object_cache 视图中namespace名称。 16. Library cache pin 这个等待事件和library cache lock 一样是发生在共享池中并发操作引起的事件。通常来讲,如果Oracle 要对一些PL/SQL 或者视图这样的对象做重新编译,需要将这些对象pin...
Event Name P1 P2 P3 DFS db file lock file# not used not used DFS lock handle type|mode id1 id2 KOLF: Register LFI close lfictx fileop 0 KOLF: Register LFI exists lfictx nameop 0 KOLF: Register LFI isopen lifctx nameop 0 KOLF: Register LFI length ...
Library cache lock parameter参数 P1 handle address: 对应于x$kg lob KGLHDADR、x$kg llk KGLHDADR P2 lock address: 对应于x$kg llk KGLLKADR P3 100*mode+namespace:拆分P3参数obj ect_id(8 bit)+namespace(4 bit)+lock mode(4bit),非DBA_OBJECT obj ect 前面8bit是0 SQL select to_char(...
两个事件期待对比多,依据p1,p2,p3 以及sid 检讨sql 语句,能否有调 优的可以==>db file scattered read 基本可以定性为FTS÷IFS 59。ibrary cache pi n 不library cache lock 是什举中央的期待事情, 个别说明什举问题? 解答:个别涌如今对package,procedure 迕行编译,add contraint ...
<11> library cache lock该事件通常是由于执行多个 18、DDL 操作导致的 ,即在 library cache object上添加一个排它锁后 ,又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可通过到基表x$kgllk 中查找其对应的对象。- 查询引起该等待事件的阻塞者的 sid 、会话用户、锁住的对象select b....