我們今天主要向大家講述的是IBM DB2數據庫無限活動日志策略，我前兩天在相關網站看見IBM DB2數據庫無限活動日志策略的資料，覺得挺好，就拿出來供大家分享。如果你對其相關的實際操作有興趣的話，你就可以對以下的文章點擊觀看了。
當DB2數據庫第一次被創建的時候一共有三個日志文件，其被稱做主要日志文件，作為創建過程的一部分被分配了。在Linux和Unix平台上，這些日志文件共有1,000個大小為4KB的頁面;在Windows平台上，這些日志文件共有250個大小為4KB的頁面。
當數據庫第一次被創建的時候，有3個日志文件，被稱做主要日志文件，作為創建過程的一部分被分配了。在Linux和Unix平台上，這些日志文件共有1,000個大小為4KB的頁面;在Windows平台上，這些日志文件共有250個大小為4KB的頁面。
然而，被使用的主要日志文件的數量，連同每一個能夠容納的數據量，都被數據庫配置文件中的logprimary 和logfilsiz 參數所控制。所有被創建的主要日志文件的使用方式都由為數據庫選擇的日志策略所決定。有兩個可使用的不同的策略，一個是循環日志，一個是檔案歸建日志。但是一種被稱為無限活動日志的混合方式也許工作得最好。
循環日志要求存儲在日志緩沖區的記錄以循環的順序被寫入主要日志文件。一旦主要日志文件被寫滿，並且仍被標記為“不可用”，DB2數據庫管理器就會分配次要日志文件，並且將記錄寫入其中。被允許的次要日志文件的總數由數據庫配置文件的logsecond參數控制。
在檔案歸建日志中，與循環日志類似，存放在日志緩沖區的日志記錄被寫入預先分配的主要日志文件中。然而，與循環日志不同的是，這些日志文件永遠不會被重用。每次當主要日志文件被寫滿的時候，另一個主要日志文件就會被分配，這樣所要使用的主要日志文件的數量(由數據庫配置參數logprimary指定)就總是可得的。只要磁盤還有空間，這個過程就會持續下去。
無限活動日志。你也許考慮通過簡單地配置數據庫，讓其使用大量所需的主要和/或次要日志文件來避免日志空間被全部用光。然而，被允許的日志文件(主要的和次要的組合在一起)的最大數量是256個，並且如果你的日志文件的尺寸相對較小，那麼當事務的工作量變大或者是事務運行了過長的時間，你仍然有可能很快地用光全部日志空間。
而且，由於每次被迫分配日志文件的時候都會影響性能，你就會想要盡可能地避免分配大量的次要日志文件。理想情況是，你希望分配足夠的主要日志文件來應付大多數情況，並且使用剛好可以應付事務的工作量最高峰時的數量的次要日志文件。
如果你非常關注日志空間的消耗殆盡，並且你想要避免分配IBM DB2數據庫大量的次要日志文件，那麼你可以配置數據庫，使其執行一種被稱為無限活動日志或者無限日志的策略。無限活動日志允許一個跨越所有主要日志和一個或多個檔案歸建日志的活動事務，並且有效地允許事務使用無限數量的日志文件。
為了能夠使用無限活動日志，你只需簡單地設置數據庫配置參數userexit 和logsecond 分別為yes 和 –1。注意到下面這一點是很重要的，即當數據庫配置參數userexit設置為yes時，每當日志文件被關閉的時候，一個用戶提供的userexit 程序就會被調用，並且這個程序會將不需要的日志文件移動至另一個可以永久存儲的位置(因此，服務器上日志存儲空間被消耗殆盡的危險就會被消除)。
當服務器配置參數logsecond被設置為-1時，配置參數logprimary和logfilsiz仍然用於指定DB2在活動日志路徑上保留多少個主要日志文件，以及每個文件應該有多大。如果DB2需要從一個日志文件中讀取日志，但是這個文件不在活動日志路徑上，DB2就會調用userexit 程序從存檔文件中檢索日志文件，並且將其拷貝至活動日志區域，這樣其他針對相同文件的讀取就會加快速度。DB2管理著這些所需日志文件的檢索、拷貝和移除。
注意：雖然無限活動日志可被用於支持那些大的作業環境，IBM DB2數據庫需要的日志空間超出了正常情況下分配的主要日志空間，但是它仍然有它的權衡點。特別是，回滾操作(無論是在savepoint級，還是在事務級)的執行，會由於需要在檔案存儲地點檢索日志文件而變得非常緩慢。同樣地，崩潰恢復也會由於同樣的原因而變得很慢。
上述的相關內容就是對IBM DB2數據庫無限活動日志策略的描述，希望會給你帶來一些幫助在此方面。
