事務複製前和後腳本
只是一個前言，我現在作為一個偶然的 DBA 工作，對任何無知感到抱歉。
我需要完全重建我們的一個事務複製。訂閱者數據庫的索引策略與發布者數據庫的索引策略不同，主鍵相同但 NC 索引上的聚集索引不同。我知道預設情況下這些表完全被訂閱者刪除。我相信我可以在快照應用程序前後使用腳本來刪除和創建索引。
訂閱者和發布者上的聚集索引都是 UniqueIdentifier 但不同的列。該表有近 10 億行，而且非常寬。只是想我會提供這些資訊以防萬一。
我的問題是：
- 使用後執行腳本是解決此問題的最佳方法嗎？
- 如果訂閱者的聚集索引與發布者不同，我最好允許批量插入與發布者聚集索引一起發生，還是在批量插入之前設置備用聚集索引會更好？
提前感謝您的幫助。
在我的上一份工作中，這正是我們為非常相似的場景所做的（也在 SQL Server 2008 R2 - 標準版上），我是建構它的人。我們有一個現成的供應商應用程序，我們大量使用並需要報告出來。它的索引方式與我們從中報告的方式不同。
我們有一種方式將事務複製設置從供應商應用程序同步到我們的報表伺服器。我設置了 pre 和 post 腳本來刪除和重新創建適當的索引（以及一些其他相關實體，如索引視圖），當然在執行之前也首先檢查對像是否存在（您可以通過 sys 模式的表和視圖檢查這一點）。
腳本本身只是指向訂閱伺服器上所有邏輯所在的儲存過程。維護程式碼比更新外部腳本文件更自然。在同步模式之前刪除自定義索引的預腳本很重要，因為我們遇到了一個錯誤，其中事務複製偶爾會中斷並停止同步。（如果您需要我的 pre 和 post 腳本的程式碼範例，請告訴我，我會更新此答案。）
關於您的第二個問題，通常將記錄批量插入表中然後添加索引會更快（這為 SQL Server 提供了一次以最有效的方式排列數據的全貌）。要使用事務複製執行此操作，您需要在該表的文章屬性下的發布者屬性視窗中取消選擇“複製聚集索引”（以及非聚集索引）。（讓它與發布伺服器的聚集索引同步數據實際上只是將您的伺服器在使用首選聚集索引在訂閱伺服器上重新索引時需要做的工作加倍。）
在我看來，由於表大小，更好的方法是使用
truncate table發布選項中的策略並使用 pre 腳本在繼續載入之前創建所有索引。另外兩個問題：
是工作？我的意思是這個複制與更多的 10 億行同步？在我的工作中，複製表有超過 3 億行的問題。
該表是否已分區？有了這個尺寸，我真的很推薦。