Hardware-Grundlagen:

Die Bühne, auf der SQL Server auftreten darf

SQL Server ist kein gewöhnliches Programm. Er verwaltet Terabytes an Daten, bedient hunderte gleichzeitiger Verbindungen, schreibt Transaktionen atomar in das Transaktionslog und hält dabei einen Buffer Pool im Gigabyte-Bereich im Arbeitsspeicher ständig aktuell. Das alles gleichzeitig — und am liebsten auf Hardware, die für genau diese Anforderungen konzipiert wurde.

Wer die Hardware nicht versteht, rätselt beim Performance-Troubleshooting. Er sieht hohe IO-Latenzen und weiß nicht, ob 15 Millisekunden normal oder katastrophal sind. Er sieht NUMA-Node-Imbalances im Monitoring-Dashboard und googelt hilflos. Er kauft mehr RAM und ist enttäuscht, dass es trotzdem nicht schneller wird — weil das eigentliche Problem woanders liegt. Dieses Kapitel ändert das.

Wir schauen uns die vier Säulen der SQL-Server-Hardware an: CPU, RAM, Storage und Netzwerk. Nicht als abstrakte Theorie, sondern mit konkreten Zahlen, typischen Konfigurationsfehlern und dem ständigen Fokus auf die Frage: Was bedeutet das für meine Datenbank?

Dabei begegnen wir zum ersten Mal unseren drei Begleitern, die das gesamte Buch begleiten werden. Die Musterwerk GmbH betreibt einen soliden Mittelklasse-Server mit einem Mix aus guten und ausbaufähigen Entscheidungen. Trendforge Digital GmbH hat einen tadellosen Server — aber Entwickler, die ihn systematisch in die Knie zwingen. Und dann ist da noch Sparfuchs & Partner Steuerberatungs GmbH, die auf 4 vCPUs, 8 GB RAM und einer einzigen Festplatte eine 12-GB-Datenbank zur kompletten Unbenutzbarkeit gebracht hat. Den vollen Umfang dieses Kunstwerks betrachten wir in Kapitel 33 — aber Sparfuchs wird uns durch das gesamte Buch als mahnendes Beispiel begleiten.

 

Praxisbeispiel: Der Anruf, den du kennst
Ein Kunde meldet sich. "Der SQL Server ist langsam." Erste Frage: Wie sieht die Hardware aus? Antwort: "4 vCPUs, 8 GB RAM, alles auf einer Platte." Zweite Frage: Wie groß ist die Datenbank? Antwort: "12 Gigabyte." Dritte Frage: Priority Boost aktiviert? — Stille. Dann: "Was ist das?"
Das ist Sparfuchs. Und du wirst nach diesem Buch weder derjenige sein, der diesen Anruf tätigt, noch derjenige, der dann nicht weiter weiß.

 

1. CPU: Kerne, Takt und das NUMA-Dilemma

Die CPU ist der Taktgeber. Alles, was SQL Server tut — Abfragen parsen, Pläne erstellen, Locks verwalten, Daten aggregieren — läuft auf CPU-Kernen. Aber "mehr CPU ist besser" ist eine gefährlich vereinfachte Aussage. Die Wahrheit ist: Es kommt darauf an, welchen Workload du hast, wie die CPU-Architektur aussieht, und ob deine Konfiguration das Potenzial der Hardware überhaupt ausschöpft.

1.1 Kerne versus Takt: Die Frage, die nie aufhört

SQL Server-Workloads lassen sich grob in zwei Kategorien einteilen — und diese Kategorisierung bestimmt, was du beim CPU-Kauf priorisierst.

OLTP-Workloads (Online Transaction Processing) bestehen aus vielen kurzen, schnellen Transaktionen: INSERT, UPDATE, DELETE in rascher Folge, dutzende oder hunderte parallele Sessions. Hier konkurrieren Sessions häufig um dieselben Ressourcen — Locks auf denselben Zeilen, Latches auf denselben Speicherseiten. Die kritische Größe ist, wie schnell eine einzelne Transaktion erledigt wird und den Lock wieder freigibt. Ein schnellerer Kern erledigt die Transaktion schneller, hält den Lock kürzer, und reduziert die Contention. Bei OLTP-Workloads gewinnt Takt.

Analytische Workloads (OLAP, Reporting, Data Warehouse) bestehen aus wenigen, aber riesigen Abfragen. Ein SELECT über 500 Millionen Zeilen, eine Aggregation über die gesamte Bestellhistorie, ein JOIN über mehrere Faktentabellen. SQL Server parallelisiert diese Abfragen — er verteilt die Arbeit auf mehrere Worker-Threads, die auf verschiedenen Kernen gleichzeitig laufen. Mehr Kerne bedeuten mehr parallele Worker, mehr parallele Arbeit, schnellere Gesamtlaufzeit. Bei analytischen Workloads gewinnt Kernzahl.

Für die meisten Produktionssysteme ist die Wahrheit ein Kompromiss: gemischte Workloads, die sowohl OLTP- als auch Reporting-Aspekte haben. Der pragmatische Ausgangspunkt: 8 bis 16 physische Kerne mit einem Basistakt zwischen 2,5 und 3,5 GHz. Das ist eine Konfiguration, mit der die meisten mittelgroßen Deployments gut fahren — und eine Konfiguration, die mit SQL Server Enterprise Edition wirtschaftlich sinnvoll lizenziert werden kann.

 

Hinweis: Standard Edition und die Kern-Begrenzung

SQL Server Standard Edition ist auf 24 Kerne (4 Sockets, der kleinere Wert gilt) begrenzt. Enterprise Edition nutzt bis zu 640 logische Prozessoren (SQL Server 2022). Wer einen 48-Kern-Server mit Standard Edition betreibt, verschenkt die Hälfte der Hardware — zahlt aber trotzdem für Strom, Kühlung und Rack-Platz. Die Core-Lizenzierung ist ein Hauptargument dafür, nicht blind "den größten Server im Katalog" zu kaufen.

 

1.2 CPU-Caches: L1, L2, L3 und warum der L3 kritisch ist

Zwischen der CPU und dem Hauptspeicher liegt eine Welt voller Latenz. DDR5-RAM ist schnell — für menschliche Verhältnisse. Für eine moderne CPU, die bei 3,5 GHz taktet und in unter einer Nanosekunde eine Instruktion ausführen kann, ist jeder RAM-Zugriff mit 60–80 Nanosekunden Latenz eine Ewigkeit. Daher gibt es CPU-Caches: kleine, extrem schnelle Speicherhierarchien direkt auf dem Prozessor-Die.

Der L1-Cache ist pro Kern vorhanden, typischerweise 32–64 KB groß, und hat eine Zugriffslatenz von rund 1 Nanosekunde. Hier liegen aktive Instruktionen und die Daten, die gerade verarbeitet werden. Der L2-Cache ist ebenfalls pro Kern, größer (256 KB bis 2 MB) und etwa 4 Nanosekunden schnell — er fungiert als Warteraum für Daten, die wahrscheinlich bald in den L1 hochgezogen werden. Der L3-Cache schließlich wird von allen Kernen eines Sockets geteilt, ist deutlich größer (8 bis 96 MB bei modernen Server-CPUs) und hat eine Zugriffslatenz von 10–30 Nanosekunden.

Für SQL Server ist der L3-Cache der entscheidende Faktor. SQL Server speichert Datenseiten (je 8 KB) im Buffer Pool und greift bei jeder Abfrageausführung auf diese Seiten zu. Wenn die aktiv genutzten Seiten — der "heiße" Bereich des Buffer Pools — in den L3-Cache passen, ist jeder Zugriff 3–6× schneller als ein RAM-Zugriff. Bei einem OLTP-System mit einer überschaubaren Menge häufig genutzter Index-Seiten kann ein großer L3 den Unterschied zwischen 50.000 und 90.000 Transaktionen pro Sekunde ausmachen.

Die Unterschiede zwischen Prozessorfamilien sind hier erheblich: Ein Intel Xeon Gold 6338 hat 48 MB L3-Cache. Ein AMD EPYC 9654 bringt 384 MB L3-Cache mit — acht Mal so viel. Für Workloads mit einem heißen Arbeitsbereich von 200–300 MB ist das ein messbarer Vorteil. Das bedeutet nicht automatisch "kauf AMD" — es bedeutet: Kenn deinen Workload, und berücksichtige die Cache-Größe bei der Hardware-Entscheidung.

1.3 NUMA: Non-Uniform Memory Access

 

Definition: NUMA

Non-Uniform Memory Access (NUMA) beschreibt eine Speicherarchitektur, bei der mehrere CPU-Sockets jeweils ihren eigenen lokalen Speichercontroller und direkt angeschlossenen RAM haben. Speicherzugriffe auf lokalen RAM sind schneller als auf RAM, der physisch an einem anderen Socket hängt. SQL Server ist seit Version 2005 NUMA-aware und versucht, Speicher und Rechenarbeit auf demselben NUMA-Knoten zu halten.

 

Moderne Server-Mainboards haben zwei, vier oder noch mehr CPU-Sockets. Jeder Socket hat seinen eigenen Speichercontroller und seine eigenen DIMM-Slots. Das bedeutet mehr Gesamtkapazität und mehr Speicherbandbreite — aber es hat eine Konsequenz, die SQL Server-Administratoren kennen müssen: Nicht jeder RAM-Zugriff ist gleich schnell.

Ein Kern auf Socket 0, der auf RAM zugreift, der physisch an Socket 0 angebunden ist, hat eine Latenz von etwa 60–80 Nanosekunden. Derselbe Kern, der auf RAM an Socket 1 zugreift, muss über den QPI- oder UPI-Interconnect zwischen den Sockets — das kostet 100–200 Nanosekunden. Faktor 1,5 bis 3 für exakt dieselbe Operation.

 

Abb. 1.1: NUMA-Topologie auf einem Dual-Socket-Server

SQL Server kennt diese Topologie und reagiert darauf: Er erstellt pro NUMA-Knoten eigene Scheduler und versucht, Worker-Threads auf dem Knoten zu halten, auf dem die benötigten Daten liegen. Wenn das gut funktioniert, ist NUMA für den Workload transparent. Wenn es schlecht funktioniert — etwa, weil der Buffer Pool asymmetrisch gefüllt ist oder, weil Prozesse ständig zwischen Knoten "wandern" — entstehen NUMA-Imbalances, die sich in ungleich verteilter Scheduler-Last ausdrücken.

Wie du NUMA-Probleme konkret diagnostizierst, schauen wir uns in Kapitel 11 (Memory Management) und Kapitel 9 (Wait Statistics) an. Für die Hardware-Entscheidung gilt als einfache Regel: Kaufe symmetrisch. Gleich viel RAM pro NUMA-Knoten, gleich viele Kerne pro Socket.

 

Hinweis: NUMA-Topologie abfragen
Die folgende DMV gibt dir einen schnellen Überblick über die NUMA-Topologie deines SQL Servers:
SELECT node_id, node_state_desc,
memory_node_id,
online_scheduler_count,
memory_object_count
FROM sys.dm_os_nodes
WHERE node_state_desc != 'DEAD';
Ein gesundes Ergebnis zeigt symmetrische Knoten mit gleichmäßiger Scheduler-Verteilung. Mehr dazu in Kapitel 11.

 

1.4 Hyperthreading: Doppelt hält besser — oder halbiert die Leistung?

Intels Hyperthreading (HT) und AMDs SMT (Simultaneous Multithreading) präsentieren dem Betriebssystem mehr logische Kerne als physisch vorhanden sind. Ein 16-Kern-Prozessor mit HT erscheint als 32-Kern-Prozessor. Der Trick dahinter: Beide logischen Kerne eines physischen Kerns teilen sich die Ausführungseinheiten. Wenn ein logischer Kern auf RAM wartet — was häufig passiert — kann der andere logische Kern die frei stehenden Ausführungseinheiten nutzen und seine Arbeit erledigen.

Für SQL Server ist Hyperthreading in der Regel vorteilhaft. In den meisten Szenarien verbessert es den Durchsatz um 10 bis 30 Prozent, weil SQL Server viele Threads hat, die zwischen CPU-Arbeit und IO-Warten wechseln. Es gibt Ausnahmen: Bei spinlock-intensiven Workloads kann HT Contention verschlimmern, weil mehr logische Threads um dieselben physischen Ressourcen konkurrieren. Aber das sind Randerscheinungen, die gezielte Analyse erfordern.

Was du bei Hyperthreading unbedingt anpassen musst: MAXDOP (Maximum Degree of Parallelism). Diese Einstellung bestimmt, wie viele parallele Worker-Threads SQL Server für eine einzelne Abfrage einsetzen darf. MAXDOP sollte sich an den physischen Kernen orientieren, nicht an den logischen. Auf einem 16-Kern-Prozessor mit HT (also 32 logische Kerne) ist MAXDOP = 8 ein guter Ausgangspunkt — sicher nicht 32.

Warum nicht die vollen physischen Kerne? Weil andere Sessions auch Kerne brauchen. MAXDOP = 8 auf einem 16-Kern-Server bedeutet: Eine parallele Abfrage kann maximal die Hälfte der CPU beanspruchen, die andere Hälfte bleibt für parallelen OLTP-Traffic. Wie MAXDOP exakt zu berechnen und zu konfigurieren ist, schauen wir in Kapitel 5 (Serverkonfiguration) im Detail. Für die Hardware-Entscheidung gilt: Hyperthreading an, MAXDOP vernünftig gesetzt.

 

Warnung: MAXDOP = 0 ist kein "ich überlass das SQL Server"

MAXDOP = 0 bedeutet: SQL Server darf für eine Abfrage so viele Kerne nutzen wie vorhanden sind. Auf einem 32-Kern-Server mit 32 logischen Prozessoren startet SQL Server dann 32 parallele Worker für eine Abfrage — und blockiert damit den gesamten Server für alle anderen Sessions. MAXDOP = 0 auf Servern mit mehr als 8 Kernen ist ein häufiger Konfigurationsfehler mit dramatischen Auswirkungen. Kapitel 5 zeigt die richtige Formel.

 

1.5 SQL Server Lizenzierung und die CPU-Kalkulation

SQL Server Enterprise Edition wird pro physischem Kern lizenziert. Ein 32-Kern-Server kostet entsprechend viel — und das beeinflusst Kaufentscheidungen in einer Weise, die nicht immer im Performance-Interesse liegt.

Das typische Anti-Pattern: "Wir kaufen den 64-Kern-Server, weil er im Angebot war, lizenzieren aber nur 16 Kerne." Das Ergebnis ist ein Server, der auf einem Viertel seiner Möglichkeiten läuft — und für den Rest trotzdem Strom, Rack-Platz und Kühlung bezahlt wird. SQL Server erkennt die unlizenzierte Kapazität und nutzt sie nicht.

Die wirtschaftlich sinnvolle Strategie: Kaufe einen Server, der gut zu deinem lizenzierten Core-Count passt. Für Standard Edition (max 24 Kerne) ist ein 24-Kern-Server optimal — nicht ein 64-Kern-Server mit 24 lizenzierten Kernen. Für Enterprise Edition gilt: Mehr Kerne als 32 lohnen sich nur bei nachgewiesenem Bedarf für sehr hohe Parallelität.

 

Workload-Typ	Physische Kerne	Takt (Basis)	Empfehlung
OLTP klein	8 Kerne	≥ 3,0 GHz	Standard Edition ausreichend
OLTP mittel	16 Kerne	≥ 2,8 GHz	Standard oder Enterprise
OLTP groß	24–32 K.	≥ 2,5 GHz	Enterprise, HT aktiviert
OLAP/Reporting	32+ Kerne	≥ 2,0 GHz	Enterprise, große L3-Caches
Gemischt (typisch)	16 Kerne	2,8–3,2 GHz	Standard oder Enterprise

Tab. 1.1: CPU-Empfehlungen nach Workload-Typ

 

2. RAM: Der Buffer Pool braucht Futter

RAM ist die wichtigste Ressource für SQL Server. Nicht CPU, nicht Storage — RAM. Weil SQL Server einen Großteil seiner Arbeit einfach vermeidet, wenn die benötigten Daten bereits im Speicher liegen. Und "Arbeit vermeiden" bedeutet hier: keine physischen IO-Operationen, keine Wartezeiten auf Festplatten oder SSDs, keine Konkurrenz um IO-Bandbreite.

2.1 Wie SQL Server RAM nutzt: Der Buffer Pool

Das zentrale Konzept heißt Buffer Pool. Der Buffer Pool ist ein Speicherbereich, in dem SQL Server Datenseiten cached. Jede Seite ist 8 KB groß — das ist die fundamentale IO-Einheit von SQL Server. Wenn eine Abfrage auf Daten zugreift, liest SQL Server die entsprechenden Seiten vom Datenträger in den Buffer Pool und hält sie dort. Beim nächsten Zugriff auf dieselben Seiten — ob von derselben Session oder einer anderen — findet SQL Server die Seiten bereits im Speicher und spart sich den Disk-Zugriff.

Der Geschwindigkeitsunterschied ist enorm: Ein RAM-Zugriff kostet rund 60–80 Nanosekunden. Ein NVMe-SSD-Zugriff kostet 50–100 Mikrosekunden — Faktor 1.000. Eine SATA-SSD: 0,1 bis 0,5 Millisekunden — Faktor 10.000. Eine HDD: 8 bis 15 Millisekunden — Faktor 200.000. Jede Seite, die im Buffer Pool liegt statt auf der Disk, spart diesen Faktor ein.

Die Page Life Expectancy (PLE) misst, wie lange eine Seite durchschnittlich im Buffer Pool bleibt, bevor sie für neue Seiten verdrängt wird. Ein früher verbreiteter Richtwert war PLE > 300 Sekunden. Das ist heute unvollständig: Bei einer 500-GB-Datenbank auf einem Server mit 64 GB RAM ist ein PLE von 150 Sekunden vielleicht das Beste, was du erreichen kannst — und trotzdem kein Problem, wenn der Workload diese Charakteristik hat. Bei einer 20-GB-Datenbank auf demselben Server sollte der PLE bei mehreren tausend Sekunden liegen. Wie du PLE korrekt interpretierst und in den Kontext deiner Gesamtsituation einordnest, schauen wir in Kapitel 11 (Memory Management).

 

Hintergrund: Buffer Pool ist nicht der einzige RAM-Verbraucher
SQL Server nutzt RAM auch für andere Zwecke: Plan Cache (gespeicherte Abfragepläne), ColumnStore-Pools, In-Memory OLTP (Hekaton), Lock Manager, Thread-Stacks und diverse interne Strukturen. Auf einem Server mit 128 GB RAM kann der Plan Cache problemlos 2–4 GB belegen, besonders, wenn viele ad-hoc-Abfragen gestellt werden. Der Buffer Pool bekommt den Löwenanteil — aber er ist nicht das Einzige.

 

2.2 Wie viel RAM ist genug?

Die ehrlichste Antwort ist: "Mehr, als du gerade hast." Aber das ist als Beschaffungsargument wenig hilfreich. Hier sind messbare Ansätze.

Ausgangspunkt ist der Working Set: Die Menge der Daten, auf die dein Workload regelmäßig zugreift. Nicht die Gesamtgröße aller Datenbanken — sondern die aktiv genutzten Tabellen und Indizes. Bei einem typischen OLTP-System sind das oft 20–40 Prozent der Gesamtdatenbankgröße. Bei einem DWH mit Columnstore-Indizes kann Kompression die relevante Datenmenge stark reduzieren.

Ziel ist: Der Working Set soll vollständig in den Buffer Pool passen. Sobald das der Fall ist, sinken die physischen IO-Operationen dramatisch, und der PLE steigt auf hohe Werte. Darüber hinaus bringt mehr RAM abnehmende Renditen — außer du hast spezifische andere Verbraucher wie große In-Memory-OLTP-Tabellen.

Zur Gesamtkalkulation: Buffer Pool + 4 GB Betriebssystem-Reserve + 2 GB für andere SQL-Server-Komponenten ist ein solider Ausgangspunkt. Darüber hinaus sollte max server memory immer explizit gesetzt sein — mehr dazu in Kapitel 5 (Serverkonfiguration).

 

Szenario	DB-Größe (gesamt)	Working Set (ca.)	RAM-Empfehlung
OLTP klein	50 GB	15–20 GB	32–64 GB RAM
OLTP mittel	200 GB	50–80 GB	128 GB RAM
OLTP groß	1 TB	200–300 GB	384–512 GB RAM
DWH mit Columnstore	5 TB	300–500 GB	512 GB RAM + testen
Reporting (gemischt)	500 GB	100–150 GB	256 GB RAM

Tab. 1.2: RAM-Empfehlungen nach Datenbankgröße und Workload (Richtwerte)

 

 

Warnung: max server memory nicht vergessen
SQL Server greift ohne explizite Begrenzung so viel RAM wie möglich. Das Betriebssystem, andere Dienste und der SQL Server Agent brauchen aber ebenfalls Speicher. Typische Faustformel: Reserviere 4–8 GB für Windows auf einem dedizierten SQL-Server, weise den Rest SQL Server zu. Auf einem Server mit 128 GB RAM: max server memory = 120.000 (MB).
Sparfuchs & Partner hatte max server memory = 8192 bei 8 GB physischem RAM. Theoretisch korrekt — praktisch kämpfte Windows mit 200 MB um Luft, und der Out-of-Memory-Manager verdrängte SQL-Server-Seiten aktiv aus dem RAM.

 

2.3 Memory Channels: Warum die DIMM-Bestückung zählt

RAM-Module liefern Daten nicht über einen einzigen Kanal an die CPU, sondern parallel über mehrere. Je mehr Kanäle aktiv genutzt werden, desto höher die Speicherbandbreite — und höhere Bandbreite bedeutet, dass der Buffer Pool schneller mit Daten versorgt werden kann.

DDR5-RAM im Dual-Channel-Modus liefert typischerweise 70–90 GB/s an die CPU. Im Quad-Channel-Modus sind es 140–180 GB/s. Für SQL Server unter hoher Last — viele gleichzeitige Abfragen, große scans über den Buffer Pool — ist Speicherbandbreite ein realer Engpass. Wer zwei identische Server mit 256 GB RAM vergleicht, von denen einer symmetrisch im Quad-Channel-Modus bestückt ist und der andere nur Dual-Channel nutzt, wird messbare Unterschiede bei analytischen Workloads sehen.

Die Regel ist einfach: Bestücke DIMM-Slots immer symmetrisch. Bei vier Speicherkanälen mit je zwei Slots: vier, acht oder sechzehn Module — immer in gleichmäßiger Verteilung. Asymmetrische Bestückung zwingt den Memory Controller in einen Fallback-Modus mit reduzierter Kanalnutzung. Das ist einer der häufigsten stillen Performance-Killer bei der Server-Inbetriebnahme.

2.4 NUMA und RAM-Verteilung: Symmetrie ist Pflicht

Auf einem Dual-Socket-Server hängt jeder Socket an seinen eigenen DIMM-Slots. SQL Server weiß das und teilt den Buffer Pool proportional auf die NUMA-Knoten auf: Bei 50/50-RAM-Verteilung bekommt jeder Knoten die Hälfte des Buffer Pools. Bei 75/25-Verteilung entstehen Probleme: Der kleinere Knoten kann seinen Anteil nicht ausreichend füllen, oder die Verteilung wird ineffizient, und Seiten werden auf dem falschen Knoten gehalten.

Kaufe gleich viel RAM pro Socket. Wenn ein Socket 256 GB RAM haben soll, dann beide. Nicht 192 GB auf Socket 0 und 64 GB auf Socket 1, weil "die anderen Slots für später" reserviert sind — das ist eine Konfiguration, die sofort schmerzt.

2.5 ECC-Speicher: Nicht verhandelbar

ECC steht für Error-Correcting Code. ECC-Speichermodule erkennen Einzelbit-Fehler im laufenden Betrieb und korrigieren sie — ohne Absturz, ohne Datenverlust, ohne, dass irgendjemand etwas merkt. Die Fehlerrate bei DRAM liegt bei etwa einem Bitfehler pro 4 GB RAM pro Jahr unter normalen Bedingungen. Bei einem Server mit 256 GB RAM sind das statistisch rund 64 Bit-Fehler jährlich.

Ohne ECC würde ein Bitfehler in einer SQL-Server-Datenseite im Buffer Pool zu einer stillen Datenkorruption führen. Nicht zu einem Crash, der sofort auffällt — zu einem falschen Wert in einer Tabelle, der erst bei einer Prüfung Monate später entdeckt wird. Oder gar nicht.

 

Warnung: Non-ECC in Produktionssystemen
Non-ECC-RAM in einem SQL-Server-Produktionssystem ist keine Kosteneinsparung — es ist ein nicht quantifizierbares Risiko für Datenintegrität. Consumer-Hardware (Desktop-Mainboards, Mini-PCs, "Homelab"-Server) hat oft keinen ECC-Support. Das ist einer der vielen Gründe, warum "wir betreiben das auf einem alten Desktop" keine akzeptable Lösung für Produktionsdatenbanken ist.

 

3. Storage: Das ewige Nadelöhr

Storage ist der langsamste Teil der klassischen Server-Hardware — und gleichzeitig das Subsystem, das SQL Server am häufigsten wartet. Wenn du in Kapitel 9 (Wait Statistics) die Wait-Type-Statistiken deines Servers anschaust, werden IO-bezogene Waits in den meisten Produktionssystemen unter den Top 5 auftauchen. Das Verständnis des Storage-Subsystems ist daher keine Kür — es ist Grundvoraussetzung für effektives Troubleshooting.

3.1 Der IO-Stack: Von der Abfrage bis zum Datenträger

Wenn SQL Server eine Datenseite liest, die nicht im Buffer Pool liegt, beginnt eine Reise durch mehrere Schichten. Das Verständnis dieser Schichten ist wichtig, weil jede Schicht Latenz addiert und jede Schicht ein möglicher Engpass ist.

SQL Server Buffer Manager: Erkennt, dass die Seite nicht im Cache liegt — stellt eine IO-Anfrage.

Windows I/O Manager: Nimmt die Anfrage entgegen und leitet sie weiter.

Windows Cache Manager: Normalerweise ein weiterer Cache — SQL Server umgeht ihn für Data Files via FILE_FLAG_NO_BUFFERING.

File System (NTFS): Übersetzt Datei-Offsets in physische Cluster-Adressen auf dem Volume.

Volume Manager / Storage Spaces: Verteilt IO auf RAID-Stripes oder Storage-Pools.

Storage Driver / HBA: Kommuniziert mit dem physischen Controller über PCIe, SAS oder SATA.

Physisches Medium: HDD-Magnetscheibe, SATA-SSD, NVMe — hier liegt schließlich das Bit.

 

Abb. 1.2: Der IO-Stack von SQL Server bis zum physischen Medium

Zwei wichtige Aspekte dieses Stacks: Erstens umgeht SQL Server den Windows Cache Manager für Data Files und Log Files. Er schreibt direkt durch (Bypass-IO). Das ist gewollt — SQL Server verwaltet seinen eigenen Cache (Buffer Pool) und will keine doppelte Pufferung. Zweitens ist das Transaction Log besonders latenz-sensitiv: Jeder COMMIT muss warten, bis der Log-Record physisch auf dem Datenträger liegt (das sogenannte Write-Ahead Logging). Hohe Log-Schreib-Latenz bedeutet direkt höhere Transaktionslatenz für den Endnutzer.

3.2 HDD: Ehrwürdig, langsam, manchmal noch sinnvoll

Festplatten haben rotierende Magnetscheiben. Der Lesekopf muss mechanisch zur richtigen Spur fahren (Seek Time: 5–12 ms) und dann warten, bis sich der gesuchte Sektor unter dem Kopf befindet (Rotationslatenz: bei 7.200 RPM durchschnittlich 4,2 ms, maximal 8,3 ms). Bei 15.000 RPM halbiert sich die Rotationslatenz — was aber die Seek Time nicht wesentlich verbessert.

Die Gesamtlatenz für einen Random-Read auf einer 7.200-RPM-HDD beträgt typischerweise 8–15 ms, bei einer 15.000-RPM-HDD 4–8 ms. Das klingt schnell — bis man sich überlegt, dass SQL Server bei einem normalen OLTP-Workload tausende solcher IO-Operationen pro Sekunde benötigt.

Das fundamentale Problem: SQL Server arbeitet mit Random IO auf 8-KB-Seiten. HDDs sind mechanisch für sequentielle Zugriffe optimiert. Bei sequentiellem Lesen kann eine moderne HDD 150–200 MB/s erreichen. Bei Random-4K-IO sind es oft nur 0,5–2 MB/s — eine Reduzierung um Faktor 100. Das ist keine Schwäche der HDD-Implementierung, das ist Physik.

Wann HDDs heute noch sinnvoll sind: Als Backup-Target (sequentielle Writes, große Blöcke), für kalte Archivdaten (selten gelesen, nie geschrieben) und als Teil von gestuften Storage-Lösungen. Für Produktionsdatenbanken, TempDB oder Transaction Logs gilt hingegen seit dem Preisverfall von SSDs: Finger weg.

3.3 SSD: Die Revolution, die zur Normalität wurde

Solid-State Drives haben keine beweglichen Teile. Seek Time entfällt vollständig. Latenz entsteht nur durch Controller-Overhead, Flash-Speicher-Lese- und Schreiboperationen sowie Queue-Verarbeitungszeit.

SATA SSDs liefern Random-Read-Latenzen von 0,05 bis 0,5 ms — Faktor 20 bis 100 gegenüber HDDs. Die sequentielle Bandbreite liegt bei 450–600 MB/s, begrenzt durch das SATA-Interface. IOPS-Werte von 50.000 bis 100.000 bei 4-KB-Random-Reads sind typisch.

Wichtig für den Produktionseinsatz: Enterprise-SSDs, nicht Consumer-SSDs. Die Unterschiede sind erheblich. Enterprise-SSDs sind für 3 bis 10 Drive Writes Per Day (DWPD) ausgelegt — also für ein drei- bis zehnfaches des Fassungsvermögens pro Tag an geschriebenen Daten. Consumer-SSDs kommen auf 0,3 bis 1 DWPD. Ein 1-TB-Laufwerk im Consumer-Segment ist für 300 GB bis 1 TB Schreibdaten pro Tag ausgelegt. Das Transaction Log eines mittelgroßen OLTP-Systems überschreitet das in Stunden.

Dazu kommt Power Loss Protection: Enterprise-SSDs haben Kondensatoren, die sicherstellen, dass bei einem plötzlichen Stromausfall die im flüchtigen Schreib-Cache liegenden Daten noch auf den Flash-Chips gespeichert werden. Consumer-SSDs haben das meist nicht — und SQL Server verlässt sich darauf, dass ein bestätigter Write auch wirklich persistiert ist. Ohne Power Loss Protection droht bei Stromausfall Datenverlust trotz erfolgreichem COMMIT.

 

Warnung: Consumer-SSDs im Produktionssystem

Consumer-SSDs (Samsung QVO, WD Blue, Crucial BX) sind nicht für SQL-Server-Produktionslasten ausgelegt. Ihre Schreib-Endurance ist zu gering, ihnen fehlt Power Loss Protection, und ihre Latenz-Konsistenz unter Last ist schlecht. Eine Samsung 870 QVO mag 3.500 MB/s sequentiell schaffen — aber unter sustained Random-Write-Last bricht sie auf 200 MB/s ein und bleibt dort. Für Entwickler-Laptops: vollkommen in Ordnung. Für den Produktionsserver: ein Risiko.

 

3.4 NVMe: Vollgas direkt am PCIe-Bus

NVMe (Non-Volatile Memory Express) ist kein Speichermedium — es ist ein Interface-Protokoll. NVMe-SSDs hängen direkt am PCIe-Bus, ohne den Umweg über SATA oder SAS. Das klingt wie ein technisches Detail, hat aber dramatische Auswirkungen auf Throughput und Latenz.

Der Engpass bei SATA ist das Interface-Protokoll AHCI (Advanced Host Controller Interface). AHCI wurde für HDDs entworfen und kennt genau eine Queue mit maximal 32 ausstehenden Befehlen. SAS verbessert das auf 256 Queues mit je 256 Befehlen. NVMe kennt bis zu 65.535 Queues mit je 65.535 Befehlen.

Warum ist das wichtig? SQL Server unter Last generiert hunderte gleichzeitiger IO-Anfragen — von verschiedenen Sessions, verschiedenen Threads, verschiedenen Datenbanken. SATA kann davon 32 parallel verarbeiten, den Rest muss es sequentiell abarbeiten. NVMe kann in der Praxis tausende parallele IOs effizient verwalten. Das Ergebnis: NVMe skaliert linear mit steigender IO-Last, während SATA bei hoher Concurrency an Grenzen stößt.

Typische NVMe-Performance: Random-Read-Latenz 0,02 bis 0,1 ms (20 bis 100 µs), sequentielle Bandbreite 3.000 bis 7.000 MB/s, Random-4K-IOPS 500.000 bis 1.500.000. Das ist gegenüber SATA-SSDs nochmals Faktor 3 bis 5 bei Latenz und Faktor 5 bis 15 bei IOPS.

Für TempDB und Transaction Logs ist NVMe die erste Wahl — TempDB wird in Kapitel 13 noch ausführlich behandelt, aber schon jetzt gilt: TempDB auf das schnellste verfügbare Storage. Bei NVMe-Preisen, die in den letzten Jahren stark gefallen sind, ist das für Produktionssysteme keine Frage mehr. Mehr Details zu Storage-Performance-Messung findest du in Kapitel 2 (Storage Deep Dive), zur Analyse von IO-Latenzen unter Last in Kapitel 10 (IO-Performance).

3.5 RAID: Welches Level für welchen Zweck?

RAID (Redundant Array of Independent Disks) kombiniert mehrere physische Datenträger, um Redundanz und/oder Performance zu erhöhen. Die grundlegenden RAID-Level kennen die meisten — aber die Konsequenzen für SQL Server-Workloads werden häufig falsch eingeschätzt.

 

RAID-Level	Redundanz	Read-Performance	Write-Performance	Overhead	SQL Server Empfehlung
RAID 0	Keine	Exzellent	Exzellent	0%	Nie für Produktionsdaten
RAID 1	Ja (Mirror)	Gut	Gut	50%	OS-Laufwerk, kleine Logs
RAID 5	Ja (1 Disk)	Gut	Schlecht*	33%	Nicht für schreibint. WL
RAID 6	Ja (2 Disks)	Gut	Sehr schlecht	50%	Nur Archiv/Cold Storage
RAID 10	Ja (Mirror+Str.)	Exzellent	Sehr gut	50%	Standard für DB-Daten
RAID 50	Ja (1 pro Set)	Sehr gut	Mittel*	~17%	Große Arrays, seq. WL

Tab. 1.3: RAID-Level im Vergleich (* Write-Penalty durch Paritäts-Berechnung)

 

Das Write-Penalty bei RAID 5 ist der kritische Punkt, den SQL Server-Administratoren verstehen müssen. Für jeden geschriebenen Datenblock muss der RAID-Controller folgende Operationen durchführen: Den alten Datenblock lesen, den alten Paritätsblock lesen, den neuen Paritätsblock berechnen, den neuen Datenblock schreiben und den neuen Paritätsblock schreiben. Ein logischer Write kostet also mindestens 4 physische IO-Operationen. Auf HDDs führt das zu dramatischen Performance-Einbrüchen unter Schreib-Last. Auf SSDs ist das Write-Penalty weniger ausgeprägt — aber RAID 10 bleibt trotzdem die sichere Wahl, weil der Rebuild im Fehlerfall bei RAID 5 auf Flash-Medien die verbleibenden Disks unter erhebliche Last setzt und das Risiko eines Doppelausfalls erhöht.

RAID 5 und schreibintensive Workloads sind wie Kaffee und Schlaftabletten — beides funktioniert für sich, zusammen neutralisieren sie sich bestenfalls, im schlimmsten Fall endet es in einem Supportfall. Das Transaction Log eines aktiven SQL Servers ist eine der schreibintensivsten Anwendungen überhaupt: konstante sequentielle Writes, jede Transaktion wartet auf den physischen Write. RAID 5 für das Transaction Log ist explizit nicht empfohlen — von Microsoft und von jedem DBA, der das einmal erlebt hat.

 

Tipp: Separate Volumes für Data, Log und TempDB
Verteile SQL Server-Dateien auf separate physische Volumes:
– Data Files (.mdf, .ndf): RAID 10, schnelle SSDs oder NVMe
– Transaction Log (.ldf): RAID 1 oder RAID 10, NVMe bevorzugt (latenz-kritisch)
– TempDB: NVMe, falls verfügbar auf eigenem Volume
– Backups: Separates Volume oder Netzwerkpfad, HDD akzeptabel
Die Trennung verhindert gegenseitige IO-Konkurrenz und ermöglicht gezieltes Monitoring pro Dateityp.

 

3.6 SAN, NAS und DAS: Wo liegt der Datenträger?

DAS (Direct Attached Storage) bedeutet: Der Datenträger sitzt direkt im Server oder in einem physisch angeschlossenen Shelf. Keine Netzwerkschicht, keine zusätzliche Indirektion. Das ist die einfachste und oft schnellste Konfiguration — vor allem mit lokalen NVMe-Drives, die über PCIe direkt angebunden sind.

SAN (Storage Area Network) ist ein dediziertes Speichernetzwerk, über Fibre Channel (FC) oder iSCSI angebunden. FC-SANs erreichen Latenzen von unter 0,5 ms zwischen Server und Storage — wenn sie korrekt konfiguriert sind. iSCSI teilt sich die Netzwerkinfrastruktur mit anderem Traffic und ist latenz-technisch schwieriger zu optimieren. SANs sind sinnvoll, wenn Storage-Flexibilität, dynamische Provisionierung oder Shared Storage für Cluster und AlwaysOn-Konfigurationen benötigt werden.

NAS (Network Attached Storage) bietet dateibasierten Zugriff über SMB (Server Message Block) oder NFS. Microsoft unterstützt SQL Server auf SMB 3.0-Freigaben offiziell — aber die Anforderungen an Netzwerklatenz und Zuverlässigkeit sind hoch, und die Fehlerszenarien sind komplexer als bei DAS oder SAN. Für Produktionssysteme mit hohen IOPS-Anforderungen ist NAS selten die optimale Wahl.

3.7 Konkrete Latenzzahlen: Was ist normal, was ist ein Problem?

 

Storage-Typ	Random-Read (p50)	Random-Read (p99)	Sequential Write	SQL Server Bewertung
HDD (7.200 RPM)	8–12 ms	25–50 ms	100–150 MB/s	Nicht für Produktion
HDD (15k RPM)	4–8 ms	15–30 ms	150–200 MB/s	Nur Archiv/Backup
SATA SSD	0,1–0,3 ms	0,5–2 ms	400–550 MB/s	Akzeptabel für Data
NVMe (SATA-Tier)	0,05–0,1 ms	0,2–0,5 ms	1.500–3.500 MB/s	Gut für alle Typen
NVMe (PCIe 4/5)	0,02–0,06 ms	0,1–0,3 ms	4.000–7.000 MB/s	Optimal, bes. Log+TempDB
FC-SAN (korrekt konfiguriert)	0,3–0,8 ms	1–3 ms	1.000–2.000 MB/s	Gut, aber Monitor IO-Stack

Tab. 1.4: Erwartete IO-Latenzen nach Medium und Zugriffstyp (typische Produktionswerte)

 

Als Alarmgrenzen für SQL Server Data Files und Log Files haben sich folgende Werte etabliert: Über 20 ms durchschnittliche Latenz ist ein Zeichen zum Untersuchen. Über 50 ms ist dringend zu untersuchen. Über 100 ms ist ein Notfall. Die folgende Abfrage zeigt die durchschnittlichen IO-Latenzen pro Datenbankdatei, akkumuliert seit dem letzten Neustart:

-- Durchschnittliche IO-Latenz pro Datenbankdatei seit SQL-Server-Start

-- Werte unter 20 ms sind gut, über 50 ms sofort untersuchen

SELECT

    DB_NAME(vfs.database_id)  AS Datenbank,

    mf.physical_name          AS Dateiname,

    -- Leselatenz: Gesamte Wartezeit geteilt durch Anzahl Lesevorgänge

    vfs.io_stall_read_ms  / NULLIF(vfs.num_of_reads,  0) AS Avg_Leselatenz_ms,

    -- Schreiblatenz: Besonders kritisch für das Transaction Log

    vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS Avg_Schreiblatenz_ms,

    vfs.num_of_reads          AS Lesevorgaenge,

    vfs.num_of_writes         AS Schreibvorgaenge

FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs

JOIN sys.master_files mf

    ON vfs.database_id = mf.database_id

    AND vfs.file_id    = mf.file_id

ORDER BY Avg_Schreiblatenz_ms DESC;

 

Wichtiger Hinweis zur Interpretation: Die DMV-Werte sind kumulativ seit dem letzten SQL-Server-Neustart. Wenn der Server vor einer Woche gestartet wurde und die meiste IO-Last in einem kurzen Spitzen-Zeitraum anfiel, werden die Durchschnittswerte durch die ruhigen Zeiten verwässert. Wie du IO-Latenzen zeitpunktgenau mit Baseline-Messungen in Kontext setzt, zeigt Kapitel 9 (Wait Statistics) und Kapitel 10 (IO-Performance).

Zum Vergleich: Bei Sparfuchs & Partner betrug die durchschnittliche Schreiblatenz für das Transaction Log 98 ms — mit p95-Spitzen von 312 ms. Auf einem NVMe-Laufwerk wären 0,03 ms realistisch: Faktor 10.000. Das ist kein übertriebenes Beispiel — das ist gemessene Realität, dokumentiert in Kapitel 33.

4. Netzwerk: Meistens unschuldig, manchmal schuldig

Netzwerk ist selten der primäre Engpass bei SQL Server — aber "selten" bedeutet nicht "nie". In den meisten OLTP-Systemen mit kurzen Transaktionen und kleinen Result Sets ist die NIC nicht der limitierende Faktor. In bestimmten Szenarien aber schon, und die Konfiguration der NIC-Parameter hat messbaren Einfluss auf Latenz und Durchsatz.

4.1 Wann Netzwerk zum Engpass wird

Drei Szenarien, in denen das Netzwerk zum tatsächlichen Bottleneck werden kann:

Große Result Sets: Eine Abfrage, die eine Million Zeilen mit je 500 Byte zurückgibt, erzeugt 500 MB Netzwerk-Traffic — pro Ausführung. Auf einem 1-GbE-Link mit 120 MB/s effektivem Durchsatz dauert das Transfer allein über 4 Sekunden. Das ist dann kein Datenbankproblem, das ist ein Applikationsdesign-Problem: Niemand braucht eine Million Zeilen auf einmal. Wie man Result Sets vernünftig dimensioniert, behandelt Kapitel 24 (Result-Set-Design).

AlwaysOn Availability Groups: Die Synchronisation der Log-Records zwischen Primary-Replikat und Secondary-Replikaten läuft über das Netzwerk. Bei hohem Transaktionsvolumen — mehrere hundert MB/s Log-Generierung — ist ein 1-GbE-Link schnell gesättigt. Für synchrone AlwaysOn-Konfigurationen ist 10 GbE keine Option, sondern Pflicht. Bei asynchronem Commit ist die Bandbreitenanforderung noch gleich hoch, aber die Auswirkung auf die Primary-Performance ist geringer.

Backup über das Netzwerk: Backup auf einen Netzwerk-Share bindet Netzwerkbandbreite. Eine 500-GB-Datenbank, unkomprimiert gesichert, erzeugt 500 GB Netzwerktraffic. Auf 1 GbE dauert das Transfer rund 67 Minuten — Backup-Kompression kann das auf 30 Minuten reduzieren, aber 10 GbE wäre 8-10× schneller. Für tägliche Full-Backups großer Datenbanken über Netzwerk ist Bandbreite ein Planungsfaktor.

4.2 NIC-Konfiguration für SQL Server

Windows konfiguriert NIC-Adapter mit Einstellungen, die für allgemeine Workloads ausgewogen sind — nicht für latenz-optimierte Datenbankserver. Die folgenden Einstellungen sollten auf jedem SQL-Server-Host überprüft und angepasst werden.

Receive Side Scaling (RSS): RSS verteilt eingehende Netzwerkpakete auf mehrere CPU-Kerne. Ohne RSS verarbeitet ein einzelner Kern den gesamten Netzwerk-IO-Interrupt — das wird bei hohem Durchsatz schnell zum Engpass. RSS sollte aktiviert und auf mehrere Kerne verteilt sein.

Flow Control: Diese Funktion erlaubt dem Empfänger, den Sender via Pause-Frames zu bremsen, wenn er überfordert ist. Klingt nützlich — führt in der Praxis aber zu Problemen. Pause-Frames können gesamten Traffic auf einem Switch-Port einfrieren und kaskadieren. Für SQL Server-NICs empfiehlt Microsoft, Flow Control zu deaktivieren.

Energy Efficient Ethernet (EEE): Reduziert Stromverbrauch bei niedrigem Traffic. Das führt zu Latenz-Spitzen von mehreren Millisekunden, wenn der NIC aus dem Energie-Spar-Modus aufwacht — ein in OLTP-Systemen deutlich messbarer Effekt. Deaktivieren.

Interrupt Moderation: Bündelt Netzwerk-Interrupts, um CPU-Last zu reduzieren. Erhöht dabei die Latenz. Für latenz-sensitive SQL-Server-Workloads auf "Low" stellen oder deaktivieren.

Power Management: Windows erlaubt standardmäßig, Netzwerkadapter in Energiespar-Modi zu schalten. Das kann zu Latenz-Spitzen führen. Für SQL-Server-NICs den Power-Plan auf "Höchstleistung" setzen, und in den erweiterten NIC-Eigenschaften "Allow the computer to turn off this device to save power" deaktivieren.

 

Tipp: NIC-Einstellungen prüfen und setzen (PowerShell)
# Aktuelle NIC-Einstellungen anzeigen
Get-NetAdapterAdvancedProperty -Name "Ethernet" |
Select-Object DisplayName, DisplayValue
# Flow Control deaktivieren
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
-DisplayName "Flow Control" -DisplayValue "Disabled"
# Energy Efficient Ethernet deaktivieren
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
-DisplayName "Energy Efficient Ethernet" -DisplayValue "Disabled"
# NIC-Bezeichnung ggf. anpassen — Get-NetAdapter zeigt die korrekten Namen

 

4.3 Jumbo Frames: Manchmal hilfreich, immer konfigurationsintensiv

Normale Ethernet-Frames haben eine MTU (Maximum Transmission Unit) von 1.500 Byte. Jumbo Frames erhöhen das auf 9.000 Byte. Die Idee: Weniger Frame-Overhead pro übertragene Datenmenge, höherer effektiver Durchsatz, weniger CPU-Interrupts.

Jumbo Frames helfen bei großen sequentiellen Datentransfers — Backups auf Netzwerk-Shares, ETL-Pipelines, Replikation großer Datenmengen. Der Frame-Overhead ist bei kleinen OLTP-Abfragen mit kleinen Result Sets vernachlässigbar — der Vorteil bleibt aus.

Was du beachten musst: Jumbo Frames müssen end-to-end aktiviert sein. Client-NIC, Switch-Port, Server-NIC, und jeder Hop dazwischen müssen MTU 9000 unterstützen und konfiguriert haben. Wenn nur eine Seite Jumbo Frames sendet, fragmentieren die Pakete — das ist langsamer als normale 1500-Byte-Frames. Konfiguriere Jumbo Frames nur, wenn du weißt, dass deine gesamte Netzwerkinfrastruktur es unterstützt, und teste es danach mit iperf oder ähnlichen Tools.

 

Hinweis: Netzwerk-Baseline mit iperf3
Bevor du Netzwerk als Ursache ausschließt oder identifizierst: Miss die Netzwerkbandbreite zwischen SQL-Server und Client oder zwischen Replikaten mit iperf3.
# Auf dem Zielserver (Empfänger):
iperf3 -s
# Auf dem Quellserver (Sender):
iperf3 -c <Ziel-IP> -t 30 -P 4
Ein gesunder 10-GbE-Link sollte ~9,5 Gbit/s erreichen. Deutlich darunter deutet auf Konfigurationsprobleme, Kabelprobleme oder Switch-Engpässe hin.

 

5. Hardware-Sizing: Was wirklich gebraucht wird

Hardware-Sizing für SQL Server ist kein exaktes Handwerk — es ist eine informierte Schätzung, die durch Monitoring und Kapazitätsplanung laufend verfeinert wird. Trotzdem gibt es vernünftige Ausgangspunkte, die die meisten mittleren Produktionssysteme abdecken.

5.1 Die Entscheidungsmatrix

 

Workload	Physische Kerne	RAM	Data Storage	Log Storage	Netzwerk
OLTP klein (< 50 GB, < 50 aktive User)	8 Kerne ≥ 3 GHz	32–64 GB	SSD RAID10 2×500 GB	NVMe RAID1 2×250 GB	1–10 GbE
OLTP mittel (< 500 GB, < 200 aktive User)	16 Kerne 2,8 GHz	128–256 GB	NVMe RAID10 4×1 TB	NVMe RAID1 2×500 GB	10 GbE
OLTP groß (< 2 TB, > 200 aktive User)	24–32 Kerne 2,5 GHz	256–512 GB	NVMe RAID10 6×2 TB	NVMe RAID10 4×1 TB	2×10 GbE
OLAP/DWH (mehrere TB)	32+ Kerne (Kernzahl priorisieren)	512+ GB	NVMe RAID10 große Kapazität	NVMe RAID1 2×500 GB	10–25 GbE
AlwaysOn AG (HA-Konfiguration)	Wie Primary, gleiche Kerne	Wie Primary	Wie Primary	NVMe RAID1, beste Latenz	2×10 GbE (dediziert AG)

Tab. 1.5: Hardware-Sizing-Matrix nach Workload-Typ (Ausgangspunkte, kein Ersatz für Lastmessung)

 

5.2 Die häufigsten Anti-Patterns

Ein paar Konfigurationen, die in freier Wildbahn häufig anzutreffen sind und die du vermeiden solltest:

RAID 5 für das Transaction Log: Das Write-Penalty trifft genau die IO-Operationen, die SQL Server nicht warten lassen kann.

Priority Boost aktiviert: Eine SQL-Server-Einstellung, die seit SQL Server 2008 als deprecated gilt und trotzdem in vielen Installationen aktiv ist. Sie gibt SQL Server OS-Priorität und kann das gesamte System destabilisieren. Kapitel 5 zeigt, wie du das schnell findest und deaktivierst.

max server memory nicht gesetzt: SQL Server nimmt sich was er kriegen kann — und Windows hungert.

Windows Power Plan auf "Balanced": Senkt CPU-Takt unter Last, führt zu messbaren Latenz-Spitzen. Immer "Höchstleistung" setzen.

Data, Log und TempDB auf demselben Volume: Alle IO-Typen konkurrieren miteinander. Separate Volumes sind Pflicht.

Non-ECC RAM in Produktionssystemen: Kein weiterer Kommentar nötig.

Consumer-SSDs statt Enterprise-SSDs: Endurance, Power Loss Protection, Latenz-Konsistenz — alles schlechter.

MAXDOP auf die Anzahl der logischen Prozessoren gesetzt: Führt zu unkontrolliertem Parallelismus. Kapitel 5 zeigt die richtige Berechnung.

Asymmetrische RAM-Bestückung auf NUMA-Servern: NUMA-Knoten-Imbalances als Dauergeräusch im Monitoring.

 

Praxisbeispiel: Der Sparfuchs-Klassiker: Alle Anti-Patterns auf einmal
Sparfuchs & Partner Steuerberatungs GmbH, Instanz BUCHSQL01, hat es geschafft, fast alle genannten Anti-Patterns gleichzeitig zu aktivieren: 4 vCPUs, 8 GB RAM (max server memory = 8192), eine einzige Spindel für OS + TempDB + Data + Log + Backup, Priority Boost = 1, MAXDOP = 0, Kompatibilitätslevel 110 auf SQL Server 2019, und ein Transaktionslog von 183 GB bei 24 GB Datenbankgröße — weil in sechs Jahren nie ein Log-Backup gemacht wurde.
Das ist kein erfundenes Horrorszenario für dieses Buch. Das ist ein real existierendes System, das in Kapitel 33 vollständig analysiert wird.

 

Zusammenfassung

Die Hardware ist die Grundlage, auf der jede Performance-Analyse und jede Optimierungsmaßnahme aufbaut. Wer hier nicht genau hinschaut, löst Symptome statt Ursachen.

Bei der CPU ist die wichtigste Erkenntnis: Kerne und Takt haben unterschiedliche Bedeutung für unterschiedliche Workloads. OLTP profitiert von hohem Takt, analytische Workloads von vielen Kernen. NUMA ist eine Architekturgegebenheit, kein Problem — solange die Konfiguration symmetrisch ist und SQL Server NUMA-aware arbeiten kann. Hyperthreading hilft in der Regel, erfordert aber eine korrekte MAXDOP-Konfiguration. Und die Lizenzkalkulation gehört zwingend in die Hardware-Entscheidung.

RAM ist die wichtigste einzelne Ressource für SQL Server. Der Buffer Pool entscheidet, wie viele physische IO-Operationen vermieden werden können. Die Größe des Working Sets ist der entscheidende Parameter für die RAM-Dimensionierung — nicht die Gesamtgröße der Datenbank. ECC ist keine Option, DIMM-Bestückung muss symmetrisch sein, und max server memory muss immer explizit gesetzt werden.

Storage ist dort, wo die meisten Performance-Probleme ihren Ursprung haben. NVMe ist für TempDB und Transaction Log die erste Wahl, RAID 10 der Standard für Produktionsdaten, und RAID 5 für schreibintensive Workloads ein Anti-Pattern. Die konkreten Latenzzahlen aus Tabelle 1.4 sind die Referenz für die erste Einschätzung, ob ein Storage-Problem vorliegt. Die DMV sys.dm_io_virtual_file_stats liefert die Messwerte direkt aus SQL Server.

Netzwerk ist selten der primäre Engpass, aber die NIC-Konfiguration (RSS, Flow Control, Power Management) hat messbaren Einfluss. 10 GbE ist für AlwaysOn-Konfigurationen Pflicht, für Standard-OLTP-Deployments ein sinnvoller Standard.

Die Hardware-Sizing-Matrix in Tabelle 1.5 ist ein Ausgangspunkt, kein Ersatz für Messung. Kein Hardware-Sizing ist dauerhaft korrekt — es muss regelmäßig mit aktuellen Monitoring-Daten abgeglichen werden. Wie du Baseline-Messungen systematisch aufbaust und pflegst, zeigt Kapitel 9 (Wait Statistics) und Kapitel 31 (Analyse-Methodik).

 

Ausblick auf Kapitel 2

Kapitel 2 (Storage Deep Dive) führt den Storage-Strang dieses Kapitels weiter und geht erheblich tiefer. Wir messen IO-Performance mit DiskSpd, unterscheiden zwischen sequentiellem und zufälligem IO, betrachten den Windows IO-Stack unter dem Mikroskop und schauen uns an, wie SAN-Konfigurationen die tatsächlich gemessene Latenz beeinflussen. Außerdem: Autogrowth-Events, Instant File Initialization und warum 847 Autogrowth-Events in 120 Minuten à 1 MB ein ernstes Konfigurationsproblem sind — Spoiler: Sparfuchs war wieder dabei.

 

Kapitel 2