it-swarm-eu.dev

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 ... Abgesehen davon, dass ich eine 100-GB-Datenbank habe und 50 GB Daten lösche - nicht in einer Tabelle, sondern ein allgemeines Bereinigen alter Daten auf datenbankweiter Ebene, die 90% der Daten abdeckt Tabellen - Ist dies ein geeigneter Anwendungsfall für das Verkleinern der Datenbank?

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

44
bumble_bee_tuna

Ein Reorganisieren und Schrumpfen wird nie wirklich empfohlen.

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 alle Indizes und Einschränkungen für Primär-/Fremdschlüssel vor dem Verkleinern 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. Anschließend werden alle Indizes und Schlüssel neu erstellt.

Das Neuerstellen der Indizes nach dem Verkleinern bedeutet, dass sie nicht wesentlich fragmentiert werden sollten. Wenn sie während des Verkleinerns entfernt werden, bedeutet dies, dass beim erneuten Erstellen nicht viele kleine "Löcher" in der Seitenzuordnung in den Dateien verbleiben, die später zu einer Fragmentierung führen können.

Eine weitere Option, wenn Sie die Anwendungen offline schalten können, besteht darin, alle Daten in eine neue Datenbank mit derselben Struktur zu migrieren. Wenn Ihr Erstellungsprozess solide ist, sollten Sie in der Lage sein, diese leere Datenbank schnell zu erstellen. Wenn nicht, erstellen Sie eine aus der aktuellen Datenbank (stellen Sie eine Sicherung der aktuellen Datenbank 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 100%) wesentlich effizienter sein kann. Um den Kopiervorgang zu beschleunigen, müssen Sie die Datendatei (en) der Zieldatenbank auf verschiedenen physischen Laufwerken in die Quelle verschieben (es sei denn, Sie verwenden SSDs. In diesem Fall müssen Sie sich nicht um die Reduzierung der Kopfbewegungen kümmern), können Sie sie verschieben zum 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 ein Wachstum von einigen Monaten enthält. Dadurch wird die Datenkopie wieder etwas schneller als Während des gesamten Prozesses wird nicht immer wieder neuer Speicherplatz zugewiesen.

Dies ist möglicherweise besser als die Verwendung von Shrink, da durch die Migration der Daten in eine neue Datenbank die beabsichtigte Aktion des Shrink-Vorgangs repliziert wird, jedoch möglicherweise mit weitaus geringerer Fragmentierung (was die unbeabsichtigte Folge eines Reorganisierens und Shrinkens ist). Ein Verkleinerer nimmt einfach Blöcke vom Ende der Datei und platziert sie an der ersten Stelle näher am Anfang, ohne die zugehörigen Daten zusammenzuhalten.

Ich vermute, dass das Ergebnis auch räumlich effizienter sein wird, da es danach wahrscheinlich weniger teilweise genutzte Seiten gibt. Beim Verkleinern 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 (wo eine Tabelle einen hat) in das Ziel einfügen und andere Indizes erstellen nachdem alle Daten migriert wurden.

Wenn Sie die Apps überhaupt nicht offline schalten können, ist natürlich nur das Verkleinern Ihre einzige Option. Wenn Sie also wirklich den Speicherplatz zurückfordern müssen, gehen Sie damit. Abhängig von Ihren Daten, Zugriffsmustern, der Größe des allgemeinen Arbeitssatzes, der Größe RAM 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, aber möglicherweise später einfacher zu 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 ein Shrink + Reorganizing für ein Einzelstück wahrscheinlich auch in Ordnung, aber ich mag es einfach, Leute dazu zu bringen, niemals über regelmäßige Shrinks nachzudenken! (Ich habe gewusst, dass die Leute sie täglich planen).

14
David Spillett

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

Wenn Sie die Datenbank verkleinern, wofür werden Sie den freigegebenen Speicherplatz verwenden? Wenn Sie diesen Speicherplatz nur frei halten möchten, falls diese Datenbank wieder wächst, drehen Sie einfach Ihre Räder.

Was Sie in Betracht ziehen könnten, nachdem Sie all diesen freien Speicherplatz in der Datei haben, ist die Neuerstellung Ihrer Indizes, damit diese besser optimiert werden (und es wird viel weniger schmerzhaft sein, dies zu tun, wenn Sie freien Speicherplatz dafür haben - Denken Sie daran, einen Pullover in einem winzigen Schrank gegen ein großes Schlafzimmer auszutauschen.

Wenn dies also keine größere Bereinigungsoperation war und Sie wirklich nicht wieder auf die gleiche Datenmenge hochfahren, würde ich es einfach so lassen, wie es ist, und mich auf andere Bereiche der Optimierung konzentrieren.

16
Aaron Bertrand

Wenn Ihnen der Speicherplatz ausgeht und Ihre Daten nicht so groß werden sollen, schrumpfen Sie, aber erstellen Sie Ihre Indizes anschließend mit geeigneten Füllfaktoren neu, 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 löschen, und verwenden Sie beim Sichern der Datenbank die Komprimierungsoptionen.

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 zuerst auf das eingestellt werden, was Ihrer Meinung nach beispielsweise für ein Jahr erforderlich ist, und Auto Growth sollte auf eine Größe eingestellt werden, die Sie getestet haben und die die Betriebsleistung nicht beeinträchtigt. Siehe Berühren Sie nicht die Schaltfläche zum Verkleinern der Datenbank in SQL Server! von Mike Walsh.

Das Neuerstellen von Indizes vor dem Verkleinern führt dazu, dass die Indizes schlecht angeordnet sind. Es ist nicht gut, wieder aufzubauen und dann zu schrumpfen. Durch das Verkleinern werden die Indizes entstellt, um Speicherplatz wiederherzustellen. Daher ist es sinnlos, sie vorher neu zu erstellen und dann zu verkleinern. Siehe Wann wird Auto Shrink verwendet von Thomas LaRock.

2
GilesDMiddleton

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

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 Wertes gesunken. Aber was bringt es, all das Gepäck herumzutragen? Zumal im Gegensatz zu einigen Artikeln im Internet die Größe Ihrer Datendateien DIREKT mit der Dauer der Sicherung/Wiederherstellung korreliert. Dies liegt daran, dass im Gegensatz zu vielen Artikeln in realen Szenarien auf einer bestimmten Seite mehr Daten geladen werden als nur die Inhalte, die 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 (viele 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 Dateigruppe und legen Sie diese als Standard fest.
  3. Löschen Sie alle nicht gruppierten Indizes (beachten Sie, dass einige Indizes Einschränkungen sein können).
  4. Erstellen Sie Ihre Clustered-Indizes in der neuen Dateigruppe mit DROP_EXISTING = ON (was im Vergleich zu vielen Alternativen zunächst eine immens schnelle, minimal protokollierte Operation ist).
  5. Erstellen Sie Ihre nicht gruppierten Indizes neu.
  6. Zum Schluss SHRINKEN Sie Ihre alte Datendatei (normalerweise PRIMARY).

Auf diese Weise bleiben nur die Systemobjekte, Statistiken, Prozeduren und so weiter Ihrer Datenbank übrig. Die Verkleinerung sollte viel, VIEL schneller sein, und es ist keine weitere Indexpflege für Ihre Hauptdatenobjekte erforderlich, die ordentlich erstellt wurden, und ein minimales Risiko für zukünftige Fragmentierung.

1
Kahn

Ich weiß nicht, ob dies besser funktionieren würde, als nach dem Verkleinern neu zu indizieren, aber eine andere Option wäre, eine neue Datendatei mit angemessener 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 anschließend die Daten zurückzuschieben, um die Seitenumkehr zu vermeiden. Wenn Sie jedoch in den Festkörper wechseln möchten, sollte dies ohnehin keinen großen Unterschied machen.

1
cfradenburg