it-swarm.com.de

Wiederherstellungssicherung schlägt fehl - nicht genügend Speicherplatz

Ich habe ein Backup, das ungefähr 6 GB groß ist. Es ist eine "leichte" Sicherung des Originals (mit gelöschten Protokolltabellen), die ungefähr 14 GB groß ist.

Ich versuche, die Sicherung auf meinem lokalen SQL Express-Server wiederherzustellen. Es schlägt fehl mit einer Meldung wie: System.Data.SqlClient.Error: insufficient disk space. Es werden 227.891.019.776 Bytes benötigt, was absolut verrückt und fast so groß wie meine gesamte Festplatte ist.

Wie auf anderen Websites gefunden, habe ich versucht, RESTORE FILELISTONLY FROM DISK = 'backupfile.bak'.

Die Datendatei (Spalte Size) hat eine Größe von 6.888.226.816, die Protokolldatei jedoch eine Größe von 221.006.987.264. Die Spalte BackupSizeInBytes gibt 6.259.736.576 und 0 zurück.

Wenn ich das richtig verstehe, überprüft die Wiederherstellung, ob genügend Speicherplatz vorhanden ist, um die "theoretische" Größe der Protokolldatei wiederherzustellen, bevor Sie fortfahren, wobei die tatsächliche Größe der Protokolldatei nicht berücksichtigt wird.

Wie kann ich das umgehen? Es ist etwas schwierig, ein Backup zu erhalten. Wenn ich mein Problem lösen kann, ohne auf den Produktionsserver zurückkehren zu müssen, wäre das großartig.

Vielen Dank !

Übrigens, ich bin auf SQL Server 2008 R2 Express.

7
thomasb

Beachten Sie, dass die Sicherungsgröße keine leeren Seiten enthält. Wenn Sie jedoch die Wiederherstellung tatsächlich durchführen, müssen die Daten- und Protokolldateien werden über 200 GB liegen, da genau das wiederhergestellt werden muss, was das Quellsystem hatte (einschließlich) eine Protokolldatei mit mehr als 200 GB, unabhängig davon, wie voll sie war).

Wenn Sie keinen Datenverlust riskieren möchten, müssen Sie dies an der Quelle korrigieren (z. B. die Protokolldatei auf einen vernünftigen Wert verkleinern), eine weitere vollständige Sicherung erstellen und diese wiederherstellen. Ich bin mir nicht sicher, warum es schwierig ist, ein Backup zu erstellen. Dies ist ein ziemlich normaler Vorgang und sollte ein Dienst sein, der von jedem bereitgestellt wird, den Sie an Host SQL Server bezahlen.

Sie sollten die Quellendatenbank auch so reparieren, dass sie entweder (a) im richtigen Wiederherstellungsmodell ist oder (b) häufiger Protokollsicherungen durchführt. Ihre Protokolldatei ist lächerlich, da Sie sich in der vollständigen Wiederherstellung befinden und niemals Protokollsicherungen durchführen. Wenn Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt benötigen, beginnen Sie mit der Sicherung Ihres Protokolls. Wenn Sie dies nicht tun, wechseln Sie zu einfach. Die Protokolldatei sollte sich selbst verwalten, wenn Sie sie richtig konfiguriert haben. Wenn Sie dies nicht tun, sollte das Verkleinern ein einmaliger Vorgang sein, und dann sollten Sie die Konfiguration korrigieren, damit Sie dies nächste Woche nicht erneut tun ...

7
Aaron Bertrand

DBCC TRACEON (3104) umgeht die Speicherplatzprüfungen für Wiederherstellungsprozesse.

2
Nic

Es gab keine Transaktionsprotokollsicherungen, damit das Protokoll wiederverwendet werden konnte. Es muss also das gesamte leere Protokoll abrufen, um zu den Teilen zu gelangen, in denen möglicherweise einige Transaktionen wiederhergestellt werden müssen.

Wenn Sie also bereit sind, einen (möglicherweise ziemlich großen) Datenverlust zu erleiden, können Sie ihn ohne das Protokoll wiederherstellen. Dies wird nicht empfohlen.

Hier ist ein Link zum allgemeinen Thema der Wiederherstellung von SQL Server-Datenbanken: http://www.sqlskills.com/blogs/paul/category/disaster-recovery/ . Sie sind nicht allein: http://www.sqlskills.com/blogs/paul/search-engine-qa-23-my-transaction-log-is-full-now-what/ . Schließlich zu einigen Befehlen, die in dieser Situation helfen können, wieder nicht empfohlen (Sie werden mit ziemlicher Sicherheit Datenverlust erleiden) http://blog.sqlauthority.com/2010/04/26/sql-server-attach -mdf-Datei-ohne-ldf-Datei-in-Datenbank / .

1
Grignar Grenac

Wenn Sie noch die ursprüngliche Datenbank online haben. und Sie haben keinen Protokollversand, keine Replikation oder verwenden keine Transaktionsprotokollsicherungen. Anschließend können Sie ALTER DATABASE {name} SET RECOVERY SIMPLE ausführen, wodurch das Transaktionsprotokoll geleert wird (wodurch Sie diese Datei später verkleinern können). Führen Sie dann BACKUP DATABASE {name} TO DISK = '{file}' aus. Kopieren Sie die Datei auf Ihren neuen Server und stellen Sie die Datenbank {new_name} TO DISK = '{file}' wieder her. Möglicherweise müssen Sie die logischen Dateien mithilfe von WITH .. MOVE {x} TO {new_file} neuen Speicherorten zuordnen, siehe URL http://msdn.Microsoft.com/en-us/library/ms177429) .aspx für etwas mehr Syntax. Nach der Sicherung können Sie ALTER DATABASE {name} SET RECOVERY FULL ausführen, um die ursprüngliche Datenbank auf das vollständige Wiederherstellungsmodell zurückzusetzen (dies sollten Sie auch für Ihre neue Kopie tun). Sie können auch Folgendes nützlich finden, wenn diese Schritte schief gehen: http://www.sqlskills.com/blogs/paul/category/backuprestore/ .

Wenn Sie Speicherplatz auf der Festplatte freigeben möchten, um das neue Backup zu erstellen (nach dem SET RECOVERY und vor dem BACKUP). Sie sollten use {database_name} ausführen. EXEC sp_helpdb {Datenbankname} sucht dann im Ergebnis nach der Zeile mit der Spalte mit dem Verwendungswert "Nur Protokoll". Verwenden Sie dies dann als Wert für {Dateiname} in der dbcc-Schrumpfdatei ('{Dateiname}', 1024), wodurch die .LDF-Datei auf 1 GB reduziert werden soll (d. H. Die Größe ist in MB). VERWENDEN SIE KEINE Schrumpfdatei für Datendateien, sondern nur für Protokolldateien. Weitere Informationen zu letzteren finden Sie auf der oben genannten Paul Randall-Website.

0
Grignar Grenac