訂閱者數據庫上的長時間執行和鎖定查詢是否會導致發布者數據庫出現性能問題？
我們的其中一台伺服器有一個訂閱者數據庫。我以前沒有使用過複製，也找不到有關該機制如何工作的資訊。發布者是否必須在送出事務之前等待複製完成，還是在將更改應用於訂閱者之前使用隊列或事務日誌？訂閱者用作自定義報表生成器（以及其他用途）的後端，它不能很好地利用索引，因此表經常被鎖定幾分鐘。我擔心這可能對我們的發布者產生任何影響，發布者在我們的實時製作伺服器上。發布者和訂閱者都處於完全恢復狀態。
我們的其中一台伺服器有一個訂閱者數據庫。我以前沒有使用過複製，也找不到有關該機制如何工作的資訊。發布者是否必須在送出事務之前等待複製完成，還是在將更改應用於訂閱者之前使用隊列或事務日誌？
您還沒有指定什麼類型的複制，所以我將假設事務複製。Trans Replication 的基本流程（假設訂閱已經初始化）如下：
- Distributor 上的 Log Reader Agent 連接到 Publisher 並讀取標記為 FOR REPLICATION 的任何事務的事務日誌。
- 然後將事務分解為儲存在分發數據庫中的命令。
- 分發代理讀取分發數據庫中的表並將命令應用於訂閱者。
根據您的配置，會有一些細微的變化，但這基本上是過程。發布者不等待訂閱者或分發者確認收到交易。唯一真正的影響是，如果文件具有標記為 FOR REPLICATION 且日誌讀取器代理尚未復製到分發的日誌記錄，則 SQL 無法清除日誌文件的非活動部分。
我擔心這可能對我們的發布者產生任何影響，發布者在我們的實時製作伺服器上。發布者和訂閱者都處於完全恢復狀態。
在正常操作期間，不應對 Publisher 產生任何不利影響。如果您必須重新初始化您的訂閱者，因為必須拍攝新的快照，這可能會產生重大影響，這可能會增加您的伺服器上的負載，並且在快照生成期間確實需要一些模式鎖定。
如果您的 Distributor 與 Publisher 是同一台伺服器，那麼由於伺服器上的活動增加，您通常會看到性能影響，但通常這並不重要。您也可以改用遠端分發伺服器來緩解這種情況。
訂閱者用作自定義報表生成器（以及其他用途）的後端，它不能很好地利用索引，因此表經常被鎖定幾分鐘。
你是什麼意思不能使用索引？您的意思是訂閱者表上的索引不適合您正在執行的報告嗎？如果是這樣，我建議不要複製非聚集索引並創建適合訂閱者的索引。您的非聚集索引不必複製，這是複制用於報告目的的優勢之一，因此您可以將訂閱伺服器上的索引策略定位到報告而不是像發布伺服器那樣的操作訪問。