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.
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 – idealerweise in der logischen Reihenfolge der Schlüsselwerte. Fragmentierung entsteht, wenn diese Reihenfolge durch INSERT-, UPDATE- und DELETE-Operationen zerfällt.
Zwei Arten der Fragmentierung
| Art | Was passiert | Auswirkung | Messwert |
|---|---|---|---|
| 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 |
Fragmentierung messen
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;
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.
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.
- 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.
- 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 = ONangesprochen werden.
-- 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;
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.
- 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.
- 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 = ONblockiert REBUILD den Lesezugriff auf die Tabelle während der gesamten Operation. - ONLINE-Option nur in Enterprise/Developer:
ONLINE = ONist 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.
-- 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 = 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.
Entscheidungsrahmen – wann was
Die klassischen Schwellenwerte (10 % / 30 %) stammen aus einer Zeit dominanter HDDs. Sie sind ein guter Ausgangspunkt, aber nicht das einzige Kriterium.
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 Factor | Geeignet für | Nachteil |
|---|---|---|
| 100 (0) | Read-Only oder Insert-Only-Tabellen (stets am Ende) | Sofortige Fragmentierung bei Updates im mittleren Bereich |
| 90–95 | Wenig volatile Tabellen (Stammdaten, Kataloge) | Geringe interne Fragmentierungsreserve |
| 75–85 | Standard für OLTP-Tabellen mit gleichmäßigem DML | Mehr Seiten bei gleichem Datenvolumen |
| 60–70 | Hotspot-Tabellen mit vielen Inserts/Updates auf denselben Schlüsselbereichen | Deutlich mehr Speicherbedarf, mehr I/O |
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
-- 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öße | SQL Server < 2016 | SQL Server 2016+ (TF 2371 oder Compat. 130+) |
|---|---|---|
| < 500 Zeilen | 500 Änderungen | 500 Änderungen |
| 500 – 25.000 Zeilen | 500 + 20 % der Zeilen | Dynamisch: √(1000 × Zeilenanzahl) |
| > 25.000 Zeilen | 20 % der Zeilenzahl | Dynamisch: √(1000 × Zeilenanzahl) |
√(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.
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.
- 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 = ONwird die Aktualisierung im Hintergrund durchgeführt – die laufende Abfrage wartet nicht.
- 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.
-- 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!
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.
- 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.
- 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.
-- 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;
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:
| Operation | Fragmentierung 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
UPDATE STATISTICS redundant und verschwendet Ressourcen.
Empfohlene Reihenfolge in einem Wartungszyklus
- Fragmentierung messen (
sys.dm_db_index_physical_stats) - Stark fragmentierte Indizes REBUILD-en (Statistiken inklusive)
- Moderat fragmentierte Indizes REORGANIZE-n
- Nach REORGANIZE:
UPDATE STATISTICSfür reorganisierte Tabellen ausführen - Für Tabellen mit kritischen Spaltenverteilungen:
UPDATE STATISTICS … WITH FULLSCAN sp_updatestatsfür alle übrigen veränderten Statistiken am Ende
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
-- 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;
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
| Szenario | Index-Wartung | Statistik-Update | Frequenz |
|---|---|---|---|
| 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 |