db2的日誌管理[轉]

問題13、db2日誌管理（完成）

---歸檔日誌

db2 update db cfg for dbtest using logretain recovery userexit on

db2 update db cfg for dbtest using logarchmeth1 DISK:D:/DB2/Arch_log

db2 update db cfg for dbtest using logarchmeth2 DISK:D:/DB2/Arch_log2

[@more@]

db2 update db cfg for dbtest using LOGPRIMARY 100 LOGSECOND 50 LOGFILSZ 65535 ;

(此時單個日誌檔案的大小為:65535 *4K ,可用日誌的個數為: 100+50 )

---迴圈日誌

/*Logretaim=Recovery --（Logretaim/userexit兩個值任選一個）

userexit=Yes*/

db2 update db cfg for edw using logarchmeth1 off logarchmeth2 off

db2 update db cfg for edw using logretain NO userexit NO

db2 update db cfg for edw using LOGPRIMARY 100 LOGSECOND 50 LOGFILSIZ 65535 ;

(此時單個日誌檔案的大小為:65535 *4K ,可用日誌的個數為: 100+50 )

--重啟資料庫才生效 （或者斷開所有連結）

set instance=db2inst4

db2stop force

db2start

db2 activate db edw

--更改聯機日誌的路徑（更改後logpath的值發生改變）

db2 update db cfg for edw using newlogpath /dw/edwdata/db2log

一.日誌概述

任何資料庫管理系統都必須擁有確保資料一致性和可恢復性的機制。關聯式資料庫系統為確保那些非常重要的特性所使用的眾多機制之一是事務性日誌記錄。在本文中，我們將定義和討論事務性日誌記錄的型別，及如何分配日誌檔案、如何儲存它們。

資料庫儲存了供應用程式訪問和處理的資料。那些應用程式會插入、讀取、更新或刪除資料。每一個這樣的活動都是在一個事務中執行的，該事務被 定義成“應用程式過程中一個可恢復的操作序列”。除非已經提交了事務（也稱作“工作單元”），否則它不會影響資料庫。

將資料庫操作組合到事務中只是確保資料一致性解決方案的一半。另一半是稱作預寫式日誌記錄（write-ahead logging）的資料庫管理器實現。不管事務是否被提交，只要它們發生，就會記錄這些事務。在將任何資料從緩衝池寫到資料庫結構之前，事務會從日誌緩衝區（log buffer）寫到 日誌檔案（事務性日誌記錄）。用於記錄事務的檔案叫做 事務日誌 。

二.日誌分類

DB2 UDB 有兩種可用的日誌記錄型別 — 迴圈（circular）日誌記錄和 歸檔（archive）日誌記錄。其中歸檔日誌又分為聯機歸檔日誌和離線歸檔日誌。

2.1迴圈日誌記錄

迴圈日誌記錄是資料庫使用的預設日誌記錄策略。在此策略中，一旦日誌目錄中最後一個主日誌檔案被寫滿了，就會將新的事務寫到第一個日誌檔案中，從而覆蓋現有的日誌資料。這些新事務會繼續依次覆蓋每個舊日誌檔案。這種日誌記錄方法確保了所有已提交事務的資料一致性，這樣就可以執行應急恢復。

迴圈日誌記錄通常在資料倉儲環境中使用，在該環境中，恢復資料庫需要的只是恢復資料庫映象的問題。該策略不應該用線上事務處理（on-line transaction processing，OLTP）環境，因為它不可能進行前滾恢復。

2.2歸檔日誌記錄

與迴圈日誌記錄相比，當最後一個日誌檔案寫滿時，歸檔日誌記錄過程會建立一個新的日誌檔案，這樣將來的事務就不會覆蓋現有的日誌檔案。當初始化資料庫時，系統會在活動日誌目錄中分配一定數量、指定大小的主日誌檔案。這個數量由資料庫配置引數控制。當主日誌檔案都寫滿時，就會“根據需要”建立輔助日誌檔案，直到建立了最大數量的輔助日誌檔案為止。一旦達到了這個數量，如果需要附加的日誌空間，就會發出一個錯誤，指出沒有更多的可用日誌檔案，所有資料庫活動停止。

利用歸檔日誌記錄，就可能採取聯機(線上)資料庫備份，在執行這一操作期間，會繼續記錄資料庫活動。如果資料庫崩潰或發生故障，就會使用全備份映象，然後執行使用歸檔日誌的前滾操作，透過前滾到日誌結尾，將資料庫恢復到時間點狀態或最近的一致狀態，從而恢復資料庫。

有兩種歸檔日誌：

聯機歸檔日誌: 活動日誌中所有改動對正常處理已不需要，即該日誌中所記錄的事務都已提交併寫入資料庫檔案時，該活動日誌轉換為聯機歸檔日誌。稱之為聯機，是由於它們與活動日誌存放在同一個目錄下。

離線歸檔日誌: 將聯機歸檔日誌從活動日誌目錄下Copy到另外的地方存檔，就稱為離線歸檔日誌。這些日誌可能在資料庫前滾恢復的時候仍然需要。

三．日誌相關引數

我們只有弄清楚了日誌相關的引數之後，才能正確修改配置引數，得到我們想要的日誌管理模式，現對各引數介紹如下：

3.1 LOGRETAIN

預設情況下，logretaim的值為OFF，此時採用迴圈日誌記錄方式，將期修改為ON/ RECOVERY時，採用歸檔日誌記錄方式，從而允許資料庫管理器使用前滾恢復方法，可以進行線上備份。該引數使歸檔日誌保留在資料庫日誌路徑目錄中。當啟用了 logretain配置引數時，就不需要啟用 userexit 。這兩個引數中的任何一個都足以允許前滾恢復方法。

以下是 logretain的有效值：

No（預設值）— 表示不保留日誌。

Recovery — 表示保留日誌，且可以用於前滾恢復。此外，如果您使用資料複製，CAPTURE 程式可以將日誌中所記錄的更新寫到更改表。

Capture — 表示只保留日誌，這樣 Capture 程式可以將更新寫到更改表。如果沒有裁剪這些日誌，那麼它們可以用於正向恢復。注：通常僅當為了資料複製而設定資料庫時，才使用 Capture 設定。

如果 logretain設定成“Recovery”或者 userexit設定成“Yes”，將保留活動日誌檔案，而且這些檔案將變成聯機歸檔日誌檔案，以便在前滾恢復中使用。這稱為日誌保留記錄。

在將 logretain設定成“Recovery”和／或將 userexit設定成“Yes”之後，必須對資料庫進行完全備份。這一狀態由backup_pending標誌參數列示。

如果 再logretain設定成“No”並且 userexit也設定成“No”，就不能對資料庫執行前滾恢復，而且可恢復性僅限於最新的資料庫備份。在這種情況下，資料庫管理器會刪除 logpath目錄中的所有日誌檔案（包括聯機歸檔日誌檔案），分配新的活動日誌檔案，並且回覆到迴圈日誌記錄。

當 logretain設定成“Capture”時，在 Capture 程式完成時，它會呼叫 PRUNE LOGFILE 命令來刪除日誌檔案。雖然如果不裁剪日誌，這些日誌就可以用於正向恢復，但如果您想要確保可以對資料庫執行前滾恢復，就不應該將 logretain設定成“Capture”。

當 logretain配置引數設定成“RECOVERY”時，日誌檔案將保留在活動日誌路徑中。活動日誌路徑由資料庫配置檔案中的“日誌檔案路徑（Path to Log Files）（ logpath）”或“更改的日誌檔案路徑（Changed Path to Log Files）（newlogpath）”值確定。

3.2 USEREXIT

該引數使資料庫管理器呼叫使用者出口程式來歸檔和檢索日誌。啟用了使用者出口之後，就允許前滾恢復。當啟用了userexit配置引數時，就不需要啟用 logretain。這兩個引數中的任何一個都足以允許前滾恢復方法。

使用該參數列示覆蓋了迴圈日誌記錄（預設值）。 userexit包含有 logretain的功能，反之卻不成立。

當使用 userexit 配置引數或 logretain配置引數以允許前滾恢復時，活動日誌路徑非常重要。當啟用了 userexit配置引數時，會呼叫使用者出口來歸檔日誌檔案，並將它們移到活動日誌路徑以外的位置。

以下是該引數的有效值：

No（預設值）

Yes

如果啟用了該引數，無論 logretain引數如何設定，都會執行日誌保留記錄。該引數還表示使用者出口程式應該用於歸檔和檢索日誌檔案。當資料庫管理器關閉日誌檔案時，會歸檔日誌檔案。當 ROLLFORWARD 實用程式需要使用日誌檔案來恢復資料庫時，就會檢索它們。

在啟用了引數 logretain和／或 userexit時，必須對資料庫進行完全備份。這一狀態由 backup_pending標誌參數列示。

如果取消選擇這兩個引數，就不能對資料庫進行前滾恢復，因為將不再保留日誌。在這種情況下，資料庫管理器會刪除logpath目錄中的所有日誌檔案（包括聯機歸檔日誌檔案），分配新的活動日誌檔案，並且回覆到迴圈日誌記錄。

3.3 LOGPRIMARY

該引數指定要建立的主日誌的數量。

無論主日誌是空的還是滿的，所需的磁碟空間量都是相同的。因此，如果您配置的日誌數量比需要的多，那麼您就不必要地多使用了磁碟空間。如果您配置的日誌太少了，就會遇到“日誌滿”情況。當選擇要配置的日誌數量時，必須考慮您生成的每個日誌的大小，以及您的應用程式是否能處理“日誌滿”情況。

對於 V8.1，這個限制是 256 GB。即，日誌檔案的數量（LOGPRIMARY ＋ LOGSECOND）乘以以位元組為單位的每個日誌檔案的大小（LOGFILSIZ * 4096）必須小於256 GB。

3.4 LOGSECOND

該引數指定為恢復日誌檔案（僅當需要時）而建立和使用的輔助日誌檔案的數量。請注意，日誌檔案的總數由以下等式限制：

logprimary＋ logsecond<＝ 256（DB2 UDB V8.1）

當主日誌檔案滿了時，就會按需要每次分配一個輔助日誌檔案（大小為 logfilsiz），最多達到由該引數控制的最大數量。如果所需的輔助日誌檔案的數量比該引數允許的數量大，就會將一個錯誤程式碼返回到應用程式，並且會停止對資料庫的操作。

3.5 LOGFILSZ

該引數確定了每個已配置日誌的頁數量。一頁的大小是 4 KB。每個主日誌的大小（頁數量）對資料庫效能有直接影響。當將資料庫配置成保留日誌，每當寫滿一個日誌時，就會發出一個分配和初始化一個新日誌的請求。增加日誌大小會減少為分配和初始化新日誌所需的請求數量。但是，請注意，日誌大小越大，格式化每個新日誌所花費的時間就越多。格式化新日誌對於連線到資料庫的應用程式是透明的，而且也不會影響資料庫效能。

3.6 LOGBUFSZ

該引數允許您指定資料庫共享記憶體的數量，在將日誌記錄寫到磁碟之前，用該共享記憶體作為這些記錄的緩衝區。當發生以下情況之一時，會將日誌記錄寫到磁碟：事務提交/日誌緩衝區滿了/引起寫操作的其它一些內部資料庫管理器事件。

緩衝日誌記錄將導致使日誌檔案 I/O 更有效，因為將日誌記錄寫到磁碟的頻率將更低，而每次寫入磁碟的日誌記錄則更多。

3.7 MINCOMMIT

該引數允許您延遲將日誌記錄寫到磁碟，直到已經執行了所規定的最小數量的提交。當您有多個針對資料庫的應用程式正在執行，並且應用程式在非常短的時間段裡請求了許多提交，那麼該延遲可以幫助減少與寫日誌記錄相關的資料庫管理器開銷，從而提高效能。

這種提交分組只有在該引數的值大於 1 且連線到資料庫的應用程式數量大於該引數的值時才會發生。當執行提交分組時，應用程式提交請求將被掛起，直到以下兩種情況有一種先發生：時間過去一秒或者提交請求的數量等於該引數的值。

3.8 NEWLOGPATH

資料庫日誌最初建立在名為 SQLOGDIR 的目錄中，該目錄是資料庫目錄的子目錄。可以透過將該配置引數的值更改成指向另一個目錄或裝置來更改放置活動日誌和將來歸檔日誌的位置。如果將資料庫配置成進行前滾恢復，那麼就不會將當前儲存在資料庫日誌路徑目錄中的歸檔日誌移到新的位置。

因為您可以更改日誌路徑位置，所以前滾恢復所需的日誌可能會在不同的目錄中或在不同的裝置上存在。在前滾過程中可以更改此配置引數以允許您訪問多個位置中的日誌。

在資料庫處於一致狀態之前，將不會更改對 newlogpath的值。資訊性資料庫配置引數 database_consistent表示資料庫的狀態。

注：資料庫管理器每次寫一個事務日誌。可以是活動狀態的事務的總大小受資料庫配置引數限制：