文章主要描述的是IBM DB2數據庫無限活動的日志策略詳細講解，我們大家都知道當數據庫***次被創建之時，其一共有3個日志文件，被稱做主要日志文件，作為創建過程的一部分被分配了。在Linux和Unix平臺上。

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

當IBM DB2數據庫***次被創建的時候，有3個日志文件，被稱做主要日志文件，作為創建過程的一部分被分配了。在Linux和Unix平臺上，這些日志文件共有1,000個大小為4KB的頁面;在Windows平臺上，這些日志文件共有250個大小為4KB的頁面。

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

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

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

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

理想情況是，你希望分配足夠的主要日志文件來應付大多數情況，并且使用剛好可以應付事務的工作量***峰時的數量的次要日志文件。如果你非常關注日志空間的消耗殆盡，并且你想要避免分配大量的次要日志文件，那么你可以配置數據庫，使其執行一種被稱為無限活動日志或者無限日志的策略。

無限活動日志允許一個跨越所有主要日志和一個或多個檔案歸建日志的活動事務，并且有效地允許事務使用無限數量的日志文件。為了能夠使用無限活動日志，你只需簡單地設置IBM DB2數據庫配置參數userexit 和logsecond 分別為yes 和 –1。

注意到下面這一點是很重要的，即當IBM DB2數據庫配置參數userexit設置為yes時，每當日志文件被關閉的時候，一個用戶提供的userexit 程序就會被調用，并且這個程序會將不需要的日志文件移動至另一個可以***存儲的位置(因此，服務器上日志存儲空間被消耗殆盡的危險就會被消除)。

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

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

以上的相關內容就是對IBM DB2數據庫無限活動日志策略的介紹，望你能有所收獲。

【編輯推薦】

1. DB2數據庫為單個會話鎖定“竅門”
2. 快速掌握DB2數據移動的操作技巧
3. DB2建立database Partition的點滴
4. DB2數據庫備份成功與否的正確驗證方式描述
5. DB2數據庫所支持的外部文件格式與制格式的文件