本文描述了在開放系統上使用 IBM® DB2® Universal Database™ 時配置日志傳送的概念和實現。由于數據庫系統對于企業成功變得越來越重要，對于全天不間斷(24x7)可用性的需求也就變得前所未有地強烈。一種常見的提供 99.99%(或“四個九”)可用性的方法是實現“熱”備用數據庫服務器。使用備用服務器并不是個新概念;數據庫管理員(DBA)們已經使用該方法多年了。通常，備用服務器需要 DBA 或操作員手工創建主系統上數據庫和日志的備份，然后定期地將這些備份恢復到備用服務器上。如果主服務器發生故障，則宕機時間僅限于處理自從將最近一次備份恢復到備用服務器以來的日志文件所需的時間量。
備用服務器故障轉移通常并不是自動的。相關人員必須確定啟用備用服務器所花費的時間是否少于修復主系統上的原始故障所花的時間。
日志傳送是什么?
日志傳送(log shipping)是一種方法，它自動從主 DB2 服務器備份事務日志，并使該備份自動對備用服務器可訪問。一旦將日志文件放到了備用服務器上，它就可以保持與主服務器的相對同步。
為什么要花費力氣實現日志傳送?
日志傳送有什么好處，您為什么要花費時間設置它呢?日志傳送提供了下列優點:
無需昂貴的軟件或硬件即可實現冗余故障轉移系統。無論從硬件還是軟件角度來看，主服務器和備用服務器不必相同。備用服務器可以用于其它用途;而不必長期閑置。例如，當輔助數據庫因處理進入的日志文件而處于不可訪問狀態時，可以在備用服務器上運行另一個獨立數據庫。
一旦設置好，配置成本相對低廉并且易于維護。
有非常可靠的方法用于提供數據庫的冗余副本。
由于數據庫處于前滾方式，因此它提供了熱備用，熱備用使數據庫啟動，并且已經準備好數據高速緩存。
能夠被配置成當故障出現時允許極少量的數據損失(如果有數據丟失的話)。
實現和維護配置的成本相對低廉。
支持本地位置和災難(遠程)方案。
有沒有局限?
日志傳送有一些局限。與 HACMP 或 Veritas Cluster 那樣的系統不同，它不提供完整的功能。但是，它也不需要額外的硬件或軟件。這可以歸結為一個權衡成本與可用性及復雜性的問題。對于大多數需要冗余系統，但在故障轉移方案期間可以接受一些數據丟失的客戶而言，日志傳送是一種實用的解決方案。
只有使用附加軟件，才能使日志傳送徹底自動化。DBA 或操作員仍然必須在發生故障時手工地將主服務器的功能轉移到備用服務器;但可以為這個故障編制腳本以最大限度地減少人為干預。用戶被中斷的時間，等于重播一個或多個日志文件并從任何不完整的事務回退所需時間的總和，外加重新連接用戶的應用程序所需的時間。使備用數據庫聯機所需的時間取決于該備用服務器處理進入的日志文件的頻率，以及日志文件的大小。
一旦將數據庫切換到備用服務器，就必須更改客戶機應用程序，使它也能指向新的服務器。或者，您可以轉移該服務器的主機名和 IP 地址。
操作方面的考慮事項
何時重新初始化備用數據庫
在 DB2 上重建索引時，會將一條日志記錄寫入日志，以表明該操作已啟動。當備用數據庫處理這條日志記錄時，它不會在備用服務器上自動重建該索引。(通過設置數據庫管理器 INDEXREC 配置值)可以將 DB2 配置為在其脫離前滾暫掛狀態(例如，接管時)之后，第一次連接到數據庫就重建索引，或者配置為在第一次嘗試訪問索引時進行重建。無論使用哪種方法，在發生系統故障轉移時，最終用戶都會察覺性能下降。防止這種情況的方法之一，是從主數據庫的備份映像重新填充備用數據庫，或者在重建索引時使用 I/O 暫掛和分離鏡像技術進行刷新。
在主數據庫上運行 DB2 裝入實用程序會影響備用數據庫服務器。當調用 LOAD 命令時，可以選擇讓裝入實用程序制作所裝入的表空間的備份映像，或者將備份映像的創建延遲到將來某個時間。如果選擇讓裝入實用程序創建備份映像，則備用服務器必須有權訪問裝入實用程序所用的目標設備。如果選擇以后再進行備份，或者在重播裝入日志記錄時備份映像不可用，那么備用服務器會將被裝入的表空間置于恢復暫掛狀態。在兩種情況下，您都應該在裝入操作完成后刷新備用數據庫，以確保在需要進行故障轉移的情況下，備用服務器上的所有數據都是可訪問的。
先決條件
以下是在 DB2 上設置和配置日志傳送之前必須滿足的先決條件:
主系統和備用系統都必須運行同一版本的 DB2。可以故障轉移到備用服務器以便在主系統上安裝 DB2 的新修訂包;但是，版本必須相同或更高。不能使用這種方法“回退”到某個修訂包，因為兩個系統不僅必須運行同一級別的 DB2，而且還必須運行同一級別的操作系統。
備用系統可用于數據庫和日志文件的磁盤空間必須至少和主系統的一樣多。您必須考慮在故障轉移到備用服務器時，主服務器可能幾天都無法使用的可能性。
必須在備用服務器上配置主服務器為數據庫維護而運行的所有自動化進程。DB2 只允許為每個實例配置一個用戶出口程序。如果備用服務器上已經有一個活動的數據庫，那么它使用的 DB2 實例應該獨立于主系統的 DB2 實例。
備用服務器上的日志歸檔目標必須可訪問。在故障轉移之后，必須保存日志文件，以便使主數據庫能夠恢復聯機， 必須在備用系統上恢復完整的數據庫備份，以初始化熱備用。在創建該備份之后，主系統上生成的所有日志文件也是必需的。
有哪些選項可用?
用 DB2 實現日志傳送有多種方法。本文討論了一些較為流行的方法。
在所有情況下，備用服務器都需要一個定期發出 db2 rollforward db to end of logs 命令的調度作業。這個命令運行的頻率決定了在故障轉移情形下使備用服務器可用的速度。
這種頻率還可以用作保護數據庫不受應用程序錯誤破壞的方法。例如，如果備用服務器一直保持比主服務器落后幾小時的狀態，一個應用程序破壞了數據庫中的數據，那么可以將數據庫故障轉移到備用服務器，以“回退”毀壞的數據，而對用戶影響卻很小。
所有日志傳送配置都是用用戶出口程序實現的。這是唯一可以用來在 DB2 中管理日志文件的方法。當一個日志文件滿了的時候，DB2 記錄器就將它歸檔。然后由 db2uext 可執行文件負責處理該日志文件。
日志傳送是否有不同的類型?
日志傳送有兩種方法。在 拉出方法中，備用服務器在需要時從中央共享位置(如日志歸檔目標)拉出日志文件。在 推方法中，主服務器確保當它歸檔主日志文件時使這些日志文件駐留在備用服務器上。
DB2 將日志文件歸檔到用戶出口程序 db2uext2 所指定的目標目錄中。該用戶出口程序的樣本位于 DB2 實例目錄 sqllib/samples/c 中。其中包括了用于磁盤、磁帶和 Tivoli? Storage Manager 的示例。
拉出方法
拉出方法涉及配置主系統上的用戶出口程序，以將日志文件歸檔到主服務器和備用服務器都有權訪問的目標設備上。備用服務器不會收到日志文件已歸檔的通知，而且必須檢查歸檔目標路徑。可以通過使用 db2uext2.cdisk 或 db2uext2.cadsm (在 DB2 未來的版本中將重命名為 db2uext2.ctsm )樣本用戶出口程序來做到這一點。用戶出口可執行文件必須位于主系統和備用系統的缺省 DB2 實例路徑中。
當在備用服務器上調用前滾數據庫命令時，DB2 記錄器自動嘗試從歸檔目標路徑中檢索下一個連續的日志文件。前滾操作持續檢索日志文件，直到再沒有需要處理的文件為止。
推方法
使用推方法，可以修改用戶出口程序，將日志文件復制或 FTP 到備用服務器的活動日志路徑或在備用服務器上可以訪問的溢出日志路徑。可以通過修改 db2uext2.cdisk 樣本程序，將備用服務器的日志路徑指定為目標來實現這一點。
當在備用服務器上調用 roll forward db 命令時，DB2 記錄器自動嘗試從歸檔目標路徑檢索下一個連續的日志文件。前滾操作持續檢索日志文件，直到再沒有需要處理的文件為止。
如何設置?
無論使用拉出方法還是推方法，大部分設置過程都與下面所說明的步驟類似:
將數據庫配置為啟用用戶出口程序和日志歸檔。做完這一點之后，數據庫將處于備份暫掛狀態。這個備份映像將成為恢復的初始起點，應該將它保留到執行下一次完整數據庫備份為止。
將用戶出口可執行文件置于 DB2 實例缺省搜索路徑中的某個位置。DB2 用戶出口程序的樣本源代碼模塊位于 DB2 實例 sqllib/samples/c 目錄中。它們是:
Db2uext2.cadsm — 對 Tivoli Storage Manager 的支持，也稱為 ADSM
Db2uext2.cdisk — 對磁盤的支持
Db2uext2.ctape — 對本地磁帶的支持，僅可用于 UNIX? 系統
Db2uext2.cxbsa — 對 XBSA Draft 0.8 客戶機的支持
這些樣本程序中的每個都只需要稍作修改(如 buffer_size 、 audit_log_activation 、 audit_log_path 、 error_log_activation 和 error_log_path )。每個樣本程序都包含一旦完成修改就必須發出的準確的編譯語句。
也有一些第三方供應商(如 Veritas、Legato 和 SAP)提供他們自己的 DB2 用戶出口二進制代碼，所有這些都可以用來實現日志傳送。
初始化備用服務器的數據庫。可以通過(聯機或脫機)恢復主服務器的完整 DB2 備份映像，或者通過使用分離鏡像副本來做到這一點。有關使用分離鏡像副本的詳細信息將在下面描述。在這兩種情況下，備用數據庫的硬件都不必與主數據庫的硬件相同。處理器和磁盤的個數和大小都可以完全不同。唯一的限制是備用數據庫上每個表空間的大小至少要和主數據庫上的一樣大。這是為了防止出現這樣的情況:備用系統的空間已經用盡，而主系統仍在繼續增長。如果物理磁盤布局不同，那么就需要進行重定向恢復來初始化備用數據庫。
在備用系統上配置調度作業以便定期發出 db2 rollforward to end of logs 命令。這樣會處理從主服務器接收的日志記錄，并使其備用服務器的日志保持最新。
現在備用服務器已經就緒。祝賀您!
如果“四個九”不夠好，那該怎么辦呢?
有許多辦法可確保在日志傳送配置中做到零數據丟失。但是，需要額外的配置和/或硬件。讓我們研究一些實現無數據丟失備用服務器的較流行的方法。
通過建立鏡像進行日志傳送
確保無數據丟失的方法之一是制作用于包含日志文件的卷的鏡像。可以使用操作系統的磁盤/卷鏡像功能來實現這種方法。使用這種方法時，寫入主數據庫的每條日志記錄也會被寫入備用數據庫。每條日志記錄都被寫入到這兩個系統中，這樣確保了無數據丟失。這種方法的缺點在于與兩次磁盤寫入操作相關的性能成本，其中一次寫入操作有可能是遠程的。
通過雙記錄進行日志傳送
另一種避免數據丟失的方法是利用 DB2 的雙日志記錄功能。當使用這種功能時，DB2 將同一日志記錄寫入到兩個地方。這兩個地方中的一個有可能是遠程安裝的文件系統。DB2 試圖將每條日志記錄寫入到兩條日志路徑。如果其中一條路徑發生錯誤，則將錯誤消息記錄到 db2diag.log 文件，而處理將繼續進行。如果對其中一條路徑的寫入操作失敗，那么除非活動日志文件已滿，否則 DB2 不會嘗試再向該路徑進行寫入操作。DB2 也不會在重新建立連接之后再次同步這兩個日志路徑。僅當主系統和備用系統之間的網絡連接高度可靠時，這種方法才是可行的。
利用智能存儲系統
現在，有許多智能存儲系統(如 IBM ESS、EMC 和 HDS)可供使用，它們為本地或遠程存儲系統提供了磁盤鏡像能力。這些系統中的每一個都提供了制作文件系統鏡像的同步或異步方法。有了智能存儲系統，主系統和備用系統之間日志文件鏡像的實現就會得到極大的簡化并且十分可靠。
結束語
總之，日志傳送是提供冗余故障轉移系統的相對簡單和廉價的方法。它易于設置和維護，并可用來支持本地位置和遠程位置兩種情形。這種災難恢復方法不會增加現任數據庫管理員的負擔，因為一旦完成設置，它可以自動運行。
(T114)