OracleDataGuard數(shù)據庫容災方案

1、數(shù)據庫異地容災方案介紹2008年11月目錄第一章 需求分析41.1 序言41.2 用戶現(xiàn)狀4 系統(tǒng)平臺4 數(shù)據庫平臺61.3 用戶需求7 日常功能7 故障切換7 基本要求7 性能要求8 數(shù)據一致性9 系統(tǒng)兼容性9 高可用性10 健壯性要求10 設備無關性10 管理監(jiān)控功能11第二章 Oracle Data Guard介紹122.1 Data Guard實現(xiàn)原理122.2 Oracle Data Guard 優(yōu)勢152.3 Data Guard提供的保護模式162.4 Data Guard實現(xiàn)方式以及對系統(tǒng)的限制要求172.5 切換方式17第三章 系統(tǒng)建議方案183.1 Data Guard優(yōu)勢

2、183.2 Data Guard運行模式193.3 Data Guard保護模式193.4 Data Guard初始安裝步驟193.5 用戶需求點對點應答20 日常功能20 故障切換21 基本要求22 性能要求23 數(shù)據一致性24 系統(tǒng)兼容性25 高可用性25 健壯性要求26 設備無關性27 管理監(jiān)控功能27第一章 需求分析1.1 序言在信息時代，數(shù)據是企業(yè)創(chuàng)造商業(yè)價值的生產資料，數(shù)據的丟失將為企業(yè)帶來毀滅性的災難。據Gartner Group的調查數(shù)據表明，在經歷過大型災難或長時間系統(tǒng)停運的公司中，有2/5的公司再也未恢復運行，而在其余的公司中，有1/3的公司在兩年內破產。有句古諺叫“別把雞

3、蛋放在一個籃子里”?，F(xiàn)在的信息系統(tǒng)，各種數(shù)據高度集中，“雞蛋”全放在一個籃里了。一旦出現(xiàn)突然停電、意外死機或者人為破壞，造成數(shù)據丟失是不可避免的。面對各種未可預知的災難，越來越多的企業(yè)將容災備份系統(tǒng)作為企業(yè)安全的保障。銀聯(lián)數(shù)據異地災備項目的目標是保證SF25K上各銀行（民生銀行貸記卡系統(tǒng)擬遷移至IBM主機，故此次災備項目暫不考慮；郵儲銀行貸記卡系統(tǒng)主機為IBM P570，也不在考慮范圍之內）發(fā)卡系統(tǒng)的安全，在災難情況下，最大限度地保護公司資產，減少公司各方面的損失，保證發(fā)卡系統(tǒng)的業(yè)務連續(xù)性。本方案僅對異地容災數(shù)據庫復制軟件部分做相應闡述。1.2 用戶現(xiàn)狀1.2.1 系統(tǒng)平臺發(fā)卡系統(tǒng)運行在一臺S

4、unFire E25K企業(yè)級服務器上，通過兩臺Brocade SW4900 SAN交換機與兩臺企業(yè)級存儲ST9990、SE9970相連，應用系統(tǒng)核心文件和數(shù)據庫數(shù)據文件均存放在該存儲上，存儲系統(tǒng)磁盤采用RAID 1+0方式。SF25K劃分為四個物理分區(qū)（Domain），每家銀行均使用其中的兩個，一個Domain作為生產主機，另一個Domain作為熱備主機。Domain操作系統(tǒng)為Solaris 10，數(shù)據庫系統(tǒng)為Oracle 10.2.0.2 RAC。通過Sun Cluster集群軟件，實現(xiàn)了生產機房內的雙機熱備份，保證了系統(tǒng)的高可用性。此外，在主機端還通過Sun MPXIO多通道負載均衡軟件，

5、實現(xiàn)兩條光纖通道的負載均衡，進一步避免了單點故障。以下是發(fā)卡系統(tǒng)SAN架構圖：SW4900 SW4900 SE9970 L180 (2 LTO-3)V280RNBU Master Server ST9990 SF25KDomain ADomain BDomain CDomain DVTL通過在主機端使用VxVM 4.1卷管理軟件，已建立了同機房數(shù)據災備系統(tǒng)，兩臺存儲SE9970與ST9990之間實現(xiàn)了同步數(shù)據復制，達到了以下災難恢復目標：l 日常工作，保證兩臺存儲的數(shù)據實時同步保持一致，所有數(shù)據不丟失。l 計劃外停機，任一臺存儲發(fā)生災難，保證數(shù)據不丟失，即RPO=0，并確保應用不中斷運行，即R

6、TO=0。SE9970ST9990生產主機VxVM Mirror Volume1.2.2 數(shù)據庫平臺發(fā)卡系統(tǒng)中的數(shù)據庫系統(tǒng)，是整個生產系統(tǒng)中最關鍵、最復雜的數(shù)據對象，發(fā)卡系統(tǒng)的業(yè)務運轉直接依賴于這些數(shù)據的可用性。為了確保數(shù)據庫的高可用性，發(fā)卡系統(tǒng)數(shù)據庫使用了Oracle 10g RAC版本.2，主、備機兩節(jié)點的數(shù)據庫實例同時運行，一旦主節(jié)點出現(xiàn)問題，數(shù)據庫實例無需啟停，可迅速將應用系統(tǒng)切換至備節(jié)點。截至到2008年8月底，各數(shù)據庫實例數(shù)據量情況見下表：實例名總數(shù)據量（GB）Archive log數(shù)據量（GB）高峰期Archive log變化量（MB/s）平均每天最大帳單日HX25140.42

7、SZ15120.20 CR934.550.40 DE381.550.58 UC27512162.95 合計44620324.55 1.3 用戶需求銀聯(lián)數(shù)據擬為提供外包服務的各銀行發(fā)卡系統(tǒng)建設異地災備系統(tǒng)，生產系統(tǒng)位于上海，災備系統(tǒng)位于北京。主備中心之間采用數(shù)據庫復制軟件進行異步數(shù)據復制，以保證生產數(shù)據的安全性，滿足發(fā)卡系統(tǒng)的業(yè)務連續(xù)性需求。1.3.1 日常功能l 將生產中心發(fā)卡系統(tǒng)上的數(shù)據庫變化實時異步復制到災備中心；l 災備中心的Oracle數(shù)據庫處于打開狀態(tài)，可提供實時數(shù)據查詢；l 對生產系統(tǒng)的資源占用不能太多，不能影響到生產系統(tǒng)的正常運行；l 對網絡帶寬的占用較低。1.3.2 故障切換l

8、 當生產中心的系統(tǒng)無法正常運行，而又不能在短期內恢復時，可利用災備中心提供業(yè)務接管。 l 災備中心必須在生產中心不可用6小時之內完成業(yè)務接管。l 當生產中心服務器恢復正常后，數(shù)據復制系統(tǒng)需要將災備中心的最新數(shù)據反向復制回生產中心，實現(xiàn)業(yè)務的恢復。1.3.3 基本要求l 復制軟件應滿足在單機或RAC環(huán)境下，對Oracle在線日志(Online redo log)的捕捉及復制；l 支持Oracle中所有的常用數(shù)據類型，如Oracle中的LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可實現(xiàn)用戶自定義表、字段進行復制；l 支持對數(shù)據庫中常用DDL操作的復制；l 支

9、持事務復制，要求對數(shù)據庫中較大的事務不會出現(xiàn)過多延遲；l 支持沒有PK/UK字段的表的同步。l 數(shù)據復制過程可根據需要靈活地進行控制或修改復制的方向，以滿足業(yè)務需求；l 支持在數(shù)據復制過程中對數(shù)據正確性進行校驗，如正在復制的數(shù)據在之前就已經不一致，應提供報警功能，以便及時發(fā)現(xiàn)錯誤，避免錯誤的擴大；l 提供專用圖形化集中管理軟件。1.3.4 性能要求l 數(shù)據庫初始化同步要求數(shù)據庫復制軟件能夠將發(fā)卡系統(tǒng)的數(shù)據庫中已有數(shù)據初始化同步到災備中心數(shù)據庫。在初始化同步過程中，業(yè)務不能停止，但可選擇業(yè)務量較小時段進行。在解決方案書中要求詳細描述初始化數(shù)據同步解決方案，以及整個首次同步操作所需要的時間（以10

10、0GB數(shù)據為標準），并且要求列出整個首次初始化過程中是否需要人為干預，從而可以有效地評估整個首次數(shù)據初始化的工作量。為了保證生產中心日后業(yè)務擴展存在更換服務器廠商以及數(shù)據庫版本等情況，需要注明是否支持異構平臺下的首次數(shù)據初始化同步，是否支持跨數(shù)據庫版本之間數(shù)據庫的初始化同步操作。l 數(shù)據復制性能指標數(shù)據復制的性能指標與系統(tǒng)平臺、網絡帶寬、應用系統(tǒng)等因素密切相關，參照下列運行環(huán)境：項目配置數(shù)據源SF15K 24個CPU，32GB內存， ORACLE 10.2.0.2 RAC目標端SF15K 24個CPU，32GB內存， ORACLE 10.2.0.2總數(shù)據量500GB左右（數(shù)據+索引）每天的日志

11、量每天20GB日志網絡帶寬100M和20M要求提供相應的性能參數(shù)指標：類別指標參考值首次數(shù)據初始化同步首次數(shù)據庫初始化同步時間（100M帶寬） 小于10小時首次數(shù)據庫初始化同步時間（20M帶寬）小于48小時首次數(shù)據庫初始化同步源端CPU占用小于30 增量數(shù)據同步（單個復制鏈路）源端CPU占用小于5目標端CPU占用小于5源端內存占用小于200M目標端內存占用小于200M復制數(shù)據延遲平均值10s以內業(yè)務高峰期對系統(tǒng)的影響 源端CPU占用小于10目標端CPU占用小于10復制數(shù)據延遲平均值10s以內1.3.5 數(shù)據一致性要求數(shù)據庫復制軟件提供數(shù)據庫初始化同步、數(shù)據恢復后以及日常的數(shù)據一致性檢查方案，要

12、求方案中詳細注明該數(shù)據一致性比對方案的特點以及操作復雜度，并可滿足如下要求：l 可在應用不停機的情況下，查找和發(fā)現(xiàn)不一致的數(shù)據；l 一致性檢查需要能夠進行對象屬性、記錄條數(shù)和記錄的字段內容進行一致性檢查；l 提供全庫的記錄級一致性檢查時間（以100GB的數(shù)據為例）。l 支持不含PK/UK字段的表的一致性檢查和修復。請?zhí)峁┰跊]有PK/UK字段的表中有1000萬條記錄的比對時間。對于不一致的數(shù)據，需要提供不一致記錄詳細信息，以便進行精確的修復，同時提供數(shù)據修復方案。數(shù)據修復工作要求操作簡單，修復速度快，且修復過程中不影響業(yè)務正常運行。1.3.6 系統(tǒng)兼容性數(shù)據庫復制軟件應支持以下操作系統(tǒng)平臺：l

13、Sun Solaris 9,10l IBM AIX 5.x數(shù)據庫復制軟件應支持Oracle 9i，Oracle 10g，Oracle 11g及后續(xù)數(shù)據庫版本；支持異構平臺，源端和目標端不同數(shù)據庫版本；支持Cluster/HACMP和RAC模式，并支持不同操作系統(tǒng)下不同數(shù)據庫版本之間的復制。1.3.7 高可用性主系統(tǒng)和備用系統(tǒng)的數(shù)據庫處于雙活狀態(tài)，以保證在災難發(fā)生前可在兩個系統(tǒng)上運行不同類型的應用程序。數(shù)據庫復制軟件應支持本地Cluster/HACMP的高可用方式，在本地單節(jié)點出現(xiàn)故障時，可通過Cluster軟件接管到其它節(jié)點。1.3.8 健壯性要求數(shù)據庫復制軟件在各種大壓力和各種故障情況下不會

14、造成數(shù)據復制失敗。l 網絡故障：長時間中斷、短時間中斷及網絡時斷時續(xù)情況下的正常復制；l 數(shù)據庫故障：在目標端數(shù)據庫故障下， 源端數(shù)據庫不能受到影響。當目標端數(shù)據庫修復后，復制軟件繼續(xù)工作；l 服務器硬件故障：在目標端服務器故障下， 源端生產系統(tǒng)不能受到影響，當目標端修復后，復制軟件繼續(xù)工作。1.3.9 設備無關性獨立于任何硬件設備、操作系統(tǒng)和Oracle數(shù)據庫的不同版本，能夠實現(xiàn)不同平臺之間數(shù)據庫的復制。1.3.10 管理監(jiān)控功能數(shù)據庫復制軟件需提供統(tǒng)一的管理監(jiān)控功能，能實現(xiàn)對復制軟件的運行狀態(tài)、運行日志、系統(tǒng)配置等方面進行統(tǒng)一的管理及監(jiān)控，保證出現(xiàn)錯誤時具有完整方便的報警及跟蹤機制，方便故

15、障的快速定位和解決。第二章 Oracle Data Guard介紹容災系統(tǒng)主要包括數(shù)據保護和應用切換兩大方面，其中最為重要的是數(shù)據保護部分。除了要將這些數(shù)據存放在高可用的存儲設備上之外，最重要的是這些關鍵數(shù)據應該在異地之間保持一致，以使災難發(fā)生后，系統(tǒng)可以盡快恢復。下面是幾種主要的數(shù)據保護技術。實現(xiàn)數(shù)據的異地復制，有軟件方式和硬件方式兩種途徑。軟件方式，是通過主機端軟件來實現(xiàn)，如第三方軟件或者數(shù)據庫廠家提供的遠程數(shù)據容災工具來實現(xiàn)業(yè)務數(shù)據的遠程復制。硬件方式，是基于智能存儲系統(tǒng)的控制器的遠程拷貝，可以在主、備存儲系統(tǒng)之間通過硬件實現(xiàn)復制。在實際的容災系統(tǒng)中，由于系統(tǒng)的環(huán)境不同，安全性要求不同以

16、及采用的軟硬件產品不同，數(shù)據復制過程中的工作機制也不盡相同。概括地講，數(shù)據復制地工作機制主要包括同步和異步兩種。同步遠程鏡像(同步復制技術)是指通過遠程鏡像軟件，將本地數(shù)據以完全同步的方式復制到異地，每一本地的I/O事務均需等待遠程復制的完成確認信息，方予以釋放。異步遠程鏡像(異步復制技術)保證在更新遠程存儲視圖前完成向本地存儲系統(tǒng)的基本I/O操作，而由本地存儲系統(tǒng)提供給請求鏡像主機的I/O操作完成確認信息，遠程的數(shù)據復制以后臺同步的方式進行。因為帶寬等因素限制，本次容災方案僅包括了異步復制的方式的討論。2.1 Data Guard實現(xiàn)原理Oracle Data Guard 是當今保護企業(yè)核心

17、資產（數(shù)據）的最有效解決方案，它能夠使數(shù)據在 24x7 的基礎上可用，而無論是否發(fā)生災難或其它中斷。Oracle Data Guard 是管理、監(jiān)控和自動化軟件的基礎架構，它創(chuàng)建、維護和監(jiān)控一個或多個備用數(shù)據庫，以保護企業(yè)數(shù)據結構不受故障、災難、錯誤和崩潰的影響。 Data Guard 使備用數(shù)據庫保持為與生產數(shù)據庫在事務上一致的副本。這些備用數(shù)據庫可能位于距生產數(shù)據中心數(shù)千公里的遠程災難恢復站點，或者可能位于同一城市、同一校園乃至同一建筑物內。當生產數(shù)據庫由于計劃中斷或意外中斷而變得不可用時，Data Guard 可以將任意備用數(shù)據庫切換到生產角色，從而使與中斷相關的停機時間減到最少，并防止

18、任何數(shù)據丟失。 作為 Oracle 數(shù)據庫企業(yè)版的一個特性推出的 Data Guard 能夠與其它的 Oracle 高可用性 (HA) 解決方案（如真正應用集群 (RAC) 和恢復管理器 (RMAN)）結合使用，以提供業(yè)內前所未有的高水平數(shù)據保護和數(shù)據可用性。下圖提供了 Oracle Data Guard 的一個概述。Oracle Data Guard 包括一個生產數(shù)據庫，也稱為主數(shù)據庫，以及一個或多個備用數(shù)據庫，這些備用數(shù)據庫是與主數(shù)據庫在事務上一致的副本。Data Guard 利用重做數(shù)據保持這種事務一致性。當主數(shù)據庫中發(fā)生事務時，則生成重做數(shù)據并將其寫入本地重做日志文件中。通過 Data

19、 Guard，還將重做數(shù)據傳輸?shù)絺溆谜军c上，并應用到備用數(shù)據庫中，從而使備用數(shù)據庫與主數(shù)據庫保持同步。Data Guard 允許管理員選擇將重做數(shù)據同步還是異步地發(fā)送到備用站點上。 備用數(shù)據庫的底層技術是 Data Guard 重做應用（物理備用數(shù)據庫）和 Data Guard SQL 應用（邏輯備用數(shù)據庫）。物理備用數(shù)據庫在磁盤上擁有和主數(shù)據庫逐塊相同的數(shù)據庫結構，并且使用 Oracle 介質恢復進行更新。邏輯備用數(shù)據庫是一個獨立數(shù)據庫，它與主數(shù)據庫包含相同的數(shù)據。它使用 SQL 語句進行更新，其相對優(yōu)勢是能夠并行用于恢復以及諸如報表、查詢等其他任務。 Data Guard 簡化了主數(shù)據庫和

20、選定的備用數(shù)據庫之間的轉換和故障切換，從而減少了由計劃停機和計劃外故障所導致的總停機時間。 主數(shù)據庫和備用數(shù)據庫以及它們的各種交互可以使用 SQL*Plus 來進行管理。為了獲得更簡便的可管理性，Data Guard 還提供了一個分布式管理框架（稱為 Data Guard Broker），它不但自動化了 Data Guard 配置的創(chuàng)建、維護和監(jiān)控，并對這些操作進行統(tǒng)一管理。管理員可以使用 Oracle Enterprise Manager 或 Broker 自己的專用命令行界面 (DGMGRL) 來利用 Broker 的管理功能。 下圖顯示了 Oracle Data Guard 組件。 2.

21、2 Oracle Data Guard 優(yōu)勢 災難恢復和高可用性 Data Guard 提供了一個高效和全面的災難恢復和高可用性解決方案。易于管理的轉換和故障切換功能允許主數(shù)據庫和備用數(shù)據庫之間的角色轉換，從而使主數(shù)據庫因計劃的和計劃外的中斷所導致的停機時間減到最少。 完善的數(shù)據保護 使用備用數(shù)據庫，Data Guard 可保證即使遇到不可預見的災難也不會丟失數(shù)據。備用數(shù)據庫提供了防止數(shù)據損壞和用戶錯誤的安全保護。主數(shù)據庫上的存儲器級物理損壞不會傳播到備用數(shù)據庫上。同樣，導致主數(shù)據庫永久損壞的邏輯損壞或用戶錯誤也能夠得到解決。最后，在將重做數(shù)據應用到備用數(shù)據庫時會對其進行驗證。 有效利用系統(tǒng)資

22、源 備用數(shù)據庫表使用從主數(shù)據庫接收到的重做數(shù)據進行更新，并且可用于諸如備份操作、報表、合計和查詢等其它任務，從而減少執(zhí)行這些任務所必需的主數(shù)據庫工作負載，節(jié)省寶貴的 CPU 和 I/O 周期。使用邏輯備用數(shù)據庫，用戶可以在模式中不從主數(shù)據庫進行更新的表上執(zhí)行數(shù)據處理操作。邏輯備用數(shù)據庫可以在從主數(shù)據庫中對表進行更新時保持打開，并可同時對表進行只讀訪問。最后，可以在維護的表上創(chuàng)建額外索引和物化視圖，以獲得更好的查詢性能和適應特定的業(yè)務要求。靈活的數(shù)據保護功能，從而在可用性與性能要求之間取得平衡 Oracle Data Guard 提供了最大保護、最高可用性和最高性能等模式，來幫助企業(yè)在系統(tǒng)性能要

23、求和數(shù)據保護之間取得平衡。 自動間隔檢測及其解決方案 如果主數(shù)據庫與一個或更多個備用數(shù)據庫之間的連接丟失（例如，由于網絡問題），則在主數(shù)據庫上生成的重做數(shù)據將無法發(fā)送到那些備用數(shù)據庫上。一旦重新建立連接，Data Guard 就自動檢測丟失的存檔日志序列（或間隔），并將必要的存檔日志自動傳輸?shù)絺溆脭?shù)據庫中。備用數(shù)據庫將重新與主數(shù)據庫同步，而無需管理員的任何手動干預。 簡單的集中式管理 Data Guard Broker 使一個 Data Guard 配置中的多個數(shù)據庫間的管理和操作任務自動化。Broker 還監(jiān)控單個 Data Guard 配置內的所有系統(tǒng)。管理員可以使用 Oracle Ent

24、erprise Manager 或 Broker 自己專用的命令行界面 (DGMGRL) 來利用這個集成的管理框架。 與 Oracle 數(shù)據庫集成 Oracle Data Guard 是作為 Oracle 數(shù)據庫（企業(yè)版）的一個完全集成的功能提供的，無需任何額外費用。 2.3 Data Guard提供的保護模式Oracle針對用戶的不同需求提供三種保護模式：最大保護模式、最大性能模式、最大可用模式。Oracle提供的Data Guard在最大保護模式下可以確保數(shù)據完全不丟失。它在寫本地日志的同時寫遠程standby的數(shù)據庫日志。只有兩個日志均寫成功后一個操作才是正式完成。這種方式確保了數(shù)據的最

25、大安全，能夠確保主數(shù)據庫損壞的情況下沒有任何數(shù)據丟失。但這種情況對主數(shù)據庫性能有較大的影響，即使在高速的局域網內，最大保護模式也會對主數(shù)據庫性能有超過10%的性能影響。這種方式對主備兩個數(shù)據庫之間的鏈路有非常高的要求。在這種保護模式下無論是網路鏈路還是standby數(shù)據庫等發(fā)生故障導致日志無法正常寫均會導致主數(shù)據庫無法使用。因此只有在對數(shù)據安全要求最高的情況下才會考慮使用這種方式。Oracle也提供最大性能模式。這種模式下，不傳輸實時修改的日志文件，傳遞的是歸檔日志文件，因此對主數(shù)據庫性能影響很小。歸檔日志文件傳遞是否能夠成功對主數(shù)據庫運行沒有任何影響，因此在網絡出現(xiàn)中斷或者standby數(shù)據

26、庫出現(xiàn)異常也不會影響主數(shù)據庫的正常運行。但因為日志沒有同步寫，因此在災難發(fā)生的時候備份數(shù)據庫與主數(shù)據庫可能有一定的數(shù)據差異。Oracle提供的第三種模式是上述兩種方式的折中。在網絡正常的情況下它的運行方式類似于最大保護模式，日志實時傳遞。當網絡或standby出現(xiàn)故障的時候它的運行模式類似于最大性能模式，日志延遲傳遞，不會導致主數(shù)據庫停止運行。這種方式在正常情況下因為日志實時傳遞，因此同樣對主數(shù)據庫性能有較大影響，而且對網絡鏈路要求較高。綜上所述，不同的保護模式比較如下：最大保護最大可用最大性能對主數(shù)據庫性能影響較高較高低對網絡鏈路要求極高高低備份系統(tǒng)發(fā)生故障主數(shù)據庫不可用無影響無影響數(shù)據保護

27、無數(shù)據丟失基本無數(shù)據丟失少量數(shù)據丟失2.4 Data Guard實現(xiàn)方式以及對系統(tǒng)的限制要求Oracle針對不同的用戶情況提供的兩種不同的standby方式。物理standby ,邏輯standby。物理standby數(shù)據庫，在通常的模式下備份庫始終處于恢復狀態(tài)，用戶無法訪問備份庫的數(shù)據。如果需要訪問數(shù)據，需要將恢復模式停止，將數(shù)據庫打開到只讀狀態(tài)。這兩種狀態(tài)是排它的，也就是說數(shù)據庫要么是恢復狀態(tài)，保持和主數(shù)據庫一致，在這種狀態(tài)下數(shù)據庫內容不可訪問；要么是只讀狀態(tài)，數(shù)據庫不會做恢復與主數(shù)據保持一致。Oracle還提供邏輯standby數(shù)據庫。這種方式下數(shù)據庫可以在打開的狀態(tài)下保持與主數(shù)據庫的同

28、步工作。這種打開狀態(tài)和普通的數(shù)據庫open狀態(tài)不同，不能對數(shù)據做修改。這種方式通常用于繁忙的系統(tǒng)，如主數(shù)據庫日常完成業(yè)務處理，邏輯standby數(shù)據庫在完成容災的同時分擔主數(shù)據庫的查詢統(tǒng)計工作。這樣大大節(jié)約了系統(tǒng)資源。但這種方式對數(shù)據庫有一定的限制，并不是所有的系統(tǒng)都能夠支持。部分較為特殊的數(shù)據類型不支持，另外所有的表必須要有主鍵或者唯一性索引。無論是物理standby 還是邏輯standby均對系統(tǒng)要求如下:l 主備數(shù)據庫必須是完全相同的硬件架構，如均為SUN平臺。機器的內存大小、CPU數(shù)量主頻可以不同。l 操作系統(tǒng)版本、補丁完全相同。l 數(shù)據庫版本完全相同。但RAC選件可以不同。即主數(shù)據庫

29、可以是RAC模式，備份節(jié)點可以是單機。2.5 切換方式Oracle Data Guard可以實現(xiàn)failover 以及switchover的切換。Switchover指有計劃的切換。如系統(tǒng)主數(shù)據庫服務器需要硬件維護等有計劃的停機操作。這時候可以手工將所有的日志以及歸檔日志文件傳輸?shù)絺浞莨?jié)點后執(zhí)行switchover的切換。這種情況下等主數(shù)據庫恢復正常后系統(tǒng)可以手工切換回來。Failover切換是指系統(tǒng)出現(xiàn)了異常情況下的切換。系統(tǒng)管理員發(fā)現(xiàn)主數(shù)據庫服務器無法提供服務，決定啟動容災系統(tǒng)。在這種情況下的切換后如果主數(shù)據庫服務器恢復正常后需要重新配置整個Data Guard環(huán)境，無法切換回主數(shù)據庫服務

30、器。無論是那種切換方式，主備系統(tǒng)之間均存在部分差別。如IP地址不同，需要修改服務器IP 地址或應用程序重新指向。因為在不同的局域網內，應用中間件需要跨防火墻訪問系統(tǒng)。機器檔次不同、網絡帶寬不同造成的性能下降等問題。這需要在容災的預案中考慮。第三章 系統(tǒng)建議方案針對本容災方案，我們推薦采用Oracle Data Guard技術。3.1 Data Guard優(yōu)勢l 節(jié)約投資Oracle Data Guard是Oracle原廠自帶的容災產品。該產品完全免費。在容災軟件上用戶無需支付額外費用，這可以大大節(jié)約用戶的資金投入。l 技術成熟、穩(wěn)定早在Oracle 7版本就已經推出該功能（當時名稱為Stand

31、by數(shù)據庫）。其核心采用了Oracle成熟的歸檔、備份、恢復技術。經過多年不斷的發(fā)展，已經成為一項技術成熟、穩(wěn)定，有廣泛成功案例的技術。l 對系統(tǒng)運行性能影響小Data Guard在主數(shù)據庫服務器端不存在對日志解析等工作，僅需要主數(shù)據庫服務器端將歸檔日志文件傳輸?shù)饺轂墓?jié)點。因此對生產系統(tǒng)性能影響極小。l 能夠滿足用戶基本業(yè)務需求Data Guard能夠滿足用戶基本的數(shù)據容災、RTO、RPO、帶寬等相關基本業(yè)務需求。3.2 Data Guard運行模式Oracle提供了物理Data Guard以及邏輯Data Guard兩種不同的方式。這兩種方式各有優(yōu)缺點。因為用戶數(shù)據庫中存在大量表，這些表沒有

32、PK/UK；因此無法滿足邏輯Data Guard的使用前提條件。在本方案中，我們推薦采用物理Data Guard的方式。3.3 Data Guard保護模式根據用戶的實際情況，在主數(shù)據庫服務器和容災數(shù)據庫服務器之間距離較遠，使用最大保護模式和最大可用模式均會嚴重影響主數(shù)據庫的運行性能。用戶允許在出現(xiàn)異常情況下15分鐘內的數(shù)據丟失量，因此采用最大性能模式可以在現(xiàn)有帶寬的情況下滿足用戶的容災需求。采用最大性能模式，系統(tǒng)不會實時傳輸日志文件，傳遞的是歸檔日志文件，因此對主數(shù)據庫性能影響很小。歸檔日志文件傳遞是否能夠成功對主數(shù)據庫運行沒有任何影響，因此在網絡出現(xiàn)中斷或者standby數(shù)據庫出現(xiàn)異常也不

33、會影響主數(shù)據庫的正常運行。但因為日志沒有同步寫，因此在災難發(fā)生的時候備份數(shù)據庫與主數(shù)據庫可能有一定的數(shù)據差異。3.4 Data Guard初始安裝步驟1、確認主數(shù)據庫運行于歸檔模式如果主數(shù)據庫沒有處于歸檔模式，那么需要將數(shù)據庫運行模式修改為歸檔模式。該修改過程需要短暫停止數(shù)據庫運行。2、物理備份主數(shù)據庫的所有數(shù)據文件該部分工作可以在不影響業(yè)務正常運行的情況下執(zhí)行。該部分工作依據數(shù)據量以及I/O速度不同，所需要的時間也不同。一般估算，100G的數(shù)據應在1小時內備份完成。該備份操作啟動后無需人為干預。3、在主數(shù)據庫創(chuàng)建standby 控制文件通過命令創(chuàng)建災備中心的控制文件。4、拷貝備份的數(shù)據文件、

34、standby控制文件及日志文件到備份節(jié)點。因為數(shù)據量較大，可以將備份的文件壓縮后傳遞。100G的備份文件經壓縮，通常壓縮率在40% - 50%之間。100G文件壓縮后約50G。在網速為20M帶寬的情況下，假設網絡利用率為70%，那么速度約為6G/每小時；50G的文件需要9個小時傳遞完成。在網速為100M帶寬的情況下，假設網絡利用率為70%，那么速度約為30G/每小時；50G的文件需要1.5個小時傳遞完成。在數(shù)據傳輸啟動后無需人為干預。5、配置主、備中心的數(shù)據庫服務器Data Guard環(huán)境該操作對主數(shù)據庫運行沒有任何影響。其中災備中心數(shù)據庫平臺要求與主中心架構一致，如均為SUN小型機。操作系

35、統(tǒng)版本及數(shù)據庫版本均需要一致。Data Guard不支持異構平臺數(shù)據容災，也不支持不同數(shù)據庫版本之間做數(shù)據容災。6、使用主中心備份的文件創(chuàng)建災備中心數(shù)據庫系統(tǒng)。該操作主要是解壓文件、恢復數(shù)據文件的時間。約為2小時。7、配置災備中心環(huán)境。根據主中心的歸檔日志保持災備中心與主中心一致 。3.5 用戶需求點對點應答3.5.1 日常功能l 將生產中心發(fā)卡系統(tǒng)上的數(shù)據庫變化實時異步復制到災備中心；應答：滿足。Data Guard通過歸檔日志將數(shù)據庫變化復制到災備中心。l 災備中心的Oracle數(shù)據庫處于打開狀態(tài)，可提供實時數(shù)據查詢；應答：部分滿足。物理Data Guard在正?；謴偷臅r候無法處于打開狀態(tài)

36、，在打開的狀態(tài)下無法處于恢復與主數(shù)據庫保持一致的狀態(tài)。本系統(tǒng)的RPO<15分鐘，RTO<6小時，每天歸檔日志產生量<20G。可以考慮以下方式解決該問題：如果用戶對容災數(shù)據庫使用時間為白天，那么在白天，將數(shù)據庫啟動為只讀打開模式，供業(yè)務查詢。夜間，將數(shù)據庫啟動為恢復模式，保持與主生產中心一致。如果用戶對容災數(shù)據庫使用時間為夜間，那么反之在夜間將數(shù)據庫打開只讀，白天數(shù)據庫做恢復。容災中心數(shù)據庫只在指定時間內對數(shù)據庫做恢復，因此該數(shù)據庫與主數(shù)據庫之間存在1天的數(shù)據差異。雖然沒有實時做數(shù)據恢復，歸檔日志文件在產生后會同步寫入容災中心，因此系統(tǒng)可以滿足RPO<15分鐘的要求。當出

37、現(xiàn)需要啟動備用中心的情況，備用中心需要先通過歸檔日志文件恢復數(shù)據。目前每天歸檔日志量<20G，系統(tǒng)使用這些歸檔日志恢復數(shù)據的時間< 2小時，能夠滿足RTO<6小時的業(yè)務需求。如果用戶對容災中心數(shù)據庫使用為全天24小時，目前版本Data Guard無法滿足要求，在Oracle11G 以后的版本提供該功能。l 對生產系統(tǒng)的資源占用不能太多，不能影響到生產系統(tǒng)的正常運行；應答：滿足。采用物理Data Guard的最大性能模式，生產中心主機僅需要在歸檔日志產生后將歸檔日志文件寫入異地容災中心，對生產系統(tǒng)資源占用極少，不影響生產系統(tǒng)的正常運行。在網絡出現(xiàn)故障或容災中心出現(xiàn)故障時，不會影

38、響到生產系統(tǒng)的正常運行。l 對網絡帶寬的占用較低。應答：滿足。Data Guard傳輸內容數(shù)據變化產生的歸檔日志文件。目前每天歸檔日志產生量為20G，那么傳輸量為20G/天。3.5.2 故障切換l 當生產中心的系統(tǒng)無法正常運行，而又不能在短期內恢復時，可利用災備中心提供業(yè)務接管。 應答：滿足。災備中心可以提供數(shù)據庫服務器。l 災備中心必須在生產中心不可用6小時之內完成業(yè)務接管。應答：滿足。災備中心可以在6小時內完成業(yè)務接管。l 當生產中心服務器恢復正常后，數(shù)據復制系統(tǒng)需要將災備中心的最新數(shù)據反向復制回生產中心，實現(xiàn)業(yè)務的恢復。應答：部分滿足。系統(tǒng)切換可以分為有計劃的停機以及故障停機。在有計劃停

39、機的情況下，災備中心數(shù)據庫在啟用的時候，數(shù)據庫內容保持與生產中心完全一致。在主中心操作完成后，可以通過簡單命令，將災備中心啟用期間數(shù)據修改反向復制回生產中心，實現(xiàn)業(yè)務的恢復。在故障停機的情況下，主中心可能有部分數(shù)據(<15分鐘)尚未傳遞到備份中心，在災備中心啟用的時候，主、備之間數(shù)據已不一致。因此需要將所有數(shù)據重新傳遞回主中心才能實現(xiàn)業(yè)務的恢復。3.5.3 基本要求l 復制軟件應滿足在單機或RAC環(huán)境下，對Oracle在線日志(Online redo log)的捕捉及復制；應答：滿足。Data Guard通過對Online redo log產生的歸檔文件復制來完成容災。l 支持Oracl

40、e中所有的常用數(shù)據類型，如Oracle中的LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可實現(xiàn)用戶自定義表、字段進行復制；應答：滿足。物理Data Guard支持Oracle中所有的常用數(shù)據類型l 支持對數(shù)據庫中常用DDL操作的復制；應答：滿足。物理Data Guard支持Oracle中常用DDL的操作復制。l 支持事務復制，要求對數(shù)據庫中較大的事務不會出現(xiàn)過多延遲；應答：滿足。物理Data Guard支持事務復制。對較大事務不會出現(xiàn)過多延遲。l 支持沒有PK/UK字段的表的同步。應答：滿足。物理Data Guard支持沒有PK/UK字段的表的同步。l 數(shù)

41、據復制過程可根據需要靈活地進行控制或修改復制的方向，以滿足業(yè)務需求；應答：滿足。Data Guard可以靈活地控制主、備節(jié)點的swithover切換。l 支持在數(shù)據復制過程中對數(shù)據正確性進行校驗，如正在復制的數(shù)據在之前就已經不一致，應提供報警功能，以便及時發(fā)現(xiàn)錯誤，避免錯誤的擴大；應答：滿足。物理Data Guard復制的前提條件是主、備數(shù)據庫保持一致，因此不會出現(xiàn)復制的數(shù)據在之前已經不一致的情況。l 提供專用圖形化集中管理軟件。應答：滿足。Data Guard Broker與OEM可以提供很方便的圖形化集中管理。3.5.4 性能要求l 數(shù)據庫初始化同步要求數(shù)據庫復制軟件能夠將發(fā)卡系統(tǒng)的數(shù)據庫

42、中已有數(shù)據初始化同步到災備中心數(shù)據庫。在初始化同步過程中，業(yè)務不能停止，但可選擇業(yè)務量較小時段進行。在解決方案書中要求詳細描述初始化數(shù)據同步解決方案，以及整個首次同步操作所需要的時間（以100GB數(shù)據為標準），并且要求列出整個首次初始化過程中是否需要人為干預，從而可以有效地評估整個首次數(shù)據初始化的工作量。為了保證生產中心日后業(yè)務擴展存在更換服務器廠商以及數(shù)據庫版本等情況，需要注明是否支持異構平臺下的首次數(shù)據初始化同步，是否支持跨數(shù)據庫版本之間數(shù)據庫的初始化同步操作。應答：滿足。詳見Data Guard初始安裝步驟l 數(shù)據復制性能指標數(shù)據復制的性能指標與系統(tǒng)平臺、網絡帶寬、應用系統(tǒng)等因素密切相關

43、，參照下列運行環(huán)境：項目配置數(shù)據源SF15K 24個CPU，32GB內存， ORACLE 10.2.0.2 RAC目標端SF15K 24個CPU，32GB內存， ORACLE 10.2.0.2總數(shù)據量500GB左右（數(shù)據+索引）每天的日志量每天20GB日志網絡帶寬100M和20M要求提供相應的性能參數(shù)指標：類別指標參考值應答首次數(shù)據初始化同步首次數(shù)據庫初始化同步時間（100M帶寬） 小于10小時滿足，首次初始化同步時間小于5小時首次數(shù)據庫初始化同步時間（20M帶寬）小于48小時滿足，首次初始化同步時間小于12小時首次數(shù)據庫初始化同步源端CPU占用小于30 滿足，對主系統(tǒng)資源消耗極小。小于1%增

44、量數(shù)據同步（單個復制鏈路）源端CPU占用小于5滿足，對主系統(tǒng)資源消耗極小。小于1%目標端CPU占用小于5滿足，對目標資源消耗極小。小于5%源端內存占用小于200M滿足，對主資源消耗極小。無需額外內存消耗目標端內存占用小于200M滿足，對主資源消耗極小。無需額外內存消耗復制數(shù)據延遲平均值10s以內不滿足。在最大性能模式下，物理Data Guard在日志切換后將改變的數(shù)據寫入災備中心。頻繁的日志切換將影響數(shù)據庫運行性能。建議將日志切換頻率設置為10分鐘。因此數(shù)據復制最大延遲約為10分鐘。業(yè)務高峰期對系統(tǒng)的影響源端CPU占用小于10滿足，對主系統(tǒng)資源消耗極小。小于1%目標端CPU占用小于10滿足，對

45、目標資源消耗極小。小于5%復制數(shù)據延遲平均值10s以內不滿足。在最大性能模式下，物理Data Guard在日志切換后將改變的數(shù)據寫入災備中心。頻繁的日志切換將影響數(shù)據庫運行性能。建議將日志切換頻率設置為10分鐘。因此數(shù)據復制最大延遲約為10分鐘。3.5.5 數(shù)據一致性要求數(shù)據庫復制軟件提供數(shù)據庫初始化同步、數(shù)據恢復后以及日常的數(shù)據一致性檢查方案，要求方案中詳細注明該數(shù)據一致性比對方案的特點以及操作復雜度，并可滿足如下要求：l 可在應用不停機的情況下，查找和發(fā)現(xiàn)不一致的數(shù)據；l 一致性檢查需要能夠進行對象屬性、記錄條數(shù)和記錄的字段內容進行一致性檢查；l 提供全庫的記錄級一致性檢查時間（以100G

46、B的數(shù)據為例）。l 支持不含PK/UK字段的表的一致性檢查和修復。請?zhí)峁┰跊]有PK/UK字段的表中有1000萬條記錄的比對時間。對于不一致的數(shù)據，需要提供不一致記錄詳細信息，以便進行精確的修復，同時提供數(shù)據修復方案。數(shù)據修復工作要求操作簡單，修復速度快，且修復過程中不影響業(yè)務正常運行。應答：滿足。Data Guard實現(xiàn)的基本原理既：通過備份恢復的基本原理保持災備數(shù)據庫與主數(shù)據庫的一致。只有主數(shù)據庫可以修改，備數(shù)據庫是不能夠做任何改動的。當系統(tǒng)發(fā)生Switchover的切換以后，主備關系變化，同樣只有主數(shù)據庫（原來的備數(shù)據庫）可以修改，備數(shù)據庫（原來的主數(shù)據庫）是不可以修改的。因此Data G

47、uard不存在查找和發(fā)現(xiàn)不一致的數(shù)據的問題。如果備數(shù)據庫做了相應修改，那么數(shù)據復制的基礎被打破，數(shù)據復制將無法繼續(xù)進行，需要重新構建災備中心數(shù)據庫系統(tǒng)。3.5.6 系統(tǒng)兼容性數(shù)據庫復制軟件應支持以下操作系統(tǒng)平臺：l Sun Solaris 9,10l IBM AIX 5.x數(shù)據庫復制軟件應支持Oracle 9i，Oracle 10g，Oracle 11g及后續(xù)數(shù)據庫版本；支持異構平臺，源端和目標端不同數(shù)據庫版本；支持Cluster/HACMP和RAC模式，并支持不同操作系統(tǒng)下不同數(shù)據庫版本之間的復制。應答：部分滿足。Data Guard支持Sun Solaris 9,10以及IBM AIX 5.xData G