Im Rahmen der wiederkehrenden Diskussionen über „Wie setzt man einen SQL Server am besten auf?“ stolpere ich regelmäßig über die (vielleicht oft unterschätzte) Möglichkeit der „Instant File Initialization“. Mir war diese bis vor 1-2 Jahren gar nicht bekannt, aber mittlerweile gehört sie bei uns zum Standard, wie wir SQL Server installieren.

Mir ist hierzu noch ein Gespräch mit einem meiner DB2-Kollegen im Kopf, als dieser gerade eine DB2-Server-Migration plante bzw testete…
Er wollte eine neue Datenbank erstellen und musste warten bis die jeweiligen Datenfiles angelegt waren… das dauerte bei 100GB großen Datenfiles nun einmal entsprechend… (oder auch nicht 😉 )

MS SQL macht hier keine Unterschied zu IBM DB2, beide Datenbank-Systeme überschreiben den neu zu belegenden Plattenplatz der neuen Datendateien oder die Erweiterungen der Datendateien im Filesystem erstmal mit Nullen, um so sicherzustellen, dass alte Fragmente von bereits gelöschten Dateien tatsächlich überschrieben wurden.
Die Datenbereiche werden somit bereinigt, in diesem Fall initialisiert.

In Sachen SQL Server hatte ich mir hierzu bis zu dem Zeitpunkt keinerlei Gedanken gemacht, aber wie der Alttag es so möchte, kommt irgendwann immer „das erste Mal“.

Wir haben auf einem SQL-2012-Cluster eine Instanz für ein Online-CMS, dieses Online-CMS legt seine Datenbanken selber an, wenn die Redakteure ein neues „Projekt“ starten.
Ursprünglich (das Online-CMS läuft schon einige Jahre) gab es bisher nie Probleme mit dem Anlegen neuer Projekte, aber anscheinend in einer neuen Kombination aus SQL Version (Umzug aufs SQL-Cluster) und neuer CMS-Version kam es nun zu Problemen, die Redakteure beschwerten sich darüber, dass keine neuen Projekte angelegt werden könnten…

Die Überprüfungen ergaben dann auf Seiten des SQL-Servers nie eine Meldung im SQL-ErrorLog, keine Meldungen über SQL-Probleme in den Logfiles des Online-CMS, auch der Eventviewer half nicht bei der Suche. Die Anlage einer leeren Datenbank für eben dieses CMS über das SQL Management Studio zeigte auch keinerlei Abweichungen vom Standard-Verhalten, alles war wie erwartet. Die manuelle Anlage half aber nichts, weil das CMS damit nichts anfangen konnte (keine interne GUID, keine Tabellen und sonstige internen Anpassungen).
Eine Analyse mit dem Blitz-Skript von Brent Ozar ergab dann einen Hinweis auf eine verringerte Plattenperformance, diesem bin ich erstmal nachgegangen.
Die Storage-Kollegen waren behilflich und haben mir zusätzlich neue SSD-Platten angehängt bzw virtuelle Platten aus dem SSD-Plattenbereich der Storagebox zugewiesen, aber auch mit diesen schnelleren SSD-Platten war es nicht möglich ein neues Projekt anzulegen.
Mit dem Software-Herstellersupport wurde ebenfalls sämtliche Appliaktionsparameter durchgegangen, die irgendwie die Projektanlage beeinflussen könnten… insbesondere Timeouts für die Funktionen der Projekterstellung und die Parameter der Datenbankanbindung.
Dann habe ich mich weiter und intensiver mit dem Thema auseinander gesetzt und bin auf die Möglichkeit(en) der Instant File Initialization gekommen. Meine ersten manuellen Test auf dem Test-Cluster bestätigten meine Vermutungen und ließen mich hoffen, die manuelle Neuanlage von Datenbanken mit unterschiedlichen Datenbank-Größen zwischen 256MB und 5GB geschah um Vergleich zu vorher gerade zu gigantisch schnell.

Also einen neuen Termin mit dem Projektteam, den Redakteuren vereinbart. Den Parameter bzw die Berechtigung entsprechend gesetzt, die SQL Server Ressource auf dem SQL Cluster durchgestartet und die Redakteure gebeten erneut die Anlage eines Projektes zu versuchen. Und siehe da, das Projekt ließ sich tatsächlich anlegen. Die Datenbank samt aller Strukturen wurde angelegt und war im Online-CMS als neues Projekt verfügbar.

Zahlen, die genau meine Vermutungen und Versuche bestätigen, fand ich in einem Blogbeitrag von Uwe Ricken, der sich ebenfalls intensiver mit dem Thema zu Instant File Initialization auseinander gesetzt hatte.

Auf den MSDN-Seiten und im Blog von Uwe Ricken fand ich dann auch Einschränkungen und weitergehende Erläuterungen dazu.

Dadurch dass man den Service-User des SQL Server Dienstes das lokale Recht „Perform volume maintenance tasks“ aktiviert man die „Instant File Initialization“, dies muss im Cluster auf jedem einzelnen Knoten durchgeführt werden.

Durch das Aktivieren (Berechtigung dem SQL Service User erteilen) der Instant File Initialization wird verhindert, dass der SQL Server erst einmal den zu allokorierenden Datenbereich mit Nullen voll schreiben muss, denn es nur ein HighwaterMark gesetzt.
Für das Setzen der HighwaterMark (SetFileValidData) wird das Recht SE_MANAGE_VOLUME_NAME benötigt, daher muss der SQL Service User dieses Recht erhalten, der SQL Server zum Abschluss einmal durchgestartet werden.

Das Füllen der zu allokierenden Datenbereiche mit Nullen im Rahmen der Instant File Initialization bedeutet, dass jedes Byte des neuen zugewiesenen Platzes mit Nullwerten (0x0) überschrieben wird. Dieses Verhalten verhindert so Probleme mit alten Daten, die zuvor in den gleichen physikalischen NTFS Clustern gespeichert wurde. Das Füllen der Daten geschieht somit aus Gründen der Sicherheit, Stabilität und Kontinuität.

Leider ist diese „Beschleunigung“ nur bei den folgenden Datenbank-Operationen zulässig und nutzbar:

• Anlegen einer Datenbank (Create Database)
• Autogrowth einer Datendatei einer Datenbank
• Restore eines Datenbank Backups
• die Datenbank darf nicht mittels TDE verschlüsselt sein

Wie Sie selber sehen können, nützt die Funktion bei TransaktionsLogs leider nichts, denn TransaktionsLogs müssen immer erst mit Nullen vollgeschrieben werden. Ohne die Null-Initialisierung der Transaktions-Logdatei, würde der Crash-Recovery-Prozess keine Ahnung haben, wo er zu stoppen, wenn die Protokolldatei abgearbeitet wurde. Der Crash Recovery Prozess stoppt, wenn er feststellt, dass Null-Werte in der Kopfzeile des nächsten Protokollsatz verarbeitet werden.

Desweiteren benötigt man (oder der SQL Server) im Rahmen eines Restores keine leeren Datenbereiche, da diese ja schon so groß dimensioniert, dass sie nur so groß sind, wie tatsächlich auch Daten in der Datenbank vorhanden sind. Daher benötigt der Restore kein vorheriges Befüllen/Überschreiben des Datenbereiches.

Überprüfen, ob Instant File Initialization aktiviert ist:

• Aktivieren des Trace Flags 3004 (DBCC TRACEON(3004,-1);)
• Aktivieren des Trace Flags 3605 (DBCC TRACEON(3605,-1);)
• Anlegen einer Testdatenbank und dann
• im SQL Server Error Log nachschauen.

Björn Peters

Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.