Wann ist es in Ordnung, eine Datenbank zu verkleinern?

dba.stackexchange https://dba.stackexchange.com/questions/17277

Frage

Ich weiß, dass Shrink der Teufel ist: Es kehrt die Seitenreihenfolge um und ist für Hautkrebs, Datenfragmentierung und globale Erwärmung verantwortlich. Die Liste geht weiter ... Das heißt, ich habe eine 100 -GB Tabellen - ist dies ein geeigneter Anwendungsfall für das Verkleinern der Datenbank?

Wenn nicht, was sind die geeigneten Schritte, um das Haus zu reinigen, nachdem Sie einen so hohen Prozentsatz der Daten aus einer Datenbank entfernt haben? Ich kann mir zwei vorstellen: Wiederherstellung von Indizes und Aktualisierung von Statistiken. Was sonst?

War es hilfreich?

Lösung

Eine Umstrukturierung und Shrink wird nie wirklich empfohlen.

Wenn Sie die Apps einnehmen können, dient die Datenbank offline, können Sie den Prozess beschleunigen und die Indexfragmentierung reduzieren, indem Sie alle Indizes und Primär-/Fremdschlüsseleinschränkungen vor dem Schrumpfen entfernen (dies bedeutet, dass weniger Daten als nur als nur die Umschleppung sind, als nur die Datenseiten werden nicht auf den jetzt nicht existierenden Indexseiten gemischt, die den Prozess beschleunigen) und dann alle Indizes und Tasten neu erstellen.

Das Nachbauen der Indizes nach dem Schrumpfen bedeutet, dass sie nicht wesentlich fragmentiert werden sollten. Wenn sie während des Schrumpfs verschwunden sind, lässt der Wiederaufbau nicht viele kleine "Löcher" in der Seitenzuweisung innerhalb der Dateien hinterlassen, die später eine Fragmentierung einladen können.

Eine weitere Option, wenn Sie die Anwendungen offline können, besteht darin, alle Daten in eine neue Datenbank derselben Struktur zu migrieren. Wenn Ihr Build -Vorgang solide ist, sollten Sie in der Lage sein, diese leere DB schnell zu erstellen, wenn Sie nicht einen aus der aktuellen DB erstellen (eine Sicherung des aktuellen Wiederherstellens wiederherstellen, alle Inhalte in den Tabellen abschneiden/löschen und einen vollständigen Schrumpfen durchführen).

Möglicherweise möchten Sie immer noch alle Indizes im Ziel fallen lassen und danach neu erstellen, da dies bei der Änderung vieler indizierter Daten viel effizienter sein kann (in diesem Fall 100% davon). Um den Kopiervorgang zu beschleunigen, lassen Sie die Datendatei der Zieldatenbank auf verschiedenen physischen Laufwerken zur Quelle (es sei denn, Sie verwenden SSDs. In diesem Fall müssen Sie sich nicht um die Reduzierung von Kopfbewegungen kümmern), können Sie sie verschieben zum Quellort, wenn Sie fertig sind.

Wenn Sie das Ziel als neu erstellen (und nicht durch das Löschen einer Kopie der Quelle), erstellen Sie es mit einer anfänglichen Größe, die alle aktuellen Daten sowie einige Monate Wachstum enthält - dies macht die Datenkopie wieder etwas schneller als Es wird nicht ab und zu neue Raum während des gesamten Prozesses vergeben.

Dies mag besser sein als die Verwendung von Schrumpf, da die Migration der Daten in eine neue Datenbank die beabsichtigte Wirkung des Schrumpfbetriebs repliziert, jedoch möglicherweise mit weitaus weniger Fragmentierung (was die unbeabsichtigte Folge einer Reorganisation und Shrink ist). Ein Schrumpf nimmt einfach Blöcke von nahezu Ende der Datei ab und setzt sie in den ersten Raum näher, nimmt keine Anstrengungen unternommen, um verwandte Daten zusammenzuhalten.

Ich vermute, dass das Ergebnis ebenfalls effizienter sein wird, da danach wahrscheinlich weniger Teilseiten vorhanden sind. Ein Schrumpf verschiebt nur teils verwendete Seiten, wobei die Daten eher zu vollständigen Seiten führen, insbesondere wenn Sie in der Reihenfolge des Clustered-Schlüssels/-index einer Tabelle in das Ziel einfügen und andere Indizes erstellen Nachdem die Daten alle migriert sind.

Wenn Sie die Apps überhaupt nicht offline machen können, ist es Ihre einzige Option, nur einen Schrumpfen durchzuführen. Ja wirklich Ich muss den Raum zurückerobern. Abhängig von Ihren Daten, Zugriffsmustern und der gängigen Arbeitssatzgröße, wie viel RAM der Server usw. hat, ist die zusätzliche interne Fragmentierung am Ende möglicherweise nicht so wichtig.

Für den Kopiervorgang würde entweder SSIS oder Basist-T-SQL genauso gut funktionieren (die SSIS-Option ist möglicherweise weniger effizient, aber möglicherweise einfacher zu pflegen). Wenn Sie die FK -Beziehungen am Ende zusammen mit den Indizes erstellen, können Sie in beiden Fällen eine einfache "für jede Tabelle" machen. Natürlich ist ein Schrumpfen+Reorganisation wahrscheinlich auch in Ordnung, aber ich mag es, Menschen nur zu schüren, wenn ich nie regelmäßige Schrumente in Betracht ziehe! (Ich habe gekannt, dass die Leute sie täglich planen).

Andere Tipps

Wird die Datenbank wieder wachsen? Wenn ja, dann werden die Anstrengungen, die Sie in die Schrumpfvorgänge einsetzen Transaktionen müssen warten, bis dieses Wachstum geschieht. Wenn Sie suboptimale automatische Wachstumseinstellungen haben und/oder eine langsame Antriebsaktivität ist, wird diese Wachstumsaktivität ziemlich schmerzhaft sein.

Wenn Sie die Datenbank verkleinern, wofür werden Sie den freigelassenen Speicherplatz verwenden? Wenn Sie diesen Platz nur noch frei halten, falls diese Datenbank wieder wächst, drehen Sie sich nur mit Ihren Rädern.

Was Sie in Betracht ziehen könnten, jetzt, da Sie all diesen freien Speicherplatz in der Datei haben, bauen Sie Ihre Indizes wieder auf, damit sie besser optimiert sind (und es wird viel weniger schmerzhaft sein, wenn Sie einen freien Platz dazu haben - Denken Sie daran, einen Pullover in einem winzigen Schrank gegen ein großes Schlafzimmer zu wechseln).

Wenn dies also nicht ein großer Aufräumvorgang war und Sie nicht wieder auf das gleiche Datenniveau steigen, lassen ich es einfach so, wie es ist, und konzentrieren mich auf andere Optimierungsbereiche.

Wenn Ihnen der Weltraum ausgeht und Ihre Daten nicht so groß werden sollen, dann schrumpfen Sie jedoch Ihre Indizes mit geeigneten Füllfaktoren, die ein typisches Wachstum ermöglichen.

Wenn Ihr Endziel tatsächlich darin besteht, die Sicherungsgröße zu reduzieren, stellen Sie sicher, dass Sie eine umfassende Sicherungsstrategie implementieren, um das Transaktionsprotokoll zu beseitigen. Wenn Sie die DB sichern, verwenden Sie die Kompressoptionen.

Ich würde kein Autowachstum von 5 GB empfehlen, es sei denn, Sie erwarten normalerweise, dass sie häufig 5 GB wachsen. Andernfalls könnten Sie intermittierende Leistungsprobleme haben. Ihre Datengröße sollte zunächst auf das festgelegt werden, was Sie für ein Jahr für erforderlich halten, und das automatische Wachstum sollte auf eine Größe festgelegt werden, die Sie getestet haben, hat keinen Einfluss auf die Betriebsleistung. Sehen Berühren Sie diese Schrumpfdatenbank -Taste nicht in SQL Server! von Mike Walsh.

Das Wiederaufbau von Indizes vor dem Schrumpfen führt dazu, dass die Indizes schlecht angelegt werden. Es ist nicht gut, wieder aufzubauen, dann zu schrumpfen. Durch das Schrumpfen werden die Indizes verstümmelt, um den Raum wiederzugewinnen - so dass das Wiederaufbau im Voraus sinnlos ist. Sehen Wann ist automatisch Schrumpf zu werden von Thomas Larock.

Ich weiß nicht, ob dies besser funktionieren würde als nach dem Schrumpfen neu, aber eine andere Option wäre, eine neue Datendatei zu erstellen, die angemessen groß ist und alle Daten darauf verschoben wird. In diesem Fall würde ich zuerst eine Reindedex machen, damit Sie wissen, wie die tatsächliche Datengröße ist. Ein Haken ist, dass Sie sie nicht leeren können, wenn dies die erste Datei in der primären Datendatei ist. Sie sollten in der Lage sein, es zu verkleinern und die Daten anschließend zurückzuschieben, und das würde die Seitenumkehr vermeiden. Wenn Sie jedoch in Solid State wechseln möchten, sollte dies sowieso keinen großen Unterschied machen.

Ich komme spät auf diesen Weg zurück. Trotzdem haben wir auch lange Zeit über die Verwendung von Schrumpfen in unseren Testumgebungen nachgedacht und getestet. Gemäß dem Thema dort sind Zeiten, in denen Schrumpfen eine praktikable Option sind. Wenn Sie jedoch wissen, wann und wie man es anwendet, ist es für die ordnungsgemäße Ausführung sowohl lang als auch kurzfristig von entscheidender Bedeutung.

In unserem Szenario haben wir kürzlich zahlreiche Änderungen zu unserer großen DB hinzugefügt, darunter Komprimierung, Partitionierung, Archivierung und einfache alte Löschung von redundanten Daten. Infolgedessen ist der gebrauchte Teil unserer primären Datendatei auf weniger als die Hälfte dessen gesunken, was er früher war. Aber was bringt es, all das Gepäck herumzutragen? Im Gegensatz zu einigen Artikeln im Internet korreliert die Größe Ihrer Datendateien direkt mit der Sicherungs- / Wiederherstellungsdauer. Das liegt daran, dass im Gegensatz zu vielen Artikeln angenommen wird, dass reale Szenarien mehr Daten auf einer bestimmten Seite haben als nur die Dinge, die Sie möglicherweise entfernt haben.

Dies eröffnet ein großartiges Szenario zum Schrumpfen:

  1. Erstellen Sie ein Skript, das alle Objekte und ihre Dateigruppen in Ihrer Datenbank (zahlreiche Beispiele online) findet. Verwenden Sie diese, um die Drop -Klauseln zu erstellen und Definitionen für jede Ihrer Indizes und Einschränkungen zu erstellen.
  2. Erstellen Sie eine neue Datei & Dateigruppe und machen Sie dies zur Standardeinstellung.
  3. Lassen Sie alle nicht klusterten Indizes fallen (beachten Sie, dass einige Indizes Einschränkungen sein können).
  4. Erstellen Sie Ihre Cluster -Indizes auf der neuen Dateigruppe mit Drop_EXISTING = on (was übrigens eine immens schnelle, minimal protokollierte Operation ist, mit vielen Alternativen im Vergleich zu vielen Alternativen).
  5. Erstellen Sie Ihre nicht klusterten Indizes.
  6. Verkleinern Sie Ihre alte Datendatei (normalerweise primär).

Auf diese Weise gibt es die einzigen Daten, die dort noch da sind, die Systemobjekte, Statistiken, Verfahren und so weiter. Der Schrumpf sollte viel, viel schneller sein, und es ist keine weitere Indexwartung Ihrer Hauptdatenobjekte erforderlich, die ordentlich in der Reihenfolge und minimales Risiko für zukünftige Fragmentierung erstellt wurden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top