dann hast Du nichts mehr zu lachen, weil niemand mehr an die Daten gelangt. So gerade eben bei einem Kunden passiert. Die große Frage dabei ist, wie kommt man dennoch wieder in das System? Dieser Artikel beschreibt Step by Step das Vorgehen, um wieder Zugriff zum SQL Server zu gelangen.
Inhaltsverzeichnis
Problembeschreibung
Ein DBA meinte, mit Hilfe eines LOGON-Triggers in Microsoft SQL Server zu protokollieren, wann wer sich zum SQL Server auf welche Datenbank verbindet. Die Tabelle hat den folgenden Aufbau:
CREATE TABLE dbo.LogonHistory
(
Id INT NOT NULL IDENTITY (1, 1),
UserName NVARCHAR(128) NOT NULL,
LogonDate DATETIME NOT NULL,
DatabaseName NVARCHAR(128) NOT NULL,
CONSTRAINT pk_LogonHistory PRIMARY KEY CLUSTERED (Id)
);
GO
Der LOGON-Trigger wurde so programmiert, dass jedes Login automatisch in die Tabelle geschrieben wurde. Blöd nur, dass mit der Zeit der Rahmen der möglichen Werte für das Primärschlüssel-Attribut erreicht waren (in diesem Fall ca. 6 Monate). Was macht der SQL Server, wenn der LOGON-Trigger nicht korrekt ausgeführt wird? Richtig – er lässt ein Login nicht mehr zu und beendet die Verbindung. Manchmal hat man Pech und dann kommt auch noch Unglück dazu – die DAC-Verbindung wurde für den Server nicht aktiviert. Somit konnte eine administrative Verbindung nicht hergestellt werden. Man hat sich also nicht nur selbst ausgesperrt sondern auch noch die Schlüssel weggeworfen. Wie kommen wir also wieder in den Server?
Hinweis
Alle im Folgenden beschriebenen Schritte müssen unmittelbar auf dem Windows Server ausgeführt werden, auf dem SQL Server installiert wurde.
Phase 1: Server mit Minimalkonfiguration starten
Damit wir wieder an den SQL Server gelangen können, muss verhindert werden, dass der LOGON-Trigger ausgeführt wird. Das gelingt, indem der SQL Server mit „Minimalkonfiguration“ gestartet wird.
Damit einher gehen ein paar Besonderheiten, die beachtet werden müssen:
- Nur ein einziger Benutzer kann eine Verbindung herstellen, und der CHECKPOINT-Prozess wird nicht ausgeführt.
- Der Remotezugriff und das Read-Ahead werden deaktiviert.
- Für den Startvorgang vorgesehene gespeicherte Prozeduren werden nicht ausgeführt.
- tempdb wird auf die kleinstmögliche Größe konfiguriert.
- Die Überwachung wird deaktiviert, aber die Überwachungs-DDL kann weiterhin ausgegeben werden.
Phase 2: Mit sqlcmd eine Verbindung zum SQL Server herstellen
Dank Minimalkonfiguration wird verhindert, dass Servertrigger ausgeführt werden. Nun können wir uns Zugriff auf den gestarteten SQL Server verschaffen. Mit SQL Server Management Studio geht das aber nicht, da SSMS mindestens zwei Verbindungen aufbaut (siehe oben: „…ein einziger Benutzer…“).
Phase 3: Aktivierung von DAC
Eine Dedicated Administrative Connection ist in der aktuellen Situation nicht mehr erforderlich. Eigentlich würde es nun vollkommen ausreichen, den Logon Trigger zu deaktivieren, damit wieder Zugriffe auf SQL Server angenommen werden. In diesem Fall aktivieren ich DAC, damit zukünftig auch ohne einen Start mit Minimalkonfiguration auf den Server zugegriffen werden kann.
Phase 4: Deaktivieren des LOGON Triggers
Der wichtigste Schritt ist die Deaktivierung des LOGON Triggers. Dazu wird in der gleichen sqlcmd-Session der folgende Befehl ausgeführt:
Phase 5: Neustart von SQL Server mit vollständiger Konfiguration
Sobald der LOGON Trigger deaktiviert wurde (ich habe gleich einen Rundumschlag gemacht), kann der Server wieder normal gestartet werden. Dazu wird der Dienst gestoppt und anschließend OHNE Parameter neu gestartet.
Herzlichen Dank fürs Lesen!
