FILESTREAM (SQL Server)

FILESTREAM ermöglicht SQL Server-basierten Anwendungen das Speichern unstrukturierter Daten, z. B. Dokumente und Bilder, im Dateisystem. Anwendungen können die umfangreichen Streaming-APIs und die Leistung des Dateisystems nutzen und gleichzeitig die Transaktionskonsistenz zwischen den unstrukturierten Daten und den entsprechenden strukturierten Daten beibehalten.

FILESTREAM integriert das SQL Server-Datenbankmodul in ein NTFS-Dateisystem, indem binäre BLOB-Daten (Binary Large Object) als Dateien im Dateisystem gespeichert varbinary(max) werden. Mit Transact-SQL-Anweisungen können FILESTREAM-Daten eingefügt, aktualisiert, abgefragt, gesucht und gesichert werden. Win32-Dateisystemschnittstellen bieten Streamingzugriff auf die Daten.

FILESTREAM verwendet den NT-Systemcache zum Zwischenspeichern von Dateidaten. Dadurch wird jeder Effekt reduziert, den FILESTREAM-Daten möglicherweise auf die Leistung des Datenbankmoduls haben. Der SQL Server-Pufferpool wird nicht verwendet; Daher steht dieser Speicher für die Abfrageverarbeitung zur Verfügung.

FILESTREAM ist nicht automatisch aktiviert, wenn Sie SQL Server installieren oder aktualisieren. Sie müssen FILESTREAM mithilfe von SQL Server Configuration Manager und SQL Server Management Studio aktivieren. Um FILESTREAM zu verwenden, müssen Sie eine Datenbank erstellen oder ändern, um einen speziellen Dateigruppentyp zu enthalten. Erstellen oder ändern Sie dann eine Tabelle, sodass sie eine varbinary(max) Spalte mit dem FILESTREAM-Attribut enthält. Nachdem Sie diese Aufgaben abgeschlossen haben, können Sie Transact-SQL und Win32 verwenden, um die FILESTREAM-Daten zu verwalten.

Weitere Informationen zum Installieren und Verwenden von FILESTREAM finden Sie in der Liste verwandter Aufgaben.

Wann sollte man FILESTREAM verwenden

In SQL Server können BLOBs Standarddaten varbinary(max) sein, die die Daten in Tabellen speichern, oder FILESTREAM-Objekte varbinary(max) , die die Daten im Dateisystem speichern. Die Größe und Verwendung der Daten bestimmt, ob Sie Datenbankspeicher oder Dateisystemspeicher verwenden sollten. Wenn die folgenden Bedingungen zutreffen, sollten Sie FILESTREAM verwenden:

Objekte, die gespeichert werden, sind im Durchschnitt größer als 1 MB.
Der schnelle Lesezugriff ist wichtig.
Sie entwickeln Anwendungen, die eine mittlere Ebene für Anwendungslogik verwenden.

Bei kleineren Objekten bietet das Speichern von varbinary(max) BLOBs in der Datenbank häufig eine bessere Streamingleistung.

FILESTREAM-Speicher

FILESTREAM-Speicher wird als varbinary(max) Spalte implementiert, in der die Daten als BLOBs im Dateisystem gespeichert werden. Die Größen der BLOBs sind nur durch die Volumengröße des Dateisystems begrenzt. Die Standardbeschränkung varbinary(max) von 2 GB Dateigrößen gilt nicht für BLOBs, die im Dateisystem gespeichert sind.

Um anzugeben, dass eine Spalte Daten im Dateisystem speichern soll, geben Sie das FILESTREAM-Attribut für eine varbinary(max) Spalte an. Dadurch speichert das Datenbankmodul alle Daten für diese Spalte im Dateisystem, aber nicht in der Datenbankdatei.

FILESTREAM-Daten müssen in FILESTREAM-Dateigruppen gespeichert werden. Eine FILESTREAM-Dateigruppe ist eine spezielle Dateigruppe, die Dateisystemverzeichnisse anstelle der Dateien selbst enthält. Diese Dateisystemverzeichnisse werden als Datencontainer bezeichnet. Datencontainer sind die Schnittstelle zwischen Datenbankmodulspeicher und Dateisystemspeicher.

Berücksichtigen Sie beim Verwenden des FILESTREAM-Speichers Folgendes:

Wenn eine Tabelle eine FILESTREAM-Spalte enthält, muss jede Zeile eine nicht null eindeutige Zeilen-ID aufweisen.
Mehrere Datencontainer können einer FILESTREAM-Dateigruppe hinzugefügt werden.
FILESTREAM-Datencontainer können nicht geschachtelt werden.
Wenn Sie Failoverclustering verwenden, müssen sich die FILESTREAM-Dateigruppen auf freigegebenen Datenträgerressourcen befinden.
FILESTREAM-Dateigruppen können auf komprimierten Volumes verwendet werden.

Integriertes Management

Da FILESTREAM als varbinary(max) Spalte implementiert und direkt in das Datenbankmodul integriert ist, funktionieren die meisten SQL Server-Verwaltungstools und -funktionen ohne Änderung für FILESTREAM-Daten. Sie können beispielsweise alle Sicherungs- und Wiederherstellungsmodelle mit FILESTREAM-Daten verwenden, und die FILESTREAM-Daten werden mit den strukturierten Daten in der Datenbank gesichert. Wenn Sie FILESTREAM-Daten nicht mit relationalen Daten sichern möchten, können Sie eine partielle Sicherung verwenden, um FILESTREAM-Dateigruppen auszuschließen.

Integrierte Sicherheit

In SQL Server werden FILESTREAM-Daten genauso gesichert wie andere Daten: durch Erteilen von Berechtigungen auf Tabellen- oder Spaltenebene. Wenn ein Benutzer über die Berechtigung für die FILESTREAM-Spalte in einer Tabelle verfügt, kann der Benutzer die zugehörigen Dateien öffnen.

Hinweis

Die Verschlüsselung wird für FILESTREAM-Daten nicht unterstützt.

Nur das Konto, unter dem das SQL Server-Dienstkonto ausgeführt wird, erhält NTFS-Berechtigungen für den FILESTREAM-Container. Es wird empfohlen, keine anderen Konten Berechtigungen für den Datencontainer zu erteilen.

Hinweis

SQL-Anmeldungen funktionieren nicht mit FILESTREAM-Containern. Nur die NTFS-Authentifizierung funktioniert mit FILESTREAM-Containern.

Zugriff auf BLOB-Daten mit Transact-SQL und Streaming-Zugriff auf das Dateisystem

Nachdem Sie Daten in einer FILESTREAM-Spalte gespeichert haben, können Sie mithilfe Transact-SQL Transaktionen oder mithilfe von Win32-APIs auf die Dateien zugreifen.

Transact-SQL Zugriff

Mithilfe von Transact-SQL können Sie FILESTREAM-Daten einfügen, aktualisieren und löschen:

Sie können einen Einfügevorgang verwenden, um ein FILESTREAM-Feld mit einem NULL-Wert, einem leeren Wert oder relativ kurzen Inlinedaten vorzufüllen. Eine große Datenmenge wird jedoch effizienter in eine Datei gestreamt, die Win32-Schnittstellen verwendet.
Wenn Sie ein FILESTREAM-Feld aktualisieren, ändern Sie die zugrunde liegenden BLOB-Daten im Dateisystem. Wenn ein FILESTREAM-Feld auf NULL festgelegt wird, werden die dem Feld zugeordneten BLOB-Daten gelöscht. Sie können kein Transact-SQL Chunked Update verwenden, das als UPDATE**.**Write() implementiert wurde, um teilweise Aktualisierungen der Daten auszuführen.
Wenn Sie eine Zeile löschen oder eine Tabelle löschen oder abschneiden, die FILESTREAM-Daten enthält, löschen Sie die zugrunde liegenden BLOB-Daten im Dateisystem.

Dateisystem-Streamingzugriff

Die Win32-Streamingunterstützung funktioniert im Kontext einer SQL Server-Transaktion. Innerhalb einer Transaktion können Sie FILESTREAM-Funktionen verwenden, um einen logischen UNC-Dateisystempfad einer Datei abzurufen. Anschließend verwenden Sie die OpenSqlFilestream-API, um ein Dateihandle abzurufen. Dieses Handle kann dann von Win32-Dateistreamingschnittstellen wie ReadFile() und WriteFile() verwendet werden, um auf die Datei über das Dateisystem zuzugreifen und sie zu aktualisieren.

Da Dateivorgänge transaktional sind, können Sie FILESTREAM-Dateien nicht über das Dateisystem löschen oder umbenennen.

Erläuterungsmodell

Der FILESTREAM-Dateisystemzugriff modelliert eine Transact-SQL-Anweisung mithilfe von "Datei öffnen und schließen". Die Anweisung beginnt, wenn ein Dateihandle geöffnet wird und endet, wenn das Handle geschlossen wird. Wenn beispielsweise ein Schreibhandle geschlossen wird, wird jeder mögliche AFTER-Trigger, der in der Tabelle registriert ist, ausgelöst, als ob eine UPDATE-Anweisung abgeschlossen wäre.

Speicher-Namespace

In FILESTREAM steuert das Datenbankmodul den Namensraum des physischen BLOB-Dateisystems. Eine neue systeminterne Funktion, PathName, stellt den logischen UNC-Pfad des BLOB bereit, der jeder FILESTREAM-Zelle in der Tabelle entspricht. Die Anwendung verwendet diesen logischen Pfad, um das Win32-Handle abzurufen und mit den BLOB-Daten mithilfe regulärer Win32-Dateisystemschnittstellen zu arbeiten. Die Funktion gibt NULL zurück, wenn der Wert der FILESTREAM-Spalte NULL ist.

Transaktionaler Dateisystemzugriff

Eine neue systeminterne Funktion , GET_FILESTREAM_TRANSACTION_CONTEXT(), stellt das Token bereit, das die aktuelle Transaktion darstellt, der die Sitzung zugeordnet ist. Die Transaktion muss gestartet und noch nicht abgebrochen oder bestätigt worden sein. Durch das Abrufen eines Tokens bindet die Anwendung die FILESTREAM-Dateisystem-Streamvorgänge an eine begonnene Transaktion. Die Funktion gibt NULL zurück, wenn keine explizit gestartete Transaktion ausgeführt wird.

Alle Dateihandles müssen geschlossen werden, bevor die Transaktion bestätigt oder abbricht. Wenn ein Handle außerhalb des Transaktionsbereichs geöffnet bleibt, verursachen zusätzliche Lesevorgänge gegen das Handle einen Fehler. Zusätzliche Schreibvorgänge für das Handle werden erfolgreich ausgeführt, die tatsächlichen Daten werden jedoch nicht auf den Datenträger geschrieben. Ebenso werden alle geöffneten Handles ungültig, wenn die Datenbank oder Instanz des Datenbankmoduls heruntergefahren wird.

Transaktionslebensdauer

Bei FILESTREAM stellt das Datenbankmodul beim Transaktionscommit die Transaktionsbeständigkeit für FILESTREAM-BLOB-Daten sicher, die durch den Streamingzugriff des Dateisystems geändert werden.

Isolationsemantik

Die Isolationsemantik wird durch Transaktionsisolationsstufen des Datenbankmoduls gesteuert. Die Read-Committed-Isolationsstufe wird für Transact-SQL und den Zugriff auf das Dateisystem unterstützt. Wiederholbare Lesevorgänge sowie serialisierbare und Snapshotisolierungen werden unterstützt. Unsauberes Lesen wird nicht unterstützt.

Die Öffnungsoperationen des Dateisystemzugriffs warten nicht auf Sperrungen. Stattdessen schlagen die geöffneten Vorgänge sofort fehl, wenn sie aufgrund der Transaktionsisolation nicht auf die Daten zugreifen können. Die Streaming-API-Aufrufe schlagen mit ERROR_SHARING_VIOLATION fehl, wenn die Öffnungsoperation aufgrund eines Isolationsverstoßes nicht fortgesetzt werden kann.

Um teilweise Aktualisierungen durchzuführen, kann die Anwendung ein FS-Steuerelement für das Gerät (FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT) ausgeben, um den alten Inhalt in die Datei zu holen, auf die das geöffnete Handle verweist. Dadurch wird eine serverseitige alte Inhaltskopie ausgelöst. Um eine bessere Anwendungsleistung zu erzielen und potenzielle Timeouts zu vermeiden, wenn Sie mit sehr großen Dateien arbeiten, empfiehlt es sich, asynchrone E/A zu verwenden.

Wenn der FSCTL nach dem Schreiben des Handles ausgeführt wird, bleibt der letzte Schreibvorgang bestehen, und frühere Schreibvorgänge am Handle gehen verloren.

Dateisystem-APIs und unterstützte Isolationsstufen

Wenn eine Dateisystem-API aufgrund einer Isolationsverletzung keine Datei öffnen kann, wird eine ERROR_SHARING_VIOLATION Ausnahme zurückgegeben. Diese Isolationsverletzung tritt auf, wenn zwei Transaktionen versuchen, auf dieselbe Datei zuzugreifen. Das Ergebnis des Zugriffsvorgangs hängt vom Modus ab, in dem die Datei geöffnet wurde, und von der Version von SQL Server, auf der die Transaktion ausgeführt wird. In der folgenden Tabelle werden die möglichen Ergebnisse für zwei Transaktionen beschrieben, die auf dieselbe Datei zugreifen.

Transaktion 1	Transaktion 2	Ergebnis für SQL Server 2008	Ergebnis für SQL Server 2008 R2 und höhere Versionen
Zum Lesen öffnen.	Zum Lesen öffnen.	Beides ist erfolgreich.	Beides ist erfolgreich.
Zum Lesen öffnen.	Zum Schreiben geöffnet.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Lesevorgänge aus, die in Transaktion 1 ausgeführt werden.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Lesevorgänge aus, die in Transaktion 1 ausgeführt werden.
Zum Schreiben geöffnet.	Zum Lesen öffnen.	Öffnen für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION-Ausnahme fehl.	Beides ist erfolgreich.
Zum Schreiben geöffnet.	Zum Schreiben geöffnet.	Das Öffnen für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION Fehlermeldung fehl.	Das Öffnen von Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION-Ausnahme fehl.
Zum Lesen öffnen.	Zum Auswählen öffnen.	Beides ist erfolgreich.	Beides ist erfolgreich.
Zum Lesen öffnen.	Zum Aktualisieren oder Löschen öffnen.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Lesevorgänge aus, die in Transaktion 1 ausgeführt werden.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Lesevorgänge aus, die in Transaktion 1 ausgeführt werden.
Zum Schreiben geöffnet.	offen für SELECT.	Transaktion 2 bleibt blockiert, bis Transaktion 1 einen Commit ausführt oder die Transaktion beendet, oder die Wartezeit für die Transaktionssperre abläuft.	Beides ist erfolgreich.
Zum Schreiben geöffnet.	Zum Aktualisieren oder Löschen öffnen.	Transaktion 2 blockiert, bis Transaktion 1 committet oder die Transaktion beendet, oder die Transaktionssperre die Zeitvorgabe überschreitet.	Transaktion 2 blockiert, bis Transaktion 1 die Transaktion abschließt oder beendet, oder die Zeitüberschreitung der Transaktionssperre eintritt.
Für SELECT öffnen.	Zum Lesen öffnen.	Beides ist erfolgreich.	Beides ist erfolgreich.
Öffnen für SELECT	Zum Schreiben geöffnet.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Transaktion 1 aus.	Beides ist erfolgreich. Schreibvorgänge unter Transaktion 2 wirken sich nicht auf Transaktion 1 aus.
Zum Aktualisieren oder Löschen öffnen.	Zum Lesen öffnen.	Der Geöffnete Vorgang für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION Ausnahme fehl.	Beides ist erfolgreich.
Zum Aktualisieren oder Löschen öffnen.	Schreibzugriff möglich.	Der offene Vorgang für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION Exception fehl.	Der offene Vorgang für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION-Ausnahme fehl.
Für SELECT mit wiederholbarem Lesevorgang öffnen.	Zum Lesen öffnen.	Beides ist erfolgreich.	Beides ist erfolgreich.
Für SELECT mit wiederholbarem Lesevorgang öffnen.	Zum Schreiben geöffnet.	Der offene Vorgang bei Transaktion 2 schlägt mit einem ERROR_SHARING_VIOLATION-Fehler fehl.	Der Geöffnete Vorgang für Transaktion 2 schlägt mit einer ERROR_SHARING_VIOLATION Ausnahme fehl.

Write-Through von Remoteclients

Der Remotedateisystemzugriff auf FILESTREAM-Daten wird über das SMB-Protokoll (Server Message Block) aktiviert. Wenn der Client remote ist, werden keine Schreibvorgänge auf clientseitiger Seite zwischengespeichert. Die Schreibvorgänge werden immer an den Server gesendet. Die Daten können auf serverseitiger Seite zwischengespeichert werden. Es wird empfohlen, dass Anwendungen, die auf Remoteclients ausgeführt werden, kleine Schreibvorgänge konsolidieren, um weniger Schreibvorgänge mit größerer Datengröße zu erstellen.

Das Erstellen von zugeordneten Speicheransichten (zugeordneter Speicher-E/A) mithilfe eines FILESTREAM-Handles wird nicht unterstützt. Wenn die Speicherzuordnung für FILESTREAM-Daten verwendet wird, kann das Datenbankmodul keine Konsistenz und Haltbarkeit der Daten oder der Integrität der Datenbank garantieren.

Freigeben über