【導讀】本等要求一致，且對絡環(huán)境的要求比較高。的配置和設備，比較麻煩。其特點與基于存儲設備的復制方案比較類似，也可以選擇同步或。其目標系統(tǒng)如果要實現可讀，需要創(chuàng)建第三方鏡像。個人認為這種技術和。或者說是保證在異常發(fā)生的那一刻有足夠的緩沖來保障？也就是說，復制的時候起文件寫入順序和oracle的順序一致嗎？形象一點說它的原理可能有點像raid0，就是說它的寫入順序應該和原系統(tǒng)是一樣的。不知道我的理解對不對?？隙〞芯彺嬷袛祿膿p失，也不能100%保證數據文件的一致。一般來說是用這種。二天早上，再把存儲的同步斷掉，然后由另外一臺主機來啟動目標端存儲上的數據庫，件在邏輯上是否一致，所以會造成復制端在停止復制后有很大幾率不能正常啟動。數據庫，但還是有1/3的幾率無法啟動，如果是在原系統(tǒng)發(fā)生故障或斷電的情況下，藏的問題沒有機會暴露出來。

　　

【正文】 盤頭的 tab 應該隔多少時間加一次鎖，然后新的插入寫 cache，所以如果這個時間源端 off 的話， cache 中的數據應該是丟失的（磁盤壞）。 軟件級的復制也一樣，你總有一個隊列來處理 ops/rac 的事務順序，這個隊列有放在磁盤上用文件來排隊的，也有 直接在內存中排隊的，這些也是關鍵的東西。當然像軟件復制這樣的軟件可以通過重新分析日志的方式來彌補，如果磁盤沒有壞的話。 同步絕對就是那樣，每個在 SOURCE 端寫入的東西必須被遠端的存儲設備寫入成功（不一定是寫入磁盤）才返回主機寫入成功，基本可以認為就是一個距離很遠的RAID1。一致性的問題不用擔心，但是帶寬要求等等都是很高的。 異步的方法，在之前很多是不能保證一致的，呵呵。最近據說多了很多能保證一致的方法，就知道 HDS 會吧所有寫記錄到本地一個日志卷， EMC 和 IBM 的方法還沒有弄的很清楚。 看看我們的實際應用 現在介紹我們數據庫同步的成功案例，你們提到的問題都可以解決。 現在我們的數據同步已經投入了實際運行，采用逐步增加表的方式。目前已經同步了149 個表，其中包括詳單表，統(tǒng)計基表等。最大的 6000 多萬記錄，有 16 個超過 1000萬記錄，采用 10 分鐘異步復制。主要有以下特點： 關鍵業(yè)務數據（排出了很多垃圾數據），數據量最小 對生產機影響較小，目前一般只用到 300M 空間 目標端數據不可以修改，完全保證數據一致 初始同步快捷、方便，不需要停止生產系統(tǒng)應用。影響小，只相當如一個 select。 管理 方便、靈活：能夠看到各表上次同步時間；上次同步后又有多少條新數據；上次各表同步耗費多長時間等。 目前每天進行一次 count(*) 檢查，沒有發(fā)現有問題。 我們一前也試用過 dsj 和 shareplex 的產品，從名氣上來說，應該還不錯。具體不是我親自試用的，但最后沒有能夠成功，我想與我們的系統(tǒng)復雜、數據庫本身不是很穩(wěn)定、要求太高有關。 這是一個 24 小時運行的系統(tǒng)，停止應用程序來進行初始同步比較麻煩。 需要在每天早晨從同步的數據中產生關鍵的數據和報表，要求不能耽誤。 要求管理維護簡單、靈活：要求運行穩(wěn)定 ，同步中斷后能夠簡單快速處理完。 現在我們用的 oracle 機制，加上第三方數據同步管理軟件，只用了 1 個晚上就將主體數據同步好，一周就正式投入使用。然后逐步完善增加同步的表，目前已經同步了 149張表，還對同步數據進行了分區(qū)處理等優(yōu)化，從目前的近一個月的情況來看效果理想。 經過一年半還多的時間試用了 2 家產品沒有能夠成功，用一周時間就解決了問題（主要報表實際上第二天就正式使用了），心里是多么的欣慰、興奮和富有成就感。 所以寫了這么多東西。 就是用了 ORACLE 物化視圖技術 +一個圖形界面配置，還以為是啥東東哦。 還有誰為建立報表機和容災的數據同步而煩惱嗎？ oracle 的功能確實很強大，這需要大家一起去挖掘，才會有基于 oracle 的更多更好的應用軟件產生。 samchj 兄，你是 DSG 的吧？海龜從 ORACLE,IBM 出來，而且專攻容災的公司，我想不出第二家。你們的技術很牛，對底層很清楚，但讓人擔心對 ORACLE 后續(xù)版本的支持。雖然所宣稱的產品功能實現很吸引人，在測試中有不少問題，亟待完善。 VP 忙著改 BUG，應該是沒有什么時間來這灌水。 關于 BITI 擔心的存儲同步問題，樓上的已經解釋很清楚了。之所以存儲廠商要求主節(jié)點、容災節(jié)點更換成他們的存儲設備，就是要解決 I/O,CACHE 的問題，從而保證同步端能夠做到完全鏡像。 容災端只有停掉同步，才能打開數據庫，然后下一次再重做同步。而且他們還提供SNAPSHOT 的功能，建立一個快照數據庫，對于一個大數據庫，需要的存儲很可觀。 我個人認為，存儲廠商的最大優(yōu)勢在于維護量少，有保障。 DATA GUARD 配置靈活，不依賴于底層，但需要人為監(jiān)控。 聲明：我們這用的不是 DATA GUARD 是一個第三方軟件，目前報表機同步底層用的是 實例化視圖。 如果建立應用級的容災，數據需要實時 同步，估計需要用到同步復制技術了。目前還沒有下決心做，擔心性能問題。目前有過 1 個表的初步測試，還沒有進行大量表的測試。 對你的 ppt 提幾個疑問： 1。傳統(tǒng)同步軟件方案為 10 年前的技術，比較落后。 這個恐怕有些武斷，相反對于數據庫的復制我個人更看好如 Quest 的 shareplex 等產品。同樣 dataguard 也使用類似技術，絕對不是如你所言是 10 年前的落后技術。 2。傳統(tǒng)同步軟件方案，因其本身的缺陷，導致需要大量復雜的機制和操作來保證數據的一致，實施成本大。 復雜的機制不是最終客戶需要考慮的，相反這些軟件的 實施成本是相應較小的（當然如果你的成本是指 money 的話，那自然是比物化視圖高，不過仍然可以選用 DG），說起復雜的機制，即使是你使用的物化視圖，也仍然有大量內部的控制是較復雜的，不過這些不需要實施者去考慮而已。 3。采用硬件存儲快照的方式，同步方式不靈活，將生產系統(tǒng)上所有的數據全部同步。（經過長時間運行和維護的生產系統(tǒng)往往大量的臨時表和大量的垃圾數據，這些實際上是不需要同步的。 通?；诖鎯Φ膹椭铺峁┝司硪患壍墓芾?，完全可以通過配置不同的數據文件在不同的卷上來達到復制關鍵數據的目的。 4。采用硬件存儲快 照的方式，耗費大量的存儲設備，成本巨大。 就我所知，至少 veritas 的 vvr 不需要太多額外的存儲。 5。華爾東城公司采用的獨特方案，采用 oracle 的各種技術相結合，結合本公司獨特的同步參數設置。通過本公司軟件控制進行同步的管理。 其實你這個 ppt 真是說的很含糊，用于單純的 sales 宣傳恐怕還可以，如果是用于技術交流實在是有些不痛不癢。 6。華爾東城產品重要的益處，保證容災數據完全一致，報表數據與 10 分鐘前一致 。 既然有 10 分鐘的差距，為何仍然說容災數據完全一致？如果說你們使用了物化視圖的方案，那么 就不可能在一個刷新期內（你們這兒的 10 分鐘？）保證數據不丟失。除非還有業(yè)務 log 的分析軟件作后備。 7。華爾東城產品重要的益處，對主機性能影響小。 其實物化視圖的刷新對于主機并不是很小的影響，如果 10 分鐘之內需要刷新大量的數據，可以明顯的看到 CPU 的波峰，特別是 oracle 本身對于 mvlog 的處理還是有些問題的，所以不確定你們是否真的作過跟其它專業(yè)同步軟件的主機性能影響的比較。 8。本公司得益于 oracle 新技術的推出，加上本公司的努力，終于能夠為數據同步提供完美的方案，這也是我們值得驕傲的一件事情。 不否認你們確實作出了一個比較完備的同步解決方案，但是希望能夠本著技術交流的想法在 itpub 討論問題，而不是作單純的商業(yè)宣傳。我想很多人都希望知道你所指的oracle 新技術是什么？不應該說就是物化視圖吧。