Gérer les FileTables

Décrit les tâches administratives courantes pour la gestion des FileTables.

Guide pratique pour obtenir une liste de FileTables et d’objets connexes

Pour obtenir la liste des FileTables, interrogez l’une des vues de catalogue suivantes :

sys.filetables (Transact-SQL)
sys.tables (Transact-SQL) (Vérifiez la valeur de la colonne is_filetable .)

SELECT * FROM sys.filetables;  
GO  
  
SELECT * FROM sys.tables WHERE is_filetable = 1;  
GO

Pour obtenir la liste des objets définis par le système qui ont été créés lors de la création des FileTables associés, interrogez l’affichage catalogue sys.filetable_system_defined_objects (Transact-SQL).

SELECT object_id, OBJECT_NAME(object_id) AS 'Object Name'  
    FROM sys.filetable_system_defined_objects  
    WHERE object_id = filetable_object_id;  
GO

Désactivation et réactivation de l’accès non transactionnel au niveau de la base de données

Pour acquérir l’accès exclusif requis pour certaines tâches d’administration, vous devrez peut-être désactiver temporairement l’accès non transactionnel.

Comportement de l’instruction ALTER DATABASE lors de la modification du niveau d’accès non transactionnel

Lorsque vous définissez l’accès non transactionnel à READ_ONLY ou OFF, la commande ALTER DATABASE ne retourne pas le contrôle à l’utilisateur tant qu’il existe des handles de fichiers ouverts qui entrent en conflit avec l’opération demandée. Les handles de fichier qui entrent en conflit avec cette opération sont les suivants :
- Lorsque vous définissez l’accès à NONE, tous les handles de fichiers ouverts.
- Lorsque vous définissez l’accès à READ_ONLY, tous les handles de fichiers ouverts pour l’accès en écriture.
Pour plus d’informations sur la suppression de handles de fichiers ouverts, consultez Tuer les handles de fichiers ouverts associés à un FileTable dans cette rubrique.

Si la commande ALTER DATABASE est annulée ou se termine par un délai d’expiration, le niveau d’accès transactionnel n’est pas modifié.
Si vous appelez l’instruction ALTER DATABASE avec une clause de terminaison WITH <(ROLLBACK AFTER entier [ SECONDS ] | ANNULATION IMMÉDIATE | NO_WAIT), tous les handles de fichiers non transactionnels ouverts sont tués.

Avertissement

L’arrêt des handles de fichiers ouverts peut entraîner la perte de données non enregistrées par les utilisateurs. Ce comportement est cohérent avec le comportement du système de fichiers lui-même.

Effets de la désactivation de l’accès non transactionnel

La modification du niveau d’accès non transactionnel au niveau de la base de données a les effets suivants sur les répertoires FileTable sous le répertoire au niveau de la base de données :

Lorsque vous définissez l’accès à NONE, tous les répertoires FileTable et leur contenu ne sont plus accessibles ou visibles.
Lorsque vous définissez l’accès à READ_ONLY, tous les répertoires FileTable et leur contenu sont également en lecture seule.

La désactivation de FILESTREAM au niveau de l’instance a les effets suivants sur les répertoires au niveau de la base de données sur cette instance, ainsi que sur les répertoires FileTable sous ces répertoires :

Aucun des répertoires au niveau de la base de données sur l’instance n’est visible si FILESTREAM est désactivé au niveau de l’instance.

Guide pratique pour désactiver et réactiver l’accès non transactionnel au niveau de la base de données

Pour plus d’informations, consultez Options SET d’ALTER DATABASE (Transact-SQL).

Pour désactiver l’accès non transactionnel complet
Appelez l’instruction ALTER DATABASE et DÉFINISSEz la valeur de NON_TRANSACTED_ACCESS à READ_ONLY ou OFF.

-- Disable write access.  
ALTER DATABASE database_name  
    SET FILESTREAM ( NON_TRANSACTED_ACCESS = READ_ONLY );  
GO  
  
-- Disable non-transactional access.  
ALTER DATABASE database_name  
    SET FILESTREAM ( NON_TRANSACTED_ACCESS = OFF );  
GO

Pour réactiver l’accès non transactionnel complet
Appelez l’instruction ALTER DATABASE et SET la valeur de NON_TRANSACTED_ACCESS à FULL.

ALTER DATABASE database_name  
    SET FILESTREAM ( NON_TRANSACTED_ACCESS = FULL );  
GO

Guide pratique pour garantir la visibilité des FileTables dans une base de données

Un répertoire au niveau de la base de données et les répertoires FileTable sous celui-ci sont visibles lorsque toutes ces conditions sont remplies :

FILESTREAM est activé au niveau de l’instance.
L’accès non transactionnel est activé au niveau de la base de données.
Un répertoire valide a été spécifié au niveau de la base de données.

Désactivation et réactivation de l’espace de noms FileTable au niveau de la table

La désactivation de l’espace de noms FileTable désactive toutes les contraintes et déclencheurs définis par le système qui ont été créés avec FileTable. Cela est utile dans les cas où un FileTable doit être réorganisé à grande échelle à l’aide de Transact-SQL opérations sans entraîner de frais d’application de la sémantique FileTable. Toutefois, ces opérations peuvent laisser FileTable dans un état incohérent et empêcher la réactivation de l’espace de noms FileTable.

La désactivation d’un espace de noms FileTable a les résultats suivants :

Les colonnes et données FileTable ne sont pas physiquement supprimées de la table.
Le répertoire FileTable et les fichiers et répertoires qu’il contient disparaissent du système de fichiers et ne sont pas disponibles pour l’accès aux E/S de fichiers.
Les colonnes FileTable définies par le système ne peuvent pas être supprimées et recréées ; sinon, ils se comportent comme des colonnes ordinaires pour les opérations DML.
Les descripteurs de fichiers ouverts empêchent les contraintes FileTable d’être désactivées, car cette opération nécessite un verrou de schéma sur la table.
L’application de toutes les sémantiques FileTable, y compris les contraintes et déclencheurs définis par le système, s’arrête une fois l’espace de noms FileTable désactivé.

La réactivation d’un espace de noms FileTable a les résultats suivants :

FileTable est vérifié pour la cohérence. Si des incohérences sont détectées, une erreur est générée et le FileTable reste désactivé ; sinon, fileTable est réactivé.
L’application de la sémantique FileTable, y compris les contraintes et les déclencheurs définis par le système, est restaurée.
Le répertoire FileTable et les fichiers et répertoires qu’il contient deviennent visibles dans le système de fichiers et deviennent disponibles pour l’accès aux E/S de fichiers.

Comment désactiver et réactiver l'espace de noms FileTable au niveau de la table

Appeler l’instruction ALTER TABLE avec { ENABLE | DISABLE } FILETABLE_NAMESPACE option.

Pour désactiver l’espace de noms FileTable

ALTER TABLE filetable_name  
   DISABLE FILETABLE_NAMESPACE;  
GO

Pour réactiver l’espace de noms FileTable

ALTER TABLE filetable_name  
   ENABLE FILETABLE_NAMESPACE;  
GO

Tuer des handles de fichiers ouverts associés à un FileTable

Les handles ouverts sur les fichiers stockés dans un FileTable peuvent empêcher l’accès exclusif requis pour certaines tâches administratives. Pour activer des tâches urgentes, vous devrez peut-être tuer les handles de fichiers ouverts associés à un ou plusieurs FileTables.

Avertissement

Comment obtenir une liste de descripteurs de fichiers ouverts associés à un "FileTable"

Interrogez la vue-catalogue sys.dm_filestream_non_transacted_handles (Transact-SQL).

SELECT * FROM sys.dm_filestream_non_transacted_handles;  
GO

Comment faire pour fermer les handles de fichiers ouverts associés à un FileTable

Appelez la procédure stockée sp_kill_filestream_non_transacted_handles (Transact-SQL) avec les arguments appropriés pour tuer tous les handles de fichiers ouverts dans la base de données ou dans FileTable, ou pour tuer un handle spécifique.

USE database_name;  
  
-- Kill all open handles in all the filetables in the database.  
EXEC sp_kill_filestream_non_transacted_handles;  
GO  
  
-- Kill all open handles in a single filetable.  
EXEC sp_kill_filestream_non_transacted_handles @table_name = 'filetable_name';  
GO  
  
-- Kill a single handle.  
EXEC sp_kill_filestream_non_transacted_handles @handle_id = integer_handle_id;  
GO

Guide pratique pour identifier les verrous détenus par FileTables

La plupart des verrous pris par FileTables correspondent aux fichiers ouverts par les applications.

Pour identifier les fichiers ouverts et les verrous associés
Joignez le champ request_owner_id dans la vue de gestion dynamique sys.dm_tran_locks (Transact-SQL) avec le champ fcb_id dans sys.dm_filestream_non_transacted_handles (Transact-SQL). Dans certains cas, le verrou ne correspond pas à un seul handle de fichier ouvert.

SELECT opened_file_name  
    FROM sys.dm_filestream_non_transacted_handles  
    WHERE fcb_id IN  
        ( SELECT request_owner_id FROM sys.dm_tran_locks );  
GO

Sécurité FileTable

Les fichiers et répertoires stockés dans FileTables sont sécurisés par la sécurité SQL Server uniquement. La sécurité basée sur les tables et les colonnes est appliquée pour l’accès au système de fichiers, ainsi que pour l’accès Transact-SQL. Les API de sécurité du système de fichiers Windows et les paramètres de liste de contrôle d’accès ne sont pas pris en charge.

Les autorisations de sécurité et d’accès applicables aux groupes de fichiers et conteneurs FILESTREAM s’appliquent également aux FileTables, car les données de fichier sont stockées en tant que colonne FILESTREAM dans fileTable.

Sécurité FileTable et accès Transact-SQL
Transact-SQL l’accès aux données dans FileTables est sécurisé de la même façon que toute autre table. Les vérifications de sécurité appropriées au niveau de la table et des colonnes sont effectuées pour chaque opération qui accède ou modifie les données.

Sécurité fileTable et accès au système de fichiers
Les API du système de fichiers nécessitent des autorisations SQL Server appropriées sur l’ensemble de la ligne de FileTable (c’est-à-dire l’autorisation au niveau de la table) pour ouvrir un handle dans un fichier ou un répertoire stocké dans FileTable. Si l’utilisateur n’a pas l’autorisation SQL Server appropriée sur une colonne du FileTable, l’accès au système de fichiers est refusé.

Sauvegarde et tables de fichiers

Lorsque vous utilisez SQL Server pour sauvegarder un FileTable, les données FILESTREAM sont sauvegardées avec les données structurées de la base de données. Si vous ne souhaitez pas sauvegarder des données FILESTREAM avec des données relationnelles, vous pouvez utiliser une sauvegarde partielle pour exclure les groupes de fichiers FILESTREAM.

Cohérence transactionnelle des sauvegardes FileTable

De nombreux outils et opérations d’administration (y compris la sauvegarde, la sauvegarde des journaux et la réplication transactionnelle) lisent les données cohérentes transactionnellement en lisant les journaux des transactions. À ce stade, ils lisent toutes les données FILESTREAM mises à jour dans le cadre d’une transaction. Lorsque l’accès non transactionnel n’est pas activé au niveau de la base de données, ces outils et opérations fonctionnent avec une cohérence transactionnelle complète.

Toutefois, lorsque l’accès non transactionnel complet est activé, un FileTable peut contenir des données qui ont été mises à jour plus récemment (via une mise à jour non transactionnelle) que la transaction que l’outil ou le processus lit dans le journal des transactions. Cela signifie qu’une opération de restauration « point dans le temps » sur une transaction spécifique peut contenir des données FILESTREAM plus récentes que cette transaction. Il s’agit du comportement attendu lorsque les mises à jour non transactionnelles sont autorisées sur FileTables.

SQL Server Profiler et FileTables

SQL Server Profiler peut capturer les opérations Windows File Open and File Close dans la sortie de trace pour les fichiers stockés dans un FileTable.

Audit et FileTables

FileTable peut être audité comme n’importe quelle autre table. Howerver, les modèles d’accès Win32 ne sont pas définis en fonction des opérations. Une seule action dans le système de fichiers se traduit en plusieurs opérations DML Transact-SQL. Par exemple, l’ouverture d’un fichier dans Microsoft Word se traduit par plusieurs opérations open/close/create/rename/delete et les activités DML correspondantes Transact-SQL. Cela entraîne des enregistrements d’audit détaillés où il est difficile de mettre en corrélation les enregistrements entre les actions du système de fichiers et les enregistrements d’audit DML correspondants Transact-SQL.

DBCC et FileTables

Vous pouvez utiliser DBCC CHECKCONSTRAINTS pour valider les contraintes sur un FileTable, y compris les contraintes définies par le système.

Voir aussi

Compatibilité fileTable avec d’autres fonctionnalités SQL Server
FileTable DDL, Functions, Procédures stockées et vues

Last updated on 2017-06-13

Partager via