shared pool 原理
Shared Pool 原理
Robinson
由於shared pool中最重要的是library cache，所以本文主要講解Library cache的結構，library cache latch，library cache lock，library cache pin。
What is shared pool?
Shared pool是SGA中的一部分，由於它是SGA的一部分，這意味著它可以被所有的程序所訪問，Shared Pool當中主要包含了2部分：library cache和
dictionary cache 也稱為 row cache。
Library cache
Dictionary cache包含了表，檢視的依賴資訊，比如表結構，它的使用者，Oracle在解析SQL的時候就會頻繁的訪問dictionary cache。
How is it managed?
Shared pool和PGA都是由一個Oracle的記憶體管理器來管理，我們稱之為KGH heap manager。Heap Manager不是一個程序，而是一串程式碼。Heap Manager
Library Cache Manager
Library cache Manager 可以看做是Heap Manager
Hash Table and Hash Bucket
Library cache是由一個hash table組成，這個hash table又由hash bucket組成的陣列構成，每個hash bucket又是由一些相互指向的library cache handle所組成，library cache object handle就指向具體的library cache object以及一些引用列表。
Library Cache結構示意圖如下：
Library Cache handle
我們對Library cache中所有物件的訪問是通過利用library cache handle來實現的，也就是說我們想要訪問library cache object，我們必須先找到library cache handle。Library cache handle指向library cache object,它包含了library object的名字，名稱空間，時間戳，引用列表，lock物件以及pin物件的列表資訊等等。Library cache handle也被library cache用來記錄哪個使用者在這個這個handle上有lock，或者是哪個使用者正在等待獲得這個lock。那麼這裡我們也知道了library cache lock是發生在handle上的。
當一個程序請求library cache object, library cache manager就會應用一個hash 演算法，從而得到一個hash 值，根據相應的hash值到相應的hash bucket中去尋找。這裡的hash演算法原理與buffer cache中快速定位block的原理是一樣的。如果library cache object在記憶體中，那麼這個library cache handle就會被找到。有時候，當shared pool不夠大，library cache handle會保留在記憶體中，然而library cache heap由於記憶體不足被age out，這個時候我們請求的object heap就會被過載。最壞的情況下，library cache handle在記憶體中沒有找到，這個時候就必須分配一個新的library cache handle，同時object heap也會被載入到記憶體中。
Library Cache Object
Library Cache Object是由一些獨立的heap所組成，前面說了Library cache handle指向Library cache Object，其實handle是指向第一個heap,這個heap 我們就稱之為heap 0。Heap 0記錄了指向其他heap的指標資訊。
根據上面描述，Library cache中的的Library cache object結構示意圖可以用上圖來表示(本圖摘自DSI405)
Library cache lock/pin
Library cache lock/pin是用來控制對library cache object的併發訪問的。Lock管理併發，pin管理一致性，lock是針對於library cache handle,而pin是針對於heap。
當我們想要訪問某個library cache object，我們首先要獲得這個指向這個object的handle的lock，獲得這個lock之後我們就需要pin住指向這個object的heap。
當我們對包，儲存過程，函式，檢視進行編譯的時候，Oracle就會在這些物件的handle上面首先獲得一個library cache lock，然後再在這些物件的heap上獲得pin，這樣就能保證在編譯的時候其它程序不會來更改這些物件的定義，或者將物件刪除。
當一個session對SQL語句進行硬解析的時候，這個session就必須獲得library cache lock，這樣其他session就不能夠訪問或者更改這個SQL所引用的物件。如果這個等待事件花了很長時間，通常表明共享池太小(由於共享池太小，需要搜尋free的chunk，或者將某些可以被移出的object page out，這樣要花很長時間)，當然了，也有可能另外的session正在對object進行修改(比如split 分割槽),而當前session需要引用那個table，那麼這種情況下我們必須等另外的session進行完畢。
Library Cache lock有3中模式：
lShare(S):當讀取一個library cache object的時候獲得
lExclusive(X): 當建立/修改一個library cache object的時候獲得
lNull(N)：用來確保物件依賴性
比如一個程序想要編譯某個檢視，那麼就會獲得一個共享鎖，如果我們要create/drop/alter某個物件，那麼就會獲得exclusive lock。Null鎖非常特殊，我們在任何可以執行的物件(cursor，function)上面都擁有NULL鎖，我們可以隨時打破這個NULL鎖，當這個NULL鎖被打破了,就表示這個物件被更改了，需要從新編譯。NULL鎖主要的目的就是標記某個物件是否有效。比如一個SQL語句在解析的時候獲得了NULL 鎖，如果這個SQL的物件一直在共享池中，那麼這個NULL鎖就會一直存在下去，當這個SQL語句所引用的表被修改之後，這個NULL鎖就被打破了，因為修改這個SQL語句的時候會獲得Exclusive 鎖，
由於NULL鎖被打破了，下次執行這個SQL的時候就需要從新編譯。
Library Cache pin有2種模式：
lShare(S):讀取object heap
lExclusive(X)：修改object heap
Library Cache pin沒有什麼好說的，當某個session想要讀取object heap，就需要獲得一個共享模式的pin，當某個session想要修改object heap，就需要獲得排他的pin。當然了在獲得pin之前必須獲得lock。
下面就是一個在Oracle10g RAC環境中的Library cache lock的案例
這個RAC環境有2個節點
SQL> select inst_id from gv$instance;
INST_ID
----------
2
1
在第一個節點中，session 4538被library cache lock阻塞
SQL> select inst_id,sid,serial#,event ,p1raw,machine,status from gv$session where username='BX5685';
INST_IDSIDSERIAL# EVENTP1RAWMACHINESTATUS
---------- ---------- ---------- ------------------------ --------------------
1453839833 library cache lockC000000346FBA458 bdhp4462ACTIVE
在Node1上面查詢
SQL> select * from dba_kgllock where kgllkreq > 0;
KGLLKUSEKGLLKHDLKGLLKMODKGLLKREQ KGLLKTYPE
---------------- ---------------- ---------- ---------- ------------
C0000004789EF9D0 C000000346FBA45802 Lock
SQL> select kglnaown, kglnaobj from x$kglob where kglhdadr = 'C000000346FBA458';
KGLNAOWNKGLNAOBJ
-------------------- --------------------
IDWSU1PROD_ASSOC_DNORM
SQL> select kglhdadr, kglnaown, kglnaobj from x$kglob where kglnaobj = 'PROD_ASSOC_DNORM' and KGLNAOWN='IDWSU1';
KGLHDADRKGLNAOWNKGLNAOBJ
---------------- -------------------- --------------------
C000000346FBA458 IDWSU1PROD_ASSOC_DNORM
在Node2上面查詢
SQL> select kglhdadr, kglnaown, kglnaobj from x$kglob where kglnaobj = 'PROD_ASSOC_DNORM' and KGLNAOWN='IDWSU1';
KGLHDADRKGLNAOWNKGLNAOBJ
------------------------------ -------------------- ------------------------------
C000000443267070IDWSU1PROD_ASSOC_DNORM
C00000035C33E248IDWSU1PROD_ASSOC_DNORM
SQL> col event format a30
select sid, serial#,s.event, sql_text from dba_kgllock w, v$session s, v$sqlarea a
where w.kgllkuse = s.saddr and w.kgllkhdl='C000000443267070'
and s.sql_address = a.address
and s.sql_hash_value = a.hash_value;SQL>234
SIDSERIAL# EVENTSQL_TEXT
---------- ---------- ------------------------------
477436583 db file scattered readALTER TABLE PROD_ASSOC_DNORM ENABLE CONSTRAINT PROD_ASSOC_DNORM_PK USING INDEX STORAGE ( INITIAL 4194304 NEXT 4194304 PCTINCREASE 0 ) TABLESPACE CDW_REFERENCE01M LOCAL
在Oracle10gR2中，library cache pin被library cache mutex 所取代
Library cache Latch
Library cache latch用來控制對library cache object的併發訪問。前面已經提到，我們要訪問library cache object之前必須獲得library cache lock， lock不是一個原子操作(原子操作就是在操作程中不會被打破的操作，很明顯這裡的lock可以被打破),Oracle為了保護這個lock，引入了library cache latch機制，也就是說在獲得library cache lock之前，需要先獲得library cache latch，當獲得library cache lock之後就釋放library cache latch。
如果某個library cache object沒有在記憶體中，那麼這個lock就不能被獲取，這個時候需要獲得一個library cache load lock latch，然後再獲取一個library cache load lock,當load lock獲得之後就釋放library cache load lock latch。
我們來看一下在 Oracle10gR2 中的一個有關library cache latch，
library cache lock, library cache pin 的統計情況
SQL> select name,gets,misses,sleepsfrom v$latch where name like '%library%';
NAMEGETSMISSESSLEEPS
------------------------------ ---------- ---------- ----------
library cache 193741529855138662346346
library cache lock 7346205874250303021
library cache pin171326029108613868
library cache pin allocation293049035 1
library cache lock allocation52261473492
library cache load lock 720252176234
library cache hash chains000
library cache latch受隱含引數_KGL_LATCH_COUNT的控制，預設值為大於等於系統中CPU個數的最小素數，但是Oracle對其有一個硬性限制，該引數不能大於67。注意：我們去查詢_kgl_latch_count有時候顯示為0,這是一個bug。
那麼library cache object handle是由哪個子latch來保護的呢？Oracle利用下面演算法來確定：
latch# = mod(bucket#, #latches)(摘自DSI405)
也就是說用哪個子latch去保護某個handle是根據那個handle所在的bucket號，以及總共有多少個子latch來進行hash運算得到的，對此我們不必深究。
latch contention
根據前面的講解，存在大量硬解析的系統上面就必然引發library cache latch, library cache lock競爭，下面就是一個每秒高達74個硬解析所引發
Library cache lock 成為Top wait event的一個案例。
Load Profile
|
Per Second |
Per Transaction |
|
|
Redo size: |
832,040.22 |
10,738.95 |
|
Logical reads: |
56,114.37 |
724.26 |
|
Block changes: |
5,897.48 |
76.12 |
|
Physical reads: |
3,442.07 |
44.43 |
|
Physical writes: |
174.41 |
2.25 |
|
User calls: |
273.48 |
相關推薦Oracle Shared Pool 原理and cal ota 內存不足 attach 內存管理 共享服務器 number 3.4 Oracle Shared Pool 原理 由於shared pool中最重要的是library cache，所以本文主要講解Libr buffer cache 和shared pool 詳解（之三，shared pool原理）【深入解析--eygle】 學習筆記 1.2 shared pool原理 Shared Pool是Oracle SGA設定中最複雜也是最重要的一部分內容，Oracle通過Shared Pool來實現SQL共享、減少程式碼硬解析等，從而提高資料庫的效能。在某些版本中，如果設 shared pool 原理Shared Pool 原理 Robinson 由於shared pool中最重要的是library cache，所以本文主要講解Library cache的結構，library cache l 關於shared pool的深入探討(六)-高Latch競爭案例size ... ogre poi hash map exec invalid star alink 研究了幾天shared pool,沒想到忽然就撞到問題上來了.作為一個案例寫出來給大家參考一下吧. 問題起因是公司做短信群發,就是那個18萬買的4000字的短信小說(噓,小 關於shared pool的深入探討(三)dbm num events tab names size ntc data lag 基本命令： ALTER SESSION SET EVENTS ‘immediate trace name LIBRARY_CACHE level LL‘; 其中LL代表Level級別,對於 Oracle數據庫大量library cache: mutex X及latch: shared pool問題排查一例data library end get post nal try 會話 mod 業務系統數據庫夯住，數據庫內大量的library cache: mutex X及latch: shared pool等待，alert日誌信息如下 Tue Sep 26 22:10:04 20 spark2原理分析-Task排程物件Pool原理分析概述 本文分析Task排程器的Pool排程物件的實現原理。 通過文章spark2原理分析-Task排程物件實現介面(Schedulable)原理分析 我們知道，任務排程器(TaskScheduler)中的排程物件分為兩類:Pool和TaskSetManager。而這兩類排程物件都 35 Oracle深度學習筆記——關於dbms shared pool MARKHOT35.Oracle深度學習筆記——關於dbms_shared_pool. MARKHOT 歡迎轉載，轉載請標明出處：http://blog.csdn.net/notbaron/article/details/50859148 BMS_SHARED_POOL包提供儲存過程來將PL/SQ 35 Oracle深度學習筆記——關於dbms shared pool MARKHOTali sdn 固定 idc num 共享池 font default edit 35.Oracle深度學習筆記——關於dbms_shared_pool. MARKHOT 歡迎轉載，轉載請標明出處：http://blog.csdn.net/notbaron/articl Oracle記憶體全面分析(3)- Buffer Cache的重要檢視和 共享池（Shared pool）1.1.3.3. Buffer Cache的重要檢視 關於Buffer Cache，oracle提供一些重要檢視，用於查詢關於Buffer Cache的重要資訊，為調整Buffer Cache、提高效能提供參考。下面一一介紹它們 · v$db_cache_advice 上 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列5Flushing(清空) SHARED POOL 在使用大量literal SQL的系統中，shared pool隨時間推移會產生大量碎片進而導致併發能力的下降。Flushing sha ORACLE SGA shared pool組成硬解析即整個SQL語句的執行需要完完全全的解析，生成執行計劃。生成執行計劃需要耗用CPU資源，以及SGA資源。在此不得不提的是對庫快取中閂的使用。閂是鎖的細化，可以理解為是一種輕量級的序列化裝置。當程序申請到閂後，則這些閂用於保護共享記憶體的數在同一時刻不會被兩個以上的程序修改。在硬解析時，需要申請閂的使用， buffer cache 和shared pool詳解（之五，問題診斷總結）【深入解析--eygle】 學習筆記 1.2.7 診斷和解決ORA-04031 錯誤 Shared Pool的主要問題在根本上只有一個，就是碎片過多帶來的效能影響。 1.2.7.1 什麼是ORA-04031錯誤 當嘗試在共享池分配大塊的連續記憶體失敗（很 oracle優化-shared poolOracle優化中的shared pool tunning優化。 在oracle優化中，Shared pool的優化應該放在優先考慮，因為一個cache miss在shared pool中發生比在data buffer中發生導致的成本更高，由於dictionary資 Oracle記憶體詳解之三 Shared pool 共享池一. Shared Pool 概述 在之前的blog對Oracle 的記憶體架構也做了一個概述，參考： 在網上搜到一篇介紹shared pool 非常詳細的pdf資料。 原文連結以找不到，但還是要感謝作者Kamus的辛勤 關於shared pool的深入探討我們看到,在Oracle9i中,Free Lists被劃分為0~254,共255個Bucket。 每個Bucket容納的size範圍 Bucket 0~199 容納size以 4 遞增 Bucket 200~249 容納size以 64 遞增 從Bucket 249開始,Oracle各Bucke Shared pool深入分析及效能調整shared pool的內部管理機制 3.1解析SQL語句的過程 為了將使用者寫的可讀的SQL文字轉化為oracle認識的且可執行的語句，這個過程就叫做解析過程。 解析分為硬解析和軟解析。當一句SQL第一次被執行時必須進行硬解析。 當客戶端發出一條SQL語句（也可以是一個儲存過程或者一個匿名P 深入理解Oracle中的shared pool與library cache元件及相關等待事件傳統的’library cache pin’在10.2.0.2之後預設被取代， 此處PIN被Mutex及其ref count取代。 當程序執行遊標語句時或者需要PIN，或者需要hard parse一個子遊標heap。在版本10.2.0.1中， 使用mutex部分程式碼替代PIN的功能預設是不啟用的， Oracle 檢視 Shared Pool 資訊的相關指令碼關於Oracle SGA中Shared Pool的詳細說明，參考我的blog： 在上篇blog裡，介紹了shared pool 的組成和一些原理， 也有一些指令碼，在這篇blog裡，在補充幾個檢視Shared Pool 的指令碼。 [20190319]shared pool latch與library cache latch的簡單探究.txt手記 table 獲取 inux pub free unix put cursor [20190319]shared pool latch與library cache latch的簡單探究.txt--//昨天看Oracle DBA手記3：數據庫性能優化與內部原理解析.pdf |