基于Oracle數據庫的邏輯數據同步技術在實踐中的應用研究

基于Oracle數據庫的邏輯數據同步技術在實踐中的應用研究

　　摘 要：隨著人們對生活質量要求的提高，隨時隨地的為客戶提供無折扣的服務成為服務行業爭相實現的目標，要實現這個目標，災備系統建設是一個持續的話題;另外，除了越來越大的交易量，隨著用戶查詢需求的增加，數據庫負荷越來越重，甚至無法直接為客戶帶來查詢結果，將災備端數據庫兼用作查詢數據庫實現雙活，又可以起到有效分擔壓力，提高響應速度的效果。數據同步技術是災備系統建設及數據庫雙活的基礎和核心環節，本文介紹了某公司實施基于Oracle數據庫的數據同步案例，并對測試及試運行前期存在的一些問題進行了分析和改進，取得了較好的效果，可以供同類項目參考。

　　【關鍵詞】容災 雙活Oracle 數據同步

　　1 引言

　　1.1 背景

　　伴隨信息化的持續推進，數據的安全和業務運行的可靠性越來越重要，災備系統能為業務系統的高可用性和高可靠性提供有力保障。

　　某公司電話銷售系統是一個全國集中的系統，該系統承擔超過5000座席及全國市縣一級落地業務人員的訪問量，系統規模及壓力大，影響范圍廣，需要建設可靠、穩定、高效的容災體系;并能實現在災備端實時查詢生產數據，分擔生產端壓力。數據同步是實現上述目標的核心及基礎。

　　1.2 研究思路

　　以該企業實施的數據同步項目為案例，介紹了災備體系的基礎架構和基礎環境，在此基礎上選用了合適的數據同步產品，設計了同步方案和策略，經測試和試運行，總結過程中產生的問題，提出了解決方案并付諸實施，對同步過程持續進行監控，對比結果進行總結。

　　2 數據同步技術

　　數據同步技術大致可分為存儲系統層、操作系統層、數據庫系統層同步技術。

　　2.1 存儲系統層數據復制

　　現在的存儲設備經過多年的發展已經十分成熟。特別是中高端產品，一般都具有先進的數據管理功能。遠程數據復制功能幾乎是現有中高端產品的必備功能。要實現數據的復制需要在生產中心和災備中心都部署一套這樣的存儲系統，數據復制功能由存儲系統實現。如果距離比較近(幾十公里之內)之間的鏈路可由兩中心的存儲交換機通過光纖直接連接，如果距離在100公里內也可通過增加DWDM等設備直接進行光纖連接，超過100公里的距離則可增加存儲路由器進行協議轉換途徑WAN或INTERNET實現連接，因此從理論上可實現無限制連接。存儲系統層的數據復制技術對于主機的操作系統是完全透明的，是對于將來增加新的操作平臺，可不用增加任何復制軟件的投資，即可完成實現復制。缺點是由于基于存儲是由存儲硬件廠商提供的，在兼容性方面有局限性。用戶要使用同一廠商的設備，給用戶造成的選擇面太小，成本容易提高，并且對線路帶寬的要求通常也較高。對于預算充足，存儲環境不是很復雜的企業來說，選擇基于存儲的技術比較適合。存儲系統層的數據復制基于同構的存儲，各個存儲廠商都有自己的復制軟件，如IBM PPRC、EMC SRDF、HP Continues Access、HDS TrueCopy等。

　　2.2 操作系統層數據復制

　　主要通過操作系統或者數據卷管理器來實現對數據的遠程復制。這種復制技術要求本地系統和遠端系統的主機是同構的，其實現方式是基于主機的數據復制，容災工作在主機的卷管理器這一層，通過磁盤卷的鏡像或復制，實現數據的容災。這種方式也不需要在兩邊采用同樣的存儲設備，具有較大的靈活性，缺點是復制功能會多少占用一些主機的CPU資源，對主機的性能有一定的影響。目前基于原廠的邏輯卷管理軟件如IBM AIX LVM、HP-UINX MirrorDisk、Sun Solaris SVM等可以實現在本廠平臺上的邏輯卷鏡像，專業的數據復制軟件提供了更大的靈活性，支持多個平臺的邏輯卷鏡像，其中代表性的軟件是Symantec VERITAS Storage Foundation 軟件。

　　2.3 數據庫數據復制技術

　　數據庫數據復制技術通常采用日志復制功能，依靠本地和遠程主機間的日志歸檔與傳遞來實現兩端的數據一致。這種復制技術對系統的依賴性小，有很好的兼容性。缺點是本地復制軟件向遠端復制的是日志文件，這需要遠端應用程序重新執行和應用才能生產可用的備份數據。目前基于數據庫的復制技術主要有：Oracle DataGuard、Oracle GoldenGate、DSG RealSync、Quest SharePlex、九橋DDS等。

　　3 某公司數據同步方案設計

　　3.1 災備體系架構及基礎環境

　　容災體系的目標是實現在線的兩地三中心應用級容災，主生產中心A及同城災備中心C(兼查詢中心)在北京，異地災備中心B在廣東。項目實施分為四個階段，第一階段生產中心A與同城災備中心C的雙向數據同步測試及切換演練;第二階段實現新生產中心A與同城災備中心C(兼查詢中心)及異地災備中心B的雙向數據同步測試及切換演練;第三階段實現兩地三中心上線試運行。

　　兩地三中心的環境情況如下所示：

　　(1) A中心：數據庫主機為IBM P780，AIX6.1，存儲為IBM DS8800，數據庫為oracle10.2.0.5。

　　(2) B中心：數據庫主機為IBM P780，AIX6.1，存儲為EMC VAXe，數據庫為oracle10.2.0.5。

　　(3) C中心：數據庫主機為SUN M9000、Solaris 10，存儲為HP XPS24000，數據庫為oracle10.2.0.5。

　　(4) 同城網帶寬：2*200Mbps。

　　(5) 廣域網帶寬：2*200Mbps。

　　(6) 生產庫數據量：1.6T，日志量：9G/小時(源端生成量)。

　　3.2 數據同步產品

　　基于以上基礎條件，要求使用的數據同步產品在以下幾方面有良好的支持。

　　(1)支持異構的存儲、操作系統和數據庫管理系統。

　　(2)目標數據庫處于打開狀態。

　　(3)支持一對多、多對一，雙向復制等。

　　(4)所占系統資源較少。

　　(5)傳輸的數據量小，對帶寬要求不高。

　　(6)支持無主鍵數據庫表的同步。

　　通過對現有市面產品功能的考察，并基于以上條件進行了初步篩選。存儲層和操作系統層的復制技術不太適合該場景，他們對硬件平臺和操作系統有較為嚴格的限制;Oracle 10g數據庫DataGuard組件不支持同步過程中目標庫打開;Oracle GoldenGate、Quest SharePlex無主鍵表同步性能較差，而系統中無主鍵表數量占比較高。經篩選，確定一款數據庫層的數據同步軟件DDS進行測試。

　　3.3 同步原理

　　基于數據庫層的數據同步需要在源端和目標端各自安裝一套軟件。DDS軟件其工作原理分為歷史數據庫同步與增量數據同步兩個步驟，這個兩個步驟的相互結合可實現oracle數據庫的不停機在線數據遷移。

　　每次同步動作由以下幾個步驟組成：

　　(1) 在源端軟件中配置抓取進程和隊列、傳輸進程，在目標端配置讀取進程、裝載進程和隊列。

　　(2)抓取進程分析源數據庫的日志文件，抓取所需的數據變更操作，將其存儲在自己專有的緩存文件中，放入到抓取隊列。

　　(3)由傳輸進程對抓取隊列文件進行封裝處理，壓縮，將其放入到傳輸隊列中，由傳輸進程將文件通過網絡發送到目標服務器上。

　　(4)目標服務器上的接收進程接收這些文件，根據裝載隊列配置進行拆分，將其放入到裝載隊列中。

　　(5)由裝載進程將這些文件中的變更應用到目標數據庫中。

　　(6)當歷史數據同步完成時，軟件根據歷史同步記載的SCN號，對大于此SCN號的表的事務進行增量加載。從而使目標端數據庫與生產端數據庫始終保持一致，此時，生產業務系統可隨時使用目標端數據庫來頂替原生產數據庫，從而完成了數據遷移的過程。

　　DDS軟件進行數據同步，在以下幾方面有優勢：

　　(1) 通過在目標數據庫的數據裝載方面，不是通過主鍵或唯一鍵來實現數據記錄的定位，而是自己維護一個源數據庫和目標數據庫的數據記錄的rowid mapping表，通過rowid來實現記錄的定位，因此在數據裝載效率方面有不小的提高。

　　(2)對傳輸文件進行壓縮，壓縮比約為1：10，可以大大減少傳輸量，降低帶寬要求。

　　但同時軟件要建立和維護源、目標塊之間的映射列表，當同步數據量越來越大時，映射表也變的非常龐大，讀寫效率隨之降低。

　　3.4 同步策略

　　根據災備體系架構規劃以及同步軟件的特性，基于災難應急流程制定了災備體系的數據同步策略。策略包括四個步驟：正常、生產宕機、生產恢復、生產接管。

　　(1) 正常生產狀態下，在A中心配置兩套獨立的同步策略，同時向B中心和C同步數據。

　　(2) 生產中心發生災難，B中心做為容災中心接管業務，同時斷開三個中心間的數據同步機制。

　　(3) A中心的軟、硬件環境恢復，但業務仍然由B中心接管，同時需要做B中心到A中心的一次數據全同步。

　　(4) 在A中心接管業務后，需要做A中心到B中心和C中心的一次數據全同步。B中心和C中心的歷史數據全部清空，重新從A中心同步過來。

　　3.5 同步效果

　　(1)前期測試，使用loadrunner工具進行壓力模擬，增量同步效果，如表1所示。

　　(2) 試運行期間，同步效果如下：

　　全同步時間3小時13分22秒;增量同步時間，在業務高峰期3499秒;CPU資源占用低于5%，I/O資源占用低于1%，CPU資源占用低于5%;網絡傳輸量是Oracle在線日志增量的十分之一以下。

　　4 問題及分析

　　4.1 問題

　　在設計之初，由于對壓力了解不夠，僅在目標端配置一個隊列進行數據加載，文件順序加載，造成裝載效率低，累計時間延遲高。

　　4.2 解決方案設計及效果

　　針對順序加載的弊端，考慮將裝載隊列拆分為多個隊列，同時啟動多個裝載進程裝載不同的隊列，提高裝載效率。

　　(1) 首先考慮到數據庫存在多個用戶，用戶之間關聯度小，比較適合作為拆分依據。

　　(2) 其次，同一用戶的不同表數據操作類型有差異，部分表數據量執行的DML操作頻繁，部分表幾乎沒有DML操作。執行DML操作頻繁的表，在同步時需要頻繁查找映射表以進行更改，而非DML操作則不需要查表，將DML頻繁的表單獨拆分到一個隊列，有利于減少其他表執行同步的等待時間，提高效率。

　　(3) 再次，部分表之間存在主外鍵關系，這部分表在進行刪除操作時，需要考慮級聯刪除的情形，建議拆分到同一隊列，以保證統一性。

　　(4) 最后，還需考慮在目標端禁用觸發器，避免觸發器引起的重復操作動作。如表2所示。

　　基于以上考慮，將隊列按用戶、DML操作頻繁性、主外鍵關聯等條件拆分為19個裝載隊列。

　　從表2可以看到，通過優化，在數據庫交易數據數及數據庫日志量翻倍的情況下，增量同步時間反而減少至5秒左右，優化取得了良好的效果。

　　5 總結

　　本文簡單介紹了目前主流的數據同步技術，基于某公司現狀及災備需求，選取了數據同步產品，設計了同步策略，給出了測試及試運行期間的同步效果數據;并針對期間出現的問題進行一定深度的分析，設計解決方案，達到了一定的效果，可以供同類項目參考。

　　參考文獻

　　[1]郭偉華.淺談Oracle數據同步技術[J].科技資訊，2010.

　　[2]羅易.存儲數據復制技術在容災系統中的應用[D].重慶大學，2008.

【基于Oracle數據庫的邏輯數據同步技術在實踐中的應用研究】相關文章：

Oracle數據庫的優化03-18

.NET技術的數據庫技術與應用研究11-14

實現基于網頁的數據庫數據導入03-18

基于Web的交互式數據庫查詢技術03-20

基于ＳＱＬＳｅｒｖｅｒ２０００的數據庫性能調整技術03-22

大型ORACLE數據庫優化設計方案03-21

基于PHP的Web數據庫訪問03-19

基于數據庫的JPG圖像處理03-18

基于ASP技術開發Web數據庫檢索程序03-18