數據庫災難性恢復

數據庫災難性恢復

1 數據庫的選型

1.1 基本原則

選擇什麼樣的數據庫是否可以從幾個方面考慮：

1)企業根據自身規模和要求選擇適當規模的數據庫；

2)產品數據所要求的安全性；

3)數據庫本身的處理冗餘度的能力 ；

4)能處理多種格式的數據文件（企業內部流動的）。

 

1.2 數據庫以及數據庫服務器的選型

數據庫服務器上的存放着大量關鍵的信息和數據。而且，一旦數據庫系統發生異常錯誤或導致數據的丟失，其損失將是災難性的。

數據庫系統的衡量標準通常有兩個：一個是整個數據庫系統的運行性能，包括了一些典型操作的響應時間，以及在系統負載比較大的情況下，系統依然要有合理的運行表現；第二個是數據庫系統的穩定性，即數據庫系統能夠穩定持續運行的時間，要求能夠達到5×24。

基於服務器硬件的高可用性基於服務器硬件的高可用性通常包括兩個核心部分：一、運行性能，即在突然增加的負載下，如增加交易容量和用戶數量，系統依然有合理的運行表現；二、容錯性能，就是防止系統崩潰，如果任何部件出現失效，系統都不會損失關鍵數據且易於恢復正常，而對最終用戶的服務不會出現明顯的中斷。

由此，硬件系統的可靠性、穩定性、科學有效的維護是提高系統可用性指標的關鍵因素；對於避免人爲誤操作及防範病毒，除採用必要的技術手段外，更要建立一整套嚴格的計算機系統管理規程，防範於未然；對於系統的容災，選取恰當的冗餘備份措施，如服務器的冗餘、交換機等網絡鏈路的冗餘等。而在服務器和磁盤陣列上，採用RAID系統來存儲重要的數據庫數據和應用服務器系統的其它數據，如採用高性能的RAID-5實現數據冗餘，並且保證系統的吞吐能力，提升整體性能；此外，多項冗餘技術，如冗餘雙電源、冗餘I/O數據通道、冗餘總線，支持熱插拔、ECC內存及緩存等都將作爲服務器選型的基本技術依據。

所以採用的要求數據庫集羣方案既充分考慮系統的性能，又提供最可靠的運行環境。同時要做到資源的充分利用；另外，當其中的某一臺服務器由於發生錯誤，包括軟件和硬件錯誤，導致無法繼續提供服務時，所有的應用將被自動轉移到另一臺可用的服務器所上，這就充分保證了整個數據庫系統的高可用性。同時，整個數據庫集羣系統的規模可以根據用戶的需求來設計或改變。

2高可用性解決方案

2.1 涉及到的三個方面

當設計 HA 解決方案時，應該考慮所有這三個方面：用戶應用程序、客戶機軟件、數據庫引擎。

數據庫應用程序是基於客戶機／服務器的。應用程序依靠數據庫軟件的完整性來產生一致的結果。雖然這看起來似乎相當明顯，但當選擇和設計解決方案時理解如何實現這一點非常重要。

當應用程序提交 SQL 事務時，在可以假設事務完成之前它必須接收返回碼。應用程序並不與數據庫引擎直接交互。事務經由客戶機軟件傳遞到引擎。由客戶機軟件將響應返回給應用程序。正的返回碼錶示成功的情況，而負的返回碼錶示失敗。應用程序如何處理這些情況對於整體 HA 解決方案很重要。通過包含返回碼邏輯，尤其是關於事務失敗的，應用程序可以使 HA 解決方案對於最終用戶顯得更加天衣無縫。

數據庫引擎通過實現事務日誌來確保完整性，事務日誌存儲了所有插入、更新和刪除活動。事務日誌確保了數據庫更改只在應用程序發出提交語句後接收到正的返回碼時纔算完成。事務日誌是 HA 和 DR 解決方案的基礎部分。

在可以提交 SQL 事務之前，必須建立到數據庫的連接。CONNECT 語句用於建立數據庫連接，但有一些基本特性會影響連接被路由到哪裏。客戶機軟件有兩個目錄告訴它如何路由數據庫連接嘗試：

節點目錄（node directory）列出了服務器的位置（服務器的 IP 地址或主機名）和數據庫服務器用於偵聽數據庫連接嘗試的端口。

數據庫目錄（database directory）列出了數據庫名稱、數據庫別名和節點目錄中用於建立連接的對應項。

當應用程序發出 CONNECT 語句時，會搜索數據庫目錄來查看是否存在這個數據庫名或數據庫別名。如果這一項的類型是“indirect”，那麼數據庫是本地的，並通過共享存儲段建立該連接。如果這一項的類型是“remote”，那麼節點名用於指向節點目錄中的正確項。節點目錄信息允許客戶機軟件正確路由連接嘗試。通過了解客戶機如何通過目錄結構建立數據庫連接，在您規劃 HA 解決方案時就可以規劃資源移動。

2.2 高可用性的兩種類型

選擇高可用性解決方案很大程度上取決於客戶的業務需求。有兩種類型的高可用性可供選擇： 持續可用性（continuous availability）和 故障轉移可用性（failover availability）。

2.2.1 持續可用性

持續可用性要求數據庫引擎可隨時用於處理 SQL 事務。這類可用性通常只在最關鍵的應用程序中實現。要實現這個目標，要求百分之百的冗餘。那意味着您必須有兩個完全互相獨立（包括在硬件和軟件方面）的系統。

基本上，SQL 事務在這兩個系統上發生。一個系統發生故障不會造成其夥伴系統上事務的處理髮生中斷。要使這成爲現實，應用程序必須知道這兩個系統，並且將每個事務實現爲跨兩個系統的分佈式工作單元（distributed unit of work，DUOW）。DUOW 是作爲在系統之間協調的一個事務而執行的一系列 SQL 語句。應用程序將事務提交給這兩個系統，並從這兩個系統接收關於成功或失敗的返回碼。然後應用程序可以繼續處理另一個 DUOW 或執行另一種操作。如果發生故障，其中一個數據庫系統不能再爲應用程序提供服務，則應用程序（被編碼爲可以捕獲該錯誤）可以利用另一個系統繼續處理它的工作負載，而不會發生中斷。

要實現 DUOW 需要類型 2 數據庫連接和事務監視器。類型 2 數據庫連接建立了適合於 DUOW 的環境。事務監視器負責實現 DUOW 並確保完成或回滾 DUOW 中的事務。DB2 可以充當事務監視器或者您可以使用另一家軟件供應商（如 Microsoft 或 BEA）的事務監視器。

圖 1說明了通過使用 DUOW 提供的持續可用性解決方案。

圖 1. 分佈式工作單元

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

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

2.2.2 故障轉移可用性

故障轉移可用性與持續可用性的區別在於：數據庫引擎會有一段時間（儘管時間很短暫）無法用於事務處理。這種解決方案的基本元素有：

l         主系統和輔助系統

l         故障檢測

l         數據源移動

兩個系統都有數據庫數據的副本，當檢測到故障時，就會發生故障轉移。在故障轉移過程中，數據源從主系統移到輔助系統。

有兩種故障轉移可用性： 同步（synchronous）和 異步（asynchronous）。同步可用性保證了主系統和輔助系統上的數據源是一致的，而且在故障轉移之後維持完整的連續性。異步可用性不保證主系統和輔助系統數據庫是完全同步的。將數據庫更改從主系統移到輔助系統的方法會不同，但這個過程會生成一個時間窗口，在這段時間內數據還沒有從一個系統遷移到另一個系統。數據量也許會非常小，時間窗口可能會非常短，但是我們在決定解決方案時必須要考慮這一點。

下面就是兩四個同步或異步故障轉移可用性的選項。

 

1）專用的 HA 軟件選項

同步方法涉及數據庫軟件與專用 HA 軟件的緊密集成以產生 HA 羣集。HA 軟件支持由於操作系統平臺的不同而不同。常用的 HA 解決方案有：

l         High Availability Cluster Multiprocessing（HACMP — AIX）

l         Microsoft Cluster Server（MSCS）— Windows

l         Sun Cluster — Sun

l        Steeleye 的 Lifekeeper — Linux 和 Windows

這些列出的都是針對各平臺的最常見選項。還有其它一些 HA 軟件解決方案，也可以使用它們。

所有這些解決方案的工作方式基本相同。如果有故障，數據庫服務器可以從一臺機器移到備份系統上。要完成該任務，HA 軟件會將所有必需的資源移到輔助系統。這些資源包括物理數據庫的磁盤資源、網絡資源和數據庫服務器資源。

在 HA 羣集解決方案中，單個物理數據庫副本存儲在共享存儲系統上。在 DB2 環境中，一次只能有一個系統“擁有”存儲器陣列。當檢測到故障時，存儲器的所有權就會從主系統轉移到輔助系統。同時也會轉移網絡資源。最後，在輔助系統上啓動數據庫服務器資源，使數據庫變爲可用。

故障的檢測由服務器之間的“心跳”連接執行。這個“心跳”是 HA 軟件的一個功能，它可以察覺硬件和軟件故障。

由於只有一個數據庫的副本，所以它始終是同步的。數據庫引擎的故障轉移和重新啓動的時間取決於以下因素：

l         檢測故障所需的時間

l         移動數據庫資源相關資源（存儲陣列和聯網資源等）所必需的時間長度

l        DB2 引擎執行崩潰恢復所需的時間

當數據庫沒有正確關閉時，DB2 總是會執行崩潰恢復。崩潰恢復是日誌文件的處理，從而確保將所有已提交的事務都寫到磁盤並且回滾未提交的事務。執行該操作所需的時間取決於發生故障時數據庫日誌中“打開”工作的量。整個故障轉移可能只需要幾秒鐘，如果要從日誌文件中處理的工作量很大，可能會需要更長時間。

這種可用性解決方案的一個優點是它不需要對應用程序或客戶機配置目錄做任何更改。HA 軟件爲數據庫連接提供了一個虛擬的 IP 地址資源。當檢測到故障時，該 IP 地址就會進行故障轉移，應用程序可以使用它以前使用的同一條連接語句。發生故障轉移時，所有應用程序都會斷開連接，客戶機會將通信錯誤情況返回給應用程序。一旦數據庫服務器在輔助系統上運行之後，應用程序只要重新發出連接語句，就可以象以前一樣繼續處理工作了。

這也稱作 熱備用（hot standby）配置。但是，在等待故障轉移時，輔助系統並不一直空閒。也可以以 相互接管（mutual takeover）配置來配置系統，在該配置中，這兩個服務器都主動地主管不同的數據庫。每臺機器都準備在發生故障時接管其夥伴的工作負載。

圖 2. 專用的 HA 軟件選項

表 2. 專用 HA 軟件選項的優缺點

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

2）數據複製選項

DB2 UDB 包含了集成複製能力。DB2 的複製實現包括兩部分： Capture（捕獲）和 Apply（應用）。複製管理員指定表中要複製的複製源，然後通過使用前一步中的複製源作爲其來源，在目標數據庫（輔助系統）上創建複製預訂。Capture 進程監控事務日誌以獲取對複製源表的所有更改，然後將對這些表的任何更改放到登臺表中。Apply 程序定期讀取登臺表並將更改轉移到預訂目標。

數據複製是一個異步過程。在已更改的數據還沒有放到登臺表中或者 Apply 程序還沒有將更改複製到目標系統期間，這兩個數據庫不是同步的。這不一定是一段很長的時間或很大的數據量，但必須考慮這一可能性。

複製有幾個好的特性。它允許：如果不需要整個副本，可以只複製數據的子集。只要有足夠的網絡帶寬滿足用戶的需要，距離就不是問題。複製還允許在使用 IBM 的 Information Integrator 產品的情況下，可以在一個獨立的平臺或不同的數據庫管理系統上託管輔助系統。這兩個系統都是“活動的”，因此可以完成獨立的工作。例如，一個系統可以用於處理事務，而輔助系統可以用於創建報告或運行備份。

複製只捕獲對源表的更改。它不會捕獲對系統目錄的更改。例如，必須在兩個系統上都執行對錶許可權的更改，因爲複製無法複製這項更改。

此外，故障轉移過程不是自動的。發生故障後，系統管理員必須在客戶機上進行更改，這樣他們纔可以針對輔助系統工作；或者在輔助系統上做更改，使它可以模擬主系統。這將允許應用程序按以前那樣繼續工作，而不必更改應用程序編碼。一個替代方法是使用諸如 IBM 的 Edge Server 之類的產品來管理服務器連接。如果應用程序是用戶應用程序，那麼用戶只要連接到輔助數據庫，而不必對客戶機配置或數據庫服務器做任何實際的更改。

運行復制有一些開銷。額外的工作量取決於對源表的插入、更新和刪除活動的量。不需要對基本表進行額外的鎖定，因爲複製只分析日誌文件，而不會分析基本表。但登臺表（更改表）的填充和這些事務的日誌記錄需要數據庫資源。

圖 3說明了用於高可用性的複製選項。

圖 3. 複製

表 3. 複製解決方案的優缺點

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

 

3）日誌傳送選項

所有數據庫更改（插入、更新或刪除）都記錄在 DB2 事務日誌中。事務日誌主要用於崩潰恢復和在故障之後恢復系統。正如我們已經討論的，它們在複製中發揮作用。此外，它們還可用於另一個高可用性解決方案日誌傳送（log shipping）。該 HA 方案類似於數據複製選項。它要求輔助系統準備好在主系統發生故障時進行接管。管理員通過恢復主系統數據庫的備份來創建這個輔助系統。通過恢復主系統的數據庫備份，備份系統將處於前滾暫掛狀態。事務日誌從主系統轉移到輔助系統，並用於使數據庫前滾以完成事務。如果發生故障，管理員應停止前滾過程，並且使數據庫聯機。

可以用幾種方式完成轉移日誌文件的過程。主要方法是使用 DB2 的 用戶出口（user exit）工具。用戶出口是當事務日誌已滿並準備歸檔時調用的可執行應用程序。數據庫引擎將日誌文件傳遞給用戶出口，用戶出口邏輯將執行所有必需的工作。用戶出口可以製作日誌的副本、將它發送到磁帶設備、調用另一個程序或執行它被編碼來處理的任何例程。一個可能的選項是將日誌文件複製到輔助系統可以讀取日誌並應用日誌中包含的事務的位置。

與複製選項相同，日誌傳送是一個異步過程。只要主系統上有活動日誌文件並且還有未應用且未完成的日誌文件，輔助系統就處於不同步狀態。

DB2 確實有執行雙日誌記錄的能力。這允許數據庫在不同捲上創建複製日誌文件，從而增加冗餘。此外，該方法不會在數據庫服務器上產生額外的開銷。與使用複製不同，該方法不會創建兩個活動的系統，因爲備份系統在被管理員停止前滾暫掛狀態之前一直處於不可用狀態。

圖 4說明了日誌傳送過程。

圖 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：

l         SNAPSHOT 實現只允許數據庫執行崩潰恢復。創建了一個複製的數據庫，但在恢復期間不回滾任何事務。該方法適用於創建測試環境或報告機器。它不提供用於數據庫恢復的方法，因此不應用作 HA 選項。

l         STANDBY 和 MIRROR 方法允許創建恢復實現。在這兩種情況下，DB2INIDB 工具使數據庫處於前滾暫掛狀態。然後可以將主系統中的日誌文件應用到備份系統。如果主系統發生故障，那麼輔助系統將離開前滾暫掛狀態並聯機，準備處理事務。用 STANDBY 還是用 MIRROR 方法取決於如何應用日誌以及如何使數據庫恢復聯機。

l         STANDBY 方法使數據庫在獨立於主系統的位置恢復聯機，並允許在主系統處於暫掛狀態時，在輔助系統上進行數據庫備份。

l         MIRROR 方法用所複製的卷替換原來的卷，而處理將在相同的位置中發生。

如我在日誌傳送部分所提到的，DB2 能夠生成雙日誌。通過將日誌放在不同的捲上，該能力可以與高級存儲選項一起使用來確保日誌的完整性。DB2 用戶出口程序可以用於存儲和檢索日誌文件，並管理已歸檔日誌文件的位置。可以對用戶出口進行編碼，以將日誌放到輔助系統或另一個可用位置上。

圖 5顯示了高級存儲選項。

圖 5. 高級存儲

表 5. 高級存儲的優缺點

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

3災難及其恢復的基本類型

3.1 災難類型

爲了使數據庫損失降低到最小程度，需要一個恢復策略，確保它起作用，並經常實行策略，一些災難類型包括：

l         系統故障。電源故障、硬件故障或軟件故障都能夠使數據庫處於不一致狀態。

l         事務故障。用戶無意中會用錯誤數據修改數據庫，從而毀壞數據庫。

l         介質故障。如果磁盤驅動器變得不能使用，那麼可能會丟失所有或部分數據。

l         災難。系統所在的設施可能會遭受火災、洪水或其它類似災難的損壞。

3.2 恢復類型

DB2 考慮到了下列恢復類型：

l         崩潰恢復。這種類型的恢復通過撤銷（回滾）未提交的事務來防止數據庫處於不一致狀態。

l         版本恢復。這種類型的恢復通過使用從 BACKUP 命令獲取的備份映像來恢復先前的數據庫版本。恢復的數據庫將包含在執行 BACKUP 命令時所處狀態的信息。如果在執行備份之後針對數據庫執行進一步操作，那麼該信息將丟失。

l         前滾恢復。這種類型的恢復通過使用完全數據庫備份，結合日誌文件來擴展版本恢復。必須先恢復備份以用作基線；然後在該備份之上應用日誌。該過程會將數據庫或表空間恢復到某個特定時間點。前滾恢復要求啓用歸檔日誌記錄。

3.3  恢復的級別

建立災難恢復計劃對於現代企業至關重要。企業數據庫中的信息對於進行業務活動是極其重要的。保護該數據以及在災難之後確保其“生命”是很重要的活動。當構建 DR 計劃時，有三個關鍵級別問題。

3.3.1 需要防止的故障級別

要防止的故障級別通常是近似性問題。原始數據與其備份之間在物理上有多緊密？備份數據可以在不同的驅動器上、在獨立的機器上、在獨立的樓層上或在不同的建築物裏。不可能預測所有可能的災難。火災、水災或甚至用戶的惡作劇都可能是企業必須面對的問題。解決方案的設計應該包括公司希望防止最壞情況的方案。

3.3.2 可接受的數據丟失量

所有企業都不希望在故障之後丟失任何數據。雖然不丟失數據是可能的，但由於可能需要的複雜性和費用（尤其是如果所防止的故障級別非常高），這通常是不實際的。可接受的數據丟失量取決於數據對公司有多重要以及有什麼資源可用於確保其生命。

3.3.3允許用於恢復的時間量

恢復所需的時間量類似於高可用性的目標。它與高可用性解決方案之間的差異在於所防止的故障類型以及通常認爲合理的時間長度。HA 故障轉移通常以秒和分鐘來衡量，而災難恢復則可能以小時和天來進行衡量。不過並非總是這樣，但這個差異區分了對這些解決方案的相對期望。

3.4 備份和恢復

數據庫備份創建了數據庫的時間點映象，它是災難恢復解決方案的基本組件。DB2 提供了幾種備份，包括脫機備份、聯機備份和增量備份。從備份恢復所需的時間取決於數據庫的大小和可用於執行恢復的硬件資源。

由於數據庫備份只捕獲時間點的數據，因此無法通過一個簡單恢復來恢復備份之後發生的任何數據更改。要恢復備份之後完成的事務，就需要應用日誌文件。可以從備份和日誌文件（通過在日誌文件中進行“前滾”來應用）來恢復數據庫。這允許恢復到某個時間點或恢復到日誌文件結束。

因此，如果 DR 解決方案必須恢復自上次備份以來的事務，那麼保留日誌文件是非常關鍵的。有兩個提高日誌保留的 DB2 特性：雙日誌記錄和用戶出口工具，已在關於數據庫複製 HA 選項的部分中進行了討論。

4災難恢復方案

災難恢復方案可以分成三類：簡單備份、備份和日誌保留、高級存儲備份 。

雖然不是每個解決方案都清晰地被劃入這三類中的某一類，但它們確實爲您理解災難恢復選項提供了合理的框架。

4.1 簡單備份

只創建數據庫備份確實創建了一個 DR 解決方案。它也許是非常有限的，這取決於您的環境。通過從“活動”的系統上移走所創建的備份，可以提高保護的級別。增加數據庫備份的頻率也降低了數據丟失的風險。

備份軟件對於創建和維護 DB2 備份可能非常有幫助。例如，IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允許在其軟件控制的設備上直接備份和維護 DB2 數據庫的解決方案。這些設備可以是磁帶庫或另一種存儲設備。

簡單備份適合於只讀數據庫或由能輕鬆重新創建的批處理作業填充的數據庫，或者在備份之間不必維護數據庫更改的情況下。

表 6. 簡單備份的優缺點

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

4.2 備份和日誌保留

保留數據庫日誌文件與數據庫備份一起創建了更完善的 DR 解決方案。日誌文件允許恢復備份之間發生的數據更改。

該解決方案的真正複雜性在於保護日誌文件以確保它們在恢復期間的可用性。如果選擇實現雙日誌記錄，DB2 可以將日誌文件放在不同的位置，如果確保這些位置在不同的存儲器陣列上，那麼保護級別就會得到提高。

但是，日誌文件仍面臨存儲子系統故障。如在高可用性的日誌傳送選項中所提到的，用戶出口程序可以提供重定位日誌文件的替代方法。用戶出口可以將已關閉的日誌文件移到當前系統可用存儲陣列之外的位置，從而提高保護級別。這裏的告誡是它只移動已關閉的日誌文件。即使已實現了雙日誌記錄，包含活動事務的日誌文件仍面臨因陣列丟失或存儲設備故障而產生的丟失。

該解決方案適合於大多數面向商業事務的環境。它均衡了最小化數據丟失風險的需要和維護 DR 解決方案所需的成本。

表 7. 備份加日誌保留的優缺點

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

4.3 高級存儲備份

我們在高可用性下的 高級存儲選項部分中討論過這個主題，相同的原則在這裏也適用。正如在那部分中所見的，STANDBY 方法允許當數據庫副本處於暫掛狀態時在輔助系統上執行數據庫備份。

創建數據庫副本已經創建了 DR 解決方案的一部分。備份副本提高了保護級別。如果用雙日誌記錄和用戶出口程序正確實現了這個高級存儲備份，那麼它就爲核心企業數據庫生成了最好的 DR 解決方案。

該解決方案最適合處於企業活動核心的數據庫系統。示例可能包含了供應鏈管理和在線代理系統。

表 8. 用於災難恢復的高級存儲備份優缺點

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

 

 

附錄:名詞解釋

• 高可用性（high availability，HA）：是這樣一種需求：每當需要時，數據就可用於從屬應用程序。其目的是消除或最小化停機時間。

• 災難恢復（disaster recovery，DR）：防止由於毀滅性的故障而導致數據丟失。這類故障意味着由於不可恢復的情況而丟失數據。

• 羣集（cluster）：有兩種類型的 DB2 數據庫羣集： 高可用性和 高可伸縮性（high scalability）。雖然在一個解決方案中可以結合這兩種羣集，但應該將它們看作是互斥的實體。高可伸縮性羣集（也稱作數據庫分區）結合了多臺服務器的聚集能力以產生高性能解決方案。該技術通常用於構建數據倉庫或大型事務系統，而在這樣的數據倉庫或系統中，單個服務器是無法實現性能目標的。高可用性羣集產生一個能最大化數據庫正常運行時間的系統。在本文中，術語“羣集”僅指高可用性羣集。

備註

本文章中大部分內容來至IBM官方網站以及其他網上文章，但是其來源已經不祥，爲此對原作者表示歉意。本人只是將其組合，加上一些自己的觀點。