Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Décrit comment les FileTables fonctionnent avec d’autres fonctionnalités de SQL Server.
Groupes de disponibilité AlwaysOn et FileTables
Lorsque la base de données qui contient des données FILESTREAM ou FileTable appartient à un groupe de disponibilité AlwaysOn :
La fonctionnalité FileTable est partiellement prise en charge par les groupes de disponibilité Always On. Après un basculement, les données FileTable sont accessibles sur la réplique principale, mais les données FileTable ne sont pas accessibles sur les répliques secondaires lisibles.
Remarque
Notez qu’après un basculement, toutes les fonctionnalités FILESTREAM sont prises en charge. Les données FILESTREAM sont accessibles sur les réplicas secondaires lisibles et sur le nouveau réplica principal.
Les fonctions FILESTREAM et FileTable acceptent ou retournent des noms de réseau virtuel (VNN) à la place de noms d'ordinateur. Pour plus d’informations sur ces fonctions, consultez Filestream et FileTable Functions (Transact-SQL).
Tous les accès à FILESTREAM ou aux données FileTable via les API du système de fichiers doivent utiliser des VNN à la place des noms d'ordinateur. Pour plus d’informations, consultez FILESTREAM et FileTable avec des groupes de disponibilité AlwaysOn (SQL Server).
Partitionnement et FileTables
Le partitionnement n’est pas pris en charge sur FileTables. Avec la prise en charge de plusieurs groupes de fichiers FILESTREAM, des problèmes de montée en puissance pure peuvent être gérés sans avoir à recourir au partitionnement dans la plupart des scénarios (contrairement à SQL 2008 FILESTREAMs).
Réplication et FileTables
La réplication et les fonctionnalités associées (notamment la réplication transactionnelle, la réplication de fusion, la capture de données modifiées et le suivi des modifications) ne sont pas prises en charge avec FileTables.
Sémantique des transactions et FileTables
Applications Windows
Les applications Windows ne comprennent pas les transactions de base de données. Par conséquent, les opérations d’écriture Windows ne fournissent pas les propriétés ACID d’une transaction de base de données. Par conséquent, les restaurations transactionnelles et la récupération ne sont pas possibles avec les opérations de mise à jour Windows.
Transact-SQL applications
Pour les applications TSQL travaillant sur la colonne FILESTREAM (file_stream) dans un FileTable, la sémantique d’isolation est identique à celle du type de données FILESTREAM dans une table utilisateur normale.
Notifications de requête et FileTables
La requête ne peut pas contenir de référence à la colonne FILESTREAM dans fileTable, dans la clause WHERE ou toute autre partie de la requête.
SELECT INTO et FileTables
Les instructions SELECT INTO d’un FileTable ne propagent pas la sémantique FileTable sur la table de destination créée (comme les colonnes FILESTREAM dans une table régulière). Toutes les colonnes de la table de destination se comportent comme des colonnes normales. Ils n’auront aucune sémantique FileTable associée.
Déclencheurs et FileTables
Déclencheurs DDL (langage de définition de données)
Il n’existe aucun élément particulier à prendre en compte pour les déclencheurs DDL avec FileTables. Les déclencheurs DDL normaux se déclenchent pour les opérations Create/Alter database, ainsi que pour les opérations CREATE/ALTER TABLE pour FileTables. Les déclencheurs peuvent récupérer les données d’événement réelles qui incluent le texte de commande DDL et d’autres informations en appelant la fonction EVENTDATA(). Il n’existe aucun nouvel événement ou modification du schéma Eventdata existant.
Déclencheurs DML (langage de manipulation de données)
Ces restrictions sont appliquées pendant l’opération DDL pour créer des déclencheurs.
Les FileTables ne prennent pas en charge les déclencheurs INSTEAD OF pour les opérations DML. Il s’agit d’une restriction existante sur toutes les tables qui contiennent des colonnes FILESTREAM.
Les FileTables prendront en charge les déclencheurs AFTER pour les opérations DML.
Les déclencheurs définis sur un FileTable ne peuvent pas mettre à jour des FileTables (y compris le FileTable parent). Cette restriction existe principalement pour empêcher un déclencheur d’entrer en conflit de verrouillage avec les verrous détenus par l’accès au système de fichiers dans la même transaction.
Accès non transactionnel et ses effets sur les déclencheurs
Lorsque l’accès à la mise à jour non transactionnelle est autorisé dans une base de données, il est possible d’effectuer une mise à jour sur place des données FILESTREAM dans n’importe quelle table, y compris FileTable dans cette base de données. En raison de cette possibilité, l’image antérieure du contenu FILESTREAM peut ne pas être disponible pour être utilisée par le déclencheur.
Pour les opérations de mise à jour non transactionnelles via le système de fichiers, SQL Server crée une transaction interne pour capturer l’opération CloseHandle et les déclencheurs DML définis peuvent être déclenchés dans le cadre de cette transaction. Une annulation de cette transaction à l’intérieur du corps du déclencheur, bien que cela ne soit pas empêché, n’annule pas les modifications apportées au FILESTREAM. Une telle restauration peut également empêcher le déclenchement des déclencheurs de mise à jour, même si le contenu FILESTREAM a peut-être été modifié.
En plus de ces impacts, les déclencheurs sur FileTables doivent traiter deux comportements supplémentaires
En cas d’opérations de mise à jour non transactionnelles sur FileTable via le système de fichiers, il est possible que le contenu FILESTREAM soit verrouillé exclusivement par d’autres opérations Win32 et ne soit pas accessible en lecture/écriture via le corps du déclencheur. Dans ce cas, toute tentative d’accès au contenu FILESTREAM dans le corps du déclencheur peut donner une erreur « Violation de partage ». Les déclencheurs doivent être conçus pour gérer ces erreurs de manière appropriée.
L’image AFTER du FILESTREAM peut ne pas être stable, car dans certains cas, elle peut être écrite activement par d’autres mises à jour non transactionnelles en même temps (en raison des modes de partage autorisés dans l’accès au système de fichiers).
L’arrêt anormal des handles Win32, comme l'arrêt forcé des handles Win32 par un administrateur OU un plantage de base de données, n'exécute pas les déclencheurs utilisateur pendant les opérations de récupération, même si le contenu FILESTREAM peut avoir été modifié par l'application Win32 qui s'est arrêtée anormalement.
Vues et FileTables
vues
Une vue peut être créée sur un FileTable comme sur n’importe quelle autre table. Toutefois, les considérations suivantes s’appliquent à une vue créée sur un FileTable :
La vue n’aura aucune sémantique liée à FileTable. C’est-à-dire que les colonnes de l’affichage (y compris les colonnes Attributs de fichier) se comportent comme des colonnes d’affichage normales sans sémantique spéciale et identiques pour les lignes représentant des fichiers/répertoires.
La vue peut être mise à jour en fonction de la sémantique « vue pouvant être mise à jour », mais les contraintes de table sous-jacentes peuvent rejeter les mises à jour comme dans la table.
Vous pouvez visualiser le chemin d’accès d’un fichier dans la vue en l’ajoutant en tant que colonne explicite dans la vue. Par exemple:
CREATE VIEW MP3FILES AS SELECT column1, column2, ..., GetFileNamespacePath() AS PATH, column3,... FROM Documents
Vues indexées
Actuellement, les vues indexées ne peuvent pas inclure des colonnes FILESTREAM ou des colonnes calculées/persistantes qui dépendent des colonnes FILESTREAM. Ce comportement reste inchangé avec les vues définies sur fileTable également.
Isolation des instantanés et FileTables
L'isolation en lecture validée avec capture instantanée (RCSI) et l'isolation par capture instantanée (SI) reposent sur la capacité d'avoir un instantané des données toujours disponible pour les lecteurs, même lorsque des opérations de mise à jour sont en cours sur les données. Toutefois, les FileTables autorisent l’accès en écriture non transactionnel aux données Filestream. Par conséquent, les restrictions suivantes s’appliquent à l’utilisation de ces fonctionnalités dans les bases de données qui contiennent des FileTables :
Une base de données qui contient des FileTables peut être modifiée pour activer RCSI/SI.
Lorsque l'accès non_transactionnel est défini sur COMPLET pour la base de données, une transaction exécutée sous RCSI ou SI a le comportement suivant :
Toutes les lectures Transact-SQL de la colonne FileTable file_stream échouent. INSERT et UPDATE sur la colonne réussissent toujours, tant qu’ils ne lisent pas depuis la colonne file_stream.
Si l’instruction Transact-SQL spécifie des indices de table READCOMMITTEDLOCK, les opérations de lecture réussissent et prennent des verrous sur les lignes, au lieu d’utiliser le contrôle de version des lignes.
Les demandes d’ouverture Win32 FileStream traitées échouent également.
L’accès Win32 FileTable non transactionné réussit. Toutes les requêtes internes effectuées par FileTable ne sont pas affectées.
L’indexation en texte intégral réussit toujours, quelles que soient les options de configuration de la base de données (READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION).
Bases de données secondaires lisibles
Les mêmes considérations s’appliquent aux bases de données secondaires lisibles que les instantanés, comme décrit dans la section précédente, l’isolation des instantanés et les fileTables.
Bases de données contenues et FileTables
La fonctionnalité FILESTREAM sur laquelle dépend la fonctionnalité FileTable nécessite une configuration en dehors de la base de données. Par conséquent, une base de données qui utilise FILESTREAM ou FileTable n’est pas entièrement contenue.
Vous pouvez définir le contenu de la base de données sur PARTIAL si vous souhaitez utiliser certaines fonctionnalités des bases de données contenues, telles que les utilisateurs contenus. Dans ce cas, toutefois, vous devez savoir que certains des paramètres de base de données ne sont pas contenus dans la base de données et ne sont pas déplacés automatiquement lorsque la base de données se déplace.