Warum haben wir den Befehl SHRINKDATABASE in SQL Server?

Ich habe im Internet gelesen, wo laut Finest Developer Shrinkdatabse vermieden werden sollte, da dies zu einer Zunahme der Fragmentierung und einer Abnahme der Leistung führt.

Ich würde gerne von euch wissen, ob ihr jemals den Befehl zum Schrumpfen der Datenbank verwendet habt, wenn ja, in welchen praktischen Szenarien wir sie verwenden sollten.

In erster Linie können wir zwischen der Notwendigkeit von SHRINK und der bekannten unbeabsichtigten Nebenwirkung unterscheiden: mögliche Zunahme der Fragmentierung. Letzteres ist ein Nebeneffekt der Implementierung . Tatsächlich ist es durchaus möglich, einen Schrumpf zu entwerfen, der die Fragmentierung verringert (dh den gleichen Effekt wie ein REORGANISIEREN hat), und dies auf Kosten einer erheblich längeren Laufzeit.

Die Notwendigkeit des Schrumpfens ist durchaus gültig: Reduzieren Sie die Größe einer Datenbank, die aus irgendeinem Grund gewachsen ist. Ob Sie die Größe nach einem massiven einmaligen Löschen von Daten reduzieren, den Effekt eines einmaligen Vorgangs umkehren, der ein unerwartetes Größenwachstum verursacht hat (z. B. einen schlechten Import), die Migration auf ein stark verbessertes (und viel kleineres) Datenmodell durchführen, bereinigen Aufgrund eines früheren schlechten DBA-Managements sind sie alle ein absolut gültiger Grund für das Verkleinern einer Datenbank. Die Kosten für das Schrumpfen (erhöhte Fragmentierung) müssen natürlich berücksichtigt werden. Stellen Sie sich jedoch einen Fall vor, in dem eine schlecht gestaltete Datenbank mit 200 GB auf nur 20 GB Daten reduziert wird. Es ist absolut sinnvoll, es auf eine Größe von 50 GB zu verkleinern und die Indizes neu zu erstellen. Mit anderen Worten, die Fähigkeit zum Verkleinern einer Datenbank wird benötigt .

Was verpönt ist, ist der Missbrauch von Schrumpfen:

• regelmäßig geplantes Schrumpfen
• Manuelles Verkleinern aus unbegründeten Gründen ('Ich muss etwas Speicherplatz freigeben für ...'), wenn die Datenbank häufig tatsächlich diese Größe benötigt und über Nacht nachwächst
• Schrumpfen für kleine Ausbeuten (z. B. 200 GB um 5 GB reduzieren)

Was das LOG-Schrumpfen betrifft, ist das Problem noch direkter: LOG kann sogar auf einem gut gewarteten System wachsen. Klare Beispiele: Transaktionsreplikations- oder DB-Spiegelungsbereitstellungen, bei denen Probleme mit der Verteilungs-DB oder dem Spiegelungspartner auftreten. Bis das Problem behoben ist, muss das Protokoll vom Herausgeber (für TX) oder vom primären (für DBM) aufbewahrt werden. Wenn das Problem endgültig behoben und das angeheftete Protokoll gelöscht ist, erhalten Sie ein unnötig großes Protokoll. Dies kann und sollte auf die Betriebsgröße reduziert werden. Shrinking wird das Protokoll irgendwie als VooDoo ( ‚ich es versuchte und nicht anythin tat!‘, ‚Hmm, ich versuchte es und es funktioniert jetzt‘) gesehen , aber ist einfach , wenn Sie verstehen , dass, um das Protokoll , das zu schrumpfen Schwanzes der Protokoll muss frei sein Dies bedeutet, dass entgegen der Intuition mehr Protokoll generiert (und freigegeben) werden muss, bevor die Datei verkleinert werden kann. Alles wird unter Verwenden der DBCC-Anweisung SHRINKFILE zum Verkleinern der Transaktionsprotokolldatei in SQL Server 2005 erläutert

Fast nie.

Gültige Anwendungsfälle? Einige Beispiele:

• So beheben Sie eine aufgeblähte Protokolldatei
  Geben Sie an, wo das Wiederherstellungsmodell VOLL war und keine Protokollsicherungen durchgeführt wurden.
• Entwicklungsmaschinen, um Platz zu sparen: Diese haben keine Produktionslasten
• Schreibgeschützte Datenbanken

Ihre Untersuchung ist jedoch richtig: Jede Art von Schrumpfung sollte keine routinemäßige, geplante Operation sein

Wenn Sie einen Schrumpf benötigen, verwenden Sie stattdessen SHRINKFILE, das gezielter ist