iStream DDS:目錄,前言,套用領域,

目錄,前言,套用領域,

前言

IStream DDS（以下簡稱DDS），是基於交易的邏輯級oracle數據同步軟體。利用資料庫日誌線上跟蹤、分析技術，將生產資料庫的交易信息以事務為單位，通過異步的方式，實時的傳遞、裝載到目標資料庫中，以達到源端、目標端數據保持一致的目的。是一種準實時同步軟體。

DDS 不依賴硬體的同步能力，支持多種系統平台，具有部署簡單、同步速度快、交易延遲時間短的特點。

DDS能夠支持跨多種Unix/Linux/windows作業系統平台、不同Oracle版本之間的交易同步。

DDS同步的目標資料庫為線上打開狀態，可以隨時復用。

DDS 適用於（異構）熱容災、數據遷移、數據集中、數據分發、分擔業務等套用領域。

套用領域

1.1 生產系統的熱容災

對於大部分公司而言，容災是一項巨大的工程，意味著高額的資金和人力投入。受到傳統同步技術的限制，容災必須擁有專用的硬體支持、專用的傳輸鏈路、容災距離以及系統平台等諸多的限制。此外由於傳統容災系統的不能實時使用的特性，導致不但風險不能評估，而且巨大的投入也可能得不到任何回報。

DDS使用邏輯數據容災技術，傳遞的是交易信息，因此傳輸數據量很小，保證了在低頻寬環境下實現低延遲的Oracle交易異步同步，是一種高效且低成本的資料庫容災方式。DDS使用標準的TCP/IP協定進行通訊，容災端的Oracle資料庫可以部署在本地或遠程容災中心，距離沒有限制。

此外，由於同步的目標端資料庫始終處於打開狀態，因此，當生產資料庫遇到計畫內或非計畫停機時，DDS能夠支持前端應用程式快速的切換到容災資料庫。與其它基於磁碟或檔案系統的物理同步技術相比，不但省略了漫長的資料庫recovery和啟動時間，而且能夠保證100%的切換成功率。

下圖表示交易系統切換後，業務交易在容災系統上繼續執行的示例。

筆記本交易

電腦交易

手機交易

主交易業務系統

主交易資料庫

熱容災資料庫

DDS數據同步

當原生產系統資料庫在恢復正常使用後，可以通過DDS將容災端數據再次同步到源端資料庫中，從而達到互為容災的目的。

下圖表示，原交易系統恢復正常後，容災系統數據同步到原交易系統上的示例。

筆記本交易

電腦交易

手機交易

主交易業務系統

主交易資料庫

熱容災資料庫

DDS數據同步

1.2 分擔業務

DDS基於交易的邏輯級同步技術保證了目標端資料庫始終處於可用狀態，因此除了對於DDS所同步的schema不能進行修改以外，對於同步的schema做數據讀操作、在同步數據基礎上新創建的schema不會對同步本身產生任何影響，因此對於查詢、報表、備份、分析以及與其它業務的接口等業務或套用都可以放在目標資料庫上進行處理。

這些套用也不必在原交易資料庫上爭奪處理資源和時間視窗。生產系統運行和維護的壓力得以釋放，提高了穩定性，而不同的套用在分布的資料庫上也可以進行有針對性的最佳化。

下圖表示在容災系統做業務查詢、報表處理、數據備份、統計分析、與其它業務系統接口等套用的示例。

筆記本交易

電腦交易

手機交易

主交易業務系統

主交易資料庫

熱容災資料庫

DDS數據同步

業務查詢
報表處理
數據備份
統計分析
其他業務系統接口

1.3 數據分發與集中

DDS能夠完成企業範圍內的數據分發，將生產庫的交易數據實時同步到一個或多個本地或異地的資料庫中。也可以將業務數據分發到不同的目標端，實現專機專用。數據分發是一種典型的通過部署多伺服器、多資料庫來分擔負載，提高回響速度的企業套用模式。

下圖表示交易系統的業務數據同時分發到不同目標端的示例。

主交易業務系統資料庫

DDS數據同步

本地容災資料庫庫

本地查詢資料庫庫

異地容災資料庫庫

DDS能夠完成企業範圍內的數據集中，從多個交易數據生產庫實時同步到一個本地或異地的資料庫中。方便用戶查詢，報表列印，為BI提供基礎數據。

下圖表示交易系統的業務數據同時分發到不同目標端的示例。

DDS數據同步

目標端資料庫

主交易資料庫1

主交易資料庫3

主交易資料庫2

1.4 數據遷移

資料庫軟體、硬體升級過程中涉及到的資料庫遷移，是企業經常會遇到的情況，在傳統數據遷移過程中，經常會面臨三個方面的問題：

1.新系統和源系統os平台，oracle版本不同或資料庫字元集不同。

2.遷移時間視窗有限，甚至在某些24X7的業務中無法停機。

3.由於人為因素影響，可能會導致新交易系統部分交易無法正常運行。

針對這三種常見情況，DDS分別對應如下處理機制：

Ø DDS本身支持異構跨平台方式，對於源端和目標端作業系統和oracle資料庫版本不同或者字元集不同的情況均能夠支持。滿足第一種情況

Ø 在遷移過程中業務無需中止，只需在業務切換時中止業務，可以使業務停止時間視窗變得很短，是以分鐘來計算的。滿足了第二種情況。

Ø 目標端資料庫為實時打開，可以驗證遷移是否成功，降低人為因素對遷移過程的影響。滿足了第三種情況。

1.5 雙向同步

隨著跨地域企業的不斷發展，雙業務中心逐漸會成為一種解決龐大業務數據和企業業務回響衝突的一種必要手段。

DDS解決方案如下圖所示：

主交易資料庫2

主交易資料庫1

DDS數據反向同步

DDS數據同步

雙方各自運行各自的業務。雙方產生的業務數據實時的同步到對方資料庫中。從而達到雙業務中心，雙業務數據備份中心的效果。

二． DDS支持的同步特性

2.1 支持的同步對象

DDS支持兩種級別資料庫對象的同步：用戶級同步、表級同步、多表同步

Ø 用戶級同步：

源端資料庫指定用戶及其所包含的表、視圖、索引、過程、函式、包、序列等數據對象全部同步到目標端資料庫指定的用戶下。

DDS支持源端用戶名和目標端用戶名不同的同步方式。

Ø 多表同步：

即group方式，針對多個用戶，每個用戶只同步指定部分表同步的情況。

Ø 表級同步：

表級同步分為單表同步和多表同步

單表同步指定源端資料庫指定用戶下單個表同步到目標端資料庫指定用戶下的單個表。

2.2 支持的同步模式

同步模式主要指源端和目標端的架構模式，具體分為1:1模式、1:n模式、n:1模式、1:1:1模式四種。

1對1的同步模式

目標資料庫

生產資料庫

DDS

n對1同步模式

目標端資料庫

主交易資料庫1

主交易資料庫3

主交易資料庫2

DDS

1對n同步模式

主交易業務系統資料庫

目標資料庫1

目標資料庫2

目標資料庫3

DDS

級聯同步

目標資料庫

生產資料庫

DDS

目標資料庫/生產資料庫

使用者可以根據具體情況選擇或組合以上同步模式到您所需要的套用架構中。

2.3 數據同步方式

DDS支持歷史數據同步、只同步變化數據同步兩種方式。這兩種方式和有效結合或單獨使用。

歷史數據的同步

歷史數據指同步時刻已經存在的數據，歷史數據同步方式分為兩種：

1、快照方式

快照方式利用oracle的select的多版本特性，將歷史數據抓取到目標端，同時可選擇將變化數據實時同步，在歷史數據裝載完成後，再裝載變化數據。歷史數據的抓取與變化數據的抓取之間無縫結合，有業務運行也不影響數據同步的準確性。

相對而言，快照方式同步數據時間長，對於系統資源占有大。

2、讀檔案方式

讀檔案方式指DDS直接讀取oracle數據檔案中的表數據。

相對而言，快照方式同步數據時間端，對於系統資源占有小。但是這種方式抓取歷史數據時，源端系統不能有業務，否則無法保證同步數據的準確性。

變化數據同步

變化數據同步有兩種套用方式：

1、與歷史數據同步方式結合

DDS支持歷史數據與變化數據無縫結合的同步模式，這種方式無需停止業務。

2、單獨同步變化數據。

這種方式是在兩邊數據已經一致的情況下，將某一邊資料庫現產生的交易同步到另外一邊的資料庫中。

2.4 數據定位方式

目標端裝載交易時，對於目標端對應數據（表的記錄）的定位方式分為rowid和where兩種方式。

rowid方式：

Ø 使用rowid同步方式，由於在目標端裝載時直接根據rowid方式定位表紀錄的物理位置，不需oracle再度解析操作直接定位要修改的塊。

Ø 使用rowid方式時，首先必須進行全同步+增量同步結合的模式，後續的增量數據依賴軟體本身全同步操作。

Where方式：

Ø Where方式在目標端裝載數據時，對於目標端對應的數據查找依賴對應表的where條件，對於對應數據的查找速度完全依賴於資料庫本身的查找速度。

主要滿足兩種套用需要：

² 一種跟rowid方式相同，差別在於表的數據不能出現重複紀錄。

² 另外一種方式是只同步變化數據部分。只依賴源端和目標端相關表的數據結構。這種方式採用DDS的只進行增量同步的方式進行。

2.5 分區表特殊處理

DDS軟體同步分區表時，可選擇性的同步分區表的分區。並且DDS可按分區，並發複製分區表。此特性在資料庫中有大分區表時，能極大提高數據同步的效率。

三． DDS的同步原理如圖所示：

DDS軟體同步數據實現分為兩個步驟

1. 歷史數據同步。

2. 增量數據同步。

3.1 歷史數據同步原理

使用快照方式

首次同步時，對於同步map所涉及的每一個表的同步過程如下：

1、鎖該表；

2、記錄同步時刻的SCN(System Change Number)；

3、釋放鎖；

4、讀取該表數據；

在表做開始同步的時刻，鎖表是為了記錄SCN，取這個SCN號時這個表的快照。

開始讀取數據時，利用了oracle資料庫自身提供的“多版本”特性，能夠保證讀取數據的一致性。同時對該表進行解鎖，又使該表被鎖的時間不會太長從而嚴重影響正常交易。

這種方式保證了源端在任何時刻下都可以進行首次數據的批量同步而不會影響同步數據的準確性。

讀檔案方式

首次同步時，對於同步map所涉及的每一個表的同步過程如下：

1、記錄同步時刻的SCN；

2、讀取該表數據；

首次同步時，直接從oracle數據檔案中讀取該表數據，同時記錄同步時刻的SCN，由於這種方式要求在同步過程中，沒有交易產生，因此會保證歷史數據抓取的準確性。在同步完成後，將變化數據實時抓取。

註：首次同步是可以選擇的，如果事先已經保證了兩邊數據一致，則可不選用DDS自帶的全同步功能。直接進行交易變化部分的同步（同步方式只能選擇where方式）。

3.2 增量數據同步原理

如圖所示增量數據同步分為下面四個步驟：

1．交易抓取

Ø DDS通過事先創建的視圖來（sys.x$kccle與sys.x$kcccp的拷貝視圖）捕獲日誌變化，由於每次捕獲的日誌的物理位置都會記錄，因此可以得出日誌變化量。

Ø 後續的抓取日誌、分析交易、傳輸交易，完全由DDS獨自完成，不使用oracle資料庫任何資源。

Ø 在每次抓取的日誌量處理完成後，記錄在DDS的快取目錄中，因此對於日常運行過程中，DDS停止或其它原因需要讀取歸檔日誌時，根據記錄的日誌物理位置來定位需要抓取的歸檔日誌。

Ø DDS抓取日誌跟oracle資料庫是寫日誌是並行操作而又互不影響。

Ø 正常情況下，DDS都是準實時的抓取變化日誌量。

對於源端是rac環境來說：

Ø rac環境中，在每一個實例所在的主機作業系統上可以讀取另外主機的線上日誌（包括歸檔日誌）。通過每一個實例的日誌和SCN（System Change Number）來保證交易順序的準確性。

2．交易分析

嚴格按照源端Oracle資料庫內部SCN執行順序以及已經提交的交易來合成交易檔案，該交易檔案號是依次遞增並且是唯一的，從0開始，交易檔案號的算法跟oracle的SCN算法一樣，可以保證在oracle資料庫正常使用期間，保證DDS能夠正常使用。

DDS只處理已經完成提交的交易，對於回滾操作，DDS不處理該操作。

3．交易傳輸

DDS只傳輸交易內容，不傳輸交易內容的數據結構，採用專有的合成交易檔案格式，只有DDS提供的工具才可以解析交易內容，這樣即證了在網路傳輸過程中數據的安全性又可以保證網路傳輸過程中數據的準確性。

滿足下列三種情況，源端將刪除該交易檔案：

1) 接受的交易檔案號跟源端傳輸的一樣。

2) 接受的交易檔案大小跟源端傳輸的一樣。

3) 接受的交易檔案校驗碼跟源端傳輸的一樣。

4．交易裝載

目標端接受交易合成檔案後，首先存放在快取目錄中，然後嚴格按照從小到大順序進行裝載，裝載的交易檔案不能缺失。否則裝載的進程將一直處於等待狀態，因此無論目標端是rac環境還是單機環境都可以保證裝載的準確性。

這樣就可以保證在目標端裝載過程中，保證按照源端合成的交易檔案順序來裝載。

四． DDS同步的性能

4.1 讀取線上日誌

DDS是直接通過讀取Oracle日誌來分析出交易內容，而不是通過資料庫表來得到，這樣將不依賴資料庫本身的數據內容而直接得到交易信息。從而大大加快了合成交易檔案的速度。

4.2 記憶體中完成交易解析

源端線上日誌的抓取的最新位置是通過查詢資料庫實例sga的動態視圖得到的，這樣不僅速度快而且不會直接影響源端資料庫的物理I/O。

源端歸檔日誌的抓取是直接抓取歸檔日誌內容。也不會影響到源端資料庫的物理I/O。

抓取後的數據，只分析同步用戶或表相關的交易，對於跟同步用戶或表無關的交易直接丟棄。

日誌的抓取、分析、合成大部分情況下都是在記憶體中完成的，只有少數批量交易數據時才會使用快取目錄，這樣就可以儘可能的提高抓取、分析、合成交易的速度。

4.3 只合成已經提交的交易

DDS只合成跟同步用戶或表有關的、已經提交的交易，並且每一個交易的大小不會超過10MB。這樣將大大提高交易檔案的合成速度。

4.4 實時壓縮傳輸

網路傳輸時，首先在源端將交易合成檔案在記憶體中進行壓縮，在目標端接收後在記憶體中完成解壓縮，即：進行傳輸之前先壓縮、目標端接受壓縮交易檔案解壓縮後，存放到相應的快取目錄下。這樣可以大大減少網路流量，從而加快交易合成檔案傳輸的速度。

對於不含有lob類型的欄位，交易合成檔案何以壓縮到10-15%左右。

4.5 通過rowid定址

資料庫修改一條記錄通常依賴索引或全表掃描，這樣操作速度會因為數據量的差別而有明顯的差異。DDS是直接通過rowid對該記錄進行操作的，不會因為數據量的明顯差異使合成的交易檔案中的交易提交速度有明顯的差異。這一點對於海量數據尤為明顯。

4.6 合成交易檔案大小

DDS對每一個合成的交易檔案最大上限為10MB，加上網路傳輸時的壓縮功能，會使網路傳輸速度大大提高。

由於每一個合成的交易檔案最大為10MB，在目標端裝載時的讀取、裝載速度會很快、占用資源會比較少，從而大大加快了每一個交易合成檔案的裝載速度。

4.7 首次同步的性能

對於首次同步而言，無論是快照方式還是讀數據檔案的方式，DDS在源端支持多達16個並行同步、目標端支持並行裝載的模式，這樣可以充分利用主機資源，加快首次同步的速度，減少首次同步對於源端、目標端主機性能的影響。

4.8 增量同步的性能

對於某些情況下，目標節點裝載增量合成交易檔案慢的情況，DDS支持多達32個並行裝載，可以將不同用戶或表的數據放在不同的增量目錄下，實行並行裝載，不過對於表之間有關聯關係的數據（比如外健），就需要將這些有關聯關係的表放在同一個增量目錄下，來保證裝載數據正確性。

在一般交易系統中,軟體正常安裝後,在交易發生時(非清算時間)源端變化同步至目標端時間為2~4秒(交易量大小不超出網路與目標段機器裝載性能所能承載的數值,這一數值與具體硬體與網路環境有關).

註：另外對於一個資料庫，可採用多套DDS同時運行的模式，來對不同業務的不同用戶或表進行有針對性的同步。從而在功能、需求、性能方面有針對性的解決方案。

五． DDS的目標端資料庫可復用DDS通過三個方面來保證目標端資料庫的可復用。

5.1 目標端資料庫始終處於打開狀態

由於目標端裝載是以資料庫的交易方式來提交的，因此目標端資料庫始終處於打開狀態。即在任何情況下目標端資料庫都是可用的。

5.2 交易數據準確

DDS首先通過上述環節來保證交易數據的準確性，包括歷史數據的同步和變化數據的同步。也包含同步過程中涉及到的許可權，具體包括兩個方面，一方面是同步時源端資料庫中已經存在的許可權，另外就是在日常使用過程中，源端資料庫發生改變的許可權。這兩點DDS都能夠支持。

5.3 新產生的數據對於同步無影響

由於目標端始終屬於open狀態，對於下列情況：

1、對於同步業務數據基礎上唯讀操作。

2、新產生的業務數據。

這樣即不會對DDS同步產生影響，也可以衍生很多新的套用。

六． DDS的高可用性高可用性主要體現在RAC或HA環境下的DDS軟體切換主機後能夠繼續運行的情況，在此主要描述源端切換後如何從機制上保證DDS軟體繼續運行。

6.1 採用快取機制

在源端：

Ø DDS_PTRACK 跟蹤到redo log增量信息，將其寫入共享記憶體，並通知 DDS_PMERGE 進行處理，DDS_PTRACK同時將此數據包寫入快取目錄 $DDS_DATA/track 中，以便後續進程沒有成功處理或系統其它異常情況時，這些數據能夠恢復並重新進行處理。

Ø DDS_PMERGE 收到 DDS_PTRACK和DDS_PCLEAN 的通知，將收到的數據包進行各種必要的處理，生成處理後的數據包，將新數據包寫入共享記憶體，並通知 DDS_PCOMM 進行處理。

Ø DDS_PCOMM 收到 DDS_PMERGE和DDS_PCLEAN 的通知，將收到的數據包傳送到目標端系統，如果傳送不成功（目標系統未啟動、網路故障），將數據包寫入快取目錄 $DDS_DATA/comm中。

註：DDS在源端通過抓取、分析合成、傳輸各個環境中的快取機制來保證在軟體因各種原因重新啟動後，只要能夠讀取到相關的快取目錄就能夠繼續正常同步。

6.2 跟蹤日誌

DDS_PTRACK進程的快取檔案中將記錄資料庫實例號、日誌號、所分析到的地址。

無論DDS停止多長時間，只要有相關的資料庫日誌（個別情況下需要相關的歸檔日誌），DDS就可以繼續進行同步了。

對於HA或RAC環境，只要oracle資料庫實例切換後，在切換後的主機上，DDS軟體能夠正常連線資料庫實例、能讀取歸檔日誌、能夠讀寫上一次停止運行時刻的快取目錄，就可以繼續正常同步。因此說DDS滿足了HA或RAC環境下高可用性的需求。

七． DDS的特性

7.1 線上部署簡單、占用資源少

Ø DDS部署非常簡單。對於Unix/Linux以及Oracle熟悉的技術人員參照相關文檔，在10-30分鐘即可部署完畢。

Ø 在源端和目標端資料庫上不創建任何表。

Ø DDS對於每一個同步的用戶或表，只需4條指令完成，並且支持腳本操作，這樣就可以避免多個用戶同步時複雜的指令操作了。對於n個用戶的同步，源端只需要n+3條指令即可完成同步操作。

Ø 增量同步過程中，DDS對於主機CPU資源的占用平均不會超過5%。

7.2 異構跨平台的支持

Ø DDS是以資料庫的交易為單位進行同步、裝載，因此對於不同作業系統上的不同oracle平台環境，DDS均可以支持，。

Ø 對於源端和目標端作業系統，資料庫版本不同的情況也可以支持，當然前提是不同oracle版本之間的schema使用方法要彼此支持。

7.3 一對多和多對一

Ø DDS支持一個源端同時同步多達256個目的節點的同步模式。真正在軟體上實現了一對多的同步模式。大大減少了源端主機資源的占有率。

Ø DDS支持256個目標端同時同步到一個目標端的同步模式，真正在軟體上實現了多對一的同步模式。大大減少了源端主機資源的占有率。

7.4 對部分表重新進行單獨全同步

Ø 在增量使用過程中，有可能會因為某種誤操作導致目標端數據更改，當源端再次對相關部分的數據進行更改時，結果導致DDS將停止這張表的同步。

Ø 對於這種情況，DDS的處理方式是對該表重新進行單獨全同步，同時對於其它正在同步的表或shema不會有任何影響。這樣就避免了因為某一張表的誤操作而需要相關用戶需要全同步的操作。

7.5 定時同步

Ø DDS支持指定時間裝載同步數據到指定時刻交易的功能。不僅可以滿足某些特殊的套用需求而且在某些方面起到了備份的作用。

7.6 實時顯示交易的統計

DDS在目標端運行日誌中：

Ø 顯示每一個合成交易檔案的裝載時間以及延遲時間。

Ø 顯示每一個合成交易檔案的dml數量，包括inert、update、delete數量上的統計。

Ø 顯示每一個合成交易檔案的ddl操作語句。

7.7 字元操作和web操作模式

Ø DDS提供了不僅提供了字元操作模式而且也提供的web監控界面，通過兩種方式都可以對DDS進行日常維護和監控。滿足了不同用戶的使用習慣

Ø 兩種操作模式，DDS均提供了後台服務進程，無須第三方軟體或服務協助。

7.8 數據驗證

靜態數據校驗

Ø DDS提供了靜態數據校驗功能，來確認同步數據的準確性，使用此功能時，會將源端數據全部取出，去目標端進行逐行對比，目標端軟體裝載也將停止，對比的時間與全同步時間相差不多，因此開啟此功能時，源端資料庫不能有數據變化，

WEB對象校驗

Ø DDS 提供了WEB對象對比功能，在源端WEB頁面可隨時發起對比命令（DDS日常監控）,該功能將對比源端和目標端複製的用戶的所有對象存在與否一致的對比，如果不一致，將會把不一致的對象標紅。

DDS Monitor對比軟體

Ø DDS Monitor軟體使用select count(*)原理對比源端和目標端表的記錄數，不一致的表將會顯示並頂置。此軟體不會影響DDS軟體的運行，不過由於select count(*)比較消耗oracle資源，並且源端有頻繁交易時，源端與目標端記錄數並不一致，因此只有在源端資料庫停止變化時對比出來的結果才有意義。

7.9 支持oracle自帶數據導入工具

Ø DDS支持源端oracle自帶的 imp和sqlldr數據導入工具的使用。對於10G中的impdp工具，DDS也提供支持。這樣就不會影響使用oracle技術人員的操作習慣。

八．DDS的健壯性這裡主要列舉了增量同步期間，DDS對於常見的異常情況的支持。

8.1 網路中斷

對於同步期間網路中斷的情況，由於DDS使用了快取機制，因此在網路恢復後將繼續進行同步、裝載。

8.2 源端資料庫重新啟動

對於同步期間源端資料庫重新啟動的情況，由於DDS使用了重試的機制，因此不會因為源端資料庫的重新啟動而重新啟動DDS軟體。

8.3 源端DDS重新啟動

對於同步期間網路中斷的情況，由於DDS使用了快取機制，因此在重新啟動後，DDS將繼續同步。

8.4 目標端DDS重新啟動

對於同步期間源端資料庫重新啟動的情況，由於DDS使用了快取機制，因此在重新啟動後，DDS將繼續同步、裝載合成的交易檔案。

8.5 目標資料庫重新啟動

對於同步期間源端資料庫重新啟動的情況，由於DDS使用了重試的機制，因此不會因為源端資料庫的重新啟動而重新啟動DDS軟體。

九． DDS的軟體體系架構DDS無論在設計上還是實現上都採用了模組化的方式。進程體系跟oracle後台進程相似，分為三部分：

Ø 第一部分是監控、管理進程。

Ø 第二部分是工作進程之間通訊管理。

Ø 第三部分是工作進程

9.1 源端體系架構

DDS源端體系結構圖

源端共享記憶體區主要記錄源端共享記憶體、map參數、信號燈、進程等詳細信息。

源端進程：

Ø DDS_PMONS負責建立共享記憶體、信號燈、訊息佇列，監控系統其它進程的狀態，重起異常退出進程並報告狀態

Ø DDS_PMSGS負責收集其它所有進程報告的各種日誌信息，將這些信息存放到檔案 msg.log中。

Ø DDS_PRECVS負責接收界面傳送來的管理命令並執行,同時也負責全同步時歷史數據的同步。

Ø DDS_PTRACK負責跟蹤資料庫redo log動態增量信息，並抓取變化的redo log塊。

Ø DDS_PMERGE負責將DDS_PTRACK 抓取量信息進行分析、過濾、合成交易檔案。

Ø DDS_PCOMM負責將DDS_PMERGE 合成的交易檔案傳送到目標端。

Ø DDS_PCLEAN負責將 DDS_PMERGE和DDS_PCOMM成功處理的數據包進行清除。

9.2 目標端體系架構

DDS目標端體系結構圖

目標端共享記憶體區記錄目標端共享記憶體、信號燈、進程等詳細信息。

目標端進程：

Ø DDS_PMONT負責建立共享記憶體、信號燈、訊息佇列，監控系統其它進程的狀態，重起異常退出進程並報告狀態。

Ø DDS_PMSGT負責收集其它所有進程報告的各種日誌信息，將這些信息存放到檔案 $DDS_DATA/msg.log中。

Ø DDS_PRECVT負責接收界面傳送來的管理命令並執行，並接收交易檔案到指定的目錄中。

Ø DDS_PPUT負責將裝載歷史、增量信息到資料庫中，並記錄相關信息。也負責數據的比對。

附錄、DDS支持內容匯總

支持總項目	支持項目	支持內容	備註
數據準確（DML部分）	table	Insert/update/delete
數據準確（DML部分）	Partition tables	Insert/update/delete
數據準確（DDL部分）	Table	Create/truncate/drop
	columns	Add/modify/drop
	constraints	Add/modify/drop
	indexes	Create/alter/drop
	views	Create/alter/drop
	sequences	Create/alter/drop
	functions	Create/alter/drop
	Package( body)	Create/alter/drop
	procedures	Create/alter/drop
	Trigger	Create/alter/drop
	Synonym	Create/drop
	Role	Create/drop
	Role	Grant/revoke
數據類型	Oracle自帶類型	Blob/clob/long/bfile	DDS支持所有Oracle自帶數據類型
		Number/ TIME
		Char/varchar2/nvarchar2
	用戶定義類型	USER DEFINED TYPE
平台方面	作業系統平台	Hp/ibm/solaris/linux /windows
	Oracle	Oracle9i/10G/11G
		歸檔/非歸檔
		File/lv/ocfs/asm
特性	同步模式	一對一or一對多or多對一or組合
	同步模式	雙向同步
	同步方式	只全同步or增量or組合
	交易回退	表的dml/truncate/drop
	單表同步	增量過程中，單表全同步
	支持線上初始化	首次同步允許有交易。
	同步對象	用戶、表、組
健壯性	網路中斷	斷點續傳，無人工干預
	目標端停止複製軟體	斷點續傳
	源端停止複製軟體	斷點續傳
	源端資料庫異常	斷點續傳，無人工干預
	目標端資料庫異常	斷點續傳，無人工干預
基本功能	首次同步	讀快照方式/讀檔案方式
	首次同步	多套/並行
	增量同步	並行
	目標端可用
	交易完整性
	Oracle的Exp/imp
	Oracle的sqlload
套用領域	容災
	分擔交易
	一對多or多對一
	雙向
	數據遷移

iStream DDS

目錄

前言

套用領域

相關詞條

熱門詞條