Oracle數據庫異地容災方案介紹

太極計算機股份有限公司

TAIJICOMPLTIiRCORPORATIONLIMITED

2008年11月

目錄

第一章需求分析錯誤!未定義書簽。

1.1序言錯誤!未定義書簽。

1.2用戶現(xiàn)狀錯誤!未定義書簽。

1.2.1系統(tǒng)平臺錯誤!未定義書簽。

1.2.2數據庫平臺錯誤!未定義書簽。

1.3用戶需求錯誤!未定義書簽。

1.3.1日常功能錯誤!未定義書簽。

1.3.2故障切換錯誤!未定義書簽。

1.3.3基本要求錯誤!未定義書簽。

1.3.4性能要求錯誤!未定義書簽。

1.3.5數據一致性錯誤!未定義書簽。

1.3.6系統(tǒng)兼容性錯誤!未定義書簽。

1.3.7高可用性錯誤!未定義書簽。

1.3.8健壯性要求錯誤!未定義書簽。

1.3.9設備無關性錯誤!未定義書簽。

1.3.10管理監(jiān)控功能錯誤!未定義書簽。

第二章OracleDataGuard介紹錯誤!未定義書簽。

2.1DataGuard實現(xiàn)原理錯誤!未定義書簽。

2.2OracleDataGuard優(yōu)勢錯誤!未定義書簽。

2.3DataGuard提供的保護模式錯誤!未定義書簽。

2.4DataGuard實現(xiàn)方式以及對系統(tǒng)的限制要求錯誤!未定義書簽。

2.5切換方式錯誤!未定義書簽。

第三章系統(tǒng)建議方案錯誤!未定義書簽。

3.1DataGuard優(yōu)勢錯誤!未定義書簽。

3.2DataGuard運行模式錯誤!未定義書簽。

3.3DataGuard保護模式錯誤!未定義書簽。

3.4DataGuard初始安裝步驟錯誤!未定義書簽。

3.5用戶需求點對點應答錯誤!未定義書簽。

3.5.1日常功能錯誤!未定義書簽。

3.5.2故障切換錯誤!未定義書簽。

3.5.3基本要求錯誤!未定義書簽。

3.5.4性能要求錯誤!未定義書簽。

3.5.5數據一致性錯誤!未定義書簽。

3.5.6系統(tǒng)兼容性錯誤!未定義書簽。

3.5.7高可用性錯誤!未定義書簽。

3.5.8健壯性要求錯誤!未定義書簽。

3.5.9設備無關性錯誤!未定義書簽。

3.5.10管理監(jiān)控功能錯誤!未定義書簽。

第一章需求分析

1.1序言

在信息時代，數據是企業(yè)創(chuàng)造商業(yè)價值的生產資料，數據的丟失將為企業(yè)帶來

毀滅性的災難。據GartnerGroup的調查數據表明，在經歷過大型災難或長時間系統(tǒng)

停運的公司中，有2/5的公司再也未恢復運行，而在其余的公司中，有1/3的公司

在兩年內破產。

有句古諺叫“別把雞蛋放在一個籃子里”。現(xiàn)在的信息系統(tǒng)，各種數據高度集中，

“雞蛋”全放在一個籃里了。一旦出現(xiàn)突然停電、意外死機或者人為破壞，造成數據

丟失是不可避免的。面對各種未可預知的災難，越來越多的企業(yè)將容災備份系統(tǒng)作為

企業(yè)安全的保障。

銀聯(lián)數據異地災備項目的目標是保證SF25K上各銀行（民生銀行貸記卡系統(tǒng)

擬遷移至IBM主機，故此次災備項目暫不考慮；郵儲銀行貸記卡系統(tǒng)主機為IBM

P570,也不在考慮范圍之內）發(fā)卡系統(tǒng)的安全，在災難情況下，最大限度地保護公

司資產，減少公司各方面的損失，保證發(fā)卡系統(tǒng)的業(yè)務連續(xù)性。

本方案僅對異地容災數據庫復制軟件部分做相應闡述。

1.2用戶現(xiàn)狀

1.2.1系統(tǒng)平臺

發(fā)卡系統(tǒng)運行在一臺SunFireE25K企業(yè)級服務器上，通過兩臺BrocadeSW4900

SAN交換機與兩臺企業(yè)級存儲ST9990、SE9970相連，應用系統(tǒng)核心文件和數據庫

數據文件均存放在該存儲上，存儲系統(tǒng)磁盤采用RAID1+0方式。

SF25K劃分為四個物理分區(qū)（Domain）,每家銀行均使用其中的兩個，一個

Domain作為生產主機，另一個Domain作為熱備主機。Domain操作系統(tǒng)為Solaris

10,數據庫系統(tǒng)為Oracle10.2.0.2RAC。通過SunCluster集群軟件，實現(xiàn)了生產機房

內的雙機熱備份，保證了系統(tǒng)的高可用性。止匕外，在主機端還通過SunMPXIO多

通道負載均衡軟件，實現(xiàn)兩條光纖通道的負載均衡，進一步避免了單點故障。

以下是發(fā)卡系統(tǒng)SAN架構圖：

通過在主機端使用VxVM4.1卷管理軟件，已建立了同機房數據災備系統(tǒng)，兩

臺存儲SE9970與ST9990之間實現(xiàn)了同步數據復制，達到了以下災難恢復目標：

日常工作，保證兩臺存儲的數據實時同步保持一致，所有數據不丟失。

計劃外停機，任一臺存儲發(fā)生災難，保證數據不丟失，即RPO=(),并確保

應用不中斷運行，即RTO=O。

發(fā)卡系統(tǒng)中的數據庫系統(tǒng)，是整個生產系統(tǒng)中最關鍵、最復雜的數據對象，發(fā)

卡系統(tǒng)的業(yè)務運轉直接依賴于這些數據的可用性。

為了確保數據庫的高可用性，發(fā)卡系統(tǒng)數據庫使用了Oracle10gRAC版本

10.2.0.2,主、備機兩節(jié)點的數據庫實例同時運行，一旦主節(jié)點出現(xiàn)問題，數據庫實

例無需啟停，可迅速將應用系統(tǒng)切換至備節(jié)點。

截至到2008年8月底，各數據庫實例數據量情況見下表:

實例Archivelog數據量(GB)

總數據量(GB)高峰期Archivelog變化量(MB/s)

名平均每天最大帳單日

HX25140.42

SZ15120.20

CR934.550.40

DE381.550.58

UC27512162.95

合計44620324.55

1.3用戶需求

銀聯(lián)數據擬為提供外包服務的各銀行發(fā)卡系統(tǒng)建設異地災備系統(tǒng)，生產系統(tǒng)位

于上海，災備系統(tǒng)位于北京。主備中心之間采用數據庫復制軟件進行異步數據復制,

以保證生產數據的安全性，滿足發(fā)卡系統(tǒng)的業(yè)務連續(xù)性需求。

1.3.1日常功能

?將生產中心發(fā)卡系統(tǒng)上的數據庫變化實時異步復制到災備中心；

災備中心的Oracle數據庫處于打開狀態(tài)，可提供實時數據查詢；

?對生產系統(tǒng)的資源占用不能太多，不能影響到生產系統(tǒng)的正常運行；

?對網絡帶寬的占用較低。

1.3.2故障切換

當生產中心的系統(tǒng)無法正常運行，而又不能在短期內恢復時，可利用災備中

心提供業(yè)務接管。

?災備中心必須在生產中心不可用6小時之內完成業(yè)務接管。

當生產中心服務器恢復正常后，數據復制系統(tǒng)需要將災備中心的最新數據

反向復制回生產中心，實現(xiàn)業(yè)務的恢復。

1.3.3基本要求

復制軟件應滿足在單機或RAC環(huán)境下，對Oracle在線日志(Onlineredolog)

的捕捉及復制；

支持Oracle中所有的常用數據類型，如Oracle中的LONG>LONGRAW、

BLOB、CLOB、NCLOB、TIMESTAMP等，可實現(xiàn)用戶自定義表、字段

進行復制；

?支持對數據庫中常用DDL操作的復制；

?支持事務復制，要求對數據庫中較大的事務不會出現(xiàn)過多延遲；

?支持沒有PK/UK字段的表的同步。

數據復制過程可根據需要靈活地進行控制或修改復制的方向，以滿足業(yè)務需

需求；

支持在數據復制過程中對數據正確性進行校驗，如正在復制的數據在之前

就已經不一致，應提供報警功能，以便及時發(fā)現(xiàn)錯誤，避免錯誤的擴大；

?提供專用圖形化集中管理軟件。

1.3.4性能要求

?數據庫初始化同步

要求數據庫復制軟件能夠將發(fā)卡系統(tǒng)的數據庫中已有數據初始化同步到災備中

心數據庫。在初始化同步過程中，業(yè)務不能停止，但可選擇業(yè)務量較小時段進行。

在解決方案書中要求詳細描述初始化數據同步解決方案，以及整個首次同步操作所需

需要的時間（以100GB數據為標準），并且要求列出整個首次初始化過程中是否需

要人為干預，從而可以有效地評估整個首次數據初始化的工作量。

為了保證生產中心日后業(yè)務擴展存在更換服務器廠商以及數據庫版本等情況，

需要注明是否支持異構平臺下的首次數據初始化同步，是否支持跨數據庫版本之間

數據庫的初始化同步操作。

?數據復制性能指標

數據復制的性能指標與系統(tǒng)平臺、網絡帶寬、應用系統(tǒng)等因素密切相關，參照

下列運行環(huán)境：

項目配置

數據源SF15K24個CPU,32GB內存，ORACLE10.2.0.2RAC

目標端SF15K24個CPU,32GB內存，ORACLE10.2.0.2

總數據量500GB左右（數據+索引）

每天的日志量每天20GB日志

網絡帶寬100M和20M

要求提供相應的性能參數指標:

類別指標參考值

苜次數據庫初始化同步時間（100M帶寬）小于10小時

首次數據初始化同步首次數據庫初始化同步時間（20M帶寬）小于48小時

首次數據庫初始化同步源端CPU占用小于30%

源端CPU占用小于5%

目標端CPU占用小于5%

增量數據同步

源端內存占用小于200M

（單個復制鏈路）

目標端內存占用小于200M

復制數據延遲平均值10s以內

源端CPU占用小于10%

業(yè)務高峰期對系統(tǒng)的影響目標端CPU占用小于10%

復制數據延遲平均值10s以內

1.3.5數據一致性

要求數據庫復制軟件提供數據庫初始化同步、數據恢復后以及日常的數據一致

性檢查方案，要求方案中詳細注明該數據一致性比對方案的特點以及操作復雜度，

并可滿足如下要求：

?可在應用不停機的情況下，查找和發(fā)現(xiàn)不一致的數據；

一致性檢查需要能夠進行對象屬性、記錄條數和記錄的字段內容進行一致

性檢查；

?提供全庫的記錄級一致性檢查時間（以100GB的數據為例）。

支持不含PK/UK字段的表的一致性檢查和修復。請?zhí)峁┰跊]有PK/UK字

段的表中有1000萬條記錄的比對時間。

對于不一致的數據，需要提供不一致記錄詳細信息，以便進行精確的修復，同

時提供數據修復方案。數據修復工作要求操作簡單，修復速度快，且修復過程中不

影響業(yè)務正常運行。

136系統(tǒng)兼容性

數據庫復制軟件應支持以下操作系統(tǒng)平臺：

?SunSolaris9,10

?IBMAIX5.x

數據庫復制軟件應支持Oracle9i,Oracle10g,Oracle11g及后續(xù)數據庫版本；

支持異構平臺，源端和目標端不同數據庫版本；支持Cluster/HACMP和RAC模式,

并支持不同操作系統(tǒng)下不同數據庫版本之間的復制。

1.3.7高可用性

主系統(tǒng)和備用系統(tǒng)的數據庫處于雙活狀態(tài)，以保證在災難發(fā)生前可在兩個系統(tǒng)

上運行不同類型的應用程序。

數據庫復制軟件應支持本地Cluster/HACMP的高可用方式，在本地單節(jié)點出現(xiàn)

故障時，可通過Cluster軟件接管到其它節(jié)點。

1.3.8健壯性要求

數據庫復制軟件在各種大壓力和各種故障情況下不會造成數據復制失敗。

網絡故障：長時間中斷、短時間中斷及網絡時斷時續(xù)情況下的正常復制；

數據庫故障：在目標端數據庫故障下，源端數據庫不能受到影響。當目標

端數據庫修復后，復制軟件繼續(xù)工作；

服務器硬件故障：在目標端服務器故障下，源端生產系統(tǒng)不能受到影響，當

目標端修復后，復制軟件繼續(xù)工作。

1.3.9設備無關性

獨立于任何硬件設備、操作系統(tǒng)和Oracle數據庫的不同版本，能夠實現(xiàn)不同平

臺之間數據庫的復制。

1.3.10管理監(jiān)控功能

數據庫復制軟件需提供統(tǒng)一的管理監(jiān)控功能，能實現(xiàn)對復制軟件的運行狀態(tài)、

運行日志、系統(tǒng)配置等方面進行統(tǒng)一的管理及監(jiān)控，保證出現(xiàn)錯誤時具有完整方便

的報警及跟蹤機制，方便故障的快速定位和解決。

第二章OracleDataGuard介紹

容災系統(tǒng)主要包括數據保護和應用切換兩大方面，其中最為重要的是數據保護部

部分。除了要將這些數據存放在高可用的存儲設備上之外，最重要的是這些關鍵數據

應該在異地之間保持一致，以使災難發(fā)生后，系統(tǒng)可以盡快恢復。下面是幾種主要

的數據保護技術。

實現(xiàn)數據的異地復制，有軟件方式和硬件方式兩種途徑。軟件方式，是通過主

機端軟件來實現(xiàn)，如第三方軟件或者數據庫廠家提供的遠程數據容災工具來實現(xiàn)業(yè)

務數據的遠程復制。

硬件方式，是基于智能存儲系統(tǒng)的控制器的遠程拷貝，可以在主、備存儲系統(tǒng)

之間通過硬件實現(xiàn)復制。

在實際的容災系統(tǒng)中，由于系統(tǒng)的環(huán)境不同，安全性要求不同以及采用的軟硬

件產品不同，數據復制過程中的工作機制也不盡相同。概括地講，數據復制地工作

機制主要包括同步和異步兩種。同步遠程鏡像（同步復制技術）是指通過遠程鏡像軟件

件，將本地數據以完全同步的方式復制到異地，每一本地的I/O事務均需等待遠程

復制的完成確認信息，方予以釋放。異步遠程鏡像（異步復制技術）保證在更新遠程

存儲視圖前完成向本地存儲系統(tǒng)的基本UO操作，而由本地存儲系統(tǒng)提供給請求鏡

像主機的I/O操作完成確認信息，遠程的數據復制以后臺同步的方式進行。因為帶

寬等因素限制，本次容災方案僅包括了異步復制的方式的討論。

2.1DataGuard實現(xiàn)原理

OracleDataGuard是當今保護企業(yè)核心資產（數據）的最有效解決方案，它

能夠使數據在24x7的基礎上可用，而無論是否發(fā)生災難或其它中斷。

OracleDataGuard是管理、監(jiān)控和自動化軟件的基礎架構，它創(chuàng)建、維護和

監(jiān)控一個或多個備用數據庫，以保護企業(yè)數據結構不受故障、災難、錯誤和崩潰的

影響。

DataGuard使備用數據庫保持為與生產數據庫在事務上一致的副本。這些備

用數據庫可能位于距生產數據中心數千公里的遠程災難恢復站點，或者可能位于同

一城市、同一校園乃至同一建筑物內。當生產數據庫由于計劃中斷或意外中斷而變得

不可用時，DataGuard可以將任意備用數據庫切換到生產角色，從而使與中斷相關

的停機時間減到最少，并防止任何數據丟失。

作為Oracle數據庫企業(yè)版的一個特性推出的DataGuard能夠與其它的

Oracle高可用性（HA）解決方案（如真正應用集群（RAC）和恢復管理器（RMAN））

結合使用，以提供業(yè)內前所未有的高水平數據保護和數據可用性。下圖提供了

OracleDataGuard的一個概述。

客戶端客戶端

OracleDataGuard包括一個生產數據庫，也稱為主數據庫，以及一個或多個

備用數據庫，這些備用數據庫是與主數據庫在事務上一致的副本。DataGuard利用

重做數據保持這種事務一致性。當主數據庫中發(fā)生事務時，則生成重做數據并將其寫

入本地重做日志文件中。通過DataGuard,還將重做數據傳輸到備用站點上，并應

用到備用數據庫中，從而使備用數據庫與主數據庫保持同步。DataGuard允許管理

員選擇將重做數據同步還是異步地發(fā)送到備用站點上。

備用數據庫的底層技術是DataGuard重做應用（物理備用數據庫）和Data

GuardSQL應用（邏輯備用數據庫）。物理備用數據庫在磁盤上擁有和主數據庫逐塊

相同的數據庫結構，并且使用Oracle介質恢復進行更新。邏輯備用數據庫是一個

獨立數據庫，它與主數據庫包含相同的數據。它使用SQL語句進行更新，其相對優(yōu)

勢是能夠并行用于恢復以及諸如報表、查詢等其他任務。

DataGuard簡化了主數據庫和選定的備用數據庫之間的轉換和故障切換，從

而減少了由計劃停機和計劃外故障所導致的總停機時間。

主數據庫和備用數據庫以及它們的各種交互可以使用SQL*Plus來進行管理。

為了獲得更簡便的可管理性，DataGuard還提供了一個分布式管理框架（稱為Data

GuardBroker）,它不但自動化/DataGuard配置的創(chuàng)建、維護和監(jiān)控，并對這些

操作進行統(tǒng)一管理。管理員可以使用OracleEnterpriseManager或Broker自己

的專用命令行界面(DGMGRL)來利用Broker的管理功能。

下圖顯示了OracleDataGuard組件。

物理備用

數據庫

2.2OracleDataGuard優(yōu)勢

災難恢復和高可用性一DataGuard提供了一個高效和全面的災難恢復和

高可用性解決方案。易于管理的轉換和故障切換功能允許主數據庫和備用數據庫

之間的角色轉換，從而使主數據庫因計劃的和計劃外的中斷所導致的停機時間減

到最少。

完善的數據保護一使用備用數據庫，DataGuard可保證即使遇到不可預見

的災難也不會丟失數據。備用數據庫提供了防止數據損壞和用戶錯誤的安全保護

護。主數據庫上的存儲器級物理損壞不會傳播到備用數據庫上。同樣，導致主數

據庫永久損壞的邏輯損壞或用戶錯誤也能夠得到解決。最后，在將重做數據應用

到備用數據庫時會對其進行驗證。

有效利用系統(tǒng)資源一備用數據庫表使用從主數據庫接收到的重做數據進行

更新，并且可用于諸如備份操作、報表、合計和查詢等其它任務，從而減少執(zhí)行

這些任務所必需的主數據庫工作負載，節(jié)省寶貴的CPU和I/O周期。使用邏輯

備用數據庫，用戶可以在模式中不從主數據庫進行更新的表上執(zhí)行數據處理操

作。邏輯備用數據庫可以在從主數據庫中對表進行更新時保持打開，并可同時對

表進行只讀訪問。最后，可以在維護的表上創(chuàng)建額外索引和物化視圖，以獲得更

好的查詢性能和適應特定的業(yè)務要求。

靈活的數據保護功能，從而在可用性與性能要求之間取得平衡一Oracle

DataGuard提供了最大保護、最高可用性和最高性能等模式，來幫助企業(yè)在系

統(tǒng)性能要求和數據保護之間取得平衡。

自動間隔檢測及其解決方案一如果主數據庫與一個或更多個備用數據庫之間

間的連接丟失（例如，由于網絡問題），則在主數據庫上生成的重做數據將無法發(fā)

送到那些備用數據庫上。一旦重新建立連接，DataGuard就自動檢測丟失的存

檔日志序列（或間隔），并將必要的存檔日志自動傳輸到備用數據庫中。備用數

據庫將重新與主數據庫同步，而無需管理員的任何手動干預。

簡單的集中式管理一DataGuardBroker使一個DataGuard配置中的多

個數據庫間的管理和操作任務自動化。Broker還監(jiān)控單個DataGuard配置內

的所有系統(tǒng)。管理員可以使用OracleEnterpriseManager或Broker自己專

用的命令行界面(DGMGRL)來利用這個集成的管理框架。

與Oracle數據庫集成一OracleDataGuard是作為Oracle數據庫(企

業(yè)版)的一個完全集成的功能提供的，無需任何額外費用。

2.3DataGuard提供的保護模式

Oracle針對用戶的不同需求提供三種保護模式：最大保護模式、最大性能

模式、最大可用模式。

Oracle提供的DataGuard在最大保護模式下可以確保數據完全不丟失。它

在寫本地日志的同時寫遠程standby的數據庫日志。只有兩個日志均寫成功后一

個操作才是正式完成。這種方式確保了數據的最大安全，能夠確保主數據庫損壞

的情況下沒有任何數據丟失。但這種情況對主數據庫性能有較大的影響，即使在

高速的局域網內，最大保護模式也會對主數據庫性能有超過10%的性能影響。這

種方式對主備兩個數據庫之間的鏈路有非常高的要求。在這種保護模式下無論是

網路鏈路還是standby數據庫等發(fā)生故障導致日志無法正常寫均會導致主數據庫

庫無法使用。因此只有在對數據安全要求最高的情況下才會考慮使用這種方式。

Oracle也提供最大性能模式。這種模式下，不傳輸實時修改的日志文件，

傳遞的是歸檔日志文件，因此對主數據庫性能影響很小。歸檔日志文件傳遞是否

能夠成功對主數據庫運行沒有任何影響，因此在網絡出現(xiàn)中斷或者standby數據

庫出現(xiàn)異常也不會影響主數據庫的正常運行。但因為日志沒有同步寫，因此在災

難發(fā)生的時候備份數據庫與主數據庫可能有一定的數據差異。

Oracle提供的第三種模式是上述兩種方式的折中。在網絡正常的情況下它

的運行方式類似于最大保護模式，日志實時傳遞。當網絡或standby出現(xiàn)故障的

時候它的運行模式類似于最大性能模式，日志延遲傳遞，不會導致主數據庫停止

運行。這種方式在正常情況下因為日志實時傳遞，因此同樣對主數據庫性能有較

大影響，而且對網絡鏈路要求較高。

綜上所述，不同的保護模式比較如下:

最大保護最大可用最大性能

對主數據庫性能影響較高較高低

對網絡鏈路要求極|;匕高低

備份系統(tǒng)發(fā)生故障主數據庫不可用無影響無影響

數據保護無數據丟失基本無數據丟失少量數據丟失

2.4DataGuard實現(xiàn)方式以及對系統(tǒng)的限制要求

Oracle針對不同的用戶情況提供的兩種不同的standby方式。物理standby,

邏輯standby。

物理standby數據庫，在通常的模式下備份庫始終處于恢復狀態(tài)，用戶無

法訪問備份庫的數據。如果需要訪問數據，需要將恢復模式停止，將數據庫打開

到只讀狀態(tài)。這兩種狀態(tài)是排它的，也就是說數據庫要么是恢復狀態(tài)，保持和主

數據庫一致，在這種狀態(tài)下數據庫內容不可訪問；要么是只讀狀態(tài)，數據庫不會

做恢復與主數據保持一致。

Oracle還提供邏輯standby數據庫。這種方式下數據庫可以在打開的狀態(tài)

下保持與主數據庫的同步工作。這種打開狀態(tài)和普通的數據庫open狀態(tài)不同，

不能對數據做修改。這種方式通常用于繁忙的系統(tǒng)，如主數據庫日常完成業(yè)務處

理，邏輯standby數據庫在完成容災的同時分擔主數據庫的查詢統(tǒng)計工作。這樣

大大節(jié)約了系統(tǒng)資源。但這種方式對數據庫有一定的限制，并不是所有的系統(tǒng)都

能夠支持。部分較為特殊的數據類型不支持，另外所有的表必須要有主鍵或者唯

--性索引。

無論是物理standby還是邏輯standby均對系統(tǒng)要求如下：

主備數據庫必須是完全相同的硬件架構，如均為SUN平臺。機器的內存

大小、CPU數量主頻可以不同。

?操作系統(tǒng)版本、補丁完全相同。

數據庫版本完全相同。但RAC選件可以不同。即主數據庫可以是RAC

模式，備份節(jié)點可以是單機。

2.5切換方式

OracleDataGuard可以實現(xiàn)failover以及switchover的切換。

Switchover指有計劃的切換。如系統(tǒng)主數據庫服務器需要硬件維護等有計

劃的停機操作。這時候可以手工將所有的日志以及歸檔日志文件傳輸到備份節(jié)點

后執(zhí)行switchover的切換。這種情況下等主數據庫恢復正常后系統(tǒng)可以手工切換

換回來。

Failover切換是指系統(tǒng)出現(xiàn)了異常情況下的切換。系統(tǒng)管理員發(fā)現(xiàn)主數據庫

庫服務器無法提供服務，決定啟動容災系統(tǒng)。在這種情況下的切換后如果主數據

庫服務器恢復正常后需要重新配置整個DataGuard環(huán)境，無法切換回主數據庫

服務器。

無論是那種切換方式，主備系統(tǒng)之間均存在部分差別。如IP地址不同，需

要修改服務器IP地址或應用程序重新指向。因為在不同的局域網內，應用中間

件需要跨防火墻訪問系統(tǒng)。機器檔次不同、網絡帶寬不同造成的性能下降等問題。

這需要在容災的預案中考慮。

第三章系統(tǒng)建議方案

針對本容災方案，我們推薦采用OracleDataGuard技術。

3.1DataGuard優(yōu)勢

?節(jié)約投資

OracleDataGuard是Oracle原廠自帶的容災產品。該產品完全免費。在

容災軟件上用戶無需支付額外費用，這可以大大節(jié)約用戶的資金投入。

?技術成熟、穩(wěn)定

早在Oracle7版本就已經推出該功能（當時名稱為Standby數據庫）。其

核心采用了Oracle成熟的歸檔、備份、恢復技術。經過多年不斷的發(fā)展，

已經成為一項技術成熟、穩(wěn)定，有廣泛成功案例的技術。

?對系統(tǒng)運行性能影響小

DataGuard在主數據庫服務器端不存在對日志解析等工作，僅需要主數據

庫服務器端將歸檔日志文件傳輸到容災節(jié)點。因此對生產系統(tǒng)性能影響極

小。

?能夠滿足用戶基本業(yè)務需求

DataGuard能夠滿足用戶基本的數據容災、RTO、RPO、帶寬等相關基本業(yè)

務需求。

3.2DataGuard運行模式

Oracle提供了物理DataGuard以及邏輯DataGuard兩種不同的方式。這

兩種方式各有優(yōu)缺點。因為用戶數據庫中存在大量表，這些表沒有PK/UK；因此

無法滿足邏輯DataGuard的使用前提條件。在本方案中,我們推薦采用物理Data

Guard的方式。

3.3DataGuard保護模式

根據用戶的實際情況，在主數據庫服務器和容災數據庫服務器之間距離較

遠，使用最大保護模式和最大可用模式均會嚴重影響主數據庫的運行性能。用戶

允許在出現(xiàn)異常情況下15分鐘內的數據丟失量，因此采用最大性能模式可以在

現(xiàn)有帶寬的情況下滿足用戶的容災需求。

采用最大性能模式，系統(tǒng)不會實時傳輸日志文件，傳遞的是歸檔日志文件,

因此對主數據庫性能影響很小。歸檔日志文件傳遞是否能夠成功對主數據庫運行

沒有任何影響，因此在網絡出現(xiàn)中斷或者standby數據庫出現(xiàn)異常也不會影響主

數據庫的正常運行。但因為日志沒有同步寫，因此在災難發(fā)生的時候備份數據庫

與主數據庫可能有一定的數據差異。

3.4DataGuard初始安裝步驟

1、確認主數據庫運行于歸檔模式

如果主數據庫沒有處于歸檔模式，那么需要將數據庫運行模式修改為歸檔

模式。該修改過程需要短暫停止數據庫運行。

2、物理備份主數據庫的所有數據文件

該部分工作可以在不影響業(yè)務正常運行的情況下執(zhí)行。該部分工作依據數

據量以及UO速度不同，所需要的時間也不同。一般估算，100G的數據應在1

小時內備份完成。該備份操作啟動后無需人為干預。

3、在主數據庫創(chuàng)建standby控制文件

通過命令創(chuàng)建災備中心的控制文件。

4、拷貝備份的數據文件、standby控制文件及日志文件到備份節(jié)點。

因為數據量較大，可以將備份的文件壓縮后傳遞。100G的備份文件經壓縮,

通常壓縮率在40%-50%之間。100G文件壓縮后約50G。在網速為20M帶寬的

情況下，假設網絡利用率為70%,那么速度約為6G/每小時；50G的文件需要9

個小時傳遞完成。在網速為100M帶寬的情況下，假設網絡利用率為70%,那么

速度約為30G/每小時；50G的文件需要1.5個小時傳遞完成。在數據傳輸啟動后

無需人為干預。

5、配置主、備中心的數據庫服務器DataGuard環(huán)境

該操作對主數據庫運行沒有任何影響。

其中災備中心數據庫平臺要求與主中心架構一致，如均為SUN小型機。操

作系統(tǒng)版本及數據庫版本均需要一致。

DataGuard不支持異構平臺數據容災，也不支持不同數據庫版本之間做數據

容災。

6、使用主中心備份的文件創(chuàng)建災備中心數據庫系統(tǒng)。

該操作主要是解壓文件、恢復數據文件的時間。約為2小時。

7、配置災備中心環(huán)境。根據主中心的歸檔日志保持災備中心與主中心一

致。

3.5用戶需求點對點應答

3.5.1日常功能

?將生產中心發(fā)卡系統(tǒng)上的數據庫變化實時異步復制到災備中心;

應答：滿足。DataGuard通過歸檔日志將數據庫變化復制到災備中心。

災備中心的Oracle數據庫處于打開狀態(tài),可提供實時數據查詢;

應答：部分滿足。物理DataGuard在正常恢復的時候無法處于打開狀態(tài)，在打

開的狀態(tài)下無法處于恢復與主數據庫保持一致的狀態(tài)。本系統(tǒng)的RPO<15分鐘，

RTO<6小時，每天歸檔日志產生量<20G。可以考慮以下方式解決該問題：

如果用戶對容災數據庫使用時間為白天，那么在白天，將數據庫啟動為只

讀打開模式，供業(yè)務查詢。夜間，將數據庫啟動為恢復模式，保持與主生產中心

一致。如果用戶對容災數據庫使用時間為夜間，那么反之在夜間將數據庫打開只

讀，白天數據庫做恢復。

容災中心數據庫只在指定時間內對數據庫做恢復，因此該數據庫與主數據庫

庫之間存在1天的數據差異。雖然沒有實時做數據恢復，歸檔日志文件在產生后

會同步寫入容災中心，因此系統(tǒng)可以滿足RP0<15分鐘的要求。當出現(xiàn)需要啟動

備用中心的情況，備用中心需要先通過歸檔日志文件恢復數據。目前每天歸檔日

志量<20G,系統(tǒng)使用這些歸檔日志恢復數據的時間<2小時，能夠滿足RT0<6

小時的業(yè)務需求。

如果用戶對容災中心數據庫使用為全天24小時，目前版本DataGuard無法

滿足要求，在OraclellG以后的版本提供該功能。

?對生產系統(tǒng)的資源占用不能太多,不能影響到生產系統(tǒng)的正常運行;

應答：滿足。采用物理DataGuard的最大性能模式，生產中心主機僅需要在歸

檔日志產生后將歸檔日志文件寫入異地容災中心，對生產系統(tǒng)資源占用極少，不

影響生產系統(tǒng)的正常運行。在網絡出現(xiàn)故障或容災中心出現(xiàn)故障時，不會影響到

生產系統(tǒng)的正常運行。

?對網絡帶寬的占用較低。

應答：滿足。DataGuard傳輸內容數據變化產生的歸檔日志文件。目前每天歸檔

日志產生量為20G,那么傳輸量為20G/天。

3.5.2故障切換

當生產中心的系統(tǒng)無法正常運行,而又不能在短期內恢復時,可利用災

備中心提供業(yè)務接管。

應答：滿足。災備中心可以提供數據庫服務器。

?災備中心必須在生產中心不可用6小時之內完成業(yè)務接管。

應答：滿足。災備中心可以在6小時內完成業(yè)務接管。

當生產中心服務器恢復正常后,數據復制系統(tǒng)需要將災備中心的最新數

據反向復制回生產中心,實現(xiàn)業(yè)務的恢復。

應答：部分滿足。系統(tǒng)切換可以分為有計劃的停機以及故障停機。

在有計劃停機的情況下，災備中心數據庫在啟用的時候，數據庫內容保持

與生產中心完全一致。在主中心操作完成后，可以通過簡單命令，將災備中心啟

用期間數據修改反向復制回生產中心，實現(xiàn)業(yè)務的恢復。

在故障停機的情況下，主中心可能有部分數據(<15分鐘)尚未傳遞到備份中

心，在災備中心啟用的時候，主、備之間數據已不一致。因此需要將所有數據重

新傳遞回主中心才能實現(xiàn)業(yè)務的恢復。

3.5.3基本要求

復制軟件應滿足在單機或BAC環(huán)境下，對Oracle在線日志(Onlineredo

log)的捕提及復制;

應答：滿足。DataGuard通過對Onlineredolog產生的歸檔文件復制來完成容災。

支持Oracle中所有的常用數據類型,如Oracle中的LONG、LONG

RAW.BLOB、CLOB、NCLOB、TIMESTAMP等,可實現(xiàn)用戶自定義表、

字段進行復制;

應答：滿足。物理DataGuard支持Oracle中所有的常用數據類型

?支持對數據庫中常用DDL操作的復制;

應答：滿足。物理DataGuard支持Oracle中常用DDL的操作復制。

?支持事務復制,要求對數據庫中較大的事務不會出現(xiàn)過多延遲;

應答：滿足。物理DataGuard支持事務復制。對較大事務不會出現(xiàn)過多延遲。

?支持沒有PK/UK字段的表的同步。

應答：滿足。物理DataGuard支持沒有PK/UK字段的表的同步。

數據復制過程可根據需要靈活地進行控制或修改復制的方向,以滿足業(yè)

務需求;

應答：滿足。DataGuard可以靈活地控制主、備節(jié)點的swithover切換。

支持在數據復制過程中對數據正確性進行校驗,如正在復制的數據在之

前就已經不一致,應提供報警功能,以便及時發(fā)現(xiàn)錯誤,避免錯誤的擴

大;

應答：滿足。物理DataGuard復制的前提條件是主、備數據庫保持一致，因此

不會出現(xiàn)復制的數據在之前已經不一致的情況。

?提供專用圖形化集中管理軟件。

應答：滿足。DataGuardBroker與OEM可以提供很方便的圖形化集中管理。

3.5.4性能要求

?數據庫初始化同步

要求數據庫復制軟件能夠將發(fā)卡系統(tǒng)的數據庫中已有數據初始化同步到災

備中心數據庫。在初始化同步過程中,業(yè)務不能停止,但可選擇業(yè)務量較

小時段進行。在解決方案書中要求詳細描述初始化數據同步解決方案,以及

整個首次同步操作所需要的時間（以100GB數據為標準）,并且要求列出整

個首次初始化過程中是否需要人為干預,從而可以有效地評估整個首次數

據初始化的工作量。

為了保證生產中心日后業(yè)務擴展存在更換服務器廠商以及數據庫版本等情

況,需要注明是否支持異構平臺下的首次數據初始化同步,是否支持跨數

據庫版本之間數據庫的初始化同步操作。

應答：滿足。詳見DataGuard初始安裝步驟

?數據復制性能指標

數據復制的性能指標與系統(tǒng)平臺、網絡帶寬、應用系統(tǒng)等因素密切相關,參

照下列運行環(huán)境:

項目配置

數據源SF15K24個CPU,32GB內存,ORACLE10.2.0.2RAC

目標端SF15K24個CPU,32GB內存,ORACLE10.2.0.2

總數據量500GB左右（數據+索引）

每天的日志量每天20GB日志

網絡帶寬100M和20M

要求提供相應的性能參數指標:

類別指標參考值應答

首次數據庫初始化同滿足，首次初始化同步時間小于5小H

小于10小時

首次數步時間（100M帶寬）時

據初始4首次數據庫初始化同滿足，首次初始化同步時間小于12小

小于48小時

化同步步時間（20M帶寬）時

首次數據庫初始化同小于30%滿足，對主系統(tǒng)資源消耗極小。小于

步源端CPU占用1%

滿足，對主系統(tǒng)資源消耗極小。小于

源端CPU占用小于5%

1%

目標端CPU占用小于5%滿足，對目標資源消耗極小。小于5%

滿足，對主資源消耗極小。無需額外內

增量源端內存占用小于200M

存消耗

數據同

滿足，對主資源消耗極小。無需額外內

步目標端內存占用小于200M

存消耗

（單個

不滿足。在最大性能模式下，物理

復制鏈亂

DataGuard在日志切換后將改變的數

路）

據寫入災備中心。頻繁的日志切換將

復制數據延遲平均值10s以內

影響數據庫運行性能。建議將日志切

換頻率設置為10分鐘。因此數據復制

最大延遲約為10分鐘。

滿足，對主系統(tǒng)資源消耗極小。小于

源端CPU占用小于10%

1%

目標端CPU占用小于10%滿足，對目標資源消耗極小。小于5%

業(yè)務高

不滿足.在最大性能模式下，物理

峰期對為

DataGuard在日志切換后將改變的數

系統(tǒng)的

據寫入災備中心。頻繁的日志切換將

影響復制數據延遲平均值10s以內

影響數據庫運行性能。建議將日志切

換頻率設置為10分鐘。因此數據復制

最大延遲約為10分鐘。

3.5.5數據一致性

要求數據庫復制軟件提供數據庫初始化同步、數據恢復后以及日常的數據一

致性檢查方案,要求方案中詳細注明該數據一致性比對方案的特點以及操作復雜

度,并可滿足如下要求:

?可在應用不停機的情況下,查找和發(fā)現(xiàn)不一致的數據;

一致性檢查需要能夠進行對象屬性、記錄條數和記錄的字段內容進行一

致性檢查;

?提供全庫的記錄級一致性檢查時間（以100GB的數據為例）。

支持不含PK/UK字段的表的一致性檢查和修復。請?zhí)峁┰跊]有PK/UK

字段的表中有1000萬條記錄的比對時間。

對于不一致的數