sp_configure Referenz:
Standardwerte, Empfehlungen und die Verbotsliste
sp_configure ist das zentrale Werkzeug zur Serverkonfiguration in SQL Server. Fast jede relevante Performance-Einstellung läuft über diesen Befehl — von der Speicherzuweisung über den Parallelismus bis hin zu Features, die du lieber heute als morgen deaktivieren solltest. Dieser Anhang ist die Schnellreferenz: Welcher Wert ist der Standard, was sollte er sein, und welche Einstellungen sind schlicht verboten.
Grundprinzip: sp_configure zeigt und setzt Konfigurationswerte auf Serverebene. Nach einer Änderung ist in der Regel RECONFIGURE nötig, damit die Einstellung wirksam wird. Für einige besonders kritische (oder gefährliche) Einstellungen verlangt SQL Server stattdessen RECONFIGURE WITH OVERRIDE — ein explizites "Ja, ich weiß was ich tue". Das ist kein optionaler Zusatz, sondern ein Sicherheitsventil: Wenn RECONFIGURE allein nicht funktioniert, überlege nochmal ob du wirklich sicher bist.
-- Alle konfigurierbaren Einstellungen anzeigen
EXEC sp_configure;
-- "Erweiterte Optionen" sichtbar machen (nötig für viele Einstellungen)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- Einen Wert setzen und aktivieren
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;
-- Für gefährliche Einstellungen: explizite Bestätigung erforderlich
EXEC sp_configure 'priority boost', 0;
RECONFIGURE WITH OVERRIDE;
Wichtig: Viele Einstellungen sind erst sichtbar, wenn "show advanced options" auf 1 gesetzt ist. Ohne diesen Schritt liefert sp_configure nur eine Handvoll Basiseinstellungen — und du fragst dich, warum du max degree of parallelism nicht siehst.
Referenztabelle: Alle Performance-relevanten Einstellungen
Die folgende Tabelle listet alle Einstellungen, die direkt oder indirekt Performance-Auswirkungen haben. Kursiv gesetzte Empfehlungen bedeuten: Der richtige Wert hängt von der Umgebung ab — die Faustformel steht in der Anmerkungsspalte.
|
Einstellung |
Standard |
Empfehlung |
Einheit |
Kapitel |
Anmerkung |
|---|---|---|---|---|---|
|
max server memory (MB) |
2147483647 |
RAM − OS-Reserve |
MB |
5, 11 |
Bei 32 GB RAM: ca. 28.672 MB. OS braucht mindestens 2–4 GB. |
|
min server memory (MB) |
0 |
0 |
MB |
5 |
Auf 0 lassen — SQL Server skaliert selbst hoch. |
|
max degree of parallelism |
0 |
≤ 8, ≤ NUMA-Kerne |
Kerne |
1, 5 |
Nie 0 auf NUMA-Systemen. Faustregel: Hälfte der NUMA-Kerne, max. 8. |
|
cost threshold for parallelism |
5 |
50 |
Kosten-Einheit |
5, 15 |
Standard 5 ist viel zu niedrig — führt zu unnötigem Parallelismus bei trivialen Abfragen. |
|
optimize for ad hoc workloads |
0 |
1 |
0/1 |
5, 18 |
Spart Plan-Cache-Speicher bei vielen Einmal-Abfragen. Immer aktivieren. |
|
priority boost |
0 |
0 — NIEMALS 1! |
0/1 |
5 |
Seit SQL 2008 deprecated. Verursacht Instabilität. Absolutes Tabu. |
|
lightweight pooling |
0 |
0 — NIEMALS 1! |
0/1 |
5 |
Fiber Mode bringt keine Vorteile, verursacht aber schwer zu debuggende Probleme. |
|
max worker threads |
0 |
0 (auto) |
Threads |
5 |
Automatisch ist korrekt. Manuell setzen nur auf Anweisung von Microsoft Support. |
|
blocked process threshold (s) |
0 |
5 |
Sekunden |
5, 14 |
Aktiviert das Blocked Process Report-Event. Ohne diesen Wert bekommst du keine Blocking-Alarme. |
|
backup compression default |
0 |
1 |
0/1 |
5 |
Komprimierung spart 60–80% Backup-Größe. Kein Grund es nicht zu aktivieren. |
|
remote admin connections |
0 |
1 |
0/1 |
5 |
Ermöglicht DAC-Verbindung von remote — wichtig, wenn der Server nicht mehr reagiert. |
|
fill factor (%) |
0 |
0 (per Index) |
% |
17 |
Globaler Fill Factor ist ein stumpfes Instrument. Besser pro Index konfigurieren. |
|
index create memory (KB) |
0 |
0 (auto) |
KB |
11 |
Automatisch. Manuell setzen nur bei sehr spezifischen Problemen mit Index-Rebuilds. |
|
min memory per query (KB) |
1024 |
1024 |
KB |
12 |
Standard ist i.d.R. ausreichend. Nur erhöhen, wenn Spills durch zu kleine Grants entstehen. |
|
query wait (s) |
-1 |
-1 (auto) |
Sekunden |
12 |
Automatisch = 25× cost threshold. Manuell selten nötig. |
|
recovery interval (min) |
0 |
0 (auto) |
Minuten |
4 |
Automatisch steuert Checkpoint-Frequenz. Manuelles Setzen ist fast immer falsch. |
|
two digit year cutoff |
2049 |
2049 |
Jahr |
5 |
Interpretiert zweistellige Jahreszahlen 00–49 als 2000–2049. Standard passt. |
|
clr enabled |
0 |
je nach Bedarf |
0/1 |
5 |
Nur aktivieren, wenn CLR-Objekte tatsächlich genutzt werden. |
|
xp_cmdshell |
0 |
0 |
0/1 |
5 |
Sicherheitsrisiko. Nur bei tatsächlichem Bedarf aktivieren — und das Risiko kennen. |
|
Ole Automation Procedures |
0 |
0 |
0/1 |
5 |
Wie xp_cmdshell: deaktiviert lassen außer bei konkretem, dokumentiertem Bedarf. |
Tabelle C.1: sp_configure Einstellungen — Standard, Empfehlung und Kontext
Die Verbotsliste: Diese Einstellungen darfst du nie aktivieren
Einige sp_configure-Einstellungen sind nicht nur "normalerweise nicht empfohlen", sondern kategorisch falsch. Kein Szenario rechtfertigt ihren Einsatz in einer Produktionsumgebung — und in vielen Fällen sind sie der erste Befund, den du findest, wenn ein System seit Jahren unbemerkt schlecht konfiguriert ist. Wie bei Sparfuchs & Partner in Kapitel 33: priority boost aktiviert, Lightweight Pooling aktiviert, und niemand hatte in Jahren nachgeschaut.
|
Warnung: Verbotsliste — diese vier Einstellungen sind tabu |
|---|
|
priority boost = 1: Seit SQL Server 2008 deprecated und nicht mehr unterstützt. Erhöht den Windows-Thread-Priorität auf REALTIME, was zur Destabilisierung des Betriebssystems führen kann. Kein Performancegewinn, maximales Risiko. |
|
lightweight pooling = 1 (Fiber Mode): Fiber Mode ist ein Relikt aus den 1990er-Jahren, das auf modernen Betriebssystemen keine Vorteile bringt. Stattdessen: schwer zu debuggende Deadlocks, inkompatibel mit vielen Features. |
|
xp_cmdshell = 1 (ohne konkreten Bedarf): Öffnet eine Shell mit SQL Server-Dienstkontorechten. Wenn du keinen Prozess hast, der das aktiv nutzt, ist dieser Schalter ein offenes Fenster. |
|
Ole Automation Procedures = 1 (ohne konkreten Bedarf): Gleiche Sicherheitsklasse wie xp_cmdshell. Aktivieren nur bei dokumentiertem Bedarf mit entsprechender Risikoabwägung. |
Schnellstart: Die zehn Einstellungen die du nach jeder Installation prüfen solltest
Du hast einen neuen SQL Server — oder übernimmst einen bestehenden Server ohne Dokumentation. Diese zehn Einstellungen solltest du als erstes prüfen, bevor du anfängst den Server zu analysieren. Sie sind die Basis für alles andere.
Zusammenfassung
sp_configure ist mächtig — und gefährlich, wenn man nicht weiß was man tut. Die gute Nachricht: Die allermeisten Einstellungen funktionieren mit ihren Standardwerten ordentlich. Die schlechte Nachricht: Die wenigen Ausnahmen — max server memory, MAXDOP, cost threshold for parallelism, optimize for ad hoc workloads — werden auf vielen Servern nie angefasst, obwohl sie direkten Performance-Einfluss haben. Und die Verbotsliste ist kürzer als du denkst: priority boost und lightweight pooling müssen einfach 0 sein. Keine Diskussion.
Die vollständige Erklärung jeder dieser Einstellungen inklusive Berechnungsformeln findest du in Kapitel 5 (Serverkonfiguration) und Kapitel 11 (Memory Management). Dieser Anhang ist die Schnellreferenz zum Nachschlagen — nicht der Lehrpfad.