溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“Oracle Library Cache的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Oracle Library Cache的示例分析”這篇文章吧。
Oracle Library Cache深入解析
每一個進入庫緩存的對象，在庫緩存中都被按照本身內容分割成多塊進行存貯。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表語句的執行計劃都將無效，你再使用這些語句時，就必須重新硬解析語句。
案例：
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的所有行（列只有一部分）：
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：
業務運行前：
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以上是“Oracle Library Cache的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
