訂閱者中刪除的行 - 怎麼辦？- SQL Server 事務複製

有人錯誤地刪除了訂閱伺服器/數據庫中的一行表。

我收到以下錯誤消息：

對主鍵為 (null) 的表應用複制 (null) 命令時，在訂閱伺服器上未找到該行：(null)（來源：MSSQLServer，錯誤號：20598）

現在我已經在複製的伺服器中恢復了已刪除的行，但是訂閱者代理的分發器需要很長時間才能應用更改（目前將近 1.5 小時）。

我怎樣才能讓它立即進行此更新？

如果您錯誤地刪除了訂閱伺服器上應該通過複製接收更新的行，最簡單的修復方法是在訂閱伺服器上重建與更新失敗的行匹配的缺失行。

一旦該行在訂閱者上，更新就可以成功執行（即使它只是將相同的值寫入所需的列），然後複製應該繼續愉快地進行。

我過去也發生過同樣的情況，並且複制繼續沒有問題。

以下是複制命令需要更長時間才能應用於訂閱者的指標：

1. 檢查分發代理作業歷史記錄。檢查<stats state="2"

Article Level Parameterized Command Stats
*******************************************************************************

2017-12-28 00:01:47.952 <stats state="1" work="4274" idle="0"><reader fetch="12" wait="4274"/><writer write="4274" wait="11"/><sincelaststats elapsedtime="668" work="664" cmds="111" cmdspersec="0.000000"><reader fetch="3" wait="664"/><writer write="664" wait="3"/></sincelaststats><message>Normal events that describe both the reader and writer thread performance.</message></stats>
2017-12-28 00:02:49.529 9 transaction(s) with 9 command(s) were delivered.
2017-12-28 00:03:50.762 10 transaction(s) with 10 command(s) were delivered.
2017-12-28 00:05:00.082 13 transaction(s) with 12 command(s) were delivered.
2017-12-28 00:06:01.771 11 transaction(s) with 12 command(s) were delivered.
2017-12-28 00:06:47.991 <stats state="2" fetch="12" wait="4573" cmds="42123" callstogetreplcmds="9"><sincelaststats elapsedtime="300" fetch="0" wait="299" cmds="42123" cmdspersec="140.000000"/><message>Raised events that occur when an agent's reader thread waits longer than the agent's -messageinterval time. (By default, the time is 60 seconds.) If you notice State 2 events that are recorded for an agent, this indicates that the agent is taking a long time to write changes to the destination.</message></stats>
2017-12-28 00:07:03.974 10 transaction(s) with 9 command(s) were delivered.
2017-12-28 00:08:04.304 11 transaction(s) with 12 command(s) were delivered.
2017-12-28 00:09:15.350 12 transaction(s) with 11 command(s) were delivered.

2. 仍在分銷代理工作歷史上。您可以查看分發代理的作者和讀者執行緒上的統計資訊。（例如。Time to Apply Cmds (ms) : 4752946）

************************ STATISTICS SINCE AGENT STARTED ***********************
12-28-2017 00:09:47

Total Run Time (ms) : 4773703   Total Work Time  : 4752946
Total Num Trans     : 770   Num Trans/Sec    : 0.16
Total Num Cmds      : 769   Num Cmds/Sec     : 0.16
Total Skipped Cmds  : 0 
Total Idle Time     : 0 

Writer Thread Stats
 Total Number of Retries   : 0 
 Time Spent on Exec        : 3211250 
 Time Spent on Commits (ms): 263488    Commits/Sec         : 0.16
 Time to Apply Cmds (ms)   : 4752946   Cmds/Sec            : 0.16
 Time Spent on Schema Changes (ms) : 0
 Time Cmd Queue Empty (ms) : 12694     Empty Q Waits > 10ms: 451
 Total Time Request Blk(ms): 12694 
 P2P Work Time (ms)        : 0     P2P Cmds Skipped    : 0

Reader Thread Stats
 Calls to Retrieve Cmds    : 9 
 Time to Retrieve Cmds (ms): 4556259   Cmds/Sec            : 0.17
 Time Cmd Queue Full (ms)  : 208913    Full Q Waits > 10ms : 648

那麼為什麼命令需要更長的時間才能在訂閱者數據庫中應用？

我們需要退後一步，並在訂閱者數據庫上應用基本的 SQL Server 故障排除。檢查阻塞、IO 爭用、網路問題、檢查等待統計資訊、觸發器、游標、長時間執行的作業/事務、服務代理、AG 重做隊列等。根據我的經驗，複製性能的無聲殺手是……觸發器。除非您使用分析器或者您了解數據流的工作原理，否則您將無法捕捉到它。這些可以快速儲存待傳遞的未決命令。

我怎樣才能讓它立即進行此更新？

選項（確保在應用任何更改之前停止分發代理作業）：

1. 在訂閱者數據庫上應用缺少的命令並讓命令流向訂閱者
2. 從分發數據庫中刪除命令（在MSrepl_commands表上並確保指定xact_seqnoand command_id）。在 subsciber db 中手動應用命令。
3. 跳過缺少的命令。（不建議）
4. -CommitBatchSize將and-CommitBatchThreshold參數更改為1:1僅查看命令是否正確流向訂閱者數據庫。這也有利於故障排除以隔離問題。然後將其設置回預設值或您想要的參數。

我強烈建議您擷取複製命令統計資訊（分發代理）的基線。我們可以使用 Perfmon 來監控以下內容：

• Dist:Delivered Cmds/sec
• Dist:Delivered Trans/sec
• 地區：傳遞延遲

這將使我們了解在訂閱者數據庫中應用命令需要多長時間。命令統計數據的前後圖很重要，因為我們可以確定速度有多慢或自上次基線以來發生了什麼變化。

引用自：https://dba.stackexchange.com/questions/158973