前一篇講到「MSSQL 2008 Transactional Replication」，這是一種「單向」的覆寫動作，只會從來源端（Publisher）傳送資料到目的地端（Subscriber），目的地端的任何修改都不會影響到來源端的資料。當然～這時候就會有另外一個需求，就是希望兩邊都可以做寫入修改的動作，那麼我們就來看可以達到這個目的的「Merge Replication」怎麼做。
前一篇講到「MSSQL 2008 Transactional Replication」，這是一種「單向」的覆寫動作，只會從來源端（Publisher）傳送資料到目的地端（Subscriber），目的地端的任何修改都不會影響到來源端的資料。當然～這時候就會有另外一個需求，就是希望兩邊都可以做寫入修改的動作，那麼我們就來看可以達到這個目的的「Merge Replication」怎麼做。
-------------
Q：使用 Merge Replication 有什麼需要注意的地方？
Ans：在同步的排程（Synchronization Schedule）上，有兩種方式分別為「連續執行（Run Continuously）」與「僅在需要時執行（Run on demand only）」
因為 Transaction Replication 不會有衝突的發生，所以我會建議都用（Run Continuously）來做，但是 Merge Replication 的資料是會雙方（甚至多方）互相影響的，所以有一些人會建議在 Merge 下，使用（Run on demand only）來避免一些衝突的情形。
我們要知道的是，當有衝突發生，最後資料是怎麼決定的。（改不同資料不會有衝突，所以下面的例子，都是說明在連續執行（Run Continuously）對同一個資料表、同一個欄位、同一筆資料來做修改）
↓ 在2次的同步之間，只有 Subscriber 修改資料，所以最後兩邊都被修改成C。
↓ 因為 Publisher 的優先權比較高，所以最後會以 Publisher 為主。
↓ 上下圖比較一下，就會知道決定權是看 Priority ，而不是執行的先後順序。
↓ 加入第二個訂閱者，一樣是以 Priority 決定。
↓ 如果把 Subscriber2 的 Priority 提高，且 Publisher 並無修改資料，就會以 Priority 高的為準。
Q：那麼？為何不建議 Merge Replication 採取連續執行（Run Continuously）的方式呢？
Ans：從上面舉的例子來看，除了優先權能決定以那個值為準，更重要的是同步機制 Synchronization 執行的時機點跟週期性，SQL Agent 不可能每一秒幫你同步一次，你的 Server 也不見得願意負擔這樣的 Loading。
那隔10秒？隔一分鐘？隔3分鐘？
不管隔多久都有可能出現，不是你所預期、你所想要的結果，所以才會有人建議「Run on demand only」......在你想要兩邊同步時，才來做同步、仲裁的機制動作。
-------------
因為 Transaction Replication 跟 Merge Replication 動作幾乎一樣，所以底下的圖片部分，就不在個別說明，有需要說明者請看「前一篇」。
有特別需要說明部分，我會用紫色字來表示。
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
簡單的說只要三個步驟，就完成了資料覆寫的機制
-
設定散發者（設定散發分享資料夾）
- 建立發行集（New Publication）
- 設定訂閱者
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
↓ 經過上面的例子說明，相信你可以知道下圖中所設定的優先權是相當重要的，資料最後以什麼為主，全依賴此值來仲裁。
↓ 嘗試在 Publisher 端修改資料
↓ 嘗試在 Subscriber 端修改資料
↓ 最後兩邊會達成一致的資料值。
~ End
Merge Replication 設定並無特別於 Transaction ，只是必須注意優先權的設定。
Q：那麼？為何不建議 Merge Replication 採取連續執行（Run Continuously）的方式呢？
Ans：從上面舉的例子來看，除了優先權能決定以那個值為準，更重要的是同步機制 Synchronization 執行的時機點跟週期性，SQL Agent 不可能每一秒幫你同步一次，你的 Server 也不見得願意負擔這樣的 Loading。
那隔10秒？隔一分鐘？隔3分鐘？
不管隔多久都有可能出現，不是你所預期、你所想要的結果，所以才會有人建議「Run on demand only」......在你想要兩邊同步時，才來做同步、仲裁的機制動作。