Optimale Laufwerkskonfiguration für SQL Server 2008R2

19

Ich habe einen ziemlich ausgelasteten Datenbankserver, auf dem SQL Server 2008 R2 ausgeführt wird und der das folgende Setup aufweist:

SATA RAID 1 (2 Laufwerke) - Betriebssysteme / Programme
SAS RAID 10 (4 Laufwerke) - SQL-Datenbankdateien (Daten und Protokolle)
SAS RAID 1 (2 Laufwerke) - TempDB (Daten und Protokolle)

Angenommen, ich kann diesem Server keine zusätzlichen Laufwerke hinzufügen. Habe ich die verfügbare Konfiguration optimal genutzt? Oder sollte ich hier ein anderes Schema in Betracht ziehen, bei dem Protokolle beispielsweise von den Datendateien isoliert sind?

Aktualisieren:

Für diejenigen, die weitere Hardwaredetails angefordert haben:

Die SATA-Laufwerke (für die OS / Program-Partition verwendet) sind: WD 7200 RPM 3 Gb / s 3,5-Zoll-SATA
Die in den anderen Arrays verwendeten SAS-Laufwerke sind: Seagate 15K RPM 6 Gb / s 3,5 Zoll SAS
Der verwendete RAID-Controller ist ein: LSI 9260-8i SAS / SATA 6 Gb 8-Port

Update 2:

Ausgehend von den Rückmeldungen, die ich erhalten habe, habe ich anscheinend die folgenden Optionen zur Auswahl: - Ich werde die Prämie an jemanden vergeben, der mir sagen kann, welcher der wahrscheinlich besten in der von mir skizzierten Umgebung ist:

Lass alles so wie es ist - ich werde es wahrscheinlich nicht viel besser machen
Verschieben Sie meine 2 SAS RAID 1-Laufwerke in mein vorhandenes RAID 10-Array, damit es aus insgesamt 6 Festplatten besteht
Verschieben Sie meine Protokolldateien auf das SAS-RAID 1 und / oder verschieben Sie TempDB (Daten oder Protokolle) zurück auf das RAID 10

sql-server hardware

— DanP
quelle

Bei Ihrem zweiten Update werden genau die gleichen Fragen gestellt wie bei Ihrer ursprünglichen Frage. Daher gilt die ursprüngliche Antwort. "... das ist wahrscheinlich das Beste in der Umgebung, die ich beschrieben habe" ... Sie haben uns keine Analyse der Arbeitsbelastung gezeigt, nur dass es "ziemlich beschäftigt" ist, daher gilt die gleiche Antwort .

— Mark Storey-Smith

Mit Hochleistungs-NVMe- und anderen SSD-Festplatten auf dem Markt ist das RAID aus Sicht der Best Practices für die SQL Server-Festplattenkonfiguration nicht mehr sehr wichtig . Festplattenpools (Storage Spaces) sind der Weg, um fortzufahren. Sie müssten die Volumes jedoch logisch trennen, um festplattenbezogene Leistungsprobleme besser beheben zu können.

— Gesichter von IT

14

Varianten dieser Frage tauchen regelmäßig auf:

Es gibt auch gelegentliche Brötchenstreitigkeiten über die "Best Practice" der Daten- / Protokolltrennung.

Ohne detailliertere Analyse dessen, was dieser Server tut, gelten dieselben Ratschläge wie zuvor.

RAID 1 für Betriebssystem
RAID 10 (6 Datenträger) für Daten / Protokolle / Tempdb

Es gibt selten einen Punkt in einem Split mit so wenigen verfügbaren Spindeln. Ein einzelnes Array mit einer größeren IOP-Kapazität nimmt in der Regel die Unebenheiten Ihrer Arbeitslast besser auf als zwei kleinere Arrays.

Eine Variante, die einen Test wert sein kann, ist das Versetzen von tempdb auf das Betriebssystemlaufwerk. Tun Sie dies nur, wenn Sie eine repräsentative Arbeitslast haben, die Sie wiederholt abspielen können, um einen fairen Vergleich der Konfiguration zu gewährleisten. Wenn Sie sich für diese Anordnung in der Produktion entscheiden, stellen Sie sicher, dass das Tempdb-Wachstum begrenzt ist, damit Sie nicht versehentlich den gesamten freien Speicherplatz auf dem Betriebssystemlaufwerk belegen.

Angesichts der Tatsache, dass es sich bei Ihren OS-Laufwerken um Untersetzer mit 7200 U / min handelt, wäre ich überrascht, wenn die Tempdb in der OS-Laufwerkskonfiguration irgendeinen Vorteil hätte.

— Mark Storey-Smith
quelle

7

Es hängt alles von Ihrer Arbeitsbelastung ab, aber mit nur 6 Laufwerken sind Ihre Optionen begrenzt. Wenn Ihre Arbeitslast nicht stark von Tempdb abhängt, z. B. bei Sortierungen, Hash-Tabellen und der Snapshot-Isolierung, ist es möglicherweise besser, die 6 SAS-Laufwerke in RAID 10 zusammen zu verwenden. Wenn Sie dies jedoch wissen oder über die entsprechenden Messdaten verfügen Tempdb ist stark ausgelastet, dann sollten Sie es getrennt halten, wie Sie haben.

— Patrick Keisler
quelle

Danke für die Antwort, das Ändern der Konfiguration der Bereiche ist (leider) keine Option, da dieser Server in Produktion ist. Ich bin gespannt darauf, die Tempdb wieder auf RAID 10 umzustellen und alle Protokolldateien auf RAID 1 zu speichern. Ist dies eine clevere Option?

— DanP

2

Denken Sie daran, dass SQL Server als Teil des Commits alle Transaktionen physisch in das Protokoll schreiben muss, damit Sie die schnellstmögliche Schreibleistung in Ihrer Konfiguration erzielen. RAID 10 bietet eine bessere Schreibleistung als RAID 1, sodass die Protokolle auf dem schnelleren Volume verbleiben.

— Patrick Keisler

2

Es hängt sehr stark davon ab, was Sie unter "sehr beschäftigt" verstehen: Unterschiedliche Workload-Muster (Schreiben überlastet oder nicht, häufige oder nicht häufige Massenoperationen, gleichzeitiger Zugriff, um nur drei der vielen Variablen zu nennen) können drastische Auswirkungen auf die Arbeitslast haben Leistung einer gegebenen Spindelanordnung.

Bei einer schreibintensiven Situation kann das Trennen der Protokolle von den Daten einen signifikanten Unterschied bewirken, da bei jedem Schreibvorgang sowohl das Protokoll als auch die Datendateien aktualisiert werden. Dies bedeutet eine erhebliche Menge an zusätzlichem Kopfwechsel, wenn sich beide Dateisätze auf demselben Spindelsatz befinden .

Ohne weiteren Bezug auf Ihre Arbeitslast (und die Spezifikation dieser Laufwerke und aller Controller, die sich zwischen ihnen und der Maschine befinden) würde ich mich für drei Volumes entscheiden: eines für OS + -Programme und Tempdb (Daten), eines für die Haupt-DB Daten und die dritte für Protokolle (sowohl Tempdb als auch Haupt-DBs).

Natürlich sollten Sie sich nicht zu viel Zeit nehmen, um Daten und Protokolle getrennt zu halten, wenn Ihre Workloads nur sehr wenig Schreibvorgänge erfordern, da dies nur einen geringen Leistungsunterschied bewirkt und die Bereitstellung eines ganzen Volumens für sie sehr verschwenderisch wäre Platz.

— David Spillett
quelle

Ich würde unsere Umgebung sicherlich als "schwer schreibbar" bezeichnen - ich werde meine Frage am Montag mit detaillierteren Hardwarespezifikationen aktualisieren.

— DanP

Haben Sie eine Vorstellung von der Anzahl der Antriebe, über die OP verfügt? Ich denke eher an den Raid 1, den er für die Logdateien hat. Das klingt nicht nach einer großartigen Option für Schreibzwecke, und AFAIK-Protokolldateien sind nicht lesebeschränkt, sondern schreibbar.

— Marian

Ich habe zusätzliche Angaben zur Hardware der Maschine hinzugefügt.

— DanP

1

Dieses Missverständnis kann die Ursache für viele der Daten- / Protokolltrennungsprobleme sein, also entschuldige ich mich, aber ich werde es herausfordern. "... da bei jedem Schreibvorgang sowohl das Protokoll als auch die Datendateien aktualisiert werden" - nein, dies ist nicht der Fall. Schreibvorgänge auf Datenseiten erfolgen am Prüfpunkt und nicht bei jeder Änderung.

— Mark Storey-Smith

1

@ DavidSpillett Richtig, es wird immer Fälle geben, in denen die Aufteilung vorteilhaft ist. Der Schlüssel ist, dass Sie getestet und validiert haben, dass die Konfiguration für diese bestimmte Arbeitslast von Vorteil ist.

— Mark Storey-Smith

2

Die tatsächliche Antwort hängt von Ihren Anforderungen ab, aber im Allgemeinen ist "Daten speichern und auf verschiedenen Arrays anmelden" von größerer Bedeutung als "Tempdb auf einem eigenen Array ablegen".

Bei der Anzahl der verfügbaren Laufwerke wäre mein Ausgangspunkt:

Zwei Laufwerke, RAID 1 - Betriebssystem, ausführbare Dateien, Auslagerungsdatei.
Vier Laufwerke, RAID 5 - Alle Datendateien (alternativ RAID 1 + 0)
Zwei Laufwerke, RAID 1 - Alle Protokolldateien

Verwenden Sie SQLIO , um die Leistung verschiedener Laufwerkskonfigurationen zu testen.

— Greenstone Walker
quelle

Dies ist definitiv die "andere Seite" des Ratschlags, den ich gelesen habe. Ich wünschte, es gäbe eine endgültige Methode, um zu bestimmen, welche der Optionen besser wäre, ohne sie in einer Produktionsumgebung auszuprobieren.

— DanP

2

@DanP Nun, ich persönlich wäre Marks Rat gefolgt und hätte ein RAID10 für den Rest der Laufwerke gewählt (mit Ausnahme des Betriebssystems). Protokolldateien sind schreibintensiv und benötigen eine bessere Leistung als das, was RAID 1 meiner Meinung nach zu bieten hat. Aber ich bin kein Hardware-Experte. Nur meine 2 Cent.

— Marian

2

Ich sollte erwähnen, dass meine Meinung nur aus der Erfahrung einer (Art) fehlgeschlagenen Migration auf einen besseren Server stammt, aber mit schlechterer Leistung. Wir haben nie eine echte Auslastung auf diesem neuen Server getestet, wir hatten nie eine Chance, der Server war nicht rechtzeitig einsatzbereit. Es stellte sich heraus, dass der Servertest VOR der Migration zur Produktion obligatorisch sein sollte. Entschuldigung für die Betonung. Mein Mantra für alle Migrationen / Upgrades lautet also: TEST, TEST, TEST, ... Freaking Test so weit wie möglich.

— Marian

1

Ich bin mir nicht sicher, ob ich mit RAID 5 oder SQLIOSIM beginnen soll. Gehen wir zu einem späteren Zeitpunkt, da ersterer für sich spricht. SQLIOSIM ist ein Korrektheits- und Stresstest-Tool . Es ist kein Leistungs- oder Lasttest-Tool. Es hat absolut keinen Platz, die Leistung von config-X mit config-Y für Workload-Z zu vergleichen. Alles, was Ihnen sagen würde, ist, wie gut config-X in einem SQLIOSIM-Lauf gegen config-Y abschneidet. Wenn Sie die Leistung für Workload-Z vergleichen möchten, testen Sie Workload-Z.

— Mark Storey-Smith

1

@ GreenstoneWalker "RAID1 ist schneller zum Schreiben als RAID1 + 0" ist Quatsch. Woher kam diese Idee?

— Mark Storey-Smith

-1

Abhängig davon, wofür Sie die Datenbank verwenden (OLTP vs. Warehousing), sieht Ihre Konfiguration wie eine gute allgemeine Konfiguration aus. Wenn Sie mehr Festplatten hätten, hätten Sie mehr Optionen.

Sie könnten eine bessere Leistung erzielen, wenn Sie die Festplatte für Ihre TempDB auf RAID 0 (Stripe) umstellen. Es erhöht Ihr Ausfallrisiko, aber da TempDB nur Daten puffert, können Sie keinen Datenverlust feststellen. Die meisten Leute halten das für einen vernünftigen Kompromiss. Halten Sie einfach ein Ersatzteil in der Nähe (oder ein Ersatzteil).

Eine Sache, die Sie nicht erwähnt haben, die Sie aber versuchen könnten (falls Sie dies noch nicht getan haben): Microsoft empfiehlt, Ihre TempDB auf mehrere Dateien aufzuteilen (eine pro CPU). Natürlich ist es am besten, wenn sie sich auf separaten Datenträgern befinden, aber es hilft einfach, separate Dateien zu haben. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

— TimG
quelle

4

Tempdb wird für viele Zwecke verwendet, aber behandeln Sie es nicht als Wegwerfdatenbank und platzieren Sie es auf einem RAID 0. Beachten Sie, dass SQL Server nicht gestartet werden kann, wenn das RAID 0-Volume ausfällt.

— Patrick Keisler

Ich habe tatsächlich eine temporäre Datenbank pro Kern erstellt, wie vorgeschlagen, aber danke, dass Sie diesen Punkt ebenfalls

— angesprochen haben

1

Nun, diese Vorschläge sind nicht sehr gut und nicht für jede Umgebung geeignet. Erste wird von @PatrickKeisler früher erwähnt. Der zweite ist ein Mythos, den Paul Randal vor einiger Zeit entlarvt hat. Der Artikel lautet wie folgt: Ein SQL Server-DBA-Mythos pro Tag: (30.12.) Tempdb sollte immer eine Datendatei pro Prozessorkern haben . MS-Dokumentation kann also falsch sein, nehmen Sie es nicht auswendig.

— Marian

2

"Da TempDB nur Daten puffert, können Sie keinen Datenverlust feststellen" ... und ich bin sicher, die Benutzer des Systems werden es zu schätzen wissen, dass sie während der x-stündigen Ausfallzeit leiden, während a) Ops im Keller nach a) suchen Ersatzdatenträger oder b) Ein DBA versucht dem Helpdesk zu erklären, wie er tempdb von seinem Mobiltelefon aus verschieben kann.

— Mark Storey-Smith