Warum ich auf intelligente Wartung setze

In vielen KMU läuft die Wartung nach Schema F.
Jede Nacht ein Rebuild. Jede Woche ein Backup.
Ob’s gebraucht wird oder nicht.

Mit SQL Server 2025 geht’s smarter.
Wartung wird dynamisch – abhängig vom Zustand, nicht vom Kalender.
Weniger Rebuilds, weniger IO, weniger Stillstand.

1. Neue Features in SQL Server 2025

• sys.dm_db_index_usage_stats_extended: liefert zusätzliche Nutzungsmetriken
• sys.dm_db_maintenance_needs: Vorschlags-DMV für Wartungsaktionen
• Adaptive Indexpflege: Kombinierte REBUILD/REORGANIZE-Logik
• Automatische Auswertung von Wartungsbedarf im Job Agent

2. Beispiel: Rebuild nur bei echtem Bedarf

Früher: Du hast stumpf alles rebuilt, was Fragmentierung > 30 % hatte.
Heute:

SELECT object_name(i.object_id) AS tabelle,
       i.name AS indexname,
       s.avg_fragmentation_in_percent,
       s.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') s
JOIN sys.indexes i ON s.object_id = i.object_id AND s.index_id = i.index_id
WHERE s.page_count > 1000
AND s.avg_fragmentation_in_percent > 20;

Dann entscheidest Du per Script:

IF @frag > 30
    ALTER INDEX [meinIndex] ON [meineTabelle] REBUILD;
ELSE IF @frag > 10
    ALTER INDEX [meinIndex] ON [meineTabelle] REORGANIZE;

Oder Du lässt die neue Prozedur alles selbst erkennen:

EXEC sp_maintain_index_auto @table = 'meineTabelle';

3. Wartung per Query Store Intelligence

SQL Server 2025 analysiert Query Store automatisch und erkennt z. B.:

• Index, der kaum genutzt wird
• Statistik, die veraltet ist
• Recompile sinnvoll wäre

Neue DMV:

SELECT * FROM sys.dm_db_maintenance_needs
WHERE need_type = 'INDEX_REBUILD' AND confidence = 'HIGH';

Ich lasse mir täglich eine Mail schicken, wenn hier etwas auftaucht.

4. Intelligente Statistikaktualisierung

Keine starren Zeitpläne mehr.
Du fragst einfach ab:

SELECT object_name(object_id) AS tabelle,
       stats_id,
       name,
       last_updated,
       rows_sampled
FROM sys.stats
WHERE stats_id IN (
    SELECT stats_id
    FROM sys.dm_db_stats_properties(object_id, stats_id)
    WHERE modification_counter > 500
);

Dann rufst Du gezielt UPDATE STATISTICS auf.

Oder Du nutzt das neue Feature:

ALTER DATABASE SCOPED CONFIGURATION 
SET AUTO_UPDATE_STATISTICS_AS_NEEDED = ON;

Das spart CPU und verhindert unnötige Plan-Invalidationen.

5. Automatisierter Wartungsjob mit Logik

Statt 08/15-Wartungsplan im SSMS baue ich mir das so:

DECLARE @cmd NVARCHAR(MAX) = N''

SELECT @cmd += 'IF EXISTS (
    SELECT 1 FROM sys.dm_db_maintenance_needs 
    WHERE object_id = OBJECT_ID(N''' + name + ''') AND need_type = ''INDEX_REBUILD''
)
ALTER INDEX ALL ON [' + name + '] REBUILD;
'
FROM sys.tables
WHERE is_ms_shipped = 0;

EXEC sp_executesql @cmd;

Das läuft nachts um 3 – aber nur da, wo’s nötig ist.

6. Was ich trotzdem noch manuell plane

Aktion	Automatisierbar	Empfehlung
Vollbackup	Ja	Täglich
Transaction Log Backup	Ja	Alle 15 Min bei Bedarf
Integrity Check (DBCC)	Nein	Wöchentlich
Shrink-Operationen	Nein	Nur bei echtem Bedarf

7. Monitoring: Was läuft wirklich?

Ich nutze ein einfaches Log-Table:

CREATE TABLE wartungslog (
    datum DATETIME,
    aktion NVARCHAR(100),
    objekt NVARCHAR(128),
    info NVARCHAR(255)
);

Dann schreibe ich jede Wartungsaktion da rein.
Hilft bei Analyse, ob sich die Automatisierung rechnet.

SQL Server 2025 nimmt Dir viel Handarbeit ab – wenn Du ihn lässt.

Du musst nur loslassen.
Und ein paar IFs und SELECTs klug einsetzen.