Empfohlenes Festplatten- / Partitions-Setup für einen SQL Server


14

Ich bin auf der Suche nach einem Rat, wie ich meine Festplatten / Partitionen am besten für SQL Server einrichten kann. Hier sind einige meiner Hauptanliegen:

Wie sollen die SQL-Dateien getrennt werden (Datendateien, Logs, Temp)?

Ist es besser, viele Festplatten zu RAIDen und den Speicherplatz zu partitionieren oder mehrere RAIDs mit weniger Festplatten für jedes RAID zu erstellen?

Sollten sich Daten- und Protokolldateien auf einem anderen RAID-Typ befinden?

Sollten sich die Standarddatenbanken (master, msdb, etc ...) auf dem C: befinden oder sollten sie sich an derselben Stelle befinden wie die anderen Daten- / Protokolldateien?

Antworten:


14

Hier ist ein netter Blog-Beitrag: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

Whitepaper zur Festplattenausrichtung: http://msdn.microsoft.com/en-us/library/dd758814.aspx

Kurz gesagt, Ihr Betriebssystem sollte sich auf RAID 1 befinden, Ihre Datendateien auf RAID 10 (vorzugsweise) und Protokolldateien auf RAID 1.

SQL Performance-Artikel: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx

PDF zu den 10 besten Leistungstipps: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Denken Sie auch daran, Ihre TEMPDB aus Leistungsgründen auf einer separaten Festplatte abzulegen. Ich bin mir sicher, Paul Randal wird hier reinkommen und Sie gleich verblüffen, warum.

MS sagt warum für Tempdb: http://msdn.microsoft.com/en-us/library/ms175527.aspx


@SQLChicken: Wenn es eine Vorliebe für den Laufwerkstyp gibt -> SATA vs SAS, gibt es eine Empfehlung? SAS über SATA? (unabhängig vom RAID-Typ usw.).
Pure.Krome

1
SAS-Laufwerke werden aufgrund der Geschwindigkeit und Zuverlässigkeit SATA vorgezogen, wenn Sie das Geld dafür haben.
SQLChicken

11

Dies ist eine große Frage, die davon abhängt.

Ich kann die Frage, wie die einzelnen RAID-Arrays erstellt werden, nicht beantworten, da ich kein Speicherexperte bin, aber ich kann Ihnen beim Rest helfen.

Das erste, was Sie berücksichtigen müssen, ist die Auslastung der verschiedenen Datenbanken - OLTP (Lesen / Schreiben) oder DSS / DW (Meistens Lesen). Für Lese- / Schreib-Workloads sollten Sie RAID 1 oder RAID 10 (RAID 1 + 0) in Betracht ziehen, da diese Redundanz und hervorragende Lese- / Schreibleistung bieten. Für Workloads mit Lesezugriff können Sie RAID 5 verwenden. Der Grund, warum RAID 5 nicht für Lese- / Schreib-Workloads verwendet werden sollte, besteht darin, dass Sie für Schreibvorgänge eine Leistungsstrafe zahlen.

Transaktionsprotokolle sind ihrem Wesen nach schreib- / lesbar (oder meist schreibgeschützt, je nachdem, ob Sie das Transaktionsprotokoll für irgendetwas verwenden - z. B. für Protokollsicherungen oder für die Replikation) und sollten daher niemals auf RAID 5 gestellt werden.

Dies bedeutet, dass Sie für einige Datenbanken und Workloads möglicherweise Datendateien auf RAID 5 und Protokolldateien auf RAID 1/10 haben und für andere Datenbanken möglicherweise alles auf RAID 1/10. Wenn Sie über eine partitionierte Datenbank verfügen, enthält diese möglicherweise einige Lese- und einige Lese- / Schreibdaten, möglicherweise sogar in derselben Tabelle. Dies könnte in separate Dateigruppen aufgeteilt werden und dann jeder Dateigruppe eine entsprechende RAID-Stufe zugewiesen werden.

Die Trennung der tatsächlichen Datenbanken hängt wiederum von der Arbeitslast und den Funktionen des zugrunde liegenden E / A-Subsystems ab. Möglicherweise ist ein höherer Grad an Trennung erforderlich, um Dinge auf einzelnen RAID-Arrays zu speichern als beispielsweise in einem SAN.

Tempdb ist ein Sonderfall für sich, da es sich in der Regel um eine stark ausgelastete Datenbank handelt, die getrennt von den anderen Datenbanken gespeichert werden sollte. Die Systemdatenbanken sollten nicht stark ausgelastet sein und können überall platziert werden, solange Redundanz besteht.

Hier ist ein Link zu einem Whitepaper, das ich geschrieben habe und das Ihnen helfen sollte: Physical Database Storage Design . Stellen Sie außerdem sicher, dass Ihr E / A- Subsystem die erwartete Arbeitslast bewältigt - siehe dieses Whitepaper: Best Practices für die E / A-Vorbereitung . Stellen Sie schließlich sicher, dass Sie die richtige RAID-Stripe-Größe (in der Regel 64 KB oder höher auf neueren Systemen) und die richtige NTFS-Zuweisungseinheit (in der Regel 64 KB) verwenden und dass Sie auf Systemen vor Windows Server 2008 den Festplattenpartitions-Offset korrekt festlegen . Informationen zu diesen und Verweise auf weitere Informationen und warum Sie sie auf diese Weise konfigurieren sollten, finden Sie in diesem Blogbeitrag: Sind die Versätze Ihrer Festplattenpartitionen, die RAID-Stripe-Größen und die NTFS-Zuordnungseinheiten richtig eingestellt? .

Bototm-Linie: Kennen Sie Ihre Arbeitslast und die Fähigkeiten Ihres E / A-Subsystems und implementieren Sie diese entsprechend.

Ich hoffe das ist hilfreich für dich.

PS Was tempdb betrifft, ist es eine große Menge an Würmern, wie Sie es konfigurieren sollten, und es gibt alle Arten von widersprüchlichen Informationen. Ich habe einen umfassenden Blog-Beitrag über die Konfiguration von Tempdb-Datendateien bei Misconceptions um TF 1118 geschrieben .


Großartiger Beitrag Paul :)
Pure.Krome

1

Die kurze Antwort für Server, die ich eingerichtet habe, war schon immer

Meldet sich auf separaten physischen Datenträgern an, RAID 1 oder 10 (Striping + Spiegelung)

Datenbank auf eigenen Festplatten, je nach Leistungsanforderungen in der Regel RAID5

Viel Cache auf den RAID-Controllern

Kleben Sie Ihr Betriebssystem und Ihre Windows-Auslagerungsdatei vorzugsweise erneut auf ein separates Array, normalerweise nur einen Spiegel (RAID 1). Dadurch bleiben alle Schreibvorgänge getrennt, sodass die hohe Leistung nicht alles nach unten zieht.

Was ich in der Vergangenheit erlebt habe, ist, dass Datenbankschreibvorgänge + Protokollschreibvorgänge + Seitendateischreibvorgänge ein Raid5-Array zum Stillstand bringen und die Leistung in einem Handkorb zum Teufel wird. Das Problem ist, dass Ihre Leistung beim Testen, Entwickeln usw. in Ordnung ist. Wenn Sie jedoch in die Produktion und den Betrieb einsteigen, steigt das Problem "aus heiterem Himmel" und die Beschwerden der Benutzer steigen in die Höhe.


1

Es gibt hier weitaus bessere MSSQL-Leute als ich, aber im Allgemeinen würde ich Folgendes vorschlagen;

Betriebssystem und Code auf C: - Dies sollten die lokalen Festplatten sein, sollte ein RAID1-Array-Paar sein. - Wir verwenden 2 x 2,5-Zoll-SAS-Festplatten mit 146 GB und 10 U / min. Sie können jedoch auch 2 x SATA 7.2-Festplatten verwenden. Die Daten sollten sich auf einem recht schnellen (10krpm oder besser) RAID 1/10, 5/50/6/60-Array mit beliebiger Größe befinden - wir halten uns an FC SAN-LUNs, in der Regel auf einer "Tier 2" / 10krpm-Datenträgergruppe . Protokolle sollten auf einem separaten, SEHR SCHNELLEN (15 KRPM) kleinen (10 GB oder weniger?) RAID 1-Array-Paar abgelegt sein - wir führen unsere Protokolle auf FC SAN-LUNs, normalerweise auf einer sehr kleinen 'Tier1'- / 15 KRPM-Datenträgergruppe oder auf einer' Tier0'- / SSD-Gruppe.

Wie auch immer, Sie möchten, dass jeder Teil davon für die Leistung auf separaten Spindeln / Arrays gespeichert wird - natürlich funktioniert alles auf einer einzelnen Festplatte, aber ich vermute, Sie suchen nach einem Gleichgewicht zwischen Leistung und Kosten.

Wir speichern unsere master / tempdb mit unseren regulären Datenbanken, aber Sie können sie in eine separate Datenarray-LUN aufteilen.

Hoffe das hilft.


Interessanter Punkt, dass die Protokolllaufwerke klein sind. Hilft dies bei der Schreibgeschwindigkeit? Ist es eine gute Idee, Ihre Protokolldateilaufwerke so klein zu machen, wie Ihre Daten verarbeiten können?
Sean Howat

Ich bin weit davon entfernt, ein Experte zu sein, aber wir scheinen festzustellen, dass sie klein bleiben - Ihre Laufleistung kann variieren :)
Chopper3
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.