Was ist Instant File Initialization?

Mit Instant File Initialization lässt sich der Prozess des Erstellens oder Vergrößerns von Dateien beschleunigen, indem das Überschreiben von neuem Speicher für die Datenbankdatei (Zeroing out) nicht durchgeführt wird. Microsoft SQL Server erstellt die Datei und alloziert ihn zwar; aber der langwierige Prozess des Überschreibens bleibt aus. Dieser Vorteil kann nur auf Datenbankdateien angewendet werden, Transaktionsprotokolle können diesen Vorteil nicht nutzen. Dass Transaktionsprotokoll-Dateien diesen Vorteil nicht nutzen können, hängt damit zusammen, dass das Transaktionsprotokoll ein rotierendes Verfahren verwendet, um freie / ungenutzte VLF (Virtual Log File) wieder zu verwenden.

Vorteil von Instant File Initialization

Durch das Verhindern von “Zeroing Out” steht eine Datenbank schneller (wieder) zur Verfügung. Instant File Initialization kann bei den folgenden Prozessen einen erheblichen Geschwindigkeitsvorteil bringen:

• CREATE DATABASE
• ALTER DATABASE … MODIFY FILE
• RESTORE DATABASE
• AUTOGROWTH für Datenbanken

Alle vier genannten Prozesse haben eines gemeinsam; sie erstellen oder ändern Datenbankdateien, die von Microsoft SQL Server verwaltet werden.

Nachteil von Instant File Initialization

Da Instant File Initialization vorhandenen und allozierten Speicher nicht überschreibt, besteht die Gefahr, dass mit geeigneter Software Daten, die vorher von der Festplatte gelöscht wurden, ausgelesen werden können. Es muss vor der Aktivierung eine Sicherheitsbewertung erfolgen; wird der Speicher auch für “normale” Filesystem-Aktivitäten verwendet oder werden Datenbanken häufig gelöscht, sollte auf Instant File Initialization eventuell verzichtet werden.

Wie kann man erkennen, ob Microsoft SQL Server “Instant File Initialization” verwendet?

Instant File Initialization kann man NICHT in Microsoft SQL Server konfigurieren, da es sich dabei nicht um eine Funktionalität von Microsoft SQL Server handelt, sondern ein Sicherheitsprivileg, dass dem Dienstkonto der ausgeführten Instanz von Microsoft SQL Server zugewiesen werden kann.

Um festzustellen, ob Instant File Initialization aktiviert ist, gibt es zwei Möglichkeiten:

• Außerhalb von Microsoft SQL Server: Überprüfung der lokalen Sicherheitsrichtlinie
• In Microsoft SQL Server: Anlegen einer neuen Datenbank bei gleichzeitiger Protokollierung in das Fehlerprotokoll

Lokale Sicherheitsrichtlinie

Instant File Initialization ist ein Sicherheitsprivileg, dass standardmäßig nur Administratoren zugewiesen ist. Die lokalen Sicherheitsrichtlinien wird durch den Start von [secpol.msc] ausgeführt.

In einem englischsprachigen System heißt die oben gezeigte Richtlinie “Perform Volume Maintenance Tasks” und findet sich in [User Rights Assignment]. Ist das Dienstkonto von Microsoft SQL Server dieser Sicherheitsrichtlinie zugeordnet, ist Instant File Initialization für Microsoft SQL Server aktiviert.

Prüfung aus Microsoft SQL Server

In einem Umfeld, in dem ein DBA keinen unmittelbaren Zugang zum Betriebssystem besitzt (Segregation of Duty), gibt es ebenfalls eine Möglichkeit, zu testen, ob das Dienstkonto von Microsoft SQL Server das Privileg besitzt. Das nachfolgende Script startet die Protokollierung und legt eine neu Datenbank mit einer Initialgröße von 1.500 MB (1 GB für Daten und 500 MB für das Protokoll) an.

-- Aktivierung der Protokollierung

DBCC TRACEON (3004, 3605, -1);

-- Erstellung einer neuen Database mit einer initialen Größe

-- von 1 GB für Daten und 500 MB für das Log

CREATE DATABASE Test

ON PRIMARY

(

    NAME = 'Test',

    FILENAME = 'S:\BACKUP\Test.mdf',

    SIZE = 1000MB,

    MAXSIZE = 10000MB,

    FILEGROWTH = 0MB

)

LOG ON

(

    NAME = 'Test_Log',

    FILENAME = 'S:\BACKUP\Test.ldf',

    SIZE = 500MB,

    MAXSIZE = 500MB,

    FILEGROWTH = 0MB

);

GO

-- Auslesen des Fehlerprotokolls von Microsoft SQL Server

EXEC xp_readerrorlog;

Nachdem die neue Datenbank angelegt wurde, wird das Fehlerprotokoll ausgelesen, dessen Inhalt in der nachfolgenden Abbildung gezeigt wird.

Die Zeilen 12 – 18 zeigen, dass “Instant File Initialization” für das Dienstkonto NT Service\MSSQL$SQL_2012 nicht zur Verfügung steht; die Datendatei wurde mittels “Zeroing” mit 0 gefüllt. Für das Anlegen einer Datenbankdatei für die TEST-Datenbank benötigte das System 17 Sekunden (Zeile 12 - 13). Für das Anlegen der Protokolldatei wurden 9 Sekunden benötigt. Insgesamt werden für das Erstellen der Datenbank [Test] 26 Sekunden benötigt. Das Protokoll für das Erstellen der Datenbank bei Zuweisung des Rechts für das Dienstkonto sieht wie folgt aus:

Deutlich ist zu erkennen, dass – wie bereits oben ausgeführt – ausschließlich die Protokolldatei den Prozess des “Zeroing” über sich ergehen lassen muss. Da die Datenbankdatei unmittelbar erstellt wurde, ist die Datenbank innerhalb von 9 Sekunden betriebsbereit.

Instant File Initialization bei neuen Datenbanken

Wie die Tests demonstrieren, liegt der Vorteil bei der Anlage von neuen Datenbanken in der Bereitstellung der Datenbank innerhalb weniger Sekunden. In der Regel ist das Erstellen von neuen Datenbanken – sofern es nicht aus Applikation selbst geschieht – kein zeitkritischer Vorgang.

Instant File Initialization bei Wiederherstellung von Datensicherungen

Die Wiederherstellung einer Datenbank kann ein zeitkritisches Problem werden, wenn zum Beispiel die Produktionsdatenbank betroffen ist. Exakt dieser Umstand wurde einem Kunden zum Opfer, der eine Datenbank mit einer Dateigröße für die Daten von 750 GB wiederherstellen musste. Tragisch an dieser Situation war, dass die Datenbank selbst nur zu ca. 50% mit Daten gefüllt war. Die Wiederherstellung verzögert sich um die Zeit, die für das “Zeroing” benötigt wird. Dieser Vorgang kann jedoch eingespart werden, da die Daten unmittelbar nach der Initialisierung in die neu angelegten Datenbank-Dateien geschrieben werden.

Instant File Initialization beim Vergrößern von Datenbanken

In vielen Microsoft SQL Server Installationen ist auffällig, dass die Vergrößerung einer Datenbank entweder sehr klein gewählt wurde (1 MB) oder aber – für den angegebenen Workload – zu groß. Entscheidend für beide Szenarien ist, dass bei fehlendem Recht für “Instant File Initialization” die Anwendungen unverhältnismäßig lange warten müssen, bis das “Zeroing” abgeschlossen ist. Ist ein hoher Workload in der Applikation erkennbar, wird bei einem Vergrößerungsintervall von 1 MB zu oft die Datenbank erweitert und ein “Zeroing” initiiert. Bei einer Größe von 500 MB müsste die Applikation ca. 9 Sekunden warten, bis der Prozess abgeschlossen ist. Für eine Anwendung, die fast ausschließlich auf hohe OLTP-Vorgänge beschränkt ist, ein absolutes K.O-Kriterium.

Testmessungen

Um ein Gefühl für die Zeitunterschiede zu vermitteln, wurde eine Testdatenbank mit verschiedenen Größen und auf verschiedenen Medien erstellt. Für die Messungen wird die Testdatenbank in vier unterschiedlichen Größen (100 MB, 500 MB, 1.000 MB, 2.000 MB) mit identischer Größe für die Protokolldatei (100 MB) sowohl auf einer HDD als auch einer SDD erstellt. Eine Messung erfolgt mit jeweils aktivierter (IFI) und deaktivierter (No IFI) Berechtigung. Für die Messungen wurden als HDD eine [Toshiba MK5061GSY] mit einer Blockgröße von 64 KBytes verwendet. Für die Tests auf der SSD wurde eine [CRUCIAL CT960M500] verwendet, die ebenfalls eine Blockgröße von 64 KBytes verwendet.

Klar erkennbar ist, dass – unabhängig von HDD und/oder SDD die Erstellungszeiten fast proportional wachsen, wenn “Instant File Initialization” nicht möglich ist. Bei Aktivierung sind die Zeiten nahezu identisch, da die Größe der Protokolldatei in allen Tests identisch ist. Die Variationen rühren wohl eher aus Streuungen!

Bei einer 500 GB großen Datenbank würde die Erstellung auf einer HDD bei deaktiviertem “Instant File Initialization” nahezu 3 Stunden benötigen! Selbst auf einer SSD müssen immer noch ca. 35 Minuten vergehen, bevor die Datenbank online ist. Da in der Regel neue Datenbanken eher in kleineren Dimensionen erstellt werden, sind diese Zeiten wohl eher zu vernachlässigen. Jedoch sieht es bei der Wiederherstellung von Datenbanken ganz anders aus. Müssen erst die erstellten Datenbankdateien mittels “Zeroing out” überschrieben werden, kann so eine nicht unerhebliche Zeit für die Wiederherstellung vergehen. Ein Umstand, der in einer Produktionsumgebung bei entsprechendem SLA schnell zu Problemen führen kann.

Zeitweise Deaktivierung von Instant File Initialization

Die durchgeführten Tests kann man auf dem eigenen Datenbanksystem selbst durchspielen, ohne die Berechtigung immer wieder zu ändern (und damit einen Neustart des Dienstes durchzuführen). Sollte auf den eigenen Systemen Instant File Initialization aktiviert sein, so kann man diese Option zeitweilig mit dem Traceflag 1806 zwischenzeitlich deaktivieren.

Der Vorteil dieses Traceflags besteht vor allen darin, dass Datenbanken, die einer höhere Sicherheitsstufe unterliegen, bei der Erstellung  einem “Zeroing out” unterzogen werden.

Einschränkungen von Instant File Initialization

Instant File Initialization unterliegt besonderen Einschränkungen, die im Vorfeld geprüft werden müssen. So ist Instant File Initialization nur möglich, wenn die nachfolgenden Voraussetzungen erfüllt sind:

• Es handelt sich nicht um eine Protokolldatei (*.ldf)
• Das Betriebssystem unterstützt den Aufruf von SetFileValidData
  http://msdn.microsoft.com/en-us/library/aa365544%28VS.85%29.aspx
• Es handelt sich nicht um einen Snapshot
• Die Datenbank darf nicht verschlüsselt sein (TDE)
• Traceflag 1806 ist nicht aktiviert

Zusammenfassung

Instant File Initialization gibt dem DBA die Möglichkeit, Datenbankoperationen, die einen unmittelbaren Einfluss auf die Eigenschaften der Datenbankdateien besitzen, durch “Instant File Initialization” zu beschleunigen. Bevor man Instant File Initialization aktiviert, sollte das betriebliche Umfeld sehr genau geprüft werden. Insbesondere ein Blick auf das Dateisystem in Verbindung mit der Sensibilität der Daten ist ein wichtiges Kriterium für die Aktivierung / Deaktivierung. In größeren Unternehmen gibt es eine klare Trennung von Aufgaben (Segregation of Duty). Ein Gespräch mit dem verantwortlichen Administrator für das Betriebssystem schafft schnell Klarheit.

Insgesamt kommt die Bedeutung von Instant File Initialization nicht bei der Erstellung von “neuen” Datenbanken zum tragen. Vielmehr ist bei zeitkritischen Wiederherstellungsszenarien diese Option von größerer Bedeutung. Auch bei Applikationen, die sehr viele Daten schreiben und somit die Datenbank regelmäßig vergrößern müssen, ist Instant File Initialization ein Gewinn für die Geschwindigkeit und Stabilität der Applikation.

Sollten die Richtlinien des Unternehmens Instant File Initialization verhindern, so wäre aus meiner Sicht das Recht zu erteilen und der SQL Server Dienst mit dem Traceflag 1806 zu starten. Somit wäre Instant File Initialization grundsätzlich nicht möglich – es wäre aber für einen Administrator im Falle einer Wiederherstellung einer großen Datenbank aus einem Backup möglich, für diese Operation Instant File Initialization zeitweise zu aktivieren.

Herzlichen Dank fürs Lesen!

Seiten: 1· 2