Problembeschreibung
Stellen Sie sich folgendes Szenario vor:
-
Sie führen Microsoft SQL Server 2014 oder Microsoft SQL Server 2012 Service Pack 2 (SP2) auf einem Server aus, der als Teil eines parallelen Upgrades das sekundäre Replikat einer verfügbarkeitsgruppe hostet.
-
Sie haben eine der folgenden Updates auf die SQL Server-Installation angewendet:
-
SQL Server 2014 Kumulatives Update 5
-
SQL Server 2012 Service Pack 2-Kumulatives Update 4
-
SQL Server 2012 Service Pack 2-Kumulatives Update 3
Wichtig Der Hotfix, der in diesem Artikel erwähnt wird, ersetzt diese kumulativen Updates. Installieren Sie diese Updates nicht, wenn Sie dies noch nicht getan haben.
-
-
Um die Installation des kumulativen Updates abzuschließen, starten Sie dieses sekundäre Replikat neu.
-
Sie führen einen Failover der verfügbarkeitsgruppe durch, die das aktualisierte sekundäre Replikat in die primäre Rolle umwandelt.
In diesem Szenario können eines oder mehrere der folgenden Symptome auf dem Server auftreten, auf dem SQL Server ausgeführt wird und der jetzt das primäre Replikat ihrer verfügbarkeitsgruppe hostet:
-
Die sekundären Replikate werden als "nicht synchronisiert" gemeldet.
-
Wenn Sie sys.dm_exec_requests Abfragen, bemerken Sie die zeitweilige Blockierung von Sperren zwischen Benutzersitzungen und einer Sitzung, deren Befehl als "DB_STARTUP" gemeldet wird. Sie können auch feststellen, dass zwischen dem Prüfpunkt und DB_STARTUP Befehlen blockiert wird.
-
Deadlocks, die die Sitzung einbeziehen, die eine ihrer verfügbarkeitsdatenbanken wiederhergestellt hat, werden im SQL Server-Fehlerprotokoll angezeigt. Diese Protokolle ähneln den folgenden: <date/time> spid<xx> Recovery is writing a checkpoint in database <dbname/dbid>. This isan informational message only. No user action is required.<date/time> spid<xx> Recovery completed for database <dbname/dbid> in <x> second(s) (analysis<x> ms, redo <x> ms, undo <x> ms.) This is an informational message only. No user action is required.…<date/time> spid<xx> Error: 1205, Severity: 13, State: 28.<date/time> spid<xx> Transaction (Process ID <xx>) was deadlocked on lock resources with anotherprocess and has been chosen as the deadlock victim. Rerun the transaction.
-
Wenn Ihre verfügbarkeitsdatenbank für Microsoft SQL Server Service Broker aktiviert ist, werden Nachrichten in ihrer verfügbarkeitsdatenbank möglicherweise nicht erfolgreich verarbeitet. Wenn Sie das Tool Profiler-Ablaufverfolgung starten und dann das Ereignis "Broker: Message klassifizieren" aufzeichnen, wird das folgende Ereignis erfasst:
9791, der Broker ist in der Datenbank des Absenders deaktiviert
Hinweis Dies ist kein systematisches Problem. Möglicherweise können Sie diese kumulativen Updates auf eine AlwaysOn-Konfiguration anwenden, ohne dass dieses Problem auftritt. Wenn Sie diese kumulativen Updates bereits angewendet haben und Sie dieses Problem nicht bemerkt haben, ist Ihr System nicht betroffen, und diese Informationen gelten nicht für Sie.
Ursache
Dieses Problem tritt auf, weil es manchmal zu einer Racebedingung zwischen den System-Threads und den Benutzer Verbindungen kommt. Dadurch wird verhindert, dass die Patch-Logik des kumulativen Updates die Sperren erhält, die erforderlich sind, um den Updateprozess abzuschließen.
Fehlerbehebung
Um dieses Problem zu beheben, wenden Sie den folgenden kritischen on-Demand (COD)-Hotfix an :
3034679 Fix: AlwaysOn-Verfügbarkeitsgruppen werden möglicherweise als nicht synchronisiert gemeldetWichtig Sie müssen diesen COD-Hotfix anstelle der folgenden kumulativen Updates anwenden:
-
SQL Server 2014 Kumulatives Update 5
-
SQL Server 2012 Service Pack 2-Kumulatives Update 4
-
SQL Server 2012 Service Pack 2-Kumulatives Update 3
Hinweis Wenn Sie diese kumulativen Updates bereits angewendet haben, müssen Sie die folgenden Schritte ausführen, um dieses Problem zu beheben.
Problemumgehung
Da dieses Problem durch Konflikte zwischen der Benutzersitzung und der Upgrade-Sitzung für die verfügbarkeitsdatenbanken verursacht wird, während die Datenbanken zur primären Rolle wechseln, müssen Sie diese Konflikte eliminieren, damit die Datenbankennach diesem Zustand wiederhergestellt werden können. Führen Sie die folgenden Schritte aus, um dieses Problem zu umgehen:
-
Probieren Sie die folgenden Methoden in der angegebenen Reihenfolge aus.
Methode 1: Entfernen des DatenbankzugriffsWenn für Datenbanken die Symptome auftreten, die im Abschnitt "Problembeschreibung" erwähnt werden, verwenden Sie einen oder beide der folgenden Schritte, um die Blockierungs Sperre zu eliminieren:
-
Abfrage sys.dm_exec_requests , um Sitzungen zu finden, in denen Blockierungs Sperren in den verfügbarkeitsdatenbanken auftreten. Verwenden Sie die Kill -Anweisung, um diese Sitzungen zu beenden.
-
Deaktivieren oder beenden Sie die Anwendung, die auf die verfügbarkeitsdatenbanken zugreift.
Wenn Methode 1 das Problem nicht löst, gehen Sie zu Methode 2.
Methode 2: Neustarten des SQL Server-HostserversWenn Anwendungszugriff und Benutzer Zugriff weiterhin deaktiviert sind, starten Sie die Instanz von SQL Server neu, die die betroffenen verfügbarkeitsdatenbanken hostet. Gehen Sie dazu wie folgt vor:
-
Deaktivieren Sie das automatische Failover der verfügbarkeitsgruppe.
-
Starten Sie die betroffene Instanz von SQL Server neu, die das primäre Replikat hostet.
-
Aktivieren Sie das automatische Failover der verfügbarkeitsgruppe.
-
-
Nachdem die betroffenen Datenbanken vollständig wiederhergestellt wurden, können Sie die Anwendungs-und Benutzerkonnektivität wiederherstellen.
Status
Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.
Informationsquellen
Weitere Informationen zu den kumulativen Updates, die von diesem Problem betroffen sind, finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:
