Datenbank nach Drop-Tabelle verkleinern?


7

Ich hatte eine Tabelle mit mehr als 70 Millionen Datensätzen in einer SQL Server-Datenbank. Ich habe diese Tabelle gelöscht (eine einmalige Sache), um Speicherplatz auf der Festplatte freizugeben, aber es sieht so aus, als hätte sich die Größe nicht wesentlich geändert. Ich sehe, dass ich die Datenbank auf ein Minimum verkleinern könnte.

Ist das der Weg, es zu tun?

Das letzte Mal, als ich mit SQL Server Management Studio verkleinert habe, dauerte es einige Stunden. Gibt es einen schnelleren Weg?

Geben Sie hier die Bildbeschreibung ein

Antworten:


10

Durch das Löschen einer Tabelle wird der Speicherplatz in der Datenbank freigegeben, der Speicherplatz wird jedoch nicht an Windows zurückgegeben. Dazu muss die Datenbankdatei verkleinert werden. Wir möchten jedoch nicht, dass die Datenbankdatei voll ist. Wir möchten viel freien Speicherplatz, damit wir beim Laden weiterer Daten die Datendatei nicht häufig vergrößern müssen. Dies führt zu einer Fragmentierung der Datendatei auf den physischen Datenträgern.

Nein, es gibt keine Möglichkeit, das Schrumpfen schneller zu machen. Zum Verkleinern der Datenbank müssen die meisten Daten in der Datenbank gelesen und neu geschrieben werden, damit der gesamte Leerraum aus der Datenbankdatei an das Betriebssystem zurückgegeben werden kann. All diese E / A-Vorgänge benötigen Zeit und verursachen viele Fragmentierungsprobleme.


7

Sie sollten DBCC SHRINKFILE sehr sorgfältig lesen.

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

Im Allgemeinen möchten Sie Ihre Datenbank nicht auf die kleinstmögliche Größe auf der Festplatte verkleinern. Sie möchten SQL Server mit viel Speicherplatz belassen, damit es nicht automatisch stark wachsen muss. Die Antwort hier enthält viele nützliche Informationen:

/programming/4522719/to-dbcc-shrinkdatabase-or-not-to-dbcc-shrinkdatabase-thats-the-question


Danke für diese Info. Mein Hauptanliegen ist die Backup-Größe. Wird das Backup jetzt nach der Drop-Tabelle kleiner?
Ezi

1
Ja auf jeden Fall. Wenn Sie über SQL 2008+ verfügen, lesen Sie auch die Sicherungskomprimierung. Es ist einfach und ich habe wirklich gute Ergebnisse erzielt.

-2

Schrumpfen ist ein ziemlich teures Verfahren und kann Stunden dauern. Um den Speicherplatz am effizientesten zu nutzen, können Sie Tabellen in eine neue Dateigruppe mit vorgefertigten Clustered-Indizes übertragen und vorherige löschen. Ich persönlich bevorzuge dies, weil es einfacher ist, dieses "Schrumpfen" in mehreren Schritten und vorhersehbarer zu machen - also einfacher zu planen. Wenn Sie DBCC SHRINK starten, wissen Sie nicht, wie viel Zeit es dauern wird.

Update (Dank an mrdennny für den Hinweis): Dies ist ein sehr spezifischer Ansatz und kann nur verwendet werden, wenn Sie über eine schreibgeschützte Datenbank (wie Data Warehouse) verfügen, da beim Kopieren von Daten in eine andere Tabelle keine Schreibvorgänge in diese Tabelle für die Tabelle zulässig sind der Konsistenz zuliebe. Um Zeit zu sparen und die maximale Leistung zu erzielen, können Sie die Datenbank auf das SIMPLE-Wiederherstellungsmodell umstellen und den TABLOCK-Hinweis verwenden. Dadurch kann das System nur minimale Protokollierung verwenden und viel weniger in das Transaktionsprotokoll schreiben.


Wie genau erstellen Sie einen Clustered-Index für eine andere Dateigruppe vor? Sie können nur einen Clustered-Index pro Tabelle haben. In jeder Dateigruppe, in der sich der Clustered-Index befindet, befindet sich die Tabelle, während der Clustered-Index die Tabelle ist.
Mrdenny

Nun, Sie haben mich wahrscheinlich falsch verstanden - ich wollte nicht, dass ein neuer Clustered-Index für dieselbe Tabelle erstellt wird - das ist natürlich nicht möglich. Ich meinte die Erstellung einer völlig neuen Dateigruppe, einer neuen Tabelle dort und das Verschieben von Daten in diese. Dann lassen Sie einfach den alten Tisch fallen. sqlskills.com/blogs/paul/post/… Das vorherige Erstellen eines Clustered-Index für eine neue Tabelle ermöglicht nur den Speicherplatz, den die Daten verbrauchen, verlangsamt aber natürlich die Datenlast.
Vlad Ogay

Aus einer wenigen Konsistenz wäre das ein Albtraum. Die Anwendung schreibt Daten in die alte Tabelle, während Sie gerade in die neue Tabelle schreiben. Wenn Sie die Tabellen in eine andere Dateigruppe verschieben möchten, ändern Sie einfach den Clustered-Index und ändern Sie die Dateigruppe, in der er gespeichert ist. SQL erstellt ihn in der neuen Dateigruppe neu. Wenn dies online erfolgt, tritt kein Ausfall der Anwendung auf. Das ist alles ziemlich drastisch, nur um eine Datei zu verkleinern.
Mrdenny

Nun, der Autor hat nichts über das Schreiben gesagt, aber er sagte, es sei nur eine einmalige Sache. Ich spreche von einer schreibgeschützten Tabelle im Data Warehouse, in der Sie normalerweise selten Daten laden. Das stimmt wahrscheinlich nicht für den Autor, aber ALTER-Neuerstellung erfordert zusätzlichen Speicherplatz, der am Ende auch freigegeben werden muss - nicht wahr? Online verlangsamt diesen Prozess, wenn wir möchten, dass er auch in einem Zeitfenster schnell erledigt wird. Wenn Sie die Datenbank in ein einfaches Wiederherstellungsmodell umwandeln und diese Übertragungen im BULK INSERT-Modus durchführen können, sparen Sie Zeit.
Vlad Ogay

Das Ausführen eines ALTER in eine andere Dateigruppe sollte genauso viel Speicherplatz beanspruchen wie das Schreiben der Daten in eine neue Tabelle. Ja, der Online-Betrieb dauert etwas länger, aber das System ist die ganze Zeit betriebsbereit. Wenn der Betrieb Tage dauern kann, kann in einem Wartungsfenster nicht gearbeitet werden. Es gibt auch das Problem, ob Fremdschlüssel vorhanden sind, die diese Tabelle als übergeordnetes Element verwenden und möglicherweise behoben werden müssen. Beim erneuten Erstellen in eine andere Dateigruppe sollten keine Daten mehr bereinigt werden müssen. Auf jeden Fall ist dies keine Technik, die ich einem Kunden jemals empfehlen würde.
Mrdenny

-2

Lesen Sie diesen Artikel: http://itknowledgeexchange.techtarget.com/sql-server/deleting-lob-data-and-shrinking-the-database/

"Die Lösung, die wir gefunden haben, war eigentlich ziemlich einfach. Führen Sie das Löschen der Datenbank wie gewohnt durch. Sichern und Wiederherstellen der Datenbank. Führen Sie dann das Verkleinern durch, und erstellen Sie anschließend die Clustered-Indizes neu, um das durch das Verkleinern verursachte Fragmentierungsproblem zu beheben . "


Ein Verkleinern, gefolgt von einer Neuerstellung des Clustered-Index, wird die Datenbank erneut aufblähen. Die Datenbank soll wachsen, Sie müssen nur planen, wie viel wachsen soll (Autogrowth). Und was werden Sie gewinnen, wenn Sie einen Shrink machen und ein paar Gigs zurückbekommen, wenn die Datenbank wieder auf diese Größe anwächst?
Kin Shah
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.