KB3054530 – KORREKTUR: Beschädigung tritt auf Seiten des sekundären Replikats auf, wenn Sie das sekundäre Replikat in nicht lesbar ändern

Gilt für
SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Standard

Symptome

Angenommen, Sie verwenden das Feature AlwaysOn-Verfügbarkeitsgruppen in Microsoft SQL Server 2012. Wenn Sie den Verbindungszugriff des sekundären Replikats von "lesbar" in "unlesbar" ändern, tritt eine Beschädigung auf Seiten auf, die die Seitenkomprimierung im angegebenen Replikat verwenden.

Verfügbarkeitsdatenbanken, bei denen dieses Problem auf dem sekundären Replikat auftritt, können aufgrund eines Fehlers während der Wiederholungsphase der Synchronisierung nicht wiederhergestellt werden. Das sekundäre Replikat wird nicht mit dem primären Replikat synchronisiert und meldet den Synchronisierungsstatus "SUSPEND_FROM_REDO". Darüber hinaus erhalten Sie die folgenden Fehlermeldungen im Fehlerprotokoll von SQL Server, die das sekundäre Replikat hostet:

Hinweis

< Datum><Zeit> spid<ID-Fehler> : 17066, Schweregrad: 16, Status: 1.
< Datum><Zeit> spid<ID> SQL Server Assertion: File: <page.cpp>, line=3898 Failed Assertion = '!pageFull'. Dieser Fehler kann zeitlich bedingt sein. Wenn der Fehler nach dem erneuten Ausführen der Anweisung weiterhin auftritt, verwenden Sie DBCC CHECKDB, um die Datenbank auf strukturelle Integrität zu überprüfen, oder starten Sie den Server neu, um sicherzustellen, dass die In-Memory-Datenstrukturen nicht beschädigt sind.
< Datum><Zeit> spid<ID> Fehler: 3624, Schweregrad: 20, Status: 1.
< Datum><Zeit> spid<ID> Eine Systemassertionsprüfung ist fehlgeschlagen. Weitere Informationen finden Sie im SQL Server Fehlerprotokoll. In der Regel wird ein Assertionsfehler durch einen Softwarefehler oder eine Datenbeschädigung verursacht. Erwägen Sie die Ausführung von DBCC CHECKDB, um nach einer Beschädigung der Datenbank zu suchen. Wenn Sie während des Setups zugestimmt haben, Dumps an Microsoft zu senden, wird ein Minidump an Microsoft gesendet. Möglicherweise ist ein Update von Microsoft im neuesten Service Pack oder in einem QFE des technischen Supports verfügbar.
< Datum><Zeit> Spid<ID> AlwaysOn-Verfügbarkeitsgruppen datenverschiebung für datenbank '<DataBase Name>' wurde aus folgendem Grund angehalten: "system" (Quell-ID 2; Quellzeichenfolge: 'SUSPEND_FROM_REDO'). Um die Datenverschiebung in der Datenbank fortzusetzen, müssen Sie die Datenbank manuell fortsetzen. Informationen zum Fortsetzen einer Verfügbarkeitsdatenbank finden Sie in der SQL Server-Onlinedokumentation.
< Datum><Zeit> spid<ID> Fehler: 3313, Schweregrad: 21, Status: 2.
< Datum><Zeit>spid-ID>< Beim Wiederholen eines protokollierten Vorgangs in der Datenbank "<DataBase Name>" ist bei der Protokolldatensatz-ID (1786:4978584:74) ein Fehler aufgetreten. In der Regel wird der spezifische Fehler zuvor als Fehler im Windows-Ereignisprotokolldienst protokolliert. Stellen Sie die Datenbank aus einer vollständigen Sicherung wieder her, oder reparieren Sie die Datenbank.
< Datum><Zeit> spid<ID> ALTER DB param-Option: RESUME
< Datum><Zeit> Die Datenverschiebung der spid<ID> AlwaysOn-Verfügbarkeitsgruppen für die Datenbank "<DataBase Name>" wurde fortgesetzt. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit> spid<ID> Nicht qualifizierte Transaktionen werden im Datenbankdatenbanknamen>< für eine Änderung des Status von AlwaysOn-Verfügbarkeitsgruppen zurückgesetzt. Geschätzter Rollbackabschluss: 100 %. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit> Spid<ID> AlwaysOn-Verfügbarkeitsgruppenverbindung mit der primären Datenbank, die für die sekundäre Datenbank "<DataBase Name>" auf dem Verfügbarkeitsreplikat mit der Replikat-ID beendet wurde: {bbdecb-f26b-47e9-9e7d-7c22f99edb23}. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit> spid<ID> Startet die Datenbank "<DataBase Name>".
< Datum><Zeit> spid<ID> Wiederherstellung der Datenbank "<DataBase Name>" (13) ist 0 % abgeschlossen (ca. 781 Sekunden verbleiben). Phase 1 von 3. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.
……

Lösung

Das Problem wurde zuerst im folgenden kumulativen Update von SQL Server behoben.

Kumulatives Update 6 für SQL Server 2012 SP2

            
             Kumulatives Update 16 für SQL Server 2012 SP1
          

Informationen zu kumulativen Updates für SQL Server

Jedes neue kumulative Update für SQL Server enthält alle Hotfixes und alle Sicherheitsfixes, die im vorherigen kumulativen Update enthalten waren. Sehen Sie sich die neuesten kumulativen Updates für SQL Server an:

      

Weitere Informationen

Das vorherige Problem kann auftreten, wenn der Lesezugriff für das sekundäre Replikat geändert wird.
Sie können den Lesezugriff von Verfügbarkeitsdatenbanken auf dem sekundären Replikat mit den folgenden beiden Methoden festlegen:

  • Legen Sie den Lesezugriff mithilfe des Befehls ALTER AVAILABILITY GROUP fest:

    ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON N'<SRV>' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))

  • Legen Sie den Lesezugriff fest, indem Sie die Einstellungen in Objekt-Explorer von SQL Server Management Studio (SSMS) ändern:

    • Stellen Sie eine Verbindung mit dem Server her, und öffnen Sie dann den Ordner AlwaysOn-Verfügbarkeit.
    • Öffnen Sie den Ordner Verfügbarkeitsgruppen.
    • Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, und wählen Sie Eigenschaften aus.
    • Ändern Sie die Eigenschaft Lesbares sekundäres Replikat in Nein, und klicken Sie dann auf OK.

Status

Microsoft hat bestätigt, dass dies ein Problem bei den Microsoft-Produkten ist, die im Abschnitt „Gilt für“ aufgeführt sind.