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 Webshop nimmt keine Bestellungen mehr an, das interne ERP zeigt nur noch die Sanduhr, und in der Hotline stapeln sich die Anrufe. Der erste Blick gilt der Datenbank — und das Management Studio bleibt beim Verbindungsversuch einfach hängen. Kein Fehler, kein Timeout, nur ein Drehkreis, der sich dreht und dreht. Der SQL Server, das Herz des ganzen Betriebs, reagiert nicht mehr. Und während im Hintergrund die ersten Stimmen lauter werden und jemand schon nach dem Neustart-Knopf schielt, stellt sich genau eine Frage: Was jetzt — und in welcher Reihenfolge?

Willkommen beim akutesten aller Notfälle aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/). Ein vollständig hängender Server fühlt sich an wie ein Herzstillstand — und genau wie in der Notfallmedizin entscheidet die richtige Reihenfolge über den Ausgang. Dieser Beitrag zeigt dir die ersten fünfzehn Minuten: wie du überhaupt noch an den Server herankommst (Stichwort DAC), wie du in wenigen Schritten die Ursache eingrenzt, und welchen einen Reflex du um jeden Preis unterdrücken musst. Kein Theorie-Vortrag, sondern der Griff, der im Ernstfall sitzt.

Was „der Server hängt“ technisch bedeutet

„Der Server hängt“ ist ein Symptom, kein Befund — und die wichtigste erste Unterscheidung lautet: Ist der Dienst tot oder ist die Engine eingefroren? Das sind zwei völlig verschiedene Lagen mit völlig verschiedenen Maßnahmen. Beim toten Dienst läuft der SQL-Server-Prozess gar nicht mehr — er ist abgestürzt oder hat sich beim Start nicht hochgefahren. Bei der eingefrorenen Engine läuft der Prozess noch, nimmt aber keine Arbeit mehr an: Er ist da, aber unerreichbar, wie ein Patient mit Puls, der nicht ansprechbar ist. Welcher der beiden Fälle vorliegt, bestimmt alles Weitere — und es lässt sich in Sekunden klären, indem man den Status des Windows-Dienstes prüft, statt es zu raten.

Der häufigere und tückischere Fall ist die eingefrorene Engine. Hier läuft der Dienst, aber etwas verstopft den Server so vollständig, dass keine normale Verbindung mehr durchkommt. Die typische Ursache ist, dass alle Worker-Threads belegt sind — der SQL Server arbeitet jede Anfrage über einen Worker-Thread aus einem begrenzten Pool ab, und wenn alle Threads in einer Blocking-Kette, in CPU-Last oder im Warten auf weggebrochenes Storage feststecken, ist schlicht keiner mehr frei, um deine Verbindungsanfrage anzunehmen. Der Server ist dann nicht abgestürzt, sondern erstickt an seiner eigenen Last. Und genau für diese Situation gibt es einen Notausgang, den die meisten nicht kennen.

Dieser Notausgang ist die Dedicated Admin Connection (DAC). Sie ist eine vom SQL Server fest reservierte Verbindung mit einem eigenen Worker-Thread und einem eigenen Speicherbereich, die nur dem Administrator-Notfall gehören. Während die regulären Verbindungen alle am verstopften Pool scheitern, hat die DAC ihren eigenen, immer freien Kanal — sie ist der Dienstboteneingang, durch den du hineinkommst, wenn die Vordertür verrammelt ist. Sie zu kennen und im Ruhezustand für den Fernzugriff vorbereitet zu haben, ist der Unterschied zwischen einer gezielten Diagnose und einem blinden Neustart aus Verzweiflung.

Abgrenzung: Dienst tot vs. Engine eingefroren Dienst tot — der SQL-Server-Prozess läuft nicht (Absturz, Start gescheitert). Diagnose über den Dienst-Status und das ERRORLOG; die DAC hilft hier NICHT, weil gar keine Engine läuft. Engine eingefroren — der Prozess läuft, nimmt aber keine Arbeit mehr an (Worker-Threads verstopft). Hier ist die DAC der Notausgang, über den die Ursachen-Diagnose läuft.

Der Diagnose-Pfad für die ersten 15 Minuten

Im Notfall zählt die Reihenfolge. Der folgende Pfad führt dich von der einen entscheidenden Frage über den DAC-Notausgang bis zur Eingrenzung der Ursache — und zeigt den Reflex, den du unterdrücken musst:

Die Skripte: hineinkommen und den Übeltäter finden

Schritt 1 — Über die DAC hineinkommen

Wenn das Management Studio nicht mehr durchkommt, ist die DAC über sqlcmd der Weg hinein. Der Schalter -A erzwingt die Admin-Verbindung:

:: Aus einer Eingabeaufforderung (cmd / PowerShell), NICHT aus dem SSMS-Query: sqlcmd -S MeinServer -E -A   — (Einmalig im RUHEZUSTAND vorbereiten: DAC fuer Fernzugriff freischalten) EXEC sp_configure 'remote admin connections', 1; RECONFIGURE;   — Pruefen, ob die DAC ueberhaupt lauscht (Port im ERRORLOG): — Suche nach 'Dedicated admin connection support was established'

Wichtig: Die DAC gibt es pro Instanz nur einmal — ist sie schon belegt, kommt niemand zweites hinein. Und sie aus einer Eingabeaufforderung zu nutzen ist entscheidend, weil das grafische SSMS bei einem hängenden Server selbst oft nicht mehr reagiert. Wer remote admin connections nicht vorab freigeschaltet hat und nicht lokal am Server sitzt, steht jetzt vor verschlossener Tür — deshalb gehört diese Einstellung in die Vorsorge.

Schritt 2 — Den Server in 60 Sekunden vermessen

Einmal über die DAC drin, willst du schnell wissen, woran der Server erstickt. Diese Abfrage zeigt die aktiven Anfragen, ihre Wartetypen und wer wen blockiert — die Übersichtsaufnahme des Notfalls:

— Aktive Anfragen, Wartetypen und Blocking auf einen Blick SELECT r.session_id, r.status, r.command, r.wait_type, r.wait_time / 1000.0 AS WartezeitSek, r.blocking_session_id AS BlocktVon, r.cpu_time, r.total_elapsed_time FROM sys.dm_exec_requests AS r WHERE r.session_id > 50 — System-Sessions ausblenden ORDER BY r.wait_time DESC;

Lies das von oben: Häufen sich LCK_-Wartetypen mit gefüllter BlocktVon-Spalte, ist es eine Blocking-Kette. Dominiert PAGEIOLATCH, steht das Storage. Bei RESOURCE_SEMAPHORE ist der Speicher knapp, bei THREADPOOL sind die Worker-Threads erschöpft. Der Wartetyp ist der Fingerzeig auf den richtigen Detail-Beitrag.

Schritt 3 — Den Head-Blocker gezielt finden

Ist es Blocking, brauchst du den Kopf der Kette — die Session, die alle anderen blockiert, selbst aber auf niemanden wartet:

— Head-Blocker: blockiert andere, wird selbst nicht blockiert SELECT w.session_id AS BlockierteSession, w.blocking_session_id AS Blocker, w.wait_type, w.wait_duration_ms, t.text AS BlockerStatement FROM sys.dm_os_waiting_tasks AS w OUTER APPLY ( SELECT TOP 1 st.text FROM sys.dm_exec_connections AS conn CROSS APPLY sys.dm_exec_sql_text(conn.most_recent_sql_handle) AS st WHERE conn.session_id = w.blocking_session_id ) AS t WHERE w.blocking_session_id IS NOT NULL ORDER BY w.wait_duration_ms DESC;   — Nur im Notfall und gezielt: die EINE blockierende Session beenden — KILL <session_id>; — mit Bedacht, niemals blind

Die sieben häufigsten Ursachen

Ein vollständig hängender Server hat fast immer einen dieser sieben Gründe. Dieser Beitrag ist die Eingangsdiagnose — für jede Ursache gibt es einen eigenen Detail-Beitrag im Notarztwagen mit der ausführlichen Behandlung:

1. Blocking-Kette

Eine lange, nicht abgeschlossene Transaktion hält Sperren und blockiert eine wachsende Kette weiterer Sessions, bis nichts mehr geht. Der Head-Blocker steht oben, alle anderen warten auf ihn. Gezielt den Kopf finden und nur den beenden — Details im Blocking-Beitrag (/sql-server-blocking/).

2. CPU am Anschlag

Alle Kerne bei 100 Prozent — keine Abfrage kommt mehr durch, weil keine Rechenzeit frei ist. Oft eine entartete Abfrage oder Parameter Sniffing. Ausführlich im CPU-Beitrag (/sql-server-cpu-100-prozent/).

3. Memory Pressure

Der Buffer Pool erstickt, Abfragen warten ewig auf Speicher-Zuteilung (RESOURCE_SEMAPHORE). Der Server lebt noch, kommt aber nicht vom Fleck. Mehr im Memory-Pressure-Beitrag (/sql-server-memory-pressure/).

4. Transaktionslog voll

Ist das Log voll, stoppen alle Schreibvorgänge schlagartig — und ein Server, der nicht mehr schreiben kann, wirkt wie eingefroren. Die Lösung steht im Transaktionslog-Beitrag (/sql-server-transaktionslog-voll/).

5. tempdb voll oder unter Contention

Weil sich die ganze Instanz tempdb teilt, lähmt eine volle oder verstopfte tempdb alles gleichzeitig. Diagnose und Behandlung im tempdb-Beitrag (/sql-server-tempdb-probleme/).

6. I/O-Stillstand

Antwortet das Storage nicht mehr oder extrem langsam (PAGEIOLATCH-Waits in Sekunden statt Millisekunden), steht der Server still, obwohl er „läuft“. Hier liegt das Problem unter dem SQL Server, oft im Storage-Subsystem selbst.

7. Worker-Threads erschöpft (THREADPOOL)

Der hinterhältigste Fall: Sind alle Worker-Threads in einer der obigen Lagen festgefahren, kann der Server keine neuen Anfragen mehr annehmen — auch deine nicht. Der Wartetyp THREADPOOL ist das Kennzeichen, und genau hier ist die DAC mit ihrem eigenen Thread oft die einzige Tür, die noch aufgeht.

Was du auf keinen Fall tun solltest

Nicht: Sofort den Dienst killen und neu starten. Der reflexhafte Neustart ist der häufigste und teuerste Fehler. Er verwischt alle Diagnose-Spuren, kann ein langes, nicht unterbrechbares Rollback offener Transaktionen auslösen — und die Ursache kehrt prompt zurück, weil sie nie gefunden wurde.

Nicht: Blind und mehrfach neu starten, „weil es vielleicht beim dritten Mal klappt“. Jeder weitere Neustart verlängert nur die Ausfallzeit und das Rollback. Wenn ein kontrollierter Neustart nötig ist, dann einer — danach Ursache klären, nicht weiter probieren.

Nicht: Wahllos KILL auf Sessions absetzen. Die falsche Session zu beenden kann ein riesiges Rollback starten und die Lage verschlimmern. Erst den Head-Blocker sauber identifizieren, dann gezielt genau diese eine Session beenden.

Nicht: Erst im Notfall feststellen, dass die DAC nicht erreichbar ist. Ohne vorab freigeschaltete Remote-DAC stehst du bei einem hängenden Server vor verschlossener Tür. Diese Freischaltung gehört in die Vorsorge, nicht in die Krise.

Die drei häufigsten Anfängerfehler 1. Aus Panik sofort neu starten — und damit Spuren, Ursache und oft auch noch Minuten durch ein langes Rollback verlieren. 2. Nicht zwischen totem Dienst und eingefrorener Engine unterscheiden — und die DAC bei einem gar nicht laufenden Dienst suchen, wo sie nicht helfen kann. 3. Die DAC erst im Ernstfall entdecken. Wer sie nicht kennt und nicht vorbereitet hat, hat im Notfall kein Werkzeug, sondern nur den Neustart-Knopf.

Nachsorge: damit es nicht wiederkommt

Ist der Server wieder erreichbar, ist die Arbeit nicht vorbei — ein Hänger ist immer ein Symptom, und das Symptom kehrt zurück, wenn die Ursache bleibt. Drei Schritte für die Postmortem-Analyse: Erstens, die Ursache aus den Diagnose-Daten festhalten — welcher Wartetyp dominierte, welche Session war der Head-Blocker, was tat sie? Diese Spur ist Gold wert und genau das, was ein blinder Neustart vernichtet hätte. Zweitens, die Remote-DAC dauerhaft freischalten und den Zugang dokumentieren, damit der nächste Notfall mit einem griffbereiten Werkzeug beginnt statt mit der Suche danach. Drittens, die eigentliche Ursache strukturell angehen — über den passenden Detail-Beitrag, ob das nun die Blocking-Vermeidung, die CPU-Entlastung oder die tempdb-Konfiguration ist. Der akute Griff rettet den Moment; die Nachsorge verhindert die Wiederholung.

Vertiefung in der Buchreihe

Notfall-Diagnose, DMV-Forensik und die DAC füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Empfohlene Bände Band 1: Performance & Troubleshooting — das Heimatbuch dieses Beitrags: die DMV-Forensik für den Notfall, Wartetypen, Blocking und die DAC im Detail. Band 3: Hochverfügbarkeit & Disaster Recovery — wie man durch Always-On und Failover dafür sorgt, dass ein hängender Server nicht den ganzen Betrieb lahmlegt.

Verwandte Notfälle im Notarztwagen

Ein hängender Server führt fast immer zu einer der konkreten Ursachen — diese Beiträge sind die nächste Station:

CPU dauerhaft bei 100 Prozent (/sql-server-cpu-100-prozent/) — wenn keine Rechenzeit mehr frei ist und der Server an Last erstickt.

Blocking-Kaskaden auflösen (/sql-server-blocking/) — die häufigste Einzelursache: den Head-Blocker finden und gezielt lösen.

Tempdb-Probleme — voll, langsam oder Contention (/sql-server-tempdb-probleme/) — wenn die gemeinsame Arbeitsdatenbank die ganze Instanz lähmt.

Transaktionslog vollgelaufen (/sql-server-transaktionslog-voll/) — wenn alle Schreibvorgänge schlagartig stoppen.

Drei Wege, wenn der Server jetzt gerade hängt

Akut-Hotline

Wenn der Server in diesem Moment hängt und jede Minute zählt: anrufen. Halte bereit, ob der SQL-Dienst noch läuft (oder gestoppt ist) und ob du über die DAC noch hineinkommst — das sind die zwei Informationen, die den schnellsten Weg bestimmen. Meist lässt sich gemeinsam in wenigen Minuten klären, ob es ein Head-Blocker, eine Ressourcen-Erschöpfung oder ein toter Dienst ist, und die richtige Maßnahme einleiten — gezielt statt mit dem Neustart-Holzhammer.

Festpreis-Analyse

Wenn dein Server schon mehrfach gehangen hat und du wissen willst, warum — und wie du es strukturell abstellst? Die Festpreis-Analyse liefert die Antwort: Ich werte die Vorfälle aus, identifiziere das wiederkehrende Muster (Blocking, Ressourcen, Konfiguration), prüfe die Anfälligkeiten und liefere einen Bericht mit priorisierten Maßnahmen, die den nächsten Stillstand verhindern. Zum vereinbarten Festpreis, ohne Stundenzähler.

Selbst-Diagnose-Kit

Für alle, die für den nächsten Ernstfall gerüstet sein wollen: Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — DAC-Zugang und Freischaltung, die 60-Sekunden-Übersichtsabfrage, die Head-Blocker-Suche — plus den Diagnose-Pfad zum Ausdrucken und eine Notfall-Checkliste für die ersten fünfzehn Minuten. Damit hast du, wenn es darauf ankommt, ein Werkzeug in der Hand statt nur den Neustart-Knopf.

Ein letzter Tipp Prüfe heute, solange alles ruhig läuft, eine einzige Sache: Ist auf deinem wichtigsten Server die Remote-DAC freigeschaltet — und weißt du, wie du dich per sqlcmd über sie verbindest? Das sind fünf Minuten im Ruhezustand. Wenn der Server das nächste Mal hängt, ist genau das der Unterschied zwischen einer gezielten Diagnose in zwei Minuten und einem blinden Neustart, der Spuren vernichtet und die Ursache zurückkehren lässt. Der Notausgang muss vorbereitet sein, bevor es brennt — danach kommt man nicht mehr an ihn heran.

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.

Was tun, wenn der SQL Server nicht mehr antwortet?

Ruhe bewahren und der Reihe nach diagnostizieren, statt sofort den Dienst zu killen. Die erste Frage lautet: Läuft der SQL-Server-Dienst überhaupt noch, oder ist er abgestürzt? Läuft er, aber die Engine reagiert nicht, ist die Dedicated Admin Connection (DAC) dein Notausgang — eine reservierte Verbindung, die durchkommt, wenn alle normalen Verbindungen scheitern. Über sie suchst du dann die Ursache: meist eine Blocking-Kette, CPU am Anschlag, Memory Pressure, ein volles Transaktionslog oder erschöpfte Worker-Threads. Der schlimmste erste Schritt ist der reflexhafte Neustart: Er verwischt alle Spuren, kann lange Rollbacks auslösen und die Ursache kehrt prompt zurück. Der ganze Diagnose-Pfad steht in diesem Beitrag.

Wie verbinde ich mich mit einem hängenden SQL Server?

Über die Dedicated Admin Connection (DAC). Wenn der normale Verbindungsweg blockiert ist — weil alle Worker-Threads belegt sind oder die Engine unter Last erstickt —, hat die DAC einen eigenen, reservierten Worker-Thread und einen eigenen Speicherbereich und kommt deshalb durch, wo sonst nichts mehr geht. Du verbindest dich am einfachsten über sqlcmd mit dem Schalter -A (für Admin): sqlcmd -S Servername -E -A. Wichtig ist, das aus einer Eingabeaufforderung zu tun, nicht über die grafische Oberfläche, die bei einem hängenden Server selbst oft nicht mehr reagiert. Einmal verbunden, stehen dir die Diagnose-Abfragen offen, um den Übeltäter zu finden.

Was ist die Dedicated Admin Connection (DAC)?

Die DAC ist eine spezielle, vom SQL Server reservierte Verbindung für genau den Notfall, in dem nichts mehr geht. Sie hat einen eigenen, dedizierten Worker-Thread und einen reservierten Speicherbereich, die nur ihr gehören — deshalb kommt sie auch dann noch durch, wenn alle normalen Worker-Threads belegt sind und der Server keine regulären Verbindungen mehr annimmt. Sie ist quasi der Dienstboteneingang für den Administrator. Es gibt sie pro Instanz genau einmal gleichzeitig, sie ist also dem einen Notfall-Zugriff vorbehalten. Standardmäßig ist sie nur lokal auf dem Server nutzbar; für den Fernzugriff muss sie explizit freigeschaltet werden — was man besser im Ruhezustand vorbereitet als im Notfall.

Wie aktiviere ich DAC für Remote-Verbindungen?

Über die Konfigurationsoption remote admin connections, die du mit sp_configure setzt: sp_configure 'remote admin connections', 1; gefolgt von RECONFIGURE. Standardmäßig ist die DAC nämlich nur von der lokalen Maschine aus erreichbar — sitzt du im Notfall nicht direkt am Server, kommst du ohne diese Freischaltung nicht über die DAC hinein. Genau deshalb ist das eine Einstellung, die man vorausschauend im Ruhezustand aktiviert, nicht erst, wenn der Server schon hängt und man womöglich gar nicht mehr hineinkommt, um sie zu setzen. Sie gehört auf die Vorsorge-Checkliste jeder wichtigen Instanz — die Skripte dazu stehen in diesem Beitrag.

Wann sollte ich den SQL-Service neu starten?

So spät wie möglich — der Neustart ist der letzte Ausweg, nicht der erste Griff. Solange du über die DAC noch hineinkommst, ist eine gezielte Maßnahme (etwa das Beenden einer einzelnen blockierenden Session) fast immer besser als der Holzhammer. Ein blinder Neustart hat drei Nachteile: Er verwischt alle Diagnose-Spuren, sodass die Ursache im Dunkeln bleibt und prompt zurückkehrt; er kann ein langes, nicht unterbrechbares Rollback offener Transaktionen auslösen, das die Ausfallzeit drastisch verlängert; und er löst das Problem oft gar nicht, weil die Ursache (etwa eine Dauerschleife in der Anwendung) sofort wieder zuschlägt. Erst wenn die DAC nicht durchkommt und keine andere Option bleibt, ist der kontrollierte Neustart gerechtfertigt.

Was sind die häufigsten Ursachen für einen hängenden SQL Server?

Sieben Verdächtige decken die allermeisten Fälle ab: eine Blocking-Kette, in der eine lange Transaktion dutzende andere blockiert; CPU dauerhaft am Anschlag, sodass keine Abfrage mehr durchkommt; Memory Pressure, bei der der Buffer Pool erstickt; ein volles Transaktionslog, das alle Schreibvorgänge stoppt; tempdb-Probleme (voll oder unter Contention); ein I/O-Stillstand, weil das Storage weg ist oder extrem langsam antwortet; und erschöpfte Worker-Threads (Thread-Pool-Starvation), bei der schlicht keine Threads mehr frei sind, um neue Anfragen zu bearbeiten. Jeder dieser Verdächtigen hat im Notarztwagen einen eigenen Detail-Beitrag — dieser hier ist die Eingangsdiagnose, die dich zum richtigen weiterleitet.

Wie finde ich den Head-Blocker in einer Blocking-Kette?

Über die Wartesicht sys.dm_os_waiting_tasks in Verbindung mit der blocking_session_id: Du suchst die Session, die andere blockiert, selbst aber auf niemanden wartet — das ist der Head-Blocker an der Spitze der Kette. Eine schnelle Variante zeigt dir alle Sessions, deren blocking_session_id ungleich null ist (die also blockiert werden), und die ID des jeweiligen Blockers; der Blocker, der selbst nicht in dieser Liste als blockiert auftaucht, ist der Kopf. Hast du ihn gefunden, prüfst du, was er tut, und entscheidest gezielt, ob du ihn beenden musst. Das Thema Blocking hat einen eigenen, ausführlichen Beitrag — dieser hier zeigt nur den schnellen Notfall-Griff über die DAC.