Glossar:

Fachbegriffe, Abkürzungen und SQL Server Jargon von A bis Z

Dieses Glossar fasst die wichtigsten Fachbegriffe des Buchs kompakt zusammen. Die Definitionen sind bewusst knapp gehalten — keine Romane, sondern präzise Einzeiler mit einem kurzen Kontext. Wer tiefer einsteigen will, findet bei jedem Eintrag einen Verweis auf das entsprechende Kapitel. Ein Glossar ersetzt kein Kapitel — aber es rettet dich um 23 Uhr, wenn der Begriff schon wieder aus dem Gedächtnis gerutscht ist.

Die Sortierung ist alphabetisch nach Begriff. Abkürzungen erscheinen zusätzlich unter ihrem ausgeschriebenen Namen. Querverweise im Format "(→ Kap. X)" zeigen, wo der Begriff ausführlich behandelt wird.

 

ACID

Atomicity, Consistency, Isolation, Durability — die vier Garantien einer Transaktion. Atomicity: alles oder nichts. Consistency: die Datenbank bleibt in einem gültigen Zustand. Isolation: gleichzeitige Transaktionen sehen sich nicht gegenseitig in die Karten. Durability: einmal committet, bleibt committet — auch nach einem Absturz. SQL Server erfüllt alle vier Garantien, allerdings ist "Isolation" je nach gewähltem Isolation Level mehr oder weniger stark. (→ Kap. 27)

Ascending Key Problem

Ein häufiges Statistikproblem bei monoton wachsenden Schlüsseln wie IDENTITY oder DATETIME-Spalten: Die Statistik kennt nur die Werte, die beim letzten Update vorlagen. Neuere, größere Werte erscheinen im Histogramm nicht — der Cardinality Estimator schätzt die Anzahl neuer Zeilen daher hoffnungslos falsch. Ergebnis: suboptimale Ausführungspläne für Abfragen auf aktuellen Daten. (→ Kap. 16)

AlwaysOn Availability Groups

SQL Servers Hochverfügbarkeitslösung auf Datenbankebene. Primäres Replikat nimmt Schreibzugriffe entgegen, sekundäre Replikate bleiben synchronisiert und können optional für Lesezugriffe genutzt werden. Kein Shared Storage erforderlich — AlwaysOn repliziert das Transaction Log. Performance-relevant, weil Commit-Latenzen steigen, wenn das sekundäre Replikat nicht schnell genug bestätigt. (→ Band 3)

Autogrowth

Automatisches Vergrößern einer Datenbankdatei, wenn der Platz ausgeht. Klingt praktisch, ist es auch — als Sicherheitsnetz. Als Normalzustand ist Autogrowth ein Warnsignal: Die Datei wurde falsch dimensioniert, und jedes Growth-Event kostet Zeit. Bei Sparfuchs & Partner haben wir 847 Autogrowth-Events in zwei Stunden gesehen — bei 1 MB Schritten und ohne Instant File Initialization eine reinrassige IO-Katastrophe. (→ Kap. 10)

Baseline

Der dokumentierte Normalzustand eines Systems unter typischer Last. Ohne Baseline ist Performance-Analyse Rätselraten mit ernstem Gesicht. Eine Baseline beantwortet die entscheidende Frage: War dieser Wert gestern auch so? Die Baseline ist die Grundreligion dieses Buchs — kein Kapitel in Teil III kommt ohne sie aus. (→ Kap. 9, 31)

Batch Mode

Ausführungsmodus für Abfragen, bei dem SQL Server Daten in Blöcken von bis zu 900 Zeilen verarbeitet statt Zeile für Zeile (Row Mode). Batch Mode nutzt SIMD-Instruktionen und ist für analytische Workloads (viele Zeilen, wenige Spalten) dramatisch schneller — oft Faktor 5–10×. Ursprünglich nur für Columnstore-Indizes, ab SQL Server 2019 auch für Rowstore-Tabellen verfügbar (Batch Mode on Rowstore). (→ Kap. 15, 17)

Blocking

Eine Transaktion wartet auf eine Sperre, die eine andere Transaktion hält. Im Unterschied zum Deadlock wartet beim Blocking nur eine Seite — die andere Transaktion läuft weiter und gibt die Sperre irgendwann frei. Kurzes Blocking ist normal; langes Blocking (> Sekunden) ist ein Problem. (→ Kap. 14)

B-Baum (B-Tree)

Die zugrundeliegende Datenstruktur für Clustered- und Non-Clustered-Indizes in SQL Server. Ein balancierter Baum mit Root Node oben, Intermediate Nodes in der Mitte und Leaf Nodes unten. Die Leaf-Ebene eines Clustered Index enthält die tatsächlichen Datenseiten; bei Non-Clustered Indizes enthält sie Zeilenzeiger (RID für Heaps, Clustering Key für Clustered Tables). Suchoperationen traversieren den Baum von oben nach unten — O(log n) Aufwand. (→ Kap. 17, 22)

Buffer Pool

Der zentrale Speicher-Cache von SQL Server. Datenbankseiten (8 KB) werden beim ersten Zugriff von Disk in den Buffer Pool geladen und bleiben dort, solange Speicher verfügbar ist. Der LazyWriter verdrängt ältere Seiten nach LRU-Prinzip, wenn neuer Platz gebraucht wird. Je größer der Buffer Pool, desto seltener muss SQL Server auf Disk zugreifen — deswegen gilt: mehr RAM = schnellerer SQL Server, bis zu einem Sättigungspunkt. (→ Kap. 4, 11)

Cardinality Estimator (CE)

Die Komponente im Query Optimizer, die schätzt, wie viele Zeilen ein Operationsschritt produziert. Falsche Schätzungen führen zu falschen Join-Strategien, falschen Parallelisierungsentscheidungen und falschen Memory Grants. SQL Server hat zwei CE-Versionen: CE 70 (Legacy, Kompatibilitätslevel ≤ 80) und CE 120+ (ab SQL 2014). Der Unterschied ist messbar: Bei bestimmten Abfragen produziert CE 120 deutlich bessere Schätzungen, bei anderen — insbesondere bei Korrelationen zwischen Spalten — kann er schlechter sein. (→ Kap. 16)

Checkpoint

SQL Servers Mechanismus, um modifizierte Datenbankseiten (Dirty Pages) aus dem Buffer Pool auf Disk zu schreiben. Ohne regelmäßige Checkpoints würde ein Recovery nach einem Absturz ewig dauern. Der Checkpoint-Abstand wird durch die Recovery Interval-Einstellung gesteuert (Standard: 1 Minute). Indirekte Checkpoints (ab SQL 2012 Standard) schreiben kontinuierlich im Hintergrund statt in einem großen Schwall. (→ Kap. 4, 10)

Clustered Index

Ein Index, der die Datenseiten der Tabelle physisch nach dem Index-Key sortiert. Pro Tabelle ist maximal ein Clustered Index möglich, denn die Daten können nur in einer Reihenfolge physisch vorliegen. Tabellen ohne Clustered Index heißen Heap. Der Clustered Key wird in alle Non-Clustered Indizes als Zeilenzeiger aufgenommen — breite Clustered Keys vergrößern also alle anderen Indizes mit. (→ Kap. 17, 22)

Connection Pool

Ein Pool bereits geöffneter Datenbankverbindungen auf Applikationsseite, die wiederverwendet werden statt bei jeder Anfrage neu aufgebaut zu werden. Verbindungsaufbau kostet Zeit (Authentifizierung, Session-Initialisierung) — Connection Pooling amortisiert diesen Aufwand. Kritisch bei ORMs: Wenn der Pool zu klein ist, stehen Threads an. Wenn er zu groß ist, überlastet er den SQL Server. (→ Kap. 30)

Cost Threshold for Parallelism

sp_configure-Einstellung, die bestimmt ab welchen geschätzten Kosten ein Abfrageplan parallelisiert wird. Standard: 5 — was de facto bedeutet: fast alles wird parallelisiert. Empfohlener Wert für OLTP: 40–50. Zu niedriger Wert → zu viel Parallelismus → CXPACKET-Waits und Scheduler-Contention. (→ Kap. 5, 15)

CTE (Common Table Expression)

Ein benannter, temporärer Ergebnissatz, der im Scope einer einzigen SQL-Anweisung existiert (WITH-Klausel). CTEs verbessern die Lesbarkeit komplexer Abfragen erheblich und ermöglichen rekursive Abfragen. Performance-Hinweis: SQL Server materialisiert CTEs nicht automatisch — eine CTE kann mehrfach ausgewertet werden, wenn sie mehrfach referenziert wird. (→ Kap. 23)

Deadlock

Zwei Transaktionen blockieren sich gegenseitig: A wartet auf eine Ressource, die B hält, und B wartet auf eine Ressource, die A hält. Keiner kommt weiter. SQL Servers Deadlock Monitor erkennt das und wählt ein Opfer (meist die kostengünstigere Transaktion), die mit Fehler 1205 zurückgerollt wird. Deadlocks sind kein Datenbankfehler, sondern ein Applikationsdesignproblem. (→ Kap. 14)

Delta Store

Ein rowstore-basierter Zwischenspeicher im Columnstore-Index für neu eingefügte Zeilen, die noch nicht in den komprimierten Columnstore verschoben wurden. Der Tuple Mover verschiebt den Delta Store in den Columnstore, sobald er ~1 Million Zeilen enthält. Kleine Delta Stores verlangsamen Columnstore-Scans, weil beide Speicher parallel durchsucht werden müssen. (→ Kap. 17)

Dirty Page

Eine Datenbankseite im Buffer Pool, die seit dem letzten Checkpoint modifiziert wurde und noch nicht auf Disk zurückgeschrieben ist. Dirty Pages sind der Preis, den SQL Server für schnelle Schreiboperationen zahlt: erst in den Speicher schreiben, später asynchron auf Disk persistieren. (→ Kap. 4, 11)

DMV (Dynamic Management View)

Systemsichten (sys.dm_*) und Systemfunktionen (sys.dm_*), die Laufzeitinformationen über SQL Server-Internals liefern. DMVs sind das wichtigste Diagnosewerkzeug des DBAs: Wait Statistics, Buffer Pool-Nutzung, Query Plan Cache, aktive Verbindungen — alles über DMVs abrufbar. Daten sind flüchtig: nach einem Neustart werden die meisten DMVs zurückgesetzt. (→ Kap. 8, 9, Anhang E)

Execution Plan (Ausführungsplan)

Die Abfolge von Operatoren, die SQL Server für die Ausführung einer Abfrage gewählt hat. Der Optimizer berechnet aus einer Menge möglicher Pläne den (angeblich) günstigsten. "Estimated Plan" zeigt den Plan vor der Ausführung, "Actual Plan" danach — mit tatsächlichen Zeilenzahlen. Abweichungen zwischen Estimated und Actual sind der erste Hinweis auf Statistikprobleme. (→ Kap. 15)

Extended Events (XE)

SQL Servers modernes, leichtgewichtiges Tracing-Framework. Ersetzt den alten SQL Trace (Profiler) und ist bei weitem ressourcenschonender. Mit XE definiert man Sessions, die bestimmte Events abfangen (z.B. sql_statement_completed, lock_acquired) und in Targets (Ring Buffer, File Target, Event Counter) schreiben. Das wichtigste Diagnosewerkzeug neben DMVs. (→ Kap. 8)

Fill Factor

Der Prozentsatz, zu dem Index-Seiten beim Rebuild befüllt werden. Fill Factor 80% bedeutet: 20% jeder Seite bleiben frei für spätere Einfügungen. Zu hoher Fill Factor → häufige Page Splits → Fragmentierung. Zu niedriger Fill Factor → verschwendeter Speicherplatz und mehr IO. Der richtige Wert hängt vom Schreibmuster ab. (→ Kap. 17)

Filtered Index

Ein Index mit einer WHERE-Bedingung, der nur eine Teilmenge der Zeilen indiziert. Ideal für Spalten mit schiefer Verteilung (z.B. Status = "Offen" bei einer Auftragstabelle mit 99% erledigten Aufträgen). Kleiner, effizienter, günstigere Wartung — aber nur nützlich, wenn Abfragen die gleiche WHERE-Bedingung verwenden. (→ Kap. 17, 22)

Fragmentation (Index-Fragmentierung)

Zustand eines Index, bei dem die logische Reihenfolge der Seiten nicht mehr der physischen Reihenfolge auf Disk entspricht. Externe Fragmentierung (Seiten außer Reihe) schadet Sequential-Scans. Interne Fragmentierung (halb leere Seiten) verschwendet Speicher. Bei Sparfuchs & Partner: 97% Fragmentierung. Mit SSD-Storage verliert externe Fragmentierung an Bedeutung — der IO-Overhead für Random Access ist minimal. (→ Kap. 17)

GAM (Global Allocation Map)

Eine spezielle Seite im SQL Server-Datenbankformat, die verfolgt welche Extents (8 aufeinanderfolgende 8-KB-Seiten) frei oder belegt sind. Bei intensiven Allokations-Workloads — typischerweise TempDB unter Volllast — kann Contention auf GAM-Seiten entstehen. Das klassische Symptom sind PAGELATCH_EX-Waits auf TempDB-Allokationsseiten. (→ Kap. 13)

Memory Grant

Speicher, den SQL Server einer Abfrage vor der Ausführung für Sortierungen und Hash-Joins reserviert. Die Größe wird basierend auf Kardinalitätsschätzungen berechnet — falsche Schätzungen führen zu überdimensionierten Grants (Speicherverschwendung) oder unterdimensionierten Grants (Spill to Disk). Beide sind schlecht. (→ Kap. 12)

Hash Join

Ein Join-Algorithmus, der eine Hash-Tabelle aus der kleineren Eingabemenge baut und dann die größere Eingabe gegen die Hash-Tabelle prüft. Gut für große Datenmengen ohne nützliche Indizes, schlecht für OLTP mit kleinen Ergebnismengen. Hash Joins benötigen Memory Grants — werden sie zu groß, spillen sie in TempDB. (→ Kap. 12, 15)

Heap

Eine Tabelle ohne Clustered Index. Zeilen werden ohne bestimmte Reihenfolge gespeichert. Heaps sind in OLTP-Szenarien selten die beste Wahl: Beim Lesen über Non-Clustered Indizes entstehen RID-Lookups (ähnlich Key Lookups), die für jede gefundene Zeile einen separaten Seitenaufruf erfordern. (→ Kap. 17, 22)

Histogramm (Statistik-Histogramm)

Die Kernkomponente einer SQL Server-Statistik. Ein Histogramm teilt die Wertebereiche einer Spalte in bis zu 200 Schritten (Steps) auf und speichert für jeden Schritt: minimaler Wert, maximaler Wert, Anzahl Zeilen (EQ_ROWS, RANGE_ROWS). Der Cardinality Estimator interpoliert aus dem Histogramm die erwartete Zeilenzahl für einen gegebenen Filterwert. (→ Kap. 16)

IFI (Instant File Initialization)

Windows-Feature, das das Nullen von neu allokierten Datenbankdateien überspringt. Ohne IFI muss SQL Server jeden neuen Datei-Bereich mit Nullen überschreiben, bevor er genutzt werden kann — bei einem 50-GB-Autogrowth-Event dauert das Minuten. Mit IFI: Millisekunden. Gilt nur für Datendateien; Transaction Logs müssen aus Sicherheitsgründen immer genullt werden. (→ Kap. 10)

Implicit Conversion

Wenn SQL Server einen Datentypvergleich durchführt und die Typen nicht übereinstimmen, konvertiert er automatisch — meistens den kleineren in den größeren Typ. Das Problem: Wenn eine indizierte Spalte konvertiert werden muss, ist der Index oft nicht mehr nutzbar (SARGability-Killer). Der häufigste Fall: VARCHAR-Spalte mit NVARCHAR-Parameter im ORM. (→ Kap. 21, 30)

In-Memory OLTP (Hekaton)

SQL Servers speicheroptimierte Engine für extreme OLTP-Workloads. Tabellen leben vollständig im RAM, Zugriffe sind latch-frei und lock-frei durch MVCC. Für geeignete Workloads (hohe Konkurrenz, kurze Transaktionen) sind Faktoren von 10–100× gegenüber disk-basierten Tabellen möglich. Einschränkungen: kein ALTER TABLE für memory-optimierte Tabellen, kein RCSI, kein Parallelismus. (→ Kap. 11)

Index Seek vs. Index Scan

Seek: SQL Server traversiert den B-Baum direkt zur gesuchten Zeile — O(log n), sehr effizient. Scan: SQL Server liest die gesamte Leaf-Ebene des Index — O(n), teuer bei großen Tabellen. Ein Scan ist nicht automatisch schlecht: Wenn eine Abfrage einen Großteil der Tabelle liest, ist ein Scan effizienter als tausend Seeks. (→ Kap. 15, 22)

Join-Typen

SQL Server kennt drei physische Join-Algorithmen: Nested Loop Join — iteriert über alle Zeilen der äußeren Eingabe und sucht für jede passende Zeilen in der inneren Eingabe; ideal für kleine Outer-Inputs mit indizierten Inner-Tables. Hash Join — baut eine Hash-Tabelle; ideal für große, nicht indizierte Inputs. Merge Join — setzt voraus, dass beide Eingaben nach dem Join-Key sortiert sind; sehr effizient, wenn die Vorsortierung vorhanden ist (z.B. über Indizes). (→ Kap. 15)

Key Lookup

Wenn ein Non-Clustered Index eine Abfrage nicht vollständig abdeckt, muss SQL Server für jede gefundene Zeile zusätzlich in der Basistabelle (Clustered Index oder Heap) nachschlagen — das ist der Key Lookup (früher: Bookmark Lookup). Jeder Key Lookup ist ein separater IO-Zugriff. Bei vielen Zeilen werden daraus Tausende von IOs. Covering Indizes lösen das Problem. (→ Kap. 15, 17, 22)

Kompatibilitätslevel

Eine Datenbankeinstellung, die bestimmt welche Version des Query Optimizers und des Cardinality Estimators für diese Datenbank aktiv ist. Kompatibilitätslevel 110 = SQL 2012-Verhalten, 160 = SQL 2022-Verhalten. Sparfuchs & Partner lief auf Kompatibilitätslevel 110 auf SQL Server 2019 — damit verzichtet man freiwillig auf 7 Jahre Optimizer-Verbesserungen. (→ Kap. 6, 16)

LazyWriter

Ein SQL Server-Hintergrundprozess, der den Buffer Pool verwaltet: Er überwacht den freien Speicher und schreibt Dirty Pages auf Disk, wenn der Pool knapp wird. Der LazyWriter reagiert auf Speicherdruck — wenn er häufig arbeiten muss, ist das ein Symptom für zu wenig RAM oder zu hohen max server memory. (→ Kap. 11)

Lock Escalation

SQL Servers Mechanismus, um Row Locks oder Page Locks zu einem Table Lock zu eskalieren, wenn eine Transaktion zu viele feingranuläre Sperren hält. Standardschwelle: 5.000 Row Locks auf einer Tabelle. Lock Escalation kann Blocking verursachen, weil ein Table Lock viele gleichzeitige Operationen blockiert. (→ Kap. 14, 28)

Logical Reads

Die Anzahl der 8-KB-Seiten, die eine Abfrage aus dem Buffer Pool gelesen hat — unabhängig davon, ob die Seite vom Disk kam oder bereits gecacht war. Logical Reads sind die primäre Kennzahl für die Effizienz einer Abfrage: weniger Logical Reads = effizienter. SET STATISTICS IO ON zeigt sie pro Abfrage. (→ Kap. 15)

LPIM (Lock Pages in Memory)

Windows-Recht, das SQL Server erlaubt, Buffer Pool-Seiten im physischen RAM zu sperren und damit vor dem Windows Virtual Memory Manager zu schützen. Ohne LPIM kann Windows den SQL Server-Speicher auslagern (pagen) — mit fatalen Performance-Folgen. Empfehlung: auf NUMA-Systemen und bei physischer Hardware immer aktivieren. (→ Kap. 3, 11)

MAXDOP (Max Degree of Parallelism)

sp_configure-Einstellung, die die maximale Anzahl CPU-Kerne für parallele Abfrageausführung begrenzt. Standard: 0 (alle Kerne). Empfehlung: 8 auf großen Systemen, NUMA-Node-Größe auf NUMA-Systemen. Ein falscher MAXDOP-Wert ist einer der häufigsten Konfigurationsfehler überhaupt. (→ Kap. 1, 3, 5, 15)

max server memory

Die wichtigste sp_configure-Einstellung. Begrenzt, wie viel RAM der Buffer Pool maximal belegen darf. Standard: 2.147.483.647 MB (also unbegrenzt) — was bedeutet, dass SQL Server im Zweifelsfall das gesamte System-RAM aufbraucht. Empfehlung: Mindestens 4 GB für das OS reservieren. Sparfuchs & Partner hatte max server memory = 8.192 MB bei 8 GB physischem RAM — rechne selbst. (→ Kap. 5, 11)

Memory Clerk

Interne Komponente, die Speicher aus dem SQL Server-Adressraum für einen bestimmten Zweck verwaltet (z.B. Buffer Pool, Plan Cache, Connection Memory). DMV sys.dm_os_memory_clerks zeigt alle Memory Clerks mit aktuellem Speicherverbrauch. Nützlich, wenn unklar ist, welche Komponente den Speicher aufbraucht. (→ Kap. 11)

Non-Clustered Index

Ein Index, der eine eigene B-Baum-Struktur mit Zeigern auf die Datenseiten anlegt, ohne die Datenseiten selbst zu bewegen. Pro Tabelle sind bis zu 999 Non-Clustered Indizes möglich — was nicht heißt, dass das sinnvoll wäre. Jeder Index kostet bei INSERT/UPDATE/DELETE. Die Kunst liegt im Finden der richtigen Balance. (→ Kap. 17, 22)

NUMA (Non-Uniform Memory Access)

Speicherarchitektur für Multi-CPU-Systeme: Jeder CPU-Socket hat lokalen RAM (schnell, ~50–70 ns) und kann auf den RAM anderer Sockets zugreifen (langsam, ~100–150 ns). SQL Server ist NUMA-aware und versucht, Buffer Pool und Threads auf dem gleichen NUMA-Knoten zu halten. Falsch konfiguriertes MAXDOP kann NUMA-Grenzen überschreiten und Remote-Memory-Zugriffe erzwingen. (→ Kap. 1, 3, 4, 11)

N+1 Problem

Ein klassisches ORM-Antipattern: Statt eines einzigen Joins werden N+1 Einzelabfragen abgesetzt (eine für die Hauptliste, eine für jede Zeile darin). Bei 1.000 Zeilen entstehen 1.001 Datenbankaufrufe statt einem. Bei Trendforge Digital haben wir das im industriellen Maßstab gesehen. (→ Kap. 30)

OLTP (Online Transaction Processing)

Workload-Charakteristik: viele kurze, konkurrierende Transaktionen, meist auf kleinen Datenmengen. Im Gegensatz zu OLAP (analytische Abfragen auf großen Datenmengen). SQL Server ist für OLTP optimiert; analytische Workloads profitieren von Columnstore-Indizes und Batch Mode. (→ Kap. 4, 17)

ORM (Object-Relational Mapper)

Framework, das Datenbankzugriffe in objektorientiertem Code abstrahiert (z.B. Entity Framework, Hibernate, Dapper). ORMs erhöhen die Entwicklerproduktivität, können aber katastrophale SQL erzeugen — besonders bei Lazy Loading, N+1 und fehlenden Indizes für die generierten Abfragen. Der DBA schaut dann zu und weint. (→ Kap. 30)

Page (Datenbankseite)

Die kleinste IO-Einheit in SQL Server: 8 KB groß, immer. Jede Datenbankdatei besteht aus Pages. Acht aufeinanderfolgende Pages bilden einen Extent (64 KB). Der Buffer Pool cacht Seiten. Alle IO-Operationen arbeiten auf Seitenebene — auch, wenn man nur eine Zeile liest, wird die gesamte 8-KB-Seite geladen. (→ Kap. 4)

Parameter Sniffing

SQL Servers Mechanismus, beim ersten Kompilieren einer Stored Procedure die übergebenen Parameterwerte zu "sniffen" und den Plan dafür zu optimieren. Problem: Wenn der erste Aufruf einen untypischen Wert hat (z.B. kleines Ergebnis für einen Index Seek optimiert), wird der gecachte Plan für spätere Aufrufe mit großen Ergebnissen katastrophal langsam. (→ Kap. 18, 26)

PFS (Page Free Space)

Allokationsseite, die für jede Datenseite im Datenbankfile vermerkt, wie voll diese ist (in 5-Stufen-Granularität: 0%, 1–50%, 51–80%, 81–95%, 96–100%). Wird bei INSERT-Operationen konsultiert. Contention auf PFS-Seiten ist das klassische TempDB-Problem bei vielen parallelen Sessions. (→ Kap. 13)

PLE (Page Life Expectancy)

Wie lange eine Seite im Durchschnitt im Buffer Pool verbleibt, bevor sie verdrängt wird — gemessen in Sekunden. Grobe Faustregel: PLE sollte über 300 liegen. Besser: Baseline erheben und Abweichungen beobachten. Ein PLE-Einbruch ist oft das erste sichtbare Symptom von Speicherdruck. (→ Kap. 9, 11)

Plan Cache

SQL Servers Cache für kompilierte Ausführungspläne. Ein gecachter Plan wird wiederverwendet, wenn die gleiche Abfrage erneut ausgeführt wird — Kompilierung kostet CPU. Zu viele Ad-hoc-Abfragen (unterschiedliche Parameterwerte in SQL-Text) fluten den Cache, verbrauchen Speicher und erzeugen hohe Kompilierungsrate. Optimize for Ad Hoc Workloads ist die Standard-Gegenmaßnahme. (→ Kap. 18)

Query Store

Seit SQL Server 2016: persistente Speicherung von Ausführungsplänen und Performance-Metriken in der Datenbank selbst. Mit Query Store kann man Plan-Regressionen nach Updates erkennen und einen älteren, besseren Plan erzwingen (Forced Plans) — ohne Code-Änderungen. Automatic Plan Correction (ab SQL 2017) tut das sogar automatisch. (→ Kap. 19)

RCSI (Read Committed Snapshot Isolation)

Eine Datenbankeinstellung, die das Standard-Isolation-Level READ COMMITTED so umschreibt, dass Lesezugriffe nicht mehr durch Schreibsperren blockiert werden. Stattdessen lesen sie die letzte committete Version einer Zeile aus dem Row Version Store (in TempDB). Führt zu drastisch weniger Blocking, erhöht aber TempDB-Last. (→ Kap. 14, 27, 29)

Resource Governor

SQL Server-Feature zur Ressourcensteuerung: Workloads können in Pools und Workload Groups eingeteilt werden, mit Limits für CPU-Zeit, Memory Grants und IO. Nützlich um Reporting-Abfragen vom OLTP-Betrieb zu isolieren. (→ Kap. 12)

Row Versioning

Mechanismus, der alte Zeilenversionen in TempDB speichert, um Lesern eine konsistente Sicht auf den Datenbankzustand zu geben, ohne Schreiber zu blockieren. Wird von RCSI und Snapshot Isolation genutzt. Kostet TempDB-Platz proportional zur Menge der gleichzeitigen Schreibtransaktionen. (→ Kap. 29)

SARGability

Search ARGument Able — die Eigenschaft eines Filterausdrucks, Indizes nutzen zu können. Ein SARGable Ausdruck erlaubt dem Optimizer einen Index Seek; ein Non-SARGable erzwingt einen Scan. Klassische SARGability-Killer: Funktionen auf indizierten Spalten, Implizite Konvertierungen, LIKE mit führendem Wildcard. (→ Kap. 21)

Scalar UDF (Scalar User Defined Function)

Eine T-SQL-Funktion, die einen einzelnen Wert zurückgibt. Klingt harmlos, ist es nicht: Scalar UDFs werden pro Zeile aufgerufen, verhindern Parallelismus, sind für den Optimizer eine Black Box und können kein Inlining nutzen (außer mit INLINE = ON ab SQL 2019). Bei Sparfuchs & Partner wurde fn_GetSteuersatz 360.000-mal pro Query aufgerufen. (→ Kap. 26)

Signal Wait vs. Resource Wait

Die fundamentale Unterscheidung in der Wait Statistics-Analyse: Ein Resource Wait wartet auf eine externe Ressource (Disk, Speicher, Sperre). Ein Signal Wait wartet darauf, dass ein Thread auf dem CPU-Scheduler eingeplant wird, obwohl die Ressource bereits verfügbar ist. Hohe Signal Waits zeigen CPU-Sättigung an — zu viele Threads, zu wenig Kerne. (→ Kap. 9)

Snapshot Isolation

Isolation Level, bei dem Transaktionen eine konsistente Sicht auf den Datenbankzustand zum Transaktionsbeginn erhalten. Im Gegensatz zu RCSI (Snapshot zum Statement-Beginn) gilt der Snapshot bei Snapshot Isolation für die gesamte Transaktion. Ermöglicht Optimistic Concurrency — Schreibkonflikte werden bei Commit gemeldet. (→ Kap. 27, 29)

SQLOS

SQL Server Operating System — der interne Scheduler, der SQL Server-Threads auf Windows-Threads abbildet. SQLOS implementiert kooperatives Multitasking: Threads geben die CPU freiwillig ab (SOS_SCHEDULER_YIELD). SQLOS ist auch für Memory Management, IO-Completion-Ports und NUMA-Awareness zuständig. (→ Kap. 4, 9)

TempDB

Die Systemdatenbank für temporäre Objekte: #temp-Tabellen, @Tabellenvariablen, Spool-Operationen, Row Version Store, Hash-Join- und Sort-Spills. TempDB ist ein globaler Engpass — alle Datenbanken teilen sich eine TempDB. Best Practice: TempDB auf einem schnellen dedizierten Volume, mehrere Datendateien (eine pro logischem Core, max. 8). (→ Kap. 12, 13, 29)

Trace Flag

Globale oder Session-Schalter, die undokumentiertes oder nicht-Standard-Verhalten von SQL Server aktivieren. Trace Flags sind ursprünglich Debugging-Werkzeuge — manche sind aber zu legitimen Konfigurationsoptionen geworden (z.B. TF 1117, 1118 für TempDB-Allokation, in SQL 2016 als Standard übernommen). Nie ohne Testphase aktivieren. (→ Kap. 13)

Transaction Log (Transaktionsprotokoll)

Jede Änderung an einer SQL Server-Datenbank wird zuerst im Transaction Log protokolliert, bevor sie auf die Datenseiten geschrieben wird (Write-Ahead Logging). Das Log ist entscheidend für ACID-Garantien und Recovery. Ein aufgeblähtes Log (wie das 183-GB-Log bei Sparfuchs & Partner bei 24 GB Datenbank) zeigt typischerweise fehlende Log-Backups oder lang laufende Transaktionen. (→ Kap. 6, 10)

TVP (Table-Valued Parameter)

Ein Tabellentyp, der als Parameter an Stored Procedures oder Funktionen übergeben werden kann. Nützlich um Mengen von Werten effizient an SQL Server zu übergeben, statt IN-Klauseln mit Tausenden von Werten oder WHILE-Schleifen. (→ Kap. 26)

Update Statistics

Der Vorgang, Statistiken (Histogramm + Dichtevektoren) für eine Tabelle oder einen Index zu aktualisieren. SQL Server tut das automatisch, wenn ~20% der Zeilen geändert wurden (Standard-Schwelle) — aber dieser Schwellenwert ist bei großen Tabellen zu groß. Auto_Update_Statistics_Async lässt Abfragen mit veralteten Statistiken weiterlaufen und aktualisiert im Hintergrund. (→ Kap. 6, 16)

UPDLOCK

Ein Abfrage-Hint, der SQL Server anweist, beim Lesen Update Locks statt Shared Locks zu setzen. Nützlich, um Deadlocks zu vermeiden, die durch Lock-Konvertierung (S → X) entstehen. Korrekt eingesetzt verhindert es das klassische "Read-Modify-Write"-Deadlock-Muster. (→ Kap. 14, 28)

VLF (Virtual Log File)

Das Transaction Log wird intern in Virtual Log Files aufgeteilt. Zu viele VLFs (Tausende) entstehen durch häufige kleine Autogrowth-Events und verlangsamen Datenbankstart, Backup und Recovery. Sparfuchs & Partner hatte 48.312 VLFs. Lösung: Transaction Log auf die richtige Größe vorallokieren oder mit einem einzigen großen Schritt wachsen lassen und dann DBCC SHRINKFILE mit REORGANIZE nutzen. (→ Kap. 6)

Wait Statistics

Die kumulative Aufzeichnung aller Wartezustände, in denen SQL Server-Threads Zeit verbracht haben, seit dem letzten Neustart. Wait Statistics sind der wichtigste Einstiegspunkt für Performance-Diagnose: Sie zeigen den dominanten Engpass des Systems ohne Raten oder Vermuten. Die Analyse-Methodik: Wait Types nach kumulierter Wartezeit sortieren, Idle Waits herausfiltern, verbleibende Top-5 priorisieren. (→ Kap. 9)

Write-Ahead Logging (WAL)

Das fundamentale Persistenz-Prinzip von SQL Server: Bevor eine modifizierte Datenseite auf Disk geschrieben wird, muss der zugehörige Log-Eintrag bereits persistent sein. Das garantiert, dass im Absturzfall alle Änderungen aus dem Log rekonstruiert werden können. WRITELOG-Waits zeigen, wie lange Commits auf das Transaction Log warten — hohe Werte deuten auf IO-Probleme beim Log-Volume hin. (→ Kap. 6, 10)

XE (Extended Events)

Abkürzung für Extended Events — SQL Servers modernes Tracing-Framework. Siehe Extended Events. (→ Kap. 8)

Abkürzungsverzeichnis

Die folgende Tabelle listet die im Buch verwendeten Abkürzungen alphabetisch auf.

 

Abkürzung	Ausgeschrieben	Kapitel
ACID	Atomicity, Consistency, Isolation, Durability	27
AG	Availability Group (AlwaysOn)	Band 3
CE	Cardinality Estimator	16
CTE	Common Table Expression	23
DMV	Dynamic Management View	8, 9
DOP	Degree of Parallelism	5, 15
GAM	Global Allocation Map	13
IFI	Instant File Initialization	10
IMOLTP	In-Memory OLTP (Hekaton)	11
LPIM	Lock Pages in Memory	3, 11
MAXDOP	Max Degree of Parallelism	1, 5
MDF	Master Database File (primäre Datendatei)	4
NDF	Secondary Database File (Datendatei)	4, 13
NUMA	Non-Uniform Memory Access	1, 3, 4
OLAP	Online Analytical Processing	4, 17
OLTP	Online Transaction Processing	4
ORM	Object-Relational Mapper	30
PFS	Page Free Space	13
PLE	Page Life Expectancy	9, 11
RCSI	Read Committed Snapshot Isolation	14, 27, 29
RID	Row Identifier (Heap-Zeilenzeiger)	17, 22
RPO	Recovery Point Objective	Band 3
RTO	Recovery Time Objective	Band 3
SAN	Storage Area Network	2
SGAM	Shared Global Allocation Map	13
SQL	Structured Query Language	passim
TVP	Table-Valued Parameter	26
UDF	User Defined Function	26
VLF	Virtual Log File	6
WAL	Write-Ahead Logging	6, 10
XE	Extended Events	8

Abkürzungsverzeichnis Band 1

 

 

Hinweis: Dieses Glossar wächst
Begriffe, die in Band 2 (Betrieb, Security & Plattformen) eingeführt werden, erscheinen im Glossar von Band 2. Eine bandübergreifende Begriffssuche ist über das Stichwortverzeichnis der Buchreihe möglich — das entsteht nach Abschluss aller Bände.