DB2日志傳送基礎知識(1)

本文描述了在開放系統上使用 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 的示例。