Warum funktioniert DBCC SHRINKFILE inkonsequent in einer Datenbank Job?

Question

Warum funktioniert DBCC SHRINKFILE inkonsequent in einer Datenbank Job?

stimmen

1

DBCC SHRINKFILE immer funktioniert, wenn ich es manuell auf einer Log-Datei ausführen, auch wenn ich die folgende Meldung:

'Cannot shrink log file 2 (Claim_Log) because all logical log files are in use.'

Wenn ich es von einem Job ausgeführt, jedoch schrumpft es nur das Protokoll über ein Drittel der Zeit. Die anderen Zeiten, es bleibt nur groß (ca. 150Gb). Es gibt nie einen Fehler andere als die oben genannten. Dies ist die Aussage, die ich benutze:

DBCC SHRINKFILE (N'Claim_log' , 0, TRUNCATEONLY)

Ich habe auf dem Arbeitsschritt freigegeben „Schrittausgabe in der Geschichte einbeziehen“. Gibt es etwas, das ich tun kann, um mehr Informationen zu erhalten, warum dies nicht funktioniert?

Edit: Hier ist die vollständige Meldung aus dem Protokoll:

'Executed as user: *. Cannot shrink log file 2 (Claim_Log) because all logical
log files are in use. [SQLSTATE 01000] (Message 9008)  DBCC execution completed. 
If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000]
(Message 2528).  The step succeeded.'

Ich habe bereits versucht, Benutzer aus dem db treten und es dem Single-User-Modus einstellen.

sql-server sql-server-2005 sql-agent-job log-files

Veröffentlicht am 09/12/2008 um 17:27
quelle vom benutzer Keith Walton

In anderen Sprachen...

3 antworten

stimmen

2

versuchen , die Ausgabe von CHECKPOINT ersten Befehl, dann die Protokolle schrumpfen

genommen von BOL ( http://msdn.microsoft.com/en-us/library/aa226036(SQL.80).aspx )

Forces alle schmutzigen Seiten für die aktuelle Datenbank auf der Festplatte geschrieben werden. Schmutzige Seiten sind Daten oder Log-Seiten geändert, nachdem sie in den Puffer-Cache eingetragen, aber die Änderungen noch nicht auf die Festplatte geschrieben. Weitere Informationen über Logkürzung finden Sie im Transaktionsprotokoll Kürzen.

Beantwortet am 09/12/2008 um 18:01
quelle vom benutzer rip747

stimmen

0

Bedeutet derzeit die Log-Datei ist in Verwendung und Ausgabe Kontrollpunkt, wo Kontrollpunkt wird auf datfile schreibt, die nicht an die Daten-Datei aus Transaktionsprotokolldatei (Dirty Seiten) geschrieben wurde. Check gibt es eine aktuelle Aktivität auf oder nicht geht,

Überprüfen Sie, ob aktive Transaktion mit 2005 SELECT * FROM sys.dm_tran_session_transactions

2000 DBCC loginfo

macht guten Plan => 1.Erstellen maintenace Plan für das Protokoll (Made Plan) sichern.

Beantwortet am 29/08/2009 um 06:18
quelle vom benutzer RamaUdaya.K

MrEs · Accepted Answer · 2011-07-06 05:10

Ich löste vor kurzem ein ähnliches Problem, ich fand, dass in sys.databases, log_reuse_wait_desc zu ‚Replikation‘ gleich war. Offensichtlich bedeutet dies, etwas in der Art von SQL Server für eine Replikations Aufgabe warten zu beenden, bevor sie den Protokollspeicher wiederverwenden können.

Allerdings hatte die Replikation nie auf unserer DB noch auf unserem Server verwendet. Sie sollen den Zustand zu löschen, indem Sie ‚sp_removedbreplication‘ in der Lage sein; aber für mich ‚sp_removedbreplication‘ nicht lösen das Problem. Stattdessen sind gerade SQL sagen, dass die Datenbank nicht Teil einer Replikations war ...

Ich fand meine Antwort hier:

Im Grunde hatte ich eine Replikation zu erstellen, setzen Sie alle Replikations Zeiger auf Null; dann löschen Sie die Replikation hatte ich gerade gemacht. dh

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