Echt jetzt ??? Datenbank mit aktiviertem Auto_Close ???

Ich bin hvor kurzem erneut über eine Konfiguration auf einer Datenbank bzw auf einem SQL Server gestolpert, bei der ich immer wieder frage: „Wie kommt man im Jahr 2020/21 auf die Idee an einer Datenbank den Parameter „Auto_Close“ auf True zu setzen?“ Selbst wenn man diesen Wert seit Jahren und etlichen Versionen „mit sich herumschleppt“, so muss das doch irgendwann mal auffallen… In der Vorbereitung auf diesen Blog-Post habe ich zahlreiche Artikel gefunden, die schon mindestens 10 Jahre alt sind (zum Beispiel) und davon abraten, diesen Konfigurationsparameter auf „true“ zu setzen. Aber einmal der Reihe nach, was macht dieser Parameter, was bewirkt er und warum waren manche Dienstleister der Meinung, dass das Aktivieren von AutoClose eine gute Idee sei.

Was ist dieses AutoClose

Gemäß Microsoft Dokumentation

-- Aktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE ON WITH NO_WAIT
GO

-- Deaktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE OFF WITH NO_WAIT
GO

Heißt also, dass alle Datenbanken die irgendwann mal vor „Jahrzehnten“ auf einem SQL Server Express oder einer Desktop Engine erstellt wurden, diesen Parameter (im worst-case seit 20 Jahren) bei jeder Migration mit sich mitnehmen… Warum schaut hier denn kein Admin hin und setzt diesen Wert wieder auf das Optimum „false“ )? Natürlich muss ich zumindest daraufhin weisen, dass es unter ganz bestimmten Anwendungsfällen auch sinnvoll sein kann, diesen Parameter zu aktivieren! (dazu später mehr)

Also um das noch einmal im Detail zu erläutern, was AutoClose bewirkt… Die Datenbank schläft eigentlich immer, da Auto_Close aktiviert wurde, dann kommt der User und möchte Daten aus der Datenbank abfragen… dann muss der SQL Server diese Datendateien erst öffnen, einen DBCC CheckDB laufen lassen… die Folge davon ist natürlich ein gewisser Zeitverlust je nach Größe der Datenbank, der allgemeinen Leistung des System und der aktuellen Last auf dem System.

Ich kann mir gut vorstellen, warum man früher der Meinung war, dass die Nutzung dieser Option eine gute Idee war… früher – also rund um den SQL Server 2000 bzw 2005 – gab es noch nicht so performante Systeme und Ressourcen waren teurer, daher hat man sich somit erhofft System-Ressourcen zu sparen und für andere Datenbanken und Applikationen nutzen zu können. Ebenso habe ich gelesen, dass es damals was damit zu tun gehabt haben soll, dass der SQL Server auch auf FAT32-Filesystemen lauffähig (Windows 98) war und es hier Befürchtungen gab, dass Datenbanken „zerstört“ werden könnten weil sie eben nicht richtig geschlossen (im Filesystem) wurden.*¹ Und natürlich wie in der Microsoft Dokumentation benannt, war das natürlich bei allen „freien“ Versionen der Fall, da hier nur eine CPU genutzt werden konnte, hier dann einer Ressourcen-Knappheit vorgebeugt werden sollte.

Worst-case: Performance-Impact

Der worst-case ist natürlich, dass die Aktivierung – ob gewollt, ungewollt oder eben per Default – zu Performancebeinträchtigung des SQL Servers und der nutzenden Applikationen kommt. Durch das ständige Öffnen und Schliessen der Datenbanken und das damit verbundene Überprüfen der Datenbank-Konsistenz. Wie bereits angedeutet, kann es Sinn machen, diese Funktion zu aktivieren, denn es gibt immer Ausnahmen… zum Beispiel könnte ich mir Entwickler-Server vorstellen, bei denen jeder Entwickler seine eigene Datenbank hat und ggfs nicht alle gleichzeitig arbeiten/entwickeln, dann könnte es unter Umständen Sinn machen, diesen Konfigurationspunkt zu verändern. Oder – und hier kommt wieder der Blogbeitrag von Greg*¹ zum Tragen – wenn man einen SQL Server mit vielen Datenbanken hat, die aber nicht alle gleichzeitig genutzt werden (zum Beispiel ein weltweit agierender Händler mit sehr vielen Standorten und jeder Standort eine eigene Datenbank hat). Aber wie immer gilt dann, dass man das testen muss, was ggfs sinnvoller ist, dauernd die Datenbank zu schliessen oder eben offen zu lassen.

Ich hatte zum Beispiel in der letzten Woche einen Kunden mit einem langsamen SQL Server, als ich dort ins Log schaute, waren 90% der Einträge genau die Meldungen „Starting database“ und „Shutting down database“ (das war nicht das einzige Problem hier), aber eben genau diese Kunden-Situation hat mich dazu bewogen, diesen Beitrag zu schreiben.

Wer jetzt – bei nächster Gelegenheit seine SQL Server überprüfen möchte, dem möchte ich den Blogpost aus dem Jahr 2013 von Rob Sewell ans Herz legen, wo er mit Powershell eine Liste von Servern überprüft und ggfs korrigiert. => SQL Express Migration Auto_Close Setting

*¹ – Thx an Greg Low

Björn Peters

Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.