MIS2000 Lab. is MVP 2008-2017/7/1 for ASP/ASP.NET.
簡單的說，有兩台DB
第一台，稱為「發行者」（Distribution / 資料的主要來源）。
第二台，稱為「訂閱者」（Subscription）。接受第一台DB複製過來的資料。
先依照自己的情況，挑選一種複寫方式。
我想，不少需求都是第一種「交易式複寫」便能搞定。
1. 交易式複寫 *
交易式複寫一般用於伺服器 對 伺服器環境，並適用於下列各案例：
‧您希望發生累加式更新時，能立即傳播給「訂閱者」。
‧應用程式在發行者進行變更的時間與變更到達訂閱者的”時間”需要有低度延遲。
‧應用程式需要中繼資料狀態的存取權。例如，若資料列變更五次，交易式複寫允許應用程式回應至每個變更 (如引發觸發程序)，而非只有回應至資料列的資料變更。
‧發行者有極大量的插入、更新和刪除活動。
‧發行者或訂閱者為非 SQL Server 資料庫，如 Oracle。
依預設，交易式發行集的訂閱者應當成唯讀處理，因為變更並不會寫回發行者。
2. 合併式複寫
合併式複寫通常會在 伺服器 至 用戶端環境中使用。
合併式複寫適合於下列任何情況：
‧多個訂閱者可能會在不同時間更新相同的資料，並將這些變更傳播到發行者與其他訂閱者。
‧「訂閱者」需要接收資料、離線變更資料，稍後同步變更「發行者」和其他「訂閱者」。
‧每個訂閱者需要一個不同的資料分割。
‧可能會發生衝突，而在發生衝突時，您需要偵測與解決衝突的能力。
‧應用程式需要淨資料變更，而非對中繼資料狀態的存取。例如，如果資料列在「訂閱者」與「發行者」同步之前，於「訂閱者」端變更了五次，則該資料列只需在「發行者」端變更一次，以反映最終資料變更 (即第五次的值)。
合併式複寫允許各站台自發地工作，然後將更新合併到單一的統一結果。
3. 快照式複寫
若下列一或多項敘述為真，則最適合單獨使用快照式複寫：
‧較少變更資料。
‧可接受已過時的發行者相關資料副本放置一段時間。
‧複寫小量資料時。
‧在短時間內發生大量變更。
資料變更數量可觀 但次數不頻繁時，最適合快照式複寫。
***************************************************************************************************************************************
有一些相關的文章，可以先參考一下。
網友的經驗談、安裝步驟都有圖片說明了。話雖如此，我還是買了幾本書先看過一遍。
***************************************************************************************************************************************
當然，微軟有一份說明也很詳細。步驟最明確！
我是依照 "微軟的教學課程" 來做實驗，個人心得如下
無法保證正確，因為我不是網管與DBA高手。但我做了很多次，這是成功經驗：
================================================
1. 文件中提到的多個帳號，我只用了一個就能完成。
重點，這個帳號必須在兩台DB都有，權限最好設定 "高"一點，以免後續步驟的執行權限不足。
2. 發行者（第一台DB），資料的主要來源。這個資料庫請設定為 sa，以免後續步驟的執行權限不足。
點選這一個資料庫，按下"滑鼠右鍵"並選「屬性 Property」
畫面左側的 Menu，請選第二個 Files。
然後在畫面右邊的第二格，請輸入 sa（原本可能寫 default）.....微軟上面的教學文章沒有提到這一點
執行權限不足，是我十餘次設定中最常發生的錯誤。
另外幾個「權限設定」在微軟的教學文章中有提到。只要沒有漏了做，應該都能運作。
...........................完成了上面兩個重點（微軟教學文章中沒有提到），就OK啦！
3. 本文一開始收錄的相關BLOG文章，其他網友、前輩都會自己寫SQL Script來做設定。
微軟教學文件中、我自己的設定經驗，發覺這並非必要條件。
只要依照微軟的教學文章，畫面上的精靈步驟逐一做好，效果是一樣的。
精靈設定，完成後一樣可以產生SQL Scriipt，我有拿出來其他前輩的寫法作比對，100%雷同。
4. "似乎（我不確定）"只能複寫「資料表（Table）」
設定過程中，我把 View、Stored Procedure打勾以後，都會造成失敗。
網路上看見的設定步驟（包含微軟教學文件），都 "只有" 勾選「資料表（Table）」
5. 「資料表（Table）」必須要有主索引鍵（P.K. / Primary Key）
不然的話，不能勾選（不能複寫到別人身上）
我想，不少需求都是第一種「交易式複寫」便能搞定。
小型的資料庫（例如幾百MB的 .mdf檔），延遲時間大約只有一秒 (Intranet裡面比較快）。
稍微大一點的資料庫（例如20GB的 .mdf檔），延遲時間則可能到達十餘秒才能複寫過去（如果是 Internet不知道會不會更慢？）
但效果已經不錯了。
資料庫的大小，跟運作時間有正相關。
在建立（設定）時、或是重新 run一次快照（snapshot）會很花時間
我曾經放置一天就發現 複寫的Agent壞了，必須重來一次（重新做 Reinitialization才恢復）
如果做壞了，想要重新設定「複寫」（把原本的設定刪除）
有時需要重新啟動SQL Server服務才能將步驟重做一次
== 結 論 ==
設定很簡單......微軟的產品與設定，大家不用擔心
重點是 發生問題時該 怎麼處理？
書上都沒講到（這些 "經驗" 比較寶貴，但比較難取得）
因為網管、DBA這部分我不熟悉，初學的時候，比較難下關鍵字
所以常常 Google不到資訊，但是在對岸的百度（http://www.baidu.com/）就很容易查到東西
沒有留言:
張貼留言