Aufgeräumt, aber ohne Platz

Ein grüner Haken, und die Splits gehen weiter

Zwei Indizes können nach der Wartung nahezu fragmentierungsfrei sein und sich bei den nächsten Inserts trotzdem unterschiedlich verhalten. Wir vergleichen sechs Varianten aus demselben Ausgangszustand. Entscheidend ist dabei, ob auf den Seiten Platz für die folgenden Zeilen bleibt und welche Kosten die Wartung verursacht.

Das ist Teil 2 einer Reihe. Teil 1 erklärt Seiten, Splits und Reserve mit Bildern statt Messwerten; wer dort Bild 8 kennt, sieht hier dasselbe in Zahlen. Teil 3 fragt, was ein Index tut, wenn niemand ihn wartet.

Der Aufbau

Eine Tabelle mit einem GUID als Clustering-Key und 200 Byte Nutzdaten. Die Schlüssel stammen aus einer reproduzierbaren, breit verteilten Hashfolge: Neue Zeilen treffen also zufällig verteilte Stellen im bestehenden Schlüsselbereich. Wir bauen eine Million Zeilen mit Fillfactor 81 auf und fügen dann 100.000 Zeilen einzeln ein. Danach ist der Index zu 16,69 % fragmentiert. Diesen Zustand sichern wir.

Jede Wartungsvariante beginnt mit genau diesem Backup:

Danach folgen weitere 100.000 Einzelinserts, für jede Variante dieselben Schlüssel in derselben Reihenfolge. Jeder Vergleich läuft dreimal in wechselnder Reihenfolge, auf SQL Server 2022 und 2025 in eigenen Containern. Gemessen ist ein synthetischer Einzelindex unter serieller Last, keine produktive Benutzerlatenz.

Was wir zählen

Was REORGANIZE und REBUILD mit der Reserve machen

Fillfactor 81 heißt: Beim Aufbau bleiben auf den Blattseiten rund 19 % frei. Weil nur ganze Zeilen auf eine Seite passen, liegt die gemessene Dichte nach dem Aufbau bei 83,4 %, nicht exakt bei 81 %. Diese Reserve nimmt später Zeilen auf, die mitten in den Schlüsselbereich der Seite fallen. Ist sie aufgebraucht, muss SQL Server die Seite teilen.

Nach 100.000 zufällig verteilten Inserts sieht der Index uneinheitlich aus. Manche Seiten wurden gerade geteilt und sind halb leer. Andere haben ihre Reserve aufgebraucht und sind voll bis an den Rand.

Schematisch

Schematischer Vergleich mit gleicher Gesamtreserve

REORGANIZE arbeitet auf den vorhandenen Blattseiten. Es bringt sie in die richtige Reihenfolge und schiebt Zeilen von wenig gefüllten Seiten zusammen, höchstens bis zum Fillfactor. Seiten, die schon voller sind, leert es nicht. Microsoft beschreibt genau diese Grenze in der Dokumentation zu sys.dm_db_index_physical_stats.

REBUILD baut den Index neu auf und füllt die Blattseiten dabei wieder bis zum Fillfactor.

Beide Operationen senken die Fragmentierung: REORGANIZE auf 0,28 %, der Offline-REBUILD auf 0 %. Nach dem Prozentwert sind beide ein Erfolg.

Die nächsten 100.000 Inserts

Grafik 1

Nach REORGANIZE mehr als fünfmal so viele Split-Logrecords wie nach REBUILD FF81

Median aus drei Läufen, SQL 2022 und 2025 identisch. Hervorgehoben: die beiden Hauptarme.

Daten zur Grafik

Split-Logrecords und Fragmentierung nach den nächsten 100.000 Inserts je Variante

Variante	Split-Logrecords	Fragmentierung danach
REORGANIZE	14.870	58,2 %
REBUILD FF81 offline	2.632	12,8 %
Keine Wartung	15.066	69,8 %
Nur Statistiken	15.066	69,8 %
REBUILD FF81 online	2.538	12,8 %
REBUILD FF100	30.455	96,8 %

Median aus drei Läufen, SQL Server 2022; SQL Server 2025 liefert dieselben Mediane.

Nach REORGANIZE entstehen bei denselben Inserts mehr als fünfmal so viele Split-Logrecords wie nach dem REBUILD mit Reserve, also gegenüber REORGANIZE rund 82 % weniger mit dem REBUILD. Beide Engines liefern dieselben Zahlen; die Schlüsselfolge ist auf beiden gleich.

Die Kontrollarme zeigen, woran das liegt:

Ein frischer, geordneter Index ist also nicht automatisch ein guter Ausgangspunkt für die nächsten Inserts in bestehende Bereiche. Und Statistikpflege kann einen Plan verbessern, Platz auf einer Seite schafft sie nicht. Umgekehrt aktualisiert ein REBUILD auch die Statistik des Index. Wer nach einem REBUILD schnellere Abfragen sieht, sollte prüfen, welcher der beiden Effekte gewirkt hat.

Weniger Split-Logrecords heißen nicht im selben Maß schnellere Inserts. Die Insertzeit sank im Lab nach dem REBUILD gegenüber REORGANIZE um 17 bis 26 %. Das ist ein Hinweis, keine Latenzmessung: Die Zählung selbst, Commits in Gruppen von 1.000 Zeilen und Hintergrund-I/O verzerren absolute Zeiten.

Der Durchschnitt allein erklärt es nicht

Nach REORGANIZE ist der Index im Mittel sogar etwas voller als nach dem REBUILD, 85,3 % gegenüber 83,4 % Seitendichte. Der Durchschnitt allein erklärt das folgende Insertverhalten deshalb nicht. Zusätzlich zählt, auf welchen Seiten der freie Platz liegt.

Grafik 2

Volle Seiten bleiben nach REORGANIZE voll

Füllgrad aller erfassten Blattseiten nach REORGANIZE und nach REBUILD FF81 (SQL 2022, erster Lauf). Markiert: Seiten mit weniger als 225 Byte frei.

Lesehilfe: Waagerecht: Wie voll ist eine Seite? Senkrecht: Anteil der Seiten mit diesem Füllgrad.

Daten zur Grafik

Blattseiten je Zeilenzahl nach REORGANIZE und nach REBUILD FF81

Zeilen je Seite	Füllgrad	REORGANIZE Seiten	Anteil	REBUILD FF81 Seiten	Anteil
1–16	bis 44,5 %	121	0,34 %	0	0 %
17	47,2 %	1.298	3,62 %	0	0 %
18	50,0 %	468	1,31 %	0	0 %
19	52,8 %	1.605	4,48 %	0	0 %
20	55,6 %	512	1,43 %	1	0,003 %
21	58,4 %	182	0,51 %	0	0 %
22	61,1 %	101	0,28 %	0	0 %
23	63,9 %	19	0,05 %	0	0 %
24	66,7 %	84	0,23 %	0	0 %
25	69,5 %	74	0,21 %	0	0 %
26	72,3 %	61	0,17 %	0	0 %
27	75,0 %	58	0,16 %	0	0 %
28	77,8 %	65	0,18 %	0	0 %
29	80,6 %	1.392	3,89 %	0	0 %
30	83,4 %	1.888	5,27 %	36.666	99,997 %
31	86,2 %	5.032	14,05 %	0	0 %
32	88,9 %	7.164	20,00 %	0	0 %
33	91,7 %	7.080	19,76 %	0	0 %
34	94,5 %	5.318	14,85 %	0	0 %
35	97,3 %	3.301	9,21 %	0	0 %

Erfasste Blattseiten: 35.823 nach REORGANIZE, 36.667 nach REBUILD FF81. Füllgrad = (8.096 − freie Byte) / 8.096. Eine Seite fasst höchstens 35 Zeilen zu 225 Byte.

Eine neue Testzeile belegt in diesem Aufbau 223 Byte plus 2 Byte im Slot-Verzeichnis der Seite. Nach REORGANIZE haben 9,21 % der erfassten Blattseiten weniger als 225 Byte frei. Eine weitere Zeile auf einer dieser Seiten löst einen Split aus. Nach REBUILD FF81 trifft das auf keine erfasste Seite zu; nahezu alle Seiten liegen dort in derselben Füllklasse.

Gesamtmenge und Verteilung der Reserve unterscheiden sich in diesem Versuch beide. 9,21 % der Seiten sind dabei keine Splitwahrscheinlichkeit von 9,21 %: Wie oft Inserts diese Seiten treffen, hängt von der Schlüsselverteilung ab. Die Verteilung zeigt aber, warum ein guter Durchschnitt die nächste Insertlast nicht vorhersagt.

Was es kostet

Wartung kostet Log, Zeit und Verfügbarkeit. In unserem eingefrorenen Vergleich, offline, gemessen als erzeugte Logrecord-Bytes:

Grafik 3

Das Recovery-Modell verändert das Kostenverhältnis

Erzeugtes Log und Dauer je Eingriff, SIMPLE und FULL, REBUILD FF81 offline. SQL 2022, Median aus drei Läufen.

Unter SIMPLE wird der Offline-REBUILD minimal protokolliert, unter FULL nicht. Der Satz „REORGANIZE schreibt immer Größenordnungen mehr Log“ stimmt deshalb nicht allgemein. Gemessen haben wir die Summe der erzeugten Logrecords, nicht die Größe der Logdatei oder des Logbackups. Andere Betriebsbedingungen, etwa ein Online-REBUILD (im selben Vergleich 34 MiB), können das Verhältnis stark verändern.

Auch die Verfügbarkeit gehört zur Entscheidung. Ein Offline-REBUILD kann den Zugriff auf die Tabelle für die Dauer der Operation blockieren; auch ein Online-REBUILD hat kurze Sperrphasen (Microsoft: How online index operations work). REORGANIZE läuft online, belastet das System aber ebenfalls. Unter gleichzeitigen Schreibzugriffen haben wir das hier nicht vermessen.

Microsoft empfiehlt REORGANIZE grundsätzlich wegen des geringeren Ressourcenbedarfs und verlangt zugleich, Nutzen und Kosten an der tatsächlichen Arbeitslast zu prüfen (Index maintenance strategy). Unser Fall widerspricht dem nicht. Er zeigt ein Ziel, nämlich neue Reserve für Inserts in bestehende Bereiche, das REORGANIZE nicht erreicht.

Was wir daraus ableiten

Für den untersuchten Fall wiederholter Inserts in bestehende Schlüsselbereiche ist ein REBUILD mit Reserve ein wirksamer Prüfkandidat. REORGANIZE hat hier die logische Fragmentierung reduziert, die Reserve auf vollen Seiten jedoch nicht erneuert. Der beobachtete Unterschied entspricht der von Jeff Moden gezeigten Gegenprobe, jetzt auf zwei aktuellen Versionen.

Ob eine dieser Wirkungen den Eingriff rechtfertigt, hängt vom Ziel und der Last ab. Indizes mit aufsteigenden Schlüsseln, selten geänderte Tabellen oder überwiegend gelesene Indizes haben andere Bedürfnisse, und Reserve kostet Seiten, die Scans anfassen müssen. Eine bessere Dichte für Lesezugriffe kann ebenfalls ein legitimes Wartungsziel sein.

Unser Vorschlag für die Reihe:

Ein Fragmentierungswert nach dem Job beantwortet keinen dieser drei Punkte.

Ausblick Teil 3: Was passiert ganz ohne Wartung? Wir haben zwei Indizes ohne jeden Eingriff auf über drei Millionen Zeilen wachsen lassen. Wo sich die Seitendichte stabilisiert und warum die Split-Logrecords trotzdem weiterlaufen, folgt in Teil 3.

Grenzen der Messung

• Synthetische Daten, ein Clustered Index ohne Nebenindizes, feste Zeilenbreite, keine Deletes, keine Kompression, keine LOBs, keine Partitionen.
• Serielle Last, MAXDOP 1, keine gleichzeitigen Schreiber; Sperrwirkung von Online- und Offline-REBUILD nicht gemessen.
• Linux-Container auf einer Lab-VM, Daten, Log und TempDB auf derselben SATA-SSD. SQL Server 2022 (16.0.4295.3) und 2025 (17.0.5005.3), Developer Edition.
• Auto-Statistiken, Query Store und ADR im Versuch abgeschaltet.
• Wartungsvergleich: drei Wiederholungen je Variante, Median. Die 60-Tage-Reihen sind je eine deterministische Trajektorie ohne Streuungsangabe; sie sind keine unabhängigen Workloads.
• Die Seitenverteilung (Grafik 2) stammt aus dem ersten Lauf auf SQL 2022, nicht aus einem Median.
• Logmengen: Summe der Logrecord-Längen nach einer LSN-Grenze, nicht Logdatei- oder Logbackupgröße.
• Geprüft am 05.10.2026. Die Versuchsbedingungen sind dokumentiert; zu einem öffentlichen Reproduktionspaket informieren wir gesondert.

Weiterlesen

• PSG: Teil 1 · Platz für die nächste Zeile
• PSG: Teil 3 · Wenn der Index ohne Wartung wächst
• Jeff Moden: „Black Arts“ Index Maintenance #1
• Brent Ozar: You've Heard of Page Splits. Here's What They Really Mean.
• Microsoft: Optimize index maintenance to improve query performance and reduce resource consumption