Technischer Blog

Die Anzahl der Verbindungen die eine SQL Server Instanz verwalten kann ist abhängig von der Konfiguration der Instanz. In jedem Falle gibt es eine endliche Obergrenze und eine Erschöpfung der möglichen Verbindungen aus dem Verbindungspool wird eintreten was zu Performanceproblemen oder sogar Verbindungsverweigerungen führen kann. Häufig ist die Ursache ein fehlerhaftes Verbindungsmanagement. Eine Verbindung zum SQL Server wird geöffnet und nicht mehr geschlossen. Im Idealfall wird dieselbe Verbindung immer wieder verwendet und am Ende einer "Session" als "kann geschlossen werden" markiert (Wenn man z.b. das managen der Connections dem .NET Framework überlässt). Weitere Ursachen können Transaktionen darstellen, die nicht explizit abgeschlossen werden mittels eines "Commit" oder "Rollbacks" oder etwa das im Falle einer Ausnahme (Exception) die Verbindung offen bleibt und verwaist. Hier fallen ebenso asynchrone Operationen mit rein. Oder aber ein Entwickler "debugged" mittels Breakpoints und beendet das ganze, wobei die Connection weiterhin bestehen bleibt.

Ein Fix resultiert entweder durch das explizite Abschiessen / Kill der Verbindungen oder durch einen Service-Restart. Eine Konfiguration von Connection-Timeouts schafft hier keine Abhilfe. Selbst wenn der Server und das involvierte System robust arbeiten, können Netzwerk- und Treiberprobleme zu o.b. Szenario führen. Ein Monitoring bzw. eine Überwachung dieser Metriken ist damit vor allem bei produktiven Systemen unerlässlich und ein Grund um Entwicklungssysteme und Test- und vor allem produktive Systeme voneinander zu trennen. Für eine effektive Prävention von Connection Leaks sind korrektes Verbindungsmanagement, Monitoring und die Verwendung von Pooling-Einstellungen entscheidend. Timeout-Werte können dabei ergänzend genutzt werden, um ineffiziente Verbindungen zu identifizieren oder Abbrüche zu forcieren. Auf Entwicklerseite rate ich zur Implementation eines robusten Datenbankverbindungsmanagement, wie zum Beispiel über ein Singleton-Pattern. Vor allem wenn die Software exzessiv Datenbankoperationen auslöst, wird der geringe Mehraufwand potentielle Probleme erheblich reduzieren und vorbeugen. Ein Script zum aufspüren von Connection-Leaks ist hier zu finden (Externer Link)