Neuerstellung des Transaktionslogs

Wir haben eine sehr große Datenbank (~ 6 TB), deren Transaktionsprotokolldatei gelöscht wurde (während SQL Server heruntergefahren wurde. Wir haben versucht:

1. Trennen und erneutes Anschließen der Datenbank; und
2. Wiederherstellen der Transaktionsprotokolldatei

... aber bisher hat nichts geklappt.

Wir führen derzeit:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... aber angesichts der Größe der Datenbank wird dies wahrscheinlich einige Tage dauern.

Fragen

• Gibt es einen Unterschied zwischen dem obigen und dem folgenden Befehl?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Sollten wir stattdessen ausführen REPAIR_ALLOW_DATA_LOSS?

Es ist erwähnenswert, dass die Daten aus anderen Quellen stammen, damit die Datenbank wiederhergestellt werden kann. Wir vermuten jedoch, dass die Reparatur der Datenbank viel schneller geht als das erneute Einfügen aller Daten.

Aktualisieren

Für diejenigen, die Punkte halten: Der ALTER DATABASE/REBUILD LOGBefehl wurde nach ungefähr 36 Stunden ausgeführt und es wurde berichtet:

Warnung: Das Protokoll für die Datenbank 'Datenbankname' wurde neu erstellt. Transaktionskonsistenz ist verloren gegangen. Die RESTORE-Kette wurde unterbrochen, und der Server verfügt nicht mehr über einen Kontext zu den vorherigen Protokolldateien. Daher müssen Sie wissen, um welche es sich handelt.
Sie sollten DBCC CHECKDB ausführen, um die physische Konsistenz zu überprüfen. Die Datenbank wurde in den Nur-Dbo-Modus versetzt. Wenn Sie bereit sind, die Datenbank für die Verwendung bereitzustellen, müssen Sie die Datenbankoptionen zurücksetzen und alle zusätzlichen Protokolldateien löschen.

Wir liefen dann eine DBCC CHECKDB(dauerte ca. 13 Stunden), die erfolgreich war. Angenommen, wir alle haben die Bedeutung von Datenbanksicherungen (und das Gewähren des Zugriffs auf den Server durch Projektmanager ...) erkannt.

Trennen Sie niemals eine verdächtige Datenbank. Wie haben Sie die Datenbank angefügt, nachdem Sie sie getrennt haben? Sie haben CREATE DATABASEmit FOR ATTACH_REBUILD_LOGOption verwendet?

Diese Befehle hätten den Trick machen sollen:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Ich habe einen Beitrag für diese Situation geschrieben:

Verfahren zur Wiederherstellung der SQL 2005/2008-Datenbank - Protokolldatei gelöscht (Teil 3)

Sie fragten nach dem Unterschied zwischen:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) und
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

Die Sache ist, dass Sie beide ausführen können, um die Protokolldatei neu zu erstellen, aber mit CHECKDBIhnen auch das Protokoll neu erstellen und die Datenbank auf Integritätsfehler überprüfen.

Auch die zweite (alter database) funktioniert nicht, wenn aktive Transaktionen (nicht auf die Festplatte geschrieben) vorhanden waren, als die Protokolldatei verloren ging. Beim Starten oder Anhängen möchte SQL Server eine Wiederherstellung (Rollback und aktualisierende Wiederherstellung) von der Protokolldatei ausführen, die nicht vorhanden ist. Dies passiert, wenn eine Festplatte abstürzt oder der Server unerwartet heruntergefahren wird und die Datenbank nicht ordnungsgemäß heruntergefahren wird. Ich denke, es war nicht dein Fall und alles war gut für dich.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)Bei Ausführung einer Datenbank im Notfallstatus wird die Datenbank auf Inkonsistenzfehler überprüft. Zunächst wird versucht, mithilfe der Protokolldatei Inkonsistenzen zu beheben. Wenn dies fehlt, wird das Transaktionsprotokoll neu erstellt.

2. ALTER DATABASE REBUILD LOG ON...ist eine undokumentierte Prozedur und erfordert eine nachfolgende DBCC CHECKDB, um alle Fehler zu beheben.

Ja, das sind zwei verschiedene Aussagen, die jeweils sehr unterschiedliche Dinge tun.

Abhängig vom Status der Datenbank, in der die Datei gelöscht wurde, können Sie möglicherweise den Betrieb aufnehmen, indem Sie die Datenbank anhängen und das Protokoll mit den folgenden Schritten neu erstellen:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Siehe sp_attach_single_file_db (Transact-SQL) in der Produktdokumentation.

Siehe auch diesen Blog-Beitrag von Paul S. Randal :

NOT-AUS-Reparatur: der allerletzte Ausweg