如何修復 MS SQL Server 上的複制混亂

我從備份中恢復了一個數據庫。數據庫使用複制發佈到不同的伺服器。假設數據庫還原會破壞複製，我嘗試刪除複製並重新創建它（我們有一個腳本可以從頭開始重新創建它）。我不確定我到底做了什麼，但現在它處於完全混亂的狀態，我無法修復它。

首先，我嘗試擺脫訂閱（在發布伺服器上）：

EXEC sp_dropsubscription @publication = 'PublicationName', @article = N'all', @subscriber = 'SubscriberServerName'

這似乎有效。SELECT * FROM syssubscriptions顯示沒有結果。查看訂閱伺服器，SSMS > {SubscriberServer} > 複製 > 本地訂閱 - 訂閱不存在。

因此，我嘗試刪除該出版物。SSMS > {Server} > 複製 > 本地出版物 > {PublicationName} > 刪除。這給出了以下錯誤消息：

Could not delete publication 'PublicationName'.
Could not drop article. A subscription exists on it.
Changed database context to 'DatabaseName'. (Microsoft SQL Server, Error: 14046)

好的，所以我嘗試刪除文章：

EXEC sp_droparticle @publication = 'PublicationName', @article = N'all'

並得到這個錯誤：

Invalidated the existing snapshot of the publication. Run the Snapshot Agent again to generate a new snapshot.
Msg 14046, Level 16, State 1, Procedure sp_MSdrop_article, Line 75
Could not drop article. A subscription exists on it.

好的，所以我嘗試啟動快照代理，我得到了這個內部 SQL 異常：

The SQL command 'sp_MSactivate_auto_sub' had returned fewer rows than expected by the replication agent.

所以我嘗試了另一種刪除文章的方法，DELETE FROM sysarticles. 這似乎奏效了 - 我現在已經刪除了這些文章，但是當我嘗試刪除該出版物時，我仍然得到相同的“無法刪除該出版物，因為該出版物至少存在一個訂閱”錯誤。

我還重新啟動了 SQL Server - 沒有幫助。

我不知道這裡發生了什麼，我該如何解決？

順便說一句，當你給一個知道足夠危險的軟體開發人員提供數據庫的密鑰時，就會發生這種情況。幸運的是，這不是生產環境……

TLDR：

似乎禁用和重新啟用複制可能解決了這個問題：

exec sp_replicationdboption @dbname = N'DatabaseName', @optname = N'publish', @value = N'false'
exec sp_replicationdboption @dbname = N'DatabaseName', @optname = N'publish', @value = N'true'

我想這相當於將其關閉然後重新打開…

更長的版本：

一位同事試圖修復它。他嘗試了一些東西，但沒有走得很遠。他在放棄之前所做的一項更改是禁用複制。

然後我嘗試了 Cody 的建議。sp_dropsubscription 命令抱怨不存在訂閱。所以我嘗試了 sp_droppublication 命令。這抱怨沒有在數據庫上啟用複制。所以我啟用它並重新執行命令。這次它抱怨該出版物不存在。我刷新了 SSMS 中的 Local Publications 節點，果然它已經消失了。我執行了複製設置腳本，生成了一個新快照，現在一切正常。喜悅！

我不能 100% 確定禁用和啟用複制是真正解決問題的方法，但如果複製搞砸了，絕對值得一試。

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