Warum kann ich eine Transaktionsprotokolldatei auch nach der Sicherung nicht verkleinern?

Question

Ich habe eine Datenbank, die eine 28gig Transaktionsprotokolldatei hat. Recovery-Modus ist einfach. Ich habe gerade eine vollständige Sicherung der Datenbank, und dann lief beide:

backup log dbmcms with truncate_only

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

Der Name des db ist db_mcms und der Name der Transaktionsprotokolldatei ist Wxlog0.

Weder hat geholfen. Ich bin mir nicht sicher, was ich als nächstes tun soll.

Answer 1

Sie für die Beantwortung von allen danken.

Wir haben endlich das Problem gefunden. In sys.databases war log_reuse_wait_desc gleich 'replication'. Anscheinend bedeutet dies, dass SQL Server darauf wartet, dass eine Replikationsaufgabe abgeschlossen wird, bevor der Protokollspeicherbereich erneut verwendet werden kann.

Replikation wurde noch nie in dieser Datenbank verwendet oder dieser Server wurde mit einmal auf dieser db gespielt. Wir haben den falschen Status gelöscht, indem wir sp_removedbreplication ausgeführt haben. Nachdem wir das ausgeführt hatten, funktionierten Backup Log und dbcc shrinkfile einwandfrei.

Definitiv eine für die Trickkiste.

Quellen:

http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b

http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705

Answer 2

Haben Sie aus dem SQL Server Management Studio mit der GUI versucht. Rechtsklick auf die Datenbank, Aufgaben, verkleinern, Dateien. Wählen Sie Dateityp = Protokoll.

Ich arbeitete für mich vor einer Woche.

Answer 3

Sie nicht brauchen diese

DBCC SHRINKFILE ('Wxlog0', 0) 

Seien Sie sicher, dass Sie sich der Gefahren bewusst sind: siehe hier: Do not truncate your ldf files!

Und hier Backup Log with Truncate_Only: Like a Bear Trap

Answer 4

Try Zielgröße zu verwenden, die Sie benötigen anstelle von TRUNCATEONLY in DBCC:

DBCC SHRINKFILE ('Wxlog0', 1)

Und überprüfen Sie dies Artikel:

http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx

http://support.microsoft.com/kb/907511

Edit:

Sie können versuchen, zugeordneten Seiten an den Anfang der Protokolldatei mit

DBCC SHRINKFILE zuerst zu bewegen ('Wxlog0', NOTRUNCATE)

und achtern er, dass

DBCC SHRINKFILE ('Wxlog0', 1)

Answer 5

Versuchen Sie eine andere vollständige Sicherung, nachdem Sie Backup das Protokoll w/truncate_only Erstellen (IIRC sollten Sie diese auf jeden Fall tun, um die Log-Kette zu erhalten). Im einfachen Wiederherstellungsmodus sollte Ihr Protokoll sowieso nicht viel wachsen, da es nach jeder Transaktion effektiv gekürzt wird. Versuchen Sie dann, die Größe anzugeben, die die Protokolldatei haben soll, z.

-- shrink log file to c. 1 GB 
DBCC SHRINKFILE (Wxlog0, 1000); 

Die TRUNCATEONLY Option neu ordnet die Seiten nicht in der Log-Datei, so dass Sie möglicherweise eine aktive Seite am „Ende“ der Datei haben, die sie von geschrumpft werden verhindern könnten.

Sie können auch DBCC SQLPERF (LOGSPACE) verwenden, um sicherzustellen, dass wirklich Platz in der Protokolldatei vorhanden ist, die freigegeben werden soll.

Answer 6

Setzen Sie die DB zurück in den Vollmodus, führen Sie die Transaktionsprotokollsicherung aus (nicht nur eine vollständige Sicherung) und dann den Shrink.

Nachdem es geschrumpft ist, können Sie die DB wieder in den einfachen Modus versetzen und es txn Protokoll wird die gleiche Größe bleiben.

Answer 7

Sie können ein Transaktionsprotokoll nicht kleiner als die ursprünglich erstellte Größe verkleinern.

Answer 8

Wenn Sie den Wiederherstellungsmodus für die Datenbank 2005 einstellen (weiß nicht für vor 2005), wird die Protokolldatei zusammen gelöscht und Sie können sie wieder in den vollständigen Wiederherstellungsmodus versetzen, um die Protokolldatei neu zu starten . Wir haben das mit SQL 2005 Express so erlebt, dass wir mit den Daten nicht in die Nähe des 4-GB-Limits kommen konnten, bis wir den Wiederherstellungsmodus geändert haben.

Answer 9

Sie können auf dieses Problem stoßen, wenn Ihre Datenbank so eingestellt ist, dass sie automatisch das Protokoll & mit vielen virtuellen Protokolldateien auflöst.
Führen Sie DBCC LOGINFO('databasename') & Blick auf den letzten Eintrag, wenn dies eine 2 ist dann wird Ihre Protokolldatei nicht verkleinern. Im Gegensatz zu Datendateien können virtuelle Protokolldateien nicht innerhalb der Protokolldatei verschoben werden.

Sie müssen BACKUP LOG und DBCC SHRINKFILE mehrere Male ausführen, um die Protokolldatei zu verkleinern.

Für zusätzliche Bonuspunkte laufen DBBC loginfo zwischen log & ausweicht

Answer 10

ich das gleiche Problem in der Vergangenheit gehabt haben. Normalerweise müssen ein Shrink- und ein Trn-Backup mehrmals ausgeführt werden. In extremen Fällen habe ich die DB auf "Simple" wiederhergestellt und dann eine Verkleinerungsoperation für die Protokolldatei ausgeführt. Das funktioniert immer für mich. Aber in letzter Zeit hatte ich eine Situation, in der das nicht funktionieren würde. Das Problem wurde durch eine lange laufende Abfrage verursacht, die nicht abgeschlossen wurde. Daher waren alle Versuche zum Verkleinern nutzlos, bis ich diesen Prozess beenden und meine Verkleinerungsvorgänge ausführen konnte. Wir sprechen eine Protokolldatei, die auf 60 GB angewachsen ist und jetzt auf 500 MB geschrumpft ist.

Denken Sie daran, sobald Sie vom FULL in den einfachen Wiederherstellungsmodus wechseln und den Shrink durchführen, vergessen Sie nicht, ihn auf FULL zu setzen. Dann müssen Sie unmittelbar danach eine FULL DB-Sicherung durchführen.

Answer 11

"sp_removedbreplication" löste das Problem nicht für mich, da SQL gerade zurückkehrte, dass die Datenbank nicht Teil einer Replikation war ...

ich meine Antwort hier:

• http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
• http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx

Im Grunde hatte ich eine Replikation zu erstellen, setzen Sie alle Replikations Zeiger auf Null; Löschen Sie dann die Replikation, die ich gerade erstellt habe. heißt

Execute SP_ReplicationDbOption {DBName},Publish,true,1 
GO 
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 
GO 
DBCC ShrinkFile({LogFileName},0) 
GO 
Execute SP_ReplicationDbOption {DBName},Publish,false,1 
GO 

Answer 12

Diese Antwort wurde von here angehoben worden und wird hier der andere Thread, falls gebucht gelöscht wird:

Die Tatsache, dass Sie nicht ausgeschüttete LSN im Protokoll ist das Problem haben. Ich habe das schon einmal gesehen, nicht sicher, warum wir nicht die Transaktion als repliziert aufheben. Wir werden das intern untersuchen. Sie können Sie den folgenden Befehl ausführen, die Transaktion demarkieren als

repliziert

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 

An diesem Punkt sollten Sie in der Lage sein, um das Protokoll zu kürzen.

Answer 13

Ich versuchte alle aufgelisteten Lösungen und keiner von ihnen funktionierte. Am Ende musste ich eine sp_detach_db machen, dann die ldf-Datei löschen und die Datenbank erneut anhängen, um eine neue ldf-Datei zu erstellen. Das hat funktioniert.

Answer 14

Ich weiß, das ist ein paar Jahre alt, aber wollte ein paar Infos hinzufügen.

Ich fand in sehr großen Protokollen, insbesondere wenn die DB nicht auf Sicherung Transaktionsprotokolle (Protokolle waren sehr groß) gesetzt, würde die erste Sicherung der Protokolle nicht log_reuse_wait_desc auf nichts setzen, sondern den Status als noch sichern lassen. Dies würde den Schrumpf blockieren. Wenn Sie die Sicherung ein zweites Mal ausführen, setzen Sie den Wert von log_reuse_wait_desc auf NOTHING zurück, damit der Shrink verarbeitet werden kann.