it-swarm.com.de

DBCC SHRINKFILE in der Protokolldatei reduziert die Größe auch nach dem Sichern der Protokolldatei nicht

Ich habe eine Datenbank, [My DB], die die folgenden Informationen enthält:
SQL Server 2008
MDF-Größe: 30 GB
LDF-Größe: 67 GB

Ich wollte die Protokolldatei so weit wie möglich verkleinern und begann meine Suche, um herauszufinden, wie das geht. Vorsichtsmaßnahme: Ich bin kein DBA (oder nähere mich einem DBA) und habe mich durch diese Suche weiterentwickelt.

Zuerst ging ich zu SSMS, DB-Eigenschaften, Dateien und bearbeitete den Wert für die Anfangsgröße (MB) auf 10. Dadurch wurde die Protokolldatei auf 62 GB reduziert (nicht genau die von mir eingegebenen 10 MB). Also habe ich SQL Profiler angehängt und gesehen, dass DBCC SHRINKFILE aufgerufen wird. Ich habe diesen Befehl dann in den Abfrageeditor eingegeben und hier sind die Ergebnisse.

DBCC SHRINKFILE (N'My DB_Log' , 10)

Und die Ausgabe war:

Cannot shrink log file 2 (My DB_Log) because the logical log file located at the end of the file is in use.
DbId   FileId      CurrentSize MinimumSize UsedPages   EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
8      2           8044104     12800       8044104     12800

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Daraufhin habe ich einige Nachforschungen angestellt und folgendes herausgefunden:

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

Was bedeutet, dass ich die Protokolldatei vor dem Verkleinerungsfile sichern muss, damit die virtuellen Protokolldateien freigegeben werden und das Verkleinerungsfile seinen Job machen kann - ich weiß nicht, was das bedeutet ... ich paraphrasiere hier nur :)

Also dachte ich, ich würde versuchen, die Protokolldatei zu sichern und dann eine DBCC-SHRINKFILE zu erstellen (und die neue Protokolldateigröße in 12800 ändern, da dies die in der Ausgabe des vorherigen DBCC-SHRINKFILE-Befehls angegebene Mindestgröße war).

BACKUP LOG [My DB] TO DISK = 'D:\SQLBackup\20110824-MyDB-Log.bak'
GO
DBCC SHRINKFILE (N'My DB_Log' , 12800)
GO

Das Ergebnis war das gleiche wie beim ersten Mal. Ich kann die Protokolldatei nur auf 62 GB reduzieren.

Ich bin mir nicht sicher, was ich falsch mache und was ich als nächstes versuchen soll.

70
Ed Sinek

Zusätzlich zu den bereits durchgeführten Schritten müssen Sie den Wiederherstellungsmodus auf einfach einstellen, bevor Sie das Protokoll verkleinern können.

DIESES IS NOT A RECOMMENDED PRACTICE für Produktionssysteme ... Sie werden Ihre Fähigkeit verlieren, sich bis zu einem Punkt in zu erholen Zeit aus früheren Backups/Protokolldateien.

Ein Beispiel und eine Erläuterung finden Sie in Beispiel B auf dieser Seite DBCC SHRINKFILE (Transact-SQL) msdn.

35
jlnorsworthy

Okay, hier ist eine Lösung, um die physische Größe der Transaktionsdatei zu reduzieren, aber ohne Ändern Sie den Wiederherstellungsmodus auf einfach.

Suchen Sie in Ihrer Datenbank die file_id der Protokolldatei mit der folgenden Abfrage.

SELECT * FROM sys.database_files;

In meinem Fall ist die Protokolldatei file_id 2. Jetzt möchten wir die verwendeten virtuellen Protokolle suchen und dies mit dem folgenden Befehl ausführen.

DBCC LOGINFO;

Hier können Sie feststellen, ob virtuelle Protokolle verwendet werden, indem Sie feststellen, ob der Status 2 (in Verwendung) oder 0 (frei) ist. Beim Verkleinern von Dateien werden leere virtuelle Protokolle ab dem Ende der Datei physisch entfernt, bis der erste Verwendungsstatus erreicht ist. Aus diesem Grund wird eine Transaktionsprotokolldatei beim Verkleinern manchmal teilweise verkleinert, es werden jedoch nicht alle freien virtuellen Protokolle entfernt.

Wenn Sie feststellen, dass Status 2 nach 0 auftritt, wird der Verkleinerungsvorgang dadurch daran gehindert, die Datei vollständig zu verkleinern. Um dies zu umgehen, führen Sie eine weitere Transaktionsprotokollsicherung durch und führen Sie diese Befehle sofort aus. Geben Sie dabei die oben angegebene Datei-ID und die Größe an, auf die Ihre Protokolldatei reduziert werden soll.

-- DBCC SHRINKFILE (file_id, LogSize_MB)
DBCC SHRINKFILE (2, 100);
DBCC LOGINFO;

Daraufhin wird die Zuordnung der virtuellen Protokolldatei angezeigt, und Sie werden hoffentlich feststellen, dass sie etwas reduziert wurde. Da virtuelle Protokolldateien nicht immer in der richtigen Reihenfolge zugewiesen werden, Sie müssen möglicherweise das Transaktionsprotokoll ein paarmal sichern und diese letzte Abfrage erneut ausführen; Aber ich kann es normalerweise in ein oder zwei Backups verkleinern.

116
Radderz

Ich benutze dieses Skript auf SQL Server 2008 R2.

USE [db_name]

ALTER DATABASE [db_name] SET RECOVERY SIMPLE WITH NO_WAIT

DBCC SHRINKFILE([log_file_name]/log_file_number, wanted_size)

ALTER DATABASE [db_name] SET RECOVERY FULL WITH NO_WAIT
13
manit

Versuche dies

ALTER DATABASE XXXX  SET RECOVERY SIMPLE

use XXXX

declare @log_File_Name varchar(200) 

select @log_File_Name  = name from sysfiles where filename like '%LDF'

declare @i int = FILE_IDEX ( @log_File_Name)

dbcc shrinkfile ( @i , 50) 
7
user2630576

Paul Randal hat eine ausgezeichnete Diskussion über dieses Problem in seinem Blog: http://www.sqlskills.com/blogs/paul/post/backup-log-with-no_log-use-abuse- und-undokumentierte-Trace-Flags-to-Stop-it.aspx

4
PseudoToad

Verkleinern einer Protokolldatei

Für Protokolldateien verwendet das Datenbankmodul target_size, um die Zielgröße für das gesamte Protokoll zu berechnen. Zielgröße ist daher die Menge an freiem Speicherplatz im Protokoll nach dem Verkleinerungsvorgang. Die Zielgröße für das gesamte Protokoll wird dann in die Zielgröße für jede Protokolldatei übersetzt. DBCC SHRINKFILE versucht, jede physische Protokolldatei sofort auf ihre Zielgröße zu verkleinern.

Befindet sich jedoch ein Teil des logischen Protokolls in den virtuellen Protokollen außerhalb der Zielgröße, gibt das Datenbankmodul so viel Speicherplatz wie möglich frei und gibt dann eine Informationsmeldung aus.

Die Nachricht beschreibt, welche Aktionen erforderlich sind, um das logische Protokoll aus den virtuellen Protokollen am Ende der Datei zu verschieben. Nach dem Ausführen der Aktionen kann mit DBCC SHRINKFILE der verbleibende Speicherplatz freigegeben werden.

Da eine Protokolldatei nur auf eine virtuelle Protokolldateigrenze verkleinert werden kann, ist es möglicherweise nicht möglich, eine Protokolldatei auf eine Größe zu verkleinern, die kleiner als die Größe einer virtuellen Protokolldatei ist, auch wenn dies nicht der Fall ist wird verwendet . Die Größe der virtuellen Protokolldatei wird vom Datenbankmodul dynamisch ausgewählt, wenn Protokolldateien erstellt oder erweitert werden.

  • Fehlerbehebung: Die Datei wird nicht verkleinert

Wenn der Verkleinerungsvorgang fehlerfrei ausgeführt wird, die Größe der Datei jedoch scheinbar nicht geändert wurde, überprüfen Sie, ob in der Datei ausreichend Speicherplatz zum Entfernen vorhanden ist, indem Sie einen der folgenden Vorgänge ausführen:

Führen Sie die folgende Abfrage aus.

SELECT name, size/128.0 - CAST (FILEPROPERTY (name, 'SpaceUsed') AS int) /128.0 AS AvailableSpaceInMB FROM sys.database_files;

Führen Sie den Befehl DBCC SQLPERF aus, um den im Transaktionsprotokoll verwendeten Speicherplatz zurückzugeben.

  • Wenn nicht genügend freier Speicherplatz verfügbar ist, kann der Verkleinerungsvorgang die Dateigröße nicht weiter reduzieren.

  • In der Regel scheint die Protokolldatei nicht zu verkleinern. Dies ist normalerweise das Ergebnis einer Protokolldatei, die nicht abgeschnitten wurde.

  • Sie können das Protokoll abschneiden , indem Sie das Datenbank-Wiederherstellungsmodell auf EINFACH setzen. oder durch Sichern des Protokolls und anschließendes erneutes Ausführen der Operation DBCC SHRINKFILE .

Beispiel:

Verkleinern einer Protokolldatei auf eine bestimmte Zielgröße

Im folgenden Beispiel wird die Protokolldatei in der AdventureWorks-Datenbank auf 1 MB verkleinert. Damit der Befehl DBCC SHRINKFILE die Datei verkleinern kann, wird die Datei zuerst abgeschnitten, indem das Datenbankwiederherstellungsmodell auf SIMPLE festgelegt wird.

Transact-SQL

USE AdventureWorks2012;
GEHEN
- Kürzen Sie das Protokoll, indem Sie das Datenbankwiederherstellungsmodell auf EINFACH ändern.
ALTER DATABASE AdventureWorks2012
EINFACHES EINSTELLEN DER WIEDERHERSTELLUNG;
GEHEN
- Verkleinern Sie die abgeschnittene Protokolldatei auf 1 MB.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GEHEN
- Setzen Sie das Datenbankwiederherstellungsmodell zurück.
ALTER DATABASE AdventureWorks2012
SET RECOVERY FULL;
GEHEN

Wenn Sie DBCC SHRINKFILE (Logfile, size) verwenden, wird nur bis zum Ende der Protokolldatei gekürzt. Wenn es das höchste virtuelle Protokoll erreicht, das noch verwendet wird, kann es nicht weiter verkleinert werden. Dies wird in der SQL Server-Onlinedokumentation beschrieben unter:

http://technet.Microsoft.com/en-us/library/ms189493.aspx

Sobald das obere Ende des Protokolls klar ist, kann es verkleinert werden. Dies hängt wiederum davon ab, wie viel des Protokolls noch verwendet wird. Das Protokoll kann durch Sicherungen gelöscht werden, die Sicherungen löschen jedoch keine unvollständigen Transaktionen, sodass das Protokoll auch nach wiederholten Sicherungen in einem High-End-Verzeichnis VLF verbleiben kann.

Wie groß war die ursprünglich erstellte Protokolldatei im Hinblick auf die Zunahme und Abnahme von VLFs und wie ist die Einstellung für das Wachstum der Protokolldatei? Wenn es nur um einen kleinen Betrag wächst, werden mehr VLFs erzeugt, als irgendjemand wünscht.

Ein übliches Muster zum Verkleinern einer Protokolldatei ist CHECKPOINT, BACKUP, SHRINKFILE, CHECKPOINT, BACKUP, SHRINKFILE usw., bis Sie Ergebnisse erhalten. Es gibt viele Gründe, warum das Protokoll möglicherweise nicht verkleinert werden kann, einschließlich eines sehr großen Rollbacks.

Das Umschalten von Einfach auf Voll hat ein Problem:

Hier gibt es Regeln und Ausnahmen. Wir werden im Folgenden ausführlich über langfristige Transaktionen sprechen.

Eine Einschränkung, die Sie beim vollständigen Wiederherstellungsmodus beachten sollten, ist folgende: Wenn Sie nur in den vollständigen Wiederherstellungsmodus wechseln, jedoch niemals eine erste vollständige Sicherung durchführen, wird SQL Server Ihrer Anforderung nach einer vollständigen Wiederherstellung nicht nachkommen. Ihr Transaktionsprotokoll funktioniert weiterhin wie in Simple, bis Sie zu Full Recovery Model wechseln UND Ihre erste vollständige Sicherung durchführen.

Vollständiges Wiederherstellungsmodell ohne Protokollsicherungen ist schlecht:

Das ist also der häufigste Grund für ein unkontrolliertes Holzwachstum? Antwort: Sie befinden sich im vollständigen Wiederherstellungsmodus, ohne Protokollsicherungen durchzuführen.

Dies passiert den Menschen ständig.

Warum ist das so ein häufiger Fehler?

Warum passiert es die ganze Zeit? Weil jede neue Datenbank ihre anfängliche Einstellung für das Wiederherstellungsmodell erhält, indem sie sich die Modelldatenbank ansieht.

Die anfängliche Einstellung für das Wiederherstellungsmodell des Modells ist immer "Vollständiges Wiederherstellungsmodell" - bis jemand dies ändert. Man könnte also sagen, dass das "Standard-Wiederherstellungsmodell" voll ist. Vielen Benutzern ist dies nicht bekannt, und ihre Datenbanken werden im vollständigen Wiederherstellungsmodell ohne Protokollsicherungen ausgeführt. Daher ist eine Transaktionsprotokolldatei viel größer als erforderlich. Aus diesem Grund ist es wichtig, die Standardeinstellungen zu ändern, wenn sie für Ihr Unternehmen und dessen Anforderungen nicht funktionieren.

4
Kundan Dasange

Ich habe viele Möglichkeiten ausprobiert, aber das funktioniert.

Beispielcode ist in DBCC SHRINKFILE verfügbar

USE DBName;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE DBName  
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 1 MB.  
DBCC SHRINKFILE (DBName_log, 1);  --File name SELECT * FROM sys.database_files; query to get the file name
GO  
-- Reset the database recovery model.  
ALTER DATABASE DBName  
SET RECOVERY FULL;  
GO
2
Sathish