Klartext: SQL Server läuft nicht von allein

Der SQL Server ist kein Toaster. Du kannst ihn nicht einfach hinstellen und vergessen.

Wenn Du die Wartung schleifen lässt, zahlst Du irgendwann drauf. Entweder mit Zeit. Oder mit Datenverlust. Oder mit einer durchgeglühten CPU am Montagmorgen.

Ich sag’s Dir, wie’s ist: Du brauchst einen Plan. Einen, den Du auch durchziehst.

Was regelmäßig getan werden muss

• Backups
• Indexpflege
• Statistiken aktualisieren
• Logfile-Größe kontrollieren
• TempDB im Blick behalten
• Fehlerprotokolle prüfen
• Wartungspläne regelmäßig testen

Tägliche Basics: Backups

Jeden Tag ein Full-Backup. Jede Stunde ein Log-Backup – bei produktiven Systemen.

-- Vollbackup
BACKUP DATABASE MeineDatenbank
TO DISK = 'D:\Backup\MeineDatenbank_FULL.bak'
WITH INIT, STATS = 5;

-- Transaktionslog sichern
BACKUP LOG MeineDatenbank
TO DISK = 'D:\Backup\MeineDatenbank_LOG.trn'
WITH INIT, STATS = 5;

Ohne das? Kannst Du eine Woche Arbeit verlieren. Oder gleich die ganze Firma.

Indexe pflegen – sonst wird’s lahm

Ab 5 % Fragmentierung: Reorganize.
Ab 30 % Fragmentierung: Rebuild.

-- Automatisiertes Rebuild nach Fragmentierungsgrad
DECLARE @TableName NVARCHAR(128)
DECLARE @IndexName NVARCHAR(128)
DECLARE @SQL NVARCHAR(MAX)

DECLARE IndexCursor CURSOR FOR
SELECT 
    OBJECT_NAME(ips.object_id), 
    i.name
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 30 AND i.index_id > 0

OPEN IndexCursor  
FETCH NEXT FROM IndexCursor INTO @TableName, @IndexName  

WHILE @@FETCH_STATUS = 0  
BEGIN  
    SET @SQL = 'ALTER INDEX [' + @IndexName + '] ON [' + @TableName + '] REBUILD;'  
    EXEC(@SQL)  
    FETCH NEXT FROM IndexCursor INTO @TableName, @IndexName  
END  

CLOSE IndexCursor  
DEALLOCATE IndexCursor  

Ohne Indexpflege wird jede Abfrage langsam. Und zwar richtig.

Statistiken: SQL Server braucht sie

Wenn Du die nicht regelmäßig aktualisierst, schätzt der Optimizer ins Blaue. Mit Pech plant er Dir ein Hash Join auf 10 Millionen Zeilen, obwohl’s nur 200 waren.

-- Statistiken aktualisieren
EXEC sp_updatestats;

Einmal die Woche reicht. Außer Du hast viele Änderungen – dann öfter.

TempDB: Das stille Leiden

Wenn TempDB zu klein ist, läuft alles aus dem Ruder. Sortierungen. Joins. Worktables.

• Nutze mehrere Dateien (gleiche Größe).
• Kontrolliere Auto-Growth.
• Setze Initialgröße sinnvoll.

-- TempDB-Dateien prüfen
SELECT name, size * 8 / 1024 AS SizeMB, physical_name
FROM sys.master_files
WHERE database_id = 2;

Logs im Auge behalten

SQL Server protokolliert viel. Die meisten gucken nie rein.

Schau regelmäßig ins SQL Server Error Log und ins Windows-Eventlog. Da steht oft schon Tage vorher drin, dass was schiefläuft.

-- Letzte Fehler anzeigen
EXEC xp_readerrorlog 0, 1, N'error', NULL, NULL, NULL, N'desc';

Was im schlimmsten Fall passiert

• Transaktionslog läuft voll → Kein Schreiben mehr möglich
• Keine Backups → Kein Restore nach Hardware-Crash
• Index zerschossen → Abfragen laufen minutenlang
• TempDB überläuft → Komplettes System hängt
• Keine Überwachung → Festplatte voll, ohne dass es einer merkt
• Autogrowth mitten im Tagesbetrieb → Freeze

Und dann klingelt um 5 Uhr früh das Telefon. Herzlichen Glückwunsch.

Mein Tipp: Wartung automatisieren

Setz Wartungspläne auf. Oder nutze Ola Hallengrens Skripte. Die laufen sauber, sind konfigurierbar und machen’s Dir leicht.

Link: https://ola.hallengren.com/

Wenn Du’s manuell machst – vergisst Du’s. Ist so.

Kleine Tabelle: Was wie oft?

Aufgabe	Häufigkeit
Full Backup	täglich
Log Backup	stündlich
Index Reorganize	wöchentlich
Index Rebuild	monatlich
sp_updatestats	wöchentlich
TempDB prüfen	monatlich
Fehlerprotokolle checken	wöchentlich

Was ich immer wieder sehe

• „Ja, machen wir irgendwann mal.“
• „Läuft doch alles.“
• „Kein Budget für Admin.“

Dann kracht’s. Und dann ist plötzlich Geld da. Für Notfall-Restore, Recovery und Rufschädigung.

Mach’s besser. Automatisiere. Und zieh’s durch.