Oracle數(shù)據(jù)庫異地容災(zāi)方案概述

Oracle數(shù)據(jù)庫異地容災(zāi)方案介紹

太極計算機股份有限公司

TAIJICOMPLTIiRCORPORATIONLIMITED

2008年11月

目錄

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

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

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

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

1.2.2數(shù)據(jù)庫平臺錯誤!未定義書簽。

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

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

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

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

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

1.3.5數(shù)據(jù)一致性錯誤!未定義書簽。

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

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

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

1.3.9設(shè)備無關(guān)性錯誤!未定義書簽。

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用戶需求點對點應(yīng)答錯誤!未定義書簽。

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

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

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

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

3.5.5數(shù)據(jù)一致性錯誤!未定義書簽。

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

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

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

3.5.9設(shè)備無關(guān)性錯誤!未定義書簽。

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

第一章需求分析

1.1序言

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

毀滅性的災(zāi)難。據(jù)GartnerGroup的調(diào)查數(shù)據(jù)表明，在經(jīng)歷過大型災(zāi)難或長時間系統(tǒng)

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

在兩年內(nèi)破產(chǎn)。

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

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

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

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

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

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

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

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

本方案僅對異地容災(zāi)數(shù)據(jù)庫復(fù)制軟件部分做相應(yīng)闡述。

1.2用戶現(xiàn)狀

1.2.1系統(tǒng)平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

應(yīng)用不中斷運行，即RTO=O。

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

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

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

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

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

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

實例Archivelog數(shù)據(jù)量(GB)

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

名平均每天最大帳單日

HX25140.42

SZ15120.20

CR934.550.40

DE381.550.58

UC27512162.95

合計44620324.55

1.3用戶需求

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

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

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

1.3.1日常功能

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

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

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

?對網(wǎng)絡(luò)帶寬的占用較低。

1.3.2故障切換

當(dāng)生產(chǎn)中心的系統(tǒng)無法正常運行，而又不能在短期內(nèi)恢復(fù)時，可利用災(zāi)備中

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

?災(zāi)備中心必須在生產(chǎn)中心不可用6小時之內(nèi)完成業(yè)務(wù)接管。

當(dāng)生產(chǎn)中心服務(wù)器恢復(fù)正常后，數(shù)據(jù)復(fù)制系統(tǒng)需要將災(zāi)備中心的最新數(shù)據(jù)

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

1.3.3基本要求

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

的捕捉及復(fù)制；

支持Oracle中所有的常用數(shù)據(jù)類型，如Oracle中的LONG>LONGRAW、

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

進行復(fù)制；

?支持對數(shù)據(jù)庫中常用DDL操作的復(fù)制；

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

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

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

需求；

支持在數(shù)據(jù)復(fù)制過程中對數(shù)據(jù)正確性進行校驗，如正在復(fù)制的數(shù)據(jù)在之前

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

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

1.3.4性能要求

?數(shù)據(jù)庫初始化同步

要求數(shù)據(jù)庫復(fù)制軟件能夠?qū)l(fā)卡系統(tǒng)的數(shù)據(jù)庫中已有數(shù)據(jù)初始化同步到災(zāi)備中

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

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

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

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

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

需要注明是否支持異構(gòu)平臺下的首次數(shù)據(jù)初始化同步，是否支持跨數(shù)據(jù)庫版本之間

數(shù)據(jù)庫的初始化同步操作。

?數(shù)據(jù)復(fù)制性能指標

數(shù)據(jù)復(fù)制的性能指標與系統(tǒng)平臺、網(wǎng)絡(luò)帶寬、應(yīng)用系統(tǒng)等因素密切相關(guān)，參照

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

項目配置

數(shù)據(jù)源SF15K24個CPU,32GB內(nèi)存，ORACLE10.2.0.2RAC

目標端SF15K24個CPU,32GB內(nèi)存，ORACLE10.2.0.2

總數(shù)據(jù)量500GB左右（數(shù)據(jù)+索引）

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

網(wǎng)絡(luò)帶寬100M和20M

要求提供相應(yīng)的性能參數(shù)指標:

類別指標參考值

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

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

首次數(shù)據(jù)庫初始化同步源端CPU占用小于30%

源端CPU占用小于5%

目標端CPU占用小于5%

增量數(shù)據(jù)同步

源端內(nèi)存占用小于200M

（單個復(fù)制鏈路）

目標端內(nèi)存占用小于200M

復(fù)制數(shù)據(jù)延遲平均值10s以內(nèi)

源端CPU占用小于10%

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

復(fù)制數(shù)據(jù)延遲平均值10s以內(nèi)

1.3.5數(shù)據(jù)一致性

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

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

并可滿足如下要求：

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

一致性檢查需要能夠進行對象屬性、記錄條數(shù)和記錄的字段內(nèi)容進行一致

性檢查；

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

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

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

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

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

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

136系統(tǒng)兼容性

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

?SunSolaris9,10

?IBMAIX5.x

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

支持異構(gòu)平臺，源端和目標端不同數(shù)據(jù)庫版本；支持Cluster/HACMP和RAC模式,

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

1.3.7高可用性

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

上運行不同類型的應(yīng)用程序。

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

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

1.3.8健壯性要求

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

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

數(shù)據(jù)庫故障：在目標端數(shù)據(jù)庫故障下，源端數(shù)據(jù)庫不能受到影響。當(dāng)目標

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

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

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

1.3.9設(shè)備無關(guān)性

獨立于任何硬件設(shè)備、操作系統(tǒng)和Oracle數(shù)據(jù)庫的不同版本，能夠?qū)崿F(xiàn)不同平

臺之間數(shù)據(jù)庫的復(fù)制。

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

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

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

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

第二章OracleDataGuard介紹

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

部分。除了要將這些數(shù)據(jù)存放在高可用的存儲設(shè)備上之外，最重要的是這些關(guān)鍵數(shù)據(jù)

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

的數(shù)據(jù)保護技術(shù)。

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

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

務(wù)數(shù)據(jù)的遠程復(fù)制。

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

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

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

件產(chǎn)品不同，數(shù)據(jù)復(fù)制過程中的工作機制也不盡相同。概括地講，數(shù)據(jù)復(fù)制地工作

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

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

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

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

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

寬等因素限制，本次容災(zāi)方案僅包括了異步復(fù)制的方式的討論。

2.1DataGuard實現(xiàn)原理

OracleDataGuard是當(dāng)今保護企業(yè)核心資產(chǎn)（數(shù)據(jù)）的最有效解決方案，它

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

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

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

影響。

DataGuard使備用數(shù)據(jù)庫保持為與生產(chǎn)數(shù)據(jù)庫在事務(wù)上一致的副本。這些備

用數(shù)據(jù)庫可能位于距生產(chǎn)數(shù)據(jù)中心數(shù)千公里的遠程災(zāi)難恢復(fù)站點，或者可能位于同

一城市、同一校園乃至同一建筑物內(nèi)。當(dāng)生產(chǎn)數(shù)據(jù)庫由于計劃中斷或意外中斷而變得

不可用時，DataGuard可以將任意備用數(shù)據(jù)庫切換到生產(chǎn)角色，從而使與中斷相關(guān)

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

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

Oracle高可用性（HA）解決方案（如真正應(yīng)用集群（RAC）和恢復(fù)管理器（RMAN））

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

OracleDataGuard的一個概述。

客戶端客戶端

OracleDataGuard包括一個生產(chǎn)數(shù)據(jù)庫，也稱為主數(shù)據(jù)庫，以及一個或多個

備用數(shù)據(jù)庫，這些備用數(shù)據(jù)庫是與主數(shù)據(jù)庫在事務(wù)上一致的副本。DataGuard利用

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

入本地重做日志文件中。通過DataGuard,還將重做數(shù)據(jù)傳輸?shù)絺溆谜军c上，并應(yīng)

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

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

備用數(shù)據(jù)庫的底層技術(shù)是DataGuard重做應(yīng)用（物理備用數(shù)據(jù)庫）和Data

GuardSQL應(yīng)用（邏輯備用數(shù)據(jù)庫）。物理備用數(shù)據(jù)庫在磁盤上擁有和主數(shù)據(jù)庫逐塊

相同的數(shù)據(jù)庫結(jié)構(gòu)，并且使用Oracle介質(zhì)恢復(fù)進行更新。邏輯備用數(shù)據(jù)庫是一個

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

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

DataGuard簡化了主數(shù)據(jù)庫和選定的備用數(shù)據(jù)庫之間的轉(zhuǎn)換和故障切換，從

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

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

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

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

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

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

下圖顯示了OracleDataGuard組件。

物理備用

數(shù)據(jù)庫

2.2OracleDataGuard優(yōu)勢

災(zāi)難恢復(fù)和高可用性一DataGuard提供了一個高效和全面的災(zāi)難恢復(fù)和

高可用性解決方案。易于管理的轉(zhuǎn)換和故障切換功能允許主數(shù)據(jù)庫和備用數(shù)據(jù)庫

之間的角色轉(zhuǎn)換，從而使主數(shù)據(jù)庫因計劃的和計劃外的中斷所導(dǎo)致的停機時間減

到最少。

完善的數(shù)據(jù)保護一使用備用數(shù)據(jù)庫，DataGuard可保證即使遇到不可預(yù)見

的災(zāi)難也不會丟失數(shù)據(jù)。備用數(shù)據(jù)庫提供了防止數(shù)據(jù)損壞和用戶錯誤的安全保護

護。主數(shù)據(jù)庫上的存儲器級物理損壞不會傳播到備用數(shù)據(jù)庫上。同樣，導(dǎo)致主數(shù)

據(jù)庫永久損壞的邏輯損壞或用戶錯誤也能夠得到解決。最后，在將重做數(shù)據(jù)應(yīng)用

到備用數(shù)據(jù)庫時會對其進行驗證。

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

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

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

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

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

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

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

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

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

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

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

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

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

檔日志序列（或間隔），并將必要的存檔日志自動傳輸?shù)絺溆脭?shù)據(jù)庫中。備用數(shù)

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

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

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

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

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

與Oracle數(shù)據(jù)庫集成一OracleDataGuard是作為Oracle數(shù)據(jù)庫(企

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

2.3DataGuard提供的保護模式

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

模式、最大可用模式。

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

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

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

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

高速的局域網(wǎng)內(nèi)，最大保護模式也會對主數(shù)據(jù)庫性能有超過10%的性能影響。這

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

網(wǎng)路鏈路還是standby數(shù)據(jù)庫等發(fā)生故障導(dǎo)致日志無法正常寫均會導(dǎo)致主數(shù)據(jù)庫

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

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

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

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

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

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

Oracle提供的第三種模式是上述兩種方式的折中。在網(wǎng)絡(luò)正常的情況下它

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

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

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

大影響，而且對網(wǎng)絡(luò)鏈路要求較高。

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

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

對主數(shù)據(jù)庫性能影響較高較高低

對網(wǎng)絡(luò)鏈路要求極|;匕高低

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

數(shù)據(jù)保護無數(shù)據(jù)丟失基本無數(shù)據(jù)丟失少量數(shù)據(jù)丟失

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

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

邏輯standby。

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

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

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

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

做恢復(fù)與主數(shù)據(jù)保持一致。

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

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

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

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

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

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

--性索引。

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

主備數(shù)據(jù)庫必須是完全相同的硬件架構(gòu)，如均為SUN平臺。機器的內(nèi)存

大小、CPU數(shù)量主頻可以不同。

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

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

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

2.5切換方式

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

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

劃的停機操作。這時候可以手工將所有的日志以及歸檔日志文件傳輸?shù)絺浞莨?jié)點

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

換回來。

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

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

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

服務(wù)器。

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

要修改服務(wù)器IP地址或應(yīng)用程序重新指向。因為在不同的局域網(wǎng)內(nèi)，應(yīng)用中間

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

這需要在容災(zāi)的預(yù)案中考慮。

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

針對本容災(zāi)方案，我們推薦采用OracleDataGuard技術(shù)。

3.1DataGuard優(yōu)勢

?節(jié)約投資

OracleDataGuard是Oracle原廠自帶的容災(zāi)產(chǎn)品。該產(chǎn)品完全免費。在

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

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

早在Oracle7版本就已經(jīng)推出該功能（當(dāng)時名稱為Standby數(shù)據(jù)庫）。其

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

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

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

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

庫服務(wù)器端將歸檔日志文件傳輸?shù)饺轂?zāi)節(jié)點。因此對生產(chǎn)系統(tǒng)性能影響極

小。

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

DataGuard能夠滿足用戶基本的數(shù)據(jù)容災(zāi)、RTO、RPO、帶寬等相關(guān)基本業(yè)

務(wù)需求。

3.2DataGuard運行模式

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

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

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

Guard的方式。

3.3DataGuard保護模式

根據(jù)用戶的實際情況，在主數(shù)據(jù)庫服務(wù)器和容災(zāi)數(shù)據(jù)庫服務(wù)器之間距離較

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

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

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

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

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

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

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

與主數(shù)據(jù)庫可能有一定的數(shù)據(jù)差異。

3.4DataGuard初始安裝步驟

1、確認主數(shù)據(jù)庫運行于歸檔模式

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

模式。該修改過程需要短暫停止數(shù)據(jù)庫運行。

2、物理備份主數(shù)據(jù)庫的所有數(shù)據(jù)文件

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

據(jù)量以及UO速度不同，所需要的時間也不同。一般估算，100G的數(shù)據(jù)應(yīng)在1

小時內(nèi)備份完成。該備份操作啟動后無需人為干預(yù)。

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

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

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

因為數(shù)據(jù)量較大，可以將備份的文件壓縮后傳遞。100G的備份文件經(jīng)壓縮,

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

情況下，假設(shè)網(wǎng)絡(luò)利用率為70%,那么速度約為6G/每小時；50G的文件需要9

個小時傳遞完成。在網(wǎng)速為100M帶寬的情況下，假設(shè)網(wǎng)絡(luò)利用率為70%,那么

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

無需人為干預(yù)。

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

該操作對主數(shù)據(jù)庫運行沒有任何影響。

其中災(zāi)備中心數(shù)據(jù)庫平臺要求與主中心架構(gòu)一致，如均為SUN小型機。操

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

DataGuard不支持異構(gòu)平臺數(shù)據(jù)容災(zāi)，也不支持不同數(shù)據(jù)庫版本之間做數(shù)據(jù)

容災(zāi)。

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

該操作主要是解壓文件、恢復(fù)數(shù)據(jù)文件的時間。約為2小時。

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

致。

3.5用戶需求點對點應(yīng)答

3.5.1日常功能

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

應(yīng)答：滿足。DataGuard通過歸檔日志將數(shù)據(jù)庫變化復(fù)制到災(zāi)備中心。

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

應(yīng)答：部分滿足。物理DataGuard在正?；謴?fù)的時候無法處于打開狀態(tài)，在打

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

RTO<6小時，每天歸檔日志產(chǎn)生量<20G?？梢钥紤]以下方式解決該問題：

如果用戶對容災(zāi)數(shù)據(jù)庫使用時間為白天，那么在白天，將數(shù)據(jù)庫啟動為只

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

一致。如果用戶對容災(zāi)數(shù)據(jù)庫使用時間為夜間，那么反之在夜間將數(shù)據(jù)庫打開只

讀，白天數(shù)據(jù)庫做恢復(fù)。

容災(zāi)中心數(shù)據(jù)庫只在指定時間內(nèi)對數(shù)據(jù)庫做恢復(fù)，因此該數(shù)據(jù)庫與主數(shù)據(jù)庫

庫之間存在1天的數(shù)據(jù)差異。雖然沒有實時做數(shù)據(jù)恢復(fù)，歸檔日志文件在產(chǎn)生后

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

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

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

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

如果用戶對容災(zāi)中心數(shù)據(jù)庫使用為全天24小時，目前版本DataGuard無法

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

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

應(yīng)答：滿足。采用物理DataGuard的最大性能模式，生產(chǎn)中心主機僅需要在歸

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

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

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

?對網(wǎng)絡(luò)帶寬的占用較低。

應(yīng)答：滿足。DataGuard傳輸內(nèi)容數(shù)據(jù)變化產(chǎn)生的歸檔日志文件。目前每天歸檔

日志產(chǎn)生量為20G,那么傳輸量為20G/天。

3.5.2故障切換

當(dāng)生產(chǎn)中心的系統(tǒng)無法正常運行,而又不能在短期內(nèi)恢復(fù)時,可利用災(zāi)

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

應(yīng)答：滿足。災(zāi)備中心可以提供數(shù)據(jù)庫服務(wù)器。

?災(zāi)備中心必須在生產(chǎn)中心不可用6小時之內(nèi)完成業(yè)務(wù)接管。

應(yīng)答：滿足。災(zāi)備中心可以在6小時內(nèi)完成業(yè)務(wù)接管。

當(dāng)生產(chǎn)中心服務(wù)器恢復(fù)正常后,數(shù)據(jù)復(fù)制系統(tǒng)需要將災(zāi)備中心的最新數(shù)

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

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

在有計劃停機的情況下，災(zāi)備中心數(shù)據(jù)庫在啟用的時候，數(shù)據(jù)庫內(nèi)容保持

與生產(chǎn)中心完全一致。在主中心操作完成后，可以通過簡單命令，將災(zāi)備中心啟

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

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

心，在災(zāi)備中心啟用的時候，主、備之間數(shù)據(jù)已不一致。因此需要將所有數(shù)據(jù)重

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

3.5.3基本要求

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

log)的捕提及復(fù)制;

應(yīng)答：滿足。DataGuard通過對Onlineredolog產(chǎn)生的歸檔文件復(fù)制來完成容災(zāi)。

支持Oracle中所有的常用數(shù)據(jù)類型,如Oracle中的LONG、LONG

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

字段進行復(fù)制;

應(yīng)答：滿足。物理DataGuard支持Oracle中所有的常用數(shù)據(jù)類型

?支持對數(shù)據(jù)庫中常用DDL操作的復(fù)制;

應(yīng)答：滿足。物理DataGuard支持Oracle中常用DDL的操作復(fù)制。

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

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

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

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

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

務(wù)需求;

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

支持在數(shù)據(jù)復(fù)制過程中對數(shù)據(jù)正確性進行校驗,如正在復(fù)制的數(shù)據(jù)在之

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

大;

應(yīng)答：滿足。物理DataGuard復(fù)制的前提條件是主、備數(shù)據(jù)庫保持一致，因此

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

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

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

3.5.4性能要求

?數(shù)據(jù)庫初始化同步

要求數(shù)據(jù)庫復(fù)制軟件能夠?qū)l(fā)卡系統(tǒng)的數(shù)據(jù)庫中已有數(shù)據(jù)初始化同步到災(zāi)

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

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

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

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

據(jù)初始化的工作量。

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

況,需要注明是否支持異構(gòu)平臺下的首次數(shù)據(jù)初始化同步,是否支持跨數(shù)

據(jù)庫版本之間數(shù)據(jù)庫的初始化同步操作。

應(yīng)答：滿足。詳見DataGuard初始安裝步驟

?數(shù)據(jù)復(fù)制性能指標

數(shù)據(jù)復(fù)制的性能指標與系統(tǒng)平臺、網(wǎng)絡(luò)帶寬、應(yīng)用系統(tǒng)等因素密切相關(guān),參

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

項目配置

數(shù)據(jù)源SF15K24個CPU,32GB內(nèi)存,ORACLE10.2.0.2RAC

目標端SF15K24個CPU,32GB內(nèi)存,ORACLE10.2.0.2

總數(shù)據(jù)量500GB左右（數(shù)據(jù)+索引）

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

網(wǎng)絡(luò)帶寬100M和20M

要求提供相應(yīng)的性能參數(shù)指標:

類別指標參考值應(yīng)答

首次數(shù)據(jù)庫初始化同滿足，首次初始化同步時間小于5小H

小于10小時

首次數(shù)步時間（100M帶寬）時

據(jù)初始4首次數(shù)據(jù)庫初始化同滿足，首次初始化同步時間小于12小

小于48小時

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

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

步源端CPU占用1%

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

源端CPU占用小于5%

1%

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

滿足，對主資源消耗極小。無需額外內(nèi)

增量源端內(nèi)存占用小于200M

存消耗

數(shù)據(jù)同

滿足，對主資源消耗極小。無需額外內(nèi)

步目標端內(nèi)存占用小于200M

存消耗

（單個

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

復(fù)制鏈亂

DataGuard在日志切換后將改變的數(shù)

路）

據(jù)寫入災(zāi)備中心。頻繁的日志切換將

復(fù)制數(shù)據(jù)延遲平均值10s以內(nèi)

影響數(shù)據(jù)庫運行性能。建議將日志切

換頻率設(shè)置為10分鐘。因此數(shù)據(jù)復(fù)制

最大延遲約為10分鐘。

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

源端CPU占用小于10%

1%

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

業(yè)務(wù)高

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

峰期對為

DataGuard在日志切換后將改變的數(shù)

系統(tǒng)的

據(jù)寫入災(zāi)備中心。頻繁的日志切換將

影響復(fù)制數(shù)據(jù)延遲平均值10s以內(nèi)

影響數(shù)據(jù)庫運行性能。建議將日志切

換頻率設(shè)置為10分鐘。因此數(shù)據(jù)復(fù)制

最大延遲約為10分鐘。

3.5.5數(shù)據(jù)一致性

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

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

度,并可滿足如下要求:

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

一致性檢查需要能夠進行對象屬性、記錄條數(shù)和記錄的字段內(nèi)容進行一

致性檢查;

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

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

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

對于不一致的數(shù)