MSSQLSERVER_3414

Gilt für: SQL Server

Details

attribute	Wert
Produktname	SQL Server
Ereignis-ID	3414
Ereignisquelle	MSSQLSERVER
Komponente	SQLEngine
Symbolischer Name	REC_GIVEUP
Meldungstext	Fehler bei der Wiederherstellung. Die '%.*ls'-Datenbank (Datenbank-ID %d) kann daher nicht neu gestartet werden. Diagnostizieren und beheben Sie die Wiederherstellungsfehler, oder führen Sie eine Wiederherstellung von einer als fehlerfrei bekannten Sicherung aus. Falls die Fehler nicht behoben werden oder unerwartete Fehler auftreten, wenden Sie sich an den technischen Support.

Erklärung

Die angegebene Datenbank wurde wiederhergestellt, konnte jedoch nicht gestartet werden, da Fehler bei der Wiederherstellung auftraten. Durch diesen Fehler wurde die Datenbank in den SUSPECT-Status versetzt. Die primäre Dateigruppe und möglicherweise weitere Dateigruppen sind fehlerverdächtig und u. U. beschädigt. Die Datenbank kann beim Start von SQL Server nicht wiederhergestellt werden und ist daher nicht verfügbar. Eine Aktion seitens des Benutzers ist erforderlich, um das Problem zu beheben. Der SUSPECT-Status wird sowohl im SQL Server Management Studio (neben dem Datenbanksymbol) als auch in der Spalte sys.databases.state_desc angezeigt. Der Versuch, eine Datenbank mit diesem Status zu verwenden, führt zu folgendem Fehler:

Msg 926, Level 14, State 1, Line 1 
Database 'mydb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information

Beachten Sie, dass beim Auftreten dieses Fehlers in tempdb die SQL Server-Instanz heruntergefahren wird.

Ursache

Dieser Fehler kann auf vorübergehende Systemschwierigkeiten zurückzuführen sein, die beim Versuch, die Serverinstanz zu starten oder eine Datenbank wiederherzustellen, aufgetreten sind. Es kann jedoch auch ein dauerhafter Fehler vorliegen, der bei jedem Versuch auftritt, die Datenbank zu starten. Der Wiederherstellungsfehler ist in der Regel auf Fehler zurückzuführen, die vor dem Fehler 3414 im Fehlerprotokoll (ERRORLOG) oder Ereignisprotokoll zu finden sind. Der vorherige Fehler in der Protokolldatei enthält denselben spid<n-Wert> . Der folgende Wiederherstellungsfehler ist beispielsweise auf einen Prüfsummenfehler zurückzuführen, der beim Versuch, einen Protokollblock zu lesen, aufgetreten ist. Beachten Sie, dass spid15s in allen Zeilen enthalten ist:

2020-03-31 17:33:13.00 spid15s     Error: 824, Severity: 24, State: 4.  
2020-03-31 17:33:13.00 spid15s     SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb_log.LDF'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2020-03-31 17:33:13.16 spid15s     Error: 3414, Severity: 21, State: 1.  
2020-03-31 17:33:13.16 spid15s     An error occurred during recovery, preventing the database 'mydb' (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support

Es gibt eine große Bandbreite von Fehlern, die dazu führen können, dass ein Datenbank-Wiederherstellungsfehler auftritt. Auch wenn Sie jeden Fehler im Einzelfall auswerten müssen, können Datenbank-Wiederherstellungsfehler in der Regel wie im Abschnitt „Benutzeraktion“ weiter unten beschrieben behoben werden.

Aktion des Benutzers

Überprüfen Sie das Windows-Ereignisprotokoll oder ERRORLOG auf einen vorherigen Fehler, der Aufschluss über den Fehler gibt, um Informationen darüber zu erhalten, warum der Fehler 3414 aufgetreten ist. Die entsprechende Benutzeraktion hängt davon ab, ob die Informationen im Windows-Ereignisprotokoll angibt, dass der SQL Server-Fehler durch eine vorübergehende Bedingung oder einen dauerhaften Fehler verursacht wurde. Die Fehlermeldung weist Sie an, wie folgt vorzugehen: „Diagnostizieren und beheben Sie die Wiederherstellungsfehler, oder führen Sie eine Wiederherstellung von einer als fehlerfrei bekannten Sicherung aus.“ Sie können folglich versuchen, den aufgetretenen Fehler zu beheben, damit die Wiederherstellung abgeschlossen werden kann. (Weitere Informationen finden Sie unter Behebbare Fehler und verzögerte Transaktionen.)

Wenn die Fehler nicht behoben werden können, ist die erste Wahl und beste Möglichkeit für die Behebung dieses Problems die Wiederherstellung über eine fehlerfreie Sicherung. Wenn Sie jedoch keine Wiederherstellung aus einer Sicherung durchführen können, haben Sie zwei weitere Möglichkeiten, die keine vollständige Datenwiederherstellung garantieren: Verwenden Sie die Notfallreparatur mit DBCC CHECKDB, oder versuchen Sie, so viele Daten wie möglich in eine andere Datenbank zu kopieren.

1. Führen Sie eine Wiederherstellung über die letzte als fehlerfrei bekannte Datenbanksicherung durch.
2. Verwenden Sie die von DBCC CHECKDB bereitgestellte Notfallreparaturmethode.
3. Versuchen Sie, so viele Daten wie möglich in eine andere Datenbank zu kopieren.

Die erste Methode, das Wiederherstellen über eine fehlerfreie Datenbanksicherung, ist die beste Wahl, um eine Datenbank auf einen bekannten und konsistenten Stand zu bringen.

Wenn keine Sicherung verfügbar ist, ist die zweitbeste Option, die Datenbank online zu stellen und zugänglich zu machen. Beachten Sie jedoch, dass aufgrund des Wiederherstellungsfehlers keine Transaktionskonsistenz garantiert werden kann. Es gibt keine Möglichkeit, zu ermitteln, für welche Transaktionen ein Rollback oder Rollforward hätte ausgeführt werden sollen, die jedoch aufgrund des Wiederherstellungsfehlers nicht zugelassen wurden. Die Schritte zum Durchführen der Notfallreparatur werden im Abschnitt Beheben von Fehlern im Datenbank-Notfallmodus in der DBCC CHECKDB-Dokumentation beschrieben.

Wenn die Notfallreparatur nicht funktioniert und Sie versuchen möchten, einige Daten in einer anderen Datenbank zu retten, besteht die Möglichkeit, den Zugriff auf die Datenbank zu erhalten, indem Sie die Datenbank im Notfallmodus über den BEFEHL ALTER DATABASE <dbname> SET EMERGENCY festlegen. Anschließend können Sie versuchen, Daten aus Tabellen zu kopieren.

Behebbare Fehler und verzögerte Transaktionen

Nicht alle Fehler, die bei der Datenbankwiederherstellung auftreten, führen zu einem Wiederherstellungsfehler und einer Datenbank mit dem Status SUSPECT:

Fehler beim erstmaligen Öffnen der Datenbank und/oder der Transaktionsprotokolldateien treten vor der Wiederherstellung auf. Beispiele für solche Fehler sind 17204 und 17207. Wenn diese Fehler behoben wurden, kann die Wiederherstellung fortgesetzt werden. (Es ist allerdings nicht sicher, dass diese auch abgeschlossen werden kann, wenn andere Wiederherstellungsfehler auftreten.) Die Fehler 17204 und 17207 führen nicht zu einer Datenbank mit dem Status SUSPECT. Wenn diese Probleme auftreten, ist der Status der Datenbank RECOVERY_PENDING.

SQL Server ermöglicht die Wiederherstellung auch dann, wenn ein Fehler auf Seitenebene auftritt, und behält weiterhin transaktionsbezogene Konsistenz bei. Dieser Prozess hat die Anzahl von Szenarios verringert, die zu einer Datenbank mit dem Status SUSPECT führen. Dieses Konzept wird verzögerte Transaktionen genannt.

Wenn der bei der Wiederherstellung aufgetretene Fehler auf ein Problem mit einer Datenbankseite hinweist, z. B. ein Prüfsummenfehler oder die Meldung 824, kann die Wiederherstellung ohne Fehlerbehebung abgeschlossen werden. Wenn eine Transaktion nicht committet wurde, kann ein Fehler auf einer Seite zu einer verzögerten Transaktion führen, was ein Abschließen der Wiederherstellung ermöglicht.

Die folgenden ERRORLOG-Einträge zeigen ein Beispiel für einen Fehler mit der Meldung 824, der bei der Wiederherstellung aufgetreten ist. Die Wiederherstellung konnte jedoch mit einer verzögerten Transaktion abgeschlossen werden. Beachten Sie, dass in diesem Fall der Fehler 3414 nicht aufgetreten ist, sowie die Meldung, dass die Wiederherstellung der Datenbank abgeschlossen wurde:

2010-03-31 19:17:18.45 spid7s      SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xb2c87a0a; actual: 0xb6c0a5e2). It occurred during a read of page (1:153) in database ID 13 at offset 0x00000000132000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2010-03-31 19:17:18.45 spid7s      Error: 3314, Severity: 21, State: 1.   
2010-03-31 19:17:18.45 spid7s      During undoing of a logged operation in database 'mydb', an error occurred at log record ID (25:100:19). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2010-03-31 19:17:18.45 spid7s      Errors occurred during recovery while rolling back a transaction. The transaction was deferred. Restore the bad page or file, and re-run recovery.   
2010-03-31 19:17:18.45 spid7s      Recovery completed for database mydb (database ID 13) in 2 second(s) (analysis 204 ms, redo 25 ms, undo 1832 ms.) This is an informational message only. No user action is required.   

Wenn für eine committete Transaktion ein Rollforward ausgeführt werden soll, kann die Seite mit „Kein Zugriff“ gekennzeichnet werden (bei zukünftigen Versuchen, auf die Seite zuzugreifen, wird dann die Meldung 829 ausgegeben), und die Wiederherstellung kann abgeschlossen werden. In diesem Fall muss der Fehler behoben werden, indem die Seite aus einer Sicherung wiederhergestellt wird oder die Zuordnung der Seite mit DBCC CHECKDB mit Reparatur aufgehoben wird.

Siehe auch

ALTER DATABASE (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
Vollständige Datenbankwiederherstellungen (einfaches Wiederherstellungsmodell)
Verzögerte Transaktionen
MSSQLSERVER_824
sys.databases (Transact-SQL)