it-swarm.com.de

Abgeschnittene 200-GB-Tabelle, aber nicht freigegebener Speicherplatz

Ich habe nur noch 2 GB übrig, daher muss ich diese Verlaufstabelle entfernen. Diese Tabelle ist jetzt leer, aber der Datenbankspeicherplatz wurde nicht freigegeben. Und die Datenbankdatei ist 320 GB.

23

Wenn Sie auf den tatsächlichen Verbrauch von Datenbankdateien auf dem Volume verweisen, wird SQL Server behandelt das nicht automatisch. Nur weil Sie Daten aus der Datenbank entfernt haben, werden die Datenbankdateien nicht verkleinert, um nur den vorhandenen Daten zu entsprechen.

Was Sie suchen würden, wenn Sie haben, um Speicherplatz auf dem Volume zurückzugewinnen, würde die bestimmte Datei mit DBCC SHRINKFILE . Es lohnt sich, einige Best Practices gemäß dieser Dokumentation zu erwähnen:

Best Practices

Beachten Sie die folgenden Informationen, wenn Sie eine Datei verkleinern möchten:

  • Eine Verkleinerungsoperation ist am effektivsten nach einer Operation, bei der viel ungenutzter Speicherplatz erstellt wird, z. B. eine Operation zum Abschneiden von Tabellen oder zum Löschen von Tabellen.

  • Für die meisten Datenbanken muss freier Speicherplatz für den täglichen Betrieb verfügbar sein. Wenn Sie eine Datenbank wiederholt verkleinern und feststellen, dass die Datenbankgröße erneut zunimmt, bedeutet dies, dass der verkleinerte Speicherplatz für den regulären Betrieb erforderlich ist. In diesen Fällen ist das wiederholte Verkleinern der Datenbank eine verschwendete Operation.

  • Eine Verkleinerungsoperation behält den Fragmentierungsstatus von Indizes in der Datenbank nicht bei und erhöht im Allgemeinen die Fragmentierung bis zu einem gewissen Grad. Dies ist ein weiterer Grund, die Datenbank nicht wiederholt zu verkleinern.

  • Verkleinern Sie mehrere Dateien in derselben Datenbank nacheinander anstatt gleichzeitig. Konflikte mit Systemtabellen können aufgrund von Blockierungen zu Verzögerungen führen.

Ebenfalls zu beachten:

DBCC SHRINKFILE Vorgänge können zu jedem Zeitpunkt des Prozesses gestoppt werden, und abgeschlossene Arbeiten bleiben erhalten.

Es gibt sicherlich ein paar Dinge zu beachten, und ich würde empfehlen, dass Sie sich Paul Randals Blog-Beitrag ansehen, was passiert, wenn Sie diesen Vorgang ausführen.

Der erste Schritt wäre auf jeden Fall zu überprüfen, wie viel Speicherplatz und freien Speicherplatz Sie tatsächlich ersetzen können, sowie den verwendeten Speicherplatz in den Dateien:

use AdventureWorks2012;
go

;with db_file_cte as
(
    select
        name,
        type_desc,
        physical_name,
        size_mb = 
            convert(decimal(11, 2), size * 8.0 / 1024),
        space_used_mb = 
            convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
    from sys.database_files
)
select
    name,
    type_desc,
    physical_name,
    size_mb,
    space_used_mb,
    space_used_percent = 
        case size_mb
            when 0 then 0
            else convert(decimal(5, 2), space_used_mb / size_mb * 100)
        end
from db_file_cte;
25
Thomas Stringer

Zusätzlich zu den Antworten von Tom und Shanky funktioniert die DBCC SHRINKFILE möglicherweise nicht, wenn Ihre Datenbank LOB/BLOB-Daten enthält. Wenn dies der Fall ist, haben Sie zwei Möglichkeiten, je nachdem, ob Sie die Datenbank offline schalten können oder nicht. Wenn Sie die Datenbank offline schalten können, müssen Sie die Daten kopieren und wieder kopieren, um den leeren Speicherplatz zu entfernen. Sie können dies durch eine der folgenden Aktionen erreichen:

  1. Verwenden einer SELECT INTO - Anweisung, um die gesamte Tabelle in eine neue Tabelle zu übertragen. Löschen Sie die ursprüngliche Tabelle und führen Sie DBCC SHRINKFILE aus. Benennen Sie die neue Tabelle in den ursprünglichen Tabellennamen um.
  2. Kopieren Sie die Tabelle mit bcp im einheitlichen Modus, löschen Sie die Tabelle, führen Sie DBCC SHRINKFILE aus, erstellen Sie eine Tabelle und bcpen Sie die Daten in die Tabelle.
  3. Verwenden Sie Export/Import , um alle Daten in eine neue Datenbank zu verschieben, eine vorhandene Datenbank zu löschen und eine neue Datenbank in den ursprünglichen Datenbanknamen umzubenennen.

Wenn Sie die Datenbank nicht offline schalten können, können Sie den Befehl DBCC SHRINKFILE mit dem Befehl [~ # ~ verwenden ] emptyfile [~ # ~] Option.

Details für die Offline-Kopie: http://support.Microsoft.com/kb/324432/en-us

Aktuelle Informationen zur Option EMPTYFILE http://msdn.Microsoft.com/en-us/library/ms189493 (v = sql.105) .aspx

6
stacylaray

Dies ist ein normales Verhalten beim Abschneiden von Tabellen, bei dem mehr als 128 Speicherbereiche als Per Books Online entfernt werden

Wenn Sie große Indizes löschen oder neu erstellen oder große Tabellen löschen oder abschneiden, verschiebt das Datenbankmodul die tatsächlichen Freigaben der Seite und die zugehörigen Sperren, bis eine Transaktion festgeschrieben wird. Diese Implementierung unterstützt sowohl Autocommit- als auch explizite Transaktionen in einer Mehrbenutzerumgebung und gilt für große Tabellen und Indizes, die mehr als 128 Speicherbereiche verwenden.

Das Datenbankmodul vermeidet die Zuordnungssperren, die zum Löschen großer Objekte erforderlich sind, indem der Prozess in zwei separate Phasen aufgeteilt wird: logisch und physisch.

In der logischen Phase werden die vorhandenen Zuordnungseinheiten, die von der Tabelle oder dem Index verwendet werden, für die Freigabe markiert und gesperrt, bis die Transaktion festgeschrieben wird. Bei einem Clustered-Index, der gelöscht wird, werden die Datenzeilen kopiert und dann in neue Zuordnungseinheiten verschoben, die entweder als neu erstellter Clustered-Index oder als Heap im Speicher erstellt wurden. (Bei einer Indexwiederherstellung werden auch die Datenzeilen sortiert.) Bei einem Rollback muss nur diese logische Phase zurückgesetzt werden.

Die physische Phase tritt auf, nachdem die Transaktion festgeschrieben wurde. Die für die Freigabe markierten Zuordnungseinheiten werden physisch in Stapeln abgelegt. Diese Drops werden in kurzen Transaktionen verarbeitet, die im Hintergrund stattfinden, und erfordern nicht viele Sperren.

Da die physische Phase nach dem Festschreiben einer Transaktion auftritt, wird der Speicherplatz der Tabelle oder des Index möglicherweise weiterhin als nicht verfügbar angezeigt. Wenn dieser Speicherplatz erforderlich ist, damit die Datenbank wächst, bevor die physische Phase abgeschlossen ist, versucht das Datenbankmodul, Speicherplatz aus Zuordnungseinheiten wiederherzustellen, die für die Freigabe markiert sind. Verwenden Sie die Katalogansicht sys.allocation_units, um den aktuell von diesen Zuordnungseinheiten verwendeten Speicherplatz zu ermitteln.

Aufgeschobene Ablagevorgänge geben den zugewiesenen Speicherplatz nicht sofort frei und verursachen zusätzliche Gemeinkosten im Datenbankmodul. Daher werden Tabellen und Indizes, die 128 oder weniger Speicherbereiche verwenden, wie in SQL Server 2000 gelöscht, abgeschnitten und neu erstellt. Dies bedeutet, dass sowohl die logische als auch die physische Phase auftreten, bevor die Transaktion festgeschrieben wird.

Sie müssten warten und natürlich manuell verkleinern Sie die Datei , um Speicherplatz zurückzugewinnen. Erwähnenswert ist auch, dass das Verkleinern eine logische Fragmentierung verursacht und vermieden werden sollte, es sei denn, Sie benötigen Grave. Sie müssten ein wenig wie Gleichgewicht zwischen Schrumpfen und Fragmentieren. Es ist besser, sich zu fragen, ob das Schrumpfen tatsächlich das Problem lösen würde, wenn man bedenkt, dass die Daten ohnehin wieder wachsen werden.

Verwenden Sie die folgende Abfrage, um zu überprüfen, wie viel freier Speicherplatz in der Datenbank vorhanden ist

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