SQL Server: Dateigruppe nur für Systemtabellen?

11

Einer unserer Unternehmensstandards besteht darin, eine separate Dateigruppe / Datei für Benutzertabellen / -indizes zu haben. Dies ist als Standard festgelegt, sodass keine CREATE TABLE-Anweisungen qualifiziert werden müssen.

So sieht es also aus

Datei-ID 1 = Systemtabellen, MDF
Datei-ID 2 = t-log = LDF
fileid 3 = user stuff = NDF

Kann mir hier jemand helfen, die ursprüngliche Rechtfertigung zu verstehen, warum dies vorgeschrieben wurde?

Ich werde sauber kommen und sagen, ich denke, es ist Voodoo. Bin ich falsch ...?

Bearbeiten: Ich weiß, wie man Dateigruppen zum Trennen von Indizes / Partitionen / Archiven verwendet und wie man Stück für Stück wiederherstellt. Diese Frage bezieht sich auf die Verwendung einer separaten Dateigruppe auf demselben Volume nur für Systemtabellen.

sql-server filegroups disk-structures

— gbn
quelle

9

Im Microsoft 70-432-Schulungsbuch heißt es: "Der Hauptgrund, keines Ihrer Objekte in der primären Dateigruppe zu platzieren, besteht darin, die E / A so weit wie möglich zu isolieren. Die Daten in den Systemobjekten ändern sich nicht so häufig wie die Daten." Durch Minimieren der Schreibaktivität in die primäre Datendatei verringern Sie die Möglichkeit der Beschädigung aufgrund von Hardwarefehlern. Da der Status der primären Dateigruppe auch den Status der Datenbank bestimmt, können Sie die Verfügbarkeit erhöhen der Datenbank minimiert die Änderungen, die an der primären Dateigruppe vorgenommen wurden. "

Also nimm das so wie du willst. Andere sagen, dass dies unter bestimmten Umständen nicht notwendig ist und natürlich mehr zu pflegen ist. Ich dachte nur, ich würde die Argumentation von Microsoft liefern.

— Jared
quelle

Vernünftig, einige schriftliche Begründung dafür. Ich werde das akzeptieren

— gbn

1

Ein weiterer Grund ist, dass eine PARTIAL-Datenbankwiederherstellung die Wiederherstellung der PRIMARY-Dateigruppe sowie ausgewählter anderer Dateigruppen ermöglicht, wodurch eine korrekt gestaltete VLDB schneller wiederhergestellt werden kann. Ermöglichen, dass die archivierten / sekundären Dateigruppen später wiederhergestellt werden.

— MartinC

@MartinC: Ich kenne mich mit Teilwiederherstellungen usw. aus, aber ich habe die Logik der expliziten Trennung der Systemtabellen nie verstanden. Dateigruppen für Leistung, Archivierung, Wartung, Partitionierung usw. Aber Systemtabellen? Jared bot die beste Erklärung bisher ..

— gbn

Wenn die Datenbank insgesamt sehr groß ist, kann die primäre Dateigruppe eine regelmäßigere Sicherung als die Hauptdaten haben. Die Wiederherstellung würde nur eine Sicherung des Endprotokolls und eine Wiederherstellung der primären Dateigruppe und der Transaktionsprotokolle seit der Sicherung der Dateigruppe plus dem Endpunkt erfordern. Da die Systemtabellen klein sind, ist dies ein schnellerer Wiederherstellungsprozess als dies für die gesamte Datenbank der Fall ist, sodass Ausfallzeiten im Falle eines Problems reduziert werden können.

— MartinC

12

Dies ist kein Leistungsgewinn, es ist ein Wiederherstellungsgewinn zu erzielen. Wenn in den Systemtabellen eine Dateibeschädigung auftritt, geht die Datenbank verloren. Wenn Sie die Benutzerdaten in einer separaten Dateigruppe (oder in separaten Gruppen) aufbewahren, können Sie nur diese Dateien wiederherstellen, wobei der Rest der Datenbank während der Wiederherstellung online bleibt (hier unter der Annahme von Enterprise Edition).

Wenn dies der Grund ist, warum sie dies angeben, kann ich nicht sagen, aber dies wäre ein Vorteil, wenn mehrere Dateigruppen nur mit den Systemobjekten in der PRIMARY-Dateigruppe vorhanden wären.

Sie sollten dann jedoch in den Müll treten, um zu sagen, dass AutoShrink aktiviert sein sollte.

— mrdenny
quelle

Um mehr darüber zu erfahren, können Sie in Books Online nach Online Piecemeal Restore suchen.

— Brent Ozar

1

Ich habe immer gedacht, dass dies auch Voodoo ist, da sich die beiden Dateigruppen auf demselben Volume befinden (in einem SAN). Ist das Korruptionsrisiko so hoch? (Die tatsächlich betriebsbereiten DBAs setzen AutoShrink auf false)

— gbn

Wenn es eine Beschädigung gibt, handelt es sich wahrscheinlich um eine einzelne Seite innerhalb einer einzelnen Datei, da sich der Speicher beim Schreiben der Seite auf die Festplatte erhöht. Etwa 99,9999% der Datenbankbeschädigung ist ein Speicherproblem. Die Hälfte der restlichen Probleme sind fehlerhafter Speicher, der Rest sind SQL-Fehler. Wenn die Datenbanken größer werden (Multi-TB), wird dies wichtiger, da das Wiederherstellen einer Multi-TB-Datenbank mehrere Tage dauern wird.

— Mrdenny

Wäre es nicht richtig zu denken, dass Sie Folgendes tun können, wenn sich die Systemobjekte nur in der primären Dateigruppe befinden, falls Sie dies in Zukunft benötigen sollten? Erstellen Sie x zusätzliche Dateien in einer anderen Dateigruppe. Füllen Sie diese Dateien proportional, indem Sie Ihre Daten aus Ihrer vorhandenen Datendatei migrieren?

— Ally Reilly

4

Sie sind sich nicht sicher, ob Sie jemanden verstehen, der Ihren Unternehmensstandard rechtfertigt? Ich würde denken, dass jeder, der dieses Standarddokument für Ihr Unternehmen geschrieben hat, etwas Licht ins Dunkel bringen kann, warum dies getan wird.

Abgesehen davon ist es nicht ungewöhnlich, dass einige Geschäfte Systemdaten aus Benutzerdaten auflösen möchten. In Verbindung mit dedizierten Festplattensätzen können Sie einige Leistungssteigerungen erzielen.

— SQLRockstar
quelle

Vielen Dank. Nicht rechtfertigen, sondern erklären. Dies ist das gleiche DB Engineering-Team, das AutoShrink aktiviert. Glauben Sie an einen Leistungsgewinn, wenn gegebene Systemtabellen einige MB belegen und sich trotzdem im Speicher befinden?

— Gbn