FileTable-Kompatibilität mit anderen SQL Server-Funktionen

  • Artikel

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

In diesem Thema

  • AlwaysOn-Verfügbarkeitsgruppen und FileTables

  • Partitionierung und FileTables

  • Replikation und FileTables

  • Transaktionssemantik und FileTables

  • Abfragebenachrichtigungen und FileTables

  • SELECT INTO und FileTables

  • Trigger und FileTables

  • Sichten und FileTables

  • Momentaufnahmeisolation und FileTables

  • Lesbare sekundäre Datenbanken

  • Eigenständige Datenbanken und FileTables

AlwaysOn-Verfügbarkeitsgruppen und FileTables

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

  • Die FileTable-Funktionalität wird teilweise von AlwaysOn-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.

    HinweisHinweis

    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 FileTable bei AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

[TOP]

Partitionierung und FileTables

Partitionierung wird in 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).

[NACH OBEN]

Replikation und FileTables

Replikation und verwandte Funktionen (einschließlich Transaktionsreplikation, Mergereplikation, Änderungsdatenaufzeichnung und Änderungsnachverfolgung) werden in FileTables nicht unterstützt.

[NACH OBEN]

Transaktionssemantik und FileTables

  • 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 TSQL-Anwendungen, die in der FILESTREAM-(file_stream)-Spalte in einer FileTable arbeiten, ist die Isolationssemantik die gleiche wie beim FILESTREAM-Datentyp in einer regulären Benutzertabelle.

[NACH OBEN]

Abfragebenachrichtigungen und FileTables

Die Abfrage kann keinen Verweis auf die FILESTREAM-Spalte in der FileTable, in der WHERE-Klausel oder in einem anderen Teil der Abfrage enthalten.

[NACH OBEN]

SELECT INTO und FileTables

SELECT INTO-Anweisungen aus einer FileTable geben die FileTable-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 FileTable-Semantik auf.

[NACH OBEN]

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 CREATE DATABASE- oder ALTER DATABASE-Vorgänge sowie für CREATE TABLE- oder ALTER TABLE-Vorgänge 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 zur Erstellung von Triggern erzwungen.

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

    • FileTables unterstützen AFTER-Trigger für DML-Vorgänge.

    • In einer FileTable definierte Trigger können keine FileTables (einschließlich der übergeordneten FileTable) 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 FileTable 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 FILESTREAM ist möglicherweise nicht stabil, da in machen Fällen aufgrund der im Dateisystemzugriff zulässigen Freigabemodi zur selben Zeit durch andere nicht transaktionale Updates aktiv darin geschrieben werden kann.

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

[NACH OBEN]

Sichten und FileTables

  • Sichten
    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 Sicht weist keine FileTable-Semantik auf. d. h. die Spalten in der Sicht (einschließlich Dateiattributspalten) verhalten sich wie normale Sichtspalten ohne besondere Semantik. Das gleiche gilt für Zeilen, die Dateien/Verzeichnisse darstellen.

    • Die Sicht kann möglicherweise auf Grundlage der Semantik für eine aktualisierbare Sicht 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. Beispiel:

      CREATE VIEW MP3FILES AS SELECT column1, column2, …, GetFileNamespacePath() AS PATH, column3,… FROM Documents

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

[NACH OBEN]

Momentaufnahmeisolation und FileTables

Die Read Committed-Momentaufnahme und die Momentaufnahmeisolation 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 die Verwendung dieser Funktionen in Datenbanken, die FileTables 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 FileTable-file_stream-Spalte sind fehlerhaft. 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 FileTable ausgeführten Abfragen sind betroffen.

    • Die Volltextindizierung ist immer erfolgreich, unabhängig von den Datenbankoptionen (READ_COMMITTED_SNAPSHOT oder ALLOW_SNAPSHOT_ISOLATION).

[Nach oben]

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 FileTables beschrieben.

Eigenständige Datenbanken und FileTables

Die FILESTREAM-Funktion, von der die FileTable-Funktion abhängt, erfordert einen gewissen Konfigurationsaufwand außerhalb der Datenbank. Daher sind Datenbanken, die FILESTREAM oder FileTable 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 müssen Sie jedoch beachten, dass einige Datenbankeinstellungen nicht in der Datenbank enthalten sind und nicht automatisch mit der Datenbank verschoben werden.

[NACH OBEN]

Siehe auch

Konzepte

Verwalten von FileTables