oracle 10049 event之library cache lock
測試環境:windows 7 oracle 10.2.0.1
測試過程
SQL> create table t_table(a int);
Table created.
SQL> select /*+first*/ count(1) from t_table;
COUNT(1)
----------
0
SQL> select sql_text,hash_value from v$sql where sql_text like '%first%';
SQL_TEXT
-----------------------------------------------------------------------------
HASH_VALUE
----------
select sql_text,hash_value from v$sql where sql_text like '%first%'
1129238428
select /*+first*/ count(1) from t_table
1896708881
---獲取hash value的後2個位元組即7b11
SQL> select to_char(1896708881,'xxxxxxxxxxxxxx') from dual;
TO_CHAR(1896708
---------------
710d7b11
---2030即10049 event分析跟蹤library cache lock and library cache pin
確定10049針對單個sql的level值的演算法如下:
首先,10049的level可能會有如下一些值:
#define KGLTRCLCK 0x0010/* trace lock operations */
#define KGLTRCPIN 0x0020/* trace pin operations */
#define KGLTRCOBF 0x0040 /* trace objectfreeing */
#define KGLTRCINV 0x0080 /* traceinvalidations */
#define KGLDMPSTK 0x0100 /* DUMP CALL STACKWITH TRACE */
#define KGLDMPOBJ 0x0200 /* DUMP KGL OBJECTWITH TRACE */
#define KGLDMPENQ 0x0400 /* DUMP KGL ENQUEUE WITH TRACE */
#define KGLTRCHSH 0x2000/* DUMP BY HASH VALUE */
----10049 event level為hash value的後2個位元組+上述2030的組合,轉化為十進位制即可
SQL> select to_number('7b112030','xxxxxxxxxxxxxx') from dual;
TO_NUMBER('7B112030','XXXXXXXXXXXXXX')
--------------------------------------
2064719920
---oradebug分析
SQL> oradebug setmypid
Statement processed.
SQL> oradebug event 10049 trace name context forever,level 2064719920
Statement processed.
---分析的sql
SQL> select /*+first*/ count(1) from t_table;
COUNT(1)
----------
0
SQL> oradebug tracefile_name
d:\oracle\product\10.2.0\db_1\admin\orcl\udump\orcl_ora_12856.trc
SQL>
KGLTRCLCK kglget hd = 0x9092E758 KGL Lock addr = 0x8EBD8680 mode = N
KGLTRCLCK kglget hd = 0x90853ABC KGL Lock addr = 0x8EBD8290 mode = N
KGLTRCPIN kglpin hd = 0x90853ABC KGL Pin addr = 0x8EB52B00 mode = S
KGLTRCPIN kglpndl hd = 0x90853ABC KGL Pin addr = 0x8EB52B00 mode = S
KGLTRCLCK kgllkdl hd = 0x90853ABC KGL Lock addr = 0x8EBD8290 mode = N
KGLTRCLCK kgllkdl hd = 0x9092E758 KGL Lock addr = 0x8EBD8680 mode = N
小結:1,可知獲取了以null mode的library cache lock及shared mode的library cache pin
2,此為二次解析,即軟解析
測試下硬解析情況
-----檢視下ddl操作持library cache lock及library cache pin的變化情況
SQL> oradebug setmypid
Statement processed.
SQL> oradebug event 10049 trace name context forever,level 528
Statement processed.
SQL> alter table t_table add b int;
Table altered.
SQL> oradebug tracefile_name
d:\oracle\product\10.2.0\db_1\admin\orcl\udump\orcl_ora_12856.trc
SQL>
--------自trace可知在alter table add 操作期間頭尾會持x mode的librache cache lock,中間為null mode 的library cache lock
------所以說會在alter 操作時阻塞select操作(根據hash value 過濾即得到如下記錄
GLTRCLCK kglget hd = 0x90928C6C KGL Lock addr = 0x8EBD8450 mode = X
LIBRARY OBJECT HANDLE: handle=90928c6c mutex=90928D20(0)
name=SYS.T_TABLE
hash=e7aa8d8cb1072affe5729af178f71f15 timestamp=04-24-2013 16:08:10
KGLTRCLCK kglget hd = 0x90928C6C KGL Lock addr = 0x8EBD83E0 mode = N
LIBRARY OBJECT HANDLE: handle=90928c6c mutex=90928D20(0)
name=SYS.T_TABLE
hash=e7aa8d8cb1072affe5729af178f71f15 timestamp=04-24-2013 16:08:10
KGLTRCLCK kgllkdl hd = 0x90928C6C KGL Lock addr = 0x8EBD83E0 mode = N
LIBRARY OBJECT HANDLE: handle=90928c6c mutex=90928D20(0)
name=SYS.T_TABLE
hash=e7aa8d8cb1072affe5729af178f71f15 timestamp=04-24-2013 16:08:10
GLTRCLCK kgllkdl hd = 0x90928C6C KGL Lock addr = 0x8EBD8450 mode = X
LIBRARY OBJECT HANDLE: handle=90928c6c mutex=90928D20(0)
name=SYS.T_TABLE
hash=e7aa8d8cb1072affe5729af178f71f15 timestamp=04-24-2013 16:31:22
---看下alter table modify情況
同上,也是首尾持x mode library cache lock,中間為null mode的library cache lock
--再看下alter table drop column, 與alter table modify column與alter table add column不同,先是持s mode的library cache lock,然後持null mode的
--library cache lock,再接著持null mode,最後持x;
KGLTRCLCK kglget hd = 0x909000C0 KGL Lock addr = 0x8A39A6F8 mode = S
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
KGLTRCLCK kglget hd = 0x909000C0 KGL Lock addr = 0x8A39A538 mode = S
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:23
namespace=TABL flags=KGHP/TIM/SML/[02000000]
KGLTRCLCK kgllkdl hd = 0x909000C0 KGL Lock addr = 0x8A39A538 mode = S
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:23
KGLTRCLCK kgllkdl hd = 0x909000C0 KGL Lock addr = 0x8A39A6F8 mode = S
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:23
namespace=TABL flags=KGHP/TIM/SML/[02000000]
KGLTRCLCK kglget hd = 0x909000C0 KGL Lock addr = 0x8A39A538 mode = X
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:23
namespace=TABL flags=KGHP/TIM/SML/[02000000]
KGLTRCLCK kgllkdl hd = 0x909000C0 KGL Lock addr = 0x8A39A6F8 mode = N
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:23
namespace=TABL flags=KGHP/TIM/FUL/FUP/SML/[0e000000]
KGLTRCLCK kgllkdl hd = 0x909000C0 KGL Lock addr = 0x8A39A538 mode = X
LIBRARY OBJECT HANDLE: handle=909000c0 mutex=90900174(0)
name=SCOTT.T_NEW
hash=56af4db26991e4855c5bd5eb4390bf91 timestamp=04-24-2013 19:33:37
namespace=TABL flags=KGHP/TIM/FUL/SML/[06000000]
小結:1,alter table drop column與其它的ddl不同
2,大併發的生產環境下,千萬別隨便alter table,不然會造成其它併發會話的hang,即競爭library cache lock
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9240380/viewspace-759214/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- zt_如何使用event 10049分析定位library cache lock and library cache pin
- oracle library cache之library cache lock_library cache pin wait event釋義OracleAI
- 【TUNE_ORACLE】等待事件之“library cache lock”Oracle事件
- oracle異常:library cache lockOracle
- Library Cache Pin 及 Library Cache Lock分析
- library cache lock和library cache pin理解
- oracle11g之v$libcache_locks處理library cache lock及library cache pinOracle
- LIBRARY CACHE LOCK 等待事件事件
- 設定事件10049跟蹤遊標上的library cache lock/pin獲取過程事件
- library cache pin和library cache lock的診斷分析
- library cache lock和library cache pin區別總結
- [Oracle]--Library cache lock 故障解決一例Oracle
- latch:library cache lock等待事件事件
- 深入理解shared pool共享池之library cache的library cache lock系列四
- 定位Library Cache pin,Library Cache lock等待的解決方法
- zt_如何平面解決library cache lock和library cache pin
- enq:Library cache lock/pin等待事件ENQ事件
- library cache lock 阻塞程式查詢
- Library cache lock/pin詳解(轉)
- 常用定位library cache lock的方法
- LIBRARY CACHE LOCK WAITS AND NO BLOCKER FOUNDAIBloC
- Library cache pin/lock 在Oracle 10g的增強Oracle 10g
- oracle library cache之trace小記Oracle
- Oracle Library cacheOracle
- 短連線 引起的 library cache lock
- 查詢library cache lock的源頭
- 【ASM_ORACLE】Library Cache最佳化篇(二)Library cache load lock的概念和解決辦法ASMOracle
- 11G資料庫之library cache lock及library cache pin模擬結合hanganalyze定位資料庫
- 【ASK_ORACLE】Library Cache概念篇(二)之Library Cache Pin的定義Oracle
- 【ASK_ORACLE】Library cache pin 與 library load lock的關係和區別Oracle
- oracle11g之expdp產生library cache lock及tablespace autoextend off_alert logOracle
- 通過dump library cache分析與學習oracle易碎解析鎖v$lock之系列十Oracle
- 一次library cache lock 問題分析
- library cache pin/lock的解決辦法
- zt_library cache pin和lock等待分析
- 尋找 library cache lock 等待事件的session事件Session
- 'library cache lock'等待事件的處理方法事件
- 俺也談談 library cache lock 等待事件事件