【導(dǎo)讀】數(shù)據(jù)的高可用性和災(zāi)難恢復(fù)的能力是對要害數(shù)據(jù)庫系統(tǒng)的主要需求。本文概述了 DB2 UDB 的特性，這些特性提供了這些能力，并且讓您知道它們的優(yōu)缺點，這樣您就可以判定哪種方法最適合您。簡介高可用性和災(zāi)難恢復(fù)是要害數(shù)據(jù)庫應(yīng)用程序的重要需求。IBM DB2 通用數(shù)據(jù)庫（DB2）提供了許多特性來滿足這些需求。假如您還不熟悉分布式平臺上的 DB2，或者即使您已用了一段時間，您也許仍會覺得處理可用性和恢復(fù)的許多特性令人感到迷惑。您何時使用哪一種特性，當(dāng)您使用它時，您可以希望完成什么？本文旨在概述這些特性，并指導(dǎo)您理解如何使用 DB2 技術(shù)來構(gòu)建高度可用和可恢復(fù)的數(shù)據(jù)庫系統(tǒng)。此外，每種解決方案都有其成本以及獨有的優(yōu)點，因此我們將討論它們的優(yōu)缺點。在開始之前，讓我們先研究術(shù)語高可用性（high availability，HA）和災(zāi)難恢復(fù)（disaster recovery，DR）。在運(yùn)用 HA 和 DR 的技術(shù)中，它們經(jīng)常有相交的地方，但它們有兩個不同的用途。高可用性是這樣一種需求：每當(dāng)需要時，數(shù)據(jù)就可用于從屬應(yīng)用程序。其目的是消除或最小化停機(jī)時間。災(zāi)難恢復(fù)防止由于毀滅性的故障而導(dǎo)致數(shù)據(jù)丟失。這類故障意味著由于不可恢復(fù)的情況而丟失數(shù)據(jù)。術(shù)語和客戶機(jī)／服務(wù)器數(shù)據(jù)庫體系結(jié)構(gòu)我們將首先討論一些術(shù)語和概念，當(dāng)討論高可用性和災(zāi)難恢復(fù)時，應(yīng)該要理解這些術(shù)語和概念。在數(shù)據(jù)庫體系結(jié)構(gòu)討論中經(jīng)常會用到術(shù)語 群集（cluster）。有兩種類型的 DB2 數(shù)據(jù)庫群集： 高可用性和 高可伸縮性（high scalability）。雖然在一個解決方案中可以結(jié)合這兩種群集，但應(yīng)該將它們看作是互斥的實體。高可伸縮性群集（也稱作數(shù)據(jù)庫分區(qū)）結(jié)合了多臺服務(wù)器的聚集能力以產(chǎn)生高性能解決方案。該技術(shù)通常用于構(gòu)建數(shù)據(jù)倉庫或大型事務(wù)系統(tǒng)，而在這樣的數(shù)據(jù)倉庫或系統(tǒng)中，單個服務(wù)器是無法實現(xiàn)性能目標(biāo)的。高可用性群集產(chǎn)生一個能最大化數(shù)據(jù)庫正常運(yùn)行時間的系統(tǒng)。在本文中，術(shù)語“群集僅指高可用性群集。HA 數(shù)據(jù)庫解決方案有三個部分：用戶應(yīng)用程序客戶機(jī)軟件數(shù)據(jù)庫引擎當(dāng)設(shè)計 HA 解決方案時，應(yīng)該考慮所有這三個方面。僅使數(shù)據(jù)庫引擎成為高度可用并不一定能創(chuàng)建出 HA 解決方案。本文的重點是數(shù)據(jù)庫引擎正常運(yùn)行時間，但您應(yīng)該將這一問題看作只是整體解決方案的一部分。數(shù)據(jù)庫應(yīng)用程序是基于客戶機(jī)／服務(wù)器的。應(yīng)用程序依靠數(shù)據(jù)庫軟件的完整性來產(chǎn)生一致的結(jié)果。雖然這看起來似乎相當(dāng)明顯，但當(dāng)選擇和設(shè)計解決方案時理解如何實現(xiàn)這一點非常重要。當(dāng)應(yīng)用程序提交 SQL 事務(wù)時，在可以假設(shè)事務(wù)完成之前它必須接收返回碼。應(yīng)用程序并不與數(shù)據(jù)庫引擎直接交互。事務(wù)經(jīng)由客戶機(jī)軟件傳遞到引擎。由客戶機(jī)軟件將響應(yīng)返回給應(yīng)用程序。正的返回碼表示成功的情況，而負(fù)的返回碼表示失敗。應(yīng)用程序如何處理這些情況對于整體 HA 解決方案很重要。通過包含返回碼邏輯，尤其是關(guān)于事務(wù)失敗的，應(yīng)用程序可以使 HA 解決方案對于最終用戶顯得更加天衣無縫。數(shù)據(jù)庫引擎通過實現(xiàn)事務(wù)日志來確保完整性，事務(wù)日志存儲了所有插入、更新和刪除活動。事務(wù)日志確保了數(shù)據(jù)庫更改只在應(yīng)用程序發(fā)出提交語句后接收到正的返回碼時才算完成。事務(wù)日志是 HA 和 DR 解決方案的基礎(chǔ)部分。在可以提交 SQL 事務(wù)之前，必須建立到數(shù)據(jù)庫的連接。CONNECT 語句用于建立數(shù)據(jù)庫連接，但有一些基本特性會影響連接被路由到哪里。客戶機(jī)軟件有兩個目錄告訴它如何路由數(shù)據(jù)庫連接嘗試：節(jié)點目錄（node directory）列出了服務(wù)器的位置（服務(wù)器的 IP 地址或主機(jī)名）和數(shù)據(jù)庫服務(wù)器用于偵聽數(shù)據(jù)庫連接嘗試的端口。數(shù)據(jù)庫目錄（database directory）列出了數(shù)據(jù)庫名稱、數(shù)據(jù)庫別名和節(jié)點目錄中用于建立連接的對應(yīng)項。當(dāng)應(yīng)用程序發(fā)出 CONNECT 語句時，會搜索數(shù)據(jù)庫目錄來查看是否存在這個數(shù)據(jù)庫名或數(shù)據(jù)庫別名。假如這一項的類型是“indirect，那么數(shù)據(jù)庫是本地的，并通過共享存儲段建立該連接。假如這一項的類型是“remote，那么節(jié)點名用于指向節(jié)點目錄中的正確項。節(jié)點目錄信息答應(yīng)客戶機(jī)軟件正確路由連接嘗試。通過了解客戶機(jī)如何通過目錄結(jié)構(gòu)建立數(shù)據(jù)庫連接，在您規(guī)劃 HA 解決方案時就可以規(guī)劃資源移動。高可用性選擇高可用性解決方案很大程度上取決于客戶的業(yè)務(wù)需求。有兩種類型的高可用性可供選擇： 持續(xù)可用性（continuous availability）和 故障轉(zhuǎn)移可用性（failover availability）。持續(xù)可用性持續(xù)可用性要求數(shù)據(jù)庫引擎可隨時用于處理 SQL 事務(wù)。這類可用性通常只在最要害的應(yīng)用程序中實現(xiàn)。要實現(xiàn)這個目標(biāo)，要求百分之百的冗余。那意味著您必須有兩個完全互相獨立（包括在硬件和軟件方面）的系統(tǒng)。基本上，SQL 事務(wù)在這兩個系統(tǒng)上發(fā)生。一個系統(tǒng)發(fā)生故障不會造成其伙伴系統(tǒng)上事務(wù)的處理發(fā)生中斷。要使這成為現(xiàn)實，應(yīng)用程序必須知道這兩個系統(tǒng)，并且將每個事務(wù)實現(xiàn)為跨兩個系統(tǒng)的 分布式工作單元（distributed unit of work，DUOW）。DUOW 是作為在系統(tǒng)之間協(xié)調(diào)的一個事務(wù)而執(zhí)行的一系列 SQL 語句。應(yīng)用程序?qū)⑹聞?wù)提交給這兩個系統(tǒng)，并從這兩個系統(tǒng)接收關(guān)于成功或失敗的返回碼。然后應(yīng)用程序可以繼續(xù)處理另一個 DUOW 或執(zhí)行另一種操作。假如發(fā)生故障，其中一個數(shù)據(jù)庫系統(tǒng)不能再為應(yīng)用程序提供服務(wù)，則應(yīng)用程序（被編碼為可以捕捉該錯誤）可以利用另一個系統(tǒng)繼續(xù)處理它的工作負(fù)載，而不會發(fā)生中斷。要實現(xiàn) DUOW 需要類型 2 數(shù)據(jù)庫連接和事務(wù)監(jiān)視器。類型 2 數(shù)據(jù)庫連接建立了適合于 DUOW 的環(huán)境。事務(wù)監(jiān)視器負(fù)責(zé)實現(xiàn) DUOW 并確保完成或回滾 DUOW 中的事務(wù)。DB2 可以充當(dāng)事務(wù)監(jiān)視器或者您可以使用另一家軟件供給商（如 Microsoft 或 BEA）的事務(wù)監(jiān)視器。圖 1說明了通過使用 DUOW 提供的持續(xù)可用性解決方案。圖 1. 分布式工作單元表 1. 持續(xù)可用性解決方案的優(yōu)缺點優(yōu)點： 缺點： 100％ 正常運(yùn)行時間需要重復(fù)的硬件需要額外的應(yīng)用程序編碼現(xiàn)在，我們將轉(zhuǎn)到下一個高可用性解決方案。故障轉(zhuǎn)移可用性故障轉(zhuǎn)移可用性與持續(xù)可用性的區(qū)別在于：數(shù)據(jù)庫引擎會有一段時間（盡管時間很短暫）無法用于事務(wù)處理。這種解決方案的基本元素有：主系統(tǒng)和輔助系統(tǒng)故障檢測數(shù)據(jù)源移動兩個系統(tǒng)都有數(shù)據(jù)庫數(shù)據(jù)的副本，當(dāng)檢測到故障時，就會發(fā)生 故障轉(zhuǎn)移。在故障轉(zhuǎn)移過程中，數(shù)據(jù)源從主系統(tǒng)移到輔助系統(tǒng)。有兩種故障轉(zhuǎn)移可用性： 同步（synchronous）和 異步（asynchronous）。同步可用性保證了主系統(tǒng)和輔助系統(tǒng)上的數(shù)據(jù)源是一致的，而且在故障轉(zhuǎn)移之后維持完整的連續(xù)性。異步可用性不保證主系統(tǒng)和輔助系統(tǒng)數(shù)據(jù)庫是完全同步的。將數(shù)據(jù)庫更改從主系統(tǒng)移到輔助系統(tǒng)的方法會不同，但這個過程會生成一個時間窗口，在這段時間內(nèi)數(shù)據(jù)還沒有從一個系統(tǒng)遷移到另一個系統(tǒng)。數(shù)據(jù)量也許會非常小，時間窗口可能會非常短，但您在決定解決方案時必須要考慮這一點。讓我們研究可以向您提供同步或異步故障轉(zhuǎn)移可用性的選項。專用的 HA 軟件選項同步方法涉及數(shù)據(jù)庫軟件與專用 HA 軟件的緊密集成以產(chǎn)生 HA 群集。HA 軟件支持由于操作系統(tǒng)平臺的不同而不同。常用的 HA 解決方案有：High Availability Cluster Multiprocessing（HACMP — AIX）Microsoft Cluster Server（MSCS）— WindowsSun Cluster — SunSteeleye 的 Lifekeeper — Linux 和 Windows這些是我列出的針對各平臺的最常見選項。還有其它一些 HA 軟件解決方案，也可以使用它們。所有這些解決方案的工作方式基本相同。假如有故障，數(shù)據(jù)庫服務(wù)器可以從一臺機(jī)器移到備份系統(tǒng)上。要完成該任務(wù)，HA 軟件會將所有必需的資源移到輔助系統(tǒng)。這些資源包括物理數(shù)據(jù)庫的磁盤資源、網(wǎng)絡(luò)資源和數(shù)據(jù)庫服務(wù)器資源。在 HA 群集解決方案中，單個物理數(shù)據(jù)庫副本存儲在共享存儲系統(tǒng)上。在 DB2 環(huán)境中，一次只能有一個系統(tǒng)“擁有存儲器陣列。當(dāng)檢測到故障時，存儲器的所有權(quán)就會從主系統(tǒng)轉(zhuǎn)移到輔助系統(tǒng)。同時也會轉(zhuǎn)移網(wǎng)絡(luò)資源。最后，在輔助系統(tǒng)上啟動數(shù)據(jù)庫服務(wù)器資源，使數(shù)據(jù)庫變?yōu)榭捎谩９收系臋z測由服務(wù)器之間的“心跳連接執(zhí)行。這個“心跳是 HA 軟件的一個功能，它可以察覺硬件和軟件故障。由于只有一個數(shù)據(jù)庫的副本，所以它始終是同步的。數(shù)據(jù)庫引擎的故障轉(zhuǎn)移和重新啟動的時間取決于以下因素：檢測故障所需的時間移動數(shù)據(jù)庫資源相關(guān)資源（存儲陣列和聯(lián)網(wǎng)資源等）所必需的時間長度DB2 引擎執(zhí)行崩潰恢復(fù)所需的時間當(dāng)數(shù)據(jù)庫沒有正確關(guān)閉時，DB2 總是會執(zhí)行崩潰恢復(fù)。崩潰恢復(fù)是日志文件的處理，從而確保將所有已提交的事務(wù)都寫到磁盤并且回滾未提交的事務(wù)。執(zhí)行該操作所需的時間取決于發(fā)生故障時數(shù)據(jù)庫日志中“打開工作的量。整個故障轉(zhuǎn)移可能只需要幾秒鐘，假如要從日志文件中處理的工作量很大，可能會需要更長時間。這種可用性解決方案的一個優(yōu)點是它不需要對應(yīng)用程序或客戶機(jī)配置目錄做任何更改。HA 軟件為數(shù)據(jù)庫連接提供了一個虛擬的 IP 地址資源。當(dāng)檢測到故障時，該 IP 地址就會進(jìn)行故障轉(zhuǎn)移，應(yīng)用程序可以使用它以前使用的同一條連接語句。發(fā)生故障轉(zhuǎn)移時，所有應(yīng)用程序都會斷開連接，客戶機(jī)會將通信錯誤情況返回給應(yīng)用程序。一旦數(shù)據(jù)庫服務(wù)器在輔助系統(tǒng)上運(yùn)行之后，應(yīng)用程序只要重新發(fā)出連接語句，就可以象以前一樣繼續(xù)處理工作了。這也稱作 熱備用（hot standby）配置。但是，在等待故障轉(zhuǎn)移時，輔助系統(tǒng)并不一直空閑。也可以以 相互接管（mutual takeover）配置來配置系統(tǒng)，在該配置中，這兩個服務(wù)器都主動地主管不同的數(shù)據(jù)庫。每臺機(jī)器都預(yù)備在發(fā)生故障時接管其伙伴的工作負(fù)載。圖 2. 專用的 HA 軟件選項表 2. 專用 HA 軟件選項的優(yōu)缺點優(yōu)點： 缺點： 數(shù)據(jù)庫始終是同步的需要額外的軟件來創(chuàng)建和配置解決方案不需要更改應(yīng)用程序或客戶機(jī)沒有復(fù)制數(shù)據(jù)，因此提供較少的冗余不需要用戶交互來檢測和初始化故障轉(zhuǎn)移需要必須符合一些 HA 標(biāo)準(zhǔn)的外部存儲器性能不受額外工作負(fù)載的干擾由于硬件需求，限制了服務(wù)器之間的距離數(shù)據(jù)復(fù)制選項DB2 UDB 包含了集成復(fù)制能力。DB2 的復(fù)制實現(xiàn)包括兩部分： Capture（捕捉）和 Apply（應(yīng)用）。復(fù)制治理員指定表中要復(fù)制的復(fù)制源，然后通過使用前一步中的復(fù)制源作為其來源，在目標(biāo)數(shù)據(jù)庫（輔助系統(tǒng)）上創(chuàng)建復(fù)制預(yù)訂。Capture 進(jìn)程監(jiān)控事務(wù)日志以獲取對復(fù)制源表的所有更改，然后將對這些表的任何更改放到登臺表中。Apply 程序定期讀取登臺表并將更改轉(zhuǎn)移到預(yù)訂目標(biāo)。數(shù)據(jù)復(fù)制是一個異步過程。在已更改的數(shù)據(jù)還沒有放到登臺表中或者 Apply 程序還沒有將更改復(fù)制到目標(biāo)系統(tǒng)期間，這兩個數(shù)據(jù)庫不是同步的。這不一定是一段很長的時間或很大的數(shù)據(jù)量，但必須考慮這一可能性。復(fù)制有幾個好的特性。它答應(yīng)：假如不需要整個副本，可以只復(fù)制數(shù)據(jù)的子集。只要有足夠的網(wǎng)絡(luò)帶寬滿足用戶的需要，距離就不是問題。復(fù)制還答應(yīng)在使用 IBM 的 Information Integrator 產(chǎn)品的情況下，可以在一個獨立的平臺或不同的數(shù)據(jù)庫治理系統(tǒng)上托管輔助系統(tǒng)。這兩個系統(tǒng)都是“活動的，因此可以完成獨立的工作。例如，一個系統(tǒng)可以用于處理事務(wù)，而輔助系統(tǒng)可以用于創(chuàng)建報告或運(yùn)行備份。復(fù)制只捕捉對源表的更改。它不會捕捉對系統(tǒng)目錄的更改。例如，必須在兩個系統(tǒng)上都執(zhí)行對表許可權(quán)的更改，因為復(fù)制無法復(fù)制這項更改。此外，故障轉(zhuǎn)移過程不是自動的。發(fā)生故障后，系統(tǒng)治理員必須在客戶機(jī)上進(jìn)行更改，這樣他們才可以針對輔助系統(tǒng)工作；或者在輔助系統(tǒng)上做更改，使它可以模擬主系統(tǒng)。這將答應(yīng)應(yīng)用程序按以前那樣繼續(xù)工作，而不必更改應(yīng)用程序編碼。一個替代方法是使用諸如 IBM 的 Edge Server 之類的產(chǎn)品來治理服務(wù)器連接。假如應(yīng)用程序是用戶應(yīng)用程序，那么用戶只要連接到輔助數(shù)據(jù)庫，而不必對客戶機(jī)配置或數(shù)據(jù)庫服務(wù)器做任何實際的更改。運(yùn)行復(fù)制有一些開銷。額外的工作量取決于對源表的插入、更新和刪除活動的量。不需要對基本表進(jìn)行額外的鎖定，因為復(fù)制只分析日志文件，而不會分析基本表。但登臺表（更改表）的填充和這些事務(wù)的日志記錄需要數(shù)據(jù)庫資源。圖 3說明了用于高可用性的復(fù)制選項。圖 3. 復(fù)制表 3. 復(fù)制解決方案的優(yōu)缺點優(yōu)點： 缺點： 集成能力，不需要額外的軟件過程是異步的，可能會因故障而丟失數(shù)據(jù)在兩個地方復(fù)制數(shù)據(jù)，冗余更大不會自動進(jìn)行故障轉(zhuǎn)移，需要手工處理（或使用 Websphere Edge Server）靈活的體系結(jié)構(gòu)不能復(fù)制所有數(shù)據(jù)庫更改距離限制較少主系統(tǒng)上有額外的工作負(fù)載輔助系統(tǒng)可以執(zhí)行第二份工作負(fù)載日志傳送選項所有數(shù)據(jù)庫更改（插入、更新或刪除）都記錄在 DB2 事務(wù)日志中。事務(wù)日志主要用于崩潰恢復(fù)和在故障之后恢復(fù)系統(tǒng)。正如我們已經(jīng)討論的，它們在復(fù)制中發(fā)揮作用。此外，它們還可用于另一個高可用性解決方案 日志傳送（log shipping）。該 HA 方案類似于數(shù)據(jù)復(fù)制選項。它要求輔助系統(tǒng)預(yù)備好在主系統(tǒng)發(fā)生故障時進(jìn)行接管。治理員通過恢復(fù)主系統(tǒng)數(shù)據(jù)庫的備份來創(chuàng)建這個輔助系統(tǒng)。通過恢復(fù)主系統(tǒng)的數(shù)據(jù)庫備份，備份系統(tǒng)將處于前滾暫掛狀態(tài)。事務(wù)日志從主系統(tǒng)轉(zhuǎn)移到輔助系統(tǒng)，并用于使數(shù)據(jù)庫前滾以完成事務(wù)。假如發(fā)生故障，治理員應(yīng)停止前滾過程，并且使數(shù)據(jù)庫聯(lián)機(jī)。可以用幾種方式完成轉(zhuǎn)移日志文件的過程。主要方法是使用 DB2 的 用戶出口（user exit）工具。用戶出口是當(dāng)事務(wù)日志已滿并預(yù)備歸檔時調(diào)用的可執(zhí)行應(yīng)用程序。數(shù)據(jù)庫引擎將日志文件傳遞給用戶出口，用戶出口邏輯將執(zhí)行所有必需的工作。用戶出口可以制作日志的副本、將它發(fā)送到磁帶設(shè)備、調(diào)用另一個程序或執(zhí)行它被編碼來處理的任何例程。一個可能的選項是將日志文件復(fù)制到輔助系統(tǒng)可以讀取日志并應(yīng)用日志中包含的事務(wù)的位置。與復(fù)制選項相同，日志傳送是一個異步過程。只要主系統(tǒng)上有活動日志文件并且還有未應(yīng)用且未完成的日志文件，輔助系統(tǒng)就處于不同步狀態(tài)。DB2 確實有執(zhí)行雙日志記錄的能力。這答應(yīng)數(shù)據(jù)庫在不同卷上創(chuàng)建復(fù)制日志文件，從而增加冗余。此外，該方法不會在數(shù)據(jù)庫服務(wù)器上產(chǎn)生額外的開銷。與使用復(fù)制不同，該方法不會創(chuàng)建兩個活動的系統(tǒng)，因為備份系統(tǒng)在被治理員停止前滾暫掛狀態(tài)之前一直處于不可用狀態(tài)。圖 4說明了日志傳送過程。圖 4. 日志傳送表 4. 日志傳送的優(yōu)缺點優(yōu)點： 缺點： 集成能力，不需要額外的軟件過程是異步的，可能會因故障而丟失數(shù)據(jù)在兩個地方復(fù)制數(shù)據(jù)，冗余更大不會自動進(jìn)行故障轉(zhuǎn)移，需要手工處理距離限制較少輔助系統(tǒng)是被動的，只提供備份能力活動系統(tǒng)上沒有額外工作負(fù)載高級存儲選項現(xiàn)代的存儲子系統(tǒng)提供了許多高級特性。DB2 已經(jīng)能夠利用這些高級特性來創(chuàng)建高可用性和災(zāi)難恢復(fù)系統(tǒng)。雖然這些技術(shù)可能會不同，但高級存儲選項的基本要素就是能夠快速創(chuàng)建磁盤卷的相同副本。然后可以將這些卷安裝到輔助系統(tǒng)上。輔助系統(tǒng)可以充當(dāng)備份系統(tǒng)或執(zhí)行其它一些類型的工作負(fù)載。答應(yīng)實現(xiàn)這一功能的 DB2 特性叫作 暫掛 I/O（suspended I/O）。暫掛 I/O 這項技術(shù)答應(yīng)數(shù)據(jù)庫引擎使數(shù)據(jù)庫處于一致狀態(tài)，同時又保持聯(lián)機(jī)。暫掛 I/O 狀態(tài)暫掛寫 I/O 操作，以防止對數(shù)據(jù)表空間和日志的寫操作。在數(shù)據(jù)庫離開暫掛 I/O 狀態(tài)之前，該數(shù)據(jù)庫仍可用于所有應(yīng)用程序，處理只讀語句和延遲寫語句（插入、更新和刪除）。通過 SET WRITE SUSPEND 命令將數(shù)據(jù)庫置為暫掛狀態(tài)。暫掛數(shù)據(jù)庫之后，就可以制作數(shù)據(jù)庫的物理文件的副本。將需要數(shù)據(jù)庫目錄、日志文件和數(shù)據(jù)庫容器的副本。存儲硬件和軟件通過分割鏡像卷或其它高級復(fù)制技術(shù)，可以非常快地創(chuàng)建大量數(shù)據(jù)的副本。然后，所復(fù)制的卷可以用于創(chuàng)建備份系統(tǒng)。制作了副本之后，可以使用 SET WRITE RESUME 命令來繼續(xù)處理主系統(tǒng)上的所有事務(wù)。所復(fù)制的卷可以與 DB2INIDB 實用程序一起用來創(chuàng)建輔助系統(tǒng)。該實用程序有三個實現(xiàn)：SNAPSHOT、STANDBY 和 MIRROR：SNAPSHOT 實現(xiàn)只答應(yīng)數(shù)據(jù)庫執(zhí)行崩潰恢復(fù)。創(chuàng)建了一個復(fù)制的數(shù)據(jù)庫，但在恢復(fù)期間不回滾任何事務(wù)。該方法適用于創(chuàng)建測試環(huán)境或報告機(jī)器。它不提供用于數(shù)據(jù)庫恢復(fù)的方法，因此不應(yīng)用作 HA 選項。STANDBY 和 MIRROR 方法答應(yīng)創(chuàng)建恢復(fù)實現(xiàn)。在這兩種情況下，DB2INIDB 工具使數(shù)據(jù)庫處于前滾暫掛狀態(tài)。然后可以將主系統(tǒng)中的日志文件應(yīng)用到備份系統(tǒng)。假如主系統(tǒng)發(fā)生故障，那么輔助系統(tǒng)將離開前滾暫掛狀態(tài)并聯(lián)機(jī)，預(yù)備處理事務(wù)。用 STANDBY 還是用 MIRROR 方法取決于如何應(yīng)用日志以及如何使數(shù)據(jù)庫恢復(fù)聯(lián)機(jī)。STANDBY 方法使數(shù)據(jù)庫在獨立于主系統(tǒng)的位置恢復(fù)聯(lián)機(jī)，并答應(yīng)在主系統(tǒng)處于暫掛狀態(tài)時，在輔助系統(tǒng)上進(jìn)行數(shù)據(jù)庫備份。MIRROR 方法用所復(fù)制的卷替換原來的卷，而處理將在相同的位置中發(fā)生。如我在日志傳送部分所提到的，DB2 能夠生成雙日志。通過將日志放在不同的卷上，該能力可以與高級存儲選項一起使用來確保日志的完整性。DB2 用戶出口程序可以用于存儲和檢索日志文件，并治理已歸檔日志文件的位置。可以對用戶出口進(jìn)行編碼，以將日志放到輔助系統(tǒng)或另一個可用位置上。圖 5顯示了高級存儲選項。圖 5. 高級存儲表 5. 高級存儲的優(yōu)缺點優(yōu)點： 缺點： 集成能力，不需要額外的軟件過程是異步的，可能會因故障而丟失數(shù)據(jù)（這可以用雙日志記錄來彌補(bǔ)）在兩個地方復(fù)制數(shù)據(jù)，冗余更大不會自動進(jìn)行故障轉(zhuǎn)移，需要手工處理能夠迅速地復(fù)制大量數(shù)據(jù)輔助系統(tǒng)處于前滾暫掛狀態(tài)，不可用捕捉所有數(shù)據(jù)庫更改需要高級硬件災(zāi)難恢復(fù)建立災(zāi)難恢復(fù)計劃對于現(xiàn)代企業(yè)至關(guān)重要。企業(yè)數(shù)據(jù)庫中的信息對于進(jìn)行業(yè)務(wù)活動是極其重要的。保護(hù)該數(shù)據(jù)以及在災(zāi)難之后確保其“生命是很重要的活動。當(dāng)構(gòu)建 DR 計劃時，有三個要害問題：需要防止的故障級別可接受的數(shù)據(jù)丟失量答應(yīng)用于恢復(fù)的時間量。要防止的故障級別通常是近似性問題。原始數(shù)據(jù)與其備份之間在物理上有多緊密？備份數(shù)據(jù)可以在不同的驅(qū)動器上、在獨立的機(jī)器上、在獨立的樓層上或在不同的建筑物里。不可能猜測所有可能的災(zāi)難。火災(zāi)、水災(zāi)或甚至用戶的惡作劇都可能是企業(yè)必須面對的問題。解決方案的設(shè)計應(yīng)該包括公司希望防止最壞情況的方案。所有企業(yè)都不希望在故障之后丟失任何數(shù)據(jù)。雖然不丟失數(shù)據(jù)是可能的，但由于可能需要的復(fù)雜性和費用（尤其是假如所防止的故障級別非常高），這通常是不實際的。可接受的數(shù)據(jù)丟失量取決于數(shù)據(jù)對公司有多重要以及有什么資源可用于確保其生命。恢復(fù)所需的時間量類似于高可用性的目標(biāo)。它與高可用性解決方案之間的差異在于所防止的故障類型以及通常認(rèn)為合理的時間長度。HA 故障轉(zhuǎn)移通常以秒和分鐘來衡量，而災(zāi)難恢復(fù)則可能以小時和天來進(jìn)行衡量。不過并非總是這樣，但這個差異區(qū)分了對這些解決方案的相對期望。備份和恢復(fù)數(shù)據(jù)庫備份創(chuàng)建了數(shù)據(jù)庫的時間點映象，它是災(zāi)難恢復(fù)解決方案的基本組件。DB2 提供了幾種備份，包括脫機(jī)備份、聯(lián)機(jī)備份和增量備份。從備份恢復(fù)所需的時間取決于數(shù)據(jù)庫的大小和可用于執(zhí)行恢復(fù)的硬件資源。由于數(shù)據(jù)庫備份只捕捉時間點的數(shù)據(jù)，因此無法通過一個簡單恢復(fù)來恢復(fù)備份之后發(fā)生的任何數(shù)據(jù)更改。要恢復(fù)備份之后完成的事務(wù)，就需要應(yīng)用日志文件。可以從備份和日志文件（通過在日志文件中進(jìn)行“前滾來應(yīng)用）來恢復(fù)數(shù)據(jù)庫。這答應(yīng)恢復(fù)到某個時間點或恢復(fù)到日志文件結(jié)束。因此，假如 DR 解決方案必須恢復(fù)自上次備份以來的事務(wù)，那么保留日志文件是非常要害的。有兩個提高日志保留的 DB2 特性：雙日志記錄和用戶出口工具，已在關(guān)于數(shù)據(jù)庫復(fù)制 HA 選項的部分中進(jìn)行了討論。災(zāi)難恢復(fù)方案災(zāi)難恢復(fù)方案可以分成三類：簡單備份備份和日志保留高級存儲備份雖然不是每個解決方案都清楚地被劃入這三類中的某一類，但它們確實為您理解災(zāi)難恢復(fù)選項提供了合理的框架。簡單備份只創(chuàng)建數(shù)據(jù)庫備份確實創(chuàng)建了一個 DR 解決方案。它也許是非常有限的，這取決于您的環(huán)境。通過從“活動的系統(tǒng)上移走所創(chuàng)建的備份，可以提高保護(hù)的級別。增加數(shù)據(jù)庫備份的頻率也降低了數(shù)據(jù)丟失的風(fēng)險。備份軟件對于創(chuàng)建和維護(hù) DB2 備份可能非常有幫助。例如，IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了答應(yīng)在其軟件控制的設(shè)備上直接備份和維護(hù) DB2 數(shù)據(jù)庫的解決方案。這些設(shè)備可以是磁帶庫或另一種存儲設(shè)備。簡單備份適合于只讀數(shù)據(jù)庫或由能輕松重新創(chuàng)建的批處理作業(yè)填充的數(shù)據(jù)庫，或者在備份之間不必維護(hù)數(shù)據(jù)庫更改的情況下。表 6. 簡單備份的優(yōu)缺點優(yōu)點： 缺點： 保護(hù)級別： 數(shù)據(jù)庫備份可以轉(zhuǎn)移到外部位置，以提高保護(hù)級別數(shù)據(jù)丟失的風(fēng)險： 備份之間的數(shù)據(jù)更改可能會丟失（運(yùn)行增量備份來降低風(fēng)險的影響）恢復(fù)所需的時間： 數(shù)據(jù)庫恢復(fù)需要很長時間備份和日志保留保留數(shù)據(jù)庫日志文件與數(shù)據(jù)庫備份一起創(chuàng)建了更完善的 DR 解決方案。日志文件答應(yīng)恢復(fù)備份之間發(fā)生的數(shù)據(jù)更改。該解決方案的真正復(fù)雜性在于保護(hù)日志文件以確保它們在恢復(fù)期間的可用性。假如選擇實現(xiàn)雙日志記錄，DB2 可以將日志文件放在不同的位置，假如確保這些位置在不同的存儲器陣列上，那么保護(hù)級別就會得到提高。但是，日志文件仍面臨存儲子系統(tǒng)故障。如在高可用性的日志傳送選項中所提到的，用戶出口程序可以提供重定位日志文件的替代方法。用戶出口可以將已關(guān)閉的日志文件移到當(dāng)前系統(tǒng)可用存儲陣列之外的位置，從而提高保護(hù)級別。這里的告誡是它只移動已關(guān)閉的日志文件。即使已實現(xiàn)了雙日志記錄，包含活動事務(wù)的日志文件仍面臨因陣列丟失或存儲設(shè)備故障而產(chǎn)生的丟失。該解決方案適合于大多數(shù)面向商業(yè)事務(wù)的環(huán)境。它均衡了最小化數(shù)據(jù)丟失風(fēng)險的需要和維護(hù) DR 解決方案所需的成本。表 7. 備份加日志保留的優(yōu)缺點優(yōu)點： 缺點： 保護(hù)級別： 數(shù)據(jù)庫備份可以轉(zhuǎn)移到外部位置，以提高保護(hù)級別數(shù)據(jù)丟失的風(fēng)險： 假如使用適當(dāng)?shù)牟襟E來維護(hù)日志文件，會大大降低數(shù)據(jù)丟失的風(fēng)險恢復(fù)所需的時間： 數(shù)據(jù)庫恢復(fù)需要時間，應(yīng)用日志文件將增加恢復(fù)時間高級存儲備份我們在高可用性下的高級存儲選項部分中討論過這個主題，相同的原則在這里也適用。正如在那部分中所見的，STANDBY 方法答應(yīng)當(dāng)數(shù)據(jù)庫副本處于暫掛狀態(tài)時在輔助系統(tǒng)上執(zhí)行數(shù)據(jù)庫備份。創(chuàng)建數(shù)據(jù)庫副本已經(jīng)創(chuàng)建了 DR 解決方案的一部分。備份副本提高了保護(hù)級別。假如用雙日志記錄和用戶出口程序正確實現(xiàn)了這個高級存儲備份，那么它就為核心企業(yè)數(shù)據(jù)庫生成了最好的 DR 解決方案。該解決方案最適合處于企業(yè)活動核心的數(shù)據(jù)庫系統(tǒng)。示例可能包含了供給鏈治理和在線代理系統(tǒng)。表 8. 用于災(zāi)難恢復(fù)的高級存儲備份優(yōu)缺點優(yōu)點： 缺點： 保護(hù)級別： 保護(hù)級別本來就很高，而且可以通過耦合存儲子系統(tǒng)來提高保護(hù)級別。數(shù)據(jù)丟失的風(fēng)險： 假如采用雙日志記錄和用戶出口程序，會大大降低數(shù)據(jù)丟失的風(fēng)險恢復(fù)所需的時間： 恢復(fù)所需的時間非常短。結(jié)束語DB2 為構(gòu)建高可用性和災(zāi)難恢復(fù)解決方案提供了出色的技術(shù)。您應(yīng)該根據(jù)您的業(yè)務(wù)需求、可用選項和解決方案需求來做出選擇。本文中討論的這些要點為進(jìn)一步研究和評估提供了一個很好的框架。