Empfohlene Datenträger-/Partitionskonfiguration für einen SQL Server

Empfohlene Datenträger-/Partitionskonfiguration für einen SQL Server

Ich suche nach Ratschlägen, wie ich meine Festplatten/Partitionen am besten für SQL Server einrichte. Hier sind einige meiner Hauptanliegen:

Wie sollen die SQL-Dateien getrennt werden (Datendateien, Protokolle, temporäre Dateien)?

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

Sollten Daten- und Protokolldateien auf einem anderen RAID-Typ liegen?

Sollten sich die Standarddatenbanken (Master, MSDB usw.) auf C: befinden oder am selben Ort wie die anderen Daten-/Protokolldateien?

Antwort1

Hier ist ein schöner Blogbeitrag: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 auf RAID 1, Ihre Datendateien (vorzugsweise) auf RAID 10 und die Protokolldateien auf RAID 1 liegen.

Artikel zur SQL-Leistung: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 sicher, Paul Randal wird gleich vorbeikommen und Ihnen erklären, warum.

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

Antwort2

Dies ist eine große „es kommt darauf an“-Frage.

Die Frage zum Erstellen der einzelnen RAID-Arrays kann ich Ihnen nicht beantworten, da ich kein Speicherexperte bin, beim Rest kann ich Ihnen aber weiterhelfen.

Als Erstes müssen Sie die Arbeitslast der verschiedenen Datenbanken berücksichtigen – OLTP (Lesen/Schreiben) oder DSS/DW (meist Lesen). Für Lese-/Schreib-Arbeitslasten sollten Sie RAID 1 oder RAID 10 (RAID 1+0) in Betracht ziehen, da diese Redundanz und eine hervorragende Lese-/Schreibleistung bieten. Für hauptsächlich Lese-Arbeitslasten können Sie RAID 5 verwenden. Der Grund, warum RAID 5 nicht für Lese-/Schreib-Arbeitslasten verwendet werden sollte, besteht darin, dass Sie beim Schreiben Leistungseinbußen hinnehmen müssen.

Transaktionsprotokolle sind naturgemäß Lese-/Schreibprotokolle (oder hauptsächlich Schreibprotokolle, je nachdem, ob Sie das Transaktionsprotokoll für etwas anderes verwenden, z. B. Protokollsicherungen oder Replikation) und sollten daher nie auf RAID 5 gelegt werden.

Das bedeutet, dass Sie für einige Datenbanken und Workloads Datendateien auf RAID 5 und Protokolldateien auf RAID 1/10 haben können, und für andere Datenbanken können Sie alles auf RAID 1/10 haben. Wenn Sie eine partitionierte Datenbank haben, kann diese außerdem einige Daten enthalten, die hauptsächlich gelesen werden, und einige, die gelesen/geschrieben werden, möglicherweise sogar innerhalb derselben Tabelle. Dies könnte in separate Dateigruppen aufgeteilt werden und dann könnte jede Dateigruppe auf eine geeignete RAID-Ebene gesetzt werden.

Die Trennung der eigentlichen Datenbanken hängt wiederum von der Arbeitslast und den Fähigkeiten des zugrunde liegenden IO-Subsystems ab. So kann beispielsweise für die Speicherung von Dingen auf einzelnen RAID-Arrays ein höherer Trennungsgrad erforderlich sein als auf einem SAN.

Tempdb ist ein Sonderfall für sich, da es sich dabei normalerweise um eine stark ausgelastete Datenbank handelt und diese getrennt von den anderen Datenbanken gespeichert werden sollte. Die Systemdatenbanken sollten nicht stark beansprucht werden und können überall platziert werden, solange Redundanz vorhanden ist.

Hier ist ein Link zu einem Whitepaper, an dessen Erstellung ich mitgewirkt habe und das Ihnen helfen sollte:Entwurf des physischen DatenbankspeichersStellen Sie außerdem sicher, dass Ihr IO-Subsystem die erwartete Arbeitslast bewältigen kann – siehe dieses Whitepaper:Bewährte Methoden für E/A vor der Bereitstellung. Stellen Sie abschließend sicher, dass Sie die richtige RAID-Stripe-Größe (normalerweise 64 KB oder höher auf neueren Systemen) und die richtige NTFS-Zuordnungseinheitsgröße (normalerweise 64 KB) verwenden und dass Sie auf Systemen vor Windows Server 2008 den Festplattenpartitionsoffset richtig eingestellt haben. Informationen hierzu sowie Hinweise auf weitere Informationen dazu und warum Sie sie auf diese Weise konfigurieren sollten, finden Sie in diesem Blogbeitrag:Sind Ihre Festplattenpartitions-Offsets, RAID-Stripe-Größen und NTFS-Zuordnungseinheiten richtig eingestellt?.

Fazit: Kennen Sie Ihre Arbeitslast und die Fähigkeiten Ihres IO-Subsystems und implementieren Sie entsprechend.

Ich hoffe, das ist hilfreich für Sie.

PS Was tempdb betrifft, ist die Konfiguration ein großes Rätsel, und es gibt alle möglichen widersprüchlichen Informationen. Ich habe einen ausführlichen Blog-Beitrag über die Konfiguration von tempdb-Datendateien geschrieben unterMissverständnisse rund um TF 1118.

Antwort3

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

Protokollierung auf separaten physischen Datenträgern, RAID 1 oder 10 (Striping + Mirroring)

Datenbank auf eigenen Festplatten, je nach Leistungsbedarf meist RAID5

Viel Cache auf den Raid-Controllern

Platzieren Sie Ihr Betriebssystem und die Windows-Auslagerungsdatei vorzugsweise wieder auf einem separaten Array, normalerweise nur einem Spiegel (Raid 1). Dadurch werden alle Schreibvorgänge getrennt, sodass eine hohe Leistung nicht alles nach unten zieht.

Was ich in der Vergangenheit erlebt habe, ist, dass Datenbank-Schreibvorgänge + Protokoll-Schreibvorgänge + Auslagerungsdatei-Schreibvorgänge ein Raid5-Array überlasten und die Leistung in den Keller gehen wird. Das Problem ist, dass Ihre Leistung beim Testen, Entwickeln usw. in Ordnung sein wird. Aber wenn Sie in die Produktion einsteigen und die Nutzung in die Höhe schießt, wird dieses Problem „aus heiterem Himmel“ auftreten und die Benutzerbeschwerden werden in die Höhe schnellen.

Antwort4

Es gibt hier weitaus bessere MSSQL-Leute als mich, aber allgemein würde ich Folgendes vorschlagen:

Betriebssystem und Code auf C: – dies sollten die lokalen Festplatten sein, es sollte ein RAID1-Array-Paar sein – wir verwenden hierfür 2 x 2,5-Zoll-SAS-Festplatten mit 146 GB und 10.000 U/min, aber Sie könnten auch 2 x SATA-Festplatten mit 7.2 verwenden. Die Daten sollten sich auf einem ziemlich schnellen (10.000 U/min oder besser) RAID 1/10, 5/50/6/60-Array der von Ihnen benötigten Größe befinden – wir speichern unsere auf FC SAN LUNs, normalerweise auf einer „Tier 2“-/10.000 U/min-Festplattengruppe. Die Protokolle sollten sich auf einem separaten, SEHR SCHNELLEN (15.000 U/min), kleinen (10 GB oder weniger?) RAID 1-Array-Paar befinden – wir speichern unsere auf FC SAN LUNs, normalerweise auf einer sehr kleinen „Tier1“-/15.000 U/min-Festplattengruppe oder auf einer „Tier0“-/SSD-Gruppe.

In jedem Fall möchten Sie aus Leistungsgründen jeden dieser Blöcke auf separaten Spindeln/Arrays haben. Natürlich funktioniert alles auf einer einzigen Festplatte, aber ich schätze, Sie suchen nach einem Gleichgewicht zwischen Leistung und Kosten.

Wir speichern unsere Master-/Tempdb mit unseren regulären Datenbanken, aber Sie könnten sie in ein separates Datenarray-LUN aufteilen.

Hoffe das hilft.

verwandte Informationen