Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server
Beschreibt, wie FileTables mit anderen Funktionen von SQL Server funktionieren.
Always On-Verfügbarkeitsgruppen und FileTables
Wenn die Datenbank, die FILESTREAM- oder FileTable-Daten enthält, zu einer Always On-Verfügbarkeitsgruppe gehört:
Die FileTable-Funktionalität wird von Always On-Verfügbarkeitsgruppen teilweise unterstützt. Nach einem Failover kann auf dem primären Replikat auf FileTable-Daten zugegriffen werden, nicht jedoch auf FileTable-Daten auf lesbaren sekundären Replikaten.
Hinweis
Beachten Sie, dass alle FILESTREAM-Funktionen nach einem Failover unterstützt werden. Sowohl auf lesbaren sekundären Replikaten als auch auf dem neuen primären Replikat kann auf FILESTREAM-Daten zugegriffen werden.
Die FILESTREAM-Funktion und die FileTable-Funktion akzeptieren oder geben virtuelle Netzwerknamen (VNNs) statt Computernamen zurück. Weitere Informationen zu diesen Funktionen finden Sie unter FILESTREAM- und FileTable-Funktionen (Transact-SQL).
Bei allen Zugriffen auf FILESTREAM- oder FileTable-Daten über Dateisystem-APIs sollten VNNs statt der Computernamen verwendet werden. Weitere Informationen finden Sie unter Verwenden von FILESTREAM und FileTable mit Always On-Verfügbarkeitsgruppen.
Partition und Dateitabellen
Die Partitionierung wird für FileTables nicht unterstützt. Mit der Unterstützung für mehrere FILESTREAM-Dateigruppen können in den meisten Szenarien reine Skalierungsprobleme behandelt werden, ohne dass hierfür auf die Partitionierung zurückgegriffen werden muss (im Gegensatz zu SQL 2008-FILESTREAMs).
Replikation und FileTables
Replikation und verwandte Funktionen (einschließlich Transaktionsreplikation, Mergereplikation, Änderungsdatenaufzeichnung und Änderungsnachverfolgung) werden in Dateitabellen nicht unterstützt.
Transaktionssemantik und Dateitabellen
Windows-Anwendungen
Windows-Anwendungen verstehen keine Datenbanktransaktionen, deshalb stellen Windows-Schreibvorgänge nicht die ACID-Eigenschaften einer Datenbanktransaktion bereit. Daher sind Transaktionsrollbacks und Wiederherstellung bei Windows-Updatevorgängen nicht möglich.
Transact-SQL-Anwendungen
Bei Transact-SQL-Anwendungen, die in der FILESTREAM-Spalte (file_stream) in einer Dateitabelle arbeiten, ist die Isolationssemantik die gleiche wie beim FILESTREAM-Datentyp in einer regulären Benutzertabelle.
Abfragebenachrichtigungen und FileTables
Die Abfrage kann keinen Verweis auf die FILESTREAM-Spalte in der Dateitabelle , in der WHERE-Klausel oder in einem anderen Teil der Abfrage enthalten.
SELECT INTO und FileTables
SELECT INTO-Anweisungen aus einer Dateitabelle geben die Dateitabelle-Semantik nicht an die erstellte Zieltabelle weiter (genau wie FILESTREAM-Spalten in einer regulären Tabelle). Alle Zieltabellenspalten verhalten sich genau wie normale Spalten. Sie weisen keine ihnen zugeordnete Dateitabelle -Semantik auf.
Trigger und FileTables
DDL-Trigger (Data Definition Language, Datendefinitionssprache)
Es gibt keine besonderen Überlegungen für DDL-Trigger mit FileTables. Normale DDL-Trigger werden sowohl bei Datenbankoperationen wie „Create“ und „Alter“ als auch bei CREATE/ALTER TABLE-Operationen für FileTables ausgelöst. Trigger können durch Aufrufen der EVENTDATA()-Funktion die tatsächlichen Ereignisdaten abrufen, einschließlich des DDL-Befehlstexts und sonstiger Informationen. Es gibt keine neuen Ereignisse oder Änderungen an dem vorhandenen Eventdata-Schema.
DML-Trigger (Data Manipulation Language, Datenbearbeitungssprache)
Diese Einschränkungen werden während des DDL-Vorgangs zum Erstellen von Triggern durchgesetzt.
FileTables unterstützen keine INSTEAD OF-Trigger für DML-Vorgänge. Dies ist eine bestehende Einschränkung für alle Tabellen, die FILESTREAM-Spalten enthalten.
Dateitabellen unterstützen AFTER-Trigger für DML-Vorgänge.
In einer Dateitabelle definierte Trigger können keine Dateitabellen (einschließlich der übergeordneten Dateitabellen) aktualisieren. Diese Einschränkung besteht in erster Linie, um zu verhindern, dass ein Trigger in Sperrkonflikte mit den durch den Dateisystemzugriff gehaltenen Sperren derselben Transaktion gerät.
Nicht transaktionaler Zugriff und Auswirkungen auf Trigger
Wenn der nicht transaktionale Updatezugriff in einer Datenbank zulässig ist, können direkte Updates der FILESTREAM-Daten in beliebigen Tabellen ausgeführt werden, u. a. auch für FileTable in dieser Datenbank. Aufgrund dieser Möglichkeit steht das Vorabbild des FILESTREAM-Inhalts dem Trigger möglicherweise nicht zur Verwendung zur Verfügung.
Für nicht transaktionale Updatevorgänge durch das Dateisystem erstellt SQL Server eine interne Transaktion, um den CloseHandle-Vorgang aufzuzeichnen, und alle definierten DML-Trigger werden möglicherweise als Teil dieser Transaktion ausgelöst. Ein Rollback auf eine Transaktion im Triggertext wird nicht verhindert, es erfolgt jedoch kein Rollback der am FILESTREAM vorgenommenen Änderungen. Ein solcher Rollback kann ebenfalls verhindern, dass die UPDATE-Trigger ausgelöst werden, selbst wenn der FILESTREAM-Inhalt geändert wurde.
Zusätzlich zu diesen Auswirkungen gelten für Trigger in FileTables zwei zusätzliche Verhalten:
Bei nichttransaktionalen Updatevorgängen auf FileTable über das Dateisystem ist es möglich, dass die FILESTREAM-Inhalte durch andere Win32-Vorgänge exklusiv gesperrt sind und über den Triggerkörper nicht zum Lesen/Schreiben darauf zugegriffen werden kann. In solchen Fällen kann jeder Versuch, innerhalb des Triggerkörpers auf die FILESTREAM-Inhalte zuzugreifen, den Fehler „Sharing Violation“ verursachen. Trigger müssen so konzipiert werden, dass solche Fehler entsprechend behandelt werden.
Das AFTER-Image des FILESTREAMs ist möglicherweise nicht stabil, da es in einigen Fällen gleichzeitig von anderen nicht-transaktionalen Aktualisierungen aktiv geschrieben wird (aufgrund der beim Dateisystemzugriff zulässigen Sharing-Modi).
Bei einer unerwarteten Beendigung von Win32-Handles, etwa durch ein explizites Beenden von Win32-Handles durch einen Administrator oder durch einen Datenbankabsturz, werden während der Wiederherstellungsvorgänge keine Benutzer-Trigger ausgeführt, obwohl der FILESTREAM-Inhalt möglicherweise durch die unerwartet beendete Win32-Anwendung geändert wurde.
Sichten und FileTables
Ansichten
Eine Ansicht kann für eine FileTable wie für jede andere Tabelle erstellt werden. Die folgenden Überlegungen gelten jedoch für eine in einer FileTable erstellten Sicht:
Die Anzeigen weisen keine FileTable-Semantik auf. Die Spalten in der Anzeige (einschließlich Dateiattributspalten) verhalten sich z. B. wie normale Anzeige-Spalten ohne besondere Semantik. Das gleiche gilt für Zeilen, die Dateien/Verzeichnisse darstellen.
Sichten können gemäß der Semantik aktualisierbarer Sichten änderbar sein, aber die Einschränkungen der zugrunde liegenden Tabelle können diese Änderungen genauso wie bei der Tabelle selbst ablehnen.
Der Dateipfad für eine Datei kann in der Sicht visuell dargestellt werden, indem er als explizite Spalte in der Sicht hinzugefügt wird. Zum Beispiel:
CREATE VIEW MP3FILES AS SELECT column1, column2, ..., GetFileNamespacePath() AS PATH, column3,... FROM Documents
Indizierte Ansichten
Indizierte Anzeigen können derzeit keine FILESTREAM-Spalten oder berechnete/persistente berechnete Spalten enthalten, die von den FILESTREAM-Spalten abhängig sind. Dieses Verhalten bleibt bei den in der FileTable definierten Ansichten ebenfalls unverändert.
Momentaufnahmeisolation und FileTables
Die Read Committed-Momentaufnahme (RCSI) und die Momentaufnahmeisolation (SI) basieren auf der Möglichkeit, eine Momentaufnahme der für Leser verfügbaren Daten zu erstellen, selbst wenn für die Daten Updatevorgänge ausgeführt werden. FileTables lassen jedoch nicht transaktionalen Schreibzugriff auf Filestream-Daten zu. Daher gelten die folgenden Einschränkungen für diese Funktionen in Datenbanken, die Dateitabellen enthalten:
Eine Datenbank, die FileTables enthält, kann so geändert werden, dass RCSI/SI aktiviert wird.
Wenn non_transactional access für die Datenbank auf FULL festgelegt ist, hat eine unter RCSI oder SI ausgeführte Transaktion das folgende Verhalten:
Alle Transact-SQL-Lesevorgänge der Spalte Dateitabelle file_stream schlagen fehl. INSERT und UPDATE zur Spalte funktionieren weiterhin, solange sie nicht aus der file_stream-Spalte lesen.
Wenn die Transact-SQL-Anweisung READCOMMITTEDLOCK-Tabellenhinweise angibt, sind Lesevorgänge erfolgreich, und anstelle der Zeilenversionsverwaltung werden Sperren für die Zeilen vorgenommen.
Transaktive Win32 FileStream-Öffnungsanforderungen sind ebenfalls fehlerhaft.
Nichttransaktionaler FileTable-Win32-Zugriff gelingt. Nicht alle internen von Dateitabellen ausgeführten Abfragen sind betroffen.
Die Volltextindizierung ist immer erfolgreich, unabhängig von den Datenbankoptionen (READ_COMMITTED_SNAPSHOT oder ALLOW_SNAPSHOT_ISOLATION).
Lesbare sekundäre Datenbanken
Die gleichen Überlegungen gelten sowohl für lesbare sekundäre Datenbank als auch für Momentaufnahmen. Selbiges ist im vorherigen Abschnitt Momentaufnahmeisolation und FileTablesbeschrieben.
Eigenständige Datenbanken und FileTables
Die FILESTREAM-Funktion, von der die FileTable-Funktion abhängt, erfordert einen gewissen Konfigurationsaufwand außerhalb der Datenbank. Daher ist eine Datenbank, die FILESTREAM oder FileTable verwendet, nicht vollständig enthalten.
Sie können die Datenbankeindämmung auf PARTIAL festlegen, wenn Sie bestimmte Funktionen eingedämmter Datenbanken verwenden möchten, z. B. eingedämmte Benutzer. In diesem Fall sind jedoch einige der Datenbankeinstellungen nicht in der Datenbank enthalten und werden nicht automatisch verschoben, wenn die Datenbank verschoben wird.