每一个进入库缓存的对象，在库缓存中都被按照本身内容分割成多块进行存贮。Oracle这样做的目的是为了更灵活的内存管理，因为在内存寻找大块连续的内存，总比寻找小块连续内存更慢一些.如果一个库缓存对象（如一条SQL语句的执行计划），它所占的内存被切割成4个小块，它们分别被存放在库缓存的各处，并且互不相连。为了将这4个小块组合起来，Oracle另外这个库缓存对象分配一小块内存，这块内存中存有其他4个小块内存的地址，并且，还有一些有关此库缓存对象的基本信息，如名字、类型等等，这块内存就叫库缓存对象句柄（handles）。
Library Cache结构示意图如下：
在访问库缓存对象时，比如软解析时，要从库缓存中读取执行计划。Oracle首先找到句柄，读取句柄中的信息，这就叫做一次库缓存Get。如果库缓存中不包括对象的句柄信息，Oracle就要重新在库缓存中分配内存、构造句柄，这就是库缓存句柄未命中（Get Miss）。相反，如果在库缓存中找到了对象句柄，就是库缓存句柄命中（Get Hit）。硬解析时，就会发生Get Miss。而软解析则是Get Hit。
在取出句柄中的其他内存块地址后，每访问一个内存块，都叫做一次库缓存Pin。如果相应的内存块已经不在内存中了，这就是Pin Miss，Pin的未命中。相反就是Pin Hit。
当库缓存中对象发生改变后，会引起其他一些对象的无效（Invalidation）。比如，你修改了一个表的结构，那么，选择了这个表的SQL语句的执行计划就会变的无效。其实大部分对表的DDL操作，都会造成相关SQL语句执行计划的无效。就连Grant（授权）、Revoke（撤消权限）这样看来跟执行计划耗无关系的操作，都会引起无效。如果有一个表TAB1，你发布了“Grant 某权限 on tab1 to 某用户”，或“revoke 某权限 on tabl from 某用户”这样的操作，那么，所有和TAB1表有关的执行计划都将无效。无效之后，库缓存对象除句柄外的所有内存块，都将被清除。再使用到对象后，必须重新加载对象。如上例，如果你对TAB1使用了DDL语句，那么所有使用了TAB1表语句的执行计划都将无效，你再使用这些语句时，就必须重新硬解析语句。
案例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
16
:
54
:
51
SCOTT@ prod>select *
from
dept1;
DEPTNO DNAME LOC
---------- -------------- -------------
10
ACCOUNTING NEW YORK
20
RESEARCH DALLAS
30
SALES CHICAGO
40
OPERATIONS BOSTON
Elapsed:
00
:
00
:
00.06
16
:
54
:
03
SYS@ prod> select NAMESPACE,GETS,PINS,RELOADS,INVALIDATIONS
from
v$librarycache
NAMESPACE GETS PINS RELOADS INVALIDATIONS
------------------------------ ---------- ---------- ---------- -------------
SQL AREA
7722
30134
30
97
TABLE/PROCEDURE
10906
8328
88
0
BODY
608
801
0
0
TRIGGER
24
41
0
0
INDEX
96
62
0
0
CLUSTER
485
300
0
0
QUEUE
36
168
0
0
APP CONTEXT
14
14
0
0
RULESET
3
3
0
0
SUBSCRIPTION
5
5
0
0
EDITION
58
99
0
0
DBLINK
5
0
0
0
OBJECT ID
59
0
0
0
SCHEMA
3584
0
0
0
DBINSTANCE
1
0
0
0
15
rows selected.
Elapsed:
00
:
00
:
00.01
在访问对象dept1上，做DDL操作，导致原来的执行计划变得无效
16
:
55
:
01
SCOTT@ prod>grant all
on
dept1 to hr;
Grant succeeded.
Elapsed:
00
:
00
:
00.26
16
:
55
:
24
SCOTT@ prod>select *
from
dept1;
DEPTNO DNAME LOC
---------- -------------- -------------
10
ACCOUNTING NEW YORK
20
RESEARCH DALLAS
30
SALES CHICAGO
40
OPERATIONS BOSTON
Elapsed:
00
:
00
:
00.04
16
:
55
:
29
SCOTT@ prod>
16
:
55
:
08
SYS@ prod>r
1
* select NAMESPACE,GETS,PINS,RELOADS,INVALIDATIONS
from
v$librarycache
NAMESPACE GETS PINS RELOADS INVALIDATIONS
------------------------------ ---------- ---------- ---------- -------------
SQL AREA
7781
30422
32
100
TABLE/PROCEDURE
10980
8420
88
0
BODY
623
817
0
0
TRIGGER
26
43
0
0
INDEX
96
62
0
0
CLUSTER
488
302
0
0
QUEUE
36
168
0
0
APP CONTEXT
14
14
0
0
RULESET
3
3
0
0
SUBSCRIPTION
5
5
0
0
EDITION
59
101
0
0
DBLINK
5
0
0
0
OBJECT ID
59
0
0
0
SCHEMA
3595
0
0
0
DBINSTANCE
1
0
0
0
15
rows selected.
Elapsed:
00
:
00
:
00.03
16
:
55
:
34
SYS@ prod>
|
因此，使用DDL语句是需要注意的，如果没有要求立即使用DDL，我们最好等到数据库并不繁忙的时刻，再执行DDL。作为DBA，这一点一定要牢记，除非要求立即执行，否则等到数据库并不繁忙时再执行任何DDL。
再补充一点，无效和库缓存对象的老化并不一样。老化是连句柄带对象的所有内存块都被清除出去了。而无效是只在库缓存中保留对象句柄，但所有其他内存块都被清除出去。对于无效的对象，当再次重新调用到它时，Oracle会再次将它调入到库缓存中，这个操作被称为Reload。一般说来，Reload与Get是无关的，因为Reload是在对象无效后才发生的，而对象的无效并不影响对象句柄。好，说了这么多，下面我们来看这些值的意义。
我们已经讲述了Get、Pin与它们的命中、未命中，还有什么是Invalidation和Reload。在OLTP系统中，Get的命中率应该在90%之上。而Reload和Pin的次数的比值，应该小于1%。如果超出了这些数值范围，就说明库缓存的使用有问题。问题的原因主要有两个，没有使用绑定变量或是库缓存太小。不过Reload和Pin的比例过高，也可能是在繁忙时执行了DDL所导致的。
另外，V$librarycache的第一列是NAMESPACE，也就是名称空间。它相当于存储在库缓存中对象的类型。具体的名称空间是什么意思呢？就是对象的名字所在的范围，比如表和列的名字就不在一个范围内。也就是说表名和列名可以重复，还有用户名和表、列也不在同一范围内，用户名也可以和表、列名相同。我可以有个叫做AA的表，也可以有叫做AA的用户。这两个AA处在不同的范围内，也就明它们的名称空间不同。这就好像在北京有个电话号码是12345678，在上海也有个12345678，这两个电话号码虽然相同，但不会引起问题，因为它们在不同的范围内。这个范围，也可以说是类型。
我显示一下V$librarycache的所有行（列只有一部分）：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
SQL> select *
from
v$librarycache;
NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITS
--------------- ---------- --------------------- ---------- ----------
SQL AREA
21811
4149
.190225116
120258
105272
TABLE/PROCEDURE
25152
16372
.650922392
60649
46008
BODY
4360
4098
.939908257
5931
5537
TRIGGER
320
251
.784375
1655
1576
INDEX
453
128
.282560706
2065
1531
CLUSTER
755
728
.964238411
2339
2296
OBJECT
0
0
1
0
0
PIPE
0
0
1
0
0
JAVA SOURCE
0
0
1
0
0
JAVA RESOURCE
0
0
1
0
0
JAVA DATA
0
0
1
0
0
|
可以看在库缓存中共有11个名称空间，我们基本上可以说库缓存中有11种类型的信息。有一个非常重要的指标，就是库缓存命中率，这个命中率就是库缓存中所有对象的GETHITRAIO，它的计算方法如下：
select 1-sum(gethits)/sum(gets) fromv$librarycache;
这个比率应该在90%以上。
还有一个比率也很重要，就是Reload和Pin的比值，这个比值应该小于1%。
如果没有达到这些比例，解决方法很简单，问题或者是SQL语句没有共享，或者是共享池太小。
有关库缓存命中率，也可以查看STATSPACK报告中的Library Hit %项。这个我们上面已经说过了。
Library cache lock、Library cache pin等待事件
等待事件在Oracle中无处不在，为了记录这些数据，是损失了一些性能。但是你是想出了问题一筹莫展好，还是可以利用等待事件或各种资料轻松的查找出问题在哪好呢？而且，这些等待事件和资源你即使不去用它，Oracle一样会消耗CPU去记载它们。因此，一个好的DBA一定要对各种等待事件、资料了如指掌。下面，我们介绍两个和库缓存相关的等待事件，如题，就是Library cache lock和Library cache pin。
我们上面说到库缓存中的对象在库缓存中被切割成多个内存块，另有一个对象句柄记录了各个内存块的地址和其他的一些信息。当你要修改句柄中的信息时，需要在句柄上加独占锁，而如果另一个进程恰好在这时要求读、写句柄中的信息，它就必须等待。此时的等待就被Oracle记入Library cache lock事件。而读、写对象内存块也是无法同时进行的，有人如果正在写，你的读操作就必须等待，读写内存块的等待事件就是Library cache pin。如果这两个等待事件过多，同样说明了库缓存过小或没有共享执行计划。或者，当你在数据库繁忙时使用DDL时，也会有这两个等待事件。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
案例
1
：
业务运行前：
17
:
07
:
30
SYS@ prod>select name,GETS,MISSES
from
v$latch
where
upper(name) like
'%LIBRARY%'
OR upper(name) like
'%SHARE%'
;
NAME GETS MISSES
---------------------------------------------------------------- ---------- ----------
test shared non-parent l0
0
0
ksxp shared latch
0
0
kcfis stats shared latch
0
0
shared pool
126676
61
library cache load lock
0
0
shared pool simulator
6576
0
shared pool sim alloc
45
0
Shared B-Tree
302
0
shared server configuration
6
0
shared server info
1
0
运行业务：
17
:
08
:
34
SCOTT@ prod>begin
17
:
08
:
38
2
for
i
in
1.
.100000
loop
17
:
08
:
52
3
execute immediate
'insert into t1 values ('
||i||
')'
;
17
:
09
:
18
4
end loop;
17
:
09
:
26
5
end;
17
:
09
:
27
6
/
PL/SQL procedure successfully completed.
业务运行后：
17
:
11
:
05
SYS@ prod>select name,GETS,MISSES
from
v$latch
where
upper(name) like
'%LIBRARY%'
OR upper(name) like
'%SHARE%'
NAME GETS MISSES
---------------------------------------------------------------- ---------- ----------
test shared non-parent l0
0
0
ksxp shared latch
0
0
kcfis stats shared latch
0
0
shared pool
4526672
214
library cache load lock
0
0
shared pool simulator
1086437
0
shared pool sim alloc
2048
0
Shared B-Tree
316
0
shared server configuration
6
0
shared server info
1
0
10
rows selected.
17
:
15
:
42
SYS@ prod>select sid,event,WAIT_TIME,state
from
v$session_wait
where
sid=
42
SID EVENT WAIT_TIME STATE
---------- ---------------------------------------------------------------- ---------- -------------------
42
latch: shared pool
-1
WAITED SHORT TIME
Elapsed:
00
:
00
:
00.08
案例
2
：
业务运行前：
17
:
18
:
35
SYS@ prod>select sid,EVENT,TOTAL_WAITS,AVERAGE_WAIT
from
v$session_event
where
sid
in
(
42
,
46
);
SID EVENT TOTAL_WAITS AVERAGE_WAIT
---------- ---------------------------------------------------------------- ----------- ------------
42
Disk file operations I/O
4
.03
42
log file switch (
private
strand flush incomplete)
1
10.03
42
log file sync
4
1.76
42
db file sequential read
385
.23
42
latch: row cache objects
5
.44
42
latch: shared pool
194
.25
42
SQL*Net message to client
24
0
42
SQL*Net message
from
client
23
5318.9
42
SQL*Net
break
/reset to client
2
.08
42
events
in
waitclass Other
1
0
46
Disk file operations I/O
1
.03
46
db file sequential read
33
.02
46
SQL*Net message to client
13
0
46
SQL*Net message
from
client
12
79.9
14
rows selected.
运行业务：
17
:
16
:
39
SYS@ prod>select sid ,username
from
v$session
where
username is
not
null
;
SID USERNAME
---------- ------------------------------
1
SYS
42
SCOTT
46
HR
17
:
17
:
22
SCOTT@ prod>begin
17
:
20
:
46
2
for
i
in
1.
.100000
loop
17
:
20
:
52
3
execute immediate
'insert into t1 values ('
||i||
')'
;
17
:
20
:
58
4
end loop;
17
:
21
:
02
5
end;
17
:
21
:
05
6
/
PL/SQL procedure successfully completed.
17
:
17
:
42
HR@ prod>begin
17
:
21
:
16
2
for
i
in
1.
.100000
loop
17
:
21
:
24
3
execute immediate
'insert into scott.t1 values ('
||i||
')'
;
17
:
21
:
49
4
end loop;
17
:
21
:
51
5
end;
17
:
21
:
52
6
/
PL/SQL procedure successfully completed.
业务运行后：
17
:
22
:
32
SYS@ prod>select sid,EVENT,TOTAL_WAITS,AVERAGE_WAIT
from
v$session_event
where
sid
in
(
42
,
46
);
SID EVENT TOTAL_WAITS AVERAGE_WAIT
---------- ---------------------------------------------------------------- ----------- ------------
42
Disk file operations I/O
4
.03
42
latch: cache buffers chains
16
.18
42
buffer busy waits
2
.15
42
log file switch (
private
strand flush incomplete)
1
10.03
42
log file sync
4
1.76
42
db file sequential read
413
.21
42
latch: row cache objects
58
.13
42
latch: shared pool
1008
.19
42
library cache: mutex X
123
.33
42
SQL*Net message to client
24
0
42
SQL*Net message
from
client
24
6044.43
42
SQL*Net
break
/reset to client
2
.08
42
events
in
waitclass Other
87
.09
46
Disk file operations I/O
3
.03
46
latch: cache buffers chains
13
.21
46
buffer busy waits
1
.35
46
latch: redo copy
1
1.26
SID EVENT TOTAL_WAITS AVERAGE_WAIT
---------- ---------------------------------------------------------------- ----------- ------------
46
db file sequential read
38
.02
46
enq: HW - contention
1
.01
46
latch: row cache objects
58
.14
46
row cache lock
1
.08
46
latch: shared pool
666
.17
46
library cache: mutex X
99
.29
46
SQL*Net message to client
13
0
46
SQL*Net message
from
client
13
2010.63
46
events
in
waitclass Other
68
.14
26
rows selected.
Elapsed:
00
:
00
:
00.37
17
:
22
:
42
SYS@ prod>
17
:
22
:
02
SYS@ prod>select sid,event,WAIT_TIME,state
from
v$session_wait
where
sid=
42
17
:
22
:
25
2
or
sid=
46
;
SID EVENT WAIT_TIME STATE
---------- ---------------------------------------------------------------- ---------- -------------------
42
latch: shared pool
-1
WAITED SHORT TIME
46
latch: shared pool
-1
WAITED SHORT TIME
|
以上博文参考了其他博主的部分内容，这里表示感谢！
