DB2記錄傳送基礎知識簡介

本文描述了在開放系統上使用 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 執行個體。

待命伺服器上的日誌歸檔目標必須可訪問。在容錯移轉之後，必須儲存記錄檔，以便使主要資料庫能夠恢複聯機， 必須在備用系統上恢複完整的Database Backup，以初始化熱備用。在建立該備份之後，主系統上產生的所有記錄檔也是必需的。

有哪些選項可用?

用 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 記錄器自動嘗試從歸檔目標路徑檢索下一個連續的記錄檔。前滾操作持續檢索記錄檔，直到再沒有需要處理的檔案為止。

如何設定?

無論使用拉出方法還是推方法，大部分設定過程都與下面所說明的步驟類似:

將資料庫配置為啟用使用者出口程式和日誌歸檔。做完這一點之後，資料庫將處於備份暫掛狀態。這個備份映像將成為恢複的初始起點，應該將它保留到執行下一次完整Database Backup為止。

將使用者出口可執行檔置於 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)可供使用，它們為本地或遠程儲存系統提供了磁碟鏡像能力。這些系統中的每一個都提供了製作檔案系統鏡像的同步或非同步方法呼叫。有了智能儲存系統，主系統和備用系統之間記錄檔鏡像的實現就會得到極大的簡化並且十分可靠。

結束語

總之，記錄傳送是提供冗餘容錯移轉系統的相對簡單和廉價的方法。它易於設定和維護，並可用來支援本地位置和遠程位置兩種情形。這種災難恢複方法不會增加現任資料庫管理員的負擔，因為一旦完成設定，它可以自動運行。

(