此文章主要介紹的是DB2無限活動日志策略,從介紹到實際的操作技巧，你如果對DB2無限活動日志策略,從介紹到實際的操作技巧有興趣的話你就可以點擊以下的文章進行觀看了。當數據庫第一次被創(chuàng)建的時候，有3個日志文件，被稱做主要日志文件，作為創(chuàng)建過程的一部分被分配了。

在Linux和Unix平臺上，這些日志文件共有1,000個大小為4KB的頁面；在Windows平臺上，這些日志文件共有250個大小為4KB的頁面。

然而，被使用的主要日志文件的數量，連同每一個能夠容納的數據量，都被數據庫配置文件中的logprimary 和logfilsiz 參數所控制。所有被創(chuàng)建的主要日志文件的使用方式都由為數據庫選擇的DB2無限活動日志策略所決定。有兩個可使用的不同的策略，一個是循環(huán)日志，一個是檔案歸建日志。但是一種被稱為無限活動日志的混合方式也許工作得最好。

循環(huán)日志要求存儲在日志緩沖區(qū)的記錄以循環(huán)的順序被寫入主要日志文件。一旦主要日志文件被寫滿，并且仍被標記為“不可用”，DB2數據庫管理器就會分配次要日志文件，并且將記錄寫入其中。被允許的次要日志文件的總數由數據庫配置文件的logsecond參數控制。

在檔案歸建日志中，與循環(huán)日志類似，存放在日志緩沖區(qū)的日志記錄被寫入預先分配的主要日志文件中。然而，與循環(huán)日志不同的是，這些日志文件永遠不會被重用。每次當主要日志文件被寫滿的時候，另一個主要日志文件就會被分配，這樣所要使用的主要日志文件的數量（由數據庫配置參數logprimary指定）就總是可得的。只要磁盤還有空間，這個過程就會持續(xù)下去。

無限活動日志。你也許考慮通過簡單地配置數據庫，讓其使用大量所需的主要和/或次要日志文件來避免日志空間被全部用光。然而，被允許的日志文件（主要的和次要的組合在一起）的最大數量是256個，并且如果你的日志文件的尺寸相對較小，那么當事務的工作量變大或者是事務運行了過長的時間，你仍然有可能很快地用光全部日志空間。

而且，由于每次被迫分配日志文件的時候都會影響性能，你就會想要盡可能地避免分配大量的次要日志文件。理想情況是，你希望分配足夠的主要日志文件來應付大多數情況，并且使用剛好可以應付事務的工作量最高峰時的數量的次要日志文件。

如果你非常關注DB2無限活動日志空間的消耗殆盡，并且你想要避免分配大量的次要日志文件，那么你可以配置數據庫，使其執(zhí)行一種被稱為無限活動日志或者無限日志的策略。無限活動日志允許一個跨越所有主要日志和一個或多個檔案歸建日志的活動事務，并且有效地允許事務使用無限數量的日志文件。

為了能夠使用無限活動日志，你只需簡單地設置數據庫配置參數userexit 和logsecond 分別為yes 和 –1。注意到下面這一點是很重要的，即當數據庫配置參數userexit設置為yes時，每當日志文件被關閉的時候，一個用戶提供的userexit 程序就會被調用，并且這個程序會將不需要的日志文件移動至另一個可以永久存儲的位置（因此，服務器上日志存儲空間被消耗殆盡的危險就會被消除）。

當服務器配置參數logsecond被設置為-1時，配置參數logprimary和logfilsiz仍然用于指定DB2在活動日志路徑上保留多少個主要日志文件，以及每個文件應該有多大。如果DB2需要從一個日志文件中讀取日志，但是這個文件不在活動日志路徑上，DB2就會調用userexit 程序從存檔文件中檢索日志文件，并且將其拷貝至活動日志區(qū)域，這樣其他針對相同文件的讀取就會加快速度。DB2管理著這些所需日志文件的檢索、拷貝和移除。

注意：雖然無限活動日志可被用于支持那些大的作業(yè)環(huán)境，它們需要的日志空間超出了正常情況下分配的主要日志空間，但是它仍然有它的權衡點。特別是，回滾操作（無論是在savepoint級，還是在事務級）的執(zhí)行，會由于需要在檔案存儲地點檢索日志文件而變得非常緩慢。同樣地，崩潰恢復也會由于同樣的原因而變得很慢。

【編輯推薦】

1. 是DB2還原某個表空間的實際操作步驟剖析
2. DB2數據庫的備份是否成功，一看就知道！
3. DB2實施備份時應作的事項有哪些？
4. IBM DB2 UDB 在線備份與恢復完美演習！
5. DB2數據庫備份與恢復命令的總結描述