中國民航航空氣象情報數據庫系統（AMIDBS）是在北京、廣州、上海、成都、西安、沈陽、烏魯木齊等民航氣象中心及53個航站的計算機系統中，開發建設而成的中國民航氣象情報分布式數據庫系統，它組織管理全球觀測的與航空有關的氣象資料，以及基於這些觀測資料加工而成的與航空有關的氣象分析產品、預報產品、圖形圖像產品、航空氣象情報等資料，以友好的界面為空中管理部門、航空公司提供便利的、及時的航空氣象服務。
在AMIDBS的各中心和航站每天各自都能獲得大量氣象資料和產品，相互之間（特別是各中心之間）需要交換，另外各氣象中心的資料和產品還需送給位於機場的服務器為各航空公司提供服務。為了實現資料交換和傳輸，采用復制技術是一種明智的選擇。我們在各中心之間采用雙向復制，氣象中心和機場之間采用主從復制，在雙向復制中主點數據只有一個，即北京中心獲得的數據在北京更新並向上海復制，上海中心獲得的數據在上海更新並向北京復制，復制的數據類型有字符數據、實形數、整形數、大文本數據、圖形圖象數據等。下面就數據復制的一般概念、Sybase數據復制技術的特點、組成、命令等作一得簡單介紹，最後給出一簡單的應用實例。
2 . 數據復制的一般概念
數據復制是分布式數據庫技術中的一項重要技術, 其功能是提供對數據冗余的控制與維護。
數據冗余是分布式數據庫的特性之一, 即同一數據在不同的節點有多個復制拷貝, 它是為了適應數據分布、提高系統性能, 減少網絡通信費用、提高應用的有效性而形成的特性。但數據冗余又給保證數據的一致性和完整性增加難度。數據庫界曾一度提出用兩階段提交的分布事務技術來實現數據冗余的控制與維護, 以保證數據的一致性。但這種方式存在兩個嚴重的缺陷, 一是比單節點事務響應太慢, 二是一旦參與分布事務的某個節點有故障或網絡不通, 則會使其它節點也無法繼續處理數據, 從而降低了系統的可靠性。
數據復制技術就是為了克服上述缺點而研究提出的。它將數據復制的物理過程分成兩步, 修改過程和復制過程。對一個數據拷貝進行插入、修改和刪除的過程稱為修改過程, 將修改過的拷貝中的數據復制到其它拷貝的過程稱為復制過程。
目前的數據復制技術根據這兩個過程的進行方式的差異而形成下列兩種復制方式:
(1) 同步復制方式(嚴格一致性方式) 同步復制方式要求修改過程和復制過程同時進行, 即數據所有拷貝在任何時候都應保持一致。這種方式在網絡和各節點的系統十分可靠且操作正常時是很有效的。這種方式基本上是采用兩階段提交的分布事務技術來實現的。
(2) 異步復制方式(松散一致性方式) 異步復制方式允許修改過程和復制過程異步進行, 兩者之間可存在一個時間延遲, 即允許數據的各拷貝之間不立刻一致。如果修改能停下來等到異步復制趕上, 則數據的各拷貝之間就能保持一致。當參與復制的某個節點有故障時, 則那個節點的復制過程暫時停止, 待那個節點恢復正常後再接著進行。
異步復制方式從數據復制機制上分, 有下列兩種不同的復制方法:
·基於事務的異步復制 當一個數據拷貝進行修改時, 將該修改事務復制到其它數據拷貝所在的節點並進行執行, 從而達到數據復制的目的。
·基於數據的異步復制 當一個數據拷貝進行修改的同時, 對變化的數據形成一個復制品, 然後再復制到其它拷貝, 在這種方法中復制的是數據本身。
異步復制方式從等待時間上分, 也有下列兩種不同的復制方法:
·聯機異步復制 當一個數據拷貝進行修改時, 其復制過程也就聯機產生相繼進行, 除非參與的某節點有故障, 則該節點的復制過程由存儲機制進行暫存, 待故障恢復後再進行，其它節點照常進行。
·定時異步復制 當一個數據拷貝進行修改時, 其復制過程不立即進行, 而是到了指定時間後進行。在進行期間某參與節點有故障, 則該節點的復制過程由存儲機制進行暫存, 等待故障恢復後再進行。
3 . 復制技術的體系結構
復制是指將數據從數據源拷貝到一個或多個目標的過程, 復制技術的體系結構體現了數據復制過程中數據源和數據目標之間的關系。從目前的發展情況來看, 有以下三種基本的體系結構:
(1) 主／從結構(master/slaver) 這是最簡單的一種結構。在這種結構中定義一個數據拷貝為主拷貝, 稱為主點數據, 其它的拷貝為副拷貝, 稱為復制點數據。數據更新操作只能在主拷貝上進行, 然後復制給其它副拷貝。
(2) 瀑布式結構(cascade) 這種結構是主／從結構的一個擴展, 它也是由一個主拷貝和若干個副拷貝組成。不同於主／從結構的是它允許每個從屬副拷貝具有復制的能力, 即一個從屬副拷貝可以把接收到的復制數據再傳給下一個從屬副拷貝。
也就是說, 它的復制方法是鏈式的, 如節點 A→B→C……，而主／從結構是 A→B,A→C……。
(3) 對等結構(peer-to-peer) 在這種結構下，所有的拷貝在任何時刻都可以被修改，而且能將修改操作復制給其它拷貝。
比較上述三種結構，主／從結構在管理上最簡便，並能有效地防止修改沖突, 有較高的可用性。但它不夠靈活，自治性也明顯降低，由於修改必須在主點數據的節點機上進行，在使用來自非主點數據節點的修改時，必須將修改命令送給主拷貝節點，執行完成後再將結果復制回去。在這種情況下也將增加網絡開銷。瀑布結構在復制過程中能降低網絡開銷，但它的可用性比較低，因為在復制鏈上任一環節的問題都會引起復制失敗，使其後的所有節點都無法獲得復制數據。對等結構是最靈活的一種結構，它充分體現了分布數據庫的分布特性，各節點有高度自治，可用性好，但它必須在解決修改沖突後才能使復制有效, 然而解決修改沖突的難度較大、算法復雜、系統開銷大, 因而其管理的代價也很高。所以在實際應用中究竟采用哪種體系結構應視實際需要而定。
3 . Sybase 復制技術的特點
4．1 Sybase復制服務器主要采用聯機異步復制方法, 當主表中的主點數據由服務器進行修改維護後, 對主表數據修改的事務在幾秒內傳遞到復制表中。
Sybase復制服務器對數據復制管理的原則如下:
·對於每個參加復制的數據只能有一個主點和多個復制點。
·復制點和主點數據不一致, 以主點為准。
·應盡量減少由於分布傳輸的次序而產生的不一致。
Sybase復制服務器的體系結構以主從結構為主, 但也能支持下列多種體系結構:
(1) 主從結構(一個主點,多個復制點)
·只有主點修改能修改數據, 然後按約定復制到各復制點的復制表中;
·復制表不能修改。
(2) 分布式結構(多個主點, 一個復制點)
·復制點用來接收一個或多個主節點的數據
(3) 對等結構
A (主點更新, 遠程更新主點)
·只在主點更新數據, 然後按約定復制到各復制點的復制表中 ·復制點通過遠程異步事務更新主數據, 然後按約定復制到各點。
B (數據分布, 各為主復)
·主點數據分布在系統的多個服務器中, 但對每個數據而言, 全系統只有一個主點;
·每個主點有自己的數據, 主點更新自己的數據, 然後按約定復制到其它各點。
C (主點更新, 復制點更新, 互為主復)
·主點數據分布在系統的多個主點數據庫中;
·每個主點更新主點數據, 然後按約定復制到其它各點。
·在這種結構中會產生修改沖突, 技術支持的應用程序必須有辦法解決修改沖突。
(4) 聯接結構:
·把兩個主點表的列結合在一起復制到一個復制點表中; 4.2 Sybase復制服務器的其它特性
SYBASE復制服務器是Sybase SYSTEM 10的核心產品, 自1993年10月推出以來, 已為很多用戶所采用, 並備受青睐。這是由於它除了采用聯機異步復制方式和適應多種應用結構外, 還具備下列特性:
(1) 可靠實用
Sybase復制服
由於Sybase復制服務器傳遞事務, 於是也能傳遞存儲過程, 因而提供了一個有效的方法復制異步遠程存儲過程完成復制節點對數據的修改, 從而提高了可用性
(2) 復制獨立
SYBASE復制服務器的每個部份都未采用數據庫系統的特性及功能, 其工作模式是專為復制而設計的技術。Sybase復制服務器的組件如Log Transfer Mansger(LTM)是完全獨立於數據庫工作的, 沒有使用數據庫觸發器及規則, 不會增加源數據庫的負擔, 從而獲得較高的復制性能。
另外, Sybase復制服務器允許管理員選擇網上傳送數據的路由, 從而能更加有效地使用網絡, 加快了事務傳遞, 也提高了復制性能。
(3)支持異構
SYBASE復制服務器允許非Sybase數據源加入復制環境, 異構數據源不僅能充當目標節點, 接受復制的數據和存儲過程, 而且能充當主節點。
Sybase復制服務器的這個特性有利於保護用戶在各種RDBMS 上的投資、數據資源和舊的應用, 同時也可擴充在SQL Server系統方面的新投資。
(4) 本地自治
SYBASE復制系統只傳遞事務到SYBASE或非Sybase數據源, 復制何種數據及復制數據如何使用則由各節點自治決定, 每個節點有權進行下列選擇:
·選擇接受或訪問某個主數據集合(或完全集合);
·設置在本地的表名和列名;
·優化本地數據訪問方式;
4．Sybase的實際應用效果
中國民航北京氣象中心的主從復制試運行已有半年，目前運行穩定，在北京和廣州之間進行了雙向復制的試驗，其結果也是較理想的。主要有如下體會：
·數據復制減輕軟件開發和維護量，特別對於氣象部門的多種硬件平台的分布式數據庫系統，因為氣象部門的入庫數據在入庫前需要進行大量且復雜的預處理，其程序量約有幾萬條指令，使用數據復制技術後，可以只在一個地點和一種平台上開發和維護軟件，其它地點和平台可采用復制；
·數據復制可根據不同用戶的查詢要求，定義復制內容。形成不同的復制點數據庫，減輕主數據庫的負荷，一定程度上加強了主數據庫的安全性，提高了檢索速度；
·在進行復制服務定義前，要根據需求作好全面、詳細、周密的鑽研，才能作出切合實際的復制定義和復制約定；
·主點數據庫的日志文件應根據復制的內容給予足夠大的空間，以防止網絡故障或復制點機器故障造成的復制中斷，引起主點數據庫日志文件被充滿，影響主點數據庫運行的情況發生；
;應監視復制服務器的LTM 進程，及時發現問題，及時處理，以免影響主點數據庫運行；
·對於實時性要求較強的數據，在故障恢復後應清除復制日志文件，否則影響新數據復制的時效。
