Beste Hardware-Konfiguration für SQL Server 2012
Hallo zusammen,
ich darf für einen Kunden jetzt eine "Wunschliste" erstellen, was denn die beste Hardware für einen SQL-Server 2012 ist.
Das geht nach dem Motto, das Beste darf es schon sein.
Bis jetzt habe ich schon gefunden dass es
-> 64-bit Version sein sollte
-> am besten RAID 10
Was für CPU, Festplatten usw. wären denn noch am Besten für einen High-End-Sql-Server 2012?
Gibts hier evtl einen Admin, der das eine gute Lösung hat?
Danke für die Infos
Armin
ich darf für einen Kunden jetzt eine "Wunschliste" erstellen, was denn die beste Hardware für einen SQL-Server 2012 ist.
Das geht nach dem Motto, das Beste darf es schon sein.
Bis jetzt habe ich schon gefunden dass es
-> 64-bit Version sein sollte
-> am besten RAID 10
Was für CPU, Festplatten usw. wären denn noch am Besten für einen High-End-Sql-Server 2012?
Gibts hier evtl einen Admin, der das eine gute Lösung hat?
Danke für die Infos
Armin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 259556
Url: https://administrator.de/forum/beste-hardware-konfiguration-fuer-sql-server-2012-259556.html
Ausgedruckt am: 18.04.2025 um 07:04 Uhr
7 Kommentare
Neuester Kommentar
Ok, und ohne genaue Kenntnisse der Konfig möchtest du dem was vorschlagen? Klasse...
Du kannst natürlich nen dicken Server hinstellen - max. RAM, Festplatten-Raid aus SSDs, zig CPUs. Ob jetzt Win oder Linux is ne Frage der DB und des persönlichen Geschmacks... Möchtest du es sicherer haben - kein Ding, Cluster und feuer frei!
Nur: Mit der Kiste wird die DB sicher rennen - allerdings werden die Leiterbahnen einrosten weil der ggf. nicht viel macht wenn da die 30 Benutzer nur ab und an mal ne Anfrage stellen... Und was auch immer "ein Cube" mit 400 Mio Daten ist - auch das kommt ganz drauf an was das ding sein soll. Du kannst ne DB bei schlechten Abfragen schon mit ner Mio Datensätze locker überfordern - du kannst auch 400 Mio. Datensätze mal eben aus dem Ärmel schütteln wenn die Abfragen gut gemacht wurden...
Mit deinen Infos kann man leider nur sagen: Geh in den Laden, guck nach MAX ? (wobei ? z.B. MHz, GB, Core's) sein kann und nimm das. Dies hat nur leider nicht viel mit vernünftigen Angebot zu tun.
Du kannst natürlich nen dicken Server hinstellen - max. RAM, Festplatten-Raid aus SSDs, zig CPUs. Ob jetzt Win oder Linux is ne Frage der DB und des persönlichen Geschmacks... Möchtest du es sicherer haben - kein Ding, Cluster und feuer frei!
Nur: Mit der Kiste wird die DB sicher rennen - allerdings werden die Leiterbahnen einrosten weil der ggf. nicht viel macht wenn da die 30 Benutzer nur ab und an mal ne Anfrage stellen... Und was auch immer "ein Cube" mit 400 Mio Daten ist - auch das kommt ganz drauf an was das ding sein soll. Du kannst ne DB bei schlechten Abfragen schon mit ner Mio Datensätze locker überfordern - du kannst auch 400 Mio. Datensätze mal eben aus dem Ärmel schütteln wenn die Abfragen gut gemacht wurden...
Mit deinen Infos kann man leider nur sagen: Geh in den Laden, guck nach MAX ? (wobei ? z.B. MHz, GB, Core's) sein kann und nimm das. Dies hat nur leider nicht viel mit vernünftigen Angebot zu tun.
Hallo,
wenn du schon rausgefunden hast das 64bit gut währen, dann sollte dir aufgefallen sein das es eigentlich nicht's anderes mehr gibt.
Also Raid 10 würd ich da nicht nehmen eher dann sowas:
http://ocz.com/enterprise/z-drive-4500-pcie-ssd
Dann viel Arbeitsspeicher, da der SQL-Server in neueren Versionen auch inMemory Technologien hat die viel beschleunigen können.
Also vielleicht auch der 2014er?
Aber im großen und ganzen muss ich @maretz beipflichten man braucht mehr Infos für eine richtige auslegung.
Und saubere Abfragen und passende Schlüssel wirken wunder.
wenn du schon rausgefunden hast das 64bit gut währen, dann sollte dir aufgefallen sein das es eigentlich nicht's anderes mehr gibt.
Also Raid 10 würd ich da nicht nehmen eher dann sowas:
http://ocz.com/enterprise/z-drive-4500-pcie-ssd
Dann viel Arbeitsspeicher, da der SQL-Server in neueren Versionen auch inMemory Technologien hat die viel beschleunigen können.
Also vielleicht auch der 2014er?
Aber im großen und ganzen muss ich @maretz beipflichten man braucht mehr Infos für eine richtige auslegung.
Und saubere Abfragen und passende Schlüssel wirken wunder.
Noch mehr infos wären besser. Lass dir doch nicht alles aus der Nase ziehen.
- 30 user und 30 Datenbanken? Oder 30 User pro Datenbank?
Allgemein kann ich dir hier nur zu dem Best-Practise raten. Und wenn es wirklich nach "das Beste darf es sein" geht, dann ist das ja auch kein Problem.
Du solltest pro Datenbank eine eigene SQL-Instanz einrichten. Das hat zum einen den Vorteil, dass du pro SQL-Server den genutzten Arbeitspeicher konfiguriieren kannst zum anderen aber den deutlichen Vorteil, dass du das System warten kannst. Bei SW-Updates oder auch bei Störungen kommt es dann ab und zu mal vor, dass die SQL-Instanz einer Datenbank neu gestartet wird. Wenn du alle 30 Datenbanken in einer Distanz hast, kann keine der Datenbanken weiter arbeiten. Entweder musst du ewig viel koordinieren um einen Zeitpunkt zu finden oder du lebst mit unzufriedenen Usern. Du kannst natürlich die Abhängigkeiten von Datenbanken auch berücksichtigen, aber wenn es sich dabei um 30 unterschiedliche Datenbanken handelt, die nicht ausschließlich gemeinsam genutzt werden, dann würde ich dir zu 30 SQL-Instanzen raten. Ja das macht viel Arbeit bei der Einrichtung, aber du sparst dir im nachgang viele Probleme.
Je nach Daten ind er Datenbank kann eine Instanz dann auch bis zu 8GB Ram benötigen, ggf. auch mehr. Das solltest du dir im Vorfeld noch einmal ansehen. Laut MS ist Minimum 1 Gb, empfohlen 4 (http://msdn.microsoft.com/de-de/library/ms143506.aspx#hwswr). Du soltlest den Server also mindestens mit 120 GB Arbeitsspeicher für 30 SQL Instanzen ausstatten, und dann wärst du "nur" beim empfohlenen Minimalwert. Wenn es wirklich nur 30 User sind (und nicht 30 x 30) ist das natürlich sehr überdimensioniert. Aber sowas kommt beim Motto "Das beste dars schon sein" halt raus.
Darüber hinaus: Auch dein Raid wird irgendwann ausfallen. Das ist keine Frage des ob, sondern eine Frage des wann. Klar, wenn die Festplatten ausfallen, dann wirkt das Raid, aber was machst du, wenn der Raidcontroller ausfällt? Daher sollten die Transaktionsprotokolle und Backups auf einen physikalisch getrennten Raid 1 liegen. Dann kannst du die Datenbank auch im Worst Case wieder herstellen. Stell dir einfach vor, du kommst an den Server garnicht mehr ran. Dann bringt es dir nichts, wenn du die Daten auf einer anderen Partition hast. Die ist dann ggf. ja auch weg. Datenbank und Backup natürlich in unterschiedlichen Brandabschnitten.
Du soltlest mit dem Kunden noch mal sprechen und die Datenbanken analysieren. Mit "das Beste darfs schon sein" wird der Kunde meiner Meinung nach zum jetzigen Kenntnisstand nicht glücklich werden.
- 30 user und 30 Datenbanken? Oder 30 User pro Datenbank?
Allgemein kann ich dir hier nur zu dem Best-Practise raten. Und wenn es wirklich nach "das Beste darf es sein" geht, dann ist das ja auch kein Problem.
Du solltest pro Datenbank eine eigene SQL-Instanz einrichten. Das hat zum einen den Vorteil, dass du pro SQL-Server den genutzten Arbeitspeicher konfiguriieren kannst zum anderen aber den deutlichen Vorteil, dass du das System warten kannst. Bei SW-Updates oder auch bei Störungen kommt es dann ab und zu mal vor, dass die SQL-Instanz einer Datenbank neu gestartet wird. Wenn du alle 30 Datenbanken in einer Distanz hast, kann keine der Datenbanken weiter arbeiten. Entweder musst du ewig viel koordinieren um einen Zeitpunkt zu finden oder du lebst mit unzufriedenen Usern. Du kannst natürlich die Abhängigkeiten von Datenbanken auch berücksichtigen, aber wenn es sich dabei um 30 unterschiedliche Datenbanken handelt, die nicht ausschließlich gemeinsam genutzt werden, dann würde ich dir zu 30 SQL-Instanzen raten. Ja das macht viel Arbeit bei der Einrichtung, aber du sparst dir im nachgang viele Probleme.
Je nach Daten ind er Datenbank kann eine Instanz dann auch bis zu 8GB Ram benötigen, ggf. auch mehr. Das solltest du dir im Vorfeld noch einmal ansehen. Laut MS ist Minimum 1 Gb, empfohlen 4 (http://msdn.microsoft.com/de-de/library/ms143506.aspx#hwswr). Du soltlest den Server also mindestens mit 120 GB Arbeitsspeicher für 30 SQL Instanzen ausstatten, und dann wärst du "nur" beim empfohlenen Minimalwert. Wenn es wirklich nur 30 User sind (und nicht 30 x 30) ist das natürlich sehr überdimensioniert. Aber sowas kommt beim Motto "Das beste dars schon sein" halt raus.
Darüber hinaus: Auch dein Raid wird irgendwann ausfallen. Das ist keine Frage des ob, sondern eine Frage des wann. Klar, wenn die Festplatten ausfallen, dann wirkt das Raid, aber was machst du, wenn der Raidcontroller ausfällt? Daher sollten die Transaktionsprotokolle und Backups auf einen physikalisch getrennten Raid 1 liegen. Dann kannst du die Datenbank auch im Worst Case wieder herstellen. Stell dir einfach vor, du kommst an den Server garnicht mehr ran. Dann bringt es dir nichts, wenn du die Daten auf einer anderen Partition hast. Die ist dann ggf. ja auch weg. Datenbank und Backup natürlich in unterschiedlichen Brandabschnitten.
Du soltlest mit dem Kunden noch mal sprechen und die Datenbanken analysieren. Mit "das Beste darfs schon sein" wird der Kunde meiner Meinung nach zum jetzigen Kenntnisstand nicht glücklich werden.