AlwaysOn-Verfügbarkeitsgruppen werden u.U. als nicht synchronisiert gemeldet, nachdem SQL Server 2014 CU5, SQL Server 2012 SP2 CU4 oder SQL Server 2012 SP2 CU3 installiert wurde

Problembeschreibung


Betrachten Sie das folgende Szenario:
  • Microsoft SQL Server 2014 oder Microsoft SQL Server 2012 Service Pack 2 (SP2) werden auf einem Server ausgeführt, der die sekundäre Kopie einer Verfügbarkeitsgruppe als Teil eines parallelen Upgrades hostet.
  • Sie haben eines der folgenden Updates auf die SQL Server-Installation angewendet:
    • SQL Server 2014 kumulative Update 5
    • SQL Server 2012 SP2 Kumulatives Update 4
    • SQL Server 2012 Service Pack 2 kumulative Update 3
    Wichtig  Der in diesem Artikel genannte Hotfix ersetzt diese kumulativen Updates. Installieren Sie diese Updates nicht, wenn Sie nicht bereits geschehen.
     
  • Nach Abschluss der Installation des kumulativen Updates starten Sie dieses sekundäre Replikat neu.
  • Sie führen für die Verfügbarkeitsgruppe, die das aktualisierte sekundäre Replikat in die primäre Rolle überführt, ein Failover durch.
In diesem Szenario tritt mindestens eines der folgenden Symptome auf dem Server auf, auf dem SQL Server ausgeführt wird und der jetzt das primäre Replikat der Verfügbarkeitsgruppe hostet:
  • Die sekundäre Replikate wird als "Nicht synchronisiert" gemeldet.
  • Wenn Sie sys. dm_exec_requests abfragen, stellen Sie ein zeitweiliges Blockieren von Sperren zwischen Benutzersitzungen und einer Sitzung fest, deren Befehl als "DB_STARTUP" gemeldet wird Möglicherweise stellen Sie auch Sperren zwischen den Befehlen CHECKPOINT und DB_STARTUP fest.
  • Deadlocks, die die Sitzung betreffen, in der eine Verfügbarkeitsdatenbanken wiederhergestellt worden ist, werden im SQL Server-Fehlerprotokoll gemeldet. Diese Protokolle folgendermaßen aussehen:

    <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 another
    process and has been chosen as the deadlock victim. Rerun the transaction.
  • Wenn Ihre Verfügbarkeitsdatenbank für Microsoft SQL Server Service Broker aktiviert ist, können Nachrichten in der Verfügbarkeitsdatenbank möglicherweise nicht erfolgreich verarbeitet werden. Wenn Sie den Tracing Profiler starten und dann das Ereignis "Broker: Message Classify" aufnehmen, wird das folgende Ereignis aufgezeichnet:

    9791, Der Broker in der Absenderdatenbank ist deaktiviert.
Hinweis Dies ist kein systematisches Problem. Sie können diese kumulative Updates für eine AlwaysOn-Konfiguration installieren, ohne dass dieses Problem auftritt. Wenn Sie diese kumulative Updates bereits installiert haben und Sie dieses Problem nicht feststellen, ist Ihr System nicht beeinträchtigt, und diese Informationen gelten nicht für Sie.

Ursache

Dieses Problem tritt auf, weil gelegentlich eine Racebedingung zwischen Systemthreads und den Benutzerverbindungen auftreten kann. Verhindert die Patches Logik des kumulativen Updates abrufen Sperren bis zum Abschluss der Aktualisierung erforderlich sind.

Problemlösung

Zum Beheben dieses Problems den Hotfix folgende wichtige bei Bedarf (COD) :

3034679 BEHEBEN: AlwaysOn Availability Gruppen können gemeldete NICHT SYNCHRONISIERT

Wichtig  Sie müssen diesen COD-Hotfix statt die folgenden kumulativen Updates anwenden:
  • SQL Server 2014 kumulative Update 5
  • SQL Server 2012 SP2 Kumulatives Update 4
  • SQL Server 2012 Service Pack 2 kumulative Update 3


Hinweis Wenn Sie diese kumulative Updates bereits installiert haben, müssen Sie die folgende Problemumgehung zur Behebung dieses Problems verwenden.

PROBLEMUMGEHUNG

Da dieses Problem durch Konflikte zwischen der Benutzersitzung und der Upgradesitzung bezüglich der Verfügbarkeitsdatenbank während des Übergangs der Datenbank zur primären Rolle verursacht wird, müssen Sie diese Konflikte beseitigen, damit die Datenbanken aus diesem Zustand wiederhergestellt werden kann.

Führen Sie dazu folgende Schritte gegebenenfalls anlog aus.
  1. Versuchen Sie die folgenden Methoden in der angegebenen Reihenfolge.

    Methode 1: Eliminieren Sie Datenbankzugriff
    Wenn bei Datenbanken die Symptome auftreten, die im Abschnitt "Symptome" aufgeführt sind, verwenden Sie eine oder beide der folgenden Schritte nach Bedarf, um die Bedingung zu entfernen, durch die Sperren blockiert werden:
    • Führen Sie die Abfrage dm_exec_requests aus, um die Sitzungen zu finden, in denen in den Verfügbarkeitsdatenbanken Sperren blockiert werden. Verwenden Sie die Anweisung KILL, um diese Sitzung zu beenden.
    • Deaktivieren Sie oder beenden Sie die Anwendung, die auf die Verfügbarkeitsdatenbanken zugreift.

    Wenn das Problem nicht mit Methode 1 behoben werden konnte, fahren Sie mit Methode 2 fort.


    Methode 2: Starten Sie den SQL Server-Hostserver
    Wenn Anwendungs- und Benutzerzugriff noch deaktiviert sind, starten Sie die Instanz von SQL Server neu, die die betroffene Verfügbarkeit-Datenbanken hostet. Gehen Sie hierzu folgendermaßen vor:
    1. Deaktivieren Sie das automatisches Failover der Verfügbarkeitsgruppe.
    2. Starten der betroffene Instanz von SQL Server, welche das primäre Replikat hostet.
    3. Aktivieren Sie das automatische Failover der Verfügbarkeitsgruppe.
  2. Nachdem die betroffenen Datenbanken vollständig wiederhergestellt worden sind, stellen Sie die Anwendungs- und Benutzerkonnektivität wieder her.

Status

Microsoft hat bestätigt, dass es sich um ein Problem bei den Microsoft-Produkten handelt, die im Abschnitt „Eigenschaften“ aufgeführt sind.

Referenzen

Weitere Informationen zu den kumulativen Updates, die von diesem Problem betroffen sind, finden Sie in folgenden Artikeln der Microsoft Knowledge Base:
Eigenschaften

Artikelnummer: 3033492 – Letzte Überarbeitung: 10.01.2017 – Revision: 1

Feedback