SQL Server: Angemeldete Benutzer trennen und Datenbank umbenennen

Eine SQL-Server-Datenbank lässt sich nur umbenennen, über eine bestehende Fassung wiederherstellen oder löschen, solange keine andere Sitzung darauf zugreift. Sind noch Anwender angemeldet, trennst du sie vorher: entweder mit einer einzigen Anweisung (ALTER DATABASE … SET SINGLE_USER WITH ROLLBACK IMMEDIATE) oder gezielt per KILL für jede Sitzung. Dieser Beitrag zeigt beide Wege samt Skript und die Fallstricke, an denen es in der Praxis hakt — für Administratoren und Entwickler, die gelegentlich eine Datenbank umbenennen müssen.

Warum lässt sich eine Datenbank mit angemeldeten Benutzern nicht umbenennen?

Weil ALTER DATABASE … MODIFY NAME exklusiven Zugriff auf die Datenbank braucht. Solange eine fremde Sitzung darin arbeitet — ein Anwendungsserver, ein Bericht, ein offenes Management-Studio-Fenster —, scheitert die Anweisung. Dasselbe gilt für eine Wiederherstellung über eine bestehende Datenbank und für das Löschen. Die Lösung ist nicht Warten, sondern gezieltes Trennen.

Bevor du etwas trennst, schau nach, wer überhaupt verbunden ist. Die Sicht sys.dm_exec_sessions führt für jede Sitzung die aktuelle Datenbank (database_id), den Anmeldenamen und die Anwendung:

SELECT s.session_id
     , s.login_name
     , s.host_name
     , s.program_name
     , s.status
     , s.last_request_end_time
  FROM sys.dm_exec_sessions AS s
 WHERE s.database_id = DB_ID(N'Kundendaten')
   AND s.is_user_process = 1
   AND s.session_id <> @@SPID;

Die Abfrage zeigt Sitzungen, deren aktueller Datenbankkontext die Zieldatenbank ist. Wer aus einer anderen Datenbank per Dreiteilnamen zugreift, taucht nicht auf — prüfe deshalb nach dem Trennen, ob das Umbenennen wirklich durchläuft.

program_name verrät, ob hinter einer Sitzung ein Anwendungsserver, ein Berichtswerkzeug oder ein Kollege mit Management Studio steckt — und damit, wen du vorher anrufen solltest.

Wann du exklusiven Zugriff brauchst

• Umbenennen — ALTER DATABASE … MODIFY NAME
• Wiederherstellen über eine bestehende Datenbank — etwa ein Testsystem aus der Produktionssicherung neu aufsetzen
• Löschen — DROP DATABASE
• Offline nehmen — zum Verschieben oder Kopieren der Dateien
• Zustand wechseln — etwa zwischen READ_ONLY und READ_WRITE; die Dokumentation verlangt dafür ausdrücklich exklusiven Zugriff

Wie trennst du alle Benutzer mit einer einzigen Anweisung?

Mit ALTER DATABASE … SET SINGLE_USER WITH ROLLBACK IMMEDIATE. Die Anweisung trennt alle anderen Verbindungen sofort, macht ihre offenen Transaktionen rückgängig und lässt nur noch eine Sitzung zu. Danach benennst du die Datenbank um und gibst sie mit SET MULTI_USER wieder frei. Das ist der Standardweg, den auch die Microsoft-Dokumentation zum Umbenennen zeigt.

USE master;

BEGIN TRY
    ALTER DATABASE [Kundendaten] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    ALTER DATABASE [Kundendaten] MODIFY NAME = [Kundendaten_alt];
    ALTER DATABASE [Kundendaten_alt] SET MULTI_USER;
END TRY
BEGIN CATCH
    -- Etwas ist schiefgegangen: Datenbank unter altem oder neuem Namen wieder für alle öffnen
    IF DB_ID(N'Kundendaten') IS NOT NULL
        ALTER DATABASE [Kundendaten] SET MULTI_USER;
    ELSE IF DB_ID(N'Kundendaten_alt') IS NOT NULL
        ALTER DATABASE [Kundendaten_alt] SET MULTI_USER;
    THROW;
END CATCH;

Die Anweisungen laufen in master, damit deine eigene Sitzung nicht selbst in der Datenbank steht. Der CATCH-Zweig ist kein Schmuck: Scheitert ein Schritt, bliebe die Datenbank sonst im Einzelbenutzermodus hängen, und niemand käme mehr hinein. Er prüft deshalb beide Namen, den alten und den neuen.

Probiere das Vorgehen zuerst auf einer Testinstanz und lege vorher eine Sicherung an: Das Trennen verwirft offene Arbeit der Anwender unwiderruflich.

Drei Varianten der Klausel decken die übrigen Fälle ab:

• WITH ROLLBACK AFTER 60 SECONDS wartet die angegebene Zeit und macht erst danach rückgängig — Anwender können ihre Arbeit abschließen.
• WITH NO_WAIT lässt die Anweisung sofort scheitern, wenn der Zustandswechsel nicht auf der Stelle möglich ist, statt zu blockieren.
• SET RESTRICTED_USER statt SINGLE_USER lässt Mitglieder von db_owner, dbcreator und sysadmin weiter zu, und zwar in beliebiger Zahl — praktisch, wenn mehrere Administratoren gemeinsam an der Datenbank arbeiten.

Wie beendest du einzelne Sitzungen gezielt mit KILL?

KILL <session_id> beendet genau eine Sitzung und macht deren offene Transaktion rückgängig. Sinnvoll ist das, wenn du selbst bestimmen willst, wen es trifft — etwa Berichtsabfragen verschonen oder festhalten, wer getrennt wurde. Weil KILL nur eine feste Zahl akzeptiert und keine Variable, baut das Skript den Befehl je Sitzung dynamisch zusammen.

Wer unseren früheren Tipp „T-SQL KILL“ kennt: Die Idee — angemeldete Clients per Skript mit KILL entfernen — ist geblieben, die Abfrage nutzt jetzt sys.dm_exec_sessions statt der älteren Sichten wie sys.sysprocesses oder der Prozedur sp_who.

DECLARE @db   sysname = N'Kundendaten';
DECLARE @spid int     = 0;
DECLARE @cmd  nvarchar(30);

WHILE 1 = 1
BEGIN
    SELECT @spid = MIN(s.session_id)
      FROM sys.dm_exec_sessions AS s
     WHERE s.database_id     = DB_ID(@db)
       AND s.is_user_process = 1
       AND s.session_id     <> @@SPID
       AND s.session_id      > @spid;

    IF @spid IS NULL BREAK;

    SET @cmd = N'KILL ' + CAST(@spid AS nvarchar(10));

    BEGIN TRY
        EXEC (@cmd);
    END TRY
    BEGIN CATCH
        PRINT CONCAT(N'Sitzung ', @spid, N' nicht beendet: ', ERROR_MESSAGE());
    END CATCH;
END;

Das Skript geht die Sitzungen der Reihe nach durch, statt sie in einer Menge zu sammeln. Dadurch wird jede Sitzung genau einmal angefasst, auch wenn eine davon gerade zurückrollt. is_user_process = 1 schließt Systemsitzungen aus, <> @@SPID schützt deine eigene — Systemprozesse lassen sich ohnehin nicht beenden.

Was du daran einstellen kannst:

• Auswahl eingrenzen: Wer nur bestimmte Anmeldungen trennen will, ergänzt login_name oder program_name in der WHERE-Bedingung. Wer eine Liste von Sitzungs-IDs als Parameter übergibt, zerlegt sie vorab, wie es der Beitrag zum Zerlegen von Zeichenketten in T-SQL zeigt.
• Protokollieren: Vor dem KILL lassen sich login_name, host_name und program_name in eine Protokolltabelle schreiben. Wie eine solche Tabelle sinnvoll gebaut wird — und welche Pflichten sie datenschutzrechtlich mitbringt —, steht im Beitrag zu Audit-Triggern.
• Fortschritt prüfen: Ein KILL kehrt zurück, aber der Rollback der Transaktion kann bei großen Änderungen dauern. KILL <session_id> WITH STATUSONLY zeigt den Fortschritt; in sp_who steht die Sitzung währenddessen als KILLED/ROLLBACK.

Nach der Schleife erst die Abfrage aus dem ersten Abschnitt noch einmal laufen lassen und dann umbenennen:

ALTER DATABASE [Kundendaten] MODIFY NAME = [Kundendaten_alt];

Ein Nachteil bleibt: KILL sperrt keine neuen Anmeldungen. Meldet sich eine Anwendung zwischen Skript und MODIFY NAME neu an, ist der exklusive Zugriff wieder weg. Genau hier ist das Verfahren aus dem vorigen Abschnitt überlegen.

Welches Verfahren passt wann?

Für das reine Umbenennen oder Wiederherstellen ist SINGLE_USER WITH ROLLBACK IMMEDIATE fast immer richtig, sofern die Anwender vorgewarnt sind: eine Anweisung, keine Lücke für Neuanmeldungen. Das KILL-Skript lohnt sich, wenn du auswählen oder protokollieren willst. Wer Anwendern Zeit lassen möchte, nimmt ROLLBACK AFTER.

Welche Fallstricke gibt es beim Trennen?

Trennen heißt: Nicht gespeicherte Arbeit der Anwender geht verloren, und die Anwendung versucht oft sofort, sich neu zu verbinden. Halte deshalb vorab die Anwendung an, plane den Rollback ein, probiere den Ablauf vorher auf einer Testinstanz und lege eine Sicherung an. Prüfe danach, was am alten Datenbanknamen hängt. Diese Punkte entscheiden meist, ob das Umbenennen glatt läuft.

Offene Transaktionen gehen verloren. ROLLBACK IMMEDIATE und KILL machen sie rückgängig, ohne Rückfrage. Wer gerade eine Buchung erfasst, hat sie danach nicht mehr. Bei großen Transaktionen kann der Rollback selbst spürbar dauern — die Sitzung ist dann „getrennt“, hält ihre Sperren aber noch, bis er durch ist.

Anwendungen melden sich neu an. Mit Verbindungspool oder automatischer Wiederverbindung ist die Anwendung nach dem Trennen binnen Sekunden wieder da. Im Einzelbenutzermodus belegt sie dann den einzigen erlaubten Platz, und deine nächste Anweisung scheitert mit dem Hinweis, dass die Datenbank nur einen Benutzer zulässt. Gegenmittel: den Anwendungsdienst vorher anhalten. Ein gemeinsamer Batch wie im Beispiel oben verkleinert nur das Zeitfenster, er schließt es nicht.

Das Umbenennen ändert keine Dateinamen. Die logischen Dateinamen und die Dateien auf dem Datenträger behalten ihren alten Namen. Wer sie angleichen will, muss das gesondert tun.

Alles, was den alten Namen kennt, bricht. Verbindungszeichenfolgen, Aufträge des SQL Server Agent, Skripte mit Dreiteilnamen wie Kundendaten.dbo.Rechnung, Synonyme und Sicherungsjobs. Such vor dem Umbenennen in Code und Konfiguration nach dem alten Namen; danach ist es zu spät für ein ruhiges Nachziehen.

Rechte und Zuständigkeit. Für ALTER DATABASE brauchst du das ALTER-Recht auf die Datenbank. KILL verlangt die Berechtigung ALTER ANY CONNECTION, die in den festen Serverrollen sysadmin und processadmin enthalten ist. Und: Ein Eingriff in laufende Arbeit gehört abgesprochen, nicht still ins Wartungsfenster geschoben. Wie sich Sperren und Blockierungen im laufenden Betrieb verhalten, vertieft das Seminar Datenbankübergreifendes Performance-Tuning.

Wie läuft das Umbenennen in fünf Schritten ab?

Prüfen, Anwendung anhalten, trennen, umbenennen, freigeben — und in genau dieser Reihenfolge. Wer das Anhalten der Anwendung überspringt, riskiert, dass sie sich zwischen Trennen und Umbenennen neu anmeldet und den exklusiven Zugriff wieder blockiert. Mit der Reihenfolge unten bleibt das Zeitfenster klein.

1. Sitzungen prüfen — die Abfrage auf sys.dm_exec_sessions zeigt, wer verbunden ist und mit welcher Anwendung.
2. Anwendung anhalten oder Anwender vorwarnen — ein Anruf spart mehr Ärger als jedes Skript.
3. Trennen — mit SET SINGLE_USER WITH ROLLBACK IMMEDIATE oder dem KILL-Skript.
4. Umbenennen — ALTER DATABASE … MODIFY NAME = … im selben Batch wie Schritt 3.
5. Freigeben und anpassen — SET MULTI_USER, Verbindungszeichenfolgen und Aufträge auf den neuen Namen umstellen, Anwendung starten, Zugriff prüfen.

Häufige Fragen (FAQ)

Wie trenne ich in SQL Server alle Benutzer von einer Datenbank?

Mit ALTER DATABASE [Name] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;, ausgeführt in master. Die Anweisung trennt alle anderen Verbindungen sofort und macht ihre offenen Transaktionen rückgängig. Danach kannst du die Datenbank umbenennen, wiederherstellen oder löschen und sie anschließend mit SET MULTI_USER wieder freigeben. Offene Transaktionen und nicht gespeicherte Arbeit der Anwender gehen dabei verloren — vorher absprechen und sichern.

Warum scheitert das Umbenennen einer Datenbank?

Weil für ALTER DATABASE … MODIFY NAME exklusiver Zugriff nötig ist. Solange eine andere Sitzung mit der Datenbank verbunden ist, lässt sich die Anweisung nicht ausführen. Mit sys.dm_exec_sessions findest du heraus, wer verbunden ist, und mit SINGLE_USER WITH ROLLBACK IMMEDIATE oder KILL trennst du diese Sitzungen.

Was ist der Unterschied zwischen KILL und ROLLBACK IMMEDIATE?

KILL beendet eine einzelne Sitzung, die du selbst auswählst. ROLLBACK IMMEDIATE trennt als Teil von ALTER DATABASE alle anderen Sitzungen auf einmal und sperrt zugleich neue Anmeldungen, sobald die Datenbank im Einzelbenutzermodus ist. Bei KILL können sich Anwendungen sofort neu verbinden.

Kann ich KILL mit einer Variablen aufrufen?

Nein, KILL erwartet eine feste Zahl. Wer die Sitzungsnummer aus einer Abfrage holt, baut den Befehl als Text zusammen und führt ihn mit EXEC aus, wie im Skript oben. Die Sitzungsnummer stammt dabei aus sys.dm_exec_sessions und ist eine Zahl, kein freier Text.

Wie lange dauert ein KILL?

Das Beenden selbst geht schnell, der Rollback der offenen Transaktion kann bei großen Änderungen dauern. Währenddessen steht die Sitzung als KILLED/ROLLBACK in sp_who. Mit KILL <session_id> WITH STATUSONLY zeigst du den Fortschritt an, ohne etwas zu beenden.

Meine Datenbank bleibt im Einzelbenutzermodus hängen. Was tun?

Setze sie mit ALTER DATABASE [Name] SET MULTI_USER; zurück. Das schlägt fehl, wenn eine andere Sitzung den einzigen Platz belegt; in dem Fall zuerst diese Sitzung per KILL beenden oder WITH ROLLBACK IMMEDIATE ergänzen. Ein TRY … CATCH um den Umbenennungsblock verringert die Gefahr, dass der Zustand überhaupt entsteht.

Ändert das Umbenennen auch die Dateien der Datenbank?

Nein. MODIFY NAME ändert nur den Namen der Datenbank. Logische Dateinamen und die Dateien auf dem Datenträger behalten ihre alten Namen und müssen bei Bedarf gesondert angepasst werden.

Welche Rechte brauche ich zum Trennen von Benutzern?

Für ALTER DATABASE das ALTER-Recht auf die Datenbank. Für KILL die Berechtigung ALTER ANY CONNECTION, die in den festen Serverrollen sysadmin und processadmin enthalten ist.

Quellen

Die Aussagen zu KILL, Berechtigungen, ROLLBACK AFTER, RESTRICTED_USER und sys.dm_exec_sessions stammen aus der Herstellerdokumentation (abgerufen 06.10.2026):

• KILL (Transact-SQL) — Syntax, WITH STATUSONLY, erforderliche Berechtigung ALTER ANY CONNECTION
• ALTER DATABASE (Transact-SQL) — MODIFY NAME
• ALTER DATABASE SET-Optionen — SINGLE_USER, RESTRICTED_USER, MULTI_USER, Abschlussklauseln ROLLBACK AFTER, ROLLBACK IMMEDIATE, NO_WAIT
• Datenbank umbenennen — Ablauf im Einzelbenutzermodus, Hinweis zu Azure SQL Database
• sys.dm_exec_sessions — Spalten database_id, is_user_process, program_name

SQL Server, Azure und Management Studio sind Marken der Microsoft Corporation; dozent.net steht in keiner Verbindung zum Hersteller.

Verwandte Seminare und Artikel

• SQL Server Audit-Trigger: Änderungen sauber protokollieren — Änderungen an Daten protokollieren und was dabei rechtlich zu beachten ist
• T-SQL: Zeichenketten zerlegen — STRING_SPLIT und die Wege davor — Zeichenketten in T-SQL zerlegen, etwa eine Liste von Sitzungs-IDs
• SQL Server T-SQL Programmierung — Seminar: Skripte, Fehlerbehandlung und Transaktionen in T-SQL
• Datenbankübergreifendes Performance-Tuning — Seminar: Ausführungspläne, Indexstrategie und Sperrverhalten
• SQL Fortgeschritten — Seminar: Abfragen jenseits der Grundlagen

Im Seminar vertiefen

Skripte wie dieses sind Handwerkszeug aus der T-SQL-Programmierung: Schleifen, dynamisches SQL, Fehlerbehandlung mit TRY … CATCH und der saubere Umgang mit Transaktionen. Das Seminar SQL Server T-SQL Programmierung übt genau das anhand praxisnaher Beispiele. Zu diesem Thema gibt es Seminare und Beratung — vor Ort in Köln und Leverkusen sowie bundesweit inhouse oder remote; das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Die Anfrage ist unverbindlich und kostenlos; Umfang und Konditionen klären wir danach individuell.

Die Anfrage ist unverbindlich und kostenlos; Umfang und Konditionen klären wir danach individuell.