SQL Server Indexwartung: vier Stufen von links nach rechts — fragmentierte Indexbalken mit Warnung, REORGANIZE-Sync-Pfeile, REBUILD-Zahnrad mit grünem Fortschrittsbalken, gesunde gleichmäßige Indexbalken mit grünem Haken; oben ein Fragmentierungs-Donut

SQL Server Indexwartung: Fragmentierung und Neuaufbau

SQL Server Indexwartung misst Fragmentierung und behebt sie mit REORGANIZE oder REBUILD. Wann welche Option, sicherer Plan und Checkliste.

Kurz gesagt: SQL Server Indexwartung bedeutet, die Fragmentierung von Indizes zu messen und sie mit REORGANIZE oder REBUILD zu beheben. Ungepflegte Indizes verlängern Lesezeiten und blähen Backup- und Wartungsfenster auf. Für KMU ist ein wöchentlicher Wartungsplan oft der günstigste Weg, langsame Berichte zu entschärfen, ohne jede Abfrage neu zu schreiben.

Jedes UPDATE, INSERT und DELETE zerstreut Indexseiten etwas weiter: Seiten splitten, die logische Ordnung weicht von der physischen ab. Dieselbe Abfrage liest dann mehr Seiten; Platten- und Speicherdruck steigen. Wer Performance nur mit neuer Hardware oder Query-Rewrites löst und Indexwartung übersieht, lässt die Ursache bestehen.

Dieser Beitrag erklärt, was Fragmentierung bedeutet, den Unterschied zwischen REORGANIZE und REBUILD, wann welche Option passt und wie Sie einen sicheren Wartungsplan Schritt für Schritt aufsetzen.

Warum ist SQL Server Indexwartung nötig?

Indizes helfen Abfragen, die richtigen Zeilen schnell zu finden. Unter starker Schreiblast fragmentieren Indexseiten:

  • Interne Fragmentierung: auf Seiten bleibt Leerraum; für dieselben Daten werden mehr Seiten gelesen.
  • Externe Fragmentierung: die logische Reihenfolge bricht; sequentielle Reads werden zu Random-I/O.

Fragmentierung wird in Prozent gemessen. Üblich ist REORGANIZE etwa bei 10–30 % und REBUILD über 30 %; Schwellen folgen Workload und Wartungsfenster. Die offizielle Microsoft-Seite zu Indizes reorganisieren und neu erstellen fasst Befehle und Hinweise zusammen.

REORGANIZE oder REBUILD?

SQL Server Indexwartung-Zyklus: SQL-Datenbank in der Mitte; messen (Lupe + ungleichmäßige Balken), entscheiden (REORGANIZE-/REBUILD-Gabelung), ausführen (Zahnrad + Fortschritt), prüfen (Haken + gesunde Balken) — Pfeile im Uhrzeigersinn

1. Fragmentierung messen

Nutzen Sie sys.dm_db_index_physical_stats für avg_fragmentation_in_percent und page_count. Hohe Prozentwerte bei sehr kleinen Indizes können täuschen; entscheiden Sie zusammen mit der Seitenzahl.

2. REORGANIZE

Läuft online, hält Sperren kurz und ordnet den Index an Ort und Stelle. Es passt zu mittlerer Fragmentierung und engen Fenstern und ist in den meisten KMU-Umgebungen planbar.

3. REBUILD

Erstellt den Index neu und aktualisiert Statistiken. Enterprise bietet ONLINE-Rebuilds; unter Standard kann das Objekt länger gesperrt bleiben. Bevorzugen Sie REBUILD bei hoher Fragmentierung, großen Indizes und ruhigen Nachtfenstern.

4. Fill factor und Wartungsfenster

Der Fill factor lässt Platz für spätere Updates. Zu niedrig bläht den Index auf; zu hoch beschleunigt Fragmentierung. Legen Sie Wartung außerhalb von Backup und Stoßzeiten; sonst steigen SQL-Sperrprobleme.

5. Statistiken und Abfragepläne

REBUILD aktualisiert Statistiken; REORGANIZE nicht. Prüfen Sie danach Plan-Cache und Laufzeiten kritischer Berichte. Für breitere Optimierung ergänzen Sie die Checks aus 10 Wege zur Verbesserung der SQL-Datenbankleistung.

Wie richtet man einen sicheren Wartungsplan ein?

Ein einmaliger REBUILD reicht nicht; Sie brauchen einen Rhythmus:

  • Wöchentliche Messung: Indizes über Fragmentierungs- und Seitenschwellen listen.
  • Stufenweise Aktion: zuerst REORGANIZE, bei Bedarf REBUILD; nicht blind die ganze Datenbank rebuilden.
  • Mit Backups abstimmen: vor großem REBUILD aktuelles Backup sicherstellen; unser Beitrag zu SQL-Datenbank-Backup erklärt den RPO/RTO-Rahmen.
  • Überwachen: langsamste Abfragen und Plattenlatenz nach der Wartung notieren; ohne Verbesserung liegt das Problem in der Abfrage oder einem fehlenden Index.

Planen Sie die Jobs mit SQL Server Agent und schreiben Sie jedes Ergebnis in eine Tabelle. So sehen Sie, welche Indizes ständig fragmentieren und welche REBUILDs zu lange dauern. Dieselbe Überwachung entlarvt auch aufgeblähte Pläne, die nächtlich jeden Index ohne Bedarf neu erstellen.

Dokumentieren Sie außerdem, wer die Wartung freigibt und wie bei einem fehlgeschlagenen Job eskaliert wird. Ohne klare Verantwortung bleibt Indexwartung ein einmaliges Projekt statt eines stabilen Betriebsprozesses.

Checkliste vor dem Start der Indexwartung

  • Sind betroffene Datenbanken und Indizes schriftlich festgelegt?
  • Sind Fragmentierungsschwelle und Mindestseitenzahl definiert?
  • Kollidiert das Fenster nicht mit Backup und Stoßzeiten?
  • Ist ONLINE REBUILD für Ihre Standard-/Enterprise-Edition möglich?
  • Gibt es eine Prüfliste für kritische Berichte danach?

SQL Server Indexwartung ist eine Betriebsdisziplin vor teurer Hardware. Umfang und Risiko lassen sich auch aus Sicht der SQL-Beratung bewerten.

ÇAP Teknoloji richtet mit KMU SQL-Server-Indexwartung, Performance und Backup-Pläne gemeinsam ein. Sehen Sie sich unsere SQL-Beratung an oder nehmen Sie Kontakt auf, um Ihre Datenbank zu prüfen.

Häufig gestellte Fragen

Was unterscheidet REORGANIZE und REBUILD?

REORGANIZE ordnet den Index online an Ort und Stelle und aktualisiert keine Statistiken. REBUILD erstellt neu, aktualisiert Statistiken und wird bei hoher Fragmentierung bevorzugt; ONLINE-Rebuilds können unter Standard eingeschränkt sein.

Ab welchem Fragmentierungsprozentsatz warten?

Üblich ist REORGANIZE bei etwa 10–30 % und REBUILD über 30 %. Bei sehr kleinen Indizes täuscht der Prozentwert; entscheiden Sie mit page_count und passen Sie Schwellen dem Workload an.

Verlangsamt Indexwartung die Anwendung?

Trifft das Fenster Stoßzeiten, steigen Sperren und I/O. REORGANIZE ist meist leichter; große REBUILDs nachts und außerhalb von Backups planen.

Was tun, wenn die Performance danach nicht besser wird?

Ursache kann ein fehlender Index, eine schlechte Abfrage oder veraltete Statistiken sein. Prüfen Sie langsamste Abfragen, Pläne und Missing-Index-Hinweise.