Still und leise kaputt: Was bei SQL Server in KMU oft fehlt

Um was es geht

Hinter fast jeder Business-Software (Buchhaltung wie Infoniqa ONE 50, ERP, Lohn) läuft eine Datenbank, oft ein Microsoft SQL Server. SQL Server ist ein Produkt, das seit Jahrzehnten auf dem Markt ist und generell extrem zuverlässig arbeitet.

Genau das ist das Problem: Fehlende Wartung fällt oft nicht auf. Bis Daten weg sind, das Backup nicht funktioniert oder eine Sicherheitslücke ausgenutzt wird.

Besonders häufig treffen wir dieses Szenario in kleineren Betrieben mit einem externen IT-Partner. Mit dem Beitrag zeige ich dir drei Punkte, die häufig auffallen, und wie man sie angeht.

Warum Wartung in KMU eher vergessen geht

In grossen Unternehmen mit IT-Abteilungen gibt es meist dedizierte Teams (DBAs), welche sich ausschliesslich um die Datenbankserver kümmern.

 In einem KMU sieht es anders aus: Der Administrator, falls es einen gibt, kümmert sich um alles gleichzeitig. Netzwerk, Drucker, Benutzer, Exchange usw.  Der SQL Server gehört im Alltag oft nicht zu den Komponenten,  die laut nach Aufmerksamkeit verlangen.

Dazu kommt ein Dreieck, das ich immer wieder antreffe:

• Der interne Administrator geht davon aus, dass sich der Software-Lieferant oder externe IT Partner dann schon um den SQL Server kümmere.
• Die IT-Firma betreut Server und Netzwerk, sieht die Datenbank aber als Teil der Business-Software
• Der ERP- oder Softwarelieferant liefert seine Anwendung aus und geht davon aus, dass die IT für den Betrieb der Datenbank zuständig ist.

Das Ergebnis: Alle denken, jemand anders kümmere sich darum. In Tat und Wahrheit macht es niemand. Weil der Server ja «läuft», fällt es folglich niemanden auf.

Dazu kommen zwei weitere Muster:

• Wartung bringt keinen sichtbaren Nutzen. Solange nichts passiert, sieht man nicht, was sie verhindert.
• Einmal installiert, nie mehr angeschaut. Die SQL-Server-Lizenz wurde gekauft, die Instanz installiert, der Agent-Job angelegt, danach aber nie mehr angeschaut.

Still gescheitert #1: Agent-Jobs ohne Überwachung

Backups, Index-Wartung, Konsistenzprüfungen: Das alles läuft beim SQL Server über Jobs im SQL Server Agent. Diese Jobs können fehlschlagen, wegen eines vollen Laufwerks, eines geänderten Passworts oder eines umbenannten Pfads. Ohne Benachrichtigung merkt das niemand.

Was ich in der Praxis oft sehe: Jobs sind eingerichtet, aber Database Mail ist nicht konfiguriert, es gibt keinen Operator, und bei keinem Job ist «Benachrichtigung bei Fehler» aktiviert. Der Job-Verlauf ist voller roter Einträge, die nie jemand angeschaut hat.


Schreckbefund, Upps:

Unser Minimum-Standard:

• Database Mail einrichten und testen
• Einen Operator anlegen, idealerweise mit einer Gruppenadresse statt einer Einzelperson
• Bei jedem Job «Bei Fehler benachrichtigen» aktivieren
• Alerts für schwere Fehler einrichten: Severity 19 bis 25 sowie die Fehler 823, 824 und 825. Die letzten drei deuten auf Probleme beim Lesen oder Schreiben der Datenbankdateien hin und sind oft das erste Anzeichen für eine Korruption.

Still gescheitert #2: Kein CHECKDB

DBCC CHECKDB prüft, ob die Datenbank in sich konsistent ist. Wenn es zu Korruption kommt, ist häufig eine defekte Festplatte oder ein Problem im Storage die Ursache dafür.

Und hier liegt der Punkt, der oft unterschätzt wird: Ein Backup einer korrupten Datenbank ist und bleibt ein korruptes Backup. Wird die Korruption erst entdeckt, wenn alle älteren Backups bereits gelöscht sind, kann man nicht mehr auf einen sauberen Stand restoren.

Minimum-Standard:

• CHECKDB mindestens wöchentlich über alle Datenbanken laufen lassen
• Die Aufbewahrung der Backups so wählen, dass sie länger ist als das Intervall zwischen zwei Prüfungen
• Den CHECKDB-Job natürlich ebenfalls überwachen

Still gescheitert #3: Kein Patching

Beim Patching sehe ich die grössten Lücken. Erschreckend viele Server laufen noch mit dem Stand der Erstinstallation, manchmal seit Jahren…

Im heutigen AI-Zeitalter ist Patching wichtiger denn je. Täglich werden neue Schwachstellen gefunden, auch in SQL Server. Viele Firmen und kleine IT Teams denken an das Patching der Firewall, Windows Server usw. SQL Server wird viel vernachlässigt, oder keiner möchte ein Risiko auf sich nehmen.

So wird aus «lieber nichts kaputt machen» schleichend ein viel grösseres Risiko: ein Server mit bekannten, aber nie geschlossenen Sicherheitslücken.

Was viele zudem nicht wissen: Seit SQL Server 2017 gibt es keine Service Packs mehr (Quelle)

Microsoft liefert stattdessen regelmässig Cumulative Updates (CU) aus, die alle Korrekturen enthalten. Daneben gibt es GDR-Updates, die ausschliesslich Sicherheits-Fixes enthalten.

Wichtig zu wissen: Viele CUs enthalten auch wichtige Korrekturen wie Korruption, Ausbau und Stabilität. Wer viel Geld in SQL Server investiert hat, ist gut beraten, die CU- und GDR Updates zu installieren.

Dazu kommt das Support-Ende: Ältere Versionen erhalten irgendwann keine Sicherheitsupdates mehr. Wer darauf arbeitet, betreibt eine Datenbank mit bekannten, aber nicht mehr behobenen Lücken. Zum Beispiel erhält der SQL Server 2016 keine Updates mehr, sein EOL ist am 14. Juli 2026

Mein Minimum-Standard:

• Zuständigkeit schriftlich klären: Wer patcht den SQL Server, wer gibt frei, wer testet die Software danach? Ein kurzer Satz im Wartungsvertrag oder in der Betriebsdokumentation reicht oft schon.
• Einen festen Patch-Rhythmus definieren, mindestens einmal pro Quartal. Vor dem Update ein Backup erstellen und einen Snapshot der VM anlegen.
• Einen Rollback-Plan haben: Was mache ich, wenn die Software nach dem Update nicht mehr läuft?

Selbsttest: Wie steht es um deinen SQL Server?

Mit den folgenden Abfragen kannst du in wenigen Minuten den Zustand deines Servers prüfen.

Wann lief der letzte erfolgreiche CHECKDB?

SELECT name,
       DATABASEPROPERTYEX(name, 'LastGoodCheckDbTime') AS LastGoodCheckDb
FROM sys.databases
WHERE database_id <> 2
ORDER BY LastGoodCheckDb;

Gibt es bereits erkannte beschädigte Seiten?

SELECT * FROM msdb.dbo.suspect_pages;

Welche Jobs sind in den letzten 7 Tagen fehlgeschlagen?

SELECT j.name,
       msdb.dbo.agent_datetime(h.run_date, h.run_time) AS RunTime,
       h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON j.job_id = h.job_id
WHERE h.step_id = 0
  AND h.run_status = 0
  AND msdb.dbo.agent_datetime(h.run_date, h.run_time)
      > DATEADD(DAY, -7, GETDATE())
ORDER BY RunTime DESC;

Welche Jobs melden Fehler an niemanden?

SELECT name, enabled
FROM msdb.dbo.sysjobs
WHERE notify_level_email = 0;

Sind Operator, Database Mail und Alerts eingerichtet?

SELECT name, email_address, enabled FROM msdb.dbo.sysoperators;
SELECT name FROM msdb.dbo.sysmail_profile;
SELECT name, severity, message_id, enabled, has_notification
FROM msdb.dbo.sysalerts;

Welche Version und welcher Patch-Stand laufen?

SELECT SERVERPROPERTY('ProductVersion')     AS Version,
       SERVERPROPERTY('ProductUpdateLevel') AS CU,
       SERVERPROPERTY('Edition')            AS Edition;

Das Ergebnis vergleichst du mit der aktuellen Build-Liste von Microsoft.

Wann lief das letzte Backup?

SELECT d.name,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS LastFull,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS LastLog,
       d.recovery_model_desc
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name
WHERE d.database_id <> 2
GROUP BY d.name, d.recovery_model_desc
ORDER BY LastFull;

Wann wurde zuletzt ein Restore getestet?

SELECT destination_database_name, restore_date
FROM msdb.dbo.restorehistory
ORDER BY restore_date DESC;

Diese Abfrage zeigt nur Restores auf diesem Server. Ein Test auf einem separaten System erscheint hier nicht.

Die Abkürzung: sp_Blitz

Wer nicht alles einzeln prüfen will, dem empfehle ich wärmstens das kostenlose First Responder Kit von Brent Ozar (auf GitHub). Die Prozedur sp_Blitz prüft den Server in einem Durchgang auf Dutzende bekannte Probleme, darunter fehlende Backups, fehlende CHECKDB-Prüfungen, Jobs ohne Benachrichtigung und veraltete Versionen. Das Ergebnis ist eine priorisierte Liste zum Abbarbeiten.

EXEC sp_Blitz @CheckServerInfo = 1;

Fazit

Gerade in kleinen Unternehmen lohnt es sich, sich ganz bewusst zu fragen: Wer ist bei uns eigentlich für unseren SQL Server zuständig?

Der SQL-Server scheitert selten laut. Er scheitert still: mit einem Job, der seit Monaten fehlschlägt, einer Korruption, die niemand bemerkt, oder einer Version, die längst keine Updates mehr bekommt.

Mache regelmässig CHECKDB, patche deine Instanzen und schlafe ruhiger.