Index-Wartung systematisch — Rebuild, Reorganize, Statistiken

Wann reorganisieren, wann neu aufbauen? Den Fragmentierungs-Mythos entzaubern und intelligent warten statt mit dem Vorschlaghammer.

Es gibt einen Wartungsjob, den fast jeder SQL Server hat und fast keiner versteht: den nächtlichen Index-Rebuild, der stur jeden Index der Datenbank neu aufbaut, Nacht für Nacht, Stunde um Stunde. Er ist das digitale Äquivalent zu „lieber einmal zu viel als zu wenig“ — und genau wie dieser Spruch im echten Leben verursacht er mehr Schaden als Nutzen: Er treibt das Transaktionslog auf, bläst die Backups auf, blockiert bei der Offline-Variante halbe Tabellen und frisst stundenlang I/O — für einen Effekt, der auf moderner Hardware oft kaum messbar ist. Das Beste daran: Hätte man stattdessen nur die Statistiken aktualisiert, hätte man neunzig Prozent des Nutzens für ein Prozent des Aufwands bekommen.

Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) räumt mit dem Vorschlaghammer-Ansatz auf. Index-Wartung ist kein „viel hilft viel“, sondern eine Entscheidung nach Schwellenwerten: Was wird reorganisiert, was neu aufgebaut, was in Ruhe gelassen — und warum die Statistiken am Ende oft wichtiger sind als die Fragmentierung selbst. Als Beitrag der GRÜN-Stufe geht es hier nicht um einen Notfall, sondern um die ruhige, kluge Wartung, die Notfälle gar nicht erst entstehen lässt.

Fragmentierung — und warum sie überschätzt wird

Ein Index ist im Kern eine sortierte Struktur. Wenn Daten eingefügt, geändert und gelöscht werden, geraten die physischen Seiten dieser Struktur mit der Zeit in Unordnung: Es entstehen Lücken (Seiten sind nur halb gefüllt — interne Fragmentierung) und die logische Reihenfolge der Seiten weicht von ihrer physischen Anordnung ab (externe Fragmentierung). Klassischerweise galt: Je fragmentierter, desto mehr muss der Server lesen und desto mehr Sprünge muss er machen — also regelmäßig defragmentieren.

Diese Lehre stammt aus der Zeit rotierender Festplatten, bei denen ein physischer Schreib-Lese-Kopf über eine Scheibe fuhr und jeder Sprung an eine andere Stelle echte Millisekunden kostete. Auf solchen Platten war externe Fragmentierung tatsächlich teuer. Auf modernem Flash-Storage ist das anders: Eine SSD hat keinen Kopf, der irgendwohin fahren muss — der Zugriff auf Seite eine Million ist genauso schnell wie auf Seite zwei. Die externe Fragmentierung, jahrzehntelang der Schreckgespenst-Grund für nächtliche Rebuilds, ist damit weitgehend bedeutungslos geworden. Was bleibt, ist die interne Fragmentierung (halb leere Seiten kosten Cache-Platz) — und vor allem ein Nebeneffekt, der die ganze Zeit der eigentliche Hauptdarsteller war.

Dieser Hauptdarsteller sind die Statistiken. Ein Index-REBUILD aktualisiert nebenbei die Statistiken des Index mit voller Abtastung — und sehr oft ist genau das der Grund, warum „nach dem nächtlichen Rebuild alles schneller läuft“. Nicht die aufgeräumten Seiten haben geholfen, sondern die frischen Schätzgrundlagen für den Optimizer. Wer das versteht, hört auf, mit dem Vorschlaghammer Seiten umzuschichten, und fängt an, gezielt zu warten: Statistiken pflegen immer, Indizes nur dann anfassen, wenn es sich lohnt. Der Zusammenhang zwischen Statistiken und Plänen ist so wichtig, dass er einen eigenen Beitrag hat — den über Parameter Sniffing und Plan-Regression. Ein Gedankenexperiment macht es greifbar: Nimm eine Tabelle mit fünf Prozent Fragmentierung, aber Statistiken, die seit dem letzten großen Import nicht mehr aktualisiert wurden. Ein REBUILD räumt hier physisch fast nichts auf — die fünf Prozent waren ohnehin harmlos —, aber die nebenbei erneuerten Statistiken geben dem Optimizer plötzlich wieder ehrliche Zahlen, und genau deshalb läuft danach alles flüssiger. Hätte man stattdessen reorganisiert, wäre die Wirkung ausgeblieben, weil REORGANIZE die Statistiken eben nicht anfasst. Dasselbe Werkzeug, dasselbe Symptom, völlig verschiedene Ergebnisse — und der ganze Unterschied liegt in einem Mechanismus, den die meisten gar nicht auf dem Schirm haben.

Der Entscheidungsbaum

Statt blind alles zu rebuilden, triffst du pro Index eine bewusste Entscheidung nach drei Kriterien: Relevanz (Größe), Fragmentierungsgrad und Statistik-Aktualität. Der folgende Baum macht daraus ein klares Vorgehen:

Die Skripte: messen, entscheiden, ausmisten

Schritt 1 — Fragmentierung der relevanten Indizes messen

Die DMV liefert die Fragmentierung; der Filter auf die Seitenzahl blendet die irrelevanten Kleinst-Indizes aus, bei denen jede Wartung Zeitverschwendung wäre:

Die Empfehlung-Spalte setzt die Schwellenwerte aus dem Baum direkt um. Beachte den Modus LIMITED: Er ist schnell und schonend genug für den laufenden Betrieb — die gründlicheren Modi SAMPLED und DETAILED lesen tiefer, kosten aber spürbar mehr und gehören nur in die gezielte Untersuchung.

Schritt 2 — Gezielt warten: REBUILD oder REORGANIZE

Schritt 3 — Ausmisten: ungenutzte Indizes finden

Der wirksamste Wartungsschritt ist oft das Löschen. Ein Index, der bei jedem Schreibvorgang mitgepflegt werden muss, aber nie gelesen wird, ist reiner Ballast:

Indizes mit hohen Schreibzugriffen und null Lesezugriffen sind die Streichkandidaten — aber nicht blind löschen: Die Statistik wird beim Neustart zurückgesetzt, du brauchst also eine Beobachtungsperiode, die auch Monats- und Quartalsläufe abdeckt. Ein Index, den nur der große Jahresreport nutzt, sieht elf Monate lang ungenutzt aus. Und Primärschlüssel- sowie Unique-Indizes bleiben tabu, egal was die Lesestatistik sagt — sie erfüllen einen anderen Zweck als reine Performance.

Die intelligente Wartungsstrategie in der Praxis

Ola Hallengren statt Wartungsplan-Assistent

Der eingebaute Wartungsplan-Assistent kennt nur „alles rebuilden“ oder „alles reorganisieren“ — pauschal, ohne Blick auf den einzelnen Index. Die Ola Hallengren Maintenance Solution macht es richtig: Ihr IndexOptimize prüft jeden Index einzeln, wendet je nach Fragmentierung die passende Maßnahme an oder lässt ihn in Ruhe, und pflegt auf Wunsch die Statistiken gleich mit. Sie ist kostenlos, weltweit erprobt und der De-facto-Standard — wer noch mit dem Assistenten arbeitet, sollte den Wechsel auf seine Wartungsliste setzen. Ein typischer Aufruf wartet nur, was es nötig hat, und aktualisiert die Statistiken der reorganisierten Indizes automatisch.

Online, Offline und das Wartungsfenster

Ein REBUILD offline sperrt die Tabelle für die Dauer der Operation — auf einer großen, viel genutzten Tabelle ist das ein Ausfall, kein Wartungsschritt. ONLINE = ON umgeht das, ist aber der Enterprise Edition vorbehalten und braucht mehr Ressourcen und tempdb. REORGANIZE ist dagegen immer online und jederzeit unterbrechbar — der sichere Default, wenn kein klares Wartungsfenster existiert. Und auf Enterprise gibt es seit einigen Versionen den resumable Online-Rebuild, der sich anhalten und später fortsetzen lässt: ideal für sehr große Indizes, die nicht in eine einzelne Nacht passen. Wer Always-On-Replicas betreibt, denkt zusätzlich an die Log-Flut, die jeder Rebuild über die Synchronisierungs-Strecke schickt — nachzulesen im Always-On-Beitrag.

Fill Factor — Vorbeugen statt Nachsorgen

Der Fill Factor bestimmt, wie voll die Seiten beim Aufbau gepackt werden. Ein Wert von 100 (Standard) füllt randvoll — effizient für reine Lesetabellen, aber bei vielen Einfügungen entstehen schnell wieder Seitenteilungen und damit Fragmentierung. Ein etwas niedrigerer Fill Factor (etwa 90) lässt bewusst Luft, in die neue Zeilen passen, ohne Seiten zu spalten — das reduziert die Fragmentierung an der Quelle und damit den Wartungsbedarf. Das ist Feintuning für stark beschriebene Indizes, kein Pauschalrezept: Zu viel Luft verschwendet Cache und I/O, weil jede halb leere Seite trotzdem vollständig in den Speicher geladen wird. Besonders lohnend ist ein angepasster Fill Factor bei Indizes auf Spalten, in deren Mitte ständig eingefügt wird — etwa ein nicht fortlaufender Schlüssel, bei dem neue Werte überall zwischen den bestehenden landen. Dort entstehen ohne Reserve laufend Seitenteilungen, jede davon ein kleiner Schreibvorgang mit Fragmentierungsfolge. Bei einem rein aufsteigenden Schlüssel dagegen, bei dem neue Zeilen immer am Ende angehängt werden, bringt ein gesenkter Fill Factor nichts und verschenkt nur Platz. Wie bei allem in diesem Beitrag gilt: gezielt, nicht mit der Gießkanne.

Was du auf keinen Fall tun solltest

Index-Wartung als Teil der Routine

Index-Wartung ist kein Einzelprojekt, sondern ein fester Baustein der proaktiven Pflege — und sie gehört in denselben Atemzug wie die Statistik-Wartung, weil beide untrennbar zusammenhängen. Drei Empfehlungen für die Routine: Erstens, Ola Hallengrens IndexOptimize mit aktivierten Statistik-Optionen als wöchentlichen Job einrichten — damit ist die intelligente Wartung erledigt, ohne dass jemand jede Woche Schwellenwerte abwägt. Zweitens, einmal im Quartal die ungenutzten Indizes prüfen und ausmisten — gewachsene Systeme tragen erstaunlich viel toten Index-Ballast mit sich herum. Drittens, die Wartung in den Health Check aufnehmen, der prüft, ob der Job überhaupt läuft und durchläuft. Wie all das ins große Bild der proaktiven Wartung passt, zeigt der Health-Check-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Index-Strategie, Statistik-Mechanik und Wartungsplanung füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Beiträge im Notarztwagen

Index-Wartung hat enge Nachbarn — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zur intelligenten Index-Wartung

Selbst-Diagnose-Kit

Index-Wartung ist die klassische Selbstmach-Aufgabe — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Fragmentierungs-Analyse mit Empfehlungsspalte, gezielte REBUILD-/REORGANIZE-Vorlagen, die Suche nach ungenutzten Indizes — plus den Entscheidungsbaum zum Ausdrucken und einen vorkonfigurierten Ola-Hallengren-Aufruf, den du nur noch terminieren musst. Damit ersetzt du den nächtlichen Vorschlaghammer in einer Stunde durch eine chirurgische Wartung.

Festpreis-Analyse

Du vermutest, dass deine Datenbank unter totem Index-Ballast und einer pauschalen Wartung leidet, willst aber eine fundierte Bestandsaufnahme statt eigenem Stochern? Die Festpreis-Analyse liefert sie: Ich bewerte die komplette Index-Landschaft — Fragmentierung, Nutzung, fehlende und überflüssige Indizes, Statistik-Aktualität, Wartungsstrategie — und liefere einen Bericht mit priorisierten Maßnahmen, von den Lösch-Kandidaten bis zur fertigen Wartungskonfiguration. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn ein Wartungsjob gerade aus dem Ruder läuft — der Rebuild, der ins Tagesgeschäft ragt, oder das Log, das die Wartungsnacht aufgebläht hat: anrufen. Halte einen Zugang mit den nötigen Rechten bereit und die Information, welcher Job läuft. Meist lässt sich die akute Last sofort entschärfen und die Wartung danach vernünftig neu aufsetzen.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Wann sollte ich Indizes neu aufbauen?

Nach der bewährten Faustregel: bei Fragmentierung über 30 Prozent ein REBUILD, zwischen 10 und 30 Prozent ein REORGANIZE, unter 10 Prozent gar nichts. Aber Vorsicht — diese Schwellen gelten nur für Indizes mit echter Relevanz, also grob ab 1000 Seiten; kleine Indizes lohnen die Mühe nie und lassen sich ohnehin nicht sinnvoll defragmentieren. Und wichtiger als die reine Fragmentierungszahl ist oft die Frage, ob die Statistiken aktuell sind, denn der größte Performance-Gewinn der Wartung kommt häufig von den nebenbei aktualisierten Statistiken, nicht vom Aufräumen der Seiten. Das fertige Analyse-Skript steht in diesem Beitrag.

Was ist der Unterschied zwischen REBUILD und REORGANIZE?

REBUILD baut den Index komplett neu auf — gründlich, beseitigt Fragmentierung vollständig und aktualisiert die Statistiken mit FULLSCAN gratis mit. Der Haken: Offline sperrt es die Tabelle, ONLINE geht nur in der Enterprise Edition, und es braucht viel Platz und Log. REORGANIZE ordnet die Blattebene des Index schonend um — immer online, jederzeit unterbrechbar, ressourcenschonend, aber weniger gründlich. Der entscheidende Unterschied in der Praxis: REORGANIZE aktualisiert die Statistiken NICHT, du musst sie also separat einplanen. Faustregel: REORGANIZE bei mittlerer Fragmentierung, REBUILD bei hoher — und immer an die Statistiken denken.

Ab welcher Fragmentierung muss ich handeln?

Die klassischen Schwellen lauten: unter 10 Prozent nichts tun, 10 bis 30 Prozent REORGANIZE, über 30 Prozent REBUILD. Diese Zahlen sind aber eine Orientierung, kein Naturgesetz — und auf modernem Flash-Storage deutlich weniger kritisch als zu Zeiten rotierender Platten. Die physische Fragmentierung, also dass Seiten nicht in perfekter Reihenfolge liegen, kostet bei SSDs kaum noch Leistung, weil es keine Schreib-Lese-Köpfe mehr gibt, die quer über die Scheibe fahren müssen. Wichtiger als das blinde Einhalten der Prozent-Schwellen ist deshalb, die Wartung selektiv und ressourcenschonend zu fahren und die Statistik-Pflege nicht zu vergessen.

Was ist Ola Hallengren Maintenance Solution?

Die Ola Hallengren Maintenance Solution ist eine kostenlose, weltweit etablierte Sammlung von T-SQL-Skripten für SQL-Server-Wartung — Index- und Statistik-Pflege, Backups und Integritätsprüfungen. Ihr großer Vorteil gegenüber dem eingebauten Wartungsplan-Assistenten: Sie arbeitet intelligent statt pauschal. IndexOptimize prüft die Fragmentierung jedes Index einzeln und wendet je nach Schwellwert REORGANIZE, REBUILD oder gar nichts an, statt stur alles neu aufzubauen. Damit verwandelst du den Vorschlaghammer-Ansatz in eine chirurgische Wartung, die nur das anfasst, was es nötig hat. Sie ist der De-facto-Standard und gehört auf praktisch jeden Produktionsserver.

Wie aktualisiere ich Statistiken nach Index-Rebuild?

Nach einem REBUILD musst du gar nichts tun — der baut die Statistiken des Index mit FULLSCAN automatisch und gratis mit auf, das ist einer seiner größten Vorteile. Anders nach einem REORGANIZE: Das fasst die Statistiken nicht an, also gehört dort ein separates UPDATE STATISTICS in den Wartungsplan, sonst plant der Optimizer mit der Zeit auf veralteten Zahlen. Zu beachten ist außerdem, dass ein Index-Rebuild nur die Statistiken dieses einen Index aktualisiert, nicht die Spalten-Statistiken der Tabelle — die brauchen weiterhin ihre eigene Pflege. Ola Hallengrens IndexOptimize erledigt diese Feinheiten von selbst, wenn man die Statistik-Optionen aktiviert.

Welche Indizes brauche ich überhaupt?

Die richtige Frage vor jeder Wartung, denn den besten Index wartet man gar nicht — den ungenutzten löscht man. SQL Server führt in sys.dm_db_index_usage_stats Buch darüber, wie oft jeder Index für Seeks, Scans und Lookups verwendet wurde und wie oft er bei Schreibvorgängen mitgepflegt werden musste. Ein Index mit vielen Updates, aber null Lesezugriffen seit dem letzten Neustart ist reiner Ballast: Er kostet Speicher, verlangsamt jedes INSERT und UPDATE und will trotzdem gewartet werden. Parallel zeigen die Missing-Index-DMVs, wo Indizes fehlen — beides zusammen ist die eigentliche Index-Strategie, hinter der die reine Defragmentierung zurücktritt.

Wie finde ich ungenutzte Indizes?

Über sys.dm_db_index_usage_stats: Die DMV zählt seit dem letzten Dienststart die Seeks, Scans und Lookups (user_seeks, user_scans, user_lookups) sowie die Schreibzugriffe (user_updates) je Index. Ein Index mit hohen user_updates, aber null oder fast null Lesezugriffen ist ein heißer Kandidat fürs Löschen. Zwei Vorsichtsmaßnahmen: Die Statistik wird beim Neustart zurückgesetzt, du brauchst also eine ausreichend lange Beobachtungsperiode, die auch Monats- und Quartalsläufe einschließt — ein Index, der nur einmal im Quartal vom großen Report genutzt wird, sieht sonst ungenutzt aus. Und Unique-Constraints und Primärschlüssel-Indizes nie nach diesem Kriterium löschen.