㈠ 資料庫同步軟體和資料庫復制的區別
資料庫同步偏重於數據的同步，包括歷史數據及實時數據變化同步。用於業務數據共享或集成需求，支持異構資料庫同步（如sql Server同步到Oracle、Oracle同步到DB2）。
資料庫同步軟體如OGG、BeeDI。
資料庫復制偏重於資料庫整體結構內容復制，包括DDL及DML操作。一般用於災備或讀寫分離環境，僅用於同構資料庫。
資料庫復制軟體如DG、Beep。
㈡ 怎樣利用Oracle golden gate 分發資料庫同步消息至ActiveMQ
怎樣利用Oracle golden gate 分發資料庫同步消息至ActiveMQ
Oracle golden gate是甲骨文推出的一款資料庫同步軟體，可以實現異構資料庫之間的亞秒級同步，它不僅僅支持Oracle，還支持Mysql和一些業界常用資料庫。Ogg可以自動抽取表級數據的動態變化，直接將同步信息作用於目標資料庫。
㈢ dop是什麼
DOP技術
背景
從上世紀90年代末開始，IT界就開始重新審視大型、復雜信息系統的架構問題和信息化的技術策略問題。其主要的驅動力來自企業對信息共享、實時協同（Collaboration）、流程重構等需求的快速增長，跨企業甚至大規模區域協同信息化市場的形成，而傳統信息系統的架構、設計和開發模式明顯不能適應這些新型應用的規模和復雜性。ERP（Enterprise Resources Planning）在推動企業信息化發展的進程中扮演了重要的角色，但大型ERP項目的失敗率高達40%，在一些業務邏輯復雜、具有大量遺存異構系統的應用領域很少有成功案例；英國醫療信息現代化項目嚴重超時、超預算，被稱為IT史上的災難等客觀現實從一個側面反映出傳統信息技術和軟體架構技術在復雜應用領域的局限性。
大量遺存（Legacy）信息系統的異構性（Heterogeneity）和由此引起的信息孤島（Information Island）問題是造成這些新型應用項目復雜性高、風險大主要原因之一，也是企業、跨企業復雜應用領域的共性問題。其次，跨企業、跨區域等復雜應用領域業務流程復雜多變，信息共享、互聯協同等需求導致業務邏輯復雜化、信息表達的復雜性大幅增高也是這類新型應用領域的普遍問題。傳統的軟體技術架構、各種通用的中間件和企業級軟體開發平台、甚至包括近年來倍受關注的SOA（Service Oriented Architecture）、Web2.0等技術也未能對上述共性問題提供有效的技術解決路線。醫療健康行業信息化所面對的挑戰、絕大多數解決方案成本高、風險大、需求滿足度低、不能適應長遠發展等問題反映了這一領域的現狀。
DOP（Domain Operating Platform），也稱為領域操作平台，就是在這樣的背景下形成的。
DOP技術理念
[傳統的垂直分割技術路線]
傳統的垂直分割技術路線
按照傳統系統軟體和應用軟體的定義，無論是信息孤島問題，還是新型應用領域業務流程、業務邏輯、信息表達復雜性問題，都屬於「應用軟體」 范疇。而傳統的應用軟體架構基本上都遵循對問題域垂直分割的技術路線。如右圖所示，應用系統基本上都是獨立地架構於系統軟體平台之上，應用系統通常都有獨立的資料庫、業務邏輯層、用戶界面等垂直而封閉的架構。即便信息技術一直在不停地進化，甚至像互聯網技術等革命性技術的沖擊、企業軟體平台、中間件等技術的普遍應用，這一基本格局並沒有根本性的動搖。恰恰是這一傳統的技術路線，製造了如今普遍存在於各行各業的信息孤島現象。
信息孤島之所以成為一個難以解決的問題是由於應用系統的異構性（Heterogeneity）。所謂異構是指不同的應用系統，架構於不同的硬體、系統軟體平台，採用了不同的系統架構、不同的編程語言、不同的資料庫等。更為關鍵的是不同產品在表達相同領域概念、業務邏輯的時候，可能採用完全不同的表達方式，也就是在數據模型和數據層面的異構。當共享、整合、協同成為企業信息化的主流需求時，系統異構造成的信息不能互通共享、系統間不能協同互操作的問題就突顯出來。
系統異構和信息孤島問題並非新問題，各種基於互聯（Interconnection）和數據交換（Data Exchange）等集成手段已存在了幾十年。只是由於信息孤島經過長期累積，而今天的主流需求發生根本改變的情況下，問題由量變到質變，發展為新型企業級和區域規模信息化的主要障礙。當基於互聯或數據交換的集成技術要對付成百上千異構系統的集成的時候，項目的成本、功能、性能、質量、運行和維護都成為風險很高的問題。如果繼續堅持這一傳統的技術路線，其結果只能是信息孤島越來越多，互聯集成越來越復雜。
隨著共享、整合、協同成為企業信息化的主流需求，業務邏輯、信息表達復雜性可能成倍增高。特別是像醫療健康領域等知識密集型應用領域。醫療健康信息系統復雜性表現在很多方面，最典型的是系統所涉及的信息的復雜性。一個現代臨床醫學中心覆蓋幾十種臨床醫學學科，其信息系統涉及三十萬以上的醫學概念和專用詞彙，醫學概念間的相互聯系不下百萬，業務邏輯多不勝數，業務流程復雜又極具個性化，更為復雜的是，醫學知識、概念、流程和方法由於醫學研究的發展、新技術的出現持續不斷地更新，這些復雜性是導致醫療健康領域信息化程度顯著落後於其它領域的重要原因之一。
[DOP技術原理]
DOP技術原理
綜合上述分析結果，如果延續傳統的系統軟體和應用軟體的劃分模式，堅持傳統應用軟體架構和發展的思維定勢，信息孤島問題的解決將陷入一個怪圈，而應用領域業務邏輯、知識表達的復雜性也難以解決。鑒於上述兩個核心問題的症結基本都集中在信息模型和數據層，DOP首先提出將系統軟體的邊界向上擴展到傳統應用領域的數據層，但這一新的「系統軟體」 的適用范疇縮小到一個特定應用領域。換句話說，在傳統的應用軟體和系統軟體中間增加一個數據模型和數據層一體化（Unifying）的數據和應用服務平台，這個平台就是右圖所示的DOP，針對於一個特定應用領域的系統支撐平台。
DOP的技術理念可以簡單概括為：
（1）從數據層面和數據建模入手，通過技術創新從根本上削弱大型復雜軟體應用領域的復雜性；
（2）將操作系統的理念和技術向上擴展到傳統應用軟體的數據層，將適用范疇縮小到一個特定應用領域，將系統設備管理擴大到應用領域的常用設備；
（3） 通過領域數據一體化整合異構信息孤島，逐漸消除信息孤島產生的溫床；
（4）支持獨立於應用軟體系統的一體化數據層（Unified Data Layer），使得數據和具體應用軟體松耦合，新的應用系統可以架構在一體化數據層上，使數據的生命周期和具體的應用系統脫鉤；
（5）將特定應用領域信息系統中重復、可共享的部分從傳統應用系統中剝離出來，從而進一步削弱企業級系統的復雜性。
DOP技術核心
DOP的技術核心可以簡要地歸結為：一個新的建模體系（包括方法學，實現技術，工具軟體，應用軟體框架等） 兩個核心引擎（模型引擎、數據引擎）和一系列核心功能和服務模塊。
MDT建模體系
[領域動態建模原理]
領域動態建模原理
DOP 的領域動態建模體系，也簡稱為MDT(Meta Data Type)建模是DOP的創新技術之一。MDT建模體系主要由模型引擎、MDT建模及模型管理服務、MDT建模工具軟體（MDT Designer, MDT Browser）等構成。具體細節可參見相關文檔。
DOP的領域動態建模技術是在二階建模（Two-Level Modeling) 技術基礎上的再創新。所有的傳統模型，包括應用廣泛的關系資料庫的模型，面向對象（Object Oriented）模型等都是所謂的一階靜態模型。由於一階模型和數據緊耦合的特點，對模型的修改往往牽一發而動全身，在小型軟體系統中，其影響並不顯著，但對於大型一體化數據整合，涉及大量異構應用系統的集成，復雜的業務流程，在系統分析和設計階段，系統分析師和架構師須花費至少70%的時間與領域專家進行交流和溝通，如果涉及很多異構系統供應商的話，常常使得這類的項目成為風險大、難協調、難管理、質量難保證的多難項目。右圖簡要描述了領域動態建模的原理。
DOP的領域動態建模技術實現了如下幾個目標：
（1）用類似於應用領域的自然語言來描述信息模型，即領域概念直接用簡單易懂、所見即所得的 MDT來表達。直接由領域專家主導建模，省去大量交流時間，避免最易出錯的環節；
（2）領域概念建模和數據松耦合是實現動態建模，或所謂後建模的關鍵。這一動態特性使復雜應用領域模型具有進化能力，是削弱一階靜態模型牽一發而動全身問題的關鍵；
（3）DOP通過完整的建模、模型管理、數據管理體系自動生成和管理物理模型，屏蔽了從概念／邏輯模型到物理模型的人為干預環節，避免人為解讀／翻譯造成的信息模型異構；
（4）領域概念模型獨立於任何資料庫和編程語言，使得信息模型完全開放成為可能；
（5）領域概念模型可以攜帶實用的信息和知識，是知識建模的基礎；
（6）可交叉支持各種國家、國際標准。
基於領域概念建模、一體化數據層的軟體平台實際上是開創了一個新的軟體領域。下表對領域動態建模和其它常用的建模技術作了一個簡要的比較：
可比性 資料庫E-R模型 面向對象模型 動態MDT建模
建模主角 資料庫建模專家 UML/OO專家 領域專家
適合應用領域 傳統應用系統 傳統應用系統 一體化（Unified）企業或行業應用
小模型復雜性 低 低 不高，但沒有優勢
復雜應用領域建模復雜性 隨領域概念數量和業務邏輯的復雜性增加而指數式增高 隨領域概念數量和業務邏輯的復雜性增加快速增高，比E-R模型低 特別適合復雜應用領域建模，即便非常復雜的應用領域，仍可保持線性復雜性
知識模型支持 不適合 可以攜帶知識 非常容易數據模型關聯相關知識，但仍然不屬於語義網類知識建模
開放性 封閉模型 可以構建參考模型 完全可開放
可進化性 很困難 困難 目前最好的可進化性
兩個核心引擎
DOP的內核是由實現領域動態建模體系的模型引擎、基於MDT模型的數據管理引擎及相關的輔助服務和管理模塊構成的。
[DOP的兩個核心引擎]
DOP的兩個核心引擎
如右圖所示，模型引擎是領域動態建模體系的核心。它實現了MDT屬性模板管理、MDT對象創建管理、數據物理模型的創建和管理、物理模型和MDT 模型映射。同時，模型引擎負責DOP運行支持（Runtime）的數據和模型的映射。換句話說，數據的意義需要和相應的MDT相結合、通過數據引擎和模型引擎的「恢復」 才有意義。這一機制具有內在的安全性。通過特別的建模，DOP可以用於對數據安全要求極高的應用領域。因為，通過網路截取數據，甚至侵入到DOP數據中心，如果沒有獲得相應的MDT模型，或沒有模型引擎和數據引擎的支持，那些數據可能沒有任何意義，也不可能通過任何解密手段破譯。
數據引擎是DOP運行支持（Runtime）系統的核心。和其它企業級軟體平台和中間件不同，DOP實際上「接管」 了目標應用領域的數據層，包括一體化數據／信息模型、數據、各種數據操作服務調用。從這各角度來看，DOP更接近於一個新型資料庫系統。
數據引擎支持獨立於關系資料庫、獨立於文件系統的海量數據存儲管理。數據引擎也是分布計算、數據緩存、異構系統數據集成、數據中心間實時數據同步的核心。
作為DOP內核，除MDT建模體系、兩個核心引擎外，還有多個核心支撐模塊和服務，比如細粒度一體化數據安全管理體系等。具體請見相關技術文檔。
㈣ 資料庫同步，同步表和同步資料庫的區別
表同步偏重於數據的同步，包括歷史數據及實時數據變化同步。用於業務數據共享或集成需求，支持異構資料庫同步（如SQL Server同步到Oracle、Oracle同步到DB2）
表同步軟體產品工具 如OGG、BeeDI
庫同步偏重於資料庫整體結構內容復制，包括DDL及DML操作。一般用於災備或讀寫分離環境，僅用於同構資料庫 （如Oracle同步到Oracle、DB2同步到DB2)
庫同步工具軟體產品工具 如ODG、Beep
㈤ 如何進行異構資料庫同步
資料庫同步有很多方法,這里不討論了,我這里只針對異構資料庫.那什麼是異構資料庫呢,我們先看下定義(引用)
異構資料庫系統是相關的多個資料庫系統的集合，可以實現數據的共享和透明訪問，每個資料庫系統在加入異構資料庫系統之前本身就已經存在，擁有自己的DMBS。異構資料庫的各個組成部分具有自身的自治性，實現數據共享的同時，每個資料庫系統仍保有自己的應用特性、完整性控制和安全性控制。異構資料庫系統的異構性主要體現在以下幾個方面：
計算機體系結構的異構
各個參與的資料庫可以分別運行在大型機、小型機、工作站、PC或嵌入式系統中。
基礎操作系統的異構
各個資料庫系統的基礎操作系統可以是Unix、Windows NT、 Linux等。
DMBS本身的異構
可以是同為關系型資料庫系統的Oracle、 SQL Server等，也可以是不同數據模型的資料庫，如關系、模式、層次、網路、面向對象，函數型資料庫共同組成一個異構資料庫系統。
在轉換的過程中，有時要想實現嚴格的等價轉換是比較困難的。首先要確定兩種模型中所存在的各種語法和語義上的沖突，這些沖突可能包括：
命名沖突：即源模型中的標識符可能是目的模型中的保留字，這時就需要重新命名。
格式沖突：同一種數據類型可能有不同的表示方法和語義差異，這時需要定義兩種模型之間的變換函數。
結構沖突：如果兩種資料庫系統之間的數據定義模型不同，如分別為關系模型和層次模型，那麼需要重新定義實體屬性和聯系，以防止屬性或聯系信息的丟失。
異構資料庫同步的解決方法主要有以下幾種:
1.建立觸發器記錄表的變化情況,在源資料庫建立增、刪、改觸發器,然後根據變化登記表進行處理.優點是充分結合業務進行處理,保持數據的一致性、完整性，實時性較強，對多個數據源合並有非常大的優勢，我們現在也是採用這種方式來同步的。
2.日誌：通過分析源資料庫日誌，來獲得源資料庫中的變化的數據。ORCLE 的 非同步 CDC (Asynchronized CDC) 就是使用這種方式，但缺點是有一定延時.
㈥ DataX框架的設計、運行原理詳解
什麼是DataX
DataX 是阿里巴巴開源的一個異構數據源離線同步工具，致力於實現包括關系型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構數據源之間穩定高效的數據同步功能。
方法/步驟
DataX的設計
為了解決異構數據源同步問題，DataX將復雜的網狀的同步鏈路變成了星型數據鏈路，DataX作為中間傳輸載體負責連接各種數據源。當需要接入一個新的數據源的時候，只需要將此數據源對接到DataX，便能跟已有的數據源做到無縫數據同步。
框架設計
DataX本身作為離線數據同步框架，採用Framework + plugin架構構建。將數據源讀取和寫入抽象成為Reader/Writer插件，納入到整個同步框架中。
Reader：數據採集模塊，負責採集數據源的數據，將數據發送給Framework。
Writer：數據寫入模塊，負責不斷向Framework取數據，並將數據寫入到目的端。
Framework：用於連接reader和writer，作為兩者的數據傳輸通道，並處理緩沖，流控，並發，數據轉換等核心技術問題。
運行原理
① DataX完成單個數據同步的作業，我們稱之為Job，DataX接受到一個Job之後，將啟動一個進程來完成整個作業同步過程。DataX Job模塊是單個作業的中樞管理節點，承擔了數據清理、子任務切分(將單一作業計算轉化為多個子Task)、TaskGroup管理等功能。
②DataXJob啟動後，會根據不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便於並發執行。Task便是DataX作業的最小單元，每一個Task都會負責一部分數據的同步工作。
③切分多個Task之後，DataX Job會調用Scheler模塊，根據配置的並發數據量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的並發運行完畢分配好的所有Task，默認單個任務組的並發數量為5。
④每一個Task都由TaskGroup負責啟動，Task啟動後，會固定啟動Reader—>Channel—>Writer的線程來完成任務同步工作。
⑤DataX作業運行起來之後， Job監控並等待多個TaskGroup模塊任務完成，等待所有TaskGroup任務完成後Job成功退出。否則，異常退出，進程退出值非0
㈦ 比較好用的資料庫同步軟體又哪些
可以試試DBSync，主要特點：
●獨立運行
不需要在資料庫中設置程序或腳本，不需要更改庫結構，是一款獨立的應用程序，因此不影響現有系統的運行，簡單易用。
●支持各種數據源
既支持常規資料庫，如Access、SQL Server、Oracle、MySQL、DB2等，又支持Excel、txt、csv等文件數據，任何可用OLE DB或ODBC連接的數據，均可參與同步。
●異型資料庫同步
既支持相同類型資料庫之間的同步，如Access到Access、SQL Server到SQL Server，又支持異型資料庫之間的同步，如Excel到Access、Access到SQL Server、SQL Server到Oracle等。
●無人值守同步
軟體具有定期自動同步的功能，只需預先設置好時間間隔，就可長期自動同步；支持系統重啟後自動繼續同步，防止意外關機重啟而造成同步中斷，從而實現無人值守同步。
●支持增量同步
既支持簡單的全部復制式同步（Insert），又支持增量同步。軟體能快速掃描資料庫，找出相互間的差異（即增量），只對增量進行同步。
●支持斷點續傳
當同步中斷後，再次同步時能從中斷位置繼續同步，避免每次都需要從頭開始。
●秒級實時同步
重復同步的時間間隔最短可設置為1秒，源資料庫發生變更後，1秒後就同步過去，幾乎等同於實時同步。
●支持同步後處理
可設置同步後的SQL執行語句，實現同步之後的數據轉換、公式計算等額外任務。
㈧ 怎樣利用Oracle golden gate 分發資料庫同步消息至ActiveMQ
利用Oracle golden gate 分發資料庫同步消息至ActiveMQ 引言
Oracle golden gate是甲骨文推出的一款資料庫同步軟體，可以實現異構資料庫之間的亞秒級同步，它不僅僅支持Oracle，還支持Mysql和一些業界常用資料庫。Ogg可以自動抽取表級數據的動態變化，直接將同步信息作用於目標資料庫。然而，在某一些場景之中，我們並不需要將同步信息直接作用於目標資料庫，而是將其保存在隊列中，然後在隊列中取出這些信息，完成一些下游系統的業務需求，這樣可以讓增量同步更加靈活。本篇文章主要講述如何，配置Ogg來抽取源表的同步信息生成trail文件（Ogg專屬同步文件），並利用分發器讀取trail文件，適配成可以解析的xml，將其作為消息發送給隊列。本文將不再講訴一下關於安裝的步驟，直接上干貨。
OGG數據同步的重要概念 oracle歸檔和日誌
Oacle歸檔模式是ORACLE熱備份的必要條件，特別是7X24生產的資料庫。可以這么認為：歸檔日誌是增量同步的數據源，因此必須開啟。可以通過下面的的指令查看是否開了歸檔：
SQL> archive log list
Ogg抽取進程
開啟了歸檔和日誌，ogg就有數據源來獲取同步信息。而具體的工作是由Ogg抽取進程
㈨ GoldenGate在異構環境下的資料庫備份
表結構不同好像不能同步數據吧
最好是源端備份一下然後到目標端恢復一下 使源庫和目標庫一致後再整golden gate同步數據
有條件的話整個dataguard做備份更方便主庫出故障切換一下就o了
㈩ etl是什麼
ETL，是英文Extract-Transform-Load的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。ETL一詞較常用在數據倉庫，但其對象並不限於數據倉庫。
數據倉庫是為企業所有級別的決策制定過程，提供所有類型數據支持的戰略集合。它是單個數據存儲，出於分析性報告和決策支持目的而創建。 為需要業務智能的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。
ETL是將業務系統的數據經過抽取、清洗轉換之後載入到數據倉庫的過程，目的是將企業中的分散、零亂、標准不統一的數據整合到一起，為企業的決策提供分析依據， ETL是BI（商業智能）項目重要的一個環節。
(10)異構資料庫同步軟體擴展閱讀：
ETL與ELT：
ETL所描述的過程，一般常見的作法包含ETL或是ELT（Extract-Load-Transform），並且混合使用。通常愈大量的數據、復雜的轉換邏輯、目的端為較強運算能力的資料庫，愈偏向使用ELT，以便運用目的端資料庫的平行處理能力。
ETL（orELT）的流程可以用任何的編程語言去開發完成，由於ETL是極為復雜的過程，而手寫程序不易管理，有愈來愈多的企業採用工具協助ETL的開發，並運用其內置的metadata功能來存儲來源與目的的對應（mapping）以及轉換規則。
工具可以提供較強大的連接功能（connectivity）來連接來源端及目的端，開發人員不用去熟悉各種相異的平台及數據的結構，亦能進行開發。當然，為了這些好處，付出的代價便是金錢。