Datenbank Blog » SQL, T-SQL und PL/SQL

Offene Verbindungen zu einer SQL Server-Datenbank schließen

Offene Verbindungen zu einer SQL Server-Datenbank schließen | Datenbank Blog

Ab und an steht man vor der Herausforderung eine Datenbank in einem SQL Server wiederherzustellen oder zurückzusetzen. Dann steht man oft vor dem Problem, dass noch offene Verbindungen zur Datenbank bestehen, die diese Aufgabe verhindern. Wir zeigen, wie man die offenen Verbindungen erkennen und schließen bzw. trennen kann.

SQL Verbindungen mit dem SQL Server Management Studio (SSMS) schließen

Mit Hilfe des SQL Server Management Studios kann man über das Kontextmenü alle Verindungen zur Datenbank schließen, in dem man die Datenbank „offline“ schaltet:

So bald die Datenbank „offline“ ist, kann sie auch nicht mehr angesprochen werden. Das kann zum Nachteil werden, wenn man danach sofort mit einigen Wartungsarbeiten beginnen möchte.

SQL Verbindungen zu einer Datenbank mit einer T-SQL Stored Procedure trennen

Ein weiterer Weg alle Verbindungen zu einer Datenbank zu trennen, ist mit dem Einsatz einer Stored Procedure möglich, die (ganz wichtig) nicht auf einem Cursor basiert:

Warum sollte man SQL Cursor nicht einsetzen? Don’t use SQL Server Cursor!

Während unseren Recherchen haben wir viele Artikel mit dem Thema „Trennung von Verbindungen zu einer Datenbank“ gesehen, wo ein SQL Cursor eingesetzt wird. Microsoft selbst empfiehlt Cursor nicht einzusetzen, da bessere Alternativen existieren, siehe Artikel: Increase your SQL Server performance by replacing cursors with set operations.

Des Weiteren sind Cursors oft das falsche Werkzeug für die falsche Aufgabe. Sie werden für die schnelle und schmutzige Programmierung verwendet, wenn ein Datenbankentwickler kein gutes Verständnis für Mengenoperationen hat.

Zum Beispiel ist eine Datenbankoperation manchmal am besten auf der Client-Seite und nicht auf der Server-Seite durchzuführen. Serverseitige Cursor wurden in ADO unterstützt, die eine schreibgeschützte Ansicht der verwendeten Daten erforderten.

ADO.NET verwendet den Datenleser oder Datenadapter, der die getrennte Clientseite betreibt. Der Datenadapter greift auf die Datenbank zu und bringt die Daten unmittelbar auf die Client-Seite, trennt sofort die Verbindung zum Server, das wiederum zu einer besseren Leistung und Skalierbarkeit führt.

Auf diese Weise kann der Client durch die auf der Webseite oder dem Webserver eingestellten Ergebnisse blättern, anstatt die auf dem SQL Server eingestellten Ergebnisse zu durchsuchen und so Ressourcen zu verbrauchen.

Bevor man einen Cursor einsetzt, sollten man festlegen, wie die Daten zukünftig verwendet werden. Auch sogenannte SQL-Batches lassen sich heutzutage besser mit einer WHILE-Schleife als mit einem SQL-Cursor realisieren.

Über den Autor

Markus

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.