Sql的重載率, 就是相同的語句, 由于無法使用共享池里已經保存的執(zhí)行計劃而不得不重新將代碼載入后執(zhí)行分析,建立查詢樹后再進行執(zhí)行的一個過程.
極端糟糕的情況下, 重載率可能接近于1 , 就是說,每一個語句都需要載入后重新執(zhí)行.
2.1 oracle庫緩存Oracle的庫緩存是內存的一個區(qū)域, 是共享池里的三個組成部分之一. 庫緩存由共享SQL工作區(qū), PL/SQL包和過程, 不同的鎖和句柄組成. 每當有應用程序要執(zhí)行sql或pl/sql語句時, 這些代碼必須先暫存在oracle的庫緩存中. 當應用程序運行代碼時, oracle會先搜索庫緩存看該代碼是否已經存在于內存中. 如果代碼已經寫入內存中, oracle就可以重新使用該已存代碼(也稱為軟解析). 如果內存里找不到該代碼, oracle 必須將代碼載入到內存中(也稱為硬解析或庫緩存不命中).
系統(tǒng)會給一個已配置的庫緩存工作區(qū)分配了一定的內存量, 當內存耗盡時, 會自動從內存中刪除一些不常用的代碼, 以便騰出一定空間來裝載應用程序所需的代碼. 如果硬解析出現的次數太多, 我們可能需要增加分配給庫緩存的內存容量.
動態(tài)性能視圖V$librarycache中存儲自最近一次啟動oracle數據庫之后到目前的庫緩存的性能情況, 我們可以查看這個視圖查看軟解析和硬解析的命中率情況.
字段
數據類型
說明
NAMESPACE
VARCHAR2(15)
library cache的命名空間
GETS
NUMBER
請求GET該命名空間中對象的次數。
GETHITS
NUMBER
請求GET并在內存中找到了對象句柄的次數（鎖定命中）。
GETHITRATIO
NUMBER
請求GET的命中率。
PINS
NUMBER
請求pin住該命名中對象的次數。
PINHITS
NUMBER
庫對象的所有元數據在內存中被找到的次數（pin命中）。
PINHITRATIO
NUMBER
Pin命中率。
RELOADS
NUMBER
Pin請求需要從磁盤中載入對象的次數。
INVALIDATIONS
NUMBER
命名空間中的非法對象（由于依賴的對象被修改所導致）數。
DLM_LOCK_REQUESTS
NUMBER
GET請求導致的實例鎖的數量。
DLM_PIN_REQUESTS
NUMBER
PIN請求導致的實例鎖的數量.
DLM_PIN_RELEASES
NUMBER
請求釋放PIN鎖的次數。
DLM_INVALIDATION_REQUESTS
NUMBER
GET請求非法實例鎖的次數。
DLM_INVALIDATIONS
NUMBER
從其他實例那的得到的非法pin數。
This view contains statistics about library cache performance and activity.
Column
Datatype
Description
NAMESPACE
VARCHAR2(15)
The library cache namespace
GETS
NUMBER
The number of times a lock was requested for objects of this namespace
GETHITS
NUMBER
The number of times an object's handle was found in memory
GETHITRATIO
NUMBER
The ratio of GETHITS to GETS
PINS
NUMBER
The number of times a PIN was requested for objects of this namespace
PINHITS
NUMBER
The number of times all of the metadata pieces of the library object were found in memory
PINHITRATIO
NUMBER
The ratio of PINHITS to PINS
RELOADS
NUMBER
Any PIN of an object that is not the first PIN performed since the object handle was created, and which requires loading the object from disk
INVALIDATIONS
NUMBER
The total number of times objects in this namespace were marked invalid because a dependent object was modified
DLM_LOCK_REQUESTS
NUMBER
The number of GET requests lock instance locks
DLM_PIN_REQUESTS
NUMBER
The number of PIN requests lock instance locks
DLM_PIN_RELEASES
NUMBER
The number of release requests PIN instance locks
DLM_INVALIDATION_REQUESTS
NUMBER
The number of GET requests for invalidation instance locks
DLM_INVALIDATIONS
NUMBER
The number of invalidation pings received from other instances
2.2 library cache的內存結構2.2.1 library cache中存儲的信息
1, 按對象類型分類
共享游標(SQL and PL/SQL objects)
數據庫對象(tables , indexes, procedures and so on)
2, 按存在時間分類
存儲對象: 如table, index, view等(老化后,磁盤上還有, 所以叫永久存儲對象)
瞬時對象: 如游標(老化后就不見了)
2.2.2 library cache中如何存儲信息
圖2 library cache的內存結構
共享池內存的結構, 是計算機常用的哈希表形式的擴展. 常用的哈希表形式, 總是先有一個哈希表, 保存對象地址(或句柄), 然后,根據對象地址(或句柄)訪問對象.
表1 幾個基本概念
名稱
描述
地址
只有一個位置信息
句柄
處理位置,還包括一些其他相關信息
堆(heap)
程序開發(fā)者使用系統(tǒng)函數分配的內存
棧
開發(fā)者在程序中定義的變量就存在棧
如圖2中, 每一組哈希值, 鏈表頭叫做一個哈希桶. . 簡單地說就是哈希桶(hash bucket)指向對象句柄(object handles) , 對象句柄存有對象所占的堆內存的地址.對象的堆往往不止一個, oracle習慣稱這些堆為子堆 . 通常對象句柄中存有0號子堆的地址, 而0號子堆存有其他各個子堆的地址.
2.3 Library cache的pin與lock所有在library cache中的對象, 都由兩部分組成, 一個句柄, 至少一個子堆.
句柄中記錄的有對象的名字, 命名空間, lock的持有者和等待者, pin的持有者和等待者, 一些標志信息以及堆的地址.
在library cache中尋找對象時, 先計算hash值, 在hash表中找到句柄, 再經句柄, 找到對象實際的內存地址(子堆). 在這個過程中, 有兩個重要數據項需要被鎖保護起來. 一個是對象句柄, 另一個就是對象的內存堆. 在對象句柄上加的鎖就是library cache lock, 在內存堆上加的鎖就是library cache pin.
2.3.1 library cache lock
Locks除了阻止不相容的對句柄的訪問, 以保護句柄中數據的完整性外, 獲得locks也是在緩存中定位對象的唯一方式, 即: 進程在對句柄上加鎖的同時, 完成在內存中定位堆的操作. 在句柄上獲得lock, 餅子內存中定位到堆后, 對象可以pin自己的堆. 如果對象相關信息不在內存中, pinning一個對象將導致它和它的子堆被裝載(此種情況下, 如果是多個對象pin一個對象, 將可能造成pin等待).
Lock有三種模式
l???????? Share: 讀對象鎖
l???????? Exclusive: 修改或創(chuàng)建對象
l???????? Null: 專用于為會話持續(xù).
注意, 永久存儲對象可以被鎖在以上任意一種方式, 瞬時對象只能被鎖在null方式.
Null鎖在執(zhí)行sql聲明的解析階段被獲得, 此后一直持有. 它不阻止任何DDL, 也用屬于”易碎解析鎖”稱呼它.
以下兩種情況下null鎖被打碎:
l???????? 當鎖所在對象有一個獨占pin時.
l???????? 鎖所在對象的任何依賴對象有一個獨占pin時
Pin有兩種模式:
l???????? Share: 讀一個對象堆
l???????? Exclusive: 修改一個對象堆.
無論存儲對象還是瞬時對象, 都能被pinned在share或exclusive模式. 當修改對象時, 進程會首先以share模式pin對象, 進行錯誤和安全檢查, 然后再以exclusive模式pin對象. Pin的解除將會導致相關對象上的易碎鎖break.
2.4 查看整個庫緩存的運行情況??? select sum(pins) pins,
?????? sum(pinhits) pinhits,
?????? sum(reloads) reloads,
?????? sum(invalidations) invalidations,
?????? 100-(sum(pinhits)/sum(pins)) *100 reparsing
?from v$librarycache;
??? 上述代碼可以得到庫緩存的整體性能狀況. 其中pin為對子堆也就是對象的實際訪問或者叫執(zhí)行次數, pinhits為執(zhí)行成功數, reloads為嘗試執(zhí)行不在庫緩存里的代碼的次數. Invalidations是指那些由于某種原因(特別是通過DDL操作),使得要執(zhí)行的代碼已經失效從而需要重新載入解析代碼的次數.
2.5 解決庫緩存造成的問題庫緩存偶爾會給用戶帶來的麻煩通常源于各種鎖以及隨之而來的由鎖機制引發(fā)的以下等待事件:
庫緩存加載鎖: 當有其他用戶端對同一對象使用了庫緩存加載鎖時, 新來的客戶端必須等待先前的用戶將鎖釋放出來.
庫緩存鎖: 比如兩個用戶端想要同時編譯某段相同的代碼時.
庫緩存pin: 這時意味著其他會話以不兼容模式鎖鎖定了該子堆.
不管庫緩存中出現了哪種類型的等待事件，想要確定哪些會話在等待以及在等待的是什么資源，可以通過V$SESSION_WAIT視圖查詢進行診斷。例如，如果想要找出那些在等待“庫緩存pin”的會話，可以執(zhí)行以下的查詢語句。對于一個庫緩存pin來說，該查詢的關鍵部分是P1RAW字段，該字段給出了阻塞特定會話的對象的句柄地址。對于其他類型的等待事件，您可以參考Oracle數據庫的說明文檔，找出對應于等待中的某對象或資源的P值。
SELECT sid,event,p1raw
FROM sys.v_$session_wait
WHERE event = 'library cache pin'
AND state = 'WAITING';
然后我們可以執(zhí)行以下的查詢來找出正在等待哪些庫緩存對象;
SELECT kglnaown AS owner, kglnaobj as Object
FROM sys.x$kglob
WHERE kglhdadr='&P1RAW';
要找出那些正在等待某個對象的用戶，可以使用DBA_WAITERS視圖并執(zhí)行以下查詢。這是一個非常簡單的查詢，卻可以很巧妙的找出阻塞的會話，也就是查找與上面從V$SESSION_WAIT查詢中找出的會話相匹配的等待會話，然后看看返回的holding_session結果。我們還可以看到在被阻塞的會話之后還有多少其他會話在等待中。如果有很多等待會話，那你就需要迅速采取行動了。
SELECT?waiting_session,?holding_session?FROM?dba_waiters;
現在我們已經確定了正在進行中的會話和被等待對象，以及引發(fā)問題的會話及其SQL。那么接下來要如何解決出現的問題呢?如果等待事件持續(xù)的時間過長，那么庫緩存內部很可能發(fā)生了錯誤或故障。唯一的補救辦法就是殺死持有該鎖的所有進程。在Oracle數據庫中要達到這個目的，可以使用alter system kill session命令。不過，這個命令是否有效還得看連接的類型。有時候需要用operating system kill命令或者關閉一系列應用程序來終止連接。我們需要檢測庫緩存中完全鎖定狀態(tài)下，哪一個方法對系統(tǒng)更行之有效。至少在不得不關閉系統(tǒng)和數據庫之前，嘗試一下強迫殺死進程的方法。
當我們使用庫緩存時，只要記住它不過是在代碼執(zhí)行前，Oracle數據庫必須將這些代碼載入其中的內存區(qū)。將代碼載入到庫緩存的過程可能會受到限制，從而引起等待事件，使系統(tǒng)掛起。這時候我們要通過殺死會話、進程或修改代碼的方法快速確定導致系統(tǒng)掛起的SQL進程，不過千萬不要忘記了庫緩存只是內存的事實，我們可能只是需要給引發(fā)問題的部分重新分配一些內存，使Oracle更有效地運行而已。
下載文檔
