Wie ordne ich Microsoft SQL Server Fehlermeldungen, Statuscodes und Engine-Fehler eindeutig zu?

Fehlerklassifikation im SQL Server: Error Number, Severity, State, XACT_STATE(), HRESULT und Win32-Statuscodes im Zusammenhang lesen

Grundbausteine der T-SQL-Fehlermeldung: Error Number, Severity und State

SQL Server formatiert die meisten zur Laufzeit entstehenden Fehler nach einem festen Schema, das im Client als Kombination aus Error Number, Severity und State erscheint. Der Error Number-Wert identifiziert die Fehlermeldung eindeutig im Katalog der Engine (inklusive systemdefinierter und mancher service-/featurebezogener Meldungen). Severity ordnet den Fehler nach Wirkung und Verantwortungsbereich ein: von rein informativen Meldungen bis hin zu schweren Engine- oder Ressourcenfehlern. State ist kein „Unterfehlercode“ im Sinne einer globalen Norm, sondern ein lokaler Zusatz, der Implementierungszweige, Ursachenpfade oder Kontextvarianten derselben Fehlernummer unterscheidet. In Supportfällen ist State oft der entscheidende Hinweis, weil dieselbe Fehlernummer je nach Auslöser in unterschiedlichen Codepfaden endet.

Für die Einordnung zählt nicht nur die Zahl, sondern die Kombination: Ein identischer Error Number kann als „harmlos“ wirken, aber mit höherer Severity als Symptom eines eskalierenden Ressourcenzustands auftreten, etwa bei wiederholten Zeitüberschreitungen in Kombination mit Memory Pressure. Umgekehrt können hohe Schweregrade auftreten, ohne dass Daten beschädigt sind, beispielsweise wenn eine Verbindung abbricht, der Worker-Thread beendet wird oder eine Login-Phase scheitert. Die technische Bewertung muss deshalb immer mit dem Kontext erfolgen: betroffene Komponente (Query Processor, Storage Engine, SQLOS, Agent, HADR), Zeitbezug (einmalig vs. wiederkehrend) und Korrelation mit System-/Storage-/Netzwerkereignissen.

Transaktionskontext präzisieren: XACT_STATE(), @@TRANCOUNT und „uncommittable“

Fehlerklassifikation ist unvollständig, solange der Transaktionszustand unklar bleibt. SQL Server kann eine Transaktion nach bestimmten Fehlern in einen Zustand versetzen, in dem sie nicht mehr commitfähig ist. In diesem Moment ist nicht die ursprüngliche Fehlermeldung das alleinige Problem, sondern die Folgekaskade: weitere DML-Statements scheitern, Fehlertexte ändern sich, und ein späterer COMMIT führt nicht zur erwarteten Persistenz. XACT_STATE() liefert hier die belastbarste Kurzdiagnose: 1 für eine aktive, commitfähige Transaktion, -1 für eine aktive, aber nicht commitfähige Transaktion (Rollback erforderlich), 0 für keine aktive Transaktion. Ergänzend zeigt @@TRANCOUNT die Verschachtelungstiefe an, ohne jedoch die Commitfähigkeit zu bewerten.

Praktisch relevant ist das bei Fehlern aus Sperr-/Deadlock- und Constraint-Kontexten, aber auch bei Fehlern, die durch Abbrüche im I/O-Pfad oder durch Timeout-Semantik in Clientbibliotheken ausgelöst werden. Ein Transaktionsabbruch kann dabei durch die Engine selbst erfolgen (z. B. bei bestimmten Compile-/Runtime-Fehlern) oder durch die Anwendung erzwungen werden. In der Analyse sollte deshalb immer geprüft werden, ob ein Folgefehler nur Symptom eines bereits „vergifteten“ Transaktionskontexts ist.

• Transaktionszustand prüfen: SELECT XACT_STATE() AS xact_state, @@TRANCOUNT AS trancount;
• Rollback erzwingen, wenn uncommittable: IF XACT_STATE() = -1 ROLLBACK TRANSACTION;
• Try/Catch kontextuell nutzen: BEGIN TRY ... END TRY BEGIN CATCH SELECT ERROR_NUMBER(), ERROR_SEVERITY(), ERROR_STATE(), XACT_STATE(); END CATCH

HRESULT und Win32-Statuscodes: Brücke zwischen SQL Server, Windows und Storage-Stack

Viele der betriebskritischen SQL-Server-Meldungen tragen zusätzlich einen HRESULT oder einen Win32-Statuscode, weil die Engine bei Datei-, Netzwerk- oder Sicherheitsoperationen Windows-APIs nutzt. In solchen Fällen ist die SQL-Fehlernummer häufig nur die „Klammer“ um einen tieferen Infrastrukturfehler. Besonders bei I/O-Problemen zeigen Fehltexte typischerweise Muster wie „Operating system error …“ und nennen einen numerischen Code (Win32) oder eine 0x-Darstellung (HRESULT). Entscheidend ist die Übersetzung in die tatsächlich fehlernde Schicht: Dateisystem/Filtertreiber, Storage-Controller, Multipath/DSM, SMB-Redirector, Antimalware-Filter, Credential Provider oder Kerberos/SSPI.

HRESULT-Werte kodieren neben dem Fehler auch Herkunft und Kategorie. Win32-Codes sind die klassischeren „LastError“-Rückgabewerte aus Windows. Beide können im SQL-Kontext in unterschiedlichen Komponenten auftauchen: Storage Engine (Dateioperationen), SQLOS (Scheduler-/Threading-nahe Ressourcen), Sicherheitskontext (SSPI), HADR/Always On (Netzwerkverbindungen, Zertifikate), Agent (Subsystem-Starts). Für eine belastbare Ursachenanalyse sollten diese Codes nicht isoliert interpretiert werden. Nur die zeitliche Korrelation mit Windows-Ereignisprotokollen (System, Application) und Storage-/Netzwerkmonitoring trennt Symptome (z. B. Timeouts) von Primärursachen (z. B. wiederholte Pfad-Resets).

Praktische Lesereihenfolge: Vom Symptom zur betroffenen Komponente

Die robuste Interpretation folgt einer festen Disziplin: Zuerst wird die SQL-Fehleridentität über Error Number und den Originaltext festgelegt, danach die Auswirkung über Severity eingeordnet. Anschließend trennt State Varianten, die auf unterschiedliche Ursachenpfade hinweisen. Wenn eine Transaktion beteiligt ist, entscheidet XACT_STATE(), ob der Fehler bereits einen irreversiblen Transaktionsabbruch verursacht hat. Erst danach werden externe Codes (HRESULT/Win32) als Root-Cause-Hinweis ausgewertet, weil sie die eigentliche Ursache häufig außerhalb des SQL Servers verorten.

Diese Reihenfolge verhindert Fehlschlüsse, etwa wenn ein Deadlock-Opfer (Anwendungslogik) und ein Storage-Timeout (Infrastruktur) ähnliche Symptome wie Abbrüche oder Rollbacks erzeugen. Ebenso trennt sie Engine-Fehler, die durch falsche Objektzustände (Schema, Statistik, Berechtigungen) entstehen, von Fehlern, die nur deshalb im SQL Server sichtbar werden, weil der Prozess als erster die betroffene Ressource nutzt. In Incident-Analysen sollte daher jede Meldung konsequent als Tupel gelesen werden: (Error Number, Severity, State, Transaktionszustand, externer Statuscode) plus Komponentenkontext aus Text und begleitenden Logs.

Engine-nahe Fehlerbilder: Locks/Deadlocks, Speicher- und TempDB-Engpässe, I/O- und Storage-Fehler sowie Korruptionsindikatoren (inkl. typischer Originalmeldungen)

Locking- und Transaktionskonflikte: Blockierungen als Engine-Symptom

Locking ist im SQL Server kein Randthema, sondern Kernbestandteil der Concurrency-Control: Sperren werden durch den Lock Manager vergeben, eskalieren bei Bedarf (Row/Key/Range/Page/Table) und interagieren mit Isolation Level, Version Store (bei Snapshot-basierter Isolation) und dem Transaktionslog. Auffällige Wartezeiten entstehen deshalb häufig nicht „durch Locks an sich“, sondern durch lange laufende Transaktionen, fehlende (oder nicht sargable) Indizes, Plan-Regressionen, unpassende Parallelität oder durch externe Störungen, die eine Transaktion „festhalten“ (z. B. I/O-Latenz beim Schreiben ins Log).

Ein klassisches Engine-nahes Fehlerbild ist der Timeout beim Sperren: Die Fehlermeldung Lock request time out period exceeded. (Fehler 1222) entsteht, wenn SET LOCK_TIMEOUT oder ein klientseitiger Timeout greift. Davon zu trennen ist ein Query-Timeout auf Client-Ebene (z. B. ADO.NET), der den Server nicht zwingend veranlasst, die Ausführung sofort zu beenden; abgebrochene Abfragen hinterlassen zudem unter Umständen weiterhin laufende Server-Tasks, bis ein Abbruch tatsächlich durchgesetzt ist.

• Lock-Timeout: Fehler 1222, Originaltext Lock request time out period exceeded.; Komponente: Lock Manager/Transaktionskontext, häufig Folge langer offenen Transaktionen oder fehlender selektiver Zugriffe.
• Update-Konflikt unter Snapshot-Isolation: Fehler 3960, Originaltext typischerweise Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table '...' directly or indirectly in database '...' to update, delete, or insert the row that has been modified or deleted by another transaction.; Komponente: Version Store/Concurrency Control, tritt bei gleichzeitigen Schreibkonflikten trotz lesender Konsistenz auf.
• Lock-Eskalation und ungeplante Serialisierung: Kein einzelner Fehlercode, aber korrelierende Indikatoren sind erhöhte Wartezeiten in LCK_M_* sowie sprunghafte Veränderungen der gesperrten Ressourcen; Komponente: Lock Manager, oft ausgelöst durch große Scans, schlechte Kardinalitätsschätzungen oder fehlende Filterindizes.

Deadlocks: Erkennung, typische Meldungen und betroffene Engine-Bausteine

Deadlocks entstehen, wenn zwei oder mehr Sessions zyklisch auf Ressourcen warten, die jeweils von einer anderen Session gehalten werden. Der SQL Server löst Deadlocks aktiv auf: Ein Deadlock Monitor identifiziert Zyklen und wählt einen „Victim“, dessen Transaktion abgebrochen wird. Die Auswahl basiert unter anderem auf dem Deadlock-Priority-Konzept und auf geschätzten Rollback-Kosten; damit sind Deadlocks nicht bloß Anwendungsfehler, sondern messbare Interaktionen zwischen Zugriffswegen, Indexdesign, Sperrgranularität und Transaktionsdauer.

Der betroffene Client erhält Fehler 1205 mit dem Wortlaut Transaction (Process ID ...) was deadlocked on ... resources with another process and has been chosen as the deadlock victim. Rerun the transaction.. Parallel erscheinen Einträge im Errorlog sowie – je nach Konfiguration – Extended-Events/Trace-Ausgaben mit Deadlock-Graph. Häufige Muster sind inkonsistente Objektzugriffsreihenfolgen (Tabelle A dann B vs. B dann A), „Range Locks“ bei serializable Operationen oder FK-Checks, die unerwartete Lock-Interaktionen erzeugen.

Speicher- und TempDB-Engpässe: Grants, Spills und interne Ressourcen

Die Query-Ausführung hängt eng an Memory Clerks, Buffer Pool und dem Memory-Grant-Framework: Sorts, Hash Joins und Windowing-Funktionen fordern „Execution Memory“ an, das über Grants zugeteilt wird. Reicht das Grant nicht, weicht die Engine auf TempDB aus („Spills“). Reicht TempDB nicht, eskaliert das Problem zu harten Fehlern. Die Ursachen liegen häufig außerhalb der einzelnen Abfrage: konkurrierende speicherintensive Workloads, Parameter Sniffing mit unpassenden Grants, oder eine zu geringe Max-Server-Memory-Konfiguration im Verhältnis zu OS- und Agenten-/Backup-Prozessen.

Ein eindeutiger Indikator für echten Speicherdruck ist Fehler 701 mit dem Originaltext There is insufficient system memory in resource pool 'default' to run this query.. Dieser Fehler ist engine-nah, aber nicht automatisch „nur SQL Server“: Treibereinschränkungen, Container-Limits, OS-Memory-Pressure oder fehlerhafte Locked-Pages-Konfigurationen können die verfügbare Commit-Reserve reduzieren. TempDB-Fehler treten häufig als Folge auf: Fehler 1105 (Could not allocate space for object '...') bei erschöpftem Datenfile, und Fehler 9002 (The transaction log for database 'tempdb' is full ...) bei massivem Version-Store-/Worktable-Aufkommen oder Log-Write-Latenz.

• Insufficient memory: Fehler 701, Originaltext There is insufficient system memory in resource pool 'default' to run this query.; Komponente: Memory Manager/Resource Governor (Pool), häufig korreliert mit zu aggressiven Grants oder OS-Commit-Pressure.
• TempDB Datenfile voll: Fehler 1105, Originaltext beginnt typischerweise mit Could not allocate space for object '...'; Komponente: TempDB Allocation/Files, ausgelöst durch fehlendes Autogrowth, zu kleine Files, oder I/O-Stalls, die Wachstum/Zeroing verzögern.
• TempDB Log voll: Fehler 9002, Originaltext The transaction log for database 'tempdb' is full due to '...'; Komponente: Log Manager/TempDB Log, häufig durch Version Store (Snapshot/RCSI), große Sort/Hash-Spills oder verzögerte Log-Truncation bei internen Aktivitäten.

I/O- und Storage-Fehler: Wenn die Engine auf das Betriebssystem trifft

SQL Server kapselt Dateizugriffe über asynchrone I/O-APIs, bleibt jedoch vollständig abhängig von Storage-Stack, Controller-Cache, Multipathing, Dateisystem und deren Latenzprofil. Viele „SQL-Fehler“ sind deshalb sekundäre Symptome: Ein langsamer Log-Flush erhöht Transaktionsdauer, erzeugt Blocker und kann Deadlocks wahrscheinlicher machen; ein sporadischer Storage-Timeout produziert zunächst Retries und Wartezeiten, später harte 823/824/825-Fehler. Entscheidend ist die Trennung zwischen logischer SQL-Engine-Meldung und dem darunterliegenden Windows-Fehlercode, der im Errorlog häufig explizit ausgegeben wird.

Zu den wichtigsten I/O-Indikatoren zählen Fehler 823 (Betriebssystemfehler beim Lesen/Schreiben, häufig mit Operating system error ...), Fehler 824 (logische Konsistenzprüfung fehlgeschlagen, z. B. Checksumme/Page-ID) und Fehler 825 als Warnung, dass eine Leseoperation wiederholt werden musste. 825 ist besonders relevant, weil die Daten häufig noch „lesbar“ sind, aber bereits eine Zuverlässigkeitsstörung im Storage-Pfad signalisiert (Controller, Firmware, Verkabelung, SAN, Virtualisierung).

Korruptionsindikatoren: Von Seitenprüfungen bis zu Metadatenfehlern

Korruption zeigt sich nicht ausschließlich als „Daten kaputt“, sondern oft als Engine-Alarmkette: Page-Checks schlagen beim Lesen in den Buffer Pool fehl, LOB-Strukturen sind inkonsistent, oder Metadaten widersprechen einander. Neben 824 treten häufig Meldungen aus DBCC- oder Storage-Validierungsläufen auf, etwa Msg 8939 (Page error) oder Msg 8928 (Object/Index-ID Inkonsistenz). Solche Meldungen sind der Engine-Komponente „Storage Engine“ zuzuordnen (Allocation, B-Tree/Heap-Strukturen, IAM/PFS/GAM/SGAM), haben aber fast immer eine Infrastrukturkomponente: fehlerhafte Storage-Acknowledgements, Controller-Cache ohne Battery/Flash-Protection, defekte RAM-Module oder aggressive Filtertreiber können zu „successful completion“ bei tatsächlich unvollständigen Writes führen.

Wichtig ist die zeitliche Korrelation: 825-Warnungen, danach 823-Fehler und schließlich 824 deuten auf eine Eskalation von Zuverlässigkeitsproblemen hin. Treten Korruptionsmeldungen nach Restore auf, rückt das Backup-/Transportmedium in den Fokus; erscheinen sie nach Storage-Migrationen oder Snapshot-Rollbacks, sind Copy-offload, Changed-Block-Tracking und Konsistenzmechanismen der Plattform kritisch zu prüfen. Engine-seitig bleibt die Konsequenz dieselbe: Datenintegrität kann nicht mehr als gegeben gelten, bis Konsistenzprüfungen und eine saubere Recovery-Kette die Integrität bestätigen.

• Logische I/O-Konsistenzverletzung: Fehler 824, Originaltext beginnt mit SQL Server detected a logical consistency-based I/O error; Komponente: Buffer Manager/Storage Engine, indiziert Korruption oder inkonsistente Writes.
• Physischer I/O-Fehler: Fehler 823 mit Operating system error-Hinweis; Komponente: I/O-Schicht/OS, häufig Storage-Timeouts, Device-Errors, Filtertreiber oder Pfadinstabilität.
• Retry-Warnung als Vorläufer: Fehler 825, Originaltext ... succeeded after failing ... times; Komponente: Storage-I/O, Warnsignal für schwelende Hardware-/Fabric-Probleme trotz weiterlaufender Workloads.

Dienst- und Infrastrukturkontext: Log/Recovery-Meldungen, Authentifizierung und Berechtigungen, Always On/Replication, SQL Server Agent und Wartungsjobs als Endpunkte von Fehlerketten

Viele SQL-Server-Störungen manifestieren sich zuerst an den „Rändern“ der Engine: beim Start der Instanz, beim Wiederanlauf einer Datenbank, in Login-Fehlern, bei Always On/Replication oder in fehlgeschlagenen Agent-Jobs. Diese Endpunkte sind häufig nicht die Ursache, sondern die Stelle, an der ein Fehlerzustand in einen klaren, protokollierten Status überführt wird. Die korrekte Einordnung gelingt nur, wenn Meldungstext, Fehlernummer, Status und die verantwortliche Komponente (Database Engine, SQL Server Service, SQL Server Agent, HADR/AG, Replikations-Subsystem) gemeinsam betrachtet werden.

Log- und Recovery-Meldungen: Transaktionslog, Crash Recovery, Wiederherstellungskette

Recovery-Meldungen entstehen, wenn SQL Server den Datenbankzustand aus dem Transaktionslog und den Datendateien konsistent macht. Dabei treten typische Fehlerketten auf: Ein I/O-Problem oder ein Storage-Latenzpeak führt zu Log-Flush-Fehlern; daraus folgen Verzögerungen bei WRITELOG, dann Timeouts, schließlich eine Datenbank, die beim Neustart in Recovery hängenbleibt oder in den Status SUSPECT fällt. Meldungen im Errorlog sind in diesem Bereich oft präziser als die Surface-Symptome im Client.

Charakteristische Log/Recovery-Fehler enthalten meist sowohl die physische Datei als auch den Betriebssystem-Fehler. Besonders aussagekräftig ist die Kombination aus SQL-Fehlernummer und „Operating system error …“. Ein OS-Fehler 5 (Access denied) deutet auf Rechte/ACLs oder AV/EDR-Interference, 32 auf Datei-Locks durch Fremdprozesse, 1450 auf Ressourcenmangel im I/O-Subsystem oder Filtertreibern. Der SQL-Server-Fehler ist dann Symptom einer tieferen Schicht.

• Transaktionslog nicht schreibbar: Msg 9001, Level 21, State <state>: The log for database '%.*ls' is not available. (Engine/Storage; häufig Folge von I/O-Fehlern, fehlenden Rechten oder Offline-LUN).
• Log-Flush gescheitert: Msg 9002, Level 17 (Log voll) und Msg 9001 (Log nicht verfügbar) treten oft nachgelagert zu Msg 1450 oder OS-I/O-Fehlern auf; die Engine blockiert Commit-Pfade, bis ein Log-Flush wieder möglich ist.
• I/O beim Öffnen/Initialisieren: Msg 5120, Level 16: Unable to open the physical file '...'. Operating system error ... (Engine/SQL Server Service ↔ NTFS/ReFS/SMB; häufig ACL, Pfad, Storage, File-Handle-Filtertreiber).
• Seitenlesefehler/Storage-Symptom in Recovery: Msg 823 (OS-I/O-Fehler), Msg 824 (logischer Konsistenzfehler), Msg 825 (Read-Retry) sind Datenintegritätsindikatoren; Recovery meldet die Stelle, an der Inkonsistenzen nicht mehr verborgen bleiben.

Authentifizierung und Berechtigungen: Statuscodes als Diagnose-Vektor

Login-Fehler wirken auf Anwendungsebene wie reine Sicherheitsprobleme, sind aber oft Nebenprodukte von Domänen- und Netzwerkkontext: Zeitdrift (Kerberos), SPN/Delegation, defekte Vertrauensstellungen, gesperrte AD-Konten, DNS-Fehlauflösung oder unterbrochene DC-Erreichbarkeit. SQL Server protokolliert bei Login-Fehlern bewusst Statuscodes, die zwischen „falsches Passwort“, „Login deaktiviert“ und „Datenbank nicht verfügbar“ trennen. Für eine belastbare Zuordnung müssen Error: 18456 und der State gemeinsam ausgewertet werden; der Text allein bleibt generisch.

Im Berechtigungsbereich sind typische „Endpunkt“-Meldungen weniger der Ausdruck fehlender GRANTs als von Kontextwechseln: ein Job läuft unter Proxy, ein Dienstkonto verliert Rechte auf ein Zertifikat/Key, ein Zugriff auf Netzwerkpfade scheitert wegen Double-Hop, oder Contained Database Authentication wird unerwartet verwendet. Die Engine kann in diesen Fällen korrekt „Permission was denied“ melden, obwohl die Ursache außerhalb der Datenbank liegt.

• Login fehlgeschlagen mit Status: Msg 18456, Level 14, State <state>: Login failed for user '...' (Database Engine/Security; State entscheidet über Passwort/Deaktivierung/Default-DB/Policy/Token-Probleme).
• Serverzugriff verweigert: Msg 4060: Cannot open database requested by the login. The login failed. (Engine; häufig Default-Datenbank offline, Berechtigung fehlt oder Datenbank in Recovery/SUSPECT).
• Objekt-/Schema-Berechtigung: Msg 229: The SELECT permission was denied on the object '...', database '...', schema '...'. (Engine/Authorization; kann Folge von Besitzerwechsel, fehlendem EXECUTE AS-Kontext oder fehlender Signierung sein).
• Windows-Token/AD-Kontext bricht: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (SSPI/Windows Security; häufig Trust/DNS/DC-Erreichbarkeit, nicht SQL-Berechtigungen).

Always On Availability Groups und Replikation: Netzwerk, Quorum, Endpoint und Log-Transport

HADR-Fehler sind besonders häufig Endpunkte längerer Ketten: ein kurzes Netzwerkproblem erzeugt Disconnects; daraus folgen Redo-Backlogs, Flow-Control, ggf. Failover oder „Not Synchronizing“. AG-Fehlerbilder entstehen zudem aus dem Zusammenspiel von SQL Server Database Engine, Windows Server Failover Cluster (WSFC), DNS und Zertifikats-/Endpoint-Konfiguration. Der AG-Zustand in sys.dm_hadr_database_replica_states spiegelt das Symptom; die Ursache liegt häufig in Endpoint-Erreichbarkeit (TCP/5022), Firewall, MTU/Fragmentierung oder WSFC-Health.

In der klassischen Transaktionsreplikation treten Fehler oft in Agents (Log Reader, Distribution, Merge) auf. Die Meldung verweist dann auf einen Agent-Job, ist aber technisch ein Problem in Snapshot-Freigaben, Distributor-DB, Netzwerkzugriffen oder bei nicht idempotenten DDLs. Wichtig ist die Komponentenzuordnung: Replikationsfehler erscheinen im Agent-Jobverlauf und in msdb, nicht zwingend im SQL Server Errorlog.

• AG-Endpoint nicht erreichbar: The connection to the primary replica is not active. und Endpoint-/Transportmeldungen im Errorlog (HADR/Database Mirroring Endpoint; oft TCP/Firewall/DNS/Certificate/Service Account).
• Replikations-Agent bricht ab: The process could not execute 'sp_replcmds' on '...'. (Log Reader Agent; häufig Berechtigungen, Log-Scan-Blockaden oder beschädigte Replikationsmetadaten).
• Snapshot/Share-Zugriff scheitert: The system cannot find the path specified. bzw. Access is denied. innerhalb von Agent-Ausgaben (Replikation ↔ SMB/NTFS; typischerweise Servicekonto/Proxy/UNC-Pfad/Delegation).

SQL Server Agent und Wartungsjobs: Proxies, Subsysteme, Jobhistorie als Fehlerkondensat

Der SQL Server Agent ist ein Sammelpunkt für Infrastrukturabhängigkeiten: PowerShell benötigt Execution Policy und Zugriff auf Module, CmdExec hängt an Dateisystem- und Netzwerkrechten, SSIS benötigt Laufzeit und Katalogzugriffe, und T-SQL-Schritte erben den Sicherheitskontext des Job-Owners oder eines Proxys. Fehler in Jobs sind daher häufig Abbild von Kontextfehlern, nicht von defekten Statements. Die Jobhistorie in msdb konserviert zudem nur begrenzt Ausgabe; für forensische Analysen sind zusätzliche Agent-Logs und die Ausgabeumleitung in Dateien entscheidend.

Wartungsfehler (Index-Rebuild, CHECKDB, Backup) wirken oft wie Datenbankprobleme, enden aber in Storage- oder Berechtigungsmeldungen: fehlender Zugriff auf Backup-Ziele, VSS/Storage-Snapshots, zu wenig Platz für Sort in TempDB, oder blockierte Dateien durch Drittprozesse. Wiederkehrend sind auch Fehler durch Kontextwechsel: Ein Wartungsplan läuft als Agent-Servicekonto, während manuelle Tests im interaktiven Admin-Kontext stattfinden.

• Agent-Subsystem nicht verfügbar: SQLServerAgent is not currently running so it cannot be notified of this action. (SQL Server Agent Service; häufig Dienst gestoppt, Startkonto-Rechte, msdb-Probleme).
• Proxy-/Credential-Kontext bricht: The proxy account information for a proxy is not valid. bzw. Jobausgabe mit Login failure: the user has not been granted the requested logon type (Agent/Security ↔ Local Security Policy, Servicekonto, Credential-Passwort).
• Backup-Ziel nicht erreichbar: Msg 3201: Cannot open backup device '...'. Operating system error ...
Msg 3013: BACKUP DATABASE is terminating abnormally. (Engine/Backup ↔ Storage/SMB/ACL; häufig identisch zu 5120-Kausalketten).
• Wartung scheitert an TempDB/Ressourcen: Msg 1101 / Msg 1105 (Dateigruppe voll) oder There is insufficient system memory in resource pool 'default' (Engine/Resource Governor; häufig Folge paralleler Wartungsfenster und falsch dimensionierter TempDB).