it-swarm.com.de

SQL Server 2008 R2 (Verdächtiger) -Modus - Wie wird repariert?

Ich habe eine SQL Server 2008 R2-Datenbank im Suspect-Modus. Ich habe versucht, das Problem mit dieser Abfrage zu beheben:

EXEC sp_resetstatus ‘yourDBname’;
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb(’yourDBname’)
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB (’yourDBname’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER

Aber die Reparaturausgabe war diese Nachricht:

Warning: You must recover this database prior to access.
Msg 8921, Level 16, State 1, Line 5
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Warning: The log for database 'ServeDB' has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer 
has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has 
been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
Msg 8921, Level 16, State 1, Line 9
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

Wie kann ich die Datenbank vollständig reparieren? Diese Reparatur, die ich durchgeführt habe, funktioniert nur einige Tage, dann wechselt die Datenbank wieder in den Suspect-Modus ...

5
Vytas999

Ich bin auf ein ähnliches Problem gestoßen. Ich konnte die Datenbank jedoch nicht aus dem Verdächtigen herausholen, da auch die Backups verdächtig waren. Ich habe die Exportfunktion in SSMS verwendet, um die Tabellen und Daten in eine neue leere Datenbank zu verschieben.

Dadurch werden jedoch nicht alle Ihre gespeicherten Prozeduren, Ansichten, Funktionen usw. verschoben. Ich habe eine Kopie von RedGates SQL Compare (die ich jedem empfehlen kann, der regelmäßig mit SQL-Schemas arbeitet), die die gesamte Strukturmigration abwickelt. Das machte den Prozess ziemlich schmerzlos. RedGate bietet eine 14-tägige Testversion der Software an, falls Sie diese verwenden müssen.

Wenn Sie nur Tabellen oder eine kleine Anzahl von Prozeduren, Ansichten usw. haben, können Sie die SSMS-Funktion "Skripte generieren" verwenden, um Erstellungsskripte für diese Elemente zu erstellen, und diese dann in Ihrer neuen Datenbank ausführen.

RedGates SQL-Vergleich: http://www.red-gate.com/products/sql-development/sql-compare/

5
AJ Piscitelli

Sie können diese Datenbank nicht reparieren, und die Reparatur, die Sie möglicherweise durchgeführt haben, ist noch nicht abgeschlossen. Sie sollten sicherstellen, dass Sie verstehen , warum Ihre Datenbank beschädigt wird. Überprüfen Sie Ihr Festplattensystem, da dies der wahrscheinlichste Schuldige ist.

Stellen Sie dann Ihre Datenbank aus einer Sicherung wieder her. Führen Sie jedoch DBCC CHECKDB für genau diese Sicherung aus, um sicherzustellen, dass sie selbst nicht beschädigt ist.

DBCC CHECKDB mit REPAIR_ALLOW_DATA_LOSS ist der allerletzte Ausweg, zu dem Sie jemals gehen sollten. Vorher sollten Sie eine gültige Sicherung wiederherstellen. Wenn Sie REPAIR_ALLOW_DATA_LOSS einmal verwendet haben, erwarten Sie nicht, dass Ihre Datenbank auf magische Weise wieder zum Leben erweckt wird - höchstwahrscheinlich ist ein irreparabler Schaden aufgetreten - insbesondere in diesem Fall, da sie sich über Beschädigungen der Systemtabelle beschwert.

7

Haben Sie versucht, was Paul Randal empfiehlt? Erstellen, Trennen, erneutes Anhängen und Korrigieren einer verdächtigen Datenbank

  1. Erstellen Sie eine neue Dummy-Datenbank mit genau demselben Dateilayout und so nah wie möglich an den Dateigrößen der getrennten Datenbank
  2. Fahren Sie SQL Server herunter
  3. Tauschen Sie die beschädigten Datenbankdateien aus
  4. Starten Sie SQL Server neu
  5. Verwenden Sie die Notfallreparatur
6