Problembeschreibung
Gehen Sie davon aus, dass Sie das Feature AlwaysOn-Verfügbarkeitsgruppen in Microsoft SQL Server 2012 verwenden. 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 beim sekundären Replikat auftritt, können aufgrund eines Fehlers während der Redo-Phase der Synchronisierung nicht wiederhergestellt werden. Das sekundäre Replikat wird nicht mit dem primären Replikat synchronisiert, und es wird ein Synchronisierungsstatus von "SUSPEND_FROM_REDO" gemeldet. Darüber hinaus erhalten Sie die folgenden Fehlermeldungen im Fehlerprotokoll von SQL Server, das das sekundäre Replikat hostet:
<Datum> <Uhrzeit> SPID -<-ID> Fehler: 17066, Schweregrad: 16, Bundesland: 1. <Datum> <Uhrzeit> SPID -> <0-ID> SQL Server-Assertion: Datei: <Page. cpp>, Zeile = 3898 fehlerhafte Assertion = "! pageFull". Dieser Fehler kann Zeit bezogen sein. Wenn der Fehler nach der erneuten Ausführung 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 Datenstrukturen im Arbeitsspeicher nicht beschädigt sind. <Datum> <Uhrzeit> SPID -<-ID> Fehler: 3624, Schweregrad: 20, Bundesland: 1 . <Datum> <Uhrzeit Weitere Informationen finden Sie im SQL Server-Fehlerprotokoll. In der Regel wird ein Assertionsfehler durch einen Softwarefehler oder Datenbeschädigung verursacht. Wenn Sie nach einer Datenbankbeschädigung suchen möchten, sollten Sie DBCC CHECKDB ausführen. Wenn Sie während des Setups zugestimmt haben, Dumps an Microsoft zu senden, wird ein Mini-dump an Microsoft gesendet. Möglicherweise ist ein Update von Microsoft im neuesten Service Pack oder in einem QFE vom technischen Support erhältlich. <Datum> <Uhrzeit> SPID -<-ID> AlwaysOn-Verfügbarkeitsgruppen Daten Bewegung für Datenbank "<Datenbankname>" wurde aus folgendem Grund angehalten: "System" (Quell-ID 2; Quellzeichenfolge: "SUSPEND_FROM_REDO"). Wenn Sie die Datenverschiebung in der Datenbank fortsetzen möchten, müssen Sie die Datenbank manuell fortsetzen. Informationen zum Fortsetzen einer verfügbarkeitsdatenbank finden Sie unter SQL Server-Online Dokumentation. <Datum> <Uhrzeit> SPID -<-ID> Fehler: 3313, Schweregrad: 21, Bundesland: 2. <Datum> <Uhrzeit> SPID -> <0-ID> während der Wiedergabe eines protokollierten Vorgangs in der Datenbank "<Datenbankname>" ist ein Fehler bei der Protokolldatensatz 1786:4978584:74- In der Regel wird der spezifische Fehler im Windows-Ereignisprotokolldienst zuvor als Fehler protokolliert. Stellen Sie die Datenbank aus einer vollständigen Sicherung wieder her, oder reparieren Sie die Datenbank. <Datum> <Uhrzeit> SPID -<-ID> Alter DB param-Option: Resume<Datum> <Uhrzeit> SPID -> <0-ID> AlwaysOn-Verfügbarkeitsgruppen Datenverschiebung für Datenbank "<Datenbankname>" wurde fortgesetzt. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich. <Datum> <Uhrzeit> SPID -<-ID> nicht qualifizierte Transaktionen werden in Database <Datenbanknamen> für eine AlwaysOn-Verfügbarkeitsgruppen-Statusänderung zurückgesetzt. Geschätzte Rollback-Vervollständigung: 100%. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich. <Datum> <Uhrzeit> SPID -<-ID> AlwaysOn-Verfügbarkeitsgruppen Verbindung mit primärer Datenbank für sekundäre Datenbank "<Datenbankname>" auf dem verfügbarkeitsreplikat mit Replikat-ID: {bbdedecb-f26b-47e9-9e7d-7c22f99edb23} beendet. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich. <Datum> <Uhrzeit> SPID -<-ID> das Starten der Datenbank "<Datenbankname>". <Datum> <Uhrzeit> SPID> <2 -ID> Wiederherstellung der Datenbank "<Datenbankname>" (13) ist 0% abgeschlossen (ungefähr 781 Sekunden verbleiben). Phase 1 von 3. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.......
Fehlerbehebung
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
Jedes neue kumulative Update für SQL Server enthält alle Hotfixes und alle Sicherheitsupdates, die im vorherigen kumulativen Update enthalten waren. Schauen 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. Mithilfe der beiden folgenden Methoden können Sie den Lesezugriff auf verfügbarkeitsdatenbanken auf dem sekundären Replikat einrichten:
-
Den Lesezugriff mithilfe des Befehls Alter Availability Group einstellen:
ALTER AVAILABILITY GROUP [AGName]MODIFY REPLICA ON N'<SRV>' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))
-
Festlegen des Lesezugriffs durch Ändern der Einstellungen im Objekt-Explorer von SQL Server Management Studio (SSMS):
-
Stellen Sie eine Verbindung mit dem Server her, und öffnen Sie dann den AlwaysOn-Verfügbarkeits Ordner.
-
Öffnen Sie den Ordner "Verfügbarkeitsgruppen".
-
Klicken Sie mit der rechten Maustaste auf die verfügbarkeitsgruppe, und wählen Sie Eigenschaftenaus.
-
Ändern Sie die lesbare sekundäre Eigenschaft für das sekundäre Replikat in Nein, und klicken Sie dann auf OK.
-
Status
Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.
