Wissen

Praxis-Artikel und Buchkapitel zu SQL-Performance, Sicherheit und Hochverfügbarkeit – alle frei verfügbar.

Beratung

Festpreis-Analyse mit Bericht und Handlungsempfehlung – oder strategische Begleitung bei Architektur, Migration und Hochverfügbarkeit.

Zur Beratung

Fachbücher

Die fünfbändige Reihe „Ulis SQL-Bibliothek“ – Band 1 verfügbar. Leseprobe herunterladen!

Zu den Büchern

Tools

UB.SimSQL: SQL-Server-Lastsimulator mit regelbasierten Konfigurationsempfehlungen. Lokal, ohne Cloud, ohne Abo.

Tools ansehen

Schulungen

Online-Workshops zu Performance, Sicherheit und Entwicklung – kompakt, hands-on, ohne MOC-Folienschlacht.

Zu den Schulungen

Table of Contents

SQL Server Notfälle: Triage und erste Schritte

Strukturierte Notfalldiagnose für den SQL-Server-Ernstfall – bevor Panik die Lage verschlimmert.

SQL Server brennt: Wann der Notarztwagen wirklich hilft

Triage-System, Erste-Hilfe-Werkzeugkasten und 10 Symptome, die jeder DBA kennt.

Es ist 02:47 Uhr in der Nacht zum Sonntag. Der Diensthandy-Pager piepst zum dritten Mal. Du hängst halb angezogen auf dem Wohnzimmersofa, der Laptop balanciert auf den Knien, und du starrst auf eine VPN-Verbindung, die sich beim besten Willen nicht aufbaut. Auf der anderen Seite der Leitung: ein Anrufer aus der IT-Abteilung, der sich überschlägt vor Erklärungen, und ein SQL Server, der seit vierzig Minuten nicht mehr antwortet. Die Frühschicht der Buchhaltung kommt in zwölf Stunden ins Büro. Bis dahin müssen die Lohnläufe durch sein, sonst wird's eng.

Willkommen im echten Leben eines SQL-Server-Administrators. Genau für diese Momente gibt es den Notarztwagen — und genau darum geht es in diesem Beitrag.

Warum überhaupt ein Notarztwagen?

Wenn ein Server brennt, hilft keine schöne Architektur-Folie und kein Performance-Tuning-Buchkapitel. In dem Moment hilft nur eines: schnelle Triage, klare Reihenfolge der Maßnahmen und jemand, der nicht zum ersten Mal in dieser Lage ist. Genauso wie bei der echten Notfallmedizin: Triage, Stabilisieren, Diagnose, Therapie — in genau dieser Reihenfolge. Wer in der Akutphase auf DBCC CHECKDB losrennt, ohne erst die Symptome zu sortieren, der braucht später länger und richtet meist mehr Schaden an als das ursprüngliche Problem.

Der SQL-Server-Notarztwagen ist genau dieser Versuch, das Chaos zu strukturieren. Ein eigener Themenbereich auf boddenberg.de, in dem jedes typische Notfallsymptom seinen eigenen Diagnose-Beitrag bekommt, jeder mit klaren ersten Schritten, klaren Zuordnungen und klaren Empfehlungen, wann du selbst weitermachen kannst und wann besser jemand übernehmen sollte, der schon zehn Mal in genau dieser Lage war.

Bevor wir in die Symptome eintauchen, eine ehrliche Vorbemerkung: dieser Beitrag ersetzt keine echte Notfallhotline. Er hilft dir, in den ersten 15 Minuten die richtige Richtung einzuschlagen und nicht in die typischen Anfängerfallen zu tappen — abrupt den Server neuzustarten, das Transaktionslog wegzulöschen, ALTER DATABASE SET EMERGENCY ohne Backup hinterher. Wer sich nach diesen 15 Minuten unsicher fühlt, ruft an. Punkt.

Das Triage-System: Rot, Gelb, Grün

In jeder echten Notaufnahme der Welt sortiert man Patienten in drei Schweregrade, bevor man auch nur einen Finger an sie legt. Genauso machen wir das hier mit SQL-Server-Notfällen. Die Spurensuche fängt damit an, dass du dein Symptom einer der drei Stufen zuordnest.

Rot heißt: jetzt sofort. Der Server reagiert nicht, das Telefon klingelt im Minutentakt, alle Anwender sind betroffen. Das ist die Lage, in der du nichts ausprobieren willst, was du nicht zu 100 Prozent verstehst. Schraub erst dann an Konfigurationen, wenn du weißt, was du tust — oder ruf jemanden, der es weiß. Klassische rote Symptome: Server hängt, CPU dauerhaft auf 100 Prozent, Transaktionslog voll, Recovery Pending, Suspect Datenbank.

Gelb heißt: dringend, aber kein Brand. Das System läuft, aber täglich schlechter — Antwortzeiten sind länger geworden, Deadlocks häufen sich, Backups fallen sporadisch aus. Hier kannst du systematisch analysieren, ohne dass dir gleichzeitig die Hütte um die Ohren fliegt. Klassische gelbe Symptome: Server „langsam“, Deadlock-Wellen, Blocking-Kaskaden, schlagende Backups, instabile Verbindungen.

Grün heißt: Vorsorge. Du willst proaktiv messen, einen Health-Check fahren, dich für eine Migration vorbereiten oder dem internen Audit zuvorkommen. Hier ist alles in Ordnung — und du willst dafür sorgen, dass das so bleibt. Im Notarztwagen-Kontext ist Grün der einzige Zustand, in dem du dich in Ruhe hinsetzen und ein PowerShell-Skript laufen lassen kannst, ohne dass jemand panisch wird.

Wichtige Faustregel

Wenn du dir bei der Triage unsicher bist, stufe immer eine Klasse höher ein. Lieber einmal zu vorsichtig den Notfall ausrufen, als zu spät zu merken, dass das vermeintlich „nur langsame“ System längst kurz vor dem Kollaps stand. Im Zweifelsfall ist Rot besser als Gelb, und Gelb besser als Grün.

Der Symptom-Katalog: 10 Notfälle, die jeder DBA kennt

Hier kommt die eigentliche Karte des Notarztwagens. Jedes der zehn Symptome hat einen eigenen Detailbeitrag mit konkreten Diagnose-Skripten, Wahrscheinlichkeitsanalyse der Ursachen und Schritt-für-Schritt-Anleitungen. Klick dich gerne durch — die Reihenfolge ist die der typischen Häufigkeit, mit der ich diese Symptome in echten Engagements sehe.

Stufe ROT — Akute Notfälle

SQL Server hängt vollständig [ROT] — Keine Verbindungen mehr möglich, der SQL Server Agent antwortet nicht, Management Studio läuft in Timeouts. Erste Diagnose über die Dedicated Admin Connection (DAC), falls aktiviert.

CPU dauerhaft bei 100 Prozent [ROT] — Last verteilt sich gleichmäßig auf alle Kerne oder konzentriert sich auf einen Kern. Verdächtige: parallele Queries, fehlende Indizes, Tempdb-Spill, Statistiken aus dem letzten Jahrtausend.

Transaktionslog voll [ROT] — Die Datenbank steht. Schreibvorgänge werden mit „LOG_FULL“-Fehler abgewiesen. Erste Reaktion: NICHT das Log löschen. Erst denken, dann handeln.

Datenbank im Status „Recovery Pending“ [ROT] — Die Datenbank wurde nicht sauber wiederhergestellt, oft nach einem unsanften Neustart oder Storage-Problemen. ERRORLOG ist dein bester Freund — bevor du irgendwas tust.

Datenbank im Status „Suspect“ [ROT] — Das ist die rote Karte unter den Notfällen. Das Datenbank-Engine hat aufgegeben. Restore aus letztem konsistentem Backup ist meistens die saubere Lösung — der Weg dahin ist die Frage.

Stufe GELB — Dringende Probleme

Server „läuft langsam“ [GELB] — Der Allzweck-Hilferuf der DBA-Welt. Die Diagnose-Pyramide steht: erst Wait Stats, dann Plan-Cache, dann I/O, dann der Code. In dieser Reihenfolge.

Deadlocks häufen sich [GELB] — Vereinzelte Deadlocks sind normal, aber wenn sie zu Wellen werden, hast du strukturelle Probleme — meist in der Indexierung, der Isolation Level oder der Reihenfolge, in der Transaktionen Sperren anfordern.

Blocking-Kaskaden [GELB] — Eine lang laufende Transaktion blockiert eine zweite, die wiederum eine dritte blockiert — und plötzlich warten 80 Anwender auf den einen, der heute morgen seine Schnittstelle gestartet hat und Kaffee trinken gegangen ist.

Backups schlagen fehl [GELB] — Nichts schmeckt schlechter, als am Restore-Tag festzustellen, dass die letzten 14 Backups Müll sind. Die Ursachen sind oft trivial: Zielmedium voll, Service-Account-Berechtigungen, MAXTRANSFERSIZE.

Verbindung fehlgeschlagen [GELB] — Login Failed for User „NT AUTHORITY/ANONYMOUS LOGON“ und ähnliche Kerberos-Grüße. Meistens SPN-Registrierung, Delegation oder Firewall — selten der Server selbst.

Hinweis zur Verlinkung

Jedes der zehn Symptome bekommt einen eigenen Detailbeitrag mit konkreten Skripten und Praxisbeispielen. Die Liste wird laufend erweitert, weil die Realität immer kreativer ist als jede Liste. Wenn dir ein Symptom fehlt, das du regelmäßig siehst — schreib mir, es kommt mit auf die Karte.

Der Erste-Hilfe-Werkzeugkasten

Bevor du in die Detailbeiträge der einzelnen Symptome eintauchst, gibt es fünf Skripte, die du in jedem SQL-Notfall brauchst. Diese fünf solltest du auswendig kennen oder als Snippet in jedem Management-Studio-Profil parat haben. Wer im Notfall erst googeln muss, hat schon verloren.

Skript 1: Wer läuft gerade auf dem Server?

Die alleroberste Frage in jedem Notfall: wer macht gerade was? sys.dm_exec_requests ist die zentrale DMV dafür. Sie zeigt dir alle aktiven Anfragen, ihre Wartezustände, ihre CPU- und I/O-Werte und den aktuell ausgeführten SQL-Text.

SELECT r.session_id,

r.status,

r.command,

r.wait_type,

r.wait_time,

r.blocking_session_id,

r.cpu_time,

r.logical_reads,

DB_NAME(r.database_id) AS db_name,

SUBSTRING(t.text, (r.statement_start_offset/2)+1,

((CASE r.statement_end_offset

WHEN -1 THEN DATALENGTH(t.text)

ELSE r.statement_end_offset

END – r.statement_start_offset)/2)+1) AS statement_text

FROM sys.dm_exec_requests r

CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t

WHERE r.session_id > 50

ORDER BY r.cpu_time DESC;

Die wichtigsten Spalten in der Krise: wait_type sagt dir, worauf der Server gerade wartet. blocking_session_id ist nicht null, wenn die Session von jemand anderem blockiert wird. Und cpu_time in absteigender Sortierung deckt den Schuldigen auf, wenn die CPU brennt.

Skript 2: Wer wartet auf wen?

Wenn das Blocking-Symptom auftaucht, brauchst du die Blocking-Kette. sys.dm_os_waiting_tasks kombiniert mit sys.dm_exec_sessions gibt dir die komplette Wartepyramide.

SELECT w.session_id,

w.wait_type,

w.wait_duration_ms,

w.blocking_session_id,

s.host_name,

s.program_name,

s.login_name

FROM sys.dm_os_waiting_tasks w

JOIN sys.dm_exec_sessions s

ON w.session_id = s.session_id

WHERE w.blocking_session_id IS NOT NULL

ORDER BY w.wait_duration_ms DESC;

Damit identifizierst du den Head-Blocker — also die Session, die ganz oben in der Wartepyramide steht und auf niemanden mehr wartet, aber alle anderen blockiert. Im Normalfall ist das der Anwender, der eine offene Transaktion in seinem Excel-Frontend stehen lässt und Mittagspause macht.

Skript 3: Wie steht's um das Transaktionslog?

Bei der Log-voll-Symptomatik ist das Erstgespräch immer DBCC SQLPERF(LOGSPACE) — gibt dir den Füllstand aller Logs in einer Übersicht.

DBCC SQLPERF(LOGSPACE);

— Welche Datenbank, welches Recovery Model, was hält das Log offen?

SELECT name,

log_reuse_wait_desc,

recovery_model_desc,

state_desc

FROM sys.databases

WHERE name NOT IN ('master', 'tempdb', 'model', 'msdb');

Die Spalte log_reuse_wait_desc ist die Killer-Information: sie sagt dir genau, warum das Log nicht abgeschnitten wird. Klassiker sind LOG_BACKUP (es fehlt schlicht eine Log-Sicherung), ACTIVE_TRANSACTION (eine uralte offene Transaktion blockiert) und AVAILABILITY_REPLICA (Synchronisierung in einer AG hängt).

Skript 4: Wo sitzt die I/O-Latenz?

Wenn der Server „langsam“ ist und die CPU nicht hochgeht, ist es meistens I/O. sys.dm_io_virtual_file_stats gibt dir die durchschnittlichen Lese- und Schreibzeiten pro Datei.

SELECT DB_NAME(vfs.database_id) AS db_name,

mf.physical_name,

vfs.num_of_reads,

vfs.io_stall_read_ms,

CAST(vfs.io_stall_read_ms / NULLIF(vfs.num_of_reads,0) AS DECIMAL(10,2))

AS avg_read_latency_ms,

vfs.num_of_writes,

vfs.io_stall_write_ms,

CAST(vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes,0) AS DECIMAL(10,2))

AS avg_write_latency_ms

FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs

JOIN sys.master_files mf

ON vfs.database_id = mf.database_id

AND vfs.file_id = mf.file_id

ORDER BY avg_read_latency_ms DESC;

Faustregel für Datenbankdateien: alles unter 10 ms ist gut, 10–20 ms ist tolerabel, 20–50 ms ist ein Warnschild, alles über 50 ms ist ein Problem. Für Logdateien sollte es deutlich schneller sein — Schreiblatenzen über 5 ms sind in der Regel schon zu langsam.

Skript 5: Was sind die Top-Wartetypen?

Wenn du den allgemeinen Gesundheitszustand checken willst, gehört sys.dm_os_wait_stats auf den Schirm. Vorsicht: das ist eine kumulierte Statistik seit dem letzten Server-Restart, du brauchst entweder eine Baseline oder du resetst sie bewusst vor der Messung.

— Top-10 Wartetypen seit letztem Reset, gefiltert um Idle-Waits

SELECT TOP 10

wait_type,

waiting_tasks_count,

wait_time_ms,

wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_ms,

signal_wait_time_ms

FROM sys.dm_os_wait_stats

WHERE wait_type NOT IN (

'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE',

'SLEEP_TASK', 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH',

'WAITFOR', 'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',

'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT',

'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT',

'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',

'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT',

'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'

)

ORDER BY wait_time_ms DESC;

Die Interpretation der Wartetypen ist eine eigene Wissenschaft — CXPACKET riecht nach Parallelität, PAGEIOLATCH_* nach I/O-Engpass, LCK_M_* nach Blocking, SOS_SCHEDULER_YIELD nach CPU-Druck. Eine vollständige Übersicht der Wartetypen mit Praxis-Interpretationen findest du in Band 1: Performance der SQL-Server-Buchreihe, Kapitel 4.

Wann reicht das eigene Team, wann brauchst du externe Hilfe?

Eine der ehrlichsten Fragen, die du dir in einem Notfall stellen kannst: schaffe ich das selbst, oder brauche ich jemanden, der schon hundertmal in genau dieser Situation war? Die Antwort ist nicht schwarz-weiß — sie hängt davon ab, was auf dem Spiel steht und wieviel Zeit du hast.

Du schaffst das selbst, wenn: das Symptom klar einer der zehn Standard-Kategorien zuzuordnen ist, du die Skripte aus dem Erste-Hilfe-Werkzeugkasten verstehst und du bei den Befunden nicht ins Schwitzen kommst. Wenn du sagen kannst: aha, LOG_BACKUP im log_reuse_wait_desc — also eine Log-Sicherung anstoßen und dann die Backup-Strategie korrigieren — dann bist du auf der sicheren Seite. Mach es selbst. Dokumentiere, was du getan hast, und plane einen Tag in Ruhe für die Ursachenanalyse.

Du brauchst Hilfe, wenn: die Diagnose nach 15 Minuten nicht eindeutig ist, oder wenn du in eine Maßnahme reinläufst, deren Auswirkungen du nicht zu 100 Prozent überblickst. Klassische Beispiele: eine Suspect-Datenbank, bei der du keine konsistenten Backups hast. Ein Always-On-Verfügbarkeitsgruppen-Failover, das nicht sauber durchläuft. Ein Recovery, das sich seit 90 Minuten am gleichen Prozent festgebissen hat. Eine Korruption, die du in DBCC CHECKDB findest, aber deren Schweregrad du nicht einschätzen kannst.

Die ehrliche Wahrheit

Niemand kennt jeden Notfall. Auch ich nicht. Was Erfahrung dir gibt, ist nicht die Allwissenheit über alle möglichen Probleme — sondern die ruhige Hand in den ersten Minuten und das Gespür dafür, welche Maßnahme den Schaden vergrößert und welche ihn begrenzt. Anrufen ist keine Schwäche. Anrufen ist Risikomanagement.

Was tun in den ersten 15 Minuten?

Egal ob du selbst weitermachst oder externe Hilfe rufst — diese sieben Schritte solltest du in jedem Notfall durchgehen, bevor du irgendetwas anderes tust. Sie kosten dich maximal 15 Minuten, und sie verhindern, dass du die Situation versehentlich verschlimmerst.

Erstens: Atmen. Drei tiefe Atemzüge. Das klingt esoterisch, ist aber medizinisch betrachtet das wichtigste, was du in den ersten 30 Sekunden tun kannst. Adrenalin sabotiert dein Urteilsvermögen, und du fällst Entscheidungen im Notfall, die du im Nachhinein nicht mehr verstehst.

Zweitens: Nicht den Server neustarten. Egal wie verlockend es ist. Ein Neustart vernichtet alle DMV-Daten zur Ursachenanalyse, kann offene Transaktionen in unbekannte Zustände bringen und löst das Problem zu 80 Prozent nicht — es kommt nach 20 Minuten wieder. Neustart ist eine bewusste Entscheidung am Ende, nicht der erste Reflex.

Drittens: ERRORLOG sichern. Bevor irgendwer auf die Idee kommt, „mal kurz aufzuräumen“, kopiere das aktuelle ERRORLOG plus die letzten zwei archivierten in einen sicheren Ordner. Ohne diese Datei ist eine spätere forensische Analyse fast unmöglich.

Viertens: Screenshot vom Activity Monitor. Auch wenn Management Studio gerade noch reagiert: einen Screenshot machen, sys.dm_exec_requests einmal in eine Datei exportieren. Das sind die Beweismittel des Notfalls.

Fünftens: Wer ist alles betroffen? Ein Anruf in der IT, eine kurze Mail an die Hauptanwender: „SQL Server X reagiert nicht, wir analysieren, voraussichtliche Wiederherstellungszeit unbekannt.“ Klare Kommunikation reduziert die Anzahl Folge-Anrufe um den Faktor zehn.

Sechstens: Backup-Status checken. Wann lief das letzte funktionierende Backup? Welcher Backup-Typ? Wo liegt es? Das ist die Information, die du brauchst, falls die Lage eskaliert — und sie ist im Notfall oft schwer zu beschaffen, wenn der Backup-Server selbst betroffen ist.

Siebtens: Symptom triagieren. Erst jetzt ordnest du das Problem einer der zehn Standardkategorien zu und arbeitest mit dem Detailbeitrag des entsprechenden Symptoms weiter. Nicht vorher.

Vertiefung in der Buchreihe „SQL Server in der Praxis“

Der Notarztwagen ist die erste Hilfe — die strukturelle Lösung der zugrundeliegenden Probleme findest du in der Buchreihe „SQL Server in der Praxis“. Fünf Bände, jeder ein eigenes Spezialgebiet, alle mit dem gleichen pragmatischen, du-Anrede-und-keine-Marketing-Versprechen-Ansatz.

Die fünf Bände der SQL-Server-Reihe

Band 1: Performance — die Detailtiefe zu Wait Stats, Index-Strategie, Tempdb-Tuning, Statistiken, Plan-Cache. Das ist der Band, den du nach einem CPU- oder Performance-Notfall liest. Band 2: Security, Compliance & Governance — Verschlüsselung, NIS2, DSGVO, Berechtigungs-Audits. Hier findest du die Antwort auf die Frage „warum sollten wir mal über sa-Account-Disabling reden“. Band 3: Hochverfügbarkeit & Disaster Recovery — Always On, Failover Cluster, Log Shipping, Restore-Strategien. Pflichtlektüre nach jedem Recovery-Pending-Erlebnis. Band 4: Migration — Versions-Upgrades, Plattform-Wechsel, Cloud-Pfade. Vor jeder Migration einmal durchgelesen, spart später 80 Prozent der Schmerzen. Band 5: SQL Server für Entwickler — wie schreibt man Code, der nicht beim ersten Lasttest implodiert. Inklusive der typischen ORM-Sünden.

Die Bücher sind keine Akademie-Lehrbücher und kein Marketingmaterial — sie sind das aufgeschrieben, was ich in 30 Jahren Microsoft-Beratung wirklich gelernt habe. Mit Anekdoten von echten Kundensituationen, fiktive Beispielfirmen wie der Trendforge Digital GmbH und der Musterwerk GmbH durchziehen die Bände als roter Faden. Das macht das Lesen erträglich und das Anwenden direkt umsetzbar.

Drei Wege zur Hilfe — je nach Notlage

Wenn du bis hier durchgelesen hast, weißt du, ob du selbst weiter kannst oder ob du jemanden brauchst. Hier sind die drei Wege, je nach Schweregrad:

Wenn es jetzt gerade brennt (rote Stufe)

Ruf an. Telefon ist im Notfall jedem schriftlichen Kanal überlegen — schneller, klarer, eindeutiger. Reaktionszeit für Rückruf in akuten Lagen ist binnen vier Stunden, in 90 Prozent der Fälle deutlich schneller. Halt parat: welcher Server, welche Version, welches Symptom, welchen log_reuse_wait_desc du gerade siehst. Wenn du diese vier Informationen hast, kann das Gespräch direkt mit der Analyse starten und nicht mit der Bestandsaufnahme.

Wenn es kontinuierlich knirscht (gelbe Stufe)

Festpreis-Analyse. Eine strukturierte zweitägige Vollanalyse des SQL-Servers mit anschließendem schriftlichem Befund-Bericht. Im Bericht: Befunde sortiert nach kritisch / mittel / niedrig, Aktionsplan im Click-by-Click-Format, Rollback-Szenarien für jede Maßnahme. Das ist die Variante für den Fall, in dem du Klarheit über den Zustand des Systems brauchst, ohne dass gleichzeitig der Brand löschen ist.

Wenn du proaktiv messen willst (grüne Stufe)

Selbst-Diagnose-Kit. Ein PowerShell-Skript-Paket, das dir die wichtigsten Performance-Metriken eines SQL-Servers in DSGVO-konformer Form einsammelt — Wait Stats, Index-Health, I/O-Latenzen, Konfiguration. Kostenlos, ohne Anmeldung, mit klarer Anleitung. Damit kannst du deinen Server selbst durchchecken oder mir die Daten schicken für eine pauschale Schnellanalyse.

Was du jetzt tun kannst

Speichere diese Seite als Lesezeichen. Im Notfall hast du keine Zeit, sie zu suchen — und das ist genau der Moment, in dem du sie brauchst. Wenn dir ein Symptom in den zehn aufgelisteten fehlt, das du regelmäßig siehst, schreib mir kurz. Die Karte wird gepflegt, und jeder ergänzte Symptom-Beitrag macht den Notarztwagen für alle nützlicher.

Bleib ruhig, bleib strukturiert, und vergiss nicht: die meisten SQL-Server-Notfälle, die in den ersten 15 Minuten lebensgefährlich wirken, sind nach einer Stunde geduldiger Analyse völlig harmlos. Und für die anderen gibt es den Notarztwagen.

SQL-Server-io-latenz

I/O-Latenz hoch — Storage als Bottleneck Wenn Millisekunden zu Sekunden werden: Latenz aus SQL-Sicht messen, Schwellenwerte kennen — und mit Zahlen statt Gefühl verhandeln. Es ist Mittwochnachmittag, 14:23 Uhr. Bei Sparfuchs & Partner ist seit der großen...

SQL Server Statistiken veraltet

Statistiken veraltet — Parameter Sniffing und Plan-Regression Gestern 0,5 Sekunden, heute 45: Wenn der Optimizer auf falschen Zahlen plant. Diagnose, Auswege und die Query-Store-Versicherung. Es ist Donnerstagmorgen, 06:42 Uhr. Bei der Musterwerk GmbH ruft die...

SQL Server Memory Pressure

Memory Pressure — wenn der Buffer Pool zu klein wird Page Life Expectancy im Sturzflug, Grants in der Warteschlange: So erkennst du, ob der Druck von innen oder von außen kommt. Es ist Dienstagvormittag, 09:12 Uhr. Bei der Trendforge Digital GmbH ist seit letzter...

SQL Server tempdb-Probleme diagnostizieren

Tempdb-Probleme — voll, langsam oder Contention Tempdb ist das Schmiermittel des ganzen Servers. Wenn es klemmt, klemmt alles — so unterscheidest du die drei Krankheitsbilder. Es ist Montagmittag, 12:05 Uhr. Bei der Musterwerk GmbH bricht der große Monatsreport...

SQL Server Backup schlägt fehl

Backup schlägt fehl — Fehleranalyse mit System Ein fehlgeschlagenes Backup ist keine Lappalie, sondern eine tickende Uhr. So findest du die Ursache — und so verhinderst du das nächste Mal. Es ist Freitagmorgen, 07:38 Uhr. Die erste Mail des Tages kommt vom...

SQL Server läuft langsam – die Diagnose-Pyramide

SQL Server läuft langsam — die Diagnose-Pyramide „Das System ist träge“ ist kein Befund, sondern ein Gefühl. So machst du in vier Stufen eine Diagnose daraus — ohne Schnellschüsse. Es ist Mittwochmorgen, 08:51 Uhr. Das Telefon klingelt, am anderen...

SQL Server Blocking: Kaskaden diagnostizieren

Blocking-Kaskaden auflösen Eine Transaktion blockiert dutzende: den Head-Blocker finden, die Wartepyramide verstehen — und gezielt statt blind eingreifen. Es ist Donnerstagnachmittag, 15:33 Uhr. Bei Sparfuchs & Partner steht die Warenwirtschaft — nicht...

SQL Server Deadlocks analysieren und beheben

Deadlock-Wellen analysieren und beheben Vereinzelte Deadlocks sind Alltag — Wellen sind ein Konstruktionsfehler. So liest du den Graph und findest die Ursache. Es ist Dienstagvormittag, 10:47 Uhr. Bei der Musterwerk GmbH läuft seit dem Wochenende die neue Version...

SQL Server Login fehlgeschlagen: Error 18456

Login fehlgeschlagen — Error 18456 und Verwandte Der Klassiker mit den State-Codes: Was bedeutet State 2 vs. 38 vs. 58 — und wann steckt Kerberos dahinter? Es ist Montagmorgen, 08:14 Uhr. Bei der Trendforge Digital GmbH läuft der Kaffee, aber sonst läuft...

SQL Server hängt vollständig

SQL Server hängt vollständig Der Server reagiert nicht mehr. Die DAC als Notausgang, die sieben häufigsten Ursachen und die eskalierende Diagnose für die ersten 15 Minuten. Es ist Dienstagvormittag, 10:47 Uhr, bei der Trendforge Digital GmbH. Der...

SQL Server: CPU dauerhaft bei 100 Prozent

CPU dauerhaft bei 100 Prozent Alle Kerne brennen. Die Diagnose-Pyramide vom Top-Verursacher zum Query-Plan, die sieben häufigsten Brandstifter, Quick-Wins und Nachsorge. Es ist Montagmorgen, 08:14 Uhr, bei der Musterwerk GmbH. Die erste Schicht hat sich...

SQL Server Transaktionslog voll

Transaktionslog vollgelaufen Schreibvorgänge stoppen mit Fehler 9002. Die Diagnose über log_reuse_wait_desc, alle relevanten Werte mit Lösungsweg — und die zwei Anti-Patterns, die alles schlimmer machen. Es ist Donnerstagnachmittag, 16:38 Uhr, bei...

SQL Server Cumulative Updates installieren

Cumulative Updates und Service Packs einspielen Patchen ist Pflicht — aber mit Bedacht. Der Pre-Patch-Post-Workflow, die Always-On-Rolling-Strategie und die eine Regel: nie am Freitag. Patchen ist wie der Zahnarztbesuch der Datenbankwelt: Jeder weiß, dass er...

SQL Server Disaster Recovery Test

Disaster Recovery Test — wie man es wirklich tut Backups, die nie wiederhergestellt wurden, sind keine. Die drei Test-Stufen, was wirklich gemessen wird — und warum das echte RTO fast immer länger ist. Jedes Bürogebäude hat eine Brandschutzordnung,...

SQL Server Migration vorbereiten

SQL Server Migration vorbereiten Versions-Upgrade, neue Hardware, Cloud-Pfad: Die vier Phasen, der Rollback-Plan zuerst — und warum der Compatibility Level ein eigener Schritt ist. Eine SQL-Server-Migration ist wie ein Umzug in eine neue Wohnung: Das Tragen der...

SQL Server DBCC CHECKDB – Konsistenz-Strategie

DBCC CHECKDB — die Konsistenz-Strategie Wann, wie oft, auf welcher Maschine? Korruption früh finden, statt sie im Backup mitzusichern — und richtig reagieren, wenn sie auftaucht. Datenkorruption ist die heimtückischste aller Datenbank-Krankheiten, weil sie...

SQL Server Backup-Strategie planen

Backup-Strategie planen — RPO, RTO und die 3-2-1-Regel Wie oft, was, wohin? Von den zwei entscheidenden Fragen zur fertigen Strategie — und warum ein ungetestetes Backup keines ist. Es gibt zwei Sorten von Unternehmen: solche, die eine durchdachte Backup-Strategie...

SQL Server Query Store aktivieren und nutzen

Query Store aktivieren und nutzen Der Flugschreiber des SQL Servers: Plan-Regressionen erkennen, Ressourcenfresser finden, Upgrades absichern — wenn er rechtzeitig läuft. Stell dir ein Flugzeug ohne Flugschreiber vor. Solange alles glattgeht, fehlt er niemandem....

SQL Server tempdb konfigurieren

Tempdb optimal konfigurieren Wie viele Dateien, wie groß, auf welchem Storage? Die fünf Stellschrauben einer Wegwerf-Datenbank, an der der ganze Server hängt. Es gibt in jedem SQL Server eine Datenbank, die niemandem gehört und an der trotzdem alle...

SQL Server Index-Wartung

Index-Wartung systematisch — Rebuild, Reorganize, Statistiken Wann reorganisieren, wann neu aufbauen? Den Fragmentierungs-Mythos entzaubern und intelligent warten statt mit dem Vorschlaghammer. Es gibt einen Wartungsjob, den fast jeder SQL Server hat und fast keiner...

SQL Server Health Check – der Selbsttest

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...

SQL Server Wait Stats interpretieren

Wait Stats interpretieren — der DBA-Kompass Wartetypen sind die Sprache, in der der SQL Server seine Engpässe erklärt. Wer sie liest, rät nicht mehr — er weiß, wo er gräbt. Stell dir zwei DBAs vor, die denselben langsamen Server vor sich...

Always-On-Replica synchronisiert nicht

Always-On-Replica synchronisiert nicht Synchronization Health rot, Queues wachsen, die Uhr tickt: Log Send Queue von Redo Queue unterscheiden — und gezielt eingreifen. Es ist Freitagnachmittag, 16:48 Uhr. Bei der Trendforge Digital GmbH steht für das Wochenende...

SQL Server – Datenbank im Status Recovery Pending

Datenbank im Status Recovery Pending Die Datenbank kommt nach dem Neustart nicht hoch. ERRORLOG-Diagnose, die vier häufigsten Ursachen und die sichere Lösungssequenz — ohne reflexhafte Reparatur. Es ist Sonntagvormittag, 11:17 Uhr, kurz nach einem geplanten...

SQL Server: Datenbank im Status Suspect

Datenbank im Status Suspect Die rote Karte. Die Recovery-Pyramide vom Goldstandard (Restore + Tail-Log) bis zur Notlandung (REPAIR_ALLOW_DATA_LOSS) — und was du unter keinen Umständen tun darfst. Es ist Dienstagmorgen, 06:42 Uhr, bei der Musterwerk GmbH. Die...