據介紹,快照發布適合用在更新不需要很即時而且數據庫該變不大的情況。不過根據我這兩天所做的實驗表示,快照發布發布的內容正的是太“快照”了點,它把所有內容全部存放到文件中,然後當訂閱方訂閱時就將最新的發給訂閱方。
這種方法的確很好的實現了數據同步,可是在數據量龐大而改變步多的情況下,每次都將重復“快照”,還有網絡傳送,這些都將很大的消耗各種資源。所以我認為,
快照發布不適合數據量龐大而變化不多的數據同步。
另外,據介紹,快照發布時,訂閱服務器上所訂閱的表結構必須和發布服務器上一致,也就是說,如果建立了索引之類的東西恐怕就無效了。為此我做了一個實驗,為訂閱服務器上的某個訂閱表建立了一個觸發器,當插入新內容時將執行該觸發器(不建索引的原因是建立索引的話也無法明確的看出來是否影響),並作了一個insert操作,該操作很正常,觸發器並觸發;然後我往訂閱服務器上該表添加了一新內容,並使得兩個服務器數據同步,此時發現訂閱服務器內容已更改,即有了新添加的內容,但觸發器卻沒觸發,後又執行了一次insert操作,同樣可以觸發觸發器,所以,不敢保證是否會真的快照發布會造成索引無效。因此,同樣認為
快照發布不適合需要建立索引等內容的數據訂閱。
事務發布,它結合了快照發布和事務技術實現的發布。
首先,事務發布根據訂閱者的要求提供快照,譬如如果訂閱者是第一次訂閱,那麼它將生成一快照發供訂閱者同步,而後訂閱者再次訂閱時就不再提供快照,而是去翻查日志,將該訂閱者從上次訂閱到現在所有進行的操作都使用事務方式讓訂閱者重新執行一次,以實現數據同步。
這種發布方式只需要一次大數據量的傳送,之後就可以通過增量形式實現數據同步,大大優化了快照發布的不足之處,但是由於所有的操作都使用了事務,這將很大的占用了訂閱服務器上的資源。所以,
事務發布適合用在數據量大而數據改變量不大的數據同步場合。
另外,同樣為訂閱服務器上的訂閱表建立一個觸發器時,在事務發布的同步過程竟然會觸發,從這點可以看出事務發步和快照發布有著本質的不通。實際上,所有做了事務發布的數據庫的更改都將紀錄到事務數據庫中(默認是名字為distribution的數據庫),而事務同步的時候,發布數據庫將這些紀錄下來的命令以事務的方式發送到訂閱服務器上,並調用相應的操作的存儲過程(譬如insert到表tbl的命令,在訂閱服務器上將生成名稱為sp_MSins_tbl的存儲過程)插入數據到訂閱服務器,此時的命令和在發布服務器上執行的是一致的,所以能確保數據同步。而且,由於是調用訂閱服務器上的命令執行而不是要求兩機結構一樣,所以可以在訂閱方做一些發布方沒有的動作,譬如建觸發器和建索引之類的內容。因此它
適合使用在需要建立索引的數據訂閱上。
增量發布並不適合用於之前所說的數據同步,而且增量發布沒作過實驗,這裡就不繼續說了。
這裡選擇了事務發布。
選擇完發布方式後需要選擇欲發布的數據表,還可以同步觸發器存儲過程等內容。
圖9
並且,可以設置發布的是那些表的那些列那些行,即是可以設置發布的篩選項。如圖10,垂直設置的是列,水平設置的是行篩選條件。
圖10
圖11就是圖10按下一步後的詳細選擇項。
圖11
然後設置訂閱是否允許匿名,一般選擇只允許署名訂閱。
圖12
最後設置的是發布的代理程序運行頻繁程度,根據需要的實時度可以進行調節,如果實時度不高的話一天一次發布就可以了,比較同步過程也將耗用服務器資源,最好能調整使得同步的執行在不影響其它工作或在數據庫使用比較少的情況下執行。