閱讀本文之前請參考http://www.cnblogs.com/stswordman/p/3258897.html
最近又做了一個case，環境是sql server 2008 R2. 客戶添加了一個'replication support only'的訂閱，之后發現現存訂閱出現了更新丟失。 丟失的數據恰巧是添加訂閱前的幾秒鍾內生成的。
我開始以為是log reader沒有開啟造成的，檢查了distribution database的MSlogreader_history
,發現期間log reader並沒有停止過。
如果Log reader停止，那么添加訂閱前的更新肯定是丟失了。因為產生的數據的LSN小於"添加訂閱"的LSN， 並且distribution agent把"添加訂閱"的LSN先傳遞到了訂閱。可是log reader一直處於運行狀態，那么還有什么可能呢？ 如果log reader的效率很低，沒有即時地將數據更新傳遞到distribution agent，那么也會產生這個問題吧？我想理論上是這樣的,如果效率非常低，可以等同於log reader沒有運行! 那么如何證明這一點呢？reproduce的過程可能會很復雜，而且客戶的磁盤性能也很好…
我想到了另外一種可能，這個問題實際上和log reader的工作方式有關系：
當log reader啟動后，會去讀取publication database的日志，如果一次讀取完后，如果publication database的日志中仍然有需要處理的數據，log reader會繼續讀；如果讀取后沒有數據需要處理，log reader會休息一段時間， 時間長度為PollingInterval的值（默認為5秒中）。 那么我們假設這樣的情景。
PollingInterval為五秒。Log reader啟動后發現沒有數據需要讀取，開始休息。
在第1秒的時候，其中的article a產生了數據更新
在第2秒的時候，其中的article b產生了數據更新
在第3秒的時候，添加了一個非snapshot方式初始化的訂閱。
在第4秒的時候，其中的article c產生了數據更新
在第5秒的時候，其中的article d產生了數據更新
同時log reader開始繼續掃描日志， 我們就會發現第一秒和第二秒的數據更新丟失了。
更多信息
1 向任意一個包含'replication support only' 訂閱的發布添加article時都可能會導致這個發布庫的所有發布的所有現存訂閱出現更新丟失的問題。
向不包含'replication support only'訂閱的發布添加不會有這個問題。
2 如果在添加一個'replication support only'的訂閱時 ，該發布對應的發布數據庫的所有已存在訂閱也會出現更新丟失的情況，無論這些都訂閱通過何種方式初始化，或屬於那個發布。
解決方法之前文章介紹的相同
解決辦法
===
升級至sql servr 2012
如果您暫時沒有辦法升級，可以采用以下兩種方法：
-
添加一個新的發布，將新的article或訂閱添加到發布中。
-
在添加article前將Log reader和Distribution agent停止。添加完成后，啟動Log reader，確認Log reader已經將之前的數據傳送到了Distribution數據庫后（可以使用tracer token來確認Log reader是否已經完成同步）， 啟動Distribution agent。這樣就可以避免數據丟失了。
更多信息
========
1 向任意一個包含’replication support only’ 訂閱的發布添加article時, 都可能導致這個發布庫的所有發布的所有現存訂閱出現更新丟失的問題。 向不包含’replication support only’訂閱的發布添加article不會有這個問題。
2 如果在添加一個’replication support only’的訂閱時 ，該發布對應的發布數據庫的所有發布的所有已存在訂閱都會受到影響，無論這些訂閱是通過何種方式初始化，或屬於哪個發布。