近幾年來, 隨著IT技術的不斷進步, 以及業務需求的不斷提高, 很多企業都采用了分布式技術, 而數據同步就是分布式技術中的一個重要內容。本文著眼于Oracle數據庫, 簡單說明其自帶的數據同步技術特性, 及適用的工作場景。
1 Oracle數據同步技術
1.1 Standby/Data Guard (備用數據庫/數據保護)
Oracle從7.3開始支持備用數據庫 (Standby Database) , 7.3.x及8.0.x時需要手工拷貝所有歸檔并手工同步, 8i開始實現異步同步 (當時也被稱為Automated Standby) , 自Oracle 9i開始, 備用數據庫被數據保護 (Data Guard) 取而代之, 成為一個集日志的缺失偵測、自動傳輸、自動應用三大功能為一體的數據同步體系架構;也就是從9i開始, Data Guard開始采用LGWR (LGWR同步) /LNSn (LGWR異步) 傳輸日志, 而不僅僅是之前的ARCH傳輸, 在此基礎之上, Oracle開始支持3種不同的數據保護模式。
在9i R2之前, 備庫均是通過重演來自源庫的重做日志 (redo apply) 達成數據同步, 這樣源備庫在數據塊級是一致的, 這樣的備庫被稱為物理備庫 (Physical Standby) ;進入9i R2后, Oracle引入Logminer技術, 在備庫反向解析收到的源庫重做日志, 形成SQL語句, 然后重新執行解析出的SQL (SQL Apply) 從而達到數據同步的目的;此時備庫與源庫在邏輯上是一致的, 但在物理層面上 (如數據段的存儲子句等) 可以不一樣;通過重演SQL同步的備庫被稱為邏輯備庫 (Logical Standby) 。
物理備庫與邏輯備庫均可用于查詢, 但也有不同點:物理備庫在查詢時必須只讀打開, 此時可接收日志但不能應用;而邏輯備庫應用SQL時必須打開數據庫, 除了可以對受保護的對象做查詢外, 也可對其它對象執行DML操作。
在Oracle 10g R2之前, 除非源庫執行了日志切換, 否則備庫就算接收到了日志 (哪怕是備用日志standby logfile) 也是不能立即應用的。而在10g R2之后, 可以實時地應用聯機日志了, 這樣就保證了日志應用的連續性, 進一步縮短了數據同步的時間。到了11g, Data Guard進一步改進了物理備庫:支持備庫在只讀狀態下實時應用日志, 通過這種方式, 可以很簡便地搭建讀寫分離的高可用平臺, 如源庫運行OLTP應用, 備庫則批量生成報表或運行OLAP應用。
數據保護是Oracle推薦用于高可用、災難恢復的數據同步技術, 郵政金融系統災備項目一期即使用了數據保護 (物理備庫) 技術以實現異地災備, 但由于9i中數據保護還不完善, 日志傳輸是使用第三方軟件完成的。
Data Guard的三種數據保護模式如下。
最高性能模式:在不影響源庫的前提下提供盡可能高的數據保護等級, 在此模式下只要日志數據寫入到源庫的聯機日志中, 事務即可提交, 這也是默認的保護模式。
最高保護模式:唯一可確保零數據丟失的保護模式, 但也是對源庫性能影響最大的。在此模式下, 只有日志數據在源庫及至少一個備庫的日志文件寫入成功事務方可提交, 一旦日志數據無法寫到至少一個備庫的日志文件則可導致源庫關閉, 這極大地影響了源庫的可用性, 因此Oracle要求在此模式下, 應該為源庫配置至少兩個備庫。
最高可用模式:此模式的保護性介于最高性能及最高保護兩者之間, 在環境允許時, 其工作方式與最高保護一樣, 但日志數據無法傳輸到任意一個備庫時, 源庫并不會關閉, 而是運行在最高性能模式下, 待相應故障解決并應用完缺失日志后, 源庫自動回到最高可用模式。
Data Guard有如下優點。
*使用免費, 配置及管理較簡單, 工作可靠。
*物理備庫工作在最高保護模式時可實現零數據丟失。
*為主備庫提供了平滑切換 (switchover) 及failover (故障切換) 兩種切換方式, 可提高系統的可用性。
*可指定歸檔路徑的Delay參數延遲備庫上的日志應用, 某種程序上可防止用戶失誤。
*可減少同構環境下數據移植的時間, 如2010年郵政全國中心搬遷等工程中均使用了數據保護技術。
缺點如下。
*日志傳輸對帶寬及時延要求較高, 如使用lgwr同步傳輸則對網絡時延有很高要求, 否則用戶體驗會相當糟糕, 更不可能應用于異地災備。如使用arch傳輸日志, 雖可應用于異地災備, 但如果源庫發生故障, 最少也會丟失當前聯機日志中的內容。
*邏輯備庫不能支持所有的數據類型。
*只能同步整個數據庫, 靈活性較差。
*不支持異構環境, 要求主備庫采用同樣的操作系統及數據庫版本;不過隨著Oracle的版本演進, 這個限制已經逐步減少, 9i可允許源備庫的OS及RDBMS小版本號不同, 10g則允許在部分字節序一樣的OS上 (如均為大端字節序的操作系統) 跨平臺同步, 也可跨大版本號數據庫的同步的同步, 不過這要求備庫的RDBMS版本要高于源庫的版本號 (如10g到11g) 。
*為保證數據的同步, 源庫必須打開強制寫日志功能, 這樣會增加源庫生成的日志量, 之前可通過no logging子句完成的某些操作已經無實際意義, 增加的數據庫的運維壓力。
1.2 Streams (流)
Streams是Oracle9i R2才具有的數據同步技術, 可以將Streams簡單理解為Logminer及AQ (高級隊列) 的結合體。其工作機制為由Logminer將主庫生成的日志解析生成對應SQL, 再通過高級隊列發送到目標庫應用這些SQL。
在引入Streams之前, 數據在異構平臺遷移時, 通常使用實體化視圖 (MV) 、高級復制等技術, 但這樣技術通常會生成大量的日志或是觸發器, 對源庫的壓力較大;而Streams通過捕獲日志, 對源庫的系統壓力相對較小, 如數據庫版本是10g以上, 還可使用異地捕獲 (Down Stream:源庫日志通過源庫的ARCH等進程傳輸到另一個數據庫進行捕獲) 進一步降低系統壓力, 但這樣也會增加網絡開銷。
在Streams早期工作并不穩定, 它的一些進程總會異常關閉, 導致Logminer、隊列表所在的表空間暴漲, 極大的影響了用戶體驗。從10g R1開始, 新增了streams_pool_size參數, 在10g R1之前, Streams Pool默認從共享池中分配10%的空間, 如果它得到的內存過小, 則很容易導致上述故障, 一般建議Streams Pool不小于200M。此外在2010年北京數據庫大會與其它同行交流時也得知, 在實際工作環境中 (多為9i/10g) , 如果應用的日志量過大 (如超過10g) , streams也會頻繁宕進程。
進入10g R2后, Streams進一步支持實時異地捕獲, 即源庫通過LGWR將重做記錄發送到遠程數據庫的備用日志 (Standby Redo Log) , 遠程數據庫從中捕獲相關事務, 這樣既減輕了源庫的壓力, 又減少了源庫與備庫間數據同步的延遲, 但也相應加大了源庫LGWR的負擔, 在工作負荷較大的環境中, 要慎用此技術, 一定要確保網絡的可靠性。
到Oracle 11g, Streams開始支持同步捕獲, 但到目前為止同步捕獲僅支持DML操作。當DML操作發生時, Streams將每行的更改轉變為一個特殊的Row LCR, 它總是保存一行中所有的列值不管它是否發生了變化, 這樣就增加了源庫的系統壓力。
Stream工作步驟如下。
*捕獲 (capture) :由capture進程將redo中的變更記錄根據用戶制定的捕獲規則過濾、組合成一個稱為LCR (邏輯變更記錄) 的消息等待傳播進程處理。當capture進程在源庫上時稱為本地捕獲進程;在另一個數據庫上時稱為遠程捕獲進程。如采用遠程捕獲進程, 則源庫只負責通過arch或lgwr將日志傳輸至捕獲進程所在數據庫。整個捕獲過程又可細分為讀取 (Reader) 、準備 (Preparer) 、構造 (Builder) 三個進程, 它們都有自己的捕獲隊列。
*分段傳播:捕獲進程生成的LCR存儲在隊列中, 再通過高級隊列機制傳播到目標庫的隊列中。
*消費:目標庫的應用進程將LCR取出隊列, 并將其應用于目標庫, 在此過程中, 應用進程也可根據用戶制定的應用規則對LCR進行轉換。
Stream數據同步技術適合于數據分發及共享, 也可在一定程度上代替Data Guard的功能。不過Data Guard是專用容災技術, 它更簡單可靠。但流借助于跨平臺甚至跨數據庫 (異構環境, 如與DB2數據庫同步) 的優勢, 可實現更為復雜靈活的容災。如市場上采用同樣思想的Quest公司的Shareplex在這方面已經有杰出的表現, 在ebay中被廣泛使用以實現數據的水平分割。同類的產品還有DSG公司的Real Sync (已應用于郵政證券) 及2009年被Oracle收購的Golden Gate。
Stream的優點如下。
*高級隊列 (10g之后稱為流隊列) 發送信息的方式有點對點、發布/定閱兩種方式, 因而Stream同步技術可支持“一對多”、“一對多”、“多對一”及“多對多”的復制, 適用于數據共享及分發。
*配置靈活, 與Data G uard不同, Str eam可只復制數據庫中一部分對象, 如單表復制、單用戶復制、單表空間復制甚至是全數據庫復制;并可制定規則在復制過程中進行過濾及轉換。
*支持雙向及多源復制。
*可實現異構平臺下的遷移 (有條件限制, 需與透明網關配合使用) 。
*可實現數據倉庫的ETL過程。
*雙向及多源復制中, 具有自動沖突偵測及解決功能。
缺點如下。
*為保證數據同步, 源庫需要開啟附加日志 (Supplemental logging) , 增加日志生成量, 加大了源庫的工作負荷。
*捕獲進程如在源庫進行, 則增加源庫的工作負荷 (如空間及CPU等) , 如果采用異地捕獲, 則對對網絡的性能及可靠性有高要求。
*配置相對較復雜, 需要較高技術水平。Streams系統開銷相對較大, 介于數據保護和高級復制之間, 不過自10g R2起, Oracle將多個過程封裝到較少的過程中, 簡化了配置工作。
*不是所有的數據類型都支持, 不過從11g開始已經有所改觀, 如支持XML類型、使用透明數據加密 (Transparent Data Encrypt) 技術加密過的數據等。
*在多源鉛制中, 自動沖突偵測及解決需要細心配置, Oracle提供的預定規則無法解決所有需求。
1.3 Advanced Replication (高級復制)
在引入Streams之前, 要實現較為靈活的數據同步時, 除了實體化視圖就是高級復制了。但高級復制配置極為復雜, 對源數據庫性能影響較大的, 實際生產環境中較少使用, 在此只簡單介紹源復制及多源復制的工作機制。
高級復制的工作原理是:在復制對象時, 為復制對象生成一系列的內部觸發器及存儲過程, 在對復制對象進行操作時, 系統通過內部觸發器捕獲相關操作, 如果是異步復制, 則將其保存在延遲事務隊列 (Deferred Transaction Queue) 中, 再通過遠程過程調用 (RPCs) 執行遠程數據庫中的內部過程, 從而完成同步, 異步復制也被稱為“存儲并轉發數據復制” (storeand-forward data replication) 。如果是同步復制, 則情況有所不同, 被捕獲的操作在同一個事務中通過RPC調用遠程庫中的內部過程進行同步, 如果執行失敗, 則此操作在所有源站點上均被回滾, 正因為如此, 此同步方法也被稱為實時數據復制 (real-time data replication) 。
同步復制雖然避免了潛在的復制沖突, 但要求極其穩定的操作環境, 這在現實生產環境中是很難達成的, 因此實時性要求較高的同步環境下, 一般是采用連續推送 (Continuous Pushs) 配置的異步復制也模擬實時同步—方法是DBMS_DEFER_SYS.SCHEDULE_PUSH過程中的interval
2結語
以上簡單介紹了一下Oracle自帶的一些數據同步技術, 并非Oracle同步技術的全部, 如實體化視圖就沒有提及, 高級復制也只是簡單帶過。每個技術的定位都有自己獨特的定位, 某些情況下或可相互替代, 但也都有他們無可取代之處, 用一名話做為本文的結尾:沒有最好的技術, 只有最合適的技術。
摘要：本文探討Oracle數據庫自帶的多種數據同步技術, 并簡單說明其工作原理及優缺點。
關鍵詞：Standby/DataGuard,Stream,Advanced Replication