Index-Optimierung & Statistik-Update – SQL Server Wartung

Index-Wartung Statistiken REORGANIZE vs. REBUILD AUTO_UPDATE_STATISTICS Wartungsfenster

Index-Optimierung &
Statistik-Update –
Vor- und Nachteile im Überblick

Zwei der wichtigsten Wartungsaufgaben in SQL Server – und beide werden häufig falsch konfiguriert. Dieser Artikel beleuchtet die Mechanismen, zeigt Vor- und Nachteile beider Verfahren und gibt konkrete Empfehlungen für den Wartungsalltag.

Index-Wartung und Statistik-Aktualisierung sind zwei verschiedene Aufgaben mit unterschiedlichen Zielen – werden aber häufig verwechselt oder in denselben Topf geworfen. Ein Index REBUILD verbessert die physische Speicherstruktur, hat aber nur indirekten Einfluss auf die Statistiken. Ein Statistik-Update korrigiert die Schätzwerte des Optimizers, verändert aber nicht die physische Seitenstruktur.

Beide Verfahren haben echte Vor- und Nachteile. Blinder Aktionismus – „jede Nacht alles rebuilden" – ist genauso schädlich wie vollständiges Nichtstun. Dieser Artikel erklärt die Mechanismen, bewertet die Optionen ehrlich und zeigt, wie eine durchdachte Wartungsstrategie aussieht.

01
Index-Wartung · Grundlagen

Indexfragmentierung – was sie ist und was sie nicht ist

Ein SQL Server-Index ist ein B-Tree (Balanced Tree). Die Blattseiten des Index sind in einer doppelt verketteten Liste angeordnet – idealer­weise in der logischen Reihenfolge der Schlüsselwerte. Fragmentierung entsteht, wenn diese Reihenfolge durch INSERT-, UPDATE- und DELETE-Operationen zerfällt.

Zwei Arten der Fragmentierung

ArtWas passiertAuswirkungMesswert
Externe Fragmentierung Logische und physische Reihenfolge der Seiten weichen ab. Eine sequenzielle Suche springt auf der Disk hin und her. Erhöhte I/O-Latenz bei sequenziellen Scans (Index Scans, Bereichssuchen). Kaum relevant bei SSDs. avg_fragmentation_in_percent
Interne Fragmentierung Seiten sind nur teilweise gefüllt (Page Splits). 100 Seiten speichern die Datenmenge von 50. Mehr Seiten müssen gelesen werden. Erhöht Buffer Pool-Verbrauch. Betrifft HDDs und SSDs gleichermaßen. avg_page_space_used_in_percent
SSD-Kontext: Auf modernen SSD-Speichern ist externe Fragmentierung weitgehend irrelevant – random I/O ist nahezu so schnell wie sequential I/O. Interne Fragmentierung bleibt jedoch auf jeder Speicherart ein Problem, da sie die Anzahl der zu lesenden Seiten erhöht. Wer ausschließlich SSDs betreibt, sollte seine Wartungsintervalle daher deutlich lockern oder ganz auf Fill-Factor-Optimierung setzen.

Fragmentierung messen

T-SQL – Fragmentierung aller Indizes einer Datenbank
SELECT 
OBJECT_NAME(ips.object_id) AS Tabelle, 
i.[name] AS Indexname, 
i.type_desc AS Indextyp, 
ips.index_depth, 
ips.page_count, 
ROUND(ips.avg_fragmentation_in_percent, 1) 
AS ExtFrag_Pct, 
ROUND(ips.avg_page_space_used_in_percent, 1) 
AS Seitenfuellung_Pct, 
CASE 
WHEN ips.avg_fragmentation_in_percent > 30 THEN 'REBUILD' 
WHEN ips.avg_fragmentation_in_percent > 10 THEN 'REORGANIZE' 
ELSE 'OK' 
END AS Empfehlung 
FROM 
sys.dm_db_index_physical_stats( 
DB_ID(), NULL, NULL, NULL, 'SAMPLED' 
) ips 
INNER JOIN sys.indexes i 
ON ips.object_id = i.object_id 
AND ips.index_id = i.index_id 
WHERE 
ips.page_count > 100 -- Kleine Indizes ignorieren 
AND i.type_desc IN ('CLUSTERED', 'NONCLUSTERED') 
ORDER BY 
ips.avg_fragmentation_in_percent DESC;
Modus SAMPLED vs. DETAILED vs. LIMITED: SAMPLED ist der beste Kompromiss für den Produktionsbetrieb – schnell genug für häufige Checks, genau genug für Wartungsentscheidungen. DETAILED liefert exakte Werte, ist aber bei großen Datenbanken sehr I/O-intensiv und sollte nur auf Anforderung ausgeführt werden. LIMITED ist am schnellsten, liefert jedoch keine avg_page_space_used_in_percent-Werte.

02
Index-Wartung

ALTER INDEX … REORGANIZE

REORGANIZE defragmentiert den Blattknoten eines Index, indem es Seiten physisch in der logischen Reihenfolge sortiert. Die Operation arbeitet seitenweise und ist jederzeit unterbrechbar – wird sie abgebrochen, bleiben die bisher verarbeiteten Seiten defragmentiert.

Vorteile
  • Online und unterbrechbar: Keine langen exklusiven Sperren. Läuft im Hintergrund ohne spürbaren Einfluss auf Concurrent-Workloads.
  • Transaktional: Jede Seite wird in einer eigenen Transaktion reorganisiert. Abbruch hinterlässt keine inkonsistenten Zustände.
  • Kein TempDB-Verbrauch: Arbeitet direkt auf den Datenseiten – keine temporäre Kopie notwendig.
  • Log-schonend: Minimales Transaktionslog im Vergleich zu REBUILD.
  • Geeignet für kleinere Wartungsfenster: Kann zeitlich begrenzt und später fortgesetzt werden.
Nachteile
  • Keine Statistik-Aktualisierung: REORGANIZE aktualisiert Statistiken nicht – das muss separat erfolgen.
  • Kein Fill-Factor-Reset: Der beim Index konfigurierte Fill Factor wird nicht neu angewendet. Interne Fragmentierung bleibt erhalten.
  • Nur Blattknoten: Nicht-Blatt-Seiten des B-Tree werden nicht reorganisiert. Bei tiefen Indizes mit vielen Ebenen nur begrenzte Wirkung.
  • Langsamer als REBUILD bei starker Fragmentierung: Ab ca. 50 % Fragmentierung ist ein REBUILD effektiver und schneller als REORGANIZE.
  • LOB-Komprimierung optional: Große Objekte (text, image, XML) müssen explizit mit LOB_COMPACTION = ON angesprochen werden.
T-SQL – REORGANIZE Varianten
-- Einzelnen Index reorganisieren 
ALTER INDEX IX_Bestellung_Datum 
ON dbo.Bestellung 
REORGANIZE; 
 
-- Mit LOB-Komprimierung (für Tabellen mit text/image/XML-Spalten) 
ALTER INDEX PK_Dokument 
ON dbo.Dokument 
REORGANIZE WITH (LOB_COMPACTION = ON); 
 
-- Alle Indizes einer Tabelle reorganisieren 
ALTER INDEX ALL ON dbo.Bestellung REORGANIZE; 
 
-- Fragmentierung nach REORGANIZE prüfen 
SELECT 
i.[name], 
ROUND(ips.avg_fragmentation_in_percent, 1) AS Frag_Pct, 
ips.page_count 
FROM 
sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.Bestellung'), 
NULL, NULL, 'SAMPLED') ips 
INNER JOIN sys.indexes i 
ON ips.object_id = i.object_id AND ips.index_id = i.index_id;

03
Index-Wartung

ALTER INDEX … REBUILD

REBUILD erstellt den Index von Grund auf neu. Die alte Indexstruktur wird vollständig verworfen, alle Daten werden nach dem konfigurierten Fill Factor neu sortiert und auf frische Seiten geschrieben. Das Ergebnis ist ein strukturell perfekter Index – aber der Weg dorthin hat seinen Preis.

Vorteile
  • Vollständige Defragmentierung: Externe und interne Fragmentierung werden vollständig beseitigt. Alle Ebenen des B-Tree werden neu aufgebaut.
  • Fill-Factor-Reset: Der konfigurierte Fill Factor wird auf alle Seiten angewendet – interne Fragmentierung entsteht erst wieder durch neue DML-Operationen.
  • Statistik-Update inklusive: REBUILD aktualisiert die Indexstatistiken automatisch mit einem FULLSCAN-äquivalenten Scan.
  • Schneller bei starker Fragmentierung: Ein kompletter Neuaufbau ist effizienter als seitenweises Reorganisieren bei > 50 % Fragmentierung.
  • Komprimierung anwendbar: Row- und Page-Komprimierung können mit einem REBUILD aktiviert oder geändert werden.
Nachteile
  • TempDB-Verbrauch: Der Neuaufbau erfolgt in TempDB (oder Datenbankdatei bei SORT_IN_TEMPDB = OFF). Bei großen Indizes kann das die gesamte TempDB-Kapazität beanspruchen.
  • Transaktionslog-Volumen: Ein REBUILD schreibt bedeutend mehr in das Transaktionslog als REORGANIZE. Bei vollständigem Recovery-Modell wächst das Log erheblich.
  • Exklusive Sperre (OFFLINE): Ohne ONLINE = ON blockiert REBUILD den Lesezugriff auf die Tabelle während der gesamten Operation.
  • ONLINE-Option nur in Enterprise/Developer: ONLINE = ON ist nicht in der Standard Edition verfügbar.
  • Nicht unterbrechbar: Ein abgebrochener REBUILD lässt den Index im alten Zustand – die investierte Zeit ist verloren.
  • Ressourcenintensiv: CPU- und I/O-intensive Operation, die parallele Workloads spürbar verlangsamen kann.
T-SQL – REBUILD Varianten
-- Offline REBUILD (Standard Edition kompatibel) 
ALTER INDEX PK_Bestellung 
ON dbo.Bestellung 
REBUILD WITH ( 
FILLFACTOR = 80, -- 80% Seitenfüllung, 20% Puffer 
STATISTICS_NORECOMPUTE = OFF, 
SORT_IN_TEMPDB = ON -- Sortierung in TempDB, nicht in DB-Dateien 
); 
 
-- Online REBUILD (Enterprise Edition – kein Lesezugriff blockiert) 
ALTER INDEX ALL ON dbo.Bestellung 
REBUILD WITH ( 
ONLINE = ON, 
FILLFACTOR = 80, 
MAXDOP = 4, -- Max. 4 CPU-Kerne für Rebuild 
SORT_IN_TEMPDB = ON 
); 
 
-- REBUILD mit WAIT_AT_LOW_PRIORITY (verhindert Blockierung durch lange Transaktionen) 
ALTER INDEX IX_Konto_Status 
ON dbo.Konto 
REBUILD WITH ( 
ONLINE = ON, 
WAIT_AT_LOW_PRIORITY ( 
MAX_DURATION = 5 MINUTES, 
ABORT_AFTER_WAIT = BLOCKERS -- Blockierende Transaktionen abbrechen 
) 
);
STATISTICS_NORECOMPUTE = OFF ist der richtige Standard: Wer bei einem REBUILD STATISTICS_NORECOMPUTE = ON setzt, deaktiviert damit die automatische Statistik-Aktualisierung für diese Statistik dauerhaft – bis sie explizit zurückgesetzt wird. Das ist ein häufiger, versteckter Fehler in älteren Wartungsskripten.

04
Index-Wartung

Entscheidungsrahmen – wann was

Die klassischen Schwellenwerte (10 % / 30 %) stammen aus einer Zeit dominanter HDDs. Sie sind ein guter Ausgangspunkt, aber nicht das einzige Kriterium.

< 1.000 Seiten
Nichts tun – Optimizer wählt ohnehin Table Scan
Frag < 10 %
Nichts tun – Aufwand übersteigt den Nutzen
10 – 30 %, HDD
REORGANIZE – schonend, online, keine Statistiken nötig
10 – 30 %, SSD
Nichts tun oder Fill Factor anpassen
> 30 %, Standard Ed.
REBUILD OFFLINE im Wartungsfenster
> 30 %, Enterprise Ed.
REBUILD ONLINE mit MAXDOP-Begrenzung

Fill Factor – der oft vergessene Parameter

Der Fill Factor bestimmt, wie voll jede Indexseite beim REBUILD befüllt wird. Ein Wert von 80 lässt 20 % Platz für neue Einträge, bevor eine Page Split auftritt. Ein zu niedriger Fill Factor verschwendet Speicher und erhöht die Anzahl der Seiten – ein zu hoher führt zu häufigen Page Splits und schneller Fragmentierung.

Fill FactorGeeignet fürNachteil
100 (0)Read-Only oder Insert-Only-Tabellen (stets am Ende)Sofortige Fragmentierung bei Updates im mittleren Bereich
90–95Wenig volatile Tabellen (Stammdaten, Kataloge)Geringe interne Fragmentierungsreserve
75–85Standard für OLTP-Tabellen mit gleichmäßigem DMLMehr Seiten bei gleichem Datenvolumen
60–70Hotspot-Tabellen mit vielen Inserts/Updates auf denselben SchlüsselbereichenDeutlich mehr Speicherbedarf, mehr I/O
Fill Factor 0 = 100: Ein konfigurierter Fill Factor von 0 ist identisch mit 100 – die Seite wird vollständig gefüllt. Das ist der SQL Server-Default für neue Indizes. Für produktive OLTP-Tabellen sollte dieser Wert beim ersten REBUILD explizit auf einen sinnvollen Wert gesetzt werden.

05
Statistiken · Grundlagen

Was Statistiken sind und warum sie verfallen

Statistiken sind komprimierte Histogramme, die dem SQL Server Query Optimizer mitteilen, wie die Werte einer Spalte verteilt sind. Auf Basis dieser Histogramme schätzt der Optimizer, wie viele Zeilen eine Abfrage zurückliefert – und wählt danach den Execution Plan.

Falsche Statistiken sind die häufigste Ursache für suboptimale Execution Plans – häufiger als fehlende Indizes. Ein Optimizer, der annimmt, dass eine Abfrage 100 Zeilen zurückgibt, aber tatsächlich 10 Millionen bekommt, wählt einen völlig falschen Plan.

Anatomie einer Statistik

T-SQL – Statistik-Inhalt und Metadaten anzeigen
-- Alle Statistiken einer Tabelle mit Aktualität 
SELECT 
s.[name] AS StatistikName, 
STATS_DATE(s.object_id, s.stats_id) AS LetzteAktualisierung, 
sp.rows AS GeschätzteZeilen, 
sp.rows_sampled AS GestichprobeZeilen, 
ROUND(sp.rows_sampled * 100.0 / NULLIF(sp.rows, 0), 1) 
AS Stichprobe_Pct, 
sp.modification_counter AS ÄnderungenSeitUpdate, 
s.auto_created, 
s.user_created 
FROM 
sys.stats s 
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp 
WHERE 
s.object_id = OBJECT_ID('dbo.Transaktion') 
ORDER BY 
sp.modification_counter DESC; 
 
-- Histogramm einer Statistik anzeigen (wichtigste Diagnosequelle) 
DBCC SHOW_STATISTICS ('dbo.Transaktion', 'IX_Transaktion_Datum') WITH HISTOGRAM;

Wann Statistiken veralten

SQL Server zählt in modification_counter, wie viele Zeilen seit dem letzten Statistik-Update geändert wurden. Die automatische Aktualisierung wird ausgelöst, sobald dieser Schwellenwert überschritten ist:

TabellengrößeSQL Server < 2016SQL Server 2016+ (TF 2371 oder Compat. 130+)
< 500 Zeilen500 Änderungen500 Änderungen
500 – 25.000 Zeilen500 + 20 % der ZeilenDynamisch: √(1000 × Zeilenanzahl)
> 25.000 Zeilen20 % der ZeilenzahlDynamisch: √(1000 × Zeilenanzahl)
Dynamischer Schwellenwert ab Kompatibilitätslevel 130: Der alte statische Schwellenwert von 20 % war für große Tabellen fatal – eine Tabelle mit 100 Millionen Zeilen brauchte 20 Millionen Änderungen, bevor die Statistik aktualisiert wurde. Der neue dynamische Schwellenwert (√(1000 × Zeilen)) löst die Aktualisierung bei großen Tabellen deutlich früher aus. Das ist einer der wichtigsten Gründe, den Kompatibilitätslevel auf 130+ zu setzen.

06
Statistiken · Automatisch

AUTO_UPDATE_STATISTICS – Vor- und Nachteile

SQL Server kann Statistiken automatisch aktualisieren, wenn der Schwellenwert überschritten wird. Diese Funktion ist standardmäßig aktiviert und in den meisten Umgebungen der richtige Default.

Vorteile AUTO_UPDATE
  • Nullaufwand für DBAs: Statistiken bleiben automatisch aktuell – kein manueller Eingriff erforderlich.
  • Reagiert auf Datenveränderungen: Wird ausgelöst, wenn die Daten sich tatsächlich geändert haben, nicht nach einem starren Zeitplan.
  • Stichprobenbasiert und schnell: Liest nicht die gesamte Tabelle, sondern eine repräsentative Stichprobe.
  • Asynchrone Option (ASYNC): Mit AUTO_UPDATE_STATISTICS_ASYNC = ON wird die Aktualisierung im Hintergrund durchgeführt – die laufende Abfrage wartet nicht.
Nachteile AUTO_UPDATE
  • Statistikaktualisierung während der Abfrage (SYNC): Im synchronen Modus (Standard) wartet die auslösende Abfrage auf den Abschluss der Aktualisierung – spürbare Latenzspitze.
  • Stichprobe kann zu klein sein: Bei sehr schiefen Datenverteilungen oder kleinen Tabellen mit wenigen, sehr unterschiedlichen Werten kann die Stichprobe das Histogramm falsch darstellen.
  • Nicht sofort nach Bulk-Loads: Nach einem massiven Datenimport kann es sein, dass die automatische Aktualisierung noch nicht ausgelöst wurde, aber das Histogramm bereits stark veraltet ist.
  • Kein FULLSCAN: Die automatische Aktualisierung verwendet Stichproben – für Spalten mit ungleichmäßiger Verteilung ist das möglicherweise nicht ausreichend.
T-SQL – AUTO_UPDATE und ASYNC konfigurieren
-- Status aller Statistik-Optionen prüfen 
SELECT 
name, 
is_auto_update_stats_on AS AutoUpdate, 
is_auto_update_stats_async_on AS AutoUpdate_Async, 
is_auto_create_stats_on AS AutoCreate, 
compatibility_level 
FROM sys.databases 
WHERE database_id > 4; 
 
-- Asynchrones Update aktivieren (empfohlen für OLTP mit kurzen Transaktionen) 
ALTER DATABASE [MeineDatenbank] 
SET AUTO_UPDATE_STATISTICS_ASYNC = ON; 
 
-- Asynchrones Update: Vorsicht – erste Abfrage nach veralteter Statistik 
-- verwendet noch den alten Plan. Nur sinnvoll, wenn kurze Abfragen 
-- wichtiger sind als sofortige Plan-Korrektheit. 
 
-- Automatische Statistikerstellung deaktivieren (selten sinnvoll) 
-- Nur wenn manuelle Kontrolle über alle Statistiken gewünscht: 
ALTER DATABASE [MeineDatenbank] 
SET AUTO_CREATE_STATISTICS = OFF; -- Nur mit vollständiger manueller Verwaltung!
AUTO_UPDATE_STATISTICS = OFF ist fast immer falsch: Die automatische Aktualisierung zu deaktivieren führt in der überwiegenden Mehrheit der Fälle zu deutlich schlechteren Execution Plans. Das ist nur dann sinnvoll, wenn eine Anwendung sehr sensibel auf Plan-Änderungen reagiert und alle Statistiken manuell präzise verwaltet werden. In der Praxis ist das kaum realisierbar.

07
Statistiken · Manuell

Manuelles Statistik-Update – wann und wie

Auch wenn AUTO_UPDATE aktiviert ist, gibt es Situationen, in denen ein manuelles Statistik-Update nötig oder sinnvoll ist.

Wann manuell aktualisieren?

  • Nach einem Bulk-Load oder ETL-Prozess: Massendateneinfügungen verändern die Datenverteilung sofort – auf den automatischen Trigger zu warten kann Stunden dauern.
  • Nach einem REORGANIZE: REORGANIZE aktualisiert Statistiken nicht. Wenn nach einem REORGANIZE sofort bessere Pläne benötigt werden, muss manuell aktualisiert werden.
  • Bei stark schiefen Verteilungen: Spalten mit wenigen, sehr häufigen Werten (z.B. Status-Spalten: 90 % „aktiv", 10 % „inaktiv") profitieren von FULLSCAN.
  • Bei Parametersniffing-Problemen: Veraltete oder ungenaue Statistiken sind häufig die Wurzelursache.
Vorteile manuelles Update
  • FULLSCAN-Option: Liest alle Zeilen – das genaueste mögliche Histogramm. Besonders wichtig bei schiefen Verteilungen.
  • Zeitlich kontrollierbar: Kann in Wartungsfenstern oder nach ETL-Prozessen platziert werden.
  • Selektiv einsetzbar: Nur für kritische Spalten oder Tabellen, wo Stichproben nicht reichen.
  • Persistierte Statistiken auf Sekundärrepliken (SQL 2025): Statistiken bleiben nach Failover erhalten – weniger Kaltstart-Probleme.
Nachteile manuelles Update
  • FULLSCAN ist I/O-intensiv: Bei großen Tabellen (mehrere Hundert GB) kann ein FULLSCAN lange dauern und erheblichen I/O verursachen.
  • Plan-Invalidierung: Nach einem Statistik-Update werden gecachte Execution Plans ungültig und müssen neu kompiliert werden – kurzfristig erhöhte CPU-Last.
  • Wartungsaufwand: Manuelle Verwaltung aller Statistiken erfordert genaue Kenntnis der Datenstruktur und regelmäßige Überprüfung.
T-SQL – Manuelles Statistik-Update in verschiedenen Varianten
-- Alle Statistiken einer Tabelle mit Stichprobe aktualisieren 
UPDATE STATISTICS dbo.Transaktion; 
 
-- FULLSCAN – liest alle Zeilen, genauestes Histogramm 
UPDATE STATISTICS dbo.Transaktion WITH FULLSCAN; 
 
-- Einzelne Statistik mit FULLSCAN (für kritische Spalten) 
UPDATE STATISTICS dbo.Transaktion IX_Transaktion_Datum WITH FULLSCAN; 
 
-- Stichprobengröße explizit setzen (Kompromiss zwischen Genauigkeit und Geschwindigkeit) 
UPDATE STATISTICS dbo.Transaktion WITH SAMPLE 30 PERCENT; 
 
-- Alle Statistiken der Datenbank (alle Tabellen, Stichprobe) 
EXEC sp_updatestats; 
 
-- Veralteteste Statistiken identifizieren (kandidaten für manuelles Update) 
SELECT TOP 20 
OBJECT_NAME(s.object_id) AS Tabelle, 
s.[name] AS Statistik, 
STATS_DATE(s.object_id, s.stats_id) AS LetzteAktualisierung, 
sp.modification_counter AS Änderungen, 
sp.rows, 
sp.rows_sampled 
FROM 
sys.stats s 
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp 
WHERE 
s.object_id > 100 -- Systemtabellen ausblenden 
AND sp.rows > 0 
ORDER BY 
sp.modification_counter DESC;

08
Kombination

Zusammenspiel von Index-Wartung und Statistiken

Index-Wartung und Statistik-Update sind keine identischen Operationen, beeinflussen sich aber gegenseitig. Die folgende Tabelle zeigt, was welche Operation bewirkt:

OperationFragmentierung beseitigt?Fill Factor angewendet?Statistiken aktualisiert?Stichprobe oder FULLSCAN?
ALTER INDEX … REORGANIZE Ja (Blattknoten) Nein Nein
ALTER INDEX … REBUILD Ja (vollständig) Ja Ja FULLSCAN-äquivalent
UPDATE STATISTICS … WITH FULLSCAN Nein Nein Ja FULLSCAN (alle Zeilen)
UPDATE STATISTICS (Standard) Nein Nein Ja Stichprobe (~30 %)
sp_updatestats Nein Nein Nur veränderte Stichprobe

Die häufigste Fehler-Kombination

Fehler 1 – REORGANIZE ohne anschließendes Statistik-Update: REORGANIZE verbessert die physische Struktur, lässt aber veraltete Statistiken unberührt. Wenn ein schlechter Execution Plan durch veraltete Statistiken verursacht wird, hilft ein REORGANIZE gar nicht.
Fehler 2 – Tägliches REBUILD aller Indizes: Tägliche REBUILDs auf wenig fragmentierten Indizes verschwenden Ressourcen, produzieren unnötiges Log-Volumen und können die Datenbank während des Vorgangs verlangsamen. Statistiken, die durch den REBUILD frisch sind, können durch das direkt folgende OLTP-Volumen wieder veralten, bevor die Abfragen des nächsten Tages laufen.
Fehler 3 – Statistik-Update nach REBUILD: Da REBUILD bereits die Statistiken mit FULLSCAN aktualisiert, ist ein unmittelbar danach ausgeführtes UPDATE STATISTICS redundant und verschwendet Ressourcen.

Empfohlene Reihenfolge in einem Wartungszyklus

  1. Fragmentierung messen (sys.dm_db_index_physical_stats)
  2. Stark fragmentierte Indizes REBUILD-en (Statistiken inklusive)
  3. Moderat fragmentierte Indizes REORGANIZE-n
  4. Nach REORGANIZE: UPDATE STATISTICS für reorganisierte Tabellen ausführen
  5. Für Tabellen mit kritischen Spaltenverteilungen: UPDATE STATISTICS … WITH FULLSCAN
  6. sp_updatestats für alle übrigen veränderten Statistiken am Ende

09
Praxis

Wartungsstrategie – ein praktischer Rahmen

Eine gute Wartungsstrategie ist adaptiv, nicht starr. Sie misst zuerst, handelt dann gezielt – und unterscheidet sich je nach Speichertyp, Edition und Workloadcharakter.

Wartungsskript: adaptiv und ressourcenschonend

T-SQL – Adaptives Wartungsskript (vereinfacht nach Ola Hallengren-Prinzip)
-- Adaptives Index-Wartungsskript 
-- Fragmentierung messen → Aktion entscheiden → ausführen 
DECLARE 
@Tabelle NVARCHAR(256), 
@Index NVARCHAR(256), 
@Frag FLOAT, 
@Seiten BIGINT, 
@SQL NVARCHAR(2000); 
 
DECLARE cur CURSOR FOR 
SELECT 
QUOTENAME(SCHEMA_NAME(t.schema_id)) + '.' + QUOTENAME(t.[name]), 
QUOTENAME(i.[name]), 
ips.avg_fragmentation_in_percent, 
ips.page_count 
FROM 
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ips 
INNER JOIN sys.indexes i 
ON ips.object_id = i.object_id AND ips.index_id = i.index_id 
INNER JOIN sys.tables t 
ON i.object_id = t.object_id 
WHERE 
ips.page_count > 1000 -- Kleine Indizes überspringen 
AND ips.avg_fragmentation_in_percent > 10 
AND i.type_desc IN ('CLUSTERED', 'NONCLUSTERED') 
ORDER BY ips.avg_fragmentation_in_percent DESC; 
 
OPEN cur; 
FETCH NEXT FROM cur INTO @Tabelle, @Index, @Frag, @Seiten; 
 
WHILE @@FETCH_STATUS = 0 
BEGIN 
IF @Frag > 30 
BEGIN 
SET @SQL = 'ALTER INDEX ' + @Index + ' ON ' + @Tabelle 
 + ' REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,' 
 + ' STATISTICS_NORECOMPUTE = OFF);'; 
PRINT 'REBUILD: ' + @Tabelle + ' | ' + @Index 
+ ' | Frag: ' + CAST(@Frag AS VARCHAR(10)) + '%'; 
END 
ELSE 
BEGIN 
SET @SQL = 'ALTER INDEX ' + @Index + ' ON ' + @Tabelle 
 + ' REORGANIZE;'; 
PRINT 'REORGANIZE: ' + @Tabelle + ' | ' + @Index 
+ ' | Frag: ' + CAST(@Frag AS VARCHAR(10)) + '%'; 
END 
 
EXEC sp_executesql @SQL; 
 
FETCH NEXT FROM cur INTO @Tabelle, @Index, @Frag, @Seiten; 
END 
 
CLOSE cur; DEALLOCATE cur; 
 
-- Abschließend: Statistiken für reorganisierte Tabellen aktualisieren 
EXEC sp_updatestats;
Empfehlung – Ola Hallengrens Maintenance Solution: Das oben gezeigte Skript illustriert das Prinzip. In produktiven Umgebungen empfiehlt sich der Einsatz von Ola Hallengrens frei verfügbarer Maintenance Solution (IndexOptimize und StatisticsUpdate). Sie implementiert dasselbe adaptive Prinzip, berücksichtigt aber zusätzlich Columnstore-Indizes, LOB-Komprimierung, Partition-Awareness, online/offline-Entscheidung per Edition und detailliertes Logging.

Wartungsempfehlungen nach Szenario

SzenarioIndex-WartungStatistik-UpdateFrequenz
OLTP, HDD, hohes DML-Volumen Adaptiv (REORGANIZE/REBUILD nach Schwellenwert) AUTO + wöchentlich FULLSCAN für kritische Tabellen Index täglich messen, Aktion bei Bedarf
OLTP, SSD Nur REBUILD wenn interne Frag. hoch; Fill Factor optimieren AUTO_UPDATE reicht, nach ETL manuell Wöchentlich messen, selten handeln
Data Warehouse (nächtliches ETL) REBUILD nach jedem ETL auf veränderte Tabellen FULLSCAN nach ETL für veränderte Tabellen Nach jedem ETL-Zyklus
Reporting (überwiegend lesend) Monatlich, niedrige Priorität FULLSCAN monatlich; AUTO_UPDATE für den Rest Monatlich oder bei Plan-Problemen
AlwaysOn Sekundäre (lesend) REBUILD auf Primary (Sekundäre profitieren automatisch) Statistiken auf Sekundäre werden seit SQL 2025 persistiert Wie Primary-Wartung
Fazit: Weder blindes tägliches REBUILD noch vollständiges Nichtstun sind die richtige Antwort. Eine adaptive Strategie, die Fragmentierung misst und gezielt handelt, ist die effizienteste Wartungsform. In Kombination mit dem dynamischen Statistik-Schwellenwert (Kompatibilitätslevel 130+) und AUTO_UPDATE_STATISTICS bleiben die meisten SQL-Server-Umgebungen ohne aufwendige manuelle Eingriffe performant. Manuelles FULLSCAN-Update sollte gezielt für kritische Tabellen nach Massenladeoperationen eingesetzt werden – nicht als Ersatz für das automatische Update, sondern als Ergänzung.
MS SQL Server · Indexoptimierung & Statistik-Update · Datenbankwartung · Stand: April 2026