資料庫容災、複製解決方案全分析(轉)

資料庫容災、複製解決方案全分析http://www.tianyar.net/blog/user1/10202/archives/2006/8967.shtml

最近發現論壇上關於資料庫遠端複製和異地容災等問題的帖子比較多，現在把我知道的一些解決方案進行一下分析，能力有限，還希望大家多多補充、糾正！

目前，針對oracle資料庫的遠端複製、容災主要有以下幾種技術或解決方案：
（1）基於儲存層的容災複製方案
這種技術的複製機制是通過基於SAN的儲存區域網進行復制，複製針對每個IO進行，複製的資料量比較大;系統可以實現資料的同步或非同步兩種方式的複製.對大資料量的系統來說有很大的優勢（每天日誌量在60G以上）,但是對主機、作業系統、資料庫版本等要求一致，且對絡環境的要求比較高。
目標系統不需要有主機，只要有儲存裝置就可以，如果需要目標系統可讀，需要額外的配置和裝置，比較麻煩。

（2）基於邏輯卷的容災複製方案

這種技術的機制是通過基於TCP/IP的網路環境進行復制，由作業系統程式捕捉邏輯卷的變化進行復制。其特點與基於儲存裝置的複製方案比較類似，也可以選擇同步或非同步兩種方式，對主機的軟、硬體環境的一致性要求也比較高，對大資料量的應用比較有優勢。其目標系統如果要實現可讀，需要建立第三方映象。個人認為這種技術和上面提到的基於儲存的複製技術比較適合於超大資料量的系統，或者是應用系統的容災複製。

我一直有一個困惑，儲存級的 複製，假如是同步的，能保證 資料庫所有檔案一致嗎 ？或者說是保證在 異常發生的那一刻有足夠的緩衝來保障？

也就是說，複製的時候起檔案寫入順序和oracle的順序一致嗎？如果不一致就可能有問題，那麼是通過什麼機制來實現的呢？


上次一個儲存廠商來講產品，我問技術工程師這個問題，沒有能給出答案

我對儲存級的複製沒有深入的研究過，主要是我自己的一些理解，你們幫我看一下吧……
我覺得基於儲存的複製應該是捕捉原系統儲存上的每一個變化，而不是每隔一段時間去複製一下原系統儲存上檔案內容的改變結果，所以在任意時刻，如果原系統的檔案是一致的，那麼目標端也應該是一致的，如果原系統沒有一致，那目標端也會一樣的。形象一點說它的原理可能有點像raid 0，就是說它的寫入順序應該和原系統是一樣的。不知道我的理解對不對。另外，在發生故障的那一刻，如果是類似斷電的情況，那麼肯定會有快取中資料的損失，也不能100%保證資料檔案的一致。一般來說是用這種方式做oracle的容災備份，在發生災難以後目標系統的資料庫一般是隻有2/3的機會是可以正常啟動的（這是我接觸過的很多這方面的技術人員的一種說法，我沒有實際測試過）。我在一個移動運營商那裡看到過實際的情況，他們的資料庫沒有歸檔，雖然使用了儲存級的備份，但是白天卻是不做同步的，只有在晚上再將儲存同步，到第二天早上，再把儲存的同步斷掉，然後由另外一臺主機來啟動目標端儲存上的資料庫，而且基本上是有1/3的機會目標端資料庫是起不來的，需要重新同步。

所以我覺得如果不是資料量大的驚人，其他方式沒辦法做到同步，或者要同時對資料庫和應用進行容災，儲存級的方案是沒有什麼優勢的，尤其是它對網路的環境要求是非常高的，在異地環境中幾乎不可能實現。

不知道我的理解對不對，也不知道是不是回答了你的問題，呵呵。歡迎指正！

應該說部分地回答了我的問題，呵呵

因為 實際上儲存裝置的寫入順序 和 oracle 的程式的寫入順序肯定是不一樣的，儲存裝置一定是做過重整的，那 不管同步或者非同步的拷貝都 有可能 存在問題的。

所以我一直對這個方案的可靠性不敢完全相信，這樣一來，倒不如 data guard 可靠了


因為很明顯，儲存裝置拷貝過去的資料檔案 不一致是有很大的概率的

你的意思是說即使不考慮目標端，僅在源端的情況下，儲存裝置的寫入順序也是和Oracle不一致的？這應該是一個原因。我覺得還有一種可能性就是在忽略儲存裝置的這種情況下，在主系統當機，發生切換的時候，主系統儲存上的資料檔案也不一定能保證一致，就算目標系統保持了完全的同步，也一樣不能保正目標端資料可可以啟動。

不太理解，為什麼說儲存裝置的寫入順序會和oracle程式的寫入順序不一致阿
如果說僅在源端情況下，儲存裝置的寫入順序也是和Oracle程式不一致，那麼不考慮異地冗災，那麼是不是意味著即使本地伺服器crash，也無法啟動儲存上的資料檔案？

我也有這個疑問，以前一直覺得僅考慮主系統的情況下，儲存裝置的寫入順序應該是和資料庫的寫入順序一致的， 但我覺得biti_rainy的理解也是有道理的，儲存裝置畢竟和一般的磁碟不一樣，很可能再寫入的時候會作重新的組合，不過不知道具體的證據是什麼啊？
按照這種理解，再寫入的某一瞬間，資料庫的寫入順序和儲存的寫入順序可能是不一致的，但既然儲存寫入的結果跟oracle的寫入結果肯定是一致的，那麼我們可以把一個比較長的寫入過程分成若干個時間段，在每個時間段的結尾，oracle和儲存裝置的寫入結果都是完全一致的，那麼這個時間段的大小是多少呢？
呵呵，說得我自己都快暈了，也不知道大家明白我的意思沒有……
o
biti_rainy能不能給我們解釋一下啊？或者論壇裡有沒有對儲存裝置比較瞭解的兄弟啊？

系統上通常不一致沒關係是因為還有 logfile 的存在，而日誌檔案通常是被寫入了磁碟的，oracle本身是順序寫的，還不需要讀，應該是被重整的機率比較小

還有儲存裝置上，比如掉電沒關係，是因為儲存裝置都有足夠的短時間供電能力使得 cache 中的資料能被寫入磁碟，這個如果不能保證那一掉電基本都要出問題的


但是在複製的那端，我就不清楚是怎麼處理的，比如我要停掉複製，開始用起這資料來，或者說裝置掉電了，這個時候是怎麼處理的


在複製的那端，我感覺是沒有經過特殊處理的，因為儲存裝置完全是物理上的同步，在你停掉複製的時候，他最多隻能保證在停止複製或原系統掉電的這一刻所有檔案在物理上是和原系統的儲存是完全一致的，但他絕對不會去校驗或保證oracle的資料檔案在邏輯上是否一致，所以會造成複製端在停止複製後有很大機率不能正常啟動。我在客戶那的情況就是在原系統正常執行的情況下，停止儲存的複製，然後啟動目標端資料庫，但還是有1/3的機率無法啟動，如果是在原系統發生故障或斷電的情況下，估計就更不好說了。
我還是比較佩服那個客戶的勇氣，一個省級移動運營商的資料中心，資料庫連歸檔都沒有，一旦系統崩潰，至少要損失當天的資料，同時容災端的資料庫能不能起來還是個問題……
還好目前還沒有出問題，要是出了問題，不知道他們會怎麼辦……

上次做儲存裝置的來公司，談到這個問題的時候說： 很多客戶就是這麼做的

我就說： 很多人這麼做的並不能說就沒問題，因為很多 人沒有出現事故，是因為隱藏的問題沒有機會暴露出來。我需要：
1：機制上的可靠保障，這個可能只有非常理解 原理的人能回答
2：實際系統的測試，要經過在我們自己提供的資料場景下反覆測試

通過這兩點之後我們才敢放心使用


同意，確實很多人都是這麼用的，也確實都很可能出現問題，所以我一直以為基於儲存的資料庫容災方案是有問題的，但在有些環境中好像還只能這麼做，例如我們的一個客戶，也是一個省級的移動運營商，其資料庫每天的日誌量達到100G以上，在這種條件下，好像只有這種解決方案比較可行，其他的都會有一些問題，至少那些使用軟體實現的邏輯複製方案是不行的，我感覺oracle自己的standby好像也負擔不了吧？不過他們的資料庫至少還是歸檔的，還有一點保證。呵呵。

從ORACLE的角度來衡量基於儲存的容災肯定是有問題的，不可能做到100%可用。

即使是ORACLE的DATA GUARD也不能保證100%沒有資料丟失（當前日誌組的資料）。

換個思路了，使用基於應用的同步方案吧。


（3）基於oracle redo log的邏輯複製方式
使用這種方式的主要有一些第三方的軟體，以及oracle自己的DATAGUARD 中的logical Standby。先介紹一下第三方的軟體產品吧……

目前，國外已經有了很多比較成熟的產品及成功案例，國內也有類似的產品， 但在產品的成熟程度和成功案例上跟國外還有一定的差距。
這類產品的原理基本相同，其工作過程可以分為以下幾個流程：
使用oracle以外的獨立程式，捕捉redo log file 的資訊，將其翻譯成sql語句，再通過網路傳輸到目標端資料庫，在目標端資料庫執行同樣的sql。如果其程式趕不上oracle日誌切換，也可以捕捉歸檔日誌中的內容。也有的產品在源端以事務為單位，當一個事務完成後，再把它傳輸到目標端。所有的產品一般都是以表為單位進行復制，同時也支援大部分DDL的複製（主要在oracle9i環境中）。
這種技術的技術特點和優勢主要有以下幾點：
目標端資料庫一直是一個可以訪問的資料庫；
能保證兩端資料庫的事務一致性；
因為使用oracle以外的程式進行捕捉，且其優先順序低於oracle程式，所以對源系統資料庫的效能影響很小；
基於其實現原理及多個佇列檔案的使用，複製環境可以提供網路失敗、資料庫失敗、主機失敗的容錯能力；
因為這類軟體複製的只是sql語句或事務，所以他可以完全支援異構環境的複製，硬體的型號，oracle的版本，作業系統的種類、版本等都沒有要求。
這種方式還可以支援多種複製方式，比如資料集中、分發、對等複製、或者多層測的複製等。
由於傳輸的內容只是redolog 或archive log中的一部分，所以對網路資源的佔用很小，可以實現不同城市之間的遠端複製。

基於redolog的邏輯複製產品有很多的優勢，但跟上面提到過的其他方案比較起來，也有一些缺點：
資料庫的吞吐量太大時，其實據會有較大的延遲，當資料庫每天的日量達到60G或更大時，這種方案的可行性交差；
實施的過程可能會有一些停機時間，來進行資料的同步和配置的啟用；
複製環境建立起來以後，對資料庫結構上的一些修改需要按照規定的操作流程進行，有一定的維護成本。
不過目前這類產品的發展很快，上面的這些問題，在大部分產品的最新版本中都有很大的改進。

您說的備中心1/3機會不可用，是同步複製還是非同步複製的情況？

是指同步複製的情況。
這個數字我不敢保證它的準確性，因為我沒有做過實際的實驗來驗證，但從我在客戶那裡看到的實際情況來說，基本屬實。

您能告訴我你的客戶用的那一家的產品嗎？

不管是同步環是非同步只要不是在資料庫裡面做當機時總應該有資料不一致的情況吧 因為資料庫寫檔案是由作業系統來最終完成的，而作業系統本身又有cache，在通過邏輯複製把資料非同步或同步複製到其他儲存裝置上，中間無論哪個環節有問題，遠端儲存裝置的資料都不能同現有資料保持一致，所以我認為 biti的懷疑是很有道理的。到10g oracle可以使用assm，直接同儲存裝置對話，這樣是否能夠好一些，不太確定

儲存是通過快照來記錄狀態，然後再進行復制進行備份的。
其實最好的方法應該是捕捉redo log file 的資訊，將其翻譯成sql語句

這就是oracle stream 和quest shareplex實現的功能

利用oracle 9i的高階複製，加上第三方的管理工具就可以了

我對oracle 的高階複製研究較多，覺得這是最好的方法，能夠完全保證資料的一致性。
但管理起來比較麻煩，需要利用第三方的管理工具就可以了。我用的是 深圳華爾東城公司的管理工具，能夠自動進行簡單故障處理，目前設定的10分鐘增量同步，最大表有4000多萬條記錄，目前還只同步了一部分表，資料量達到了50G。

容災實際例子，不知道是不是有幫助

曾經評估了幾個這方面的方案，一是利用儲存本身提供的功能，在兩端距離比較遠（幾百幾千公里）的時候，只能用非同步的方式，同步的話對網路的頻寬要求很高，除非兩端能夠用光纖直接連線。非同步的方式根據廠商的解釋是這樣的，遠端儲存上的寫是無序的，不會根據生產端的次序寫入，對使用者來說是透明的，沒有辦法干預，也就是說對oracle來說是不同步的，如果沒有人為的干預進行一次同步的話，資料庫也沒有辦法啟動。但是如果要同步的話就會對生產資料庫產生影響，處於suspend狀態。至於停電等各種極端情況我們在同城同步做過測試，沒有問題，儲存能夠保證資料的一致和可用。異地非同步沒有測試過，不知有哪位兄弟做過這個試驗，能告訴結果。

看了大家的帖子，我也想說點東西，一直以來做的就是容災和備份的事情。
目前的所謂的容災可能包含兩種方式：
1.真正的容災，目的就是為了防止在災難發生的時候能減少下線時間。這個過程沒有一個能做到零下線的。
2.”假“容災，即所謂的ods，資料複製。出來的資料不單單能達到容災的目的，而且目的端資料可以實時被使用。

第一種方式可能是雞肋，因為花那麼大的投資使用當前的硬體容災方式去達到一個可能領導在任期間都不能發生的災難，實在讓人覺得不太值得，除非廠商給了這個領導很大一筆錢，不過當前許多電信行業都說要建容災中心。
第二種方式確實是一種很誘人的方式，也是我現在做的產品。這種方式主要採用兩種方式實現：
a.使用我們現在的同步工作實現首次同步（邏輯上的匯出，也是一種鬼才寫出了這個東西，當然他是我們老總），然後直接轉入監控online redolog進行日誌監控分析轉化，然後傳送到目標端裝載。
b.使用類似於bcv/ca/flashcopy這些快照類軟體在磁碟儲存級做成首次同步，然後使用我現在的產品做日誌監控，載入到目的端。

這個產品作了1年多，應該說比quest的shareplex強大的多了，但是我並非在此宣傳產品，所以我要說的是公平話。

通過oracle內部方式去達到實時同步可能本身就是一個錯誤，類似於oracle本身的advance replication以及data guard也是日誌分析方式的，他的主要缺點在於效率上存在問題，就是裝載資料量很大的時候，根本不能應付，這也是shareplex的毛病。因此我現在的產品在這個上面是克服了這些缺點，效率絕對的高。我和oracle的stream，quest的shareplex，以及非用於容災方式的data guard等對比過，大家互有長短。
關鍵就是，採用基於這種精確分析的複製方式，如何保證資料是完全準確的：
1.沒有有效的檢驗方式，檢查資料是否一致，有類似於select minus select的方式，但是對於超過100M的表，除非你有足夠的耐心，我經常見到表最大是92G，沒有分割槽，很變態。
2.就算你知道了丟失資料，如何把這個資料補回來。現在的類似於我們的軟體，都採用了rowidmap的方式去做精確定位，所以如果丟失了，你如何補回來。我知道quest 是重新同步，我們是把整個表重新同步，因為我們的邏輯到處快。
這些都是基於oracle精確複製需要解決的最大的問題。

呵呵，當然了關於這個裡面處理很多oracle的特殊操作的時候還有很多需要做的事情，quest做了8年多了吧，到5年後才支援chained row，不能不說這是一個悲劇。還有許多的操作型別怎麼辦：ddl
,truncate,rollback savepoint,nologging等等，當然日誌了沒有的時候，你如何做。
我個人的觀點，基於oracle的精確分析複製方式，除了oracle以後能做好，其他人不要輕易嘗試。

不知道能否把產品名字透露一下啊？
如果沒有猜錯應該是DSG的了？
DGS和shareplex的比較讓市場來說話吧。

每個人都會說自己的產品好，但是希望在itpub這個地方
還是要說出一些更多技術上的東西。

samchj說“此我現在的產品在這個上面是克服了這些缺點，效率絕對的高”，並且也提到你們的產品也是通過監控redo的變化，提取SQL，那麼為什麼你們的效率會絕對的高？

希望能從機制上說明一下這個問題。

首先我澄清一下，我沒有宣傳產品的意思。

我必須讓事實說話，而不是市場說話，市場存在很多人為因素。

在效率上，對於處理chained row這種在資料庫中經常出現的東西，不能採用sql statment執行的方法。而shareplex是使用的這種方法。曾經我在測試的時候就對比過這個東西。因為chained row 包括migrate row &chain row 兩種。而mr在oracle中只有一個rowid，而cr卻不止。因此如果你採用的是rowmap方式精確定位兩邊的表，那麼在處理chain row的時候，除非你能很好的處理，否則最簡單和準確的方式就是直接在源端找到這個行，然後通過sql statment的方式裝到目的端。這樣在速度上是很慢的。

效率的提高主要從分析速度和裝載速度上講的。
我不知道shareplex日誌分析是如何進行的，這當然也是這型別軟體的kernel了，這是演算法問題，我想起基本原理和logminer都差不多，在演算法上優化分析速度是很重要的。

在裝載問題上，其實shareplex也曾經使用過direct path的裝載方式，但是因為direct path本身就存在很多bug，因此乾脆就放棄了這種方式，因為據我所接觸的通過direct path裝載的bug就很多，例如索引不能使用等。所以只能通過conventional path來裝載。這就是規規矩矩的轉換成sql statment，然後交給oracle通過解釋成binary 後在裝載
了，這是很浪費時間的，而且對於qmi（基本由creat table as select引起的oracle特殊插入處理）來說，這是很不合理的，因此在這裡應該做些事情，當然細節不便於說。

另外對於首次同步的匯出和裝載，現在的oracle10g也許就是使用的這種方式了，你可以看看oracle10g的export為什麼如此快。

我還是說，不論是否市場怎麼樣，使用基於oracle精確分析裝載的軟體要慎重使用，因為他的問題是很多的。

樓上的你們產品是什麼啊

關於這類產品的一些特別情況的處理我一直很關心

另： 10G 使用的 *expdp* 和 *impdp* 應該是由 DUL + SQLLDR direct 思想的結合吧

我們現在用的是Oracle 9i ，想用複製軟體VERITAS Storage Replicator 3.0使兩臺伺服器上的資料庫同步，應該複製Oracle下的那些資料檔案，表空間？還有複製後應該怎麼做？

伺服器硬體說明：
兩臺伺服器為了節約成本，沒有使用雙機熱備，沒用磁碟陣列，每臺伺服器用4塊SCSI硬碟做成Raid 5，兩臺伺服器作業系統，資料庫安裝路徑，設定都一致，有沒有解決辦法啊?

使用SQL Server 2000資料庫把資料檔案複製到另外一臺伺服器，資料庫可以實現同步，但是Oracle 9i把一臺伺服器上的表空間複製到另一臺伺服器後資料庫不用能。

對於samchj 一直說：然後通過sql statment的方式裝到目的端。這樣在速度上是很慢的，然後交給oracle通過解釋成binary 後在裝載了，這是很浪費時間的 ？
－－－－－－－－－－－－－－－－－－－－－－－－
能否舉出實際的例子？拿出具體的資料來說話， 你所謂的慢是什麼程度？
澄清一下，shareplex 不是使用你所謂的direct path 方式。

dx6340老兄，我不是在宣傳產品，我再澄清一次。如果有人對我現在做的產品感興趣，可以給我寫郵件，但是我們只談技術，不談市場，但是在itpub上或者任何其它場合，我不會說我的產品是如何的好，雖然我的和shareplex做的對比測試很多。他們各有各的優缺點。
shareplex確實不使用direct path裝載，這個我也說過“其實shareplex也曾經使用過direct path的裝載方式”，我是說曾經，從研發上講。你可以用shareplex或者oracle的data guard等做實驗，當大資料量的時候，你可以看看他是否能分析過來和裝載過來，延遲時間多少。一秒鐘能支援的update有多少，insert有多少，如果做ddl是否需要先停止複製。這些還只是很基本的處理。logminer尚且對日誌的分析很慢（不過可以用多程式來彌補，如果你有很多的系統資源）。

wbo兄弟的“Oracle 9i把一臺伺服器上的表空間複製到另一臺伺服器後資料庫不用能。”，我的理解是，如果你使用基於儲存級的複製產品，你同步的應該是整個設定的卷或者卷組，他沒有什麼oracle的邏輯結構複製方法吧，要麼就是把這個表空間建立在一個卷組上，然後設定複製這個卷組。如果你硬是要複製一個表空間過去，我覺得你應該先通過oracle的TRANSPORT_TABLESPACE來，但是好像很沒有必要。使用儲存級的複製不能實時開啟，開啟必須斷開。

對於基於複製中的特殊方式處理，主要有這些：
1.採用何種裝載方式
2.如何準確快速執行delete和update，因為這兩個操作需要rowid，有人採用在資料庫本身建立很多的表來維護rowid。
3.對chain row的處理
4.對各種ddl的處理(truncate,create,drop,alter)
5.對於未提交的事務的處理
等等,因為我確實還沒有來總結這些資料,這裡先列各提綱,我一個一個來總結.

1.裝載方式:
在oracle中裝載資料庫不外乎兩種方式:direct path和conventinal path裝載,其中類似direct path裝載就是例如sqlload等工具使用的裝載方式,因為它省去了sql語句的編譯繫結(kk/kx),直接轉換成繫結後的格式對extent進行操作.而conventinal path裝載方式確實普通的裝載方式,即類似於標準的sql語句的裝載.後者比前者在同等條件下要慢5倍.當然兩種方式的裝載速度還和表本身的結構和大小有關.我測試的速度最大有12倍的差距.
在裝載上,你還要考慮更多內容,你不能單單呼叫oracle sqlloader,因為在oracle中有很多的oracle特殊處理的東西,例如:qmi,qmd.oracle在這裡對於這些操作有在redo中有特殊的標誌,如果你採用create table as select來建立表,你會覺得它比現建立然後用sql語句插入要快的多,在日誌中他也只有很少的記錄.因此,在處理這些的時候,你要採用特殊的演算法,所以呼叫oracle的現成工具是不理想的,曾經在oracle7之前oracle並沒有將upi (好像是這個名字)封掉,但是在oracle8i後,oracle不再開放該介面,因此很多的程式設計師對於這個層面瞭解很少.當然現在你很難找到.oci只是封裝後更高階的介面而已.
因此裝載程式的設計,對於基於oracle精確分析方式的複製有很大的決定作用,這裡面還有更多的處理,我也不能一一列出了.

呵呵，樓上的這個工具就是你自己開發的嗎？

如果你老闆能找到一個肯研究 OCI --&gt UPI ---&gtOPI 的手下 並一直堅持對oracle的研究，在國內簡直是太不容易了。


沒其他意思,如果不是你開發的，除了對這一部分外，對oracle的整體問題你有過研究嗎？

呵呵，我不知道oracle的整體問題是什麼意思，oracle太大了，我涉及的有關於oracle的備份恢復（包括非歸檔物理熱備份，各種恢復方式，以及你們都已經在討論的熱備到底在做什麼，那都是我很早前學的，反正備份的東西誇大點就是知道原理的東西多些，不過不敢在任何地方賣弄，因為技術這個東西很難說，嘻嘻）。
搞我們這個容災產品也有很久了，基本涉及的有聯機日誌分析，各種特殊操作的原理等等，不能詳細羅列，但是在裝載上說實話，我只是知道經過哪些層次，並沒有開發，而是幫助開發作單元測試，所以知道比較詳細些而已，知道對於我上面寫的東西如何處理。同時對比過諸如：shareplex，stream，data guard等軟體產品效能和基本的一些原理，也和儲存級複製軟體結合，做過組合測試而已。

對於oracle的調優工作，我還是不如大家的，不過我看eygle老兄的東西都很接近我學的東西，因為確實我曾經站在了“巨人”的肩膀上，嘻嘻，還要向大家多學習，學習。

要說深入oracle，也只是在看大家寫的東西的同時，自己總結在這些年學習的東西，和大家分享，因為我覺得，我在網路上學了些，當然我也想將我學到的東西給大家分享，呵呵。

明天繼續對於這種產品存在的各種瓶頸作分析，也希望大家指正，我申明一點，我不做產品宣傳，只是在我都測試過的基礎上總結，絕不胡說

其實也沒什麼,整體方面是說oracle的檔案、記憶體、程式等比較全面的東西，
對於 oracle internal 比較有興趣一些，如 oracle 記憶體、檔案管理、程式間通訊

巨集觀方面 備份恢復、tuning、體系結構 ，這些都是在前面internal基礎上的具體應用，瞭解了internal後在管理方面就不侷限於固定的模式了。

比如喜歡這樣的探討：


呵呵，當然，我關注的也是這些。

我努力想成為一個像我們老闆一樣的高手，他能將這些東西轉換成程式，呵呵。

但是我不能把他拉到itpub上來，否則，中國的oracle研究者有福了。不過我願意將我在他那裡學的東西共享給大家，和大家一起研究。也請多指教。

你們老闆……當初是從哪裡學來的呢

因為如果原來不是oracle的人的話，我僅僅知道國外這樣的人有一些，國內的同時精通oracle+os + 開發 的人，很罕見的 。我只是聽聞國內有oracle的人出去做這類產品去了，但具體名字不清楚，不知道是不是你們老闆。

這個如果基於儲存的複製方式是同步的,這是可以保證的.因為同步複製是複製IO,而且是主機端寫IO的順序技術複製的順序,主要分成以下四步:主機端一個IO下來,儲存複製到遠端,然後遠端完成IO,最後返回通知主機IO完成. 但是儲存不保證資料庫在此時邏輯上是一致的,這是靠資料庫本身的機制來完成的. 即此時源端資料庫崩潰,如果可以通過資料庫相應恢復手段來恢復的話,遠端複製的儲存也可以.

但如果是非同步方式的話,問題就比較麻煩. 非同步與同步的區別就是,非同步主機IO下來後不需要等遠端儲存IO完成和確認,直接返回主機端IO完成. 這些IO暫時存放在源端儲存快取裡,等累計到一定程度或滿足給頂條件時,在傳送到遠端. 此時如何保證傳遞的IO順序從而保證邏輯一致,就與具體的產品有比較大的關係了. 有的產品沒有保證機制,直接用存放的順序傳送, 但在實際傳送過程中沒有保證,如由於線路等原因造成部分傳送等. 有比較好的舊有時間戳和順序號,而且還有邏輯分組,即主機端IO下來的時候是事務相關和邏輯分組的. 儲存就將這一組IO邏輯分組,按寫下的順序標號, 這樣在非同步傳送到遠端後就可以根據邏輯分組和IO標號來完成IO. 類似具有事務的性質.

同步如果是從主機下來的IO直接複製，這樣頻繁的小IO將造成網路的大量問題，這對網路的要求太高了。 以前都是聽人說同步是從 儲存的cache 來的，拷貝的時候封鎖cache不允許寫……

我覺得這個和同步I/O和非同步I/O沒有關係，對於儲存級的複製，他們都有一個佇列來保證I/O的次序，這是類似於ca/emc等廠商的這些儲存級（varitas檔案系統級）複製的一個共同點。至少我知道veritas聲稱的原理是這樣的。

如果不能保證I/O的次序，儲存級複製沒有任何意義。而且像ca這樣的軟體，他並不是實時改變多少就穿多少，我覺得他記錄在磁碟頭的tab應該隔多少時間加一次鎖，然後新的插入寫cache，所以如果這個時間源端off的話，cache中的資料應該是丟失的（磁碟壞）。
軟體級的複製也一樣，你總有一個佇列來處理ops/rac的事務順序，這個佇列有放在磁碟上用檔案來排隊的，也有直接在記憶體中排隊的，這些也是關鍵的東西。當然像軟體複製這樣的軟體可以通過重新分析日誌的方式來彌補，如果磁碟沒有壞的話。

同步絕對就是那樣，每個在SOURCE端寫入的東西必須被遠端的儲存裝置寫入成功（不一定是寫入磁碟）才返回主機寫入成功，基本可以認為就是一個距離很遠的RAID1。一致性的問題不用擔心，但是頻寬要求等等都是很高的。
非同步的方法，在之前很多是不能保證一致的，呵呵。最近據說多了很多能保證一致的方法，就知道HDS會吧所有寫記錄到本地一個日誌卷，EMC和IBM的方法還沒有弄的很清楚。

看看我們的實際應用

現在介紹我們資料庫同步的成功案例，你們提到的問題都可以解決。
現在我們的資料同步已經投入了實際執行，採用逐步增加表的方式。目前已經同步了149個表，其中包括詳單表，統計基表等。最大的6000多萬記錄，有16個超過1000萬記錄，採用10分鐘非同步複製。主要有以下特點：
1、關鍵業務資料（排出了很多垃圾資料），資料量最小
2、對生產機影響較小，目前一般只用到300M 空間
3、目標端資料不可以修改，完全保證資料一致
4、初始同步快捷、方便，不需要停止生產系統應用。影響小，只相當如一個select。
5、管理方便、靈活：能夠看到各表上次同步時間；上次同步後又有多少條新資料；上次各表同步耗費多長時間等。
目前每天進行一次count(*) 檢查，沒有發現有問題。


我們一前也試用過dsj和shareplex的產品，從名氣上來說，應該還不錯。具體不是我親自試用的，但最後沒有能夠成功，我想與我們的系統複雜、資料庫本身不是很穩定、要求太高有關。
1、這是一個24小時執行的系統，停止應用程式來進行初始同步比較麻煩。
2、需要在每天早晨從同步的資料中產生關鍵的資料和報表，要求不能耽誤。
3、要求管理維護簡單、靈活：要求執行穩定，同步中斷後能夠簡單快速處理完。

現在我們用的oracle機制，加上第三方資料同步管理軟體，只用了1個晚上就將主體資料同步好，一週就正式投入使用。然後逐步完善增加同步的表，目前已經同步了149張表，還對同步資料進行了分割槽處理等優化，從目前的近一個月的情況來看效果理想。
經過一年半還多的時間試用了2家產品沒有能夠成功，用一週時間就解決了問題（主要報表實際上第二天就正式使用了），心裡是多麼的欣慰、興奮和富有成就感。
所以寫了這麼多東西。

就是用了ORACLE物化檢視技術+一個圖形介面配置，還以為是啥東東哦。

還有誰為建立報表機和容災的資料同步而煩惱嗎？

oracle的功能確實很強大，這需要大家一起去挖掘，才會有基於oracle的更多更好的應用軟體產生。

samchj兄，你是DSG的吧？海龜從ORACLE,IBM出來，而且專攻容災的公司，我想不出第二家。你們的技術很牛，對底層很清楚，但讓人擔心對ORACLE後續版本的支援。雖然所宣稱的產品功能實現很吸引人，在測試中有不少問題，亟待完善。VP忙著改BUG，應該是沒有什麼時間來這灌水。

關於BITI擔心的儲存同步問題，樓上的已經解釋很清楚了。之所以儲存廠商要求主節點、容災節點更換成他們的儲存裝置，就是要解決I/O,CACHE的問題，從而保證同步端能夠做到完全映象。

容災端只有停掉同步，才能開啟資料庫，然後下一次再重做同步。而且他們還提供SNAPSHOT的功能，建立一個快照資料庫，對於一個大資料庫，需要的儲存很可觀。

我個人認為，儲存廠商的最大優勢在於維護量少，有保障。DATA GUARD配置靈活，不依賴於底層，但需要人為監控。

宣告：我們這用的不是DATA GUARD

是一個第三方軟體，目前報表機同步底層用的是 例項化檢視。
如果建立應用級的容災，資料需要實時同步，估計需要用到同步複製技術了。目前還沒有下決心做，擔心效能問題。目前有過1個表的初步測試，還沒有進行大量表的測試。

對你的ppt提幾個疑問：
1。傳統同步軟體方案為10年前的技術，比較落後。
這個恐怕有些武斷，相反對於資料庫的複製我個人更看好如Quest的shareplex等產品。同樣dataguard也使用類似技術，絕對不是如你所言是10年前的落後技術。

2。傳統同步軟體方案，因其本身的缺陷，導致需要大量複雜的機制和操作來保證資料的一致，實施成本大。
複雜的機制不是最終客戶需要考慮的，相反這些軟體的實施成本是相應較小的（當然如果你的成本是指money的話，那自然是比物化檢視高，不過仍然可以選用DG），說起復雜的機制，即使是你使用的物化檢視，也仍然有大量內部的控制是較複雜的，不過這些不需要實施者去考慮而已。

3。採用硬體儲存快照的方式，同步方式不靈活，將生產系統上所有的資料全部同步。（經過長時間執行和維護的生產系統往往大量的臨時表和大量的垃圾資料，這些實際上是不需要同步的。
通常基於儲存的複製提供了卷一級的管理，完全可以通過配置不同的資料檔案在不同的捲上來達到複製關鍵資料的目的。

4。採用硬體儲存快照的方式，耗費大量的儲存裝置，成本巨大。
就我所知，至少veritas的vvr不需要太多額外的儲存。

5。華爾東城公司採用的獨特方案，採用oracle的各種技術相結合，結合本公司獨特的同步引數設定。通過本公司軟體控制進行同步的管理。
其實你這個ppt真是說的很含糊，用於單純的sales宣傳恐怕還可以，如果是用於技術交流實在是有些不痛不癢。

6。華爾東城產品重要的益處，保證容災資料完全一致，報表資料與10分鐘前一致 。
既然有10分鐘的差距，為何仍然說容災資料完全一致？如果說你們使用了物化檢視的方案，那麼就不可能在一個重新整理期內（你們這兒的10分鐘？）保證資料不丟失。除非還有業務log的分析軟體作後備。

7。華爾東城產品重要的益處，對主機效能影響小。
其實物化檢視的重新整理對於主機並不是很小的影響，如果10分鐘之內需要重新整理大量的資料，可以明顯的看到CPU的波峰，特別是oracle本身對於mvlog的處理還是有些問題的，所以不確定你們是否真的作過跟其它專業同步軟體的主機效能影響的比較。

8。本公司得益於oracle新技術的推出，加上本公司的努力，終於能夠為資料同步提供完美的方案，這也是我們值得驕傲的一件事情。
不否認你們確實作出了一個比較完備的同步解決方案，但是希望能夠本著技術交流的想法在itpub討論問題，而不是作單純的商業宣傳。我想很多人都希望知道你所指的oracle新技術是什麼？不應該說就是物化檢視吧。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/756652/viewspace-242061/，如需轉載，請註明出處，否則將追究法律責任。