SQL Server Health Check – der Selbsttest
Sechs Bereiche, eine bewusste Reihenfolge – Fundament vor Kür.
SQL Server Health Check — der Selbsttest
Sechs Bereiche, eine bewusste Reihenfolge: So prüfst du deinen Server selbst — bevor er dich prüft.
Beim Auto ist es selbstverständlich: Alle paar Monate fährt es zur Inspektion, und dort schaut jemand systematisch nach Bremsen, Öl, Reifen und Lichtern — nicht weil gerade etwas kaputt ist, sondern damit nichts kaputtgeht. Beim SQL Server fehlt diese Kultur erstaunlich oft. Da läuft eine Datenbank fünf Jahre durch, niemand schaut hin, solange sie „funktioniert“ — und dann, an einem Dienstagmorgen, kommt die Quittung gleich im Dreierpack: Das Backup war seit Monaten kaputt, die letzte Konsistenzprüfung stammt aus der Installationswoche, und in der sysadmin-Rolle steht ein Konto, von dem niemand mehr weiß, wem es gehört.
Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) ist die Inspektion, die du deinem Server selbst geben kannst. Anders als die akuten Beiträge der ROT- und GELB-Stufe behandelt er kein einzelnes Symptom, sondern liefert die strukturierte Gesamtprüfung: sechs Bereiche, eine bewusste Reihenfolge, konkrete Abfragen. Wer diesen Check zweimal im Jahr fährt, erlebt die meisten Notfälle der anderen Beiträge gar nicht erst — weil er sie als kleine Auffälligkeit findet, lange bevor sie zur Katastrophe werden. Das ist der ganze Geist der GRÜN-Stufe: prüfen, solange es ruhig ist.
Was ein Health Check ist — und warum die Reihenfolge zählt
Ein Health Check ist keine wilde Sammlung von Abfragen, sondern eine geordnete Durchsicht der Bereiche, in denen ein SQL Server krank werden kann. Die Kunst liegt weniger in den einzelnen Prüfungen — die sind meist simpel — als in der Vollständigkeit und der Reihenfolge. Denn der häufigste Fehler beim Selbsttest ist, sofort auf die Performance zu schauen, weil die am meisten Spaß macht und am sichtbarsten ist — und dabei das Fundament zu übersehen.
Deshalb folgt dieser Check einer klaren Hierarchie: Zuerst kommt das Fundament — Backup und Wiederherstellbarkeit, Integrität, Sicherheit. Das sind die Bereiche, in denen ein Versäumnis existenzbedrohend ist: Ein verlorenes, nie getestetes Backup kann das Unternehmen kosten, eine unbemerkte Korruption frisst sich durch die Daten, ein offenes sysadmin-Konto ist ein Sicherheitsleck. Erst danach kommt die Kür — Konfiguration, Performance-Baseline, Wartung. Das sind die Bereiche, in denen ein Versäumnis ärgerlich ist: Der Server läuft langsamer, als er müsste. Die Faustregel dahinter ist hart, aber wahr: Existenz schlägt Tempo. Ein blitzschneller Server ohne wiederherstellbares Backup ist ein Unfall mit Anlauf.
Und ein Health Check entfaltet seinen Wert erst über die Zeit. Eine einzelne Durchsicht ist eine Momentaufnahme; ihr eigentlicher Nutzen entsteht im Vergleich mit der letzten. „MAXDOP steht auf 0“ ist eine Feststellung — „MAXDOP steht seit der Migration wieder auf 0, obwohl wir es korrigiert hatten“ ist ein Prozess-Befund. Deshalb gehört jedes Check-Ergebnis dokumentiert, mit Datum, und beim nächsten Mal danebengelegt.
|
Fundament vor Kür — die Prioritäts-Regel Fundament (existenzbedrohend): Backup & Recovery, Integrität, Sicherheit. Ein Versäumnis hier kann das Unternehmen kosten. |
|---|
Die sechs Bereiche im Überblick
Die folgende Übersicht ist der Bauplan des Health Checks — sechs Bereiche mit ihren wichtigsten Prüfpunkten, in der Reihenfolge Fundament zuerst. Sie ist gleichzeitig die Checkliste, die du beim Durchgehen abhakst:
Die Skripte: das Fundament zuerst
Bereich 2 — Backup-Frische je Datenbank
Die wichtigste Einzelabfrage des ganzen Checks. Sie zeigt für jede Datenbank das letzte erfolgreiche Backup je Typ — und deckt sofort auf, wo eine Log-Sicherung fehlt oder ein Voll-Backup uralt ist:
|
— Letztes erfolgreiches Backup je Datenbank und Typ SELECT d.name AS Datenbank, d.recovery_model_desc AS RecoveryModel, MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS LetztesVoll, MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS LetztesDiff, MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS LetztesLog, DATEDIFF(HOUR, MAX(CASE WHEN b.type IN ('D','I') THEN b.backup_finish_date END), GETDATE()) AS StundenSeitDatensicherung FROM sys.databases AS d LEFT JOIN msdb.dbo.backupset AS b ON b.database_name = d.name WHERE d.database_id > 4 AND d.state_desc = 'ONLINE' GROUP BY d.name, d.recovery_model_desc ORDER BY StundenSeitDatensicherung DESC; |
|---|
Steht bei einer FULL-Recovery-Datenbank ein uraltes LetztesLog, hast du gleich zwei Probleme gefunden: ein Recovery-Loch und ein wachsendes Transaktionslog. Aber selbst frische Zahlen beweisen nur, dass geschrieben wurde — den entscheidenden Check, ob ein Restore funktioniert, kann keine Abfrage ersetzen. Der gehört in die Wartungsplanung, und wie man ihn aufsetzt, steht im Backup-Strategie-Beitrag.
Bereich 3 — Integrität: Korruptions-Spuren und Page Verify
|
— Gemeldete defekte Seiten (sollte leer sein!) SELECT DB_NAME(database_id) AS Datenbank, file_id, page_id, event_type, error_count, last_update_date FROM msdb.dbo.suspect_pages;
— Page-Verify-Einstellung je Datenbank (Soll: CHECKSUM) SELECT name, page_verify_option_desc FROM sys.databases WHERE database_id > 4 AND page_verify_option_desc <> 'CHECKSUM'; |
|---|
Die erste Abfrage sollte keine Zeile liefern — jede Zeile ist eine vom Server bemerkte Seitenkorruption und ein Fall für den DBCC-CHECKDB-Beitrag. Die zweite listet Datenbanken, deren PAGE_VERIFY nicht auf CHECKSUM steht — ein häufiges Erbe alter, migrierter Datenbanken, die ohne den modernen Korruptionsschutz laufen. Beides ist in Minuten geprüft und gehört in jeden Check, weil Korruption das Einzige ist, das ein gutes Backup ruinieren kann, indem es sich mitsichern lässt.
Bereich 4 — Sicherheit: Wer darf alles?
|
— Mitglieder der sysadmin-Rolle (gehoert da jeder hin?) SELECT sp.name AS Login, sp.type_desc, sp.is_disabled, sp.create_date, sp.modify_date FROM sys.server_role_members AS rm JOIN sys.server_principals AS sp ON sp.principal_id = rm.member_principal_id JOIN sys.server_principals AS r ON r.principal_id = rm.role_principal_id WHERE r.name = N'sysadmin' ORDER BY sp.name;
— Ist das sa-Konto deaktiviert? SELECT name, is_disabled FROM sys.server_principals WHERE principal_id = 1; |
|---|
Die sysadmin-Liste ist oft eine kleine Zeitreise: Da stehen ehemalige Dienstleister, ein vergessener Test-Account, das persönliche Login eines längst ausgeschiedenen Kollegen. Jeder Eintrag, der nicht zweifelsfrei dort hingehört, ist ein Risiko. Und das sa-Konto sollte deaktiviert oder zumindest umbenannt und mit einem starken Passwort versehen sein — es ist das erste Ziel jedes Angreifers. Sicherheit ist kein Performance-Thema, aber sie gehört aus gutem Grund ins Fundament: Ein kompromittierter Server hat keine Performance-Probleme mehr, sondern ganz andere.
Bereich 1 — Konfiguration: die üblichen Verdächtigen
|
— Wichtige Konfigurationswerte auf einen Blick SELECT name, value_in_use, [description] FROM sys.configurations WHERE name IN ( N'max server memory (MB)', — nicht auf Default-Maximum! N'max degree of parallelism', — MAXDOP N'cost threshold for parallelism', — selten noch beim Default 5 N'optimize for ad hoc workloads') — bei Ad-hoc-Last: 1 ORDER BY name; |
|---|
Die Kür: Performance-Baseline und Wartung
Bereich 5 — die Performance-Baseline
Erst wenn das Fundament steht, lohnt der Blick auf die Geschwindigkeit. Der Performance-Teil des Health Checks ist im Kern eine Baseline: Wait Stats (der Kompass aus dem gleichnamigen Beitrag), Page Life Expectancy, I/O-Latenzen je Datei und die Top-Ressourcenfresser — regelmäßig gemessen und weggeschrieben. Diese vier Größen zusammen ergeben das Normalbild deines Servers, gegen das du im Ernstfall vergleichst. Der entscheidende Punkt: Die Baseline ist nichts, was man im Health Check einmalig prüft — sie ist etwas, das man einrichtet, damit sie laufend misst. Die Skripte für Wait Stats und I/O-Latenz stehen in den jeweiligen Beiträgen; der Health Check stellt nur sicher, dass sie überhaupt laufen und dass der Query Store als langfristiges Gedächtnis aktiv ist.
Bereich 6 — Wartung und Jobs
Der letzte Bereich prüft, ob die Maschinerie im Hintergrund überhaupt läuft. Drei Fragen: Läuft eine Index- und Statistik-Wartung (idealerweise Ola Hallengrens Lösung), oder verlassen sich alle aufs Prinzip Hoffnung? Gibt es fehlgeschlagene Agent-Jobs, die seit Wochen rot sind und die keiner bemerkt? Und die unauffälligen Dauerschäden: ein nie rotiertes, gigantisches ERRORLOG, häufige Autogrow-Events durch zu kleine Startgrößen, eine explodierte VLF-Zahl im Transaktionslog durch eben diese Autogrows. Diese Abfrage findet die roten Jobs:
|
— Agent-Jobs mit zuletzt fehlgeschlagenem Lauf SELECT j.name AS Job, h.run_date, h.run_time, h.message FROM msdb.dbo.sysjobs AS j JOIN msdb.dbo.sysjobhistory AS h ON h.job_id = j.job_id WHERE h.step_id = 0 — Job-Gesamtergebnis AND h.run_status = 0 — 0 = Fehlgeschlagen AND j.enabled = 1 ORDER BY h.run_date DESC, h.run_time DESC; |
|---|
Was du auf keinen Fall tun solltest
|
Die drei häufigsten Anfängerfehler 1. Bei der Performance einsteigen und das Fundament überspringen. Backup, Integrität und Sicherheit sind unsichtbar, bis sie fehlen — und dann ist es zu spät. |
|---|
Vom Check zur Routine: Automatisieren und staffeln
Ein Health Check ist dann am wertvollsten, wenn er nicht von der Disziplin eines einzelnen Menschen abhängt. Drei Schritte machen aus der guten Absicht eine verlässliche Routine: Erstens, das Tagesminimum automatisieren — Backup-Frische und fehlgeschlagene Jobs gehören in einen täglichen Agent-Job mit Alarm, nicht in einen manuellen Wochenblick. Zweitens, die Baseline einrichten, damit Performance-Daten laufend anfallen, statt im Check mühsam erhoben zu werden. Drittens, einen Kalender-Termin für den vollen Check setzen — vierteljährlich, mit der Sechs-Bereiche-Liste als Vorlage und dem letzten Protokoll daneben. So wird aus dem Selbsttest eine Inspektion mit festem Intervall, genau wie beim Auto.
Wer den Check ernst nimmt, stellt schnell fest, dass jeder seiner sechs Bereiche in einen eigenen Notarztwagen-Beitrag mündet — und genau so ist es gedacht: Der Health Check ist die Landkarte, die Detail-Beiträge sind die Länder. Findest du beim Check eine Auffälligkeit, führt dich der passende Beitrag in die Tiefe.
Vertiefung in der Buchreihe
Die vollständige Health-Check-Methodik mit allen Prüflisten und Schwellenwerten verteilt sich in der Buchreihe „SQL Server in der Praxis“ über mehrere Bände — alle in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.
|
Empfohlene Bände Band 1: Performance & Troubleshooting — Konfigurations-Best-Practices, Wait-Stats- und Baseline-Aufbau, Wartungsstrategien: das Fleisch der Kür-Bereiche. |
|---|
Die sechs Bereiche, sechs Vertiefungen
Jeder Befund des Health Checks hat seinen eigenen Beitrag im Notarztwagen — hier die wichtigsten Anschlüsse:
Drei Wege, deinen Server durchzuchecken
Selbst-Diagnose-Kit
Der Health Check ist der Selbsttest schlechthin — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Backup-Frische, Korruptions- und Page-Verify-Check, sysadmin- und sa-Prüfung, Konfigurations-Übersicht, Job-Status — plus die Sechs-Bereiche-Checkliste zum Ausdrucken und eine Protokoll-Vorlage, in die du Datum und Befund einträgst. Damit fährst du die Inspektion in einer guten Stunde komplett durch und hast am Ende ein Dokument, das du beim nächsten Mal danebenlegen kannst.
Festpreis-Analyse
Du willst einmal mit dreißig Jahren Beratungserfahrung über deinen Server schauen lassen — gründlicher, als ein Selbsttest es kann, und mit einer ehrlichen Gesamtnote? Die Festpreis-Analyse ist der professionelle Health Check: alle sechs Bereiche tief geprüft, inklusive echtem Restore-Test, Konfigurations-Bewertung gegen Best Practices und einem schriftlichen Bericht mit priorisierten Maßnahmen — Quick-Wins und strukturelle Empfehlungen getrennt. Zum vereinbarten Festpreis, ohne Stundenzähler.
Akut-Hotline
Wenn der Check eine Auffälligkeit zutage gefördert hat, die du nicht allein einordnen kannst — eine Zeile in suspect_pages, ein rätselhafter sysadmin-Eintrag, ein seit Wochen roter Job: anrufen. Halte das Check-Protokoll bereit, dann klären wir gemeinsam, ob es ein Sofort-Thema ist oder auf die Wartungsliste gehört.
|
Ein letzter Tipp Führe heute die erste Abfrage dieses Beitrags aus — die Backup-Frische je Datenbank. Es ist eine einzige Abfrage, dreißig Sekunden Aufwand, und sie beantwortet die wichtigste Frage überhaupt: Wie alt ist im schlimmsten Fall der Datenstand, auf den du zurückfallen könntest? Wenn dort bei einer wichtigen Datenbank eine unangenehme Zahl steht, hast du gerade den lohnendsten Health-Check-Befund deines Jahres gefunden — und den Rest des Checks gleich mit motiviert. |
|---|
Häufige Fragen (FAQ)
Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.
Wie führe ich einen SQL Server Health Check durch?
Strukturiert, in sechs Bereichen und in bewusster Reihenfolge: erst das Fundament (Backup und Wiederherstellbarkeit, Integrität, Sicherheit), dann die Kür (Konfiguration, Performance-Baseline, Wartung und Jobs). Der Grund für die Reihenfolge ist simpel: Ein blitzschneller Server ohne getestetes Backup ist gefährlicher als ein langsamer mit solider Recovery. Pro Bereich arbeitest du eine kurze Checkliste mit konkreten Abfragen ab — die Skripte stehen in diesem Beitrag. Wichtig ist, das Ergebnis schriftlich festzuhalten und mit der letzten Prüfung zu vergleichen, denn der Wert eines Health Checks liegt im Trend, nicht in der Momentaufnahme.
Welche Konfigurationswerte sollte ich prüfen?
Die wichtigsten Stellschrauben, die erfahrungsgemäß am häufigsten falsch stehen: Max Server Memory (steht es noch auf unbegrenzt?), MAXDOP und Cost Threshold for Parallelism (die Defaults passen selten zu moderner Hardware), die Anzahl und gleiche Größe der tempdb-Dateien, Instant File Initialization (aktiviert?), die Auto-Optionen für Statistiken sowie der Compatibility Level der Datenbanken. Diese Werte liest du gebündelt aus sys.configurations und sys.databases. Falsch gesetzte Konfiguration ist die häufigste Ursache für Probleme, die wie tiefe Performance-Rätsel aussehen, aber in Wahrheit eine Einstellung von vor zehn Jahren sind.
Was ist eine Performance-Baseline?
Eine Performance-Baseline ist die dokumentierte Normallage deines Servers: Wait Stats, Page Life Expectancy, I/O-Latenzen je Datei und die Top-Ressourcenfresser, regelmäßig gemessen und weggeschrieben. Ihr Wert liegt im Vergleich — „PLE bei 2.000“ ist ohne Kontext nur eine Zahl, aber „PLE seit dem letzten Release halbiert“ ist ein Befund. Ohne Baseline diagnostizierst du im Ernstfall gegen Bauchgefühl; mit Baseline gegen Messwerte. Sie ist das Herzstück des Performance-Teils im Health Check und baut direkt auf den Wait Stats auf, die im DBA-Kompass-Beitrag erklärt sind.
Welche Wait Stats sind kritisch?
Kritisch ist immer der Wartetyp, der einen großen Anteil an der Gesamtwartezeit hat — nicht eine feste Liste. Als grobe Orientierung: Dominieren LCK_M_*-Typen, hast du ein Sperr-Thema; PAGEIOLATCH und WRITELOG deuten auf I/O oder Speicher; RESOURCE_SEMAPHORE auf Memory-Druck; SOS_SCHEDULER_YIELD auf CPU-Last. Wichtig sind zwei Dinge: die harmlosen Leerlauf-Typen herausfiltern (sonst stehen sie ganz oben), und den Anteil statt der absoluten Zahl betrachten. Die vollständige Kategorien-Landkarte mit Diagnose-Richtungen liefert der Wait-Stats-Beitrag des Notarztwagens; im Health Check gehört die Wait-Stats-Messung in die Baseline.
Wie prüfe ich die Backup-Strategie?
In drei Stufen, von der einfachsten zur wichtigsten. Erstens: Wann lief das letzte erfolgreiche Backup je Datenbank und Typ? Das beantwortet ein Blick in msdb.dbo.backupset — und deckt sofort auf, wenn eine Datenbank im FULL-Recovery-Model seit Wochen keine Log-Sicherung mehr hatte. Zweitens: Passt das Recovery-Model zur Anforderung (FULL für Point-in-Time, SIMPLE nur wo bewusst gewollt)? Drittens und am wichtigsten: Wurde je ein echter Restore getestet? Ein grüner Backup-Job beweist nur, dass geschrieben wurde, nicht dass wiederhergestellt werden kann. Die Details liefern die Beiträge zu Backup-Fehlern und Backup-Strategie.
Welche Sicherheits-Checks gehören dazu?
Die Basics, die erstaunlich oft vernachlässigt werden: Wer ist Mitglied der sysadmin-Rolle (und gehört da jeder wirklich hin)? Ist das sa-Konto deaktiviert oder zumindest umbenannt und mit starkem Passwort versehen? Gibt es verwaiste Datenbank-User ohne Login, offene Gastzugänge oder überzogene Berechtigungen? Und nicht zuletzt: Ist der Server auf einem aktuellen Patch-Stand (Cumulative Update)? Diese Prüfungen liest du aus sys.server_principals und den Berechtigungs-Sichten. Sicherheit gehört bewusst ins Fundament des Health Checks — ein kompromittierter Server ist kein Performance-Problem mehr, sondern ein Existenzproblem.
Wie oft sollte ich einen Health Check durchführen?
Gestaffelt nach Aufwand und Veränderlichkeit: den vollständigen Sechs-Bereiche-Check vierteljährlich, Backup- und Job-Status täglich (automatisiert per Alarm, nicht manuell), und die Performance-Baseline laufend per Agent-Job. Dazu kommt der anlassbezogene Sondercheck: nach jeder größeren Änderung — Release, Migration, Cumulative Update, Hardware-Wechsel — gehört einmal über die relevanten Bereiche geschaut, denn genau solche Ereignisse kippen Konfiguration und Pläne. Die Faustregel: Je weniger sich ein System ändert, desto seltener der volle Check, aber das automatisierte Tagesminimum für Backup und Jobs ist immer Pflicht.