Freigeben über


Wiederherstellung oder Wiederherstellung kann fehlschlagen oder lange dauern, wenn abfragebenachrichtigung in einer Datenbank verwendet wird

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

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

Problembeschreibung

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

  • Symptom 1: Das Wiederherstellen der Datenbank aus der Sicherung kann mit einer Fehlermeldung von 1205 fehlschlagen, wenn NEW_BROKER Option während des Wiederherstellungsvorgangs angegeben wird. Darüber hinaus werden Dumpdateien im Ordner "Errorlog" von SQL Server generiert.

  • Symptom 2: Das Wiederherstellen der Datenbank aus der Sicherung schlägt fehl, und die Datenbank wird offline. 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 Unterhaltung zugeordnet ist, wurde gelöscht, bevor Anmeldeinformationen mit dem fernen Endpunkt ausgetauscht wurden. Verwenden Sie DROP USER nicht beim Erstellen von Konvertierungen.
    <Datetime> spid61 Failed to check for pending query notifications in database "5" because of the following error when opening the database: 'A database user associated with the secure conversation was dropped before credentials beentauscht with the far endpoint. Verwenden Sie DROP USER nicht beim Erstellen von Konvertierungen. Fehler beim Cleanup der Abfragebenachrichtigungsabonnements. Weitere Informationen finden Sie in den vorherigen Fehlern.'.
    <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 verwandte Fehlermeldungen. Beheben Sie ggf. 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 ein Fehler aufgetreten (1835:7401:137). Normalerweise wird der jeweilige Fehler zuvor als Fehler im Windows-Ereignisprotokoll protokolliert. Stellen Sie die Datenbank oder Datei von einer Sicherung wieder her, oder reparieren Sie die Datenbank.

    Notiz

    Möglicherweise tritt das Problem während der Wiederherstellungsphase der Datenbank auf. Die Wiederherstellung wird auch auf einer Datenbank ausgeführt, wenn die Datenbank online gebracht wird, der Server neu gestartet wird usw.

  • Symptom 3: Das Wiederherstellen der Datenbank aus der Sicherung kann eine lange Zeit dauern, und Nachrichten, die dem folgenden ähneln, werden im SQL Server-Fehlerprotokoll protokolliert:

    Die Übermittlung von SPID-Abfragebenachrichtigungen für Datumszeit konnte keine Nachricht im Dialogfeld '{ Dialog-ID }.' senden. Übermittlungsfehler bei 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>' wegen des folgenden Fehlers im Dienstbroker: 'Das Unterhaltungshandle "<Conversation Handler>" wurde nicht gefunden.'

    Notiz

    Möglicherweise tritt das Problem während der Wiederherstellungsphase der Datenbank auf. Die Wiederherstellung wird auch auf einer Datenbank ausgeführt, wenn die Datenbank online gebracht 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 zugehörigen Tabellen des Service Brokers abgeschnitten zu haben. Zum Abschneiden ist SCH_M Sperre für das abgeschnittene Objekt erforderlich. Die Haupttransaktion hält somit eine SCH_M Sperre für sysdesend. Wenn eine Datenbank wiederhergestellt oder wiederhergestellt wird, versucht SQL Server standardmäßig, alle ausstehenden Abfragebenachrichtigungen auszulöschen, bei denen Zeilen(Nachrichten) in sysdesend-Tabelle eingefügt werden müssen. Für diesen Vorgang ist eine SCH_S Sperre für die Tabelle erforderlich. Dieser Vorgang erfolgt jedoch bei einer anderen Transaktion, und der Versuch, SCH_S Sperre zu erwerben, 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 sie besitzt, die Situation, die als Self-Deadlock bezeichnet wird. Der Deadlock wird vom Deadlock-Monitor 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" weiter unten genannten Fixartikeln dokumentiert sind.

Lösung

Problemumgehung für Symptom 1: Sie können das Problem umgehen, indem Sie das Ablaufverfolgungskennzeichnung auf Sitzungsebene 9109 aktivieren, bevor Sie den Wiederherstellungsvorgang versuchen. Nachfolgend 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

Notiz

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

Sie können das Problem auch vollständig vermeiden, 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 – Trace Flags (Transact-SQL).For more information, see DBCC TRACEON - Trace Flags (Transact-SQL).