KB3054530 – FIX: Seiten des sekundären Replikats werden beschädigt, wenn Sie das sekundäre Replikat in "unlesbar" ändern

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

Symptome

Nehmen wir an, 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, das das sekundäre Replikat hostet:

Hinweis

< Datum><Zeit>SPID-ID-Fehler><: 17066, Schweregrad: 16, Zustand: 1.
< Datum><Zeit>SPID-ID>< SQL Server Assertion: File: File: <page.cpp>, line=3898 Failed assertion = '!pageFull'. Dieser Fehler kann mit dem Timing zusammenhängen. Wenn der Fehler nach dem erneuten Ausführen der Anweisung weiterhin besteht, 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 Systembestätigungsprü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. Um eine Datenbankbeschädigung zu ermitteln, führen Sie DBCC CHECKDB aus. Wenn Sie während des Setups zugestimmt haben, Speicherabbilder an Microsoft zu senden, wird ein Miniabbild an Microsoft gesendet. Ein Update ist möglicherweise 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 "<Datenbankname>" wurde aus folgendem Grund ausgesetzt: "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>< Während der Wiederholung eines protokollierten Vorgangs in der Datenbank "<Datenbankname>" trat bei der Protokolldatensatz-ID (1786:4978584:74) ein Fehler auf. 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-Paramoption: FORTSETZEN
< Datum><Zeit>SPID-ID>< AlwaysOn-Verfügbarkeitsgruppen Die Datenverschiebung für die Datenbank "<Datenbankname>" wurde fortgesetzt. Diese Nachricht dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit>SPID-ID>< Nicht qualifizierte Transaktionen werden in der Datenbank < zurückgesetzt Datenbankname> für eine Statusänderung für AlwaysOn-Verfügbarkeitsgruppen. Geschätzte Rollback-Fertigstellung: 100 %. Diese Nachricht dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit>SPID-ID>< Verbindung von AlwaysOn-Verfügbarkeitsgruppen mit primärer Datenbank für sekundäre Datenbank "<Datenbankname>" auf dem Verfügbarkeitsreplikat mit Replikat-ID: {bbdedecb-f26b-47e9-9e7d-7c22f99edb23}. Diese Nachricht dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
< Datum><Zeit>SPID-ID>< Datenbank "<Datenbankname>" wird gestartet.
< Datum><Zeit>SPID-ID>< Die Wiederherstellung der Datenbank "<Datenbankname>" (13) ist zu 0 % abgeschlossen (es verbleiben ca. 781 Sekunden). Phase 1 von 3. Diese Nachricht dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
……

Lösung

Das Problem wurde erstmals 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 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 auf Verfügbarkeitsdatenbanken auf dem sekundären Replikat mit den folgenden beiden Methoden festlegen:

  • Legen Sie den Lesezugriff mit dem Befehl 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 im Objekt-Explorer von SQL Server Management Studio (SSMS) ändern:

    • Stellen Sie eine Verbindung mit dem Server her, und öffnen Sie 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 Lesbare sekundäre Datenbank für das sekundäre 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.