Buffer cache 的調整與優化(一)

--==============================

-- Buffer cache 的調整與優化(一)

--==============================

 

    Buffer Cache是SGA的重要組成部分，主要用於快取資料塊，其大小也直接影響系統的效能。當Buffer Cache過小的時候，將會造成更多的

free buffer waits事件。 下面將具體描述Buffer Cache的作用，調整與優化。

 

一、SGA的所有元件

    從動態檢視v$sga_dynamic_components獲取SGA的相關資訊

   

 

二、Buffer cache介紹

    1.Buffer cache的型別通常包括

        default buffer cache

        keep buffer cache

        recycle buffer cache

        nk buffer caches

       

        與Buffer cache打交道的後臺程式為DBWn，與之對應的資料檔案通常位於system 表空間，sysaux表空間，undo表空間，datafile 等  

 

            Buffer cache是SGA的一部分，其內容是由使用者程式從資料檔案讀取出來的資料塊，並且所有的使用者共享這些資料塊。通常，服務

        器程式為提高I/O效能，會一次性讀多個資料塊。對於Buffer cache中的髒資料則由DBWn程式寫入到資料檔案。同樣為提高效能，DBWn

        程式也會一次寫多個資料塊。Buffer cache會擁有一個資料塊的多個副本，當前塊的最新副本僅有一份，而該資料塊老的或舊的副本可

        能有多份，用於塊的讀一致性。Buffer cache採用LRU演算法來淘汰掉過時的資料塊。

            Buffer cache中存在檢查點佇列以及LRU連結串列。

 

    2.Buffer cache的幾個相關引數

        Buffer cache能有由多個獨立的且具有不同block size的緩衝池(buffer pool)組成。

        DB_BLOCK_SIZE：引數決定了資料庫主塊的塊大小，該塊的大小通常被系統表(system,sysaux)空間和主要的Buffer cache(recycle,keep,

            default buffer cache)所使用

        決定主要的Buffer cache大小的幾個引數

            db_cache_size

            db_keep_cache_size

            db_recycle_cache_size

 

    3.Buffer cache中塊的四種狀態

        pinned:意味著多個會話在相同的時段寫同一個資料塊，其他的會話等待訪問塊。

        clean:優先要淘汰掉的資料塊,即不是pinned狀態,也不會被再次使用的塊.該塊可能和磁碟上的塊處於同步狀態,也可能是一個讀一致性塊

        free/unused:即Buffer cache中的塊處於空閒狀態或未使用狀態，通常是由於例項剛剛啟動。

        dirty：已發生變化的資料塊，且沒有程式再使用該塊，則在aged out之前需要立即由DBWn 寫入到資料檔案。

   

            伺服器程式將資料塊從資料檔案填充到Buffer cache，當Buffer cache中不再需要使用到資料塊的副本時，而DBWn程式則將髒資料

        寫入到資料檔案，用於將資料塊由  pinned 狀態變為free 狀態。

 

    4.引數db_block_checksum

        該引數設定為true，則一個指定的校驗碼被同時寫入到資料塊，用於防止磁碟，I/O系統損壞導致資料的丟失。

       

三、客戶端伺服器程式從Buffer cache獲取資料的過程

    1.伺服器程式使用一個雜湊函式來檢查所需的資料塊是否已經位於Buffer cache。如果在Buffer cache中找到所需的資料塊，則該塊根據使

        用的頻率放置到LRU佇列中特定的位置。此時的讀資料塊為邏輯讀，且不在需要執行後續步驟。如果不在Buffer cache中，則轉到下一步。

    2.伺服器程式搜尋LRU列表中是否存在可用的空閒空間存放新的資料塊。在搜尋LRU列表同時時，已經被修改的髒資料將被伺服器程式放置到

        檢查點佇列。

    3.檢查點佇列長度超出預設大小的闕值或伺服器程式搜尋空閒塊操作預設的次數(由隱藏引數_db_block_max_scan_pct所指定的值，表示已

        經掃描的buffer header數量佔整個LRU連結串列上的buffer header的總數量，在i中該限定值為40%)，則伺服器程式通過DBWn將髒資料從

        Buffer cache寫出到資料檔案。

    4.當可用的空閒塊被找到後，伺服器程式從資料檔案讀入塊到Database Buffer cache並放置到LRU佇列中。如果所得到的塊不是一致性讀塊

        ，則伺服器程式從undo segment中重構一致性塊。

       

    Buffer cache與DBWn密切相關，下面給出DBWn觸發的條件

        髒緩衝列表達到指定的闕值大小

        搜尋LRU空閒佇列達到預設的闕值次數

        發生檢查點事件

        資料庫關閉時

        表空間實現熱備份時

        表空間離線

        在段被刪除時

       

        更多有關體系結構請參考：Oracle例項和Oracle資料庫(Oracle體系結構)       

       

四、對buffer cache調優，命中率等

    1.調整buffer cache調優規則

        調優的目標：儘可能在Buffer cache中找到資料，降低等待可用空閒塊的時間

        除錯方法：

            wait events

            cache hit ration

            v$db_cache_advice view

        調整手段

            降低SQL命令對資料塊的請求，如避免使用select * from 語句

            增加緩衝池的大小

            不同訪問方式使用不同的緩衝池(buffer pools)

            快取常用的表到記憶體

            並行讀或排序操作不使用cache,直接從磁碟讀入到PGA及記憶體

 

    2.決定Buffer cache的幾個指標

        下面的查詢中列出了涉及到buffer cache的幾個重要指標數

                       

        Session Logical Reads：所有的邏輯讀的資料塊的數量。

       

        Free Buffer Inspected指標:

            為尋找空閒buffer之前所檢查塊的總數量，即跳過塊的數量。如果該值接近髒資料塊的數量，則表明空閒塊很少，該值應儘可能小

            於髒塊的數量。

           

        Free Buffer Waits:

            當session在LRU list上沒有尋找到空閒可用資料塊或者搜尋可用的記憶體資料塊被暫停的時候，該發生該事件，此為等待DBWn將髒

            塊寫入到資料檔案的等待數。除此之外，會話在做一致性讀時，需要構造資料塊在某個時刻的前映像（image），此時需要申請內

            存來存放這些新構造的資料塊，如果記憶體中無法找到這樣的記憶體塊，也會發生這個等待事件。

           

        Buffer Busy Waits:

            使用者伺服器程式已找到所需的資料塊，但該塊正被其它程式使用或多個程式同時要修改該塊，此時需要等待的時間。

            當一個會話需要讀取一個資料塊，但這個資料塊正在被另一個會話讀取到記憶體中時，此時同樣發生Buffer Busy Waits事件。

 

           

        查詢event事件名稱

 

        產生Buffer busy waits的幾種情形

            DATA BLOCK，資料塊的競爭，該情形通常是基於表段和索引段上的競爭，下面的處理辦法

                儘可能縮小SQL語句的查詢欄位，查詢範圍，如不使用select * 查詢，將like子句改為直接賦值等

                檢查索引的合理性。如使用了sequence生成的索引，其索引鍵通常位於相同的塊，因此可以使用反向索引避免此問題

                使用自動段空間管理或增加空閒列表，以避免多個程式同時插入相同的塊

                查詢檢視v$session_wait來獲得熱點塊的檔案ID，塊ID，通過這些資訊來獲得物件ID，進一步對該物件進行調整

            UNDO Header

                基於UNDO段頭部的競爭，如果未使用自動撤銷段管理模式，則需要增加更多的回滾段

            UNDO BLOCK

                基於UNDO段塊的競爭，如果未使用自動撤銷段管理模式，則需為回滾段分配更大的尺寸

               

        產生Free Buffer waits的幾種情形    

            DBWn程式來不及將資料寫入到資料檔案，導致需要等待被釋放的空間

            I/O系統速度過於緩慢

                確保資料庫檔案是否分佈在不同的磁碟上，或增加更高效能的磁碟

            資源等待造成I/O系統過慢，如latch等待

                確保資料庫檔案是否分佈在不同的磁碟上，或增加更高效能的磁碟

            Buffer cache太小，導致DBWn來不及將髒資料寫入到資料檔案

                需要增大buffer cache的尺寸

            Buffer cache太大，而單一的DBWn程式需要多次才能將資料寫入到檔案

                減少buffer cache的尺寸，或增加更多的DBWn程式

       

    3.評估Cache的命中率

        計算命中率的思想

            1-(物理讀的次數-總的請求次數)

       

            計算命中率

           

        physical reads

            從Oracle級別來理解，從磁碟讀資料塊的次數，一次可以讀多塊,由引數db_file_multiblock_read_count來控制。此種讀方式使用

            了db cache.

            形象示意：db_file ==> db_cache ==> pga

 

        physical reads direct

            有些資料塊不會先從硬碟讀入記憶體再從記憶體讀入PGA再傳給使用者，而是繞過SGA直接從硬碟讀入PGA。比如並行查詢以及從臨時表空

            間讀取資料。這部分資料塊由於不快取使得hit ratio不會被提高。其在計算hit ratio時應當被扣除。

            形象示意：db_file  ==> pga

                通常，disk sort / hash , exp direct=Y ,都會有physical reads direct

           

 

        physical reads direct (lob)

            對於大值物件，如LOB資料型別以及LOB段，Oracle可以繞過buffer cache而直接使用PGA，其原理等同於physical reads direct

           

        使用physical reads direct，physical reads direct (lob)的優點：

            對於一個大操作，需要請求大量資料塊，假設又使用並行執行，且執行次數就那麼一次，這個時候就適合使用direct方式，

            如果還是走buffer cache則需要把buffer cache裡已快取的資料庫都清空

            注意physical write /direct 同理

 

        session logical reads

            發出的總的請求次數，此處是指從database buffer cache中請求塊。對於一致性讀，則這些緩衝包含來自回滾段的資料

 

        下面是另一種不同的計算命中率的方法，通常用在10g和11g之中

 

            consistent gets from cache

                在回滾段Buffer中的資料構造一致性讀資料塊的總次數。其產生原因是由於其他會話對當前資料塊進行操作，如update操作，

                但是由於我們的查詢是在這些修改之前呼叫的，所以需要使用回滾段中的資料塊的前映像進行查詢，來保證資料的一致性。

                這樣就產生了一致性讀。

               

            db block gets     

                在操作中提取的塊數目，而不是在一致性讀的情況下而產生的塊數。

                當前塊(current,相對於cosistent讀而言，current總是最新的塊)，從buffer cache中請求的次數。當前塊意思就是在操作

                中正好提取的塊數目，而不是在一致性讀的情況下而產生的塊數。通常的情況下，一個查詢提取的塊是在查詢開始的那個時

                間點上存在的資料塊，當前塊是在這個時刻存在的資料塊，而不是在這個時間點之前或者之後的資料塊數目。

 

            physical reads cache   

                從磁碟讀入到buffer cache中的總次數。

                產生的主要原因是：在資料庫快取記憶體中不存在這些塊, 全表掃描, 磁碟排序等

 

                db_block_gets + consistent_gets兩者之和作為總的請求次數，在與physical_reads相比進而得到命中率

 

            此方法與前面命中率計算的方法不一樣，更簡單直觀。

 

    4.影響命中率的因素

        全表掃描(小標尚可，對於大表而言I/O效能更差。而且全表掃描總是被置於LRU的最尾端，隨時被aged out)

        不同資料定義和應用程式設計影響命中率

        大表的隨機訪問(非順序)

        不均衡的cache hit

       

        命中率需要考慮的問題

            a.對相同的大表和索引的重複掃描容易造成命中率很高的假象。定期檢查頻繁使用且返回結果集很大的SQL語句，確保這些SQL語

                句使用了最優的執行計劃。

            b.避免返回查詢相同的資料，儘可能將獲得的結果集快取的客戶端程式或中介軟體。

            c.大表的全表掃描問題，直接將其放置到LRU的尾端，容易aged out。

                (小表通常指全表掃描時佔用buffer cache 20%或擁有個資料塊)。

            d.對較大OLTP系統而言，表中的很多行僅僅被訪問次或很少的次數，基於此，這些塊不易長時間佔住buffer cache。

            f.對於並行查詢或排序等，持續增加buffer cache的大小並無實際意義，優化效果並明顯。

 

    5.下列情形可以考慮增加buffer cache

        一些等待事件已經被優化

        不良的SQL語句已經被優化

        作業系統級別無不良的記憶體頁面置換

        上次增加的buffer cache有效

        基於上面的情形，且命中率很低，此時可以增加buffer cache

       

    6.增加buffer cache 的步驟

        首先將db_cache_advice置於ON 狀態

        檢查動態效能檢視v$db_cache_advice(需要考慮增加後不影響作業系統級別過多的記憶體頁面置換)

        動態增加db_cache_size的值(生產資料庫不建議關閉系統而使用動態調整alter system set db_cache_size=nM;)

   

        檢視當前buffer cache的大小

           

    7.減少buffer cache 的情形

        在命中率很高的情形下，查詢檢視v$db_cache_advice，來權衡適度降低buffer cache size是否會使得系統I/O顯劇增加，如不是，且

        降低buffer cache size不會影響效能的情況下，則可以適度降低buffer cache size的大小。

        使用alter system set db_cache_size來調整

 

    8.使用advisor來調整buffer cache

        buffer cache advisor 可以啟用或禁用通過收集統計資訊來預估buffer cache的大小，然後根據預估的大小以及工作負荷來調整buffer

        cache的大小。buffer cache advisor功能通過設定引數db_cache_advice 開啟用或禁用，該引數僅能支援系統級別的修改。

        其引數值為:OFF,ON,READY

            OFF：禁用buffer cache advisor特性，且不為advisor分配記憶體

            READY：不收集資料,但是收集資料的記憶體已經預先分配好了.通過把引數值從off設定為ready,然後再設定為on，以避免出現錯誤。

                ALTER SYSTEM SET db_cache_advice = ON | READY | OFF ;

   

        該引數設定的前提條件為STATISTICS_LEVEL引數必須要先設定為TYPICAL或者ALL

       

        通過設定啟用buffer cache advisor 功能後，可以檢視檢視v$db_cache_advice來獲得不同負荷下的advisor

        以下是該檢視的幾個重要列

            SIZE_FOR_ESTIMATE

            BUFFERS_FOR_ESTIMATE

            ESTD_PHYSICAL_READS

       

        檢視預設的buffer cache的advice

                   

    9.優化Buffer cache的常用引數及檢視

        db_cache_size

        db_cache_advice

        db_keep_cache_size

        db_recycle_cache_size

        db_file_multiblock_read_count

        statspace report

        v$db_cache_advice(view)

 

        檢視

            v$buffer_pool_statistics

            v$buffer_pool

            v$db_cache_advice

            v$sysstat

            v$sesstat

            v$system_event

            v$session_wait

            v$bh

            v$cache