In SQL bin ich nicht gut, aber ich muss eine Datenbank warten.
Es ist so gut wie kein Platz mehr dafür übrig, also habe ich beschlossen, alle Daten für das Jahr 2008 zu löschen. Nach dem Ausführen der Löschabfrage (etwa 10 000 000 bereinigte Zeilen) und dem Bereinigen des Transaktionsprotokolls habe ich herausgefunden, dass meine Aktionen hatten keine Auswirkungen auf die Datenbankgröße. Muss ich sonst noch etwas tun?
Antworten:
Das Schrumpfen ist aus den hier genannten Gründen gefährlich. Es gibt ein glückliches Medium zwischen Jimbos Antwort und Johns Antwort ... Sie sollten sich immer ernsthaft überlegen, ob Sie Ihre Datenbank verkleinern möchten oder nicht.
In einer idealen Welt würden Sie Ihre Datenbank mit viel freiem Speicherplatz erstellen, in den Sie hineinwachsen können. Ich nenne das "Right Sizing" Ihre Datenbank. Sie würden zulassen, dass dieser freie Speicherplatz vorhanden ist, und nicht danach streben, ihn zurückzugeben, und Ihre Gesamtgröße auf der verwendeten Größe belassen. Warum? Weil Ihre Datenbank irgendwann wieder wachsen wird. Dann werden Sie wieder schrumpfen. Und Sie werden in diesem schrecklichen Muster nutzloser Schrumpfen gefangen sein, gefolgt von Wachstumsraten Erhöhen Sie Ihre Indexfragmentierung.
Ich habe darüber gebloggt, wo ich die Leute ermahnte: " Fass den Schrumpfknopf nicht an! ", Aber manchmal ... manchmal musst du. Wenn Sie über eine große Datenbank verfügen, nur erheblichen Speicherplatz freigegeben haben und nicht damit rechnen, jemals wieder in diese Datenbank hineinzuwachsen, ist es in Ordnung, das Verkleinern als einmalige Operation in Betracht zu ziehen, solange Sie sich anschließend durch Neuerstellung um Ihre Indexfragmentierung kümmern können Sie. Der Schrumpfvorgang kann zeitaufwendig sein, sodass Sie ihn für eine Zeit planen möchten, in der Sie den Preis für einen Schrumpfvorgang bezahlen können. Der Ansatz, eine leere Datenbank zu erstellen und Daten in diese zu kopieren, funktioniert - bei größeren Datenbanken und vielen Daten kann dies jedoch sehr schwierig werden.
Wenn Sie planen, diesen Speicherplatz durch normale Nutzung und Wachstumsmuster in der Zukunft wieder zur Datenbank hinzuzufügen, möchten Sie den Speicherplatz möglicherweise nur dort belassen.
Ebenfalls
Sie sagten, Sie hätten Ihr Transaktionsprotokoll "gelöscht". Ich bin gespannt, wie Sie das gemacht haben, aber wenn Sie den Beitrag lesen, den ich und die anderen in der Reihe geteilt habe, werden Sie einige Tipps zur Transaktionsprotokollverwaltung sehen. Kurz gesagt: Wenn Sie sich im vollständigen Wiederherstellungsmodus befinden, sollten Sie regelmäßige Protokollsicherungen durchführen, damit das Protokoll selbst wiederverwendet wird. Andernfalls - ohne Protokollsicherungen im vollständigen Modus - wächst die Protokolldatei ständig und wächst und wächst und speichert immer das, was Sie getan haben, weil Sie SQL mitgeteilt haben, dass Sie dieses Protokoll nicht nur für die Wiederherstellung nach einem Absturz verwalten, sondern auch beibehalten möchten Manuelle Sicherung, um Transaktionen abzuspielen / Transaktionen rückgängig zu machen, um sie zu einem bestimmten Zeitpunkt für Wiederherstellungszwecke wiederherzustellen.BEGIN TRAN ... do work.... COMMIT TRANoder ob Sie nur eine große DELETEAnweisung ausgegeben und eine ganze Datenmenge in einer impliziten Transaktion gelöscht haben.)
Ich gehe auch davon aus, dass Sie diesen freien Speicherplatz in Ihrem Dateisystem suchen. Wenn Sie es in SQL und in dieser großen Datei suchen, kann es sein, dass Sie auf die Bereinigung der Geister warten, wenn Sie sofort nach Ihrer Operation suchen. Paul Randal bloggt über Ghost Cleanup .
Durch das Löschen von Zeilen in einer Datenbank wird die tatsächliche Größe der Datenbankdatei nicht verringert.
Sie müssen die Datenbank nach dem Löschen der Zeilen komprimieren.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Nachdem Sie dies ausgeführt haben, möchten Sie Indizes neu erstellen. Das Verkleinern verursacht normalerweise eine Indexfragmentierung, was zu erheblichen Leistungskosten führen kann.
Ich würde auch empfehlen, dass Sie nach dem Verkleinern die Dateien neu vergrößern, damit Sie etwas freien Speicherplatz haben. Auf diese Weise lösen neue Zeilen kein automatisches Wachstum aus. Autogrowth ist mit Performance-Kosten verbunden und sollte nach Möglichkeit vermieden werden (durch geeignete Datenbankgrößen).
SCHRINKEN SIE NICHT IN IHRE DATENBANK!
Msgstr "" "Warum passiert das? Ein Datendateischrumpfvorgang kann jeweils für eine einzelne Datei ausgeführt werden und verwendet die GAM - Bitmaps (siehe Innerhalb der Speicher - Engine: GAM, SGAM, PFS und andere Zuordnungszuordnungen), um die höchste Seite zu finden, die in der zugeordnet ist Anschließend wird die Datei so weit wie möglich nach vorne verschoben usw. Im obigen Fall wurde die Reihenfolge des Clustered-Index vollständig umgekehrt und von perfekt defragmentiert in perfekt fragmentiert geändert. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Betrachten Sie die Ironie der verkleinernden Datenbank. Eine Person verkleinert die Datenbank, um Speicherplatz zu gewinnen (sie glaubt, dies würde die Leistung verbessern), wodurch die Fragmentierung zunimmt (die Leistung verringert) die Datenbank um ein vielfaches größer zu machen als die ursprüngliche Größe der Datenbank (vor dem Verkleinern). Nun, durch das Verkleinern hat man nicht das bekommen, wonach er normalerweise gesucht hat. "
Wenn Sie Daten löschen, reserviert SQL Server den Speicherplatz für die spätere Verwendung zum Einfügen neuer Daten. Sie müssen die Datenbank verkleinern. Weitere Informationen finden Sie hier .
Ich habe dies gefunden, weil ich gerade eine Reihe von Sicherungstabellen gelöscht habe, weil meine Datenbank "ausgelastet" war. Ich habe mir die "Size" -Eigenschaft immer wieder angesehen und überlegt, warum sie nicht kleiner wird. . Nachdem ich das gelesen habe, möchte ich die Datenbank nicht verkleinern. Ich möchte den Speicherplatz für den soeben gelöschten Müll "zurückfordern". Was ich mir ansehen musste, war "Space Available". Ich denke, vielleicht ist es das, was jemand anderes brauchen könnte, um sich das auch anzuschauen.
Beachten Sie auch, dass beim Löschen großer Datenmengen eine Fragmentierung auftreten kann, wenn die Tabelle Indizes enthält. Ich hatte heute einen Tisch mit ca. 70 Millionen Datensätzen und ca. 13 GB Speicherplatz. Ich habe es auf 1639 Datensätze gesäubert (der Rest wurde durch einen einzelnen Fehler generiert), aber die Tabelle nahm immer noch rund 4,5 GB ein. Nachdem ich alle Indizes für die Tabelle neu erstellt hatte, wurden nur 85 Seiten (680 KB) benötigt. Danach habe ich inkrementelle Shrinkfile verwendet, um den Speicherplatz zurückzugewinnen (und den Fehler im System behoben, um eine Wiederholung zu verhindern).