對於大批量的更新操作 又涉及同步，如果可以：
a) 最好是使用最小粒度的維護，可以減少每次維護的工作量，也減少備份 （建立作業JOB批量操作，定期進行刪除）
b) 如果是急需，又涉及到同步，那麼可以把同步拿掉進行刪除，完成之後再建上（避免出現線上阻塞，影響性能。同步會同步大量日誌，更新完成之後再重建同步使用的不是日誌同步而是快照，所以速度要比用日誌同步快很多。）
監控：可以用 sp_who2 或者 可以通過查詢 sysprocess 獲取是否有阻塞，在更新的同時，查看同步的監控通常是看SqlMonitor，以便於對當前的情況進行隨時的調整。
1. 我們可以通過以下查詢看到目前有多少的命令沒有分發出去，如果數據量特別大，可以稍等，分發相對少一些的時候再來進行操作。
USE distribution GO SELECT COUNT(*) FROM dbo.MSrepl_commands WITH(NOLOCK)
或者就是複製監視器中的未分發命令來進行查看
2. 如果 Logreader的日誌顯示當前正在進行大量數據的讀取，那麼表示之前有大量的數據變更，如果我們正在執行分批更新的話，那麼應該先停止，這通常表明我們的分批可能不太合理，導致日誌讀取器一直在讀取事務
SQLMonitor 會對服務器造成比較大的影響。
以下腳本可以查看當時庫有多少同步，如果知道表，可以直接查詢這個表同步到什麼地方，同步到了幾處。
USE TEST GO SELECT sct .dest_db ,srt. dest_owner , srt. name , sct. srvname, pub.pubid , srt .dest_table --,srt.artid ,sct.artid FROM syspublications as pub WITH (NOLOCK) inner join sysarticles as srt WITH( NOLOCK) on pub .pubid = srt .pubid inner join syssubscriptions sct with (nolock) on srt.artid = sct.artid GROUP BY sct. srvname , pub. pubid , srt.dest_owner , srt.name , srt.dest_table ,sct .dest_db
