DB2的高可用性和災難恢復概述

2024-07-21 02:41:28

字體：大中小

來源：轉載

供稿：網友

　　【導讀】數據的高可用性和災難恢復的能力是對要害數據庫系統的主要需求。本文概述了 DB2 UDB 的特性，這些特性提供了這些能力，并且讓您知道它們的優缺點，這樣您就可以判定哪種方法最適合您。簡介　　高可用性和災難恢復是要害數據庫應用程序的重要需求。IBM DB2 通用數據庫（DB2）提供了許多特性來滿足這些需求。假如您還不熟悉分布式平臺上的 DB2，或者即使您已用了一段時間，您也許仍會覺得處理可用性和恢復的許多特性令人感到迷惑。您何時使用哪一種特性，當您使用它時，您可以希望完成什么？　　本文旨在概述這些特性，并指導您理解如何使用 DB2 技術來構建高度可用和可恢復的數據庫系統。此外，每種解決方案都有其成本以及獨有的優點，因此我們將討論它們的優缺點。　　在開始之前，讓我們先研究術語高可用性（high availability，HA）和災難恢復（disaster recovery，DR）。在運用 HA 和 DR 的技術中，它們經常有相交的地方，但它們有兩個不同的用途。　　高可用性是這樣一種需求：每當需要時，數據就可用于從屬應用程序。其目的是消除或最小化停機時間。　　災難恢復防止由于毀滅性的故障而導致數據丟失。這類故障意味著由于不可恢復的情況而丟失數據。　　術語和客戶機／服務器數據庫體系結構　　我們將首先討論一些術語和概念，當討論高可用性和災難恢復時，應該要理解這些術語和概念。　　在數據庫體系結構討論中經常會用到術語群集（cluster）。有兩種類型的 DB2 數據庫群集：高可用性和高可伸縮性（high scalability）。雖然在一個解決方案中可以結合這兩種群集，但應該將它們看作是互斥的實體。高可伸縮性群集（也稱作數據庫分區）結合了多臺服務器的聚集能力以產生高性能解決方案。該技術通常用于構建數據倉庫或大型事務系統，而在這樣的數據倉庫或系統中，單個服務器是無法實現性能目標的。高可用性群集產生一個能最大化數據庫正常運行時間的系統。在本文中，術語“群集”僅指高可用性群集。　　HA 數據庫解決方案有三個部分：　　用戶應用程序　　客戶機軟件　　數據庫引擎　　當設計 HA 解決方案時，應該考慮所有這三個方面。僅使數據庫引擎成為高度可用并不一定能創建出 HA 解決方案。本文的重點是數據庫引擎正常運行時間，但您應該將這一問題看作只是整體解決方案的一部分。　　數據庫應用程序是基于客戶機／服務器的。應用程序依靠數據庫軟件的完整性來產生一致的結果。雖然這看起來似乎相當明顯，但當選擇和設計解決方案時理解如何實現這一點非常重要。　　當應用程序提交 SQL 事務時，在可以假設事務完成之前它必須接收返回碼。應用程序并不與數據庫引擎直接交互。事務經由客戶機軟件傳遞到引擎。由客戶機軟件將響應返回給應用程序。正的返回碼表示成功的情況，而負的返回碼表示失敗。應用程序如何處理這些情況對于整體 HA 解決方案很重要。通過包含返回碼邏輯，尤其是關于事務失敗的，應用程序可以使 HA 解決方案對于最終用戶顯得更加天衣無縫。　　數據庫引擎通過實現事務日志來確保完整性，事務日志存儲了所有插入、更新和刪除活動。事務日志確保了數據庫更改只在應用程序發出提交語句后接收到正的返回碼時才算完成。事務日志是 HA 和 DR 解決方案的基礎部分。　　在可以提交 SQL 事務之前，必須建立到數據庫的連接。CONNECT 語句用于建立數據庫連接，但有一些基本特性會影響連接被路由到哪里。客戶機軟件有兩個目錄告訴它如何路由數據庫連接嘗試：　　節點目錄（node directory）列出了服務器的位置（服務器的 ip 地址或主機名）和數據庫服務器用于偵聽數據庫連接嘗試的端口。　　數據庫目錄（database directory）列出了數據庫名稱、數據庫別名和節點目錄中用于建立連接的對應項。　　當應用程序發出 CONNECT 語句時，會搜索數據庫目錄來查看是否存在這個數據庫名或數據庫別名。假如這一項的類型是“indirect”，那么數據庫是本地的，并通過共享存儲段建立該連接。假如這一項的類型是“remote”，那么節點名用于指向節點目錄中的正確項。節點目錄信息答應客戶機軟件正確路由連接嘗試。通過了解客戶機如何通過目錄結構建立數據庫連接，在您規劃 HA 解決方案時就可以規劃資源移動。　　高可用性　　選擇高可用性解決方案很大程度上取決于客戶的業務需求。有兩種類型的高可用性可供選擇：持續可用性（continuous availability）和故障轉移可用性（failover availability）。　　持續可用性　　持續可用性要求數據庫引擎可隨時用于處理 SQL 事務。這類可用性通常只在最要害的應用程序中實現。要實現這個目標，要求百分之百的冗余。那意味著您必須有兩個完全互相獨立（包括在硬件和軟件方面）的系統。　　基本上，SQL 事務在這兩個系統上發生。一個系統發生故障不會造成其伙伴系統上事務的處理發生中斷。要使這成為現實，應用程序必須知道這兩個系統，并且將每個事務實現為跨兩個系統的分布式工作單元（distributed unit of work，DUOW）。DUOW 是作為在系統之間協調的一個事務而執行的一系列 SQL 語句。應用程序將事務提交給這兩個系統，并從這兩個系統接收關于成功或失敗的返回碼。然后應用程序可以繼續處理另一個 DUOW 或執行另一種操作。假如發生故障，其中一個數據庫系統不能再為應用程序提供服務，則應用程序（被編碼為可以捕捉該錯誤）可以利用另一個系統繼續處理它的工作負載，而不會發生中斷。　　要實現 DUOW 需要類型 2 數據庫連接和事務監視器。類型 2 數據庫連接建立了適合于 DUOW 的環境。事務監視器負責實現 DUOW 并確保完成或回滾 DUOW 中的事務。DB2 可以充當事務監視器或者您可以使用另一家軟件供給商（如 Microsoft 或 BEA）的事務監視器。　　圖 1說明了通過使用 DUOW 提供的持續可用性解決方案。　　圖 1. 分布式工作單元　　

　　表 1. 持續可用性解決方案的優缺點　　

優點：	缺點：
100％正常運行時間	需要重復的硬件
	需要額外的應用程序編碼

　　現在，我們將轉到下一個高可用性解決方案。　　故障轉移可用性　　故障轉移可用性與持續可用性的區別在于：數據庫引擎會有一段時間（盡管時間很短暫）無法用于事務處理。這種解決方案的基本元素有：　　主系統和輔助系統　　故障檢測　　數據源移動　　兩個系統都有數據庫數據的副本，當檢測到故障時，就會發生故障轉移。在故障轉移過程中，數據源從主系統移到輔助系統。　　有兩種故障轉移可用性：同步（synchronous）和異步（asynchronous）。同步可用性保證了主系統和輔助系統上的數據源是一致的，而且在故障轉移之后維持完整的連續性。異步可用性不保證主系統和輔助系統數據庫是完全同步的。將數據庫更改從主系統移到輔助系統的方法會不同，但這個過程會生成一個時間窗口，在這段時間內數據還沒有從一個系統遷移到另一個系統。數據量也許會非常小，時間窗口可能會非常短，但您在決定解決方案時必須要考慮這一點。　　讓我們研究可以向您提供同步或異步故障轉移可用性的選項。　　專用的 HA 軟件選項　　同步方法涉及數據庫軟件與專用 HA 軟件的緊密集成以產生 HA 群集。HA 軟件支持由于操作系統平臺的不同而不同。常用的 HA 解決方案有：　　High Availability Cluster MultiPRocessing（HACMP — AIX）　　Microsoft Cluster Server（MSCS）— Windows　　Sun Cluster — Sun　　Steeleye 的 Lifekeeper — linux 和 Windows　　這些是我列出的針對各平臺的最常見選項。還有其它一些 HA 軟件解決方案，也可以使用它們。　　所有這些解決方案的工作方式基本相同。假如有故障，數據庫服務器可以從一臺機器移到備份系統上。要完成該任務，HA 軟件會將所有必需的資源移到輔助系統。這些資源包括物理數據庫的磁盤資源、網絡資源和數據庫服務器資源。　　在 HA 群集解決方案中，單個物理數據庫副本存儲在共享存儲系統上。在 DB2 環境中，一次只能有一個系統“擁有”存儲器陣列。當檢測到故障時，存儲器的所有權就會從主系統轉移到輔助系統。同時也會轉移網絡資源。最后，在輔助系統上啟動數據庫服務器資源，使數據庫變為可用。　　故障的檢測由服務器之間的“心跳”連接執行。這個“心跳”是 HA 軟件的一個功能，它可以察覺硬件和軟件故障。　　由于只有一個數據庫的副本，所以它始終是同步的。數據庫引擎的故障轉移和重新啟動的時間取決于以下因素：　　檢測故障所需的時間　　移動數據庫資源相關資源（存儲陣列和聯網資源等）所必需的時間長度　　DB2 引擎執行崩潰恢復所需的時間　　當數據庫沒有正確關閉時，DB2 總是會執行崩潰恢復。崩潰恢復是日志文件的處理，從而確保將所有已提交的事務都寫到磁盤并且回滾未提交的事務。執行該操作所需的時間取決于發生故障時數據庫日志中“打開”工作的量。整個故障轉移可能只需要幾秒鐘，假如要從日志文件中處理的工作量很大，可能會需要更長時間。　　這種可用性解決方案的一個優點是它不需要對應用程序或客戶機配置目錄做任何更改。HA 軟件為數據庫連接提供了一個虛擬的 IP 地址資源。當檢測到故障時，該 IP 地址就會進行故障轉移，應用程序可以使用它以前使用的同一條連接語句。發生故障轉移時，所有應用程序都會斷開連接，客戶機會將通信錯誤情況返回給應用程序。一旦數據庫服務器在輔助系統上運行之后，應用程序只要重新發出連接語句，就可以象以前一樣繼續處理工作了。　　這也稱作熱備用（hot standby）配置。但是，在等待故障轉移時，輔助系統并不一直空閑。也可以以相互接管（mutual takeover）配置來配置系統，在該配置中，這兩個服務器都主動地主管不同的數據庫。每臺機器都預備在發生故障時接管其伙伴的工作負載。　　圖 2. 專用的 HA 軟件選項　　表 2. 專用 HA 軟件選項的優缺點　　

優點：	缺點：
數據庫始終是同步的	需要額外的軟件來創建和配置解決方案
不需要更改應用程序或客戶機	沒有復制數據，因此提供較少的冗余
不需要用戶交互來檢測和初始化故障轉移	需要必須符合一些 HA 標準的外部存儲器
性能不受額外工作負載的干擾	由于硬件需求，限制了服務器之間的距離

　　數據復制選項　　DB2 UDB 包含了集成復制能力。DB2 的復制實現包括兩部分： Capture（捕捉）和 Apply（應用）。復制治理員指定表中要復制的復制源，然后通過使用前一步中的復制源作為其來源，在目標數據庫（輔助系統）上創建復制預訂。Capture 進程監控事務日志以獲取對復制源表的所有更改，然后將對這些表的任何更改放到登臺表中。Apply 程序定期讀取登臺表并將更改轉移到預訂目標。　　數據復制是一個異步過程。在已更改的數據還沒有放到登臺表中或者 Apply 程序還沒有將更改復制到目標系統期間，這兩個數據庫不是同步的。這不一定是一段很長的時間或很大的數據量，但必須考慮這一可能性。　　復制有幾個好的特性。它答應：假如不需要整個副本，可以只復制數據的子集。只要有足夠的網絡帶寬滿足用戶的需要，距離就不是問題。復制還答應在使用 IBM 的 Information Integrator 產品的情況下，可以在一個獨立的平臺或不同的數據庫治理系統上托管輔助系統。這兩個系統都是“活動的”，因此可以完成獨立的工作。例如，一個系統可以用于處理事務，而輔助系統可以用于創建報告或運行備份。　　復制只捕捉對源表的更改。它不會捕捉對系統目錄的更改。例如，必須在兩個系統上都執行對表許可權的更改，因為復制無法復制這項更改。　　此外，故障轉移過程不是自動的。發生故障后，系統治理員必須在客戶機上進行更改，這樣他們才可以針對輔助系統工作；或者在輔助系統上做更改，使它可以模擬主系統。這將答應應用程序按以前那樣繼續工作，而不必更改應用程序編碼。一個替代方法是使用諸如 IBM 的 Edge Server 之類的產品來治理服務器連接。假如應用程序是用戶應用程序，那么用戶只要連接到輔助數據庫，而不必對客戶機配置或數據庫服務器做任何實際的更改。　　運行復制有一些開銷。額外的工作量取決于對源表的插入、更新和刪除活動的量。不需要對基本表進行額外的鎖定，因為復制只分析日志文件，而不會分析基本表。但登臺表（更改表）的填充和這些事務的日志記錄需要數據庫資源。　　圖 3說明了用于高可用性的復制選項。　　圖 3. 復制　　

　　表 3. 復制解決方案的優缺點　　

優點：	缺點：
集成能力，不需要額外的軟件	過程是異步的，可能會因故障而丟失數據
在兩個地方復制數據，冗余更大	不會自動進行故障轉移，需要手工處理（或使用 Websphere Edge Server）
靈活的體系結構	不能復制所有數據庫更改
距離限制較少	主系統上有額外的工作負載
輔助系統可以執行第二份工作負載

　　日志傳送選項　　所有數據庫更改（插入、更新或刪除）都記錄在 DB2 事務日志中。事務日志主要用于崩潰恢復和在故障之后恢復系統。正如我們已經討論的，它們在復制中發揮作用。此外，它們還可用于另一個高可用性解決方案日志傳送（log shipping）。該 HA 方案類似于數據復制選項。它要求輔助系統預備好在主系統發生故障時進行接管。治理員通過恢復主系統數據庫的備份來創建這個輔助系統。通過恢復主系統的數據庫備份，備份系統將處于前滾暫掛狀態。事務日志從主系統轉移到輔助系統，并用于使數據庫前滾以完成事務。假如發生故障，治理員應停止前滾過程，并且使數據庫聯機。　　可以用幾種方式完成轉移日志文件的過程。主要方法是使用 DB2 的用戶出口（user exit）工具。用戶出口是當事務日志已滿并預備歸檔時調用的可執行應用程序。數據庫引擎將日志文件傳遞給用戶出口，用戶出口邏輯將執行所有必需的工作。用戶出口可以制作日志的副本、將它發送到磁帶設備、調用另一個程序或執行它被編碼來處理的任何例程。一個可能的選項是將日志文件復制到輔助系統可以讀取日志并應用日志中包含的事務的位置。　　與復制選項相同，日志傳送是一個異步過程。只要主系統上有活動日志文件并且還有未應用且未完成的日志文件，輔助系統就處于不同步狀態。　　DB2 確實有執行雙日志記錄的能力。這答應數據庫在不同卷上創建復制日志文件，從而增加冗余。此外，該方法不會在數據庫服務器上產生額外的開銷。與使用復制不同，該方法不會創建兩個活動的系統，因為備份系統在被治理員停止前滾暫掛狀態之前一直處于不可用狀態。　　圖 4說明了日志傳送過程。　　圖 4. 日志傳送　　

　　表 4. 日志傳送的優缺點　　

優點：	缺點：
集成能力，不需要額外的軟件	過程是異步的，可能會因故障而丟失數據
在兩個地方復制數據，冗余更大	不會自動進行故障轉移，需要手工處理
距離限制較少	輔助系統是被動的，只提供備份能力
活動系統上沒有額外工作負載

　　高級存儲選項　　現代的存儲子系統提供了許多高級特性。DB2 已經能夠利用這些高級特性來創建高可用性和災難恢復系統。雖然這些技術可能會不同，但高級存儲選項的基本要素就是能夠快速創建磁盤卷的相同副本。然后可以將這些卷安裝到輔助系統上。輔助系統可以充當備份系統或執行其它一些類型的工作負載。答應實現這一功能的 DB2 特性叫作暫掛 I/O（suspended I/O）。　　暫掛 I/O 這項技術答應數據庫引擎使數據庫處于一致狀態，同時又保持聯機。暫掛 I/O 狀態暫掛寫 I/O 操作，以防止對數據表空間和日志的寫操作。在數據庫離開暫掛 I/O 狀態之前，該數據庫仍可用于所有應用程序，處理只讀語句和延遲寫語句（插入、更新和刪除）。通過 SET WRITE SUSPEND 命令將數據庫置為暫掛狀態。暫掛數據庫之后，就可以制作數據庫的物理文件的副本。將需要數據庫目錄、日志文件和數據庫容器的副本。存儲硬件和軟件通過分割鏡像卷或其它高級復制技術，可以非常快地創建大量數據的副本。然后，所復制的卷可以用于創建備份系統。制作了副本之后，可以使用 SET WRITE RESUME 命令來繼續處理主系統上的所有事務。　　所復制的卷可以與 DB2INIDB 實用程序一起用來創建輔助系統。該實用程序有三個實現：SNAPSHOT、STANDBY 和 MIRROR：　　SNAPSHOT 實現只答應數據庫執行崩潰恢復。創建了一個復制的數據庫，但在恢復期間不回滾任何事務。該方法適用于創建測試環境或報告機器。它不提供用于數據庫恢復的方法，因此不應用作 HA 選項。　　STANDBY 和 MIRROR 方法答應創建恢復實現。在這兩種情況下，DB2INIDB 工具使數據庫處于前滾暫掛狀態。然后可以將主系統中的日志文件應用到備份系統。假如主系統發生故障，那么輔助系統將離開前滾暫掛狀態并聯機，預備處理事務。用 STANDBY 還是用 MIRROR 方法取決于如何應用日志以及如何使數據庫恢復聯機。　　STANDBY 方法使數據庫在獨立于主系統的位置恢復聯機，并答應在主系統處于暫掛狀態時，在輔助系統上進行數據庫備份。　　MIRROR 方法用所復制的卷替換原來的卷，而處理將在相同的位置中發生。　　如我在日志傳送部分所提到的，DB2 能夠生成雙日志。通過將日志放在不同的卷上，該能力可以與高級存儲選項一起使用來確保日志的完整性。DB2 用戶出口程序可以用于存儲和檢索日志文件，并治理已歸檔日志文件的位置。可以對用戶出口進行編碼，以將日志放到輔助系統或另一個可用位置上。　　圖 5顯示了高級存儲選項。　　圖 5. 高級存儲　　

　　表 5. 高級存儲的優缺點　　

優點：	缺點：
集成能力，不需要額外的軟件	過程是異步的，可能會因故障而丟失數據（這可以用雙日志記錄來彌補）
在兩個地方復制數據，冗余更大	不會自動進行故障轉移，需要手工處理
能夠迅速地復制大量數據	輔助系統處于前滾暫掛狀態，不可用
捕捉所有數據庫更改	需要高級硬件

　　災難恢復　　建立災難恢復計劃對于現代企業至關重要。企業數據庫中的信息對于進行業務活動是極其重要的。保護該數據以及在災難之后確保其“生命”是很重要的活動。當構建 DR 計劃時，有三個要害問題：　　需要防止的故障級別　　可接受的數據丟失量　　答應用于恢復的時間量。　　要防止的故障級別通常是近似性問題。原始數據與其備份之間在物理上有多緊密？備份數據可以在不同的驅動器上、在獨立的機器上、在獨立的樓層上或在不同的建筑物里。不可能猜測所有可能的災難。火災、水災或甚至用戶的惡作劇都可能是企業必須面對的問題。解決方案的設計應該包括公司希望防止最壞情況的方案。　　所有企業都不希望在故障之后丟失任何數據。雖然不丟失數據是可能的，但由于可能需要的復雜性和費用（尤其是假如所防止的故障級別非常高），這通常是不實際的。可接受的數據丟失量取決于數據對公司有多重要以及有什么資源可用于確保其生命。　　恢復所需的時間量類似于高可用性的目標。它與高可用性解決方案之間的差異在于所防止的故障類型以及通常認為合理的時間長度。HA 故障轉移通常以秒和分鐘來衡量，而災難恢復則可能以小時和天來進行衡量。不過并非總是這樣，但這個差異區分了對這些解決方案的相對期望。　　備份和恢復　　數據庫備份創建了數據庫的時間點映象，它是災難恢復解決方案的基本組件。DB2 提供了幾種備份，包括脫機備份、聯機備份和增量備份。從備份恢復所需的時間取決于數據庫的大小和可用于執行恢復的硬件資源。　　由于數據庫備份只捕捉時間點的數據，因此無法通過一個簡單恢復來恢復備份之后發生的任何數據更改。要恢復備份之后完成的事務，就需要應用日志文件。可以從備份和日志文件（通過在日志文件中進行“前滾”來應用）來恢復數據庫。這答應恢復到某個時間點或恢復到日志文件結束。　　因此，假如 DR 解決方案必須恢復自上次備份以來的事務，那么保留日志文件是非常要害的。有兩個提高日志保留的 DB2 特性：雙日志記錄和用戶出口工具，已在關于數據庫復制 HA 選項的部分中進行了討論。　　災難恢復方案　　災難恢復方案可以分成三類：　　簡單備份　　備份和日志保留　　高級存儲備份　　雖然不是每個解決方案都清楚地被劃入這三類中的某一類，但它們確實為您理解災難恢復選項提供了合理的框架。　　簡單備份　　只創建數據庫備份確實創建了一個 DR 解決方案。它也許是非常有限的，這取決于您的環境。通過從“活動”的系統上移走所創建的備份，可以提高保護的級別。增加數據庫備份的頻率也降低了數據丟失的風險。　　備份軟件對于創建和維護 DB2 備份可能非常有幫助。例如，IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了答應在其軟件控制的設備上直接備份和維護 DB2 數據庫的解決方案。這些設備可以是磁帶庫或另一種存儲設備。　　簡單備份適合于只讀數據庫或由能輕松重新創建的批處理作業填充的數據庫，或者在備份之間不必維護數據庫更改的情況下。　　表 6. 簡單備份的優缺點　　

	優點：	缺點：
保護級別：	數據庫備份可以轉移到外部位置，以提高保護級別
數據丟失的風險：		備份之間的數據更改可能會丟失（運行增量備份來降低風險的影響）
恢復所需的時間：		數據庫恢復需要很長時間

　　備份和日志保留　　保留數據庫日志文件與數據庫備份一起創建了更完善的 DR 解決方案。日志文件答應恢復備份之間發生的數據更改。　　該解決方案的真正復雜性在于保護日志文件以確保它們在恢復期間的可用性。假如選擇實現雙日志記錄，DB2 可以將日志文件放在不同的位置，假如確保這些位置在不同的存儲器陣列上，那么保護級別就會得到提高。　　但是，日志文件仍面臨存儲子系統故障。如在高可用性的日志傳送選項中所提到的，用戶出口程序可以提供重定位日志文件的替代方法。用戶出口可以將已關閉的日志文件移到當前系統可用存儲陣列之外的位置，從而提高保護級別。這里的告誡是它只移動已關閉的日志文件。即使已實現了雙日志記錄，包含活動事務的日志文件仍面臨因陣列丟失或存儲設備故障而產生的丟失。　　該解決方案適合于大多數面向商業事務的環境。它均衡了最小化數據丟失風險的需要和維護 DR 解決方案所需的成本。　　表 7. 備份加日志保留的優缺點　　

	優點：	缺點：
保護級別：	數據庫備份可以轉移到外部位置，以提高保護級別
數據丟失的風險：	假如使用適當的步驟來維護日志文件，會大大降低數據丟失的風險
恢復所需的時間：		數據庫恢復需要時間，應用日志文件將增加恢復時間

　　高級存儲備份　　我們在高可用性下的高級存儲選項部分中討論過這個主題，相同的原則在這里也適用。正如在那部分中所見的，STANDBY 方法答應當數據庫副本處于暫掛狀態時在輔助系統上執行數據庫備份。　　創建數據庫副本已經創建了 DR 解決方案的一部分。備份副本提高了保護級別。假如用雙日志記錄和用戶出口程序正確實現了這個高級存儲備份，那么它就為核心企業數據庫生成了最好的 DR 解決方案。　　該解決方案最適合處于企業活動核心的數據庫系統。示例可能包含了供給鏈治理和在線代理系統。　　表 8. 用于災難恢復的高級存儲備份優缺點　　

	優點：	缺點：
保護級別：	保護級別本來就很高，而且可以通過耦合存儲子系統來提高保護級別。
數據丟失的風險：	假如采用雙日志記錄和用戶出口程序，會大大降低數據丟失的風險
恢復所需的時間：	恢復所需的時間非常短。

　　結束語　　DB2 為構建高可用性和災難恢復解決方案提供了出色的技術。您應該根據您的業務需求、可用選項和解決方案需求來做出選擇。本文中討論的這些要點為進一步研究和評估提供了一個很好的框架。

上一篇：Windows環境下如何卸載DB2數據庫

下一篇：DB2中多種常用功能的解決方法（1）