Unsere Datenbank verfügt derzeit nur über eine Dateigruppe, PRIMARY, die ungefähr 8 GB Daten enthält (Tabellenzeilen, Indizes, Volltextkatalog).
Wann ist ein guter Zeitpunkt, um dies in sekundäre Datendateien aufzuteilen? Welche Kriterien sollte ich beachten?
Antworten:
Diese Frage besteht aus zwei Teilen: Wann muss eine neue FILEGROUP hinzugefügt werden und wann muss eine neue DATEI zu einer Dateigruppe hinzugefügt werden? Sprechen wir zuerst über die Theorie:
Mark hat Recht, was den Hauptgrund für die Leistung betrifft.
Der sekundäre Grund ist die Notfallwiederherstellung. Mit SQL Server 2005 und neuer können Sie Dateigruppenwiederherstellungen durchführen. Wenn eine Katastrophe eintritt, können Sie zuerst nur Ihre primäre Dateigruppe wiederherstellen und die Datenbank für Abfragen teilweise online schalten. Benutzer können Abfragen ausführen, während Sie andere Dateigruppen wiederherstellen. Dies ist nützlich für Datenbanken mit einer großen Menge historischer Daten, die möglicherweise nicht sofort benötigt werden, oder für Data Warehouses, die Daten in aktuelle Tabellen laden müssen, ohne historische Daten für den Zugriff zu benötigen.
Ein weiterer Grund ist das Lese- / Schreibprofil von Datengruppen. Wenn Sie über Daten verfügen, in die ständig geschrieben wird, und über andere Daten, die stark gelesen werden, können Sie verschiedene Speichertypen erstellen, um diesen Anforderungen gerecht zu werden. Sie könnten das Heavy-Write-Zeug auf Raid 10 setzen und das Read-Bias-Zeug auf billigerem Raid 5 belassen.
Lassen Sie uns nun Dateien gegen Dateigruppen sprechen. Wenn Sie Objekte in SQL Server platzieren, müssen Sie sie auf Dateigruppenebene platzieren. Sie können eine Tabelle oder einen Index in einer Dateigruppe landen, aber keine bestimmte Datei auswählen. Bei allem, was wir bisher besprochen haben, ging es darum, wann eine Dateigruppe hinzugefügt werden soll - aber wann fügen Sie eine Datei hinzu?
Wenn Sie Speicher entwerfen und über 80 Festplatten verfügen, können Sie ihn auf verschiedene Arten aufteilen:
Unterschiedliche Speichersubsysteme haben unterschiedliche Leistungsprofile. Ich habe mit einigen SANs gearbeitet, die mit 12-16-Laufwerk-Arrays am besten abschnitten, und alles, was größer war, hatte keine Leistungsverbesserung. Ein weiteres Beispiel sind SANs mit Multipathing: Wenn Ihr Server von mehreren HBAs mit Ihrem Speicher verbunden ist und Ihre Multipathing-Software nicht wirklich aktiv / aktiv ist, benötigen Sie möglicherweise ein Array pro Pfad, um die Last zu verteilen. Vier Pfade, vier Pools von Laufwerken erzielen auf diesen Laufwerkstypen eine bessere Leistung.
In diesen Fällen stehen Ihnen unter Windows vier verschiedene Arrays und vier verschiedene Laufwerke zur Verfügung (es sei denn, Sie verwenden Mount-Punkte und selbst dann sind es verschiedene Ordner), und Sie benötigen vier separate Dateien in SQL Server. Diese separaten Dateien können sich in derselben Dateigruppe befinden.
Der Hauptgrund ist die Leistung. Wenn Ihnen die IOPS-Kapazität auf Ihrem primären Dateigruppenlaufwerk ausgeht, müssen Sie auf eine zweite Dateigruppe erweitern, um IOPS je nach Speicherkonfiguration auf mehrere Festplatten / LUNs aufzuteilen.
EDIT: Brad Wilson machte einen guten Kommentar zu SSDs. Wenn Sie ein zusammengesetztes SSD / SATA / FC-Speichersystem verwenden, möchten Sie möglicherweise unterschiedliche Dateigruppen für unterschiedliche Speichertypen. Sie können dann Ihre extremen IOPS-Anforderungstabellen auf SSD-Filegropus ablegen, während Verlaufs- / Statistik-Tabellen in billigen SATA-Dateigruppen gespeichert werden können.
Ich möchte auch darauf hinweisen, dass diese Frage auch einen Aspekt der Wiederherstellbarkeit / Datenverfügbarkeit aufweist. Indem Sie mehrere Dateigruppen verwenden und keine benutzerdefinierten Objekte in der primären Dateigruppe platzieren, können Sie Online-Wiederherstellungen flexibler aktivieren. Dies ermöglicht eine stückweise Wiederherstellung auf Dateigruppenebene.
Online-Wiederherstellungen sind in Enterprise- und Developer-Editionen von SQL Server nach 2005 verfügbar
Ein weiterer Gedanke, der in den Sinn kommt, besteht darin, schreibgeschützte statische Referenzdaten von Transaktionsdaten zu trennen. Bei größeren Datenbanken kann dies den Zeit- und / oder Speicherplatz für die Durchführung einer Sicherung verringern.