SQL Server 2005/2008 - mehrere Dateien / Dateigruppen - wie viele? Warum?

Ich bin im Herzen ein Entwickler - aber hin und wieder hat ein Kunde keinen anständigen DBA, um diese Probleme zu lösen, also werde ich gerufen, um zu entscheiden ...

Was sind Ihre Strategien / Best Practices für den Umgang mit einer SQL Server-Datenbank von angemessener Größe (alles, was größer als Northwind oder AdventureWorks ist; ungefähr 2-4 GB Daten plus Indizes usw.) - verwenden Sie mehrere Dateien / Dateigruppen?

Wenn ja: wie viele? Und warum?

Was sind Ihre Kriterien, um zu entscheiden, wann Sie sich vom Ansatz "Eine Dateigruppe für alles" entfernen möchten:

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Wenn Sie mehrere Dateigruppen verwenden, wie viele verwenden Sie? Eine für Daten, eine für Index, eine für Protokoll? Mehrere (wie viele) für Daten? Was sind Ihre Gründe für Ihre Wahl - warum verwenden Sie genau diese Anzahl von Dateigruppen :-)

Vielen Dank für Hinweise, Hinweise, Gedanken!

Prost, Marc

Als Faustregel gilt, dass Dateien auf verschiedenen Volumes getrennt werden müssen, um Konflikte zu vermeiden. Die Höhe des Leistungsgewinns hängt jedoch stark vom E / A-Subsystem und der Arbeitslast ab. Zum Beispiel werden mehrere Dateien auf einer einzelnen physischen Spindel in Bezug auf die Leistung schlecht funktionieren, aber die gleiche Anordnung, bei der sich das Volume auf einer SAN-LUN mit mehreren hundert Laufwerken von RAID 10-Arrays befindet, ist möglicherweise in Ordnung. Zähler für die Länge der Festplattenwarteschlange sind Ihr Freund, um am einfachsten festzustellen, ob Sie einen E / A-Engpass haben.

Sie betrachten die E / A-Muster in den Datenbanken - schreibgeschützt, schreibgeschützt, schreibgeschützt, schreibgeschützt, schreibgeschützt - und stützen sich darauf. Sie müssen auch den richtigen RAID-Level auswählen und sicherstellen, dass Ihre Offsets der Festplattenpartition, die Größe der RAID-Stripe und die Größe der NTFS-Zuordnungseinheit korrekt eingestellt sind. Einige Leute mögen es, nicht gruppierte Indizes in eine separate Dateigruppe zu trennen, aber die Leistungssteigerungen variieren hier genau wie oben erläutert.

Neben der Leistung sollten Sie auch die Verwaltbarkeit und Wiederherstellbarkeit berücksichtigen. Wenn Sie eine einzige monolithische Datendatei für eine 100-GB-Datenbank haben, bedeutet dies, dass Ihre Wiederherstellungseinheit diese Datei ist. Wenn Sie es in 4 25-GB-Dateigruppen aufteilen, können Sie die teilweise Datenbankverfügbarkeit und die schrittweise Wiederherstellung verwenden, um nur eine einzelne Dateigruppe wiederherstellen zu müssen, falls diese beschädigt wird. Durch Partitionieren von Tabellen und Indizes in mehrere Dateigruppen können Sie auch einschränken, welche Teile der Datenbank von Wartungsvorgängen betroffen sind (z. B. Entfernen der Indexfragmentierung).

Tempdb ist ein ganz besonderer Fall, und ich werde Sie auf einen Blog-Beitrag von mir verweisen, in dem erklärt wird, warum und wie Tempdb aufgeteilt wird - es gibt viele Missverständnisse.

Ohne Ihnen hier eine umfassende Empfehlung zur Verallgemeinerung zu geben, verweise ich Sie auf eine Reihe von Whitepapers und Blog-Posts, die Sie lesen können:

• Whitepaper: Design des physischen Datenbankspeichers
• Whitepaper: Best Practices für E / A vor der Bereitstellung
• Whitepaper: Partitionierte Tabellen und Indizes in SQL Server 2005

• Whitepaper: Teilweise Datenbankverfügbarkeit

• Blogbeitrag: Missverständnisse um TF 1118 (Tempdb-Layout)

• Blogpost: Sind Ihre Offsets für Festplattenpartitionen, RAID-Stripe-Größen und NTFS-Zuordnungseinheiten richtig eingestellt? (mit Link zum Whitepaper zur Festplattenpartition)

Hoffe das hilft dir!

Die Entscheidung, eine Datenbank in verschiedene Dateigruppen aufzuteilen, sollte getroffen werden, nachdem die aktuelle Größe und das zukünftige Wachstum Ihrer Tabellen analysiert wurden. Meiner Meinung nach sollten Sie die Vor- und Nachteile sorgfältig abwägen, es sei denn, Sie haben eine große Datenbank oder Tabellen mit Millionen von Zeilen, da Sie möglicherweise mehr Leistungsprobleme verursachen, als Sie beheben.

Es gibt einige Szenarien, die unter bestimmten Voraussetzungen interessant sein könnten:

• 2 Dateigruppen: Daten und Index
• 3 Dateigruppen: Nur-Lese-Tabellen, Lese- / Schreibtabellen, Index
• mehrere Dateigruppen: schreibgeschützt, schreibgeschützt, Index, Schlüsseltabelle 1, Schlüsseltabelle 2, ...

Sie müssen Ihre Umgebung analysieren, um zu entscheiden, ob Dateigruppen bei Ihren Anforderungen an Wachstum, Nutzung und Leistung von SQL Server hilfreich sind.

Einige Schlüsselindikatoren für den Wechsel zu mehreren Dateigruppen (aus diesem Artikel ):

• Wenn die Festplattenwarteschlange Probleme mit der Anwendung und der Benutzererfahrung verursacht
  • In diesem Fall sollten Sie zusätzliche Festplattenlaufwerke mit neuen Dateigruppen nutzen, in denen sich E / A-intensive Tabellen befinden
• Wenn bestimmte Tabellen 10% oder mehr der Datenbank ausmachen
  • Wenn dies der Fall ist, sollten Sie diese besonders großen Tabellen in separate Dateigruppen auf separaten zugrunde liegenden Festplatten verschieben
  • Abhängig von der Tabellengröße im Verhältnis zum Rest der Tabellen sollten Sie eine Dateigruppe für einzelne Tabellen erstellen.
• Wenn nicht gruppierter Index und Datenbereich in großen Tabellen gleich sind
  • Wenn dies der Fall ist, sollten Sie die Daten und den Clustered-Index von den Nicht-Clustered-Indizes trennen
• Wenn ein fast gleicher Prozentsatz der schreibgeschützten und schreibgeschützten Daten in der Datenbank vorhanden ist
  • Wenn dies der Fall ist, sollten Sie die schreibgeschützten Daten in eine separate Dateigruppe als schreibgeschützte Daten aufteilen
• Wenn nicht genügend Zeit für die Datenbankwartung zur Verfügung steht
  • Wenn dies der Fall ist, sollten Sie die großen Tabellen in separate Dateigruppen auf verschiedenen zugrunde liegenden Festplatten aufteilen und die Wartung parallel durchführen
• Wenn sich das Geschäft oder die Anwendung erheblich ändern wird und die Daten viel schneller wachsen werden
  • Wenn dies der Fall ist, sollten Sie mit den Benutzern zusammenarbeiten, um das potenzielle Wachstum zu verstehen
• Wenn sich archivierte Daten in derselben Datenbank befinden wie die Produktionsdaten
  • Wenn dies der Fall ist, ziehen Sie separate Dateigruppen oder eine oder mehrere der in diesem Tipp beschriebenen Techniken in Betracht - Archivieren von Daten in SQL Server

Wenn Sie feststellen, dass Dateigruppen die Leistung Ihrer Datenbank verbessern können, schreiben Sie den Code und testen Sie den Prozess in einer Staging-Umgebung, bevor Sie die Änderungen auf Ihren Produktionsservern implementieren. Bereiten Sie einige Messungen vor, bevor Sie die Änderungen implementieren, und vergleichen Sie sie vorher / nachher. Da diese Prozesse sehr ressourcenintensiv und zeitaufwändig sein können, führen Sie diese Verfahren während eines Wartungszeitraums durch.

Vergessen Sie nicht, beim Erstellen neuer Objekte (Tabellen und Indizes) sicherzustellen, dass die Objekte in der richtigen Dateigruppe erstellt werden, um die erwartete Leistung sicherzustellen, und überprüfen Sie regelmäßig, ob sich die Datenbankobjekte in den richtigen Dateigruppen befinden und bei Bedarf korrekt sind.