Wann ist es in Ordnung, eine Datenbank zu verkleinern?

Ich weiß, dass Schrumpfen der Teufel ist: Es kehrt die Seitenreihenfolge um und ist für Hautkrebs, Datenfragmentierung und globale Erwärmung verantwortlich. Die Liste geht weiter ... Davon abgesehen habe ich eine 100 - GB - Datenbank und lösche 50 GB - Daten - nicht in einer Tabelle, sondern in einer Datenbank, die 90% der alten Daten abdeckt Tabellen - stellt dies einen geeigneten Anwendungsfall für das Verkleinern der Datenbank dar?

Wenn nicht, was sind die geeigneten Schritte, um das Haus zu bereinigen, nachdem ein so hoher Prozentsatz von Daten aus einer Datenbank entfernt wurde? Ich kann mir zwei vorstellen: Indizes neu erstellen und Statistiken aktualisieren. Was sonst?

Ein Reorganisieren-und-Schrumpfen ist eigentlich nie zu empfehlen.

Wenn Sie die Apps, die von der Datenbank bereitgestellt werden, offline schalten können, können Sie den Prozess beschleunigen und die Indexfragmentierung reduzieren, indem Sie vor dem Verkleinern alle Indizes und Primär- / Fremdschlüsseleinschränkungen entfernen (dies bedeutet, dass weniger Daten verschoben werden müssen als nur die Datenseiten werden gemischt, nicht die jetzt nicht vorhandenen Indexseiten, was den Prozess beschleunigt. Erstellen Sie dann alle Indizes und Schlüssel neu.

Wenn Sie die Indizes nach dem Verkleinern neu erstellen, sollten sie nicht wesentlich fragmentiert sein. Wenn Sie sie während des Verkleinerns nicht mehr verwenden, führt dies nicht zu vielen kleinen "Löchern" in der Seitenzuordnung in den Dateien, die später zu einer Fragmentierung führen können.

Eine andere Option, wenn Sie die Anwendungen offline schalten können, besteht darin, alle Daten in eine neue Datenbank derselben Struktur zu migrieren. Wenn Ihr Erstellungsprozess solide ist, sollten Sie in der Lage sein, diese leere Datenbank schnell zu erstellen, wenn Sie keine aus der aktuellen Datenbank erstellen (stellen Sie eine Sicherung der aktuellen wieder her, kürzen / löschen Sie alle Inhalte in den Tabellen und führen Sie eine vollständige Verkleinerung durch).

Möglicherweise möchten Sie dennoch alle Indizes im Ziel löschen und anschließend neu erstellen, da dies beim Ändern vieler indizierter Daten (in diesem Fall zu 100%) sehr viel effizienter sein kann. Um den Kopiervorgang zu beschleunigen, müssen Sie die Datendateien der Zieldatenbank auf verschiedenen physischen Laufwerken zur Quelle haben (es sei denn, Sie verwenden SSDs. In diesem Fall müssen Sie sich nicht um die Reduzierung der Kopfbewegungen kümmern). Sie können sie verschieben an den Quellspeicherort, wenn Sie fertig sind.

Wenn Sie das Ziel als neu erstellen (anstatt eine Kopie der Quelle auszublenden), erstellen Sie es mit einer Anfangsgröße, die alle aktuellen Daten sowie einige Monate Wachstum enthält. Dadurch werden die Daten wieder ein wenig schneller kopiert Es wird während des gesamten Vorgangs nicht ab und zu neuer Speicherplatz zugewiesen.

Dies ist möglicherweise besser als die Verwendung von "Verkleinern", da durch die Migration der Daten in eine neue Datenbank die beabsichtigte Aktion des Verkleinerungsvorgangs repliziert wird, jedoch möglicherweise eine weitaus geringere Fragmentierung auftritt (was die unbeabsichtigte Folge einer Reorganisation und Verkleinerung ist). Bei einem Verkleinerungsvorgang werden nur Blöcke vom Ende der Datei entfernt und am Anfang an die erste Stelle verschoben, ohne dass die zugehörigen Daten zusammengehalten werden müssen.

Ich vermute, dass das Ergebnis auch platzsparender sein wird, da es danach wahrscheinlich weniger teilweise genutzte Seiten gibt. Durch einen Verkleinerungsvorgang werden nur teilweise verwendete Seiten verschoben. Das Verschieben der Daten führt mit größerer Wahrscheinlichkeit zu vollständigen Seiten, insbesondere wenn Sie in der Reihenfolge des gruppierten Schlüssels / Index einer Tabelle (sofern eine Tabelle einen hat) in das Ziel einfügen und andere Indizes erstellen nachdem die Daten alle migriert sind.

Natürlich , wenn man die Apps überhaupt nicht offline nehmen, nur eine Schrumpf Durchführung ist Ihre einzige Option wenn Sie also wirklich den Raum gehen mit , dass zurückzufordern müssen. Abhängig von Ihren Daten, Zugriffsmustern, der allgemeinen Größe des Arbeitsspeichers, dem Arbeitsspeicher des Servers usw. ist die zusätzliche interne Fragmentierung am Ende möglicherweise nicht so bedeutend.

Für den Kopiervorgang würde entweder SSIS oder Basis-T-SQL genauso gut funktionieren (die SSIS-Option ist möglicherweise weniger effizient, lässt sich aber möglicherweise später einfacher warten). Wenn Sie die FK-Beziehungen am Ende zusammen mit den Indizes erstellen, können Sie in beiden Fällen einfach "für jede Tabelle kopieren". Natürlich ist eine einmalige Neuorganisation mit Shrink + wahrscheinlich auch in Ordnung, aber ich erschrecke die Leute nur gerne, wenn sie nie daran denken, regelmäßig zu schrumpfen! (Ich habe gewusst, dass die Leute sie täglich planen).

Wird die Datenbank wieder wachsen? Wenn ja, wird der Aufwand, den Sie für den Verkleinerungsvorgang aufwenden, nur eine Verschwendung sein, denn wenn Sie die Dateigröße verringern und dann weitere Daten hinzufügen, muss die Datei einfach wieder wachsen und Transaktionen müssen auf dieses Wachstum warten. Wenn Sie suboptimale Einstellungen für das automatische Wachstum und / oder einen langsamen Antrieb haben, wird diese Wachstumsaktivität ziemlich schmerzhaft sein.

Wofür verwenden Sie den freigewordenen Speicherplatz, wenn Sie die Datenbank verkleinern? Wenn Sie diesen Speicherplatz für den Fall freigeben möchten, dass diese Datenbank erneut wächst, müssen Sie nur die Räder drehen.

Wenn Sie jetzt über den gesamten freien Speicherplatz in der Datei verfügen, können Sie in Erwägung ziehen, Ihre Indizes neu zu erstellen, damit sie besser optimiert werden (und dies ist weitaus weniger schmerzhaft, wenn Sie dazu freien Speicherplatz haben - Denken Sie darüber nach, einen Pullover in einem winzigen Schrank gegen einen großen Schlafraum auszutauschen.

Wenn es sich also nicht um eine umfangreiche Bereinigung handelt und Sie nicht wirklich wieder auf die gleiche Datenmenge hochfahren, lasse ich es einfach wie es ist und konzentriere mich auf andere Bereiche der Optimierung.

Wenn Ihnen der Speicherplatz ausgeht und Ihre Daten nicht so groß werden sollen, schrumpfen Sie, aber erstellen Sie Ihre Indizes danach mit geeigneten Füllfaktoren neu, die ein typisches Wachstum ermöglichen.

Wenn Ihr Endziel tatsächlich darin besteht, die Sicherungsgröße zu reduzieren, müssen Sie eine umfassende Sicherungsstrategie implementieren, um das Transaktionsprotokoll zu löschen, und beim Sichern der Datenbank die Komprimierungsoptionen verwenden.

• Erstellen Sie eine vollständige Datenbanksicherung (SQL Server)
• Transaktionsprotokollsicherungen (SQL Server)

Ich würde ein automatisches Wachstum von 5 GB nicht empfehlen, es sei denn, Sie erwarten normalerweise ein häufiges Wachstum von 5 GB. Andernfalls können zeitweise Leistungsprobleme auftreten. Ihre Datengröße sollte zunächst auf das eingestellt werden, was Ihrer Meinung nach beispielsweise für ein Jahr erforderlich ist, und das automatische Wachstum sollte auf eine Größe eingestellt werden, die Sie getestet haben und die die Betriebsleistung nicht beeinflusst. Siehe Nicht die Schaltfläche "Datenbank verkleinern" in SQL Server berühren! von Mike Walsh.

Das Neuerstellen von Indizes vor dem Verkleinern führt dazu, dass die Indizes nicht richtig angeordnet sind. Es ist nicht gut, wieder aufzubauen und dann zu verkleinern. Durch das Verkleinern werden die Indizes entstellt, um Speicherplatz freizugeben. Daher ist das vorherige Neuerstellen und anschließende Verkleinern sinnlos. Siehe Wann Auto Shrink von Thomas LaRock zu verwenden ist.

Ich weiß nicht, ob dies besser funktionieren würde als eine Neuindizierung nach dem Verkleinern, aber eine andere Option wäre, eine neue Datendatei mit der entsprechenden Größe zu erstellen und alle Daten dorthin zu verschieben. In diesem Fall würde ich zuerst eine Neuindizierung durchführen, damit Sie wissen, wie groß die Daten tatsächlich sind. Ein Haken ist, dass wenn dies die erste Datei in der primären Datendatei ist, ich glaube nicht, dass Sie sie leeren können. Sie sollten in der Lage sein, es zu verkleinern und die Daten anschließend zurück zu verschieben. Dadurch würde die Seitenumkehr vermieden. Wenn Sie jedoch auf Solid State umsteigen möchten, sollte dies ohnehin keinen großen Unterschied machen.

Ich komme zu spät auf diesen Weg zurück. Trotzdem haben wir schon lange über die Verwendung von Shrink in unseren Testumgebungen nachgedacht und sie getestet. Gemäß dem Thema gibt es Zeiten, in denen das Schrumpfen eine gangbare Option ist. Das Wissen, wann und wie es anzuwenden ist, ist jedoch sowohl auf lange als auch auf kurze Sicht von entscheidender Bedeutung für eine ordnungsgemäße Ausführung.

In unserem Szenario haben wir kürzlich zahlreiche Änderungen an unserer großen Datenbank vorgenommen, darunter Komprimierung, Partitionierung, Archivierung und einfaches Löschen redundanter Daten. Infolgedessen ist der verwendete Teil unserer Primärdatendatei auf weniger als die Hälfte des früheren Werts gesunken. Aber wozu soll man das ganze Gepäck mitnehmen? Zumal im Gegensatz zu einigen Artikeln im Internet die Größe Ihrer Datendateien DIREKT MIT DER SICHERUNGS- / WIEDERHERSTELLUNGSDAUER korreliert. Dies liegt daran, dass reale Szenarien im Gegensatz zu vielen anderen Artikeln mehr Daten auf einer bestimmten Seite enthalten als nur das, was Sie möglicherweise entfernt haben.

Genauer gesagt, dies eröffnet ein großartiges Szenario für das Schrumpfen:

1. Erstellen Sie ein Skript, das alle Objekte und ihre Dateigruppen in Ihrer Datenbank findet (zahlreiche Beispiele online). Verwenden Sie dieses Skript, um die Drop-Klauseln zu erstellen und Definitionen für jeden Ihrer Indizes und Einschränkungen zu erstellen.
2. Erstellen Sie eine neue Datei und eine neue Dateigruppe, und legen Sie diese als Standard fest.
3. Löschen Sie alle nicht gruppierten Indizes (einige Indizes können Einschränkungen sein).
4. Erstellen Sie Ihre Clustered-Indizes für die neue Dateigruppe mit DROP_EXISTING = ON (was übrigens eine im Vergleich zu vielen Alternativen immens schnelle, minimal protokollierte Operation ist).
5. Erstellen Sie Ihre nicht gruppierten Indizes neu.
6. Schließlich SHRINKEN Sie Ihre alte Datendatei (normalerweise PRIMARY).

Auf diese Weise bleiben nur die Systemobjekte, Statistiken, Prozeduren und so weiter Ihrer DB übrig. Die Verkleinerung sollte viel, VIEL schneller sein, und es ist keine weitere Indexpflege für Ihre Hauptdatenobjekte erforderlich, die ordnungsgemäß erstellt wurden und das Risiko einer zukünftigen Fragmentierung minimieren.