如果在資料庫中使用查詢通知,還原或復原可能會失敗或花費很長的時間
本文可協助您解決在資料庫中使用查詢通知時,還原或復原可能會失敗或需要很長的時間的問題。
原始產品版本: SQL S
原始 KB 編號: 2483090
徵狀
您可能會發現針對查詢通知訂閱設定的資料庫出現下列一或多個徵兆:
徵兆 1:如果在還原作業期間指定 了 NEW_BROKER 選項,則從備份還原資料庫可能會失敗並出現 1205 錯誤訊息。 此外,系統會在 SQL Server的 Errorlog 資料夾中產生傾印檔案。
徵兆 2:從備份還原資料庫失敗,且資料庫脫機。 此外,下列訊息會記錄在 SQL Server 錯誤記錄檔中:
<Datetime> spid61 錯誤:9768,嚴重性:16,狀態:1。
<Datetime> spid61 在與遠端點交換認證之前,已卸除與安全對話相關聯的資料庫使用者。 建立交談時,請避免使用DROP USER。
<Datetime> spid61 無法檢查資料庫 「5」 中是否有擱置的查詢通知,因為開啟資料庫時發生下列錯誤:「在與最遠端點交換認證之前,已卸除與安全對話相關聯的資料庫使用者。 建立交談時,請避免使用DROP USER。 查詢通知訂閱清除作業失敗。 如需詳細資訊,請參閱先前的錯誤。」
<Datetime> spid61 錯誤: 9001, 嚴重性: 16, 狀態: 5。
<Datetime> spid61 資料庫 'Test' 的記錄無法使用。 檢查事件記錄檔中是否有相關的錯誤訊息。 解決任何錯誤並重新啟動資料庫。
<Datetime> spid61 錯誤:3314,嚴重性:21,狀態:4。
<Datetime> spid61 在資料庫 『Test』 中復原記錄作業期間,記錄檔記錄標識碼 (1835:7401:137) 發生錯誤。 一般而言,先前會將特定失敗記錄為 Windows 事件記錄檔服務中的錯誤。 從備份還原資料庫或檔案,或修復資料庫。注意事項
您可能會在資料庫的復原階段遇到此問題。 當資料庫上線、伺服器重新啟動等情況時,也會在資料庫上執行復原。
徵兆 3:從備份還原資料庫可能需要很長的時間,而類似下列的訊息會記錄在 SQL Server 錯誤記錄檔中:
日期時間SPID查詢通知傳遞無法在對話框 '{ Dialog ID }.' 上傳送訊息。 通知的傳遞失敗』?<qn:QueryNotification xmlns:qn=“
https://schemas.microsoft.com/SQL/Notifications/QueryNotification
” id=“2881” type=“change” source=“database” info=“restart” database_id=“7” sid=“0x010500000000000515000000FA48F22A6990BA52422C73DFF9030000”><qn:Message>4a4c696b-645c-40fd-bfef-4f2bc7c599b4;eb99973e-3cc9-4c7e-b4b9-47d8cf590c43</qn:Message></qn:QueryNotification>',因為 Service Broker 中發生下列錯誤:「找不到交談句柄「<交談處理程式>」。」。注意事項
您可能會在資料庫的復原階段遇到此問題。 當資料庫上線、伺服器重新啟動等情況時,也會在資料庫上執行復原。
原因
徵兆 1 的原因:當您在還原作業期間指定NEW_BROKER選項時,SQL Server 嘗試截斷所有 Service Broker 相關數據表。 截斷需要SCH_M截斷對象的鎖定。 因此,主要交易會在 sysdesend 上保留SCH_M鎖定。 復原或還原資料庫時,根據預設,SQL Server 會嘗試引發所有未處理的查詢通知,這會要求數據列 (訊息) 插入 sysdesend 數據表中。 此作業需要數據表的SCH_S鎖定。 不過,這項作業會發生在不同的交易上,而第一筆交易所持有的SCH_M鎖定會封鎖取得SCH_S鎖定的嘗試。 因此,執行還原的線程現在會在它擁有的資源上遭到封鎖,這稱為自我死結。 死結監視器會偵測到死結,並終止線程,因而終止還原作業。
如需鎖定的詳細資訊,請參閱 鎖定模式。 在一節中討論的其他徵兆是因為以下解決一節所述修正文章中所述的已知問題所造成。
解決方案
徵兆 1 的因應措施:您可以在嘗試還原作業之前,先啟用會話層級追蹤旗標 9109 來解決此問題。 範例文稿如下所示:
dbcc traceon (9109)
go
RESTORE DATABASE [Test]
FROM DISK = N'C:\TestBackup.bak' WITH FILE = 1,
MOVE N'test_Data' TO N'C:\test.mdf',
MOVE N'test_Log' TO N'C:\test_1.ldf',
NOUNLOAD,
STATS = 1,
NEW_BROKER
go
dbcc traceoff (9109)
go
注意事項
資料庫完全還原或復原后,強烈建議您檢查以確定查詢通知已引發。 若要達到此目的,最簡單的方式是將資料庫的狀態變更為唯讀,並將它變更回讀寫。 您可以檢查的一些其他方式包括卸離和重新附加資料庫、重新啟動 SQL Server 等。
您也可以藉由不在還原作業上指定 NEW_BROKER 選項,而改為在還原資料庫之後搭配ALTER DATABASE
使用 NEW_BROKER 選項,來完全避免此問題。
如需詳細資訊,請 參閱 DBCC TRACEON - 追蹤旗標 (Transact-SQL) 。