Teilen über

Dateitabellenkompatibilität mit anderen SQL Server-Features

  • Artikel

Gilt für: SQL Server

Beschreibt, wie FileTables mit anderen Funktionen von SQL Server funktionieren.

Always On-Verfügbarkeitsgruppen und Dateitabellen

Wenn die Datenbank, die FILESTREAM- oder FileTable-Daten enthält, zu einer Always On-Verfügbarkeitsgruppe gehört:

  • Die Funktion der Dateitabelle wird teilweise von Always On-Verfügbarkeitsgruppen 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 FILESTREAM und Dateitabelle bei Always On-Verfügbarkeitsgruppen.

Partition und Dateitabellen

Die Partition wird in Dateitabellen 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 Dateitabellen

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 für Datenbankoperationen Create/Alter sowie CREATE/ALTER TABLE-Operationen für Dateitabellen 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 zur Erstellung von Triggern erzwungen.

  • Dateitabellen 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 verhindert hauptsächlich, dass ein Trigger in einen Sperrkonflikt mit den vom Dateisystem verhängten Sperren in 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 ist das BEFORE-Image des FILESTREAM-Inhalts für den Trigger möglicherweise nicht verfügbar.

  • 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 nicht transaktionalen Updatevorgängen in der Dateitabelle durch das Dateisystem ist es möglich, dass der FILESTREAM-Inhalt ausschließlich von anderen Win32-Vorgängen gesperrt wird und darauf nicht für Lese-/Schreibzugriff durch den Triggertext zugegriffen werden kann. In solchen Fällen kann durch den versuchten Zugriff auf den FILESTREAM-Inhalt im Triggertext ein Freigabeverletzungsfehler ausgegeben werden. 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 unplanmäßigen Beendigung von Win32-Handles, wie beispielsweise beim expliziten Abbrechen von Win32-Handles durch einen Administrator ODER einen Datenbankabsturz, werden während der Wiederherstellungsvorgänge keine Benutzertrigger ausgeführt, obwohl der FILESTREAM von der unplanmäßig beendeten Win32-Anwendung möglicherweise geändert wurde.

Sichten und FileTables

Ansichten

Eine Sicht kann in einer FileTable genau wie in einer anderen Tabelle erstellt werden. Die folgenden Überlegungen gelten jedoch für eine in einer FileTable erstellten Sicht:

  • Die Anzeigen weisen keine Dateitabellen-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.

  • Die Anzeigen können möglicherweise auf Grundlage der Semantik für eine aktualisierbare Anzeige aktualisiert werden, die Updates können jedoch wie in der Tabelle aufgrund der zugrunde liegenden Tabelleneinschränkungen abgelehnt werden.

  • 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 Sichten

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 auch bei in der FileTable definierten Sichten unverändert.

Momentaufnahmeisolation und Dateitabellen

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 der nicht transaktionale Zugriff für die Datenbank auf FULL festgelegt wird, wird eine Transaktion unter RCSI ausgeführt, oder SI weist das folgende Verhalten auf:

    • Alle Transact-SQL-Lesevorgänge der Spalte Dateitabelle file_stream schlagen fehl. INSERT und UPDATE für die Spalte wären immer noch erfolgreich, solange kein Lesevorgang aus der file_stream-Spalte versucht wird.

    • 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.

    • Nicht transaktiver FileTable-Win32-Zugriff ist erfolgreich. 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 Dateitabellen

Die FILESTREAM-Funktion, von der die FileTable-Funktion abhängt, erfordert einen gewissen Konfigurationsaufwand außerhalb der Datenbank. Daher sind Datenbanken, die FILESTREAM oder Dateitabellen verwenden, nicht vollständig eigenständig.

Sie können den Einschlusstyp der Datenbank auf PARTIAL festlegen, wenn Sie bestimmte Funktionen eigenständiger Datenbanken verwenden möchten, z. B. eigenständige Benutzer. In diesem Fall sind jedoch einige der Datenbankeinstellungen nicht in der Datenbank enthalten und werden nicht automatisch verschoben, wenn die Datenbank verschoben wird.

Zugehöriger Inhalt