Beste Möglichkeit, eine Datenbank für Archivierungszwecke zu defragmentieren / zu komprimieren

Wir haben eine SQL Server-Instanz, die für die E-Mail-Archivierung verwendet wird (mit freundlicher Genehmigung eines Archivierungspakets eines Drittanbieters). Von Zeit zu Zeit wird die Software auf eine neue leere Datenbank übertragen. Wir haben dies in der Vergangenheit vierteljährlich gemacht, aber wir versuchen es jetzt monatlich. Die zu archivierende Datenmenge beträgt etwa 15 bis 20 GB pro Monat, und der Großteil der Daten befindet sich nur in einer Handvoll Tabellen (normalerweise 2 bis 4).

Sobald wir zu einer neuen Datenbank wechseln, wird die alte Datenbank nur noch schreibgeschützt verwendet. Was ich tun möchte, ist, es in eine schöne, enge Datendatei zu optimieren, wobei alle Tabellen / Indizes zusammenhängend sind und einen sehr hohen Füllfaktor haben und am Ende der Datendatei nicht viel Leerraum vorhanden ist. Außerdem verwenden wir auf diesem Server die Standard Edition mit allen damit verbundenen Einschränkungen (andernfalls würde ich bereits die Datenkomprimierung verwenden).

Einige Möglichkeiten, die mir einfallen:

REBUILD / REORGANIZE-Indizes, DBCC SHRINKFILE (Okay, dies ist keine sinnvolle Option, da DBCC SHRINKFILE die Pisse aus allem herausfragmentiert, was sie berührt, aber ich füge sie der Vollständigkeit halber hinzu.)
Erstellen Sie eine neue Datenbank mit deaktivierten automatischen Statistiken. Schreiben Sie alle Tabellen aus der Quellendatenbank und erstellen Sie sie neu. Verwenden Sie bcp, um die Daten in der Reihenfolge der Clusterschlüssel in die neue Datenbank zu exportieren / importieren. Skript und erstellen Sie alle Indizes neu. Berechnen Sie alle Statistiken mit vollständigem Scan neu.
Erstellen Sie eine neue Datenbank mit deaktivierten automatischen Statistiken. Schreiben Sie alle Tabellen aus der Quellendatenbank und erstellen Sie sie neu. Verwenden Sie SSIS oder T-SQL, um Daten in die neue Datenbank zu übertragen. Skript und erstellen Sie alle Indizes neu. Berechnen Sie alle Statistiken mit vollständigem Scan neu.

Der letzte Schritt wäre in jedem Fall, die Datenbank in den schreibgeschützten Modus zu versetzen.

Welche anderen guten / besseren Möglichkeiten gibt es dafür? Mein Anliegen ist es, die Daten so zu verschieben, dass ein hoher Füllfaktor erhalten bleibt und logisch zusammenhängend ist.

Bearbeiten:

Ich sollte erwähnen, dass ungefähr 75% der Daten in Bildspalten (LOB) gespeichert zu sein scheinen.

sql-server sql-server-2012

— db2
quelle

Interessiert es Sie (oder die Anwendung), wenn die Tabellen physisch in einer anderen Dateigruppe als enden PRIMARY?

— Jon Seigel

@ JonSeigel Ich nehme nicht an, und das ist eigentlich eine ziemlich gute Idee, da es mir die Mühe ersparen würde, eine Vorlagendatenbank zu erstellen und alle Daten zu verschieben.

— DB2

Ziehen Sie nur Lösungen in Betracht, die Sie selbst codieren, oder können Sie auch eine Anwendung überprüfen, um Ihnen dabei zu helfen? Sie können die SQL Storage Compress von RedGate verwenden , um Live-Daten zu komprimieren. Oder Sie können Virtual Restore ausprobieren , um komprimierte Backups als Online-Datenbank verfügbar zu machen (ohne tatsächlich den gesamten benötigten Speicherplatz zu haben). Sie basieren alle auf dem älteren Hyperbac Windows-Dateitreiber, der sich sehr gut für die Komprimierung von Live-Daten und Backups eignet.

— Marian

@Marian Klingt interessant, aber ich möchte mich vorerst an die nativen SQL Server-Funktionen halten. Ich muss nur die Datenbanken sehr effektiv defragmentieren, ohne dass viel ungenutzter Speicherplatz in den Dateien übrig bleibt. Wenn es sich um ein Drittanbieter-Tool handelt, das die Arbeit ausführt, anstatt manuell Skripte zu erstellen, ist das in Ordnung.

— DB2

Es ist nur ein Gedanke, aber warum nicht eine neue Dateigruppe erstellen, eine Datei hinzufügen, ein angemessenes Wachstum festlegen (z. B. 500 MB) und dann Ihre Tabellen auf dieser neuen Dateigruppe neu erstellen. Dann verkleinern Sie die Primärdatei auf fast nichts. Die Fragmentierung der Systemtabellen ist Ihnen egal.

— Nic

Antworten:

Um die physische Fragmentierung in den Dateien zu beseitigen, können Sie den Clustered-Index mit dem vorhandenen Drop in eine neue Dateigruppe verschieben. Da es sich um RO handelt, müssen sie alle zu 100% gefüllt sein, da kein Platz für Einfügungen benötigt wird. Seitensplits werden durch Aktualisierungen verursacht.

Auf diese Weise können Sie auch eine stückweise Wiederherstellung durchführen und die Datenbank sehr schnell online stellen, wenn Sie sich jemals für Enterprise entschieden haben. Enterprise erlaubt auch Columnstore-Indizes und reduziert die Abfragezeit für diese schreibgeschützten Daten massiv.

Sie können die Option "Shrinkfile" einmal verwenden, bevor Sie ohne ernsthafte Probleme mit der Fragmentierung auf "Nur Lesen" umschalten, um den gewünschten Speicherplatz am Ende der Datei zu entfernen.

Nebenbei bemerkt, überprüfen Sie einfach, ob Sie die neuesten Datentypen für Ihre LOBS verwenden. dh nvarchar (max) oder varchar (max) anstelle von ntext oder text, varbinary (max) anstelle von image?

— Beschädigte Ware
quelle

Leider werden meistens Text und Bilder verwendet. Es ist eine Anwendung von Drittanbietern, daher kann ich das nicht ändern.

— DB2

@ist wirklich transparent für die Anwendung, wobei SQL Server die Informationen in einer Zeile speichert, wenn <8k. Wenn der Anbieter angibt, dass dies nicht unterstützt wird, würde ich ihn fragen, warum er immer noch Datentypen verwendet, die ursprünglich in SQL Server 2005 veraltet waren!

— DamagedGoods

Ich kann nicht ganz sicher sein, dass die Anwendung keine text- / bildspezifischen Dinge wie WRITETEXT ausführt, die nach dem Ändern des Datentyps fehlschlagen würden. Zurück zum Hauptpunkt: Es sieht so aus, als würde die Neuerstellung des Clustered-Index die LOB-Daten nicht tatsächlich damit verschieben.

— db2

Sie können dies tun, aber Sie müssen in der GUI in Designer gehen, dann die Eigenschaften erweitern, dann haben Sie einen 'regulären Datenraum', aber auch eine TEXTIMAGE-Dateigruppe, die diesen Willen ändert, aber seien Sie vorsichtig, dies wird die Tabelle neu erstellen! Sie können dies natürlich

— skripten

Verstanden, das könnte zumindest eine nützliche Möglichkeit sein, die entsprechenden Wiederherstellungsskripte zu generieren.

— db2

Ich hatte ein ähnliches Problem mit einem Drittanbieter-Tool, das ebenfalls einen Bilddatentyp zum Speichern unstrukturierter Daten verwendete, und ich löste es, indem ich die Spalte für die Verwendung von Dateistream konvertierte . Sie müssen einige Tests durchführen, um sicherzustellen, dass die App weiterhin wie erwartet funktioniert. Auf diese Weise können Sie jedoch Ihren eigenen Archivierungsprozess schreiben, der Ihre Daten auf effiziente Weise in eine Archivdatenbank verschiebt.

— Liam Confrey
quelle

Ich vermute, dass Filestream in diesem Fall nicht gut skaliert werden kann. Wir haben über 14 Millionen Zeilen in 17 Datenbanken und erhalten Nachrichten mit rund 15.000 pro Tag. Ein wesentlicher Teil der Nachrichtentexte liegt unter 4 KB, sodass die Verschwendung von NTFS-Clustern wahrscheinlich brutal wäre (und das auch dann, wenn wir ein neues Festplattenvolumen mit einer Blockgröße von weniger als 64 KB hinzufügen).

— DB2

Können Sie in diesem Fall den Datentyp in etwas wie nvarchar (max) konvertieren und die TEXTIMAGE_ON-Klausel verwenden, um eine andere Dateigruppe für diese großen Objekte anzugeben? Auf diese Weise können Sie die Daten außerhalb der Zeile speichern und einen eigenen Prozess zur Verwaltung der Archivierung erstellen.

— Liam Confrey

Die Verwendung von Filestream hängt wirklich davon ab, wie groß die einzelnen LOBS sind. Ich denke,> 1 MB pro Datensatz zu berücksichtigen. Also würde ich in diesem Fall zustimmen, dass es keine Option ist

— DamagedGoods