DB2日誌原理

主日誌檔案和輔助日誌檔案

主日誌檔案是在建立第一個資料庫連線或者資料庫活動時立即分配的。輔助日誌檔案是在需要時動態分配的。下面是相關的一些資料庫配置引數：

引數	用途
LOGPRIMARY	表明要分配的主日誌檔案的數量
LOGSECOND	表明可以分配的輔助日誌檔案的最多數量
LOGFILSIZ	用於指定一個日誌檔案的大小（4KB頁的個數）

 

例如，一個資料庫配置檔案中引數如下：

日誌檔案大小（4KB）                         (LOGFILSIZ) = 1024

主日誌檔案的數目                           (LOGPRIMARY) = 3

輔助日誌檔案的數目                          (LOGSECOND) = 2

日誌檔案路徑                            = D:\DB2\NODE0000\SQL00001\SQLOGDIR\

假定執行以下事務，該事務將插入一百萬條記錄：

Insert into table1 values(1);

Insert into table1 values(2);

…

Insert into table1 values(1,000,000);

Commit;

DB2將填充第一個日誌檔案，然後繼續填充第二個日誌檔案，然後再填充第三個日誌檔案。當填滿第三個日誌檔案時，就沒有主日誌檔案了，於是DB2動態地分配第一個輔助日誌檔案。因為LOGSECOND是大於0的，當這個輔助日誌檔案被填滿時，DB2將繼續分配另一個輔助日誌檔案，一直重複這個過程，直到分配的輔助日誌檔案數量達到最大值LOGSECOND。對於本例，當DB2嘗試分配第三個輔助日誌檔案時，將返回一個錯誤，表明事務已用完日誌空間。這時事務將回滾。

 

=============================================

這與Oracle不同。Oracle DBWR是否將data buffer寫入datafile與事務是否提交無關。LGWR將redo log buffer寫入log也與事務是否提交無關。只是LGWR優先DBWR寫。

Oracle中，LGWR在下列情況下寫：

l     事務提交（commit）；

l     每3秒寫一次；

l     當redo log buffer用到三分之一時；

l     當DBWRn 程式寫buffer中的資料到資料檔案中時。

DBWR在下列情況下寫：

l     When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBW n to write.

l     DBWRn  periodically writes buffers to advance the  checkpoint.（檢查點大約3秒一次，所以DBWR每3秒寫一次。所有引起執行檢查點的動作也會觸發DBWR寫）。

Oracle中的commit命令：

在事務commit之前，下面的就已經發生了：

l     Oracle生成undo，undo包含了事務修改的資料的舊值；

l     在redo log buffer中產生redo資訊，redo記錄了data block的改變和rollback block的改變。redo log buffer中的這些資訊可能在事務commit之前寫入disk。

l     在database buffer中修改了資料，這些修改可能在事務commit之前被寫入disk。

事務commit，發生了下列事情：

l     undo表空間中與事務相關的內部表記錄事務的commit，產生SCN，並在這些表中記錄；

l     LGWR將redo log buffer中redo資訊寫入redo log file。並在redo log file中寫入相應的SCN；

l     釋放rows和tables上的鎖；

l     Oracle標記事務完成。

======================================================

DB2中不存在獨立的undo，而是將undo資訊也記錄在日誌檔案中。事務不提交的情況下，不會將日誌歸檔或是覆蓋日誌檔案。這就導致了上面的事務掛起的情況。如果使用無限日誌記錄模式，DB2會在一個日誌被填滿時立即歸檔而不等到所有的事務都已經被提交且具體化時才歸檔。這樣可以保證活動日誌目錄永遠不會被填滿。

 

 

日誌的型別：

活動日誌：如果以下兩個條件之一得到滿足，則一個日誌被認為是活動的（active）：

l     它包含尚未被提交或回滾的事務資訊。

l     它包含已經被提交但其更改還沒有被寫到資料庫磁碟的事務的資訊。

線上歸檔日誌：包含被提交且具體化的事務的資訊。這些日誌與活動日誌放在相同的目錄中。

離線歸檔日誌：已經從活動日誌目錄轉移到另一個目錄或媒介上的歸檔日誌。這種移動可以手動地完成，也可以由 DB2 自動完成。

 

 

日誌記錄型別：迴圈日誌記錄和歸檔

迴圈日誌記錄

類似於Oracle的 noarchivelog模式。

迴圈日誌記錄是 DB2 預設的日誌記錄模式。顧名思義，這種型別的日誌記錄以迴圈的模式重用日誌。例如，如果有四個主日誌，DB2 將按照以下順序使用它們：Log #1，Log #2，Log #3，Log #4，Log #1，Log #2，依此類推。

在迴圈日誌記錄模式下，只要一個日誌只包含已提交且 被具體化到資料庫磁碟上的事務的資訊，那麼它就可以被重用。換句話說，如果日誌仍然是活動日誌，那麼它就不能被重用。

 

歸檔日誌記錄

當使用歸檔日誌記錄模式時，您要經常歸檔（保留）日誌。在迴圈日誌記錄模式下，已提交且被具體化的事務將被覆蓋，而在歸檔日誌記錄模式下，這些事務將得到保留。例如，如果有 4 個主日誌檔案，DB2 將按照以下順序使用它們：Log #1，Log #2，Log #3，Log #4，（如果 Log #1 的所有事務已被提交且具體化，則歸檔 Log #1），Log #5（如果 Log #2 的所有事務已被提交且具體化，則歸檔 Log #2），Log #6，依此類推。

 

一個資料庫的日誌記錄的型別是由資料庫引數 LOGARCHMETH1 決定的。當 LOGARCHMETH1 為 OFF（預設值）時，歸檔日誌記錄被禁用，迴圈日誌記錄被啟用。

為了啟用歸檔日誌記錄，可以將 LOGARCHMETH1 設定為以下值中的任何一個值：

LOGRETAIN	日誌檔案將被保留在活動日誌目錄中
USEREXIT	日誌的歸檔和檢索是由使用者提供的使用者出口程式自動執行的，這個出口程式必須由 db2uext2 呼叫。這個程式用於將線上歸檔日誌移動到與活動日誌目錄不同的一個目錄中，或者移動到另一個媒介上。當在 ROLLFORWARD 操作期間需要某些離線歸檔日誌時，這個程式還可以用於將離線歸檔日誌取出到活動日誌目錄中。在 Windows 下，db2uext2 必須儲存在 sqllib\bin 目錄中，在 UNIX 下，db2uext2 必須儲存在 sqllib/adm 目錄中
DISK:directory_name	與 USEREXIT 使用相同的演算法。DB2 不呼叫使用者出口程式，而是自動將日誌檔案從活動日誌目錄歸檔到指定的目錄
TSM:[management class name]	與 USEREXIT 使用相同的演算法。日誌被歸檔到本地 Tivoli Storage Manger (TSM) 伺服器上。management class name 引數是可選的。如果沒有指定該引數，則使用預設的管理類
VENDOR:library_name	與 USEREXIT 使用相同的演算法。日誌是使用指定供應商的庫來歸檔的

由於向後相容的原因，資料庫配置檔案仍然包含引數 LOGRETAIN 和 USEREXIT。從 8.2 版開始，這兩個引數已經被 LOGARCHMETH1 取代。如果更新 USEREXIT 或 LOGRETAIN 引數，那麼 LOGARCHMETH1 將自動被更新，反之亦然。

 

無限日誌記錄

不管是使用迴圈日誌記錄還是歸檔日誌記錄，日誌空間都可能被填滿活動日誌。如果啟用無限日誌記錄，DB2 就會在一個日誌被填滿時立即歸檔這個日誌。它不會等到日誌中所有的事務都已經被提交且具體化的時候才來歸檔日誌。這樣可以保證活動日誌目錄永遠不會被填滿。例如，如果有一個長時間執行的事務，在啟用無限日誌記錄模式的情況下，就不會出現日誌空間被耗盡的情況。

要啟用無限日誌記錄：

1.  將 LOGSECOND 資料庫配置引數設定為 -1。

2.  啟用歸檔日誌記錄。

 

 

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25744374/viewspace-750126/，如需轉載，請註明出處，否則將追究法律責任。