Index-Maintenance mit Ola Hallengren’s Script – Best Practices und Tipps

Ein Post im SQL Server Subreddit hat mich diese Woche auf eine gute Frage gestoßen: Wie kann ich das Skript von Ola Hallengren für die Indexpflege optimieren oder besser anpassen? Der Nutzer war mit dem Standardverhalten nicht ganz zufrieden und fragte nach Best Practices und konkreten Tipps aus der Community.

Ein guter Anlass, das Thema einmal strukturiert aufzugreifen und aus meiner Sicht – als langjähriger DBA mit zahlreichen produktiven Umgebungen – zusammenzufassen, was wichtig ist, worauf du achten solltest und wo man das Skript sinnvoll anpassen kann.

Link zum Reddit-Post: https://www.reddit.com/r/SQLServer/comments/1ivf8j8/index_maintenance_with_ola_hallengrens_script/

Warum überhaupt Index-Maintenance?

Mit der Zeit fragmentieren Indizes – besonders bei stark frequentierten OLTP-Systemen. Das kann zu Performance-Problemen führen: langsamere Abfragen, erhöhtes I/O, suboptimale Ausführungspläne. Die regelmäßige Pflege deiner Indizes ist daher Pflichtprogramm in jeder produktiven SQL Server Umgebung.

Dabei gilt:

• Nicht jeder Index muss bei jeder Ausführung gewartet werden.
• Nicht jede Fragmentierung ist kritisch.
• Rebuilds sind teuer – Reorganize ist oft die bessere Wahl.

Das Skript ist modular aufgebaut, flexibel, gut dokumentiert und über Jahre in zig Umgebungen erprobt. Es wird von Microsoft selbst empfohlen und ist meiner Meinung nach der De-facto-Standard für SQL Server Wartung.

Ein typischer Aufruf zur Indexpflege:

EXECUTE dbo.IndexOptimize
    @Databases = 'USER_DATABASES',
    @FragmentationLow = NULL,
    @FragmentationMedium = 'INDEX_REORGANIZE',
    @FragmentationHigh = 'INDEX_REBUILD',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30,
    @UpdateStatistics = 'ALL';

Diese Konfiguration sagt:

• Unter 5 % Fragmentierung: nichts tun
• Zwischen 5–30 %: Reorganize
• Über 30 %: Rebuild
• Im Anschluss: Statistiken aktualisieren

Best Practices für den produktiven Einsatz

Wenn du Probleme mit dem Default oder spezielle Anforderungen hast, dann könnte man sich über die folgenden Punkte Gedanken machen. Es kann unter Umständen auch hilfreich sein zu prüfen, ob man zwingend alle Primary Keys pflegen muss => hier kommt es auf die Tabellen-Struktur und die Art des PK an…

Jobs nach Aufgaben splitten Gerade in größeren Umgebungen lohnt es sich, die Wartungsschritte in separate Jobs aufzuteilen. So kannst du zum Beispiel die Rebuilds nur am Wochenende laufen lassen, Reorganize täglich und Statistik-Updates noch einmal separat planen. Das erhöht nicht nur die Flexibilität bei der Planung, sondern macht auch die Fehleranalyse einfacher – denn du siehst sofort, welcher Teil der Wartung gegebenenfalls Probleme bereitet.

Nicht pauschal alles in einem Schritt machen Trenne Rebuilds und Reorganize in eigene Jobs – so hast du bessere Kontrolle über Laufzeiten und Last.

Zeitfenster berücksichtigen Rebuilds erzeugen viel I/O – besser nachts oder am Wochenende einplanen, Reorganize ggf. täglich.

Online Rebuild aktivieren (Enterprise Edition)

@Indexes = 'ALL_INDEXES',
@PageLocks = 'Y',
@SortInTempdb = 'Y',
@MaxDOP = 4,
@AllowPageLocks = 'Y',
@Online = 'Y'

Achte auf Lizenzen: Online Rebuild geht nur in der Enterprise Edition!

Job-Logging aktivieren Aktiviere Protokollierung über @LogToTable = ‚Y‘, um Historien aufzubauen und Probleme schneller zu erkennen.

Indizes gezielt ausschließen Manche Indizes (z. B. auf Archiv-Tabellen) müssen nicht gewartet werden:

@Indexes = 'ALL_INDEXES, -dbo.ArchiveTable.IX_Archive_SomeColumn'

Statistiken separat aktualisieren (Optional) Falls du sehr große Tabellen hast, lohnt es sich, Statistiken separat zu aktualisieren.

Fazit: Flexibel, aber mit Bedacht konfigurieren

Ola Hallengren’s Script ist ein kraftvolles Werkzeug – aber du solltest es nicht einfach nur blind laufen lassen. Passe es auf deine Umgebung an:

• Serverlast und Zeitfenster berücksichtigen
• Fragmentierungsschwellen je nach Workload setzen
• Logging und Monitoring aktivieren
• Rebuild vs. Reorganize gezielt einsetzen

Gerade wenn du 3rd-Party-Backup-Tools nutzt oder bestimmte Zeitvorgaben einhalten musst, solltest du die Konfiguration bewusst und dokumentiert setzen.

Wenn du Fragen zur Feinabstimmung hast oder wissen willst, wie ich das in deinen konkreten Umgebungen löse – melde dich gerne! 😊

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.