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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【TUNE_ORACLE】等待事件之“library cache lock”Oracle事件
- library cache pin和library cache lock(一)
- library cache pin和library cache lock (zt)
- library cache pin和library cache lock(二)
- library cache lock和library cache bin實驗_2.0
- Library Cache最佳化篇(一)降低library cache lock和library cache pin的方法
- latch:library cache lock等待事件事件
- Oracle Library cacheOracle
- [20240920]跟蹤library cache lock library cache pin使用gdb.txt
- [20240824]跟蹤library cache lock library cache pin使用gdb.txt
- 【ASM_ORACLE】Library Cache最佳化篇(二)Library cache load lock的概念和解決辦法ASMOracle
- 【ASK_ORACLE】Library cache pin 與 library load lock的關係和區別Oracle
- 【ASK_ORACLE】Library Cache概念篇(二)之Library Cache Pin的定義Oracle
- 【TUNE_ORACLE】等待事件之“library cache pins”Oracle事件
- Library Cache 診斷:Lock, Pin 以及 Load Lock (文件 ID 1548524.1)
- Oracle 11g 密碼延遲認證與 library cache lock 等待Oracle密碼
- 一次library cache lock 問題分析
- [20241105]跟蹤library cache lock library cache pin使用gdb(11g)2.txt
- [20241108]跟蹤library cache lock library cache pin使用gdb(11g)4.txt
- [20241108]跟蹤library cache lock library cache pin使用gdb(11g)3.txt
- [20201120]使用event 10049.txt
- Oracle11g 密碼延遲認證導致library cache lock的情況分析Oracle密碼
- 徹底搞清楚library cache lock的成因和解決方法(轉)
- Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1OracleENQ
- [20220301]oracle如何定位使用library cache mutex.txtOracleMutex
- [20240827]分析為什麼出現library cache lock等待事件2.txt事件
- [20240828]分析為什麼出現library cache lock等待事件5.txt事件
- [20220302]oracle如何定位使用library cache mutex 2.txtOracleMutex
- [20220303]oracle如何定位使用library cache mutex 3.txtOracleMutex
- library cache pin(轉)
- 重啟大法失效?詳述Oracle11g因JDBC bug引發異常Library Cache Lock等待處理事件OracleJDBC事件
- 【等待事件】library cache pin事件
- Python多程式之Process、Pool、Lock、Queue、Event、Semaphore、PipePython
- [20190402]Library Cache mutex.txtMutex
- [20210507]dump library_cache.txt
- ORACLE基礎之oracle鎖(oracle lock mode)詳解Oracle
- 故障:核心表業務高峰期授權導致library cache lock和mutex x競爭Mutex
- [20210507]分析library cache轉儲.txt
- 當刪除oracle資料庫user時發生row cache lock 等待事件Oracle資料庫事件