Der Betrieb von SQL Server ist in hohem Maße vom Disk-Subsystem abhängig. Es ist als Speicher zweifellos eine Schlüsselkomponente für die Leistung und Verfügbarkeit von SQL Server. Manchmal kann ein Problem mit dem I/O-Subsystem zu einem CRC-Fehler (Cyclic Redundancy Check) führen. Die Fehlermeldung lautet wie folgt:
Encountered error: Msg 823, Ebene 24, Zustand 2, Zeile 1
E/A-Fehler 23 (Datenfehler (zyklische Redundanzprüfung).) wurde beim Lesen an Offset 0x000001ac1c4000 in der Datei ‘C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.mdf’ festgestellt.
Es kann ein CRC-Datenfehler in der SQL-Datenbank auftreten, wenn Sie eine der folgenden Aktionen durchführen:
- Sichern und Wiederherstellen der Datenbank
- Abfragen der Datenbank
- Starten von SQL Server
Bevor wir uns daran machen, die Ursache für diesen Fehler zu identifizieren und seine Lösung zu finden, lassen Sie uns zunächst verstehen, was die zyklische Redundanzprüfung bedeutet.
Was ist CRC?
Eine zyklische Redundanzprüfung (CRC) ist ein Datenüberprüfungsalgorithmus, den Computer verwenden, um die Daten auf Speichergeräten wie SSD, HDD, CDs, Magnetbändern und mehr zu überprüfen.
Wodurch wird der Fehler der zyklischen Redundanzprüfung in der SQL-Datenbank verursacht?
Der SQL Cyclic Redundancy Check-Fehler kann aus einem der folgenden Gründe auftreten:
- Beschädigung der Registry
- Verstopfte Festplatte
- Fehlgeschlagene Programminstallation
- Falsch konfigurierte Dateien
- Datei auf fehlerhaftem Sektor der Festplatte geschrieben
Unabhängig von der spezifischen Ursache ist der zyklische Redundanzprüfungsfehler ein schwerwiegender Fehler und muss sofort behoben werden, um einen möglichen Datenverlust oder sogar einen Totalausfall des Systems zu vermeiden.
Vorkommen des SQL-CRC-Fehlers
Im Folgenden sind zwei Szenarien aufgeführt, in denen der CRC-Fehler auftreten kann:
Szenario 1: Der Fehler kann beim Sichern einer Datenbank auftreten. Wenn der Fehler während eines Backups auftritt, können Sie die SQL Server-Fehlerprotokolle einsehen, um weitere Details über den Fehler zu erhalten.
Ein Beispiel für ein ausführliches Protokoll wird unten gezeigt:
10/18/2016 12:00:19 AM Erstellen einer Sicherung von MoreData in C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\Backup\
18.10.2016 12:00:32 UHR FEHLER: Lesen auf “C:\Programme\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.MDF” fehlgeschlagen: 23(Datenfehler (zyklische Redundanzprüfung).)
BACKUP DATABASE wird abnormal beendet.
18.10.2016 12:00:32 AM ERROR: Job beendet (mit Fehlern)
Szenario 2: Das nächste Szenario ist, wenn Sie die SQL-Datenbank abfragen und diese abrupt mit dem Datenprüfungsfehler abbricht. Bei der Abfrage der Datenbank erhalten Sie einen CRC-Fehler im Fehlerbereich von SQL Server Management Studio (SSMS). Die Fehlermeldung lautet wie folgt:
Server: Msg 823, Level 24, State 2, Zeile 1
I/O-Fehler 23 (Datenfehler (zyklische Redundanzprüfung).) wurde beim Lesen am Offset 0x000001ac1c4000 in der Datei ‘C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.mdf’ festgestellt.
Wie behebt man den SQL CRC-Fehler?
Befolgen Sie die Schritte in der unten angegebenen Reihenfolge, um den Fehler zu beheben:
Schritt 1: Da die Hauptursache für den CRC-Fehler ein Problem mit dem E/A-Subsystem ist, ist es wichtig, die zugrunde liegenden Speicherprobleme zu beheben. Das wiederum würde höchstwahrscheinlich den Fehler der zyklischen Redundanzprüfung in SQL beheben.
Führen Sie das Dienstprogramm CHKDSK auf dem betreffenden Datenträger aus und lassen Sie es den Fehler mit dem Parameter /F beheben. Nachfolgend sehen Sie einen Screenshot des Befehls zur Überprüfung und Behebung des Laufwerks F:
Schritt2: Eine vollständige Defragmentierung der Festplatte wird empfohlen, nachdem das “chkdsk”mit einer erfolgreichen Reparatur aller Fehler abgeschlossen wurde.
Schritt 3: Führen Sie eine Datenintegritätsprüfung der SQL–Datenbank durch, um sicherzustellen, dass die Daten nicht beschädigt sind. Führen Sie den unten hervorgehobenen Befehl aus und analysieren Sie die Ergebnisse:
DBCC CHECKDB (MoreData) WITH NO_INFOMSGS, ALL_ERRORMSGS
Beim Ausführen des obigen Befehls wurden 2 Zuordnungsfehler und 1 Konsistenzfehler festgestellt, wie unten dargestellt:
Server: Msg 8946, Level 16, State 12, Zeile 2
Tabellenfehler: Zuordnungsseite (1:72864) hat ungültige PFS_PAGE-Seitenkopfwerte. Typ ist 0. Überprüfen Sie Typ, Objekt-ID und Seiten-ID auf der Seite.
Server: Msg 8921, Ebene 16, Zustand 1, Zeile 1
CHECKTABLE abgebrochen. Beim Sammeln von Fakten wurde ein Fehler festgestellt. Möglicherweise hat tempdb keinen Platz mehr oder eine Systemtabelle ist inkonsistent. Prüfen Sie vorherige Fehler.
Server: Msg 8966, Level 16, State 1, Zeile 1
Konnte Seite (1:72864) mit Latch-Typ UP nicht lesen und verriegeln. fehlgeschlagen.
Server: Msg 8966, Level 16, Zustand 1, Zeile 1
Seite (1:72864) mit Latch-Typ UP konnte nicht gelesen und gelatcht werden. fehlgeschlagen.
Server: Msg 8998, Level 16, Zustand 1, Zeile 1
Aufgrund von Seitenfehlern auf den GAM-, SGAM- oder PFS-Seiten kann CHECKALLOC die Datenbank-ID-8-Seiten von (1:72864) bis (1:80879) nicht verifizieren. Siehe andere Fehler für die Ursache.
CHECKDB hat 2 Zuordnungsfehler und 1 Konsistenzfehler gefunden, die keinem einzelnen Objekt zugeordnet sind.
CHECKDB hat 2 Zuordnungsfehler und 1 Konsistenzfehler in der Datenbank ‘MoreData’ gefunden
Schritt 4: An diesem Punkt ist die Datenbank beschädigt, und unsere Optionen sind entweder die Wiederherstellung der letzten Sicherung oder die Reparatur der Datenbank mit Hilfe von nativen SQL-Reparaturbefehlen oder Tools von Drittanbietern. Schauen wir uns nun diese beiden Optionen an:
Wiederherstellen der Datenbank aus einem sauberen Backup
Wenn Sie versuchen, die Datenbank aus einem Backup wiederherzustellen, wird dringend empfohlen, ein RESTORE VERIFYONLY mit der Backup-Datei durchzuführen, um zu wissen, ob das Backup in einem konsistenten Zustand ist.
RESTORE VERIFYONLY FROM DISK = C:\BackupFile\MoreData.BAK
GO
Reparieren der beschädigten SQL–Datenbank
Wenn die Wiederherstellung nicht zu einem sauberen Ergebnis führt, haben wir keine weiteren Optionen mehr und müssen uns mit der Reparatur der Datenbank befassen. Wir können versuchen, die SQL-Datenbank zu reparieren, indem wir DBCC CHECKDB mit REPAIR OPTION verwenden.
Detaillierte Informationen zu DBCC CHECKDB finden Sie hier: SQL-Datenbank mit DBCC CHECKDB-Befehl reparieren
Versuchen Sie, die db mit der DBCC CHECKDB-Option ‘Repair_Allow_Data_Loss’ zu reparieren, indem Sie den folgenden Code ausführen:
USE master;
ALTER DATABASE [CorruptDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO
ALTER DATABASE [CorruptDB] SET MULTI_USER;
GO
Was passiert, wenn DBCC CHECKDB die SQL-Datenbank nicht reparieren kann?
Die Reparatur der Datenbank mit DBCC CHECKDB mit ‘Repair_Allow_Data_Loss’ birgt das Risiko eines Datenverlustes während des Reparaturprozesses. Es kann auch nicht die erwarteten Ergebnisse liefern. Verwenden Sie das Stellar SQL Datenbank-Reparatur-Tool, um eine beschädigte SQL-Datenbank zu reparieren. Das Tool dient als die beste Alternative zu DBCC CHECKDB Repair Allow Data Loss, die bei der Reparatur einer SQL-Datenbank von allen Arten von häufigen SQL-Datenbankbeschädigungsfehlern hilft. Es repariert beschädigte MDF- und NDF-Dateien und stellt alle Datenbankobjekte wieder her. Außerdem hilft es, die Datenbank in ihrem ursprünglichen Zustand wiederherzustellen, ohne das Risiko eines Datenverlustes.
Im Wesentlichen hilft die Software bei der Reparatur beschädigter SQL Server-Datenbankdateien (.mdf und .ndf), wobei die ursprüngliche Struktur und Integrität der Datenbankobjekte erhalten bleibt.
Fazit
So, da haben Sie es! Wenn Sie einen guten Disaster-Recovery-Plan erstellt haben, dann sollten Sie keine Probleme haben, wenn Ihre Produktionsdatenbank oder eine andere Datenbank aufgrund eines CRC-Fehlers (CRC) beschädigt wird. Nehmen wir nun an, Sie befinden sich in einer Situation, in der kein ordentlicher DR-Plan erstellt wurde und Sie keine Backups zur Wiederherstellung haben. Sie können in Erwägung ziehen, die minimale Reparaturstufe zu verwenden, die von DBCC CHECKDB gemeldet wird, wenn Sie die Integritätsprüfung für die verdächtige Datenbank ausführen.Denken Sie daran, dass die Reparaturfunktion von SQL Server nicht robust ist und keine garantierte Lösung darstellt. Für eine schnellere, vielseitigere Reparatur, die Ihre korrupte SQL-Datenbank mit minimalem Datenverlust wieder zum Laufen bringt, sollten Sie sich die Software Stellar Repair for MS SQL ansehen. Es repariert die Datenbank schneller, indem es einen anspruchsvolleren Reparaturalgorithmus verwendet. Es kann sogar gelöschte Daten in Ihrer Datenbank wiederherstellen.
Was this article helpful?
