1.1.3.3.            Buffer Cache的重要檢視

關於Buffer Cache，oracle提供一些重要檢視，用於查詢關於Buffer Cache的重要資訊，為調整Buffer Cache、提高效能提供參考。下面一一介紹它們

·        v$db_cache_advice

上面我們提到了Oracle的建議器，其中有一個針對Buffer Cache的建議器。在我們設定了引數db_cache_advice為TRUE後，經過一段時間的系統執行，Oracle收集到相關統計資料，並根據一定的數學模型，預測出DB_CACHE_SIZE在不同大小情況的效能資料。我們就可以由檢視V$DB_CACHE_ADVICE查出這些資料，並根據這些資料調整DB_CACHE_SZIE，使系統性能最優。

下面是關於這個檢視的結構描述：

下面是從這個檢視中查詢出來的資料：

SQL> select size_for_estimate, estd_physical_read_factor, estd_physical_reads

  2  from v$db_cache_advice

  3  where name = 'DEFAULT';

SIZE_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS

----------------- ------------------------- -------------------

               16                    2.0176             6514226

               32                    1.7403             5619048

               48                    1.5232             4917909

               64                    1.3528             4367839

               80                    1.2698             4099816

               96                    1.1933             3852847

              112                    1.1443             3694709

              128                    1.1007             3553685

              144                    1.0694             3452805

              160                    1.0416             3362964

              176                    1.0175             3285085

              192                         1             3228693

              208                    0.9802             3164754

              224                    0.9632             3109920

              240                    0.9395             3033427

              256                    0.8383             2706631

              272                    0.7363             2377209

              288                     0.682             2202116

              304                    0.6714             2167888

              320                    0.6516             2103876

20 rows selected

當前我們的DB_CACHE_SIZE為192M，可以看到，它的物理讀因子為1，物理讀數為3228693。那麼如何根據這些資料調整DB_CACHE_SIZE呢？給出一個方法，找到變化率較平緩的點作為採用值。因為建議器做預測是，DB_CACHE_SIZE的預測值的增長步長是相同的，是16M。我們按照這一步長增加DB_CACHE_SIZE，如果每次增加物理讀降低都很明顯，就可以繼續增加，直到物理讀降低不明顯，說明繼續增加DB_CACHE_SIZE沒有太大作用。當然，效能和可用資源是天平的兩端，你需要根據自己系統的實際情況調整。

上面的例子中，我們可以考慮將DB_CACHE_SIZE調整到288M。因為在288M之前，物理讀因子變化都比較大，而從288M到304M以後，這個因子變化趨緩。用一個二維圖可以更容易看出這個變化來：

這一檢視作為調整DB_CACHE_SIZE以提高效能有很大參考價值。但衡量Buffer Cache是否合適的重要指標還是我們前面提到的快取命中率（Buffer Hit），而影響快取命中率往往還有其他因素，如效能極差的SQL語句。

·        V$BUFFER_POOL

這一檢視顯示了當前例項中所有緩衝池的資訊。它的結構如下：

·        v$buffer_pool_statistics

V$BUFFER_POOL_STATISTICS檢視記錄了所有緩衝池的統計資料。它的結構如下：

檢視當前的Buffer Cache命中率：

SQL> select 1-(physical_reads)/(consistent_gets+db_block_gets)

  2  from v$buffer_pool_statistics;

1-(PHYSICAL_READS)/(CONSISTENT

------------------------------

             0.967658520581074

SQL>

·        v$bh

這一檢視在深入定位緩衝區問題時很有用。它記錄了緩衝區中所有資料塊物件。粒度非常細。這個檢視最初的目的是用於OPS（Oracle Parallel Server Oracle平行伺服器，9i後稱為RAC）的，是用於保證RAC中各個節點的資料一致性的。但是，我們可以通過它來查詢Buffer Cache的使用情況，找出大量消耗Buffer Cache的物件。下面的語句就可以完成這一工作：

SQL> column c0 heading 'Owner'                     format a15

SQL> column c1 heading 'Object|Name'               format a30

SQL> column c2 heading 'Number|of|Buffers'         format 999,999

SQL> column c3 heading 'Percentage|ofData|Buffer' format 999,999,999

SQL> select

  2     owner                        c0,

  3     object_name                  c1,

  4     count(1)                     c2,

  5     (count(1)/(select count(*) from v$bh)) *100  c3

  6  from

  7     dba_objects o,

  8     v$bh        bh

  9  where

 10     o.object_id  = bh.objd

 11  and

 12     o.owner not in ('SYS','SYSTEM')

 13  group by

 14     owner,

 15     object_name

 16  order by

 17     count(1) desc

 18  ;

C0              C1                                     C2         C3

--------------- ------------------------------ ---------- ----------

PLSQLDEV        STANDARD_CITY                  17290      72.5860621

DBOWNER         MSG_LOG                        2          0.00839630

DBOWNER         COUNTRY_PK                     1          0.00419815

DBOWNER         PARAMETER                      1          0.00419815

DBOWNER         PARAMETER_PK                   1          0.00419815

DBOWNER         MSG_LOG_IDX1                   1          0.00419815

6 rows selected

SQL>

更重要的是，這個檢視記錄的粒度非常細，一條記錄對應了一個數據塊。這對於我們做記憶體問題分析或分析Oracle行為時很有幫助。

下面是這個檢視的結構：

1.1.4.   共享池（Shared pool）

SGA中的共享池由庫快取（Library Cache）、字典快取（Dictionary Cache）、用於並行執行訊息的緩衝以及控制結構組成。

Shared Pool的大小由引數SHARED_POOL_SIZE決定。在32位系統中，這個引數的預設值是8M，而64位系統中的預設值位64M。最大為4G。

對於Shared Pool的記憶體管理，是通過修正過的LRU演算法表來實現的。

下面分別介紹Shared Pool的幾個組成部分。

1.1.4.1.            庫快取（Library Cache）

Library Cache中包括共享SQL區（Shared SQL Areas）、PL/SQL儲存過程和包以及控制結構（如鎖、庫快取控制代碼）。

任何使用者都可以訪問共享SQL區（可以通過v$sqlarea訪問，隨後會介紹這個重要檢視）。因此庫快取存在於SGA的共享池中。

·        共享SQL區和私有SQL區

Oracle會為每一條SQL語句執行（每執行一條語句Oracle都會開啟一個遊標）提供一個共享SQL區（Shared SQL Areas）和私有SQL區（Private SQL Areas屬於PGA）。當發現兩個（或多個）使用者都在運行同一SQL語句時，Oracle會重新組織SQL區，使這些使用者能重用共享SQL區。但他們還會在私有SQL區中儲存一份這條SQL語句的拷貝。

一個共享SQL區中儲存了一條語句的解析樹和查詢計劃。在多使用者系統中，Oracle通過為SQL語句使用同一共享SQL區多次執行來節省記憶體。

當一條新的SQL語句被解析時，Oracle從共享池中分配一塊記憶體來儲存共享SQL區。這塊記憶體的大小與這條語句的複雜性相關。如果Shared Pool不夠空間分配給共享SQL區，Oracle將釋放從LRU連結串列中查詢到最近最少使用的記憶體塊，直到有足夠空間給新的語句的共享SQL區。如果Oracle釋放的是一個共享SQL區的記憶體，那麼相應的語句在下次執行時需要再次解析並重新分配共享SQL區。而從解析語句到分配共享SQL區是一個比較消耗CPU的工程。這就是為什麼我們提倡使用繫結變數的原因了。在沒有使用繫結變數時，語句中的變數的數值不同，oracle就視為一條新的語句（9i後可以通過cursor_sharing來控制），重複上面的解析、記憶體分配的動作，將大大消耗系統資源，降低系統性能。

·        PL/SQL程式單元

Oracle對於PL/SQL程式單元（儲存過程、函式、包、匿名PL/SQL塊和觸發器）的處理過程和對單個的SQL語句的處理過程相似。它會分配一個共享區來儲存被解析、編譯過的程式單元。同時分配一個私有區域來存放執行程式單元的會話所指定的程式單元的引數值（包括本地變數、全域性變數和包變數——這也叫做包的例項化）和用於執行程式所需的記憶體。如果多個使用者運行同一個程式單元，則他們共享同一個共享區域，並且各自保持一份私有區域，用於使用者會話中指定的變數值。

而一個PL/SQL程式單元中的每條單個SQL語句的處理過程則和上面描述的SQL語句的處理過程相同。要注意一點，儘管這些語句是從PL/SQL程式單元中來的，但是Oracle還是會為這些語句分配一塊共享SQL區，同時為每個使用者分配一個相應的私有SQL區。