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.
S’applique à :
SQL Server
Décrit le fonctionnement de FileTables avec d'autres fonctionnalités de SQL Server.
Groupes de disponibilité Always On et FileTables
Lorsque la base de données qui contient des données FILESTREAM ou FileTable appartient à un groupe de disponibilité Always On :
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 le réplica principal, mais les données FileTable ne sont pas accessibles sur les réplicas secondaires lisibles.
Remarque
Après un basculement, l’intégralité des fonctionnalités FILESTREAM est prise en charge. Les données FILESTREAM sont accessibles à la fois sur les réplicas secondaires avec accès en lecture 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 Fonctions FILESTREAM et FileTable (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 Utiliser FILESTREAM et FileTable avec groupes de disponibilité Always On.
Partitions et FileTables
Le partitionnement n’est pas pris en charge sur les FileTables. Avec la prise en charge de plusieurs groupes de fichiers FILESTREAM, les problèmes de montée en charge verticale peuvent être résolus sans devoir recourir au partitionnement dans la plupart des cas (contrairement aux FILESTREAM de SQL Server 2008).
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 des données modifiées et le suivi des modifications) ne sont pas prises en charge avec les FileTables.
Sémantique de transaction et FileTables
Applications Windows
Les applications Windows ne reconnaissent 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. De ce fait, la récupération et les restaurations transactionnelles ne sont pas possibles avec les opérations de mise à jour Windows.
Applications en Transact-SQL
Pour les applications Transact-SQL opérant sur la colonne FILESTREAM(file_stream) d’un FileTable, la sémantique d’isolation est la même qu’avec le type de données FILESTREAM dans une table utilisateur standard.
Notifications de requête et FileTables
La requête ne peut pas contenir de référence à la colonne FILESTREAM du 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 à la table de destination créée (à l’instar des colonnes FILESTREAM d’une table standard). Toutes les colonnes de table de destination se comportent comme des colonnes normales. Elles ne sont pas associées à une sémantique FileTable.
Déclencheurs et FileTables
Déclencheurs DDL (langage de définition de données)
Il n'y a pas d'éléments spéciaux à prendre en considération pour les déclencheurs DDL utilisés avec les FileTables. Les déclencheurs DDL normaux sont déclenchés lors des opérations Create/Alter database ainsi que des opérations CREATE/ALTER TABLE pour les FileTables. Les déclencheurs peuvent récupérer les données d'événement réelles, notamment le texte de la commande DDL et d'autres informations en appelant la fonction EVENTDATA(). Aucun nouvel événement ou changement n'a été apporté au schéma Eventdata existant.
Déclencheurs DML (langage de manipulation de données)
Ces restrictions s’appliquent lors de l’opération DDL afin de créer des déclencheurs.
Les FileTables ne prennent pas en charge les déclencheurs de type 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 prennent en charge les déclencheurs AFTER pour les opérations DML.
Les déclencheurs définis sur un FileTable ne peuvent pas mettre à jour de FileTables (notamment le FileTable parent). Cette restriction existe principalement pour empêcher un déclencheur d'entrer en conflit de verrouillage avec les verrous maintenus 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
Lorsqu'un accès de mise à jour non transactionnel est autorisé dans une base de données, il est possible d'effectuer une mise à jour sur place des données FILESTREAM dans toutes les tables, notamment un 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 éventuels déclencheurs DML définis peuvent être activés dans le cadre de cette transaction. L’annulation d’une telle transaction dans le corps du déclencheur, bien qu’elle ne soit pas empêchée, n’annule pas les modifications apportées au FILESTREAM. Une telle annulation peut également empêcher les déclencheurs de mise à jour de se déclencher, même si les données FILESTREAM ont pu être modifiées.
En plus de ces impacts, les déclencheurs sur les FileTables doivent gérer quelques comportements supplémentaires :
Avec les opérations de mise à jour non transactionnelles sur le 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 puisse pas être 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 provoquer une erreur de violation de partage. Les déclencheurs doivent être conçus pour gérer ces erreurs convenablement.
L’image AFTER du FILESTREAM peut ne pas être stable, car dans certains cas, d’autres mises à jour non transactionnelles peuvent y écrire de manière active en même temps (en raison des modes de partage autorisés dans l’accès au système de fichiers).
Un arrêt anormal de descripteurs Win32, comme la suppression explicite de descripteurs Win32 par un administrateur OU un incident de base de données, n’exécute pas de déclencheurs d’utilisateur au cours des opérations de récupération, bien que le contenu FILESTREAM ait pu être modifié par l’application Win32 arrêtée anormalement.
Vues et FileTables
Vues
Une vue peut être créée sur un FileTable comme sur toute autre table. Toutefois, les considérations suivantes s'appliquent à une vue créée sur un FileTable :
Les vues ne peuvent avoir aucune sémantique de type FileTable. Autrement dit les colonnes de l’affichage (notamment les colonnes d’attributs de fichier) se comportent comme des colonnes d’affichage normales sans sémantique spéciale. Ceci est également vrai pour les lignes qui représentent des fichiers/répertoires.
Les vues peuvent être modifiables selon la sémantique de la « vue modifiable », mais les contraintes de table sous-jacentes peuvent refuser les mises à jour comme dans la table.
Le chemin d’accès à un fichier peut être visualisé 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 de colonnes FILESTREAM ni de colonnes calculées/calculées persistantes qui dépendent des colonnes FILESTREAM. Ce comportement reste également inchangé avec les vues définies sur le FileTable.
Isolement de capture instantanée et FileTables
L’isolement RCSI (Read Committed Snapshot Isolation) et l’isolement d’instantané (SI) reposent sur la possibilité de disposer d’un instantané des données pour les lecteurs, même lorsque des opérations de mise à jour sont effectuées sur ces données. Cependant, les FileTables autorisent l'accès en écriture non transactionnel aux données FILESTREAM. Par conséquent, les restrictions suivantes s’appliquent à ces fonctionnalités dans les bases de données qui contiennent des FileTables :
Une base de données contenant des FileTables peut être modifiée pour activer RCSI/SI.
Lorsque l'accès non_transactional est défini sur FULL pour la base de données, une transaction s'exécutant sous RCSI ou SI a le comportement suivant :
Toute lecture Transact-SQL de la colonne file_stream du FileTable échoue. INSERT et UPDATE à la colonne réussissent toujours, tant qu’elles ne lisent pas à partir de la colonne file_stream.
Si l’instruction Transact-SQL spécifie des indicateurs de table READCOMMITTEDLOCK, les lectures réussissent et posent des verrous sur les lignes, au lieu d’utiliser le versionnage des lignes.
Les requêtes d'ouverture du FileStream Win32 transactionnel échouent également.
L'accès à FileTable Win32 non transactionnel aboutit. Toutes les requêtes internes effectuées par FileTable ne sont pas affectées.
L'indexation de texte intégral réussit toujours, quelles que soient les options de la base de données (READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION).
Réplicas secondaires accessibles en lecture
Les mêmes considérations s'appliquent aux bases de données secondaires lisibles comme aux instantanés, comme celles décrites dans la section précédente, Isolation d'instantané et FileTables.
Bases de données autonomes et FileTables
La fonctionnalité FILESTREAM, de laquelle la fonctionnalité FileTable dépend, requiert une configuration spécifique hors 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 mode de confinement 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, une partie des paramètres de la base de données ne sont pas contenus dans la base de données et ne sont pas automatiquement déplacés avec celle-ci.