最近發現有一個釋出經常出現問題，每幾天就出錯不同步，提示要求初始化。重新調整同步後，複制還是很慢！每天白天未分發的指令就達五六百萬條！要解決慢的問題，需要了解從釋出資料庫到訂閱資料庫中，有哪些操作，才知道哪個步驟同步緩慢。
這是很久之前自己做的一張圖，主要描述釋出到分發、分發到訂閱中，複制使用了哪些操作，如下圖：
釋出到分發：
在釋出中，複制是使用日志讀取器讀（sp_replcmds）取釋出資料庫中的事務日志的，日志讀取器是按事務順序讀取的，是以每個資料庫隻能有一個（若有CDC也使用同一個日志讀取器）。
首選，在事務日志中，到底有多少是需要複制的？使用以下指令，可以确定事務日志中被标志為複制的指令有多少。
如果事務日志中标志為複制的指令很多，常見的種情況有：
1. 有一個較大的事務還沒讀取到；
2. 日志讀取器出現問題；
正常來說，日志讀取器掃描日志還是比較快的，不會有什麼問題，不會累計較多待讀取的日志。可以使用性能計數器監控日志讀取器讀取情況：
"\SQLServer:Replication Logreader\Logreader:Delivered Cmds/sec"
"\SQLServer:Replication Logreader\Logreader:Delivered Trans/sec"
日期讀取器讀取事務日志後，會通過存儲過程 sp_msadd_commands 寫入到分發伺服器上的分發資料庫 distribution 。但是寫入是否正常呢？從上面計數器跟蹤的情況，可以估計每分鐘有讀取了多少指令。需要分發的事務和指令，系統存儲過程分别寫入了分發庫上的表 MSrepl_transactions和 MSrepl_commands
，這兩個表記錄了需要分發的指令（注意：其中的指令可能已經分發到訂閱了，隻是還沒清除）。将兩表關聯按分鐘統計，可以确定每分鐘寫入到分發庫上的指令有多少了。
在釋出到分發中，事務指令的讀取和寫入可做對比，确定讀或寫是哪段出現問題。
分發到訂閱：
分發到訂閱，首選确定有多少指令是需要分發的，若直接求和 MSrepl_transactions 和 MSrepl_commands是不準确的，因為有的已經分發了。可以打開複制螢幕檢視某個釋出中未分發的指令，若用腳本檢視，有兩個方法：
總體監控分發到訂閱的情況，可以使用計數器跟蹤：
"\SQLServer:Replication Dist\Dist:Delivered Cmds/sec"
"\SQLServer:Replication Dist\Dist:Delivered Trans/sec"
若了解更詳細情況，可在分發代理中添加以下參數，重新開機分發作業。
-Output [output_path_and_file_name]
-OutputVerboseLevel [0|1|2]]
接下來回歸主題：SQL Server 事務複制分發到訂閱同步慢
目前未分發的指令已經堵了六百多萬條了，而分發差不多兩分鐘才分發一次。在分發資料庫中檢視目前執行了什麼指令，經常看到在執行存儲過程
sp_MSget_repl_commands ，該存儲過程是從 MSrepl_transactions 和 MSrepl_commands 讀取未分發的指令，将這些指令應用到訂閱中。但是讀取出現了等待類型ASYNC_NETWORK_IO
，ASYNC_NETWORK_IO 意思是資料已經讀取了，但是客戶的還沒有完全把資料拿走。按正常了解，這些這個等待類型，很可能是網絡問題。
為了确定是不是網絡問題，我用了以下方法：
1. 從其他不堵塞的釋出中，插入跟蹤器。确認整個過程網絡沒什麼問題。
2. ping 網絡，看時間多少。基本1ms 内，正常！
3. 訂閱中建立一個共享檔案夾，在分發伺服器通路共享，拷貝一個大檔案過去。拷貝速度66mb/s ，沒毛病！
既然網絡沒什麼問題，那就要确定是不是分發到訂閱中 “寫” 出現了問題？到訂閱伺服器檢視目前執行了什麼指令，發現一個指令總數一直在執行！
從緩存中，檢視執行情況，發現該存儲過程耗時非常多！
點選上面查詢出來的執行計劃，發現應用的表竟然用表掃描！！！
找到表 MDS_ADRelation ，發現竟然沒有主鍵（或索引）！！
表釋出訂閱是必須有主鍵的，訂閱也會一會保留主鍵的，資料的同步更新就是按主鍵做條件進行更新的，而表主鍵沒了，更新就用不上索引了！！真不知道是誰删除的！
從釋出中把建立主鍵的腳本導出來，到訂閱執行，因為同步正在進行，建立主鍵時使用 （online=on）線上建立。建立完成後，分發瞬間加快（如下圖），訂閱中流量也瞬間加大了！！複制終于正常了！！