橄欖葉子

此案例剛好發現觸發程序(trigger)對合併式複寫(merge replication)與交易式複寫(transaction replication)的影響。

前幾天遇到跟複寫相關的錯誤[ 無法卸除資料庫 'ooxx'的問題，因為它已用來複寫。 (Microsoft SQL Server, 錯誤: 3724) ]，先暫時筆記一下。

在前一篇文章【透過備份及還原資料庫來初始化交易式複寫的訂閱】中，談到利用資料庫備份檔來處理交易式複寫的訂閱初始化，緊接著來說明當發行者(Publisher)新增了一個資料表，且欲加入發行集(Publication)時，我們該如何來進行。

 一般透過複寫精靈來設定交易式複寫時，都會選擇透過快照集代理程式(Snapshot Agent)來產出快照，然後藉由散發代理程式(Distribution Agent)來初始化訂閱的資料，這種方式確實是方便省事，而且當你產出快照集到訂閱被新增，這中間的資料異動，交易式複寫機制都會自動幫你補上去，然而當要複寫的資料量大到上百GB，甚至是TB時，同步資料到訂閱者所耗費的時間將會相當長，更遑論如果是跨國同步資料的情境。

拜讀了楊志強老師在FB上的一篇文章【管理 Life Saver 】之 【拯救交易式複寫問題之未遞送大量交易20170311】，老師使用了(1)關閉Log Reader讓Distributor先遞送，以及(2)調高遞送量這兩個步驟，漂亮的解決了大量交易所造成的複寫堵車問題，心想若複寫能搭配使用預存程序來更新大量資料的話，能否改善此類問題？