Datenbankwartung und Fehlersuche

Der WWS-MaX DatabaseHealthCheck überwacht in regelmäßigen Abständen den Zustand der Hauptdatenbank sowie der zugehörigen _FileIndex-Datenbank. Der HealthCheck läuft derzeit alle 15 Minuten.

Die hier beschriebenen Warnungen sollen insbesondere Probleme erkennen, die die Datenintegrität, die Verfügbarkeit oder den stabilen Betrieb der SQL-Server-Datenbanken gefährden können.

Übersicht der überwachten Warnungen

WWS-Meldung	Dringlichkeit	Bedeutung
SQL Server: Verdächtige Datenbankseiten	KRITISCH	SQL Server hat Seiten registriert, bei denen ein I/O- oder Integritätsfehler festgestellt wurde.
SQL Server: I/O-Warnungen 823/824/825	KRITISCH	SQL Server oder das Betriebssystem hat schwerwiegende Probleme beim Lesen oder Schreiben von Daten festgestellt.
SQL Server: Kritischer Speicherplatz	HOCH	Auf einem Volume mit WWS-Datenbankdateien steht zu wenig freier Speicher zur Verfügung.
SQL Server: Auffällige I/O-Latenz	HOCH	Lese- oder Schreibzugriffe auf Datenbankdateien sind über längere Zeit ungewöhnlich langsam.
SQL Server: Transaktionsprotokoll	HOCH	Das Transaktionsprotokoll einer überwachten Datenbank ist zu mindestens 85 % belegt.
SQL Server: Datenbankkonfiguration	MITTEL bis KRITISCH	Eine Datenbank ist nicht `ONLINE` oder `PAGE_VERIFY` ist nicht auf `CHECKSUM` eingestellt.
SQL Server: Datenspiegelung gestört	HOCH	Database Mirroring befindet sich seit mindestens 30 Minuten nicht im erwarteten Zustand.
SQL Server: Always On-Verfügbarkeitsgruppe gestört	HOCH	Eine Always On-Verfügbarkeitsgruppe ist seit mindestens 30 Minuten nicht gesund.
SQL Server: Datenbanksicherung veraltet oder fehlerhaft	HOCH bis KRITISCH	Full-, Differential- oder Transaktionslog-Backups fehlen, sind zu alt oder wurden von SQL Server als beschädigt markiert.
SQL Server: Datenbankintegrität fehlerhaft	KRITISCH	DBCC CHECKDB hat Konsistenz- oder Integritätsfehler in einer WWS-Datenbank gefunden.
SQL Server: Integritätsprüfung unvollständig	HOCH	Eine geplante DBCC-CHECKDB-Prüfung konnte nicht vollständig ausgeführt werden.
SQL Server: Datenbanküberwachung unvollständig	HOCH	Mindestens eine Prüfung des HealthChecks konnte nicht ausgeführt werden.

Hinweis: Die Dringlichkeit beschreibt die typische Bedeutung der Meldung. Der konkrete Einzelfall kann davon abweichen. Insbesondere die Meldungen zu Fehlern 823, 824, 825 und zu verdächtigen Datenbankseiten sollten immer zeitnah untersucht werden.

SQL Server: Verdächtige Datenbankseiten

Dringlichkeit: KRITISCH

Der HealthCheck prüft die SQL-Server-Tabelle msdb.dbo.suspect_pages für die WWS-Hauptdatenbank und die zugehörige _FileIndex-Datenbank.

Eine Warnung wird ausgelöst, wenn dort noch nicht als behoben gekennzeichnete Seiten mit einem der folgenden Ereignistypen vorhanden sind:

`event_type`	Bedeutung
`1`	Fehler 823 oder ein sonstiger 824-Fehler
`2`	Fehlerhafte Prüfsumme
`3`	Torn Page / unvollständig geschriebene Seite

Ein Eintrag bedeutet nicht in jedem Fall, dass Daten endgültig verloren sind. Er ist jedoch ein ernstes Warnsignal für mögliche Datenbankbeschädigung oder Probleme im Storage-/I/O-Pfad.

Microsoft empfiehlt bei entsprechenden Fehlern unter anderem eine vollständige Konsistenzprüfung der betroffenen Datenbank.

Lösung

Öffnen Sie auf dem Datenbankserver die SQL Server Management Studio (SSMS).
Prüfen Sie das SQL-Server-Errorlog und das Windows-Systemereignisprotokoll auf I/O-, Datenträger-, Controller- oder Dateisystemfehler.
Führen Sie für die betroffene Datenbank eine vollständige Integritätsprüfung durch:
```
DBCC CHECKDB (N'IhreDatenbank')
WITH NO_INFOMSGS, ALL_ERRORMSGS;
```
Falls DBCC CHECKDB Fehler meldet, prüfen Sie zunächst, ob eine Wiederherstellung aus einem nachweislich fehlerfreien Backup möglich ist.
Verwenden Sie REPAIR_ALLOW_DATA_LOSS nicht vorschnell. Diese Option kann Daten entfernen, um die strukturelle Konsistenz der Datenbank wiederherzustellen.
Prüfen Sie bei I/O-Auffälligkeiten zusätzlich den Datenträger, RAID-/SAN-/NAS-Controller, Firmware, Treiber, Hypervisor und gegebenenfalls die physische Storage-Hardware.

Weitere Informationen:

SQL Server: I/O-Warnungen 823/824/825

Dringlichkeit: KRITISCH

Der HealthCheck durchsucht das SQL-Server-Errorlog nach neuen Ereignissen mit den Fehlernummern 823, 824 oder 825.

Diese Meldung ist im Gegensatz zu den meisten anderen HealthCheck-Warnungen ereignisbasiert. Ein bereits gemeldeter alter Fehler wird nicht bei jedem HealthCheck erneut eingeblendet. Erst wenn ein neuer Fehler 823, 824 oder 825 protokolliert wird, wird die Warnung erneut ausgelöst.

Fehler 823

Dringlichkeit: KRITISCH

Fehler 823 bedeutet, dass ein Betriebssystem-I/O-Aufruf beim Lesen oder Schreiben einer SQL-Server-Datei fehlgeschlagen ist.

Typische Ursachen sind:

defekte oder instabile Datenträger,
Storage-Controller oder RAID-Systeme,
fehlerhafte Gerätetreiber oder Firmware,
Probleme mit SAN/NAS oder Netzwerkpfaden,
Dateisystemfehler,
Probleme auf dem Hypervisor oder zugrunde liegenden Storage.

Ein 823 ist ein schwerwiegender Systemfehler, der die Datenbankintegrität gefährden kann.

Fehler 824

Dringlichkeit: KRITISCH

Bei Fehler 824 wurde der I/O-Aufruf aus Sicht des Betriebssystems erfolgreich abgeschlossen, SQL Server hat beim Prüfen der gelesenen Seite jedoch eine logische Inkonsistenz festgestellt.

Mögliche Beispiele sind:

fehlerhafte Prüfsumme,
falsche Page-ID,
Torn Page,
veraltete oder falsche Daten wurden vom Storage geliefert.

Ein 824 ist daher kein normaler SQL-Fehler, sondern ein ernstes Zeichen für eine mögliche Beschädigung oder ein Problem im I/O-Pfad.

Fehler 825

Dringlichkeit: SEHR HOCH

Fehler 825 bedeutet, dass ein Lesevorgang zunächst fehlgeschlagen ist, nach einem oder mehreren Wiederholungsversuchen aber noch erfolgreich war.

Dadurch kann die eigentliche Anwendung zunächst weiterlaufen. Der Fehler darf trotzdem nicht ignoriert werden.

Ein 825 ist häufig eine Frühwarnung für ein beginnendes Storage-Problem und kann später zu 823-, 824-Fehlern, Datenverlust oder Datenbankbeschädigung führen.

Lösung bei 823, 824 oder 825

Prüfen Sie das SQL-Server-Errorlog auf die vollständige Fehlermeldung, insbesondere auf Datenbankdatei, Offset und weitere I/O-Fehler.
Prüfen Sie das Windows-Systemereignisprotokoll auf Fehler der Quellen Disk, StorPort, Ntfs, Controller, Multipath-Treiber oder vergleichbarer Komponenten.
Führen Sie für die betroffene Datenbank eine vollständige Integritätsprüfung durch:
```
DBCC CHECKDB (N'IhreDatenbank')
WITH NO_INFOMSGS, ALL_ERRORMSGS;
```
Prüfen Sie auch andere Datenbanken, deren Dateien auf demselben Storage liegen.
Kontrollieren Sie Hardware, Storage, Controller, Firmware und Treiber.
Bei virtualisierten SQL-Servern sollte zusätzlich die Storage-Latenz und der Zustand des Hypervisors geprüft werden.

Weitere Informationen:

SQL Server: Kritischer Speicherplatz

Dringlichkeit: HOCH

Der HealthCheck überwacht die Volumes, auf denen Dateien der WWS-Hauptdatenbank oder der _FileIndex-Datenbank liegen.

Eine Warnung wird derzeit ausgelöst, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

weniger als 10 GB freier Speicher oder
weniger als 10 % freier Speicher und gleichzeitig weniger als 50 GB frei.

Zu wenig freier Speicher kann dazu führen, dass eine Daten- oder Transaktionslogdatei nicht mehr wachsen kann. Dadurch können Schreibvorgänge und im schlimmsten Fall große Teile der WWS ausfallen.

Lösung

Prüfen Sie, welches Volume in der WWS-Warnung genannt wird.
Prüfen Sie, welche SQL-Dateien auf diesem Volume liegen.
Geben Sie Speicher frei oder erweitern Sie das Volume.
Löschen oder verkleinern Sie SQL-Datenbankdateien nicht ohne Prüfung, nur um kurzfristig freien Speicher zu schaffen.
Prüfen Sie bei stark anwachsenden Logdateien zusätzlich den Abschnitt Transaktionsprotokoll.

Weitere Informationen:

Microsoft: sys.dm_os_volume_stats

SQL Server: Auffällige I/O-Latenz

Dringlichkeit: HOCH

Der HealthCheck misst die I/O-Zähler der SQL-Server-Datenbankdateien und bildet daraus die tatsächliche durchschnittliche Latenz zwischen zwei HealthCheck-Läufen.

Eine Warnung wird derzeit erst ausgelöst, wenn:

mindestens 50 Lese- oder Schreibvorgänge im Messintervall stattgefunden haben,
die durchschnittliche Read- oder Write-Latenz mindestens 50 ms beträgt und
dieser Zustand in mindestens zwei aufeinanderfolgenden Messintervallen besteht.

Bei einem HealthCheck-Intervall von 15 Minuten entspricht dies normalerweise einer anhaltenden Auffälligkeit von ungefähr 30 Minuten.

Dadurch sollen kurze Lastspitzen nicht sofort zu einer Warnung führen.

Mögliche Ursachen

überlastetes SAN/NAS oder lokales Storage,
hohe Last durch andere virtuelle Maschinen,
Storage-Snapshots oder Backups,
Virenscanner oder andere Filtertreiber,
defekte oder langsame Datenträger,
Storage-Throttling,
Netzwerkprobleme bei entferntem Storage,
sehr hohe allgemeine Serverlast.

Lösung

Prüfen Sie, welche Datenbankdatei hohe Read- oder Write-Latenzen aufweist.
Prüfen Sie die Storage-Latenz auf dem SQL-Server bzw. Hypervisor.
Kontrollieren Sie parallel laufende Backups, Snapshots, Virenscanner und andere I/O-intensive Prozesse.
Prüfen Sie das SQL-Server- und Windows-Errorlog auf 823-, 824- oder 825-Meldungen.
Wenn gleichzeitig 823, 824 oder 825 auftreten, behandeln Sie das Problem als kritisches Storage-/Integritätsproblem.

Weitere Informationen:

Microsoft: sys.dm_io_virtual_file_stats

SQL Server: Transaktionsprotokoll

Dringlichkeit: HOCH

Der HealthCheck warnt, wenn das Transaktionsprotokoll der Hauptdatenbank oder _FileIndex-Datenbank zu mindestens 85 % belegt ist.

Eine hohe prozentuale Belegung ist nicht automatisch ein Fehler. Wenn das Log jedoch nicht wiederverwendet werden kann und weiter wächst, kann das Datenbankvolume volllaufen oder SQL Server kann keine weiteren Transaktionen mehr schreiben.

In der WWS-Warnung wird deshalb zusätzlich Log Reuse Wait ausgegeben.

Häufige Werte von Log Reuse Wait

Wert	Typische Bedeutung
`NOTHING`	Derzeit verhindert nichts die Wiederverwendung des Logs.
`LOG_BACKUP`	Es wird ein Transaktionslog-Backup benötigt.
`ACTIVE_TRANSACTION`	Eine laufende Transaktion hält Logbereiche fest.
`AVAILABILITY_REPLICA`	Ein Always On-Replikat verhindert die Wiederverwendung.
`REPLICATION`	Replikationsvorgänge halten Logbereiche fest.
`CHECKPOINT`	Ein Checkpoint ist erforderlich bzw. noch nicht abgeschlossen.

Lösung

Prüfen Sie den in der Warnung angegebenen Wert Log Reuse Wait.
Bei LOG_BACKUP: Prüfen Sie, ob regelmäßige Transaktionslog-Backups konfiguriert sind und erfolgreich ausgeführt werden.
Bei ACTIVE_TRANSACTION: Suchen Sie nach sehr lange laufenden oder blockierten Transaktionen.
Bei AVAILABILITY_REPLICA: Prüfen Sie Always On und die Erreichbarkeit der Replikate.
Prüfen Sie den freien Speicherplatz des Volumes, auf dem die Logdatei liegt.
Verkleinern Sie das Transaktionslog nicht routinemäßig. Ein Shrink behebt die Ursache einer dauerhaft hohen Logbelegung in der Regel nicht.

Weitere Informationen:

SQL Server: Datenbankkonfiguration

Die WWS fasst verschiedene grundlegende Konfigurationsprobleme unter dieser Warnung zusammen.

Datenbankstatus ist nicht ONLINE

Dringlichkeit: KRITISCH bei ungeplantem Zustand

Die Hauptdatenbank und die _FileIndex-Datenbank sollten im normalen Betrieb den Zustand ONLINE besitzen.

Andere Zustände können zum Beispiel sein:

OFFLINE
RESTORING
RECOVERING
RECOVERY_PENDING
SUSPECT
EMERGENCY

Ein Zustand wie RESTORING oder RECOVERING kann während administrativer Arbeiten vorübergehend normal sein. Wenn eine produktive WWS-Datenbank ohne geplanten Eingriff nicht ONLINE ist, sollte die Ursache jedoch sofort geprüft werden.

Besonders SUSPECT oder RECOVERY_PENDING sind kritisch.

Lösung

Prüfen Sie in SSMS den Zustand der betroffenen Datenbank.
Prüfen Sie das SQL-Server-Errorlog auf die Ursache des Zustandswechsels.
Prüfen Sie Speicherplatz, Datenbankdateien und Storage.
Bei SUSPECT, I/O-Fehlern oder beschädigten Seiten führen Sie eine vollständige DBCC CHECKDB-Prüfung durch.
Setzen Sie eine Datenbank nicht ohne Ursachenanalyse manuell auf ONLINE, EMERGENCY oder in einen anderen Zustand.

PAGE_VERIFY ist nicht auf CHECKSUM eingestellt

Dringlichkeit: MITTEL

Diese Meldung bedeutet nicht, dass die Datenbank bereits beschädigt ist.

PAGE_VERIFY = CHECKSUM ist jedoch die von Microsoft empfohlene Einstellung, um Beschädigungen durch den I/O-Pfad möglichst zuverlässig zu erkennen.

Beim Schreiben einer Seite speichert SQL Server eine Prüfsumme. Beim späteren Lesen wird sie erneut berechnet und verglichen. Stimmen die Werte nicht überein, kann SQL Server einen Fehler 824 melden.

Wenn PAGE_VERIFY auf TORN_PAGE_DETECTION oder NONE steht, ist die Erkennung von beschädigten Seiten schwächer.

Lösung

Die Einstellung kann in der Regel online geändert werden:

ALTER DATABASE [IhreDatenbank]
SET PAGE_VERIFY CHECKSUM;

Zum Ändern der Datenbankoption ist die Berechtigung ALTER auf der Datenbank erforderlich.

Wichtig: Das Aktivieren von CHECKSUM versieht nicht sofort jede bereits vorhandene Datenbankseite mit einer neuen Prüfsumme. Die Prüfsumme wird beim nächsten Schreiben der jeweiligen Seite aktualisiert. Die Einstellung ersetzt daher keine Integritätsprüfung mit DBCC CHECKDB.

Weitere Informationen:

SQL Server: Datenspiegelung gestört

Dringlichkeit: HOCH

Diese Prüfung betrifft das ältere SQL-Server-Verfahren Database Mirroring.

Die Warnung wird nur verwendet, wenn die WWS-Hauptdatenbank oder die _FileIndex-Datenbank tatsächlich an Database Mirroring teilnimmt.

Kurze Failover- oder Netzwerkereignisse werden toleriert. Eine WWS-Warnung erscheint erst, wenn der ungesunde Zustand mindestens 30 Minuten besteht.

Der HealthCheck berücksichtigt dabei den Mirroring-Modus:

bei synchronem Mirroring wird SYNCHRONIZED erwartet,
bei asynchronem Mirroring sind SYNCHRONIZED und SYNCHRONIZING zulässig,
wenn ein Witness konfiguriert ist, muss dieser CONNECTED sein.

Mögliche Ursachen

Mirroring-Partner nicht erreichbar,
SQL-Server-Dienst auf Partnerinstanz ausgefallen,
Netzwerk- oder Firewallproblem,
Mirroring-Endpunkt nicht erreichbar,
Mirroring wurde angehalten,
Witness nicht erreichbar,
Storage- oder Datenbankproblem auf einem Partner.

Lösung

Prüfen Sie in SSMS den Status des Database Mirroring.
Prüfen Sie, ob Partner und gegebenenfalls Witness erreichbar sind.
Prüfen Sie die SQL-Server-Dienste auf beiden Servern.
Prüfen Sie Firewall, Netzwerk und Mirroring-Endpunkte.
Kontrollieren Sie das SQL-Server-Errorlog beider Partner.
Erzwingen Sie einen Failover nur, wenn die Auswirkungen und der Datenstand des Zielsystems bekannt sind.

Weitere Informationen:

Microsoft: sys.database_mirroring

SQL Server: Always On-Verfügbarkeitsgruppe gestört

Dringlichkeit: HOCH

Diese Warnung betrifft SQL Server Always On Availability Groups.

Der HealthCheck prüft nur Verfügbarkeitsgruppen, in denen die WWS-Hauptdatenbank oder die _FileIndex-Datenbank enthalten ist.

Eine Warnung wird erst erzeugt, wenn der ungesunde Zustand mindestens 30 Minuten besteht. Kurze Failover- oder Verbindungsereignisse sollen dadurch nicht unnötig alarmieren.

Der HealthCheck prüft derzeit insbesondere:

connected_state_desc = CONNECTED
operational_state_desc = ONLINE, sofern dieser Wert vorhanden ist
synchronization_health_desc = HEALTHY
den aggregierten Gruppenstatus synchronization_health_desc = HEALTHY

SQL Server berücksichtigt bei der Synchronisierungsbewertung bereits, ob ein Replikat synchron oder asynchron betrieben wird.

Bedeutung

Wenn die WWS weiterhin funktioniert, kann eine Always On-Warnung trotzdem bedeuten, dass die Redundanz oder Failover-Fähigkeit eingeschränkt ist.

Eine Störung sollte deshalb zeitnah behoben werden, bevor zusätzlich das derzeit aktive Replikat ausfällt.

Lösung

Öffnen Sie in SSMS das Always On Dashboard.
Prüfen Sie, welches Replikat nicht CONNECTED, ONLINE oder HEALTHY ist.
Prüfen Sie die SQL-Server-Dienste auf allen Replikaten.
Prüfen Sie Netzwerk, Firewall und HADR-Endpunkte.
Prüfen Sie den Windows Server Failover Cluster bzw. den Quorum-Zustand.
Kontrollieren Sie die SQL-Server- und Windows-Ereignisprotokolle auf allen beteiligten Servern.
Prüfen Sie Storage und freien Speicherplatz der Replikate.

Weitere Informationen:

SQL Server: Datenbanksicherung veraltet oder fehlerhaft

Dringlichkeit: HOCH bis KRITISCH

Der HealthCheck prüft für die WWS-Hauptdatenbank und die zugehörige _FileIndex-Datenbank die SQL-Server-Sicherungshistorie in msdb.dbo.backupset.

Überwacht werden getrennt:

vollständige Datenbanksicherungen (type = 'D'),
differentielle Datenbanksicherungen (type = 'I'), sofern deren Überwachung aktiviert ist,
Transaktionslog-Sicherungen (type = 'L'), sofern deren Überwachung aktiviert ist und die Datenbank FULL oder BULK_LOGGED verwendet.

Bei SIMPLE werden Transaktionslog-Backups automatisch nicht überwacht, da SQL Server in diesem Recovery Model keine Log-Backups unterstützt.

Standardwerte

Die Backupüberwachung ist konfigurierbar. Standardmäßig gelten derzeit folgende Werte:

Backupart	Standardmäßig überwacht	Erwartetes Intervall	Automatische Erkennung	Warnung
Full	Ja	7 Tage	Ja	normalerweise nach 2 Intervallen, spätestens nach 15 Tagen
Differential	Nein	24 Stunden	Ja	normalerweise nach 2 Intervallen, spätestens nach 3 Tagen
Transaktionslog	Ja	15 Minuten	Ja	normalerweise nach 2 Intervallen, spätestens nach 120 Minuten

Bei den meisten WWS-Installationen mit FULL-Recovery-Model sollten Transaktionslog-Backups deutlich häufiger als Full-Backups ausgeführt werden. Ein typisches Intervall sind beispielsweise 15 Minuten.

Automatische Erkennung des üblichen Backupintervalls

Wenn die automatische Intervallerkennung aktiviert ist, verwendet der HealthCheck nicht einfach den Abstand zum letzten Backup.

Stattdessen werden mehrere historische Sicherungen betrachtet und aus den Abständen der Median berechnet. Dadurch beeinflusst ein einzelnes verspätetes oder ausgefallenes Backup das erkannte übliche Intervall nur wenig.

Beispiel:

Das erkannte übliche Intervall beträgt ungefähr 15 Minuten. Bei einem Warnfaktor von 2 wird eine Warnung erzeugt, wenn ungefähr 30 Minuten kein neues Log-Backup mehr vorhanden ist.

Die automatisch bestimmte Warnschwelle kann zusätzlich durch eine absolute maximale Wartezeit begrenzt werden. Dadurch kann sich ein dauerhaft schlechter werdender Backupplan nicht unbegrenzt selbst als neuer Normalzustand etablieren.

Falls noch nicht genügend historische Sicherungen vorliegen, verwendet der HealthCheck das im Einstellungsobjekt konfigurierte Standardintervall.

Veraltetes oder fehlendes Backup

Dringlichkeit: HOCH

Ein fehlendes aktuelles Backup bedeutet nicht, dass die Datenbank selbst beschädigt ist. Bei einem späteren Hardwarefehler, Datenverlust oder Bedienfehler kann jedoch kein ausreichend aktueller Wiederherstellungsstand vorhanden sein.

Bei fehlenden Transaktionslog-Backups ist zusätzlich zu beachten, dass bei FULL und BULK_LOGGED der mögliche Datenverlust im Fehlerfall seit dem letzten Log-Backup wächst. Außerdem kann das Transaktionsprotokoll weiter anwachsen, wenn es nicht regelmäßig gesichert werden kann.

Lösung

Prüfen Sie den geplanten Datenbank-Backupjob und dessen letzte Ausführungen.
Prüfen Sie, welche Backupart betroffen ist: Full, Differential oder Transaktionsprotokoll.
Prüfen Sie den verfügbaren Speicherplatz am Sicherungsziel.
Prüfen Sie SQL-Server- und Windows-Protokolle auf Fehler während der Sicherung.
Erstellen Sie bei Bedarf zeitnah die fehlende Sicherung.
Prüfen Sie, ob das konfigurierte Intervall zur tatsächlich gewünschten Backupstrategie passt.

Transaktionslog-Backup fehlt

Dringlichkeit: HOCH

Transaktionslog-Backups sind nur bei FULL und BULK_LOGGED relevant. In diesen Recovery Models sind regelmäßige Log-Backups ein wesentlicher Bestandteil der Wiederherstellungsstrategie.

Bei einem üblichen 15-Minuten-Intervall ist bereits eine deutlich längere Zeit ohne Log-Backup auffällig. Standardmäßig erzeugt der HealthCheck bei einem erkannten 15-Minuten-Intervall ungefähr nach 30 Minuten eine Warnung.

Mögliche Ursachen:

Backupjob ist deaktiviert oder fehlgeschlagen,
Sicherungsziel ist nicht erreichbar,
Datenträger ist voll,
SQL Server Agent läuft nicht,
Berechtigungen am Sicherungsziel fehlen,
Backup wird auf einem anderen Always-On-Replikat ausgeführt.

Weitere Informationen:

Differential-Backup fehlt

Dringlichkeit: MITTEL bis HOCH

Differentielle Backups sind optional und deshalb standardmäßig nicht überwacht.

Wenn sie aktiviert werden, erwartet der HealthCheck regelmäßige differentielle Sicherungen zwischen den Full-Backups. Ein neues Full-Backup ersetzt dabei die Notwendigkeit eines älteren Differential-Backups und startet die Bewertung des Differentialintervalls neu.

Differentielle Backups können bei großen Datenbanken die Wiederherstellungszeit erheblich verkürzen, weil nach dem Full-Backup weniger Log-Backups eingespielt werden müssen.

Backup mit `is_damaged = 1`

Dringlichkeit: KRITISCH

Wenn das neueste überwachte Backup einer Backupart von SQL Server mit is_damaged = 1 markiert wurde, hat SQL Server während des Backupvorgangs eine Beschädigung erkannt.

In diesem Fall sollte nicht nur der Backupjob geprüft werden. Die Datenbank selbst muss auf Integritätsprobleme untersucht werden.

Führen Sie eine vollständige Integritätsprüfung aus:

DBCC CHECKDB (N'IhreDatenbank')
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Prüfen Sie SQL-Server- und Windows-Errorlogs auf Fehler 823, 824 oder 825 sowie Storage-/I/O-Probleme.
Beheben Sie die Ursache einer eventuell gefundenen Datenbankbeschädigung.
Erstellen Sie anschließend ein neues fehlerfreies Backup.

Besonderheit bei Always On

Die Sicherungshistorie in msdb wird nicht zwischen den SQL-Server-Instanzen einer Always On Availability Group synchronisiert.

Der HealthCheck bewertet die Backup-Historie deshalb nur, wenn die aktuell verbundene Instanz laut sys.fn_hadr_backup_is_preferred_replica das bevorzugte Backup-Replikat für die Datenbank ist.

Dadurch sollen Fehlalarme vermieden werden, wenn Backups bewusst auf einem anderen Always-On-Replikat ausgeführt werden.

Hinweis: Der HealthCheck kann nur Sicherungen erkennen, die in der SQL-Server-Sicherungshistorie msdb.dbo.backupset erscheinen. Externe Sicherungsverfahren, die dort keinen Eintrag erzeugen, können von dieser Prüfung nicht erkannt werden.

Einstellungen speichern

Die HealthCheck-Konfiguration wird unter der WWS-weiten Einstellung

DatabaseHealthCheck.Settings

gespeichert.

Das Einstellungsobjekt enthält neben den Backupintervallen auch die weiteren derzeit einstellbaren HealthCheck-Schwellwerte, beispielsweise I/O-Latenz, Speicherplatz, Transaktionslogbelegung und Verzögerung bei Hochverfügbarkeitswarnungen.

Kann die gespeicherte Konfiguration nicht deserialisiert werden, verwendet der HealthCheck automatisch die hinterlegten Standardwerte.

Weitere Informationen:

SQL Server: Datenbankintegrität fehlerhaft

Dringlichkeit: KRITISCH

Der zusätzlich in einem größeren Zeitintervall ausgeführte DatabaseHealthDeepCheck verwendet DBCC CHECKDB, um die physische und logische Konsistenz der WWS-Hauptdatenbank und der zugehörigen _FileIndex-Datenbank zu prüfen.

Standardmäßig ist vorgesehen:

an normalen täglichen Läufen DBCC CHECKDB ... WITH PHYSICAL_ONLY,
in einem größeren konfigurierbaren Abstand zusätzlich ein vollständiger DBCC CHECKDB, standardmäßig alle 7 Tage.

PHYSICAL_ONLY reduziert den Prüfaufwand und kann unter anderem Torn Pages, Prüfsummenfehler und typische physische Beschädigungen erkennen. Die vollständige Prüfung führt zusätzlich die umfangreicheren logischen Konsistenzprüfungen durch.

Microsoft empfiehlt PHYSICAL_ONLY für häufigere Prüfungen auf Produktionssystemen und weiterhin periodische vollständige DBCC CHECKDB-Läufe.

Lösung

Behandeln Sie die Meldung als kritischen Integritätsfehler und prüfen Sie zunächst die vollständigen DBCC-Meldungen in der WWS-Aufgabe.
Prüfen Sie das SQL-Server-Errorlog und das Windows-Systemereignisprotokoll auf I/O- oder Storagefehler.
Stellen Sie sicher, dass ein aktuelles und nachweislich fehlerfreies Backup vorhanden ist.
Führen Sie den vollständigen DBCC CHECKDB gegebenenfalls manuell in SSMS erneut aus, um die Meldungen vollständig zu analysieren.
Verwenden Sie REPAIR_ALLOW_DATA_LOSS nicht vorschnell. Diese Option kann Daten entfernen und sollte nur nach sorgfältiger Bewertung verwendet werden.
Wenn ein fehlerfreies Backup verfügbar ist, ist eine Wiederherstellung häufig die sicherere Lösung als eine reparierende DBCC-Option.

Weitere Informationen:

Microsoft: DBCC CHECKDB

SQL Server: Integritätsprüfung unvollständig

Dringlichkeit: HOCH

Diese Warnung bedeutet, dass der DatabaseHealthDeepCheck mindestens eine geplante DBCC CHECKDB-Prüfung nicht vollständig durchführen konnte.

Mögliche Ursachen sind insbesondere:

fehlende SQL-Berechtigungen,
ein Timeout,
zu wenig freier Speicher für die interne CHECKDB-Datenbankmomentaufnahme bzw. tempdb,
die Datenbank ist nicht ONLINE,
ein Verbindungs- oder Serverfehler während der Prüfung.

Solange diese Warnung besteht, ist die Datenbankintegrität nicht vollständig bestätigt.

Lösung

Lesen Sie die konkrete Ursache in der WWS-Warnung.
Bei einem Berechtigungsfehler benötigt der verwendete Login für DBCC CHECKDB entweder die Mitgliedschaft in db_owner der jeweiligen Datenbank oder serverweit sysadmin.
Für WWS sollte nach Möglichkeit db_owner gezielt nur auf den tatsächlich überwachten WWS-Datenbanken verwendet werden, statt allein für die Prüfung sysadmin zu vergeben.
Bei Timeout oder Ressourcenproblemen führen Sie die Prüfung außerhalb der Hauptarbeitszeit erneut aus und prüfen Sie freien Speicher sowie die Belastung von tempdb und Storage.

Weitere Informationen:

Microsoft: DBCC CHECKDB - Berechtigungen und Optionen

SQL Server: Datenbanküberwachung unvollständig

Dringlichkeit: HOCH

Diese Warnung bedeutet nicht zwingend, dass bereits ein Datenbankfehler vorliegt.

Sie bedeutet jedoch, dass mindestens eine Teilprüfung des DatabaseHealthCheck nicht durchgeführt werden konnte. Dadurch entsteht ein Überwachungs-Blindspot: Ein tatsächliches Problem könnte unentdeckt bleiben.

Die konkrete Ursache wird in der WWS-Meldung mit ausgegeben.

Häufige Gründe sind:

fehlende SQL-Server-Berechtigungen,
SQL Server oder eine Systemdatenbank ist nicht erreichbar,
eine benötigte DMV oder Systemprozedur kann nicht gelesen werden,
die Verbindung wurde während der Prüfung unterbrochen.

Lösung

Lesen Sie in der WWS-Warnung, welche Teilprüfung fehlgeschlagen ist.
Prüfen Sie, ob es sich um einen Berechtigungsfehler handelt.
Testen Sie die entsprechende Abfrage in SSMS mit demselben SQL-Login, den die WWS verwendet.
Erteilen Sie nur die tatsächlich benötigte Berechtigung. Vergeben Sie nicht pauschal sysadmin.
Führen Sie den HealthCheck nach der Korrektur erneut aus oder warten Sie auf den nächsten automatischen Lauf.

Fehler durch fehlende SQL-Berechtigungen

Mehrere Teile des HealthChecks verwenden serverweite Systemansichten oder gespeicherte Prozeduren. Ein SQL-Login, der nur normale Rechte innerhalb der WWS-Datenbank besitzt, darf diese Informationen nicht zwangsläufig lesen.

Fehlende Berechtigungen führen in der Regel zur WWS-Meldung:

SQL Server: Datenbanküberwachung unvollständig

SQL-Server-Errorlog kann nicht gelesen werden

Dringlichkeit: HOCH

Mögliche Meldung:

SQL-Server-Errorlog konnte nicht auf 823/824/825 geprüft werden: Der Aufrufer ist nicht berechtigt, die gespeicherte Prozedur auszuführen.

Der HealthCheck verwendet master.sys.sp_readerrorlog.

Benötigte Berechtigung:

SQL Server 2022 oder neuer:

GRANT VIEW ANY ERROR LOG TO [WWSLogin];

Alternativ erlaubt auch VIEW SERVER PERFORMANCE STATE den Zugriff, für diesen Zweck ist VIEW ANY ERROR LOG jedoch die gezieltere Berechtigung.

SQL Server 2019 und älter:

GRANT VIEW SERVER STATE TO [WWSLogin];

Weitere Informationen:

Microsoft: sp_readerrorlog

Verdächtige Datenbankseiten können nicht geprüft werden

Dringlichkeit: HOCH

Die Tabelle suspect_pages befindet sich in der Systemdatenbank msdb.

Microsoft dokumentiert, dass Benutzer mit Zugriff auf msdb die Tabelle lesen können.

Prüfen Sie daher zunächst, ob der WWS-Login Zugriff auf msdb besitzt.

Ein möglicher expliziter Lesezugriff ist beispielsweise:

USE [msdb];
GRANT SELECT ON dbo.suspect_pages TO [WWSBenutzer];

Dabei muss der entsprechende Datenbankbenutzer in msdb bereits vorhanden sein.

Es sind für den HealthCheck keine Schreibrechte auf suspect_pages erforderlich.

Weitere Informationen:

Microsoft: suspect_pages - Berechtigungen

Freier Speicherplatz kann nicht geprüft werden

Dringlichkeit: MITTEL bis HOCH

Der HealthCheck verwendet sys.dm_os_volume_stats.

Benötigte Berechtigung:

SQL Server 2022 oder neuer:

GRANT VIEW SERVER PERFORMANCE STATE TO [WWSLogin];

SQL Server 2019 und älter:

GRANT VIEW SERVER STATE TO [WWSLogin];

Weitere Informationen:

Microsoft: sys.dm_os_volume_stats

I/O-Latenzen können nicht geprüft werden

Dringlichkeit: MITTEL bis HOCH

Der HealthCheck verwendet sys.dm_io_virtual_file_stats.

Benötigte Berechtigung:

SQL Server 2022 oder neuer:

GRANT VIEW SERVER PERFORMANCE STATE TO [WWSLogin];

SQL Server 2019 und älter:

GRANT VIEW SERVER STATE TO [WWSLogin];

Weitere Informationen:

Microsoft: sys.dm_io_virtual_file_stats

Transaktionsprotokolle können nicht geprüft werden

Dringlichkeit: MITTEL bis HOCH

Der aktuelle HealthCheck verwendet DBCC SQLPERF(LOGSPACE).

Microsoft dokumentiert hierfür auf SQL Server die serverweite Berechtigung:

GRANT VIEW SERVER STATE TO [WWSLogin];

Diese Berechtigung ist auch bei SQL Server 2022 für DBCC SQLPERF(LOGSPACE) in der Microsoft-Dokumentation angegeben.

Weitere Informationen:

Microsoft: DBCC SQLPERF

Datenbankkonfiguration kann nicht geprüft werden

Dringlichkeit: MITTEL

Der HealthCheck liest sys.databases.

Der aktuelle WWS-Login sollte die Hauptdatenbank bereits sehen können. Für die _FileIndex-Datenbank muss ebenfalls ausreichende Metadatensichtbarkeit bestehen.

Wenn nur die _FileIndex-Datenbank nicht sichtbar ist, sollte bevorzugt geprüft werden, ob der WWS-Login dort korrekt als Benutzer eingerichtet ist und die notwendige Datenbankberechtigung besitzt.

Die sehr weitreichende Serverberechtigung

GRANT VIEW ANY DATABASE TO [WWSLogin];

sollte nur vergeben werden, wenn sie tatsächlich gewünscht ist. Für den HealthCheck ist es besser, dem WWS-Login gezielt Zugriff auf die von WWS verwendeten Datenbanken zu geben.

Sicherungshistorie kann nicht geprüft werden

Dringlichkeit: HOCH

Der HealthCheck liest die Backup-Historie aus msdb.dbo.backupset.

Wenn der verwendete SQL-Login keinen Zugriff darauf besitzt, erscheint die Meldung SQL Server: Datenbanküberwachung unvollständig.

Prüfen Sie zunächst mit demselben Login in SSMS, ob folgende Abfrage möglich ist:

SELECT TOP (1) *
FROM msdb.dbo.backupset;

Falls der Zugriff verweigert wird, muss der WWS-Login als Benutzer in msdb vorhanden sein und Leserechte auf die benötigte Backup-Historie erhalten. Je nach vorhandener Benutzerverwaltung kann beispielsweise eine gezielte SELECT-Berechtigung auf dbo.backupset verwendet werden.

Vergeben Sie dafür nicht pauschal sysadmin.

Database Mirroring kann nicht geprüft werden

Dringlichkeit: MITTEL bis HOCH

Der HealthCheck verwendet sys.database_mirroring.

Die Sichtbarkeit dieser Katalogansicht richtet sich nach der normalen SQL-Server-Metadatensichtbarkeit. Ein Benutzer sieht Informationen zu Objekten, die er besitzt oder für die er eine entsprechende Berechtigung besitzt.

Wenn eine Datenbank tatsächlich gespiegelt wird, der HealthCheck aber keine Mirroring-Informationen erhält, prüfen Sie:

ob der WWS-Login Zugriff auf die betroffene Datenbank besitzt,
ob die Mirroring-Metadaten mit diesem Login in SSMS sichtbar sind,
ob explizite DENY-Berechtigungen gesetzt wurden.

Für diese Prüfung sollte nicht pauschal sysadmin vergeben werden.

Weitere Informationen:

Microsoft: sys.database_mirroring

Always On-Verfügbarkeitsgruppen können nicht geprüft werden

Dringlichkeit: HOCH

Der HealthCheck verwendet unter anderem:

sys.dm_hadr_availability_replica_states
sys.dm_hadr_availability_group_states

Benötigte Berechtigung:

SQL Server 2022 oder neuer:

GRANT VIEW SERVER PERFORMANCE STATE TO [WWSLogin];

SQL Server 2019 und älter:

GRANT VIEW SERVER STATE TO [WWSLogin];

Weitere Informationen:

DBCC CHECKDB kann nicht ausgeführt werden

Dringlichkeit: HOCH

Für den seltener laufenden DatabaseHealthDeepCheck gelten strengere Berechtigungen als für die meisten reinen DMV-Abfragen.

Microsoft verlangt für DBCC CHECKDB:

Mitgliedschaft in der festen Serverrolle sysadmin oder
Mitgliedschaft in der festen Datenbankrolle db_owner der jeweils zu prüfenden Datenbank.

Für den WWS-HealthCheck sollte bevorzugt der gezielte Datenbankzugriff verwendet werden, sofern dies mit dem Sicherheitskonzept der Installation vereinbar ist:

USE [IhreWWSDatenbank];
ALTER ROLE [db_owner] ADD MEMBER [WWSBenutzer];

Dasselbe gilt gegebenenfalls für die _FileIndex-Datenbank.

Sicherheitshinweis: db_owner ist ebenfalls eine sehr weitreichende Datenbankberechtigung. Sie sollte nur vergeben werden, wenn der für WWS verwendete Datenbankbenutzer diese Rechte im vorhandenen Berechtigungskonzept ohnehin besitzen darf. Allein für den DeepCheck sollte nicht unüberlegt sysadmin vergeben werden.

Weitere Informationen:

Microsoft: DBCC CHECKDB

Empfohlene Berechtigungen für den HealthCheck

Welche Berechtigungen tatsächlich benötigt werden, hängt von der SQL-Server-Version und den verwendeten Hochverfügbarkeitsfunktionen ab.

Für einen WWS-Login auf SQL Server 2022 oder neuer werden für die derzeitigen serverweiten Prüfungen typischerweise folgende Berechtigungen benötigt:

GRANT VIEW ANY ERROR LOG TO [WWSLogin];
GRANT VIEW SERVER PERFORMANCE STATE TO [WWSLogin];
GRANT VIEW SERVER STATE TO [WWSLogin];

Dabei gilt:

VIEW ANY ERROR LOG wird zum Lesen des SQL-Server-Errorlogs verwendet.
VIEW SERVER PERFORMANCE STATE wird für die I/O-, Volume- und Always-On-DMVs benötigt.
VIEW SERVER STATE wird in der aktuellen Implementierung für DBCC SQLPERF(LOGSPACE) benötigt.

Zusätzlich muss der WWS-Login Zugriff auf die WWS-Hauptdatenbank, die _FileIndex-Datenbank und für die suspect_pages-Prüfung auf msdb besitzen.

Sicherheitshinweis: Vergeben Sie dem WWS-Login nicht allein für den HealthCheck die feste Serverrolle sysadmin. Die oben genannten Rechte sind deutlich eingeschränkter und sollten bevorzugt gezielt vergeben werden.

Für SQL Server 2019 und älter deckt VIEW SERVER STATE einen größeren Teil der verwendeten serverweiten Prüfungen ab:

GRANT VIEW SERVER STATE TO [WWSLogin];

Zusätzlich ist weiterhin der notwendige Datenbankzugriff auf Hauptdatenbank, _FileIndex und msdb erforderlich.

Verhalten der WWS-Warnungen

Die meisten HealthCheck-Meldungen sind zustandsbasiert.

Das bedeutet:

Solange das Problem besteht, bleibt die Warnung relevant.
Wird sie in der WWS als erledigt markiert, obwohl der Fehler weiterhin vorhanden ist, kann sie beim nächsten HealthCheck erneut erscheinen.
Sobald der HealthCheck eine echte Entwarnung erkennt, wird die Systemmeldung automatisch entfernt.

Davon abweichend sind die Fehler 823, 824 und 825 ereignisbasiert:

Ein konkretes Ereignis wird nur einmal gemeldet.
Eine vom Benutzer erledigte alte Meldung bleibt erledigt.
Erst ein neu auftretender 823-, 824- oder 825-Eintrag löst erneut eine Warnung aus.

Derzeit nicht Bestandteil des HealthChecks

Der aktuelle DatabaseHealthCheck überwacht derzeit nicht:

klassische SQL-Server-Replikation mit Publisher/Distributor/Subscriber,
DBCC CHECKDB im 15-Minuten-HealthCheck; die Integritätsprüfung erfolgt bewusst in einem separaten, selteneren DeepCheck,
detaillierte Always-On-Datenbankqueues oder Send-/Redo-Latenzen.

Ein vollständiger DBCC CHECKDB ist absichtlich nicht Bestandteil des häufig laufenden 15-Minuten-HealthChecks. Die Prüfung wird vom separaten DatabaseHealthDeepCheck übernommen, da sie je nach Datenbankgröße erheblichen I/O-Aufwand verursachen kann.

Datenbankwartung und Fehlersuche

Übersicht der überwachten Warnungen

SQL Server: Verdächtige Datenbankseiten

Lösung

SQL Server: I/O-Warnungen 823/824/825

Fehler 823

Fehler 824

Fehler 825

Lösung bei 823, 824 oder 825

SQL Server: Kritischer Speicherplatz

Lösung

SQL Server: Auffällige I/O-Latenz

Mögliche Ursachen

Lösung

SQL Server: Transaktionsprotokoll

Häufige Werte von Log Reuse Wait

Lösung

SQL Server: Datenbankkonfiguration

Datenbankstatus ist nicht ONLINE

Lösung

PAGE_VERIFY ist nicht auf CHECKSUM eingestellt

Lösung

SQL Server: Datenspiegelung gestört

Mögliche Ursachen

Lösung

SQL Server: Always On-Verfügbarkeitsgruppe gestört

Bedeutung

Lösung

SQL Server: Datenbanksicherung veraltet oder fehlerhaft

Standardwerte

Automatische Erkennung des üblichen Backupintervalls

Veraltetes oder fehlendes Backup

Lösung

Transaktionslog-Backup fehlt

Differential-Backup fehlt

Backup mit is_damaged = 1

Besonderheit bei Always On

Einstellungen speichern

SQL Server: Datenbankintegrität fehlerhaft

Lösung

SQL Server: Integritätsprüfung unvollständig

Lösung

SQL Server: Datenbanküberwachung unvollständig

Lösung

Fehler durch fehlende SQL-Berechtigungen

SQL-Server-Errorlog kann nicht gelesen werden

Verdächtige Datenbankseiten können nicht geprüft werden

Freier Speicherplatz kann nicht geprüft werden

I/O-Latenzen können nicht geprüft werden

Transaktionsprotokolle können nicht geprüft werden

Datenbankkonfiguration kann nicht geprüft werden

Sicherungshistorie kann nicht geprüft werden

Database Mirroring kann nicht geprüft werden

Always On-Verfügbarkeitsgruppen können nicht geprüft werden

DBCC CHECKDB kann nicht ausgeführt werden

Empfohlene Berechtigungen für den HealthCheck

Verhalten der WWS-Warnungen

Derzeit nicht Bestandteil des HealthChecks

Backup mit `is_damaged = 1`