【DB】徹底搞清楚library cache lock的成因和解決方法(三)
前面我們已經知道碰到'library cache lock'導致程式hang時,如何解決。
那麼如何避免這類問題的發生呢?這篇文章主要介紹了library cache lock的成因以及如何避免。
當我們在執行一些DML,DDL,甚至desc tablename等等操作的時候,會話就hang住了,
還有一種情況,當我們使用create or replace procedure/function等語句修改Procedure和Function的時候,會話也會hang住,這是為什麼呢?
當出現上述情況的時候,我們可以透過v$session_wait查詢等待事件,當然,這種情況下,該session的等待事件一定是'Library cache lock'。
讓我們來解釋一下,
第一種情況,當會話1(session 1)在對一個表執行DML 或者 DDL,與此同時還有另一個會話,我們姑且稱之為會話2(session 2),這個會話2也在對這個表執行DDL(如ALTER TABLE),當會話2的完成需要很長時間時(依操作的具體的資料量而定),會話1就會hang住,這時,你查詢會話1的等待事件就是'Library cache lock'。
第二種情況,當會話1(session 1)在修改一個package,與此同時還有另一個會話,我們姑且稱之為會話2(session 2),這個會話2正在執行會話1所修改的package中的Procedure或者Function,會話1就會hang住,這時,你查詢會話1的等待事件就是'Library cache lock'。
因此,在對Package/Procedure/Function/View進行編譯和分析的時候,我們必須確定此時沒有人正在編譯和分析相同的物件,即確保沒有人也在此時改變這些需要重定義(drop和recreate)的物件的定義。
SQL> create or replace procedure who_is_using wrapped
2 0
3 abcd
4 abcd
5 abcd
6 abcd
7 abcd
8 abcd
9 abcd
10 abcd
11 abcd
12 abcd
13 abcd
14 abcd
15 abcd
16 abcd
17 abcd
18 abcd
19 7
20 200f000
21 1
22 4
23 0
24 1e
25 c WHO_IS_USING:
26 8 OBJ_NAME:
27 8 VARCHAR2:
28 b DBMS_OUTPUT:
29 6 ENABLE:
30 7 1000000:
31 1 I:
32 1 B:
33 8 USERNAME:
34 3 SID:
35 3 SYS:
36 7 X$KGLPN:
37 1 A:
38 9 V$SESSION:
39 7 X$KGLOB:
40 1 C:
41 8 KGLPNUSE:
42 1 =:
43 5 SADDR:
44 5 UPPER:
45 8 KGLNAOBJ:
46 4 LIKE:
47 8 KGLPNHDL:
48 8 KGLHDADR:
49 4 LOOP:
50 8 PUT_LINE:
51 1 (:
52 2 ||:
53 7 TO_CHAR:
54 4 ) - :
55 0
56
57 0
58 0
59 74
60 2
61 0 1d 9a 8f a0 b0 3d b4
62 55 6a :2 a0 6b 51 a5 57 91
63 :2 a0 6b :2 a0 6b ac :2 a0 6b a0
64 b9 :2 a0 b9 :2 a0 6b a0 b9 b2
65 ee :2 a0 6b a0 7e a0 6b b4
66 2e :3 a0 6b a5 b 7e :2 a0 a5
67 b b4 2e a 10 :2 a0 6b a0
68 7e a0 6b b4 2e a 10 ac
69 d0 e5 e9 37 :3 a0 6b 6e 7e
70 :3 a0 6b a5 b b4 2e 7e 6e
71 b4 2e 7e :2 a0 6b b4 2e a5
72 57 b7 a0 47 b7 a4 b1 11
73 68 4f 17 b5
74 74
75 2
76 0 3 4 19 15 14 20 13
77 25 29 2d 31 35 38 3b 3c
78 41 45 49 4d 50 54 58 5b
79 5c 60 64 67 11 6b 6f 73
80 75 79 7d 80 84 86 87 8e
81 92 96 99 9d a0 a4 a7 a8
82 ad b1 b5 b9 bc bd bf c2
83 c6 ca cb cd ce 1 d3 d8
84 dc e0 e3 e7 ea ee f1 f2
85 1 f7 fc fd 101 106 10b 10d
86 111 115 119 11c 120 123 127 12b
87 12f 132 133 135 136 13b 13e 142
88 143 148 14b 14f 153 156 157 15c
89 15d 162 164 168 16f 171 175 177
90 182 186 188 18f
91 74
92 2
93 0 1 b 18 21 :2 18 17 :2 1
94 2 :2 e 15 :2 2 6 1c :2 1e 27
95 :2 29 1c 11 15 11 1d 11 1f
96 29 1f 2b 2f 2b 37 2b c
97 11 12 :2 14 1f 1d :2 21 :2 1d 12
98 18 :2 1a :3 12 2a 30 :2 2a :5 12 :2 14
99 1f 1d :2 21 :2 1d :2 12 :4 c 2 2b
100 3 :2 f 18 1b 1d 25 :2 27 :2 1d
101 :2 18 2b 2d :2 18 33 35 :2 37 :2 18
102 :2 3 2b 6 2 :8 1
103 74
104 2
105 0 :9 1 :6 3 :8 4 :f 5 :9 6 :d 7 :2 6
106 :9 8 :2 6 5 :4 4 8 :19 9 8 a
107 4 :2 2 :6 1
108 191
109 2
110 :4 0 1 :a 0 70 1 1a 1b 5
111 :2 3 :3 0 2 :6 0 5 4 :3 0 7
112 :2 0 70 2 8 :2 0 4 :3 0 5
113 :3 0 a b 0 6 :2 0 7 c
114 e :2 0 6c 7 :3 0 8 :3 0 9
115 :3 0 11 12 0 8 :3 0 a :3 0
116 14 15 0 9 b :3 0 c :3 0
117 18 19 0 d :3 0 e :3 0 8
118 :3 0 1d 1e b :3 0 f :3 0 20
119 21 0 10 :3 0 22 23 c 25
120 49 0 4a :3 0 d :3 0 11 :3 0
121 27 28 0 8 :3 0 12 :2 0 13
122 :3 0 2a 2c 0 12 2b 2e :3 0
123 14 :3 0 10 :3 0 15 :3 0 31 32
124 0 10 30 34 16 :2 0 14 :3 0
125 2 :3 0 15 37 39 17 36 3b
126 :3 0 2f 3d 3c :2 0 d :3 0 17
127 :3 0 3f 40 0 10 :3 0 12 :2 0
128 18 :3 0 42 44 0 1c 43 46
129 :3 0 3e 48 47 :3 0 2 17 26
130 0 4b :5 0 4c :2 0 4e 10 4d
131 19 :3 0 4 :3 0 1a :3 0 50 51
132 0 1b :3 0 1c :2 0 1d :3 0 7
133 :3 0 a :3 0 56 57 0 1a 55
134 59 1f 54 5b :3 0 1c :2 0 1e
135 :3 0 22 5d 5f :3 0 1c :2 0 7
136 :3 0 9 :3 0 62 63 0 25 61
137 65 :3 0 28 52 67 :2 0 69 2a
138 6b 19 :3 0 4e 69 :4 0 6c 2c
139 6f :3 0 6f 0 6f 6e 6c 6d
140 :6 0 70 0 2 8 6f 72 :2 0
141 1 70 73 :6 0
142 2f
143 2
144 :3 0 1 3 1 6 1 d 2
145 13 16 3 1c 1f 24 1 33
146 2 29 2d 1 38 2 35 3a
147 1 58 2 41 45 2 53 5a
148 2 5c 5e 2 60 64 1 66
149 1 68 2 f 6b
150 1
151 4
152 0
153 72
154 0
155 1
156 14
157 2
158 3
159 0 1 0 0 0 0 0 0
160 0 0 0 0 0 0 0 0
161 0 0 0 0
162 2 0 1
163 3 1 0
164 10 2 0
165 0
166 /
Procedure created.
Elapsed: 00:00:00.07
SQL>
原文地址:http://blog.csdn.net/lunar2000/article/details/247611
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29487349/viewspace-2128015/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【DB】徹底搞清楚library cache lock的成因和解決方法(二)
- 【DB】徹底搞清楚library cache lock的成因和解決方法(一)
- 徹底搞清楚library cache lock的成因和解決方法(三)
- 徹底搞清楚library cache lock的成因和解決方法
- 徹底搞清楚library cache lock的成因和解決方法(轉)
- 徹底搞清楚library cache lock的成因和解決方法(1)
- 徹底搞清楚library cache lock的成因和解決方法(2)
- 徹底搞清楚library cache lock的成因和解決方法(3)
- 徹底搞清楚library cache lock的成因和解決方法(5)
- 徹底搞清楚library cache lock的成因和解決方法(4)
- 徹底搞清楚library cache lock的成因和解決方法(6)
- 徹底搞清楚library cache lock的成因和解決方法(8)
- 徹底搞清楚library cache lock的成因和解決方法(7)
- 定位Library Cache pin,Library Cache lock等待的解決方法
- 常用定位library cache lock的方法
- 【ASM_ORACLE】Library Cache最佳化篇(二)Library cache load lock的概念和解決辦法ASMOracle
- 'library cache lock'等待事件的處理方法事件
- library cache pin/lock的解決辦法
- zt_如何平面解決library cache lock和library cache pin
- Library Cache Pin 及 Library Cache Lock分析
- library cache lock和library cache pin理解
- RAC 環境Library Cache Lock的處理方法
- library cache pin和library cache lock的診斷分析
- LIBRARY CACHE LOCK 等待事件事件
- RAC環境Library Cache Lock的處理方法(zt)
- library cache lock和library cache pin區別總結
- [Oracle]--Library cache lock 故障解決一例Oracle
- oracle library cache之library cache lock_library cache pin wait event釋義OracleAI
- latch:library cache lock等待事件事件
- oracle異常:library cache lockOracle
- 短連線 引起的 library cache lock
- 查詢library cache lock的源頭
- enq:Library cache lock/pin等待事件ENQ事件
- library cache lock 阻塞程式查詢
- Library cache lock/pin詳解(轉)
- LIBRARY CACHE LOCK WAITS AND NO BLOCKER FOUNDAIBloC
- time_wait的成因和解決方案AI
- ORA-01502錯誤成因和解決方法