Database
 sql >> Datenbank >  >> RDS >> Database

Überblick über den DBCC SHRINKFILE-Befehl

Das Ausführen von DBCC Shrink-Befehlen ist in der SQL Server-Community ein ziemlich umstrittenes Thema. In diesem Artikel werden wir Details zu diesem Befehl überprüfen und einen kurzen Überblick über seine Verwendung geben und Sie auch vor den Risiken der Ausführung dieses Befehls warnen. Als DBAs wurden eine Reihe von Datenbanken von anderen Teams oder Anbietern übergeben, und nicht immer dürfen wir die von uns erstellten Datenbanken verwalten. Als DBAs müssen wir immer dann, wenn wir an Migrationen oder neuen Projekten beteiligt sind, sicherstellen, dass wir einen reibungslosen Übergang der Datenbank in die Produktion und regelmäßige Nutzung sorgfältig planen. An dieser Stelle müssen wir die Größe der Datenbank berücksichtigen. Können Sie sich vorstellen, eine Datenbankanwendung einzurichten, ohne die Wachstumsprognose für das erste Jahr oder so zu berücksichtigen? Wie wäre es, wenn Sie eine SQL Server-Datenbank erstellen, deren Größe so klein ist, dass sie jeden zweiten Tag wachsen muss und mitten in der Nacht Festplattenkapazitätswarnungen auslöst? Es mag albern klingen, aber die Wahrheit ist, dass dies passiert und manchmal nicht in Ihrer Kontrolle liegt.

Wenige Punkte, die für den proaktiven DBA zu berücksichtigen sind

Bevor Sie die Betreuung der Produktionsdatenbanken übernehmen, sollten Sie sich unbedingt bei Ihrem Vorgänger erkundigen, wie die Prognosen in Bezug auf das Datenbankwachstum aussehen. Ist die anfängliche Größe der Datenbanken, die Sie verwalten werden, angemessen bemessen? Machen Sie sich keine Sorgen, wenn die aktuelle Größe der Datenbank viel größer ist als die Daten, die sie derzeit hat. Denken Sie daran, dass Sie diese Festplattenkapazitätsanrufe um 3:00 Uhr morgens nicht wollen, wenn Sie sie durch eine Datenbank mit der richtigen Größe hätten vermeiden können. Es ist ein allgemeiner Trend für Datenbankadministratoren in der gesamten Branche, spät in der Nacht ihr Leben für alltägliche Probleme zu opfern, die gar nicht erst hätten auftreten dürfen. Berücksichtigen Sie neben der Datenbankgröße auch die Festplattenkapazität des Servers. Sie möchten nicht, dass die Festplattengröße viel zu klein ist, als eine Datenbank aufnehmen kann. Dies sind alles einfache Dinge, die sich zum Zeitpunkt der Planung als nützlich erweisen. Wie Sie wissen, ist es jedoch nicht immer ein Datenbankprofi, der Datenbanken installiert oder konfiguriert. Der wichtige Punkt, den Sie beachten sollten, ist, die Grundlagen Ihrer Datenbank in Bezug auf die Größe richtig zu machen, und Sie müssen diesen Befehl möglicherweise nie ausführen. Wie immer, als DBA, gibt es jedoch Zeiten, in denen die Dinge möglicherweise nicht in Ihrer Kontrolle liegen, und während dieser Zeit können Sie DBCC Shrink-Dateibefehle für eine effiziente Verwendung verwenden.

Wann kann ich DBCC ShrinkFile verwenden?

Sie haben gerade mitten im Schlaf eine Speicherplatzwarnung erhalten und müssen strenge SLAs einhalten. Die Prioritätsstufe ist P2 und das SLA kann sehr bald verletzt werden. Und Sie erkennen, dass die Erweiterung der Festplatte in absehbarer Zeit nicht stattfinden wird. Halten Sie in diesem Fall Ihre DBCC ShrinkFile-Befehle bereit, damit Sie sie verwenden können, um den Speicherplatz zurückzugewinnen. Wie der Name schon sagt, verkleinert es die Datei der Daten- oder Protokolldatei der Datenbank. Aber bevor Sie mit der Ausführung der DBCC-ShrinkFile-Befehle beginnen, versuchen Sie zu überprüfen, warum die Datenbankdatei überhaupt wächst.

  • Ist die Datei aufgrund einer lang andauernden Transaktion gewachsen?
  • Gibt es irgendeine Art von Blockierung auf dem Server?
  • Gibt es eine größere Anwendungsveröffentlichung, über die Sie nicht informiert wurden? (Das passiert meistens)
  • Gibt es irgendein Datenbankreplikations- oder -spiegelungsproblem, das ein Datenbankwachstum verursacht?

Es ist wichtig, möglichst schnell Antworten auf diese Fragen zu erhalten. Im Allgemeinen gibt es eine Antwort auf all diese Fragen, und zwar ein großartiges kostenloses Tool namens sp_whoisactive. Es gibt keine Worte, um die enorme Nutzung dieses Tools zu beschreiben, und ich habe es mehrfach verwendet, um zahlreiche produktionsbezogene Probleme zu beheben. Sie können den neuesten Code von diesem Link herunterladen:http://whoisactive.com/ . Es ist leicht und einfach zu bedienen und gibt die Ausgabe in kürzester Zeit zurück. Wenn Sie ein erfahrener DBA sind, steht Ihnen dies bereits zur Verfügung.

DBCC ShrinkFile mit Beispielen

Die Syntax für DBCC ShrinkFile ist einfach und direkt, siehe dieses Beispiel unten.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

Das obige Beispiel schrumpft FileName, der zu YOURDATABASE gehört, auf 1024 MB. Sie können denselben Vorgang mit SQL Server Management Studio (SSMS) ausführen. Klicken Sie mit der rechten Maustaste auf die Datenbank und gehen Sie zu Aufgaben , wählen Sie Verkleinern aus , und dann Dateien .

Sobald Sie auf Dateien klicken , erhalten Sie dieses Fenster.

Hier haben Sie die Möglichkeit, den Dateityp auszuwählen:Daten, Protokoll oder Filestream-Daten und bei Bedarf die „Aktion verkleinern“ durchzuführen. Es ist einfacher, den DBCC-Befehl selbst zum Verkleinern zu verwenden.

Verwenden von DBCC ShrinkFile mit zusätzlichen Optionen

Sie können den Befehl DBCC ShrinkFile mit zusätzlichen Optionen ausführen – emptyfile, notruncate oder truncateonly.

Leere Datei

Sie können den Befehl emptyfile wie unten verwenden.

use YOURDATABASE
go
dbcc shrinkfile(FileName,emptyfile)

Dies hilft beim Verschieben der Daten in andere Dateien innerhalb derselben Dateigruppe. Anschließend können Sie eine Datenbankdatei löschen, wenn sie nicht mehr benötigt wird. Bei dieser Option emptyfile sind jedoch einige Dinge zu beachten, da Sie nicht viel tun könnten, um den Inhalt der primären Datendatei mit der Datei-ID 1 zu leeren. Führen Sie dieses Skript aus, um die Datei-ID-Nummer zu erhalten.

select file_id, name,physical_name from sys.database_files

Hier, in diesem Beispiel, lautet der Dateiname „mo“ und file_id ist 1. Wenn Sie versuchen, die Datei mo mit file_id 1 zu leeren, erhalten Sie diese Fehlermeldung.

Dies liegt daran, dass die Originaldatei Systeminformationen enthält, die nicht geleert werden können. Aber wenn Sie denselben Befehl mit der anderen Datendatei „mo2data“ versuchen, wird der Befehl „leere Datei“ erfolgreich sein.

Nicht ausführen

Wie der Name schon sagt, wird kein Speicherplatz für das Betriebssystem freigegeben. Dies ist eher eine interne Operation innerhalb der Datei, bei der die Seiten innerhalb der Datei selbst neu verteilt werden, ohne die Gesamtgröße der Datenbankdatei zu ändern. Aus diesem Grund besteht eine große Möglichkeit, dass eine Fragmentierung eingeführt wird. Siehe das Beispiel unten.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,notruncate);  
GO

Nur kürzen

Wie der Name schon sagt, wird freier Speicherplatz vom Ende der Datei an das Betriebssystem zurückgegeben. Dies ist bei weitem der sicherste Vorgang, den Sie mit DBCC ShrinkFile ausführen können. Siehe das Beispiel unten.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,truncateonly);  
GO

Was tun, wenn DBCC ShrinkFile im Transaktionsprotokoll nicht wie erwartet funktioniert? Wenden Sie sich an diese sichere Methode, um das Problem zu beheben

Es kann vorkommen, dass dieser Befehl nicht wie erwartet funktioniert. Angenommen, Sie haben eine Situation, in der Sie versuchen, die Protokolldatei einer Datenbank zu verkleinern, und es scheint nicht zu funktionieren. Im Folgenden finden Sie einige der Schritte, die Sie unternehmen können, um zu verstehen, warum die Verkleinerung nicht wie erwartet funktioniert. Sie werden feststellen, dass die Verkleinerungsdatei als erfolgreich angezeigt wird, die Größe der Protokolldatei jedoch nicht reduziert wird. Führen Sie in diesem Fall diesen Befehl aus, um einige Dinge über die Verwendung der Protokolldatei zu überprüfen.

select name,log_reuse_wait_desc,* from sys.databases

Auf dem Screenshot können Sie sehen, dass die Spalte log_reuse_wait_desc auf eine Protokollsicherung wartet.

Hier sehen Sie, dass die Log-Sicherung für die Datenbank durchgeführt werden muss, bevor Sie die Log-Datei wirklich verkleinern können. Wenn es sich um eine Produktionsdatenbank handelt, versuchen Sie, die Protokollsicherung auf einem anderen Laufwerk durchzuführen, auf dem Speicherplatz verfügbar ist. Verwenden Sie zum Ausführen der Protokollsicherung den folgenden Beispielbefehl.

backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn'
with init,stats,compression

Nachdem Sie den Sicherungsbefehl ausgeführt haben, führen Sie den folgenden Befehl erneut aus, um den Status der Spalte log_reuse_wait_desc anzuzeigen.

select name,log_reuse_wait_desc,* from sys.databases

Auf dem Screenshot können Sie sehen, dass sich der Status für die Spalte log_reuse_wait_desc in „Nichts“ geändert hat.

Hier sehen Sie, dass sich der Status für die Spalte „log_reuse_wait_desc“ auf „Nothing“ geändert hat. In Ihrem Fall wird es möglicherweise immer noch als „LOG_BACKUP“ angezeigt. Führen Sie die Protokollsicherungen für die Datenbank weiter durch, bis sich der Status in „Nichts“ ändert. Der Grund, warum Sie möglicherweise immer noch den Status „LOG_BACKUP“ sehen, selbst nachdem Sie Transaktionsprotokollsicherungen durchgeführt haben, liegt darin, dass möglicherweise keine VLFs gelöscht wurden, nachdem Sie die Transaktionsprotokollsicherung ausgeführt haben. VLF steht für Virtual Log Files und ist Teil der internen Architektur des Transaktionsprotokolls. Transaktionsprotokolldateien bestehen aus diesen VLFs. Sie können Informationen über die VLFs erhalten, indem Sie diesen Befehl ausführen.

select * from sys.dm_db_log_info(5)

Hier steht 5 für die database_id. Der Screenshot der Ausgabe wird angezeigt. Die Anzahl der zurückgegebenen Zeilen stellt die tatsächliche Anzahl der virtuellen Protokolldateien (VLFs) in der Datenbank dar. Sie können die Spalte „vlf_status“ überprüfen, um den Status der virtuellen Protokolldatei zu überprüfen. Wert 2 bedeutet aktiv. Mit diesem Befehl können Sie die internen Flags in der Transaktionsprotokolldatei überprüfen, um zu verstehen, warum das Transaktionsprotokoll auch nach der Durchführung von Protokollsicherungen nicht freigegeben wird.

Zuvor war der verwendete Befehl DBCC LOGINFO, der ähnliche Informationen bereitstellte.

Was tun, wenn DBCC ShrinkFile im Transaktionsprotokoll nicht wie erwartet funktioniert? Etwas, das Sie in einer Nicht-Prod-Umgebung ausführen können. In Produktionsumgebungen jedoch nicht empfohlen

Sie wären auf mehreren Websites auf Leute gestoßen, die empfehlen, das Wiederherstellungsmodell in ein einfaches zu ändern und dann eine Schrumpfdatei auszuführen, um Speicherplatz für das Betriebssystem freizugeben. Denken Sie daran, dass sich die Änderung des Wiederherstellungsmodells auf ein einfaches Modell auf die Wiederherstellung Ihrer Datenbank auswirkt, da Sie nicht bis zu einem bestimmten Zeitpunkt wiederherstellen können. Dies hängt wiederum von Ihrem geschäftlichen SLA ab. Sie können das Wiederherstellungsmodell mit T-SQL (unten) oder mit der GUI ändern.

alter database DB_NAME set recovery simple

Ändern Sie mithilfe der GUI das Wiederherstellungsmodell wie gezeigt. Klicken Sie mit der rechten Maustaste auf die Datenbank, gehen Sie zu „Eigenschaften“, klicken Sie auf „Optionen“. Wählen Sie unter „Optionen“ das „Wiederherstellungsmodell“ aus.

Sie werden feststellen, dass das bloße Ändern des Wiederherstellungsmodells in „Einfach“ den Speicherplatz nicht wieder an das Betriebssystem freigibt. Sie müssten den Befehl DBCC ShrinkFile explizit ausführen, um die Datei zu verkleinern und den Speicherplatz zurückzugewinnen. Sehen Sie sich das Beispielskript unten an. Dieser Befehl verkleinert Ihren Dateinamen auf 1024 MB.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

Datenbankoption automatisch verkleinern

Sie werden feststellen, dass es in den Datenbankeigenschaften eine Option namens „Auto Shrink“ gibt. Klicken Sie einfach mit der rechten Maustaste auf die Datenbank, um die Datenbankeigenschaften anzuzeigen. Unter dem Abschnitt „Optionen“ sehen Sie diese Option wie abgebildet. Aus der Einstellung der Modelldatenbank können Sie ersehen, dass die Option „Auto Shrink“ standardmäßig deaktiviert ist. Wenn also eine neue Datenbank erstellt wird, befindet sich diese Option ebenfalls im deaktivierten Zustand. Es kann vorkommen, dass Datenbankprofis diese Option unwissentlich aktiviert lassen, ohne sich der negativen Folgen bewusst zu sein, wenn sie eingeschaltet bleibt.

Führen Sie diesen Befehl aus, um den Status dieser Option für die Datenbanken auf dem Server zu überprüfen.

select name,is_auto_shrink_on,* from sys.databases

Sie werden diese Ausgabe sehen.

Wenn Sie zufällig sehen, dass es aktiviert ist, können Sie es entweder über die GUI deaktivieren oder den folgenden Befehl für die Datenbank ausführen.

ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF

Weitere Wartungsvorschläge

Beachten Sie diese wenigen zusätzlichen Tipps, um das Problem des Datenbankwachstums zu vermeiden, aufgrund dessen Sie DBCC ShrinkFile-Befehle ausführen müssen.

  • Stellen Sie sicher, dass das Wiederherstellungsmodell Ihrer Datenbanken auf die geschäftlichen SLAs abgestimmt ist. Wenn Ihr Unternehmen keine Point-in-Time-Wiederherstellung für Testdatenbanken benötigt, belassen Sie sie einfach in einem einfachen Wiederherstellungsmodell. Ich habe mehrere Fälle gesehen, in denen das Wiederherstellungsmodell der Datenbanken vollständig war, obwohl die Wiederherstellung mit der letzten vollständigen Sicherung in Ordnung war
  • Stellen Sie eine ordnungsgemäße Überwachung sicher, insbesondere bei Datenbankwachstum. Sie sollten benachrichtigt werden, wenn die Auslastung der Protokolldatei 85 % erreicht. So haben Sie etwas Zeit, um das Platzproblem zu lösen
  • Stellen Sie sicher, dass regelmäßige Protokollsicherungen erstellt werden, wenn sich die Datenbank im vollständigen Wiederherstellungsmodell befindet, und Sie sollten gewarnt werden, wenn eine der Protokollsicherungen fehlschlägt
  • Stellen Sie sicher, dass auf den Datenbanklaufwerken ausreichend Speicherplatz vorhanden ist, um Speicherplatzprobleme zu vermeiden
  • Entwickeln Sie für Datenbanken, die archiviert werden können, einige Archivierungsstrategien, damit Sie ältere Daten in eine andere Datenbank verschieben können, um Berichte zu erstellen und diese Datenbank schreibgeschützt zu machen. Dadurch haben Sie mehr Kontrolle über die Größe der Datenbank
  • Stellen Sie sicher, dass Sie regelmäßig Integritätsprüfungen Ihrer Datenbank mit DBCC CheckDB durchführen. Weitere Informationen finden Sie in diesem Artikel:https://codingsight.com/dbcc-checkdb-overview/

Schlussfolgerung

  • Dieser Artikel hat Ihnen ein gutes Verständnis für die Verwendung des DBCC-Befehls ShrinkFile vermittelt
  • Sie haben die Risiken beim Ausführen der DBCC ShrinkFile-Befehle kennengelernt
  • Sie haben die verschiedenen Optionen kennengelernt, die wir mit den DBCC ShrinkFile-Befehlen bereitstellen können
  • Sie haben die Optionen gesehen, die wir ausprobieren können, wenn das Transaktionsprotokoll mit den DBCC-ShrinkFile-Befehlen nicht schrumpft
  • Sie haben die Standardeinstellung für automatisches Verkleinern in der Datenbankeigenschaft kennengelernt
  • Sie haben auch andere Vorschläge zur Datenbankwartung kennengelernt, um Ihre Datenbanken gesund zu halten
  • Stellen Sie schließlich sicher, dass Sie auf jeden Fall für die AUS-Tage gerüstet sind, die möglicherweise nicht in Ihrer Kontrolle liegen