Oracle Redo 並行機制

作者： fuyuncat    來源：   

       Redo log 是用於恢復和一個高階特性的重要資料，一個redo條目包含了相應操作導致的資料庫變化的所有資訊，所有redo條目最終都要被寫入redo檔案中去。Redo log buffer是為了避免Redo檔案IO導致效能瓶頸而在sga中分配出的一塊記憶體。一個redo條目首先在使用者記憶體(PGA)中產生，然後由oracle服務程式複製到log buffer中，當滿足一定條件時，再由LGWR程式寫入redo檔案。由於log buffer是一塊“共享”記憶體，為了避免衝突，它是受到redo allocation latch保護的，每個服務程式需要先獲取到該latch才能分配redo buffer。因此在高併發且資料修改頻繁的oltp系統中，我們通常可以觀察到redo allocation latch的等待。Redo寫入redo buffer的整個過程如下：
 

    在PGA中生產Redo Enrey -> 服務程式獲取Redo Copy latch(存在多個---CPU_COUNT*2) -> 服務程式獲取redo allocation latch(僅1個) -> 分配log buffer -> 釋放redo allocation latch -> 將Redo Entry寫入Log Buffer -> 釋放Redo Copy latch；

shared strand

    為了減少redo allocation latch等待，在oracle 9.2中，引入了log buffer的並行機制。其基本原理就是，將log buffer劃分為多個小的buffer，這些小的buffer被成為strand（為了和之後出現的private strand區別，它們被稱之為shared strand）。每一個strand受到一個單獨redo allocation latch的保護。多個shared strand的出現，使原來序列化的redo buffer分配變成了並行的過程，從而減少了redo allocation latch等待。

    shared strand的初始資料量是由引數log_parallelism控制的；在10g中，該引數成為隱含引數，並新增引數_log_parallelism_max控制shared strand的最大數量；_log_parallelism_dynamic則控制是否允許shared strand數量在_log_parallelism和_log_parallelism_max之間動態變化。
 

    每一個shared strand的大小 = log_buffer/(shared strand數量)。strand資訊可以由表x$kcrfstrand查到（包含shared strand和後面介紹的private strand，10g以後存在）。

    關於shared strand的數量設定，16個cpu之內最大預設為2，當系統中存在redo allocation latch等待時，每增加16個cpu可以考慮增加1個strand，最大不應該超過8。並且_log_parallelism_max不允許大於cpu_count。

    注意：在11g中，引數_log_parallelism被取消，shared strand數量由_log_parallelism_max、_log_parallelism_dynamic和cpu_count控制。
 

Private strand

    為了進一步降低redo buffer衝突，在10g中引入了新的strand機制——Private strand。Private strand不是從log buffer中劃分的，而是在shared pool中分配的一塊記憶體空間。
 

    Private strand的引入為Oracle的Redo/Undo機制帶來很大的變化。每一個Private strand受到一個單獨的redo allocation latch保護，每個Private strand作為“私有的”strand只會服務於一個活動事務。獲取到了Private strand的使用者事務不是在PGA中而是在Private strand生成Redo，當flush private strand或者commit時，Private strand被批次寫入log檔案中。如果新事務申請不到Private strand的redo allocation latch，則會繼續遵循舊的redo buffer機制，申請寫入shared strand中。事務是否使用Private strand，可以由x$ktcxb的欄位ktcxbflg的新增的第13位鑑定：
 

    對於使用Private strand的事務，無需先申請Redo Copy Latch，也無需申請Shared Strand的redo allocation latch，而是flush或commit是批次寫入磁碟，因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數、也減少了這些latch的等待，從而降低了CPU的負荷。過程如下：
 

    事務開始 -> 申請Private strand的redo allocation latch (申請失敗則申請Shared Strand的redo allocation latch) -> 在Private strand中生產Redo Enrey -> Flush/Commit -> 申請Redo Copy Latch -> 服務程式將Redo Entry批次寫入Log File -> 釋放Redo Copy Latch -> 釋放Private strand的redo allocation latch
 

    注意：對於未能獲取到Private strand的redo allocation latch的事務，在事務結束前，即使已經有其它事務釋放了Private strand，也不會再申請Private strand了。
 

    每個Private strand的大小為65K。10g中，shared pool中的Private strands的大小就是活躍會話數乘以65K，而11g中，在shared pool中需要為每個Private strand額外分配4k的管理空間，即：數量*69k。
 

    Private strand的數量受到2個方面的影響：logfile的大小和活躍事務數量。
 

    引數_log_private_mul指定了使用多少logfile空間預分配給Private strand，預設為5。我們可以根據當前logfile的大小（要除去預分配給log buffer的空間）計算出這一約束條件下能夠預分配多少個Private strand：
 

    當logfile切換後（和checkpoint一樣，切換之前必須要將所有Private strand的內容flush到logfile中，因此我們在alert log中可能會發現日誌切換資訊之前會有這樣的資訊："Private strand flush not complete"，這是可以被忽略的），會重新根據切換後的logfile的大小計算對Private strand的限制：
 

    引數_log_private_parallelism_mul用於推算活躍事務數量在最大事務數量中的百分比，預設為10。Private strand的數量不能大於活躍事務的數量。
 

    注：在預分配Private strand時，會選擇上述2個條件限制下最小一個數量。但相應的shared pool的記憶體分配和redo allocation latch的數量是按照活躍事務數預分配的。
 

    因此，如果logfile足夠大，_log_private_parallelism_mul與實際活躍程式百分比基本相符的話，Private strand的引入基本可以消除redo allocation latch的爭用問題。