Virtualisierung:

Wenn SQL Server nicht weiß, dass er nicht allein ist

SQL Server in der VM: Was sich ändert, was gleich bleibt

Vor zehn Jahren war "SQL Server auf einer VM" noch ein Diskussionsthema. Heute ist es Standard. 80 % aller neuen SQL-Server-Deployments laufen virtualisiert — auf VMware vSphere, Microsoft Hyper-V oder zunehmend auf Kubernetes. Das bringt echte Vorteile: einfache Skalierung, Snapshot-Möglichkeiten, bessere Ressourcenauslastung.

Aber Virtualisierung bringt auch eine eigene Klasse von Performance-Problemen. Probleme, die sich anders manifestieren als klassische Hardware-Probleme — und die ohne Kenntnisse des Hypervisor-Stacks fast unmöglich zu diagnostizieren sind. Memory Ballooning, CPU Ready Time, vNUMA-Misconfiguration: Alles Begriffe, die auf einem Physical-Server keine Rolle spielen und auf einer VM existenziell sind.

In diesem Kapitel schauen wir uns an, was Virtualisierung mit SQL Server macht, welche Einstellungen kritisch sind, und welche Probleme man typischerweise antrifft. NUMA-Grundlagen (die auch für VMs gelten) haben wir in Kapitel 1 erarbeitet — dieses Kapitel baut darauf auf. Die Auswirkungen auf Memory-Management werden wir in Kapitel 11 vertiefen, MAXDOP-Konfiguration in Kapitel 5.

VMware vSphere und SQL Server: Das dominante Gespann

VMware vSphere (ESXi als Hypervisor, vCenter als Management) ist die führende Virtualisierungsplattform im Enterprise-Umfeld. Für SQL Server gibt es eine Reihe von VMware-spezifischen Konzepten, die man verstehen muss.

 

Abb. 3.2: Hypervisor-Stack: SQL Server in der virtualisierten Welt (VMware und Hyper-V)

vCPUs und pCPUs: Das Mapping-Problem

Eine virtuelle CPU (vCPU) ist keine physische CPU (pCPU). Der Hypervisor mappt vCPUs auf verfügbare physische Kerne — aber nicht immer deterministisch. Eine VM mit 8 vCPUs auf einem Host mit 40 physischen Kernen hat kein Problem. Eine VM mit 8 vCPUs auf einem Host, wo insgesamt 120 vCPUs auf 40 physische Kerne gemappt sind (Overcommitment-Ratio 3:1), hat ein sehr ernstes Problem.

SQL Server sieht nur die vCPUs — es weiß nicht, dass dahinter physische Kerne stehen, die mit anderen VMs geteilt werden. Wenn SQL Server alle seine Worker-Threads gleichzeitig laufen lassen will, aber die physischen Kerne gerade mit anderen VM-Workloads beschäftigt sind, entsteht Wartezeit. Diese Wartezeit nennt sich CPU Ready Time — und ist eine der häufigsten und am schwersten erkennbaren Performance-Ursachen in virtualisierten Umgebungen.

PVSCSI statt LSI Logic

VMware bietet mehrere virtuelle Storage-Controller-Typen. Der Standard für neue VMs ist oft noch LSI Logic SAS — ein Emulations-Controller, der reale Hardware nachahmt. Für SQL Server sollte immer PVSCSI (Paravirtual SCSI) verwendet werden: Dieser Controller ist für Virtualisierung optimiert, hat deutlich höheren Durchsatz (bis zu 2× mehr IOPS in IO-intensiven Szenarien) und niedrigere CPU-Last auf dem Hypervisor. Der Wechsel von LSI Logic auf PVSCSI ist in wenigen Minuten erledigt — aber bei bestehenden VMs braucht man ein Wartungsfenster.

 

Tipp: VMware-Storage-Controller prüfen
vCenter aufrufen, VM-Einstellungen → "Add/Edit" → unter Disk-Controller den Typ prüfen. Falls "LSI Logic SAS" oder "LSI Logic Parallel": Auf PVSCSI migrieren. Das erfordert: VM herunterfahren, Controller-Typ ändern, ggf. Treiber in Windows aktualisieren, VM starten. Zeitaufwand: 15–30 Minuten. Performance-Gewinn: 10–30 % mehr IOPS in IO-intensiven Szenarien.

 

Microsoft Hyper-V: Der Heimvorteil mit Tücken

Hyper-V ist Microsofts eigener Typ-1-Hypervisor, der direkt im Windows Server integriert ist (und in Windows 10/11 für Workstations). Der "Heimvorteil" von Hyper-V für SQL Server: Beide Produkte kommen aus Redmond, die Integration ist tief, und Hyper-V enthält sogenannte "Enlightened I/O" — eine direkte Kommunikation zwischen Guest OS und Hypervisor ohne vollständige Hardware-Emulation. Das reduziert den Overhead.

Trotzdem hat Hyper-V seine eigenen Tücken. Die wichtigsten: Dynamic Memory, NUMA Spanning, und die Versuchung, VM-Snapshots auf Produktionssystemen zu verwenden.

Synthetische Treiber vs. Emulierte Hardware

Hyper-V unterscheidet zwischen emulierten Geräten (langsam, für Kompatibilität) und synthetischen Geräten (schnell, über Hyper-V Integration Services). Für SQL Server müssen immer synthetische Treiber aktiv sein: Hyper-V Integration Services installieren und aktuell halten. Ein Symptom veralteter oder fehlender Integration Services: ungewöhnlich hohe Hypervisor-CPU-Last bei IO-Operationen.

 

Plattform	Empfohlener Storage-Treiber	Netzwerk	IO-Overhead (geschätzt)
VMware vSphere	PVSCSI (Paravirtual SCSI)	VMXNET3	< 5 % vs. bare metal
Hyper-V	Synthetischer SCSI (via VSP/VSC)	Synthetisch (via VSP/VSC)	< 5 % vs. bare metal
KVM/QEMU	VirtIO-SCSI	VirtIO-Net	< 5 % (mit VirtIO)
Hyper-V (emuliert)	IDE-Controller (Legacy!)	Legacy Network	20–40 % Overhead

Tabelle 3.1: Virtuelle Treiber-Typen und ihr Overhead

 

Das vNUMA-Problem: Wenn der Hypervisor NUMA versteckt

NUMA (Non-Uniform Memory Access) haben wir in Kapitel 1 kennengelernt: In Multi-Socket-Systemen hat jeder CPU-Socket seinen eigenen lokalen Speicher. Zugriff auf "eigenen" RAM ist schnell (~60 ns), Zugriff auf "fremden" RAM ist langsam (~120 ns). SQL Server ist seit SQL Server 2005 NUMA-aware: Es versucht, Speicher und Worker-Threads NUMA-lokal zuzuordnen.

 

Abb. 3.1: vNUMA-Mapping: Korrekte NUMA-Exposition vs. versteckte NUMA-Strafe

Das Problem in VMs: Ein physischer Server mit 2 CPU-Sockets hat 2 NUMA-Nodes. Wenn der Hypervisor diese Topologie nicht an die VM weitergibt, sieht SQL Server nur einen einzigen großen "NUMA-Node" — auch, wenn die physischen Speicherzugriffe intern über QPI/UPI gehen und damit die doppelte Latenz haben. SQL Server trifft dann nicht-optimale Entscheidungen bei der Speicherzuordnung, ohne es zu wissen.

vNUMA in VMware konfigurieren

VMware hat das vNUMA-Verhalten im Lauf der ESXi-Versionen mehrfach geändert. Aktuelle Faustregel (ESXi 6.7+): Eine VM, die mehr vCPUs hat als ein einzelner NUMA-Node (also mehr als die Anzahl physischer Kerne pro Socket), bekommt automatisch vNUMA — sofern die Option "Expose NUMA topology to guest OS" aktiviert ist. Diese Option sollte für alle SQL Server-VMs explizit aktiviert sein.

-- NUMA-Konfiguration in SQL Server prüfen

-- Zeigt wie viele NUMA-Nodes SQL Server sieht.

-- Sollte auf einem 2-Socket-Server mit vNUMA "2" ergeben.

SELECT

    node_id,

    memory_node_id,

    processor_count,

    online_scheduler_count,

    memory_object_address

FROM   sys.dm_os_nodes

WHERE  node_state_desc <> N'ONLINE DAC';

 

-- Wenn nur 1 Node erscheint auf einem physisch 2-Socket-Server:

-- vNUMA ist nicht konfiguriert! Sofort prüfen und aktivieren.

 

-- Ausführlichere NUMA-Memory-Verteilung

SELECT

    node_id,

    CAST(virtual_address_space_reserved_kb / 1024.0 AS DECIMAL(10,1)) AS Reserviert_MB,

    CAST(locked_page_allocations_kb / 1024.0 AS DECIMAL(10,1))        AS LPIM_MB,

    processor_count

FROM   sys.dm_os_memory_nodes

ORDER BY node_id;

vNUMA in Hyper-V

Hyper-V hat eine ähnliche Funktionalität. Wichtig: Die Einstellung "NUMA Spanning" sollte für SQL Server-VMs deaktiviert sein. NUMA Spanning erlaubt es Hyper-V, einer VM Speicher aus mehreren NUMA-Nodes zuzuweisen — was praktisch klingt, aber zu den gleichen versteckten Remote-Speicherzugriffen führt. Besser: Eine VM pro NUMA-Node, und die VM-Größe an die NUMA-Topologie anpassen.

 

Hintergrund: Soft vs. Hard NUMA

SQL Server bietet zusätzlich "Soft NUMA": Eine manuelle NUMA-Partitionierung, bei der der DBA definiert, welche logischen Prozessoren zu einem NUMA-Node gehören. Das ist ein Workaround, wenn der Hypervisor keine korrekte vNUMA-Information liefert — aber es ist kein vollständiger Ersatz für echte NUMA-Awareness auf Hardware-Ebene. Soft NUMA konfiguriert man über ALTER SERVER CONFIGURATION SET SOFTNUMA ON|OFF.

 

Memory Ballooning: Eine toxische Beziehung

Memory Ballooning ist eine Technik, die Hypervisoren verwenden, um Speicher dynamisch zwischen VMs umzuverteilen. Die Idee: Ein "Balloon-Treiber" im Guest OS reserviert Speicher (bläst den Ballon auf), und der Hypervisor kann diesen Speicher dann anderen VMs zur Verfügung stellen. Wenn der Gast mehr Speicher braucht, gibt der Balloon-Treiber den Speicher wieder frei (Ballon geht runter).

Für die meisten Workloads ist das akzeptabel. Für SQL Server ist es eine Katastrophe.

Warum? SQL Server reserviert beim Start seinen gesamten konfigurierten Max Server Memory im Buffer Pool. Es ist sehr sorgfältig darin, diesen Speicher zu verwalten — und es erwartet, dass der reservierte Speicher auch tatsächlich verfügbar ist. Wenn der Balloon-Treiber beginnt, Speicher zurückzunehmen, muss SQL Server seinen Buffer Pool verkleinern — er wirft gecachte Datenbankseiten raus, die beim nächsten Zugriff wieder von der Platte gelesen werden müssen. Das Ergebnis: PAGEIOLATCH-Waits explodieren, IO-Last steigt, Performance bricht ein.

 

Warnung: Memory Ballooning für SQL Server-VMs deaktivieren

VMware: Speicher-Reservation auf 100% setzen (Reservierung = VM-Arbeitsspeicher). Das verhindert, dass ESXi den Speicher via Ballooning zurücknimmt. Kosten: Der Speicher ist physisch reserviert und steht anderen VMs nicht zur Verfügung. Das ist der gewünschte Zustand für Produktionsdatenbanken. Hyper-V: "Dynamic Memory" für SQL Server-VMs komplett deaktivieren. Startup RAM = Maximum RAM = der gewünschte Wert. Kein Spielraum für Hyper-V.

 

Memory Overcommitment erkennen

Wie erkennt man, ob Ballooning aktiv ist? VMware bietet im vCenter unter "VM Performance" die Metriken "balloon" (Balloon-Größe in KB) und "swap" (VMware-Swap, noch schlimmer). Werte über 0 sind ein Warnsignal. Werte in GB sind ein Notfall.

-- SQL Server-seitige Diagnose: Buffer Pool unter Druck?

-- Wenn Page Life Expectancy stark schwankt oder PLE unter 300 fällt,

-- kann Memory Ballooning die Ursache sein.

SELECT

    object_name,

    counter_name,

    cntr_value

FROM   sys.dm_os_performance_counters

WHERE  counter_name IN (

    'Page life expectancy',          -- PLE: unter 300 = kritisch

    'Memory Grants Pending',          -- Wartende Grants: über 0 = Druck

    'Target Server Memory (KB)',      -- Was SQL Server haben möchte

    'Total Server Memory (KB)'        -- Was SQL Server tatsächlich hat

)

AND    object_name LIKE '%Memory Manager%';

 

-- Wenn "Total Server Memory" weit unter "Target Server Memory" liegt:

-- SQL Server bekommt nicht den konfigurierten Speicher — Ballooning-Verdacht!

CPU Ready Time: Die unsichtbare Latenz

CPU Ready Time ist die Zeit, die eine vCPU warten muss, bis sie einen physischen Prozessorkern bekommt. Die vCPU ist bereit zu rechnen — aber der physische Kern ist gerade mit einer anderen vCPU beschäftigt. Das klingt nach einem kleinen Detail. Es ist es nicht.

Aus SQL Server-Sicht sieht das folgendermaßen aus: Ein Worker-Thread wird eingeplant (ist "runnable"), wartet aber auf Scheduling. Das registriert SQL Server als Signal Wait (mehr dazu in Kapitel 9 — Wait Statistics). Hohe Signal Waits auf einer VM deuten fast immer auf CPU Overcommitment hin.

 

CPU Ready Time (%)	Bedeutung	Maßnahme
0–2 %	Normal — kein Problem	Keine
2–5 %	Grenzwertig — beobachten	Host-Auslastung prüfen
5–10 %	Problem — messbar spürbar	vCPUs reduzieren oder VM migrieren
> 10 %	Kritisch — erhebliche Performance-Einbußen	Sofortmaßnahmen: Live-Migration, VM-Aufstockung, Host-Entlastung

Tabelle 3.2: CPU Ready Time — Interpretation und Maßnahmen

 

CPU Ready Time wird in vCenter als Prozent-Wert angezeigt (Metric: "cpu.ready.summation"). Die Darstellung ist manchmal verwirrend: 2000 ms CPU Ready in 20.000 ms Interval = 10 % Ready Time. Wichtig: Dieser Wert wird pro vCPU summiert — eine VM mit 8 vCPUs und 2 % Ready Time hat also effektiv 8 × 2 % = 16 % der gesamten CPU-Zeit "verloren".

 

Praxisbeispiel: CPU Ready: Der versteckte Performance-Räuber

In einem realen Projekt: Ein SQL Server mit "stabiler" Performance auf dem Papier — 45% CPU-Auslastung, keine auffälligen Wait Types. Aber Nutzer meldeten sporadische Hänger. Nach Blick auf vCenter: CPU Ready Time 8–12 %. Die VM teilte sich den Host mit 15 anderen VMs. Beim nächsten "Hänger" waren alle VMs unter Last. SQL Server's Worker-Threads warteten im Durchschnitt 80 ms auf CPU-Zeit, die SQL Server selbst als Signal Wait registrierte. Lösung: VM auf einen weniger ausgelasteten Host migriert. Problem verschwunden.

 

MAXDOP auf VMs: Die Formel anpassen

MAXDOP (Maximum Degree of Parallelism) steuert, wie viele Prozessoren SQL Server für eine einzelne parallele Abfrage verwenden darf. Die Grundlagen von MAXDOP haben wir in Kapitel 1 behandelt — auf VMs gelten zusätzliche Überlegungen.

Die Standard-Empfehlung für MAXDOP lautet: Nicht mehr als 8, und nicht mehr als die Anzahl logischer Prozessoren pro NUMA-Node. Auf einer VM kommen zwei Faktoren hinzu:

vCPU-Anzahl: Weniger ist oft mehr. Eine VM mit 32 vCPUs auf einem überlasteten Host verhält sich schlechter als eine VM mit 8 vCPUs auf einem entspannten Host.

NUMA-Topologie: Wenn die VM vNUMA korrekt konfiguriert hat, gilt die gleiche Regel wie auf physischer Hardware: MAXDOP = Kerne pro NUMA-Node.

CPU Overcommitment: Bei hoher Ready Time sollte MAXDOP eher niedrig sein — parallele Abfragen benötigen mehrere vCPUs gleichzeitig, was das Overcommitment verschlimmert.

-- MAXDOP-Konfiguration prüfen und setzen

-- Für eine VM mit 8 vCPUs und 1 vNUMA-Node: MAXDOP = 4 (halbe Kernzahl als Richtwert)

-- Für eine VM mit 16 vCPUs und 2 vNUMA-Nodes: MAXDOP = 8 (Kerne pro Node)

 

-- Aktuelle MAXDOP-Einstellung anzeigen

SELECT name, value, value_in_use, description

FROM   sys.configurations

WHERE  name = 'max degree of parallelism';

 

-- MAXDOP setzen (Beispiel: 4 für eine 8-vCPU-VM)

-- RECONFIGURE danach nicht vergessen!

EXEC sp_configure 'show advanced options', 1;

RECONFIGURE;

EXEC sp_configure 'max degree of parallelism', 4;

RECONFIGURE;

 

-- Cost Threshold for Parallelism ebenfalls prüfen (Kapitel 5)

-- Default 5 ist für moderne Workloads zu niedrig — 50 ist realistischer

SELECT name, value_in_use

FROM   sys.configurations

WHERE  name = 'cost threshold for parallelism';

Die genaue MAXDOP-Berechnung und die Auswirkungen auf Ausführungspläne werden in Kapitel 5 (Serverkonfiguration) und Kapitel 15 (Query Performance & Ausführungspläne) ausführlich behandelt. Dort sehen wir auch, wann Parallelismus hilft und wann er schadet.

Storage in VMs: VMDK, RDM und der IO-Overhead

Storage in VMs ist ein mehrschichtiges Thema. SQL Server sieht ein Laufwerk — dahinter steckt (in der Regel) eine virtuelle Disk-Datei auf einem VMware-Datastore oder ein Hyper-V VHDX, der auf Storage-Array-LUNs liegt. Jede Schicht kostet potenziell Latenz.

VMware: VMDK vs. RDM

VMware bietet zwei Hauptoptionen für VM-Storage:

VMDK (Virtual Machine Disk): Eine Datei auf einem VMware-Datastore. Einfach zu managen, unterstützt Snapshots. Overhead: 0,2–2 ms je nach I/O-Muster und Datastore-Typ. Für die meisten SQL-Server-Deployments ausreichend.

RDM (Raw Device Mapping): Die VM bekommt direkten Zugriff auf eine LUN im SAN. Kein VMDK-Overhead, nahezu native Latenz. Kein Snapshot-Support. Empfohlen für extrem latenz-sensitive Workloads (sub-ms) oder Windows Server Failover Cluster (WSFC) mit Shared Disks.

In der Praxis ist der VMDK-Overhead für 90 % aller SQL-Server-Workloads nicht messbar relevant. Auf einem All-Flash-Array mit NVMe-Backend und PVSCSI-Controller sind VMDK-Latenzen typischerweise unter 0,5 ms — gut genug für produktive OLTP. RDM lohnt sich dann, wenn die absolute Latenz das entscheidende Kriterium ist und die Einschränkungen (kein Snapshot) akzeptiert werden.

Hyper-V: VHDX und Pass-Through

Hyper-V's VHDX-Format ist das Pendant zu VMDK. VHDX unterstützt bis zu 64 TB, hat verbesserte Resilienz gegenüber dem älteren VHD-Format und einen ähnlich niedrigen Overhead. Pass-Through Disks (direkte LUN-Zuweisung, analog zu VMware RDM) sind für Hyper-V verfügbar, werden aber seltener eingesetzt, weil VHDX auf modernem Storage vergleichbare Latenzen erreicht.

VM-Snapshots und SQL Server: Eine toxische Kombination

VM-Snapshots sind verlockend. Ein Klick, und man hat einen "Sicherheitspunkt" vor einem riskanten Update. Für Nicht-Datenbank-VMs ist das praktisch und sinnvoll. Für SQL Server-VMs ist es eine Falle.

Das Problem: Ein VM-Snapshot friert den Zustand der virtuellen Disk ein und schreibt alle nachfolgenden Änderungen in eine separate Delta-Datei. Jeder Write-IO muss jetzt in die Delta-Datei — und je mehr Deltas sich angesammelt haben, desto länger dauert das Konsolidieren. Während ein Snapshot aktiv ist, hat jeder Write-IO einen zusätzlichen Overhead von typisch 5–20 %. Mit mehreren Snapshots kann es deutlich mehr werden.

Schlimmer: Wenn ein Snapshot gelöscht (konsolidiert) wird, schreibt der Hypervisor alle Delta-Änderungen zurück in die Basis-Disk. Dieser Prozess kann Stunden dauern und produziert massiven IO-Druck — mitten in der Produktionszeit, wenn es am unpassendsten ist.

 

Warnung: VM-Snapshots auf SQL Server-Produktionssystemen: Niemals

VM-Snapshots sind kein Backup-Ersatz für SQL Server. Sie sichern den Datenbankzustand auf Byte-Ebene — aber ein SQL Server, der gerade eine Transaktion schreibt, ist im Snapshot in einem inkonsistenten Zustand. Das macht den Snapshot für Recovery nutzlos. Wenn du Snapshots brauchst (z.B. für Patchvorgänge): Immer SQL Server vorher in den Suspend-Zustand versetzen (via VSS/Application-consistent Snapshot) oder SQL Server stoppen. Und: Snapshot sofort nach dem Patchvorgang löschen. Keine Snapshots länger als 24 Stunden.

 

Overcommitment: Wann der Hypervisor überverkauft

Overcommitment bedeutet: Der Hypervisor hat mehr virtuelle Ressourcen (vCPUs, RAM) an VMs vergeben als physische Ressourcen vorhanden sind. Für CPU ist ein gewisses Overcommitment normal und sinnvoll — nicht alle VMs rechnen gleichzeitig. Für SQL Server-RAM ist jedes Overcommitment gefährlich.

CPU-Overcommitment

Eine CPU-Overcommitment-Ratio von 2:1 (doppelt so viele vCPUs wie pCPUs) ist für gemischte Workloads oft akzeptabel. Für SQL Server-VMs unter Last sollte die Ratio idealerweise unter 1,5:1 liegen — und für hochfrequente OLTP-Systeme unter 1:1.

Wie erkennt man Overcommitment? CPU Ready Time ist das direkte Symptom auf VMware. Auf Hyper-V heißt der äquivalente Counter "Hypervisor Virtual Processor\CPU Wait Time Per Dispatch". In SQL Server selbst zeigen sich hohe Signal Waits in den Wait Statistics — der Thread ist runnable, bekommt aber keinen Scheduler. Kapitel 9 erklärt, wie man Signal Waits von Resource Waits unterscheidet und was beides bedeutet.

RAM-Overcommitment

RAM-Overcommitment für SQL Server-VMs: Null Toleranz. Jede MB, die der Hypervisor via Ballooning oder Swap zurücknimmt, landet als zusätzlicher IO auf dem Storage. VMware hat dafür einen noch schlimmeren Mechanismus als Ballooning: VM-Swap (vmem-Datei). Wenn eine VM nicht genug physischen RAM bekommt, swappt der Hypervisor VM-Speicher auf Disk — und die Performance bricht im Keller durch den Boden.

-- Speicherdruck in SQL Server erkennen

-- "Memory Grants Pending" über 0 bedeutet: Abfragen warten auf Arbeitsspeicher.

-- "Page life expectancy" unter 300 Sekunden: Buffer Pool zu klein oder unter Druck.

SELECT

    counter_name,

    cntr_value AS Wert,

    CASE counter_name

        WHEN 'Page life expectancy'    THEN CASE WHEN cntr_value < 300 THEN 'KRITISCH' WHEN cntr_value < 1000 THEN 'Grenzwertig' ELSE 'OK' END

        WHEN 'Memory Grants Pending'   THEN CASE WHEN cntr_value > 0 THEN 'PROBLEM' ELSE 'OK' END

        ELSE '---'

    END AS Bewertung

FROM   sys.dm_os_performance_counters

WHERE  counter_name IN (

    'Page life expectancy',

    'Memory Grants Pending',

    'Total Server Memory (KB)',

    'Target Server Memory (KB)'

)

AND    object_name LIKE '%Memory Manager%'

ORDER BY counter_name;

Best Practices Checkliste: SQL Server in der VM

VMware vSphere

 

Einstellung	Empfehlung	Priorität
Storage-Controller	PVSCSI (Paravirtual SCSI)	Hoch
Netzwerk-Adapter	VMXNET3	Hoch
Memory Reservation	100% (= VM-Arbeitsspeicher)	Kritisch
Memory Ballooning	Deaktivieren via Reservation	Kritisch
vNUMA	Expose NUMA topology aktivieren	Hoch
VM-Snapshots	Nie auf Produktions-SQL-VMs	Kritisch
CPU Ready Target	< 5 %, besser < 2 %	Hoch
VMware Tools	Immer aktuell halten	Mittel
NUMA Spanning	VM-Größe an NUMA-Topologie anpassen	Hoch
Huge Pages	Transparent Page Sharing deaktivieren für SQL-VMs	Mittel

Tabelle 3.3: VMware vSphere — Empfohlene Einstellungen für SQL Server-VMs

 

Microsoft Hyper-V

 

Einstellung	Empfehlung	Priorität
Integration Services	Immer installiert und aktuell	Kritisch
Dynamic Memory	Deaktivieren für SQL Server-VMs	Kritisch
NUMA Spanning	Deaktivieren — eine VM pro NUMA-Node	Hoch
VM-Generation	Generation 2 (UEFI, synthetische Geräte)	Hoch
VHDX-Speicher	Auf dediziertem CSV oder Storage Space	Hoch
VM-Snapshots	Nie auf Produktions-SQL-VMs (oder Application-consistent)	Kritisch
SR-IOV (Netzwerk)	Bei hohem Netzwerk-Throughput erwägen	Niedrig
VM-Prozessoren	Nur so viele vCPUs wie tatsächlich genutzt	Mittel

Tabelle 3.4: Microsoft Hyper-V — Empfohlene Einstellungen für SQL Server-VMs

 

Diagnose: Virtualisierungsbedingte Performance-Probleme

Symptome

 

Hinweis: Symptome eines Virtualisierungsproblems

Folgende Symptome deuten auf Virtualisierungs-bedingte Ursachen hin: • Sporadische Latenzspitzen ohne erkennbare SQL-seitige Ursache • Hohe Signal Waits in den Wait Statistics (SOS_SCHEDULER_YIELD, THREADPOOL) — Signal Waits = der Thread wartet auf CPU-Zeit, nicht auf IO oder Locks • SQL Server PLE (Page Life Expectancy) schwankt stark, obwohl kein Speicher-intensiver Workload läuft — deutet auf Memory Ballooning hin • Backup-Zeiten erhöhen sich ohne Änderung der Datenbankgröße — Snapshot-Delta-Overhead? • Performance-Probleme treten auf, wenn andere VMs auf demselben Host aktiv sind — Overcommitment

 

So misst du das

 

Hinweis: Virtualisierungs-Diagnose: Drei Ebenen

Ebene 1 — SQL Server (Signal Waits): SELECT wait_type, waiting_tasks_count, wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_type IN ('SOS_SCHEDULER_YIELD', 'THREADPOOL', 'SLEEP_TASK') ORDER BY wait_time_ms DESC; Ebene 2 — Hypervisor-Metriken (VMware vCenter): VM → Überwachen → Leistung → CPU: "cpu.ready.summation" (> 2000 ms/20s = > 10% = Problem) VM → Überwachen → Leistung → Speicher: "mem.balloon" und "mem.vmmemctl" (> 0 = Ballooning aktiv) Ebene 3 — Windows Performance Monitor in der VM: "Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch" (Hyper-V) "Memory\Available MBytes" (sollte nie unter 1 GB fallen für einen SQL Server)

 

Typische Fehlinterpretationen

 

Warnung: Fehlinterpretationen bei VM-Diagnose

1. "Hohe CPU-Auslastung in der VM = SQL Server-Problem" — Möglicherweise. Aber auch möglicherweise CPU Overcommitment auf dem Host. Erst vCenter checken. 2. "SQL Server braucht mehr vCPUs" — Nicht immer. Mehr vCPUs auf einem überlasteten Host verschlimmern das Overcommitment. Manchmal sind weniger vCPUs besser. 3. "Snapshots für Backup nutzen" — Crash-konsistente Snapshots sind kein SQL-Backup. SQL Server in einem Snapshot kann in einem inkonsistenten Zustand sein. Immer VSS-aware Backup-Lösung oder SQL Server-eigenes Backup nutzen. 4. "Dynamic Memory spart Kosten" — Stimmt, aber auf Kosten von SQL Server-Stabilität. Der gesparte RAM wird woanders gebraucht — und SQL Server zahlt mit IO-Druck.

 

Erste Gegenmaßnahmen

 

Tipp: Sofortmaßnahmen bei VM-Performance-Problemen

1. CPU Ready Time prüfen (VMware): vCenter → VM → Überwachen → Leistung → CPU. Bei > 5 %: VM auf anderen Host migrieren (Live-Migration). 2. Memory Ballooning prüfen: vCenter → VM → mem.balloon. Bei > 0: Memory Reservation erhöhen. 3. SQL Server PLE beobachten: Wenn PLE unter 300 fällt ohne offensichtliche SQL-Ursache, ist Speicherdruck von außen verdächtig. 4. Snapshots prüfen: Gibt es aktive Snapshots auf der VM? vCenter → VM → Snapshots. Wenn ja: Konsolidieren nach Backup-Fenster. 5. Signal Waits in SQL Server: SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'SOS%' oder LIKE 'THREAD%' — hohe Signal Waits bei niedrigen Resource Waits deutet auf CPU-Druck.

 

Zusammenfassung

Virtualisierung ist die Normalität für SQL Server-Deployments. Sie bringt echte Vorteile — aber auch eine eigene Klasse von Performance-Problemen, die ohne Hypervisor-Kenntnisse unsichtbar bleiben. Die wichtigsten Erkenntnisse:

Memory Ballooning ist für SQL Server-VMs gefährlich: Memory Reservation auf 100% (VMware) oder Dynamic Memory deaktivieren (Hyper-V).

CPU Ready Time über 5 % ist ein Problem: Die VM bekommt nicht genug physische CPU-Zeit. Overcommitment auf dem Host reduzieren oder VM migrieren.

vNUMA muss korrekt konfiguriert sein: SQL Server muss die physische NUMA-Topologie sehen, sonst trifft es nicht-optimale Speicher-Entscheidungen.

VM-Snapshots auf SQL Server-Produktionssystemen: Nie ohne Application-consistent Snapshot. Niemals als Backup-Ersatz.

PVSCSI (VMware) und synthetische Treiber (Hyper-V) sind Pflicht — keine emulierten Controller für SQL Server.

MAXDOP auf VMs: vNUMA-Topologie berücksichtigen und CPU-Overcommitment bei der Konfiguration einkalkulieren.

Signal Waits in SQL Server sind der Indikator für CPU-Druck auf dem Hypervisor — Signal Wait ≠ SQL-Problem.

Zusammengefasst: Virtualisierung bedeutet, dass man zwei Systeme im Blick behalten muss — SQL Server und den Hypervisor. Probleme auf einer Ebene manifestieren sich auf der anderen. Der DBA muss die Hypervisor-Sprache sprechen und der VMware-Admin muss verstehen, was SQL Server von seiner Infrastruktur erwartet. Das ist Teamarbeit.

Im nächsten Kapitel — Kapitel 4, SQL Server Architektur & Internals — steigen wir in SQL Server selbst ein: Buffer Pool, Storage Engine, Query Processor. Das Fundament, auf dem alle Performance-Diagnose aufbaut. Die Hardware-Ebene (Kapitel 1, 2 und dieses Kapitel) ist ab jetzt der Referenzrahmen — alles, was SQL Server tut, passiert auf dieser Infrastruktur.

 

Kapitel 4