溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“Oracle Library Cache的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Oracle Library Cache的示例分析”這篇文章吧。
Oracle Library Cache深入解析
每一個(gè)進(jìn)入庫緩存的對象，在庫緩存中都被按照本身內(nèi)容分割成多塊進(jìn)行存貯。Oracle這樣做的目的是為了更靈活的內(nèi)存管理，因?yàn)樵趦?nèi)存尋找大塊連續(xù)的內(nèi)存，總比尋找小塊連續(xù)內(nèi)存更慢一些.如果一個(gè)庫緩存對象（如一條SQL語句的執(zhí)行計(jì)劃），它所占的內(nèi)存被切割成4個(gè)小塊，它們分別被存放在庫緩存的各處，并且互不相連。為了將這4個(gè)小塊組合起來，Oracle另外這個(gè)庫緩存對象分配一小塊內(nèi)存，這塊內(nèi)存中存有其他4個(gè)小塊內(nèi)存的地址，并且，還有一些有關(guān)此庫緩存對象的基本信息，如名字、類型等等，這塊內(nèi)存就叫庫緩存對象句柄（handles）。
Library Cache結(jié)構(gòu)示意圖如下：
在訪問庫緩存對象時(shí)，比如軟解析時(shí)，要從庫緩存中讀取執(zhí)行計(jì)劃。Oracle首先找到句柄，讀取句柄中的信息，這就叫做一次庫緩存Get。如果庫緩存中不包括對象的句柄信息，Oracle就要重新在庫緩存中分配內(nèi)存、構(gòu)造句柄，這就是庫緩存句柄未命中（Get Miss）。相反，如果在庫緩存中找到了對象句柄，就是庫緩存句柄命中（Get Hit）。硬解析時(shí)，就會(huì)發(fā)生Get Miss。而軟解析則是Get Hit。
在取出句柄中的其他內(nèi)存塊地址后，每訪問一個(gè)內(nèi)存塊，都叫做一次庫緩存Pin。如果相應(yīng)的內(nèi)存塊已經(jīng)不在內(nèi)存中了，這就是Pin Miss，Pin的未命中。相反就是Pin Hit。
當(dāng)庫緩存中對象發(fā)生改變后，會(huì)引起其他一些對象的無效（Invalidation）。比如，你修改了一個(gè)表的結(jié)構(gòu)，那么，選擇了這個(gè)表的SQL語句的執(zhí)行計(jì)劃就會(huì)變的無效。其實(shí)大部分對表的DDL操作，都會(huì)造成相關(guān)SQL語句執(zhí)行計(jì)劃的無效。就連Grant（授權(quán)）、Revoke（撤消權(quán)限）這樣看來跟執(zhí)行計(jì)劃耗無關(guān)系的操作，都會(huì)引起無效。如果有一個(gè)表TAB1，你發(fā)布了“Grant 某權(quán)限 on tab1 to 某用戶”，或“revoke 某權(quán)限 on tabl from 某用戶”這樣的操作，那么，所有和TAB1表有關(guān)的執(zhí)行計(jì)劃都將無效。無效之后，庫緩存對象除句柄外的所有內(nèi)存塊，都將被清除。再使用到對象后，必須重新加載對象。如上例，如果你對TAB1使用了DDL語句，那么所有使用了TAB1表語句的執(zhí)行計(jì)劃都將無效，你再使用這些語句時(shí)，就必須重新硬解析語句。
案例：
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操作，導(dǎo)致原來的執(zhí)行計(jì)劃變得無效 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，我們最好等到數(shù)據(jù)庫并不繁忙的時(shí)刻，再執(zhí)行DDL。作為DBA，這一點(diǎn)一定要牢記，除非要求立即執(zhí)行，否則等到數(shù)據(jù)庫并不繁忙時(shí)再執(zhí)行任何DDL。
再補(bǔ)充一點(diǎn)，無效和庫緩存對象的老化并不一樣。老化是連句柄帶對象的所有內(nèi)存塊都被清除出去了。而無效是只在庫緩存中保留對象句柄，但所有其他內(nèi)存塊都被清除出去。對于無效的對象，當(dāng)再次重新調(diào)用到它時(shí)，Oracle會(huì)再次將它調(diào)入到庫緩存中，這個(gè)操作被稱為Reload。一般說來，Reload與Get是無關(guān)的，因?yàn)镽eload是在對象無效后才發(fā)生的，而對象的無效并不影響對象句柄。好，說了這么多，下面我們來看這些值的意義。
我們已經(jīng)講述了Get、Pin與它們的命中、未命中，還有什么是Invalidation和Reload。在OLTP系統(tǒng)中，Get的命中率應(yīng)該在90%之上。而Reload和Pin的次數(shù)的比值，應(yīng)該小于1%。如果超出了這些數(shù)值范圍，就說明庫緩存的使用有問題。問題的原因主要有兩個(gè)，沒有使用綁定變量或是庫緩存太小。不過Reload和Pin的比例過高，也可能是在繁忙時(shí)執(zhí)行了DDL所導(dǎo)致的。
另外，V$librarycache的第一列是NAMESPACE，也就是名稱空間。它相當(dāng)于存儲(chǔ)在庫緩存中對象的類型。具體的名稱空間是什么意思呢？就是對象的名字所在的范圍，比如表和列的名字就不在一個(gè)范圍內(nèi)。也就是說表名和列名可以重復(fù)，還有用戶名和表、列也不在同一范圍內(nèi)，用戶名也可以和表、列名相同。我可以有個(gè)叫做AA的表，也可以有叫做AA的用戶。這兩個(gè)AA處在不同的范圍內(nèi)，也就明它們的名稱空間不同。這就好像在北京有個(gè)電話號(hào)碼是12345678，在上海也有個(gè)12345678，這兩個(gè)電話號(hào)碼雖然相同，但不會(huì)引起問題，因?yàn)樗鼈冊诓煌姆秶鷥?nèi)。這個(gè)范圍，也可以說是類型。
我顯示一下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個(gè)名稱空間，我們基本上可以說庫緩存中有11種類型的信息。有一個(gè)非常重要的指標(biāo)，就是庫緩存命中率，這個(gè)命中率就是庫緩存中所有對象的GETHITRAIO，它的計(jì)算方法如下：
select 1-sum(gethits)/sum(gets) fromv$librarycache;
這個(gè)比率應(yīng)該在90%以上。
還有一個(gè)比率也很重要，就是Reload和Pin的比值，這個(gè)比值應(yīng)該小于1%。
如果沒有達(dá)到這些比例，解決方法很簡單，問題或者是SQL語句沒有共享，或者是共享池太小。
有關(guān)庫緩存命中率，也可以查看STATSPACK報(bào)告中的Library Hit %項(xiàng)。這個(gè)我們上面已經(jīng)說過了。
Library cache lock、Library cache pin等待事件
等待事件在Oracle中無處不在，為了記錄這些數(shù)據(jù)，是損失了一些性能。但是你是想出了問題一籌莫展好，還是可以利用等待事件或各種資料輕松的查找出問題在哪好呢？而且，這些等待事件和資源你即使不去用它，Oracle一樣會(huì)消耗CPU去記載它們。因此，一個(gè)好的DBA一定要對各種等待事件、資料了如指掌。下面，我們介紹兩個(gè)和庫緩存相關(guān)的等待事件，如題，就是Library cache lock和Library cache pin。
我們上面說到庫緩存中的對象在庫緩存中被切割成多個(gè)內(nèi)存塊，另有一個(gè)對象句柄記錄了各個(gè)內(nèi)存塊的地址和其他的一些信息。當(dāng)你要修改句柄中的信息時(shí)，需要在句柄上加獨(dú)占鎖，而如果另一個(gè)進(jìn)程恰好在這時(shí)要求讀、寫句柄中的信息，它就必須等待。此時(shí)的等待就被Oracle記入Library cache lock事件。而讀、寫對象內(nèi)存塊也是無法同時(shí)進(jìn)行的，有人如果正在寫，你的讀操作就必須等待，讀寫內(nèi)存塊的等待事件就是Library cache pin。如果這兩個(gè)等待事件過多，同樣說明了庫緩存過小或沒有共享執(zhí)行計(jì)劃?；蛘撸?dāng)你在數(shù)據(jù)庫繁忙時(shí)使用DDL時(shí)，也會(huì)有這兩個(gè)等待事件。
案例1：
業(yè)務(wù)運(yùn)行前：
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
運(yùn)行業(yè)務(wù)：
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.
業(yè)務(wù)運(yùn)行后：
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：
業(yè)務(wù)運(yùn)行前：
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.
運(yùn)行業(yè)務(wù)：
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.
業(yè)務(wù)運(yùn)行后：
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的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼