Die Wiederherstellung kann fehlschlagen oder lange dauern, wenn eine Abfragebenachrichtigung in einer Datenbank verwendet wird.

  • Artikel

Dieser Artikel hilft Ihnen, das Problem zu beheben, bei dem die Wiederherstellung fehlschlägt oder lange dauern kann, wenn eine Abfragebenachrichtigung in einer Datenbank verwendet wird.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 2483090

Symptome

Möglicherweise bemerken Sie eines oder mehrere der folgenden Symptome bei einer Datenbank, die für Abfragebenachrichtigungsabonnements konfiguriert ist:

  • Symptom 1: Beim Wiederherstellen der Datenbank aus ihrer Sicherung tritt möglicherweise ein Fehler mit der Fehlermeldung 1205 auf, wenn NEW_BROKER Option während des Wiederherstellungsvorgangs angegeben wird. Darüber hinaus werden Speicherabbilddateien im Ordner Errorlog des SQL Server generiert.

  • Symptom 2: Beim Wiederherstellen der Datenbank aus der Sicherung tritt ein Fehler auf, und die Datenbank wird offline geschaltet. Darüber hinaus werden die folgenden Meldungen im SQL Server Fehlerprotokoll protokolliert:

    <Datetime> spid61 Fehler: 9768, Schweregrad: 16, Status: 1.
    <Datetime> spid61 Ein Datenbankbenutzer, der der sicheren Konversation zugeordnet ist, wurde gelöscht, bevor Anmeldeinformationen mit dem fernen Endpunkt ausgetauscht wurden. Vermeiden Sie die Verwendung von DROP USER, während Unterhaltungen erstellt werden.
    <Datetime> spid61 Konnte in der Datenbank "5" aufgrund des folgenden Fehlers beim Öffnen der Datenbank nicht nach ausstehenden Abfragebenachrichtigungen suchen: "Ein datenbankbenutzer, der der sicheren Konversation zugeordnet ist, wurde gelöscht, bevor Anmeldeinformationen mit dem fernen Endpunkt ausgetauscht wurden. Vermeiden Sie die Verwendung von DROP USER, während Unterhaltungen erstellt werden. Fehler beim Bereinigungsvorgang für Abfragebenachrichtigungsabonnements. Weitere Informationen finden Sie unter vorherige Fehler.
    <Datetime> spid61 Fehler: 9001, Schweregrad: 16, Status: 5.
    <Datetime> spid61 Das Protokoll für die Datenbank "Test" ist nicht verfügbar. Überprüfen Sie das Ereignisprotokoll auf zugehörige Fehlermeldungen. Beheben Sie alle Fehler, und starten Sie die Datenbank neu.
    <Datetime> spid61 Fehler: 3314, Schweregrad: 21, Status: 4.
    <Datetime> spid61 Beim Rückgängigmachen eines protokollierten Vorgangs in der Datenbank "Test" ist bei der Protokolldatensatz-ID (1835:7401:137) ein Fehler aufgetreten. In der Regel wird der spezifische Fehler zuvor als Fehler im Windows-Ereignisprotokolldienst protokolliert. Stellen Sie die Datenbank oder Datei aus einer Sicherung wieder her, oder reparieren Sie die Datenbank.

    Hinweis

    Das Problem kann während der Wiederherstellungsphase der Datenbank auftreten. Die Wiederherstellung wird auch für eine Datenbank ausgeführt, wenn die Datenbank online geschaltet wird, der Server neu gestartet wird usw.

  • Symptom 3: Das Wiederherstellen der Datenbank aus der Sicherung kann lange dauern, und Meldungen ähnlich den folgenden werden in SQL Server Fehlerprotokoll protokolliert:

    Date Time SPID Die Übermittlung der Abfragebenachrichtigung konnte keine Nachricht im Dialogfeld '{ Dialog-ID }.' senden. Fehler bei der Übermittlung für die Benachrichtigung "?<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>' aufgrund des folgenden Fehlers in Service Broker: 'Das Konversationshandle "<Conversation Handler>" wurde nicht gefunden.'.

    Hinweis

    Das Problem kann während der Wiederherstellungsphase der Datenbank auftreten. Die Wiederherstellung wird auch für eine Datenbank ausgeführt, wenn die Datenbank online geschaltet wird, der Server neu gestartet wird usw.

Ursache

Ursache für Symptom 1: Wenn Sie während des Wiederherstellungsvorgangs NEW_BROKER Option angeben, versucht SQL Server, alle mit Service Broker verknüpften Tabellen abzuschneiden. Zum Abschneiden ist SCH_M Sperre für das abgeschnittene Objekt erforderlich. Die Standard Transaktion verfügt daher über eine SCH_M Sperre für sysdesend. Wenn eine Datenbank wiederhergestellt oder wiederhergestellt wird, versucht SQL Server standardmäßig, alle ausstehenden Abfragebenachrichtigungen auszulösen, sodass Rows(Messages) in die sysdesend-Tabelle eingefügt werden müssen. Dieser Vorgang erfordert eine SCH_S Sperre für die Tabelle. Dieser Vorgang erfolgt jedoch bei einer anderen Transaktion, und der Versuch, SCH_S Sperre abzurufen, wird durch die SCH_M Sperre blockiert, die von der ersten Transaktion gehalten wird. Daher wird der Thread, der die Wiederherstellung ausführt, jetzt für eine Ressource blockiert, die er besitzt. Dies wird als Selbst-Deadlock bezeichnet. Der Deadlock wird vom Deadlockmonitor erkannt, und der Thread wird beendet, wodurch der Wiederherstellungsvorgang beendet wird.

Weitere Informationen zu Sperren finden Sie unter Sperrmodi. Die anderen Symptome, die im Abschnitt Symptome erläutert werden, werden aufgrund bekannter Probleme verursacht, die in den im Abschnitt "Lösung" unten erwähnten Korrekturartikeln dokumentiert sind.

Lösung

Problemumgehung für Symptom 1: Sie können das Problem umgehen, indem Sie das Ablaufverfolgungsflag 9109 auf Sitzungsebene aktivieren, bevor Sie den Wiederherstellungsvorgang versuchen. Unten sehen Sie ein Beispielskript:

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

Hinweis

Nachdem die Datenbank vollständig wiederhergestellt oder wiederhergestellt wurde, wird dringend empfohlen, dass Sie überprüfen, ob Abfragebenachrichtigungen ausgelöst werden. Die einfachste Möglichkeit, dies zu erreichen, besteht darin, die status der Datenbank in Schreibgeschützt zu ändern und sie wieder in Lese-/Schreibzugriff zu ändern. Andere Möglichkeiten, die Sie überprüfen können, sind das Trennen und Erneutes Anfügen der Datenbank, das Neustarten SQL Server usw.

Sie können das Problem auch vollständig vermeiden, indem Sie nicht angeben, indem Sie die Option NEW_BROKER für den Wiederherstellungsvorgang nicht angeben und stattdessen mit NEW_BROKER Option verwendenALTER DATABASE, nachdem die Datenbank wiederhergestellt wurde.

Weitere Informationen finden Sie unter DBCC TRACEON – Ablaufverfolgungsflags (Transact-SQL).