Des informations supplémentaires sur les données
publicité
Article technique SQL Server Auteur : Paul S. Randal (SQLskills.com) Relecteur technique : Alexandru Chirica, Arkadi Brjazovski, Prem Mehra, Joanna Omel, Mike Ruthruff, Robin Dhamankar Date de publication : octobre 2008 S'applique à : SQL Server 2008 Résumé : Ce livre blanc décrit la fonctionnalité FILESTREAM de SQL Server 2008, qui permet le stockage et l'accès aux données BLOB en associant SQL Server 2008 et le système de fichiers NTFS. Il couvre les options de stockage d'objets BLOB, la configuration Windows et SQL Server pour utiliser des données FILESTREAM, les considérations relatives à l'association de FILESTREAM avec d'autres fonctionnalités et des informations sur l'implémentation, telles que le partitionnement et les performances. Ce livre blanc est destiné aux architectes, aux professionnels de l'informatique, ainsi qu'aux administrateurs de bases de données chargés d'évaluer ou d'implémenter FILESTREAM. Il suppose que le lecteur est familiarisé avec Windows et SQL Server et possède au moins une connaissance rudimentaire des concepts de base de données, tels que les transactions. Introduction Dans la société actuelle, les données sont générées à des taux incroyables et doivent souvent être enregistrées et accessibles de manière contrôlée et efficace. Il existe différentes technologies pour cela et le choix de la technologie dépend souvent de la nature des données qui sont stockées – structurées, semi-structurées ou non structurées : Les données structurées sont des données qui peuvent facilement être enregistrées dans un schéma relationnel, tel que celui qui représente les données de ventes pour une société. Elles peuvent être stockées dans une base de données avec une table d'informations pour les produits vendus par la société, une autre avec des informations sur les clients, ainsi que d'autres informations sur les ventes des produits aux clients. Les données sont accessibles et manipulées à l'aide d'un langage de requête complet tel que Transact-SQL. Les données semi-structurées sont des données conformes à un schéma faible, mais ne se prêtent pas au stockage dans un ensemble de tables de base de données, telles que les données où chaque point de données peut avoir des attributs radicalement différents. Ces données sont souvent stockées avec le type de données XML du logiciel de base de données Microsoft® SQL Server® et accessibles à l'aide d'un langage de requête basé sur les éléments, tel que XQuery. Les données non structurées peuvent ne pas avoir de schéma du tout (comme une partie des données chiffrées) ou peuvent représenter un volume important de données binaires (plusieurs Mo ou Go) qui peuvent sembler ne pas avoir de schéma, mais qui ont en réalité un schéma très simple lié à elles, par exemple les fichiers image, les flux vidéo ou les clips audio. Les données binaires dans ce cas signifient que les données peuvent avoir n'importe quelle valeur, et non pas uniquement celles qui peuvent être entrées au clavier. Ces valeurs de données sont généralement appelées objets blob. Ce livre blanc décrit la fonctionnalité FILESTREAM de SQL Server 2008, qui permet le stockage et l'accès aux données BLOB en associant SQL Server 2008 et le système de fichiers NTFS. Il couvre la fonctionnalité FILESTREAM, les options de stockage d'objets BLOB, la configuration du système d'exploitation Windows® et de SQL Server pour utiliser des données FILESTREAM, les considérations relatives à l'association de FILESTREAM avec d'autres fonctionnalités et des informations sur l'implémentation, telles que le partitionnement et les performances. Options de stockage d'objets BLOB Lorsque des données structurées et semi-structurées peuvent facilement être stockées dans une base de données relationnelle, le choix de l'emplacement de stockage des données non structurées ou des données BLOB est plus compliqué. Lorsque vous décidez de l'emplacement de stockage des données BLOB, prenez connaissance des spécifications suivantes : 2 Performances : la façon dont les données vont être utilisées est un facteur essentiel. Si l'accès en continu est nécessaire, le stockage des données dans une base de données SQL Server peut être plus lent que le stockage externe dans un emplacement tel que le système de fichiers NTFS. Avec le stockage du système de fichiers, les données sont lues dans le fichier et transmises à l'application cliente (directement ou avec mise en mémoire tampon supplémentaire). Lorsque les données blob sont stockées dans une base de données SQL Server, elles doivent d'abord être lues dans la mémoire de SQL Server (le pool de mémoires tampons), puis être retransmises via une connexion cliente à l'application cliente. Cela signifie non seulement que les données passent par une étape de traitement supplémentaire, mais également que la mémoire de SQL Server est inutilement « polluée » par des données BLOB, ce qui peut entraîner d'autres problèmes de performances pour les opérations SQL Server. Sécurité : les données sensibles dont l'accès doit être étroitement géré peuvent être stockées dans une base de données et la sécurité peut être contrôlée en utilisant les contrôles d'accès SQL Server habituels. Si les mêmes données sont stockées dans le système de fichiers, différentes méthodes de sécurité, telles que les listes de contrôle d'accès (ACL), doivent être implémentées. Taille des données : selon l'étude mentionnée plus loin dans ce livre blanc, les objets blob d'une taille inférieure à 256 kilo-octets (Ko) (tels que des icônes de widget) sont mieux adaptés au stockage dans une base de données, et les objets blob d'une taille supérieure à 1 Mo sont plus adaptés au stockage en dehors de la base de données. Pour ceux dont la taille est comprise entre 256 Ko et 1 Mo, la solution de stockage la plus efficace dépend du rapport lecture/écriture des données et de la fréquence de « remplacement ». Le stockage des données BLOB uniquement dans la base de données (par exemple, en utilisant le type de données varbinary (max)) est limité à 2 gigaoctets (Go) par BLOB. Accès du client : le protocole utilisé par le client pour accéder aux données SQL Server, tel qu'ODBC, peut ne pas être adapté aux applications telles que les fichiers volumineux de flux vidéo. Cela peut nécessiter le stockage des données dans le système de fichiers. Sémantique transactionnelle : si les données BLOB possèdent des données structurées associées qui sont stockées dans la base de données, les modifications apportées aux données BLOB doivent respecter la sémantique transactionnelle de façon à ce que les deux ensembles de données restent synchronisés. Par exemple, si une transaction crée des données BLOB et une ligne dans une table de base de données, puis annule l'opération, la création des données BLOB doit être annulée, ainsi que la création de la ligne dans la table. Cela peut s'avérer très complexe si les données BLOB sont stockées dans le système de fichiers sans lien vers la base de données. Fragmentation des données : les mises à jour et remplacements fréquents entraînent le déplacement des objets blob, dans les fichiers de base de données SQL Server ou dans le système de fichiers, en fonction de l'emplacement de stockage des données. Dans ce cas, si les objets blob sont volumineux, ils peuvent être fragmentés. (c.-à-d., ne pas être stockés dans une partie contiguë du disque). Cette fragmentation est plus aisément traitée à l'aide du système de fichiers qu'à l'aide de SQL Server. Simplicité de gestion : une solution utilisant différentes technologies qui ne sont pas intégrées sera plus complexe et coûteuse à gérer qu'une solution intégrée. Coût : le coût de la solution de stockage varie selon la technologie utilisée. Les explications ci-dessus concernant la taille et la fragmentation reposent sur le document Microsoft Research intitulé Utiliser ou non des objets blob : stockage d'objets blob dans une base de données ou dans un système de fichiers ? (en anglais) (Gray, Van Ingen et Sears). Le document comporte davantage d'informations sur les compromis impliqués et peut être téléchargé à l'adresse suivante : http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 Il existe une multitude de solutions pour le stockage d'objets blob, chacune ayant des avantages et des inconvénients en fonction des spécifications ci-dessus. Le tableau suivant compare trois options communes pour stocker des données blob, notamment FILESTREAM, dans SQL Server 2008. Point de comparaison Taille maximale des objets blob Performances de diffusion en continu des objets blob Sécurité Coût par Go 3 Serveur de fichiers/ Système de fichiers Taille du volume NTFS Solution de stockage SQL Server (avec varbinary(max) 2 Go – 1 octet Excellente Médiocre Excellente Listes de contrôle d'accès manuelles Faible Intégrées Intégrées + automatiques Faible Élevé FILESTREAM Taille du volume NTFS Solution de stockage Point de Serveur de fichiers/ SQL Server FILESTREAM comparaison Système de fichiers (avec varbinary(max) Simplicité de gestion Difficile Intégrée Intégrée Intégration avec les Difficile Cohérence au niveau Cohérence au niveau données structurées des données des données Développement et Plus complexes Plus simples Plus simples déploiement d'applications Récupération suite Excellente Médiocre Excellente à la fragmentation des données Performances de Excellentes Modérées Médiocres petites mises à jour fréquentes Tableau 1 : Comparaison des technologies de stockage d'objets blob avant SQL Server 2008 FILESTREAM est la seule solution qui assure la cohérence transactionnelle des données structurées et non structurées, ainsi que la gestion intégrée, la sécurité, un faible coût et d'excellentes performances de diffusion en continu. Cela est possible en stockant les données structurées dans les fichiers de base de données et les données BLOB non structurées dans le système de fichiers, tout en maintenant la cohérence transactionnelle entre les deux banques de données. Des informations supplémentaires sur l'architecture FILESTREAM sont disponibles dans la section « Présentation de FILESTREAM » plus loin dans ce document. Présentation de FILESTREAM FILESTREAM est une nouvelle fonctionnalité de SQL Server 2008. Elle permet le stockage des données structurées dans la base de données et des données non structurées associées (c.-à-d., des données BLOB) directement dans le système de fichiers NTFS. Vous accédez ensuite aux données BLOB via les API de diffusion en continu Win32® hautes performances, au lieu de devoir subir la diminution des performances liée à l'accès aux données via SQL Server. FILESTREAM assure la cohérence transactionnelle entre les données structurées et non structurées à tout moment, en permettant même la récupération jusqu'à une date et heure des données FILESTREAM à l'aide des sauvegardes de fichiers journaux. La cohérence est gérée automatiquement par SQL Server et ne requiert pas de logique personnalisée dans l'application. Le mécanisme FILESTREAM y parvient en conservant l'équivalent d'un journal des transactions de la base de données, qui possède de nombreuses conditions de gestion identiques (décrites plus en détail dans la section « Configuration du garbage collection FILESTREAM » plus loin dans ce document). La combinaison du journal des transactions de la base de données et du journal des transactions FILESTREAM permet aux données FILESTREAM et aux données structurées d'être récupérées d'un point de vue transactionnel. Au lieu d'être d'un type de données entièrement nouveau, FILESTREAM est un attribut de stockage du type de données varbinary (max) existant. FILESTREAM conserve la majorité du comportement du type de données varbinary (max). Cette fonctionnalité modifie la façon dont les données BLOB sont stockées; dans le système de fichiers plutôt que dans les fichiers de données SQL Server. FILESTREAM étant implémenté en tant que colonne varbinary (max) et intégré directement dans le moteur de base de données, la plupart des fonctions et outils d'administration SQL Server fonctionnent sans changement pour les données FILESTREAM. 4 Il est à noter que le comportement du type de données régulier varbinary (max) demeure inchangé dans SQL Server 2008, y compris la limite de taille de 2 Go. L'ajout de l'attribut FILESTREAM rend une colonne varbinary (max) essentiellement illimitée en taille (en réalité la taille est limitée à celle du volume NTFS sous-jacent). Les données FILESTREAM sont stockées dans le système de fichiers dans un ensemble de répertoires NTFS appelés conteneurs de données, qui correspondent aux groupes de fichiers spéciaux dans la base de données. L'accès transactionnel aux données FILESTREAM est contrôlé par SQL Server et un pilote de filtre du système de fichiers qui est installé dans le cadre de l'activation de FILESTREAM au niveau Windows. L'utilisation d'un pilote de filtre du système de fichiers permet également d'avoir accès à distance aux données FILESTREAM dans un chemin d'accès UNC. SQL Server gère un lien des tris de lignes de la table dans les fichiers FILESTREAM associés. Cela signifie que la suppression ou l'affectation d'un nouveau nom à des fichiers FILESTREAM directement via le système de fichiers provoque l'endommagement de la base de données. L'utilisation de FILESTREAM requiert plusieurs modifications de schéma apportées aux tables de données (le plus souvent la condition que chaque ligne doit posséder un ID de ligne unique) ; elle comprend également des restrictions lorsqu'elle est combinée avec d'autres fonctionnalités (telles que l'incapacité de chiffrer des données FILESTREAM). Elles sont toutes décrites en détail dans la section « Configuration de SQL Server pour FILESTREAM » plus loin dans ce livre blanc. Les données FILESTREAM sont accessibles et manipulées de deux manières : avec le modèle de programmation standard Transact-SQL ou via les API de diffusion en continu Win32. Les deux mécanismes sont entièrement compatibles avec les transactions et prennent en charge la plupart des opérations DML, notamment insertion, mise à jour, suppression et sélection. Les données FILESTREAM sont également prises en charge pour les opérations de maintenance, telles que la sauvegarde, la restauration et le contrôle de cohérence. L'exception principale est que les mises à jour partielles des données FILESTREAM ne sont pas prises en charge. Toute mise à jour d'une valeur de données FILESTREAM se traduit par la création d'une nouvelle copie du fichier de données FILESTREAM. L'ancien fichier est supprimé de façon asynchrone, tel que le décrit la section « Configuration du garbage collection FILESTREAM » plus loin dans ce document. Modèle de programmation double pour accéder aux données BLOB Une fois les données stockées dans une colonne FILESTREAM, elles sont accessibles en utilisant des transactions Transact-SQL ou des API Win32. Cette section fournit des informations générales sur les modèles de programmation et leur utilisation. Accès Transact-SQL À l'aide de Transact-SQL, les données FILESTREAM peuvent être insérées, mises à jour et supprimées, comme suit : 5 Les champs FILESTREAM peuvent être préremplis à l'aide d'une opération d'insertion (avec une valeur vide ou une petite valeur non NULL). Toutefois, une grande quantité de données est diffusée en continu plus efficacement à l'aide des interfaces Win32. Lorsque vous mettez à jour des données FILESTREAM, vous modifiez les données BLOB sousjacentes dans le système de fichiers. Lorsqu'un champ FILESTREAM a la valeur NULL, les données BLOB associées au champ sont supprimées. Les mises à jour segmentées TransactSQL, implémentées comme UPDATE.Write(), ne peuvent pas être utilisées pour effectuer des mises à jour partielles des données FILESTREAM. Lorsqu'une ligne qui contient des données FILESTREAM est supprimée ou une table qui contient des données FILESTREAM est supprimée ou tronquée, les données BLOB sous-jacentes dans le système de fichiers sont également supprimées. La suppression physique réelle des fichiers FILESTREAM est un processus en arrière-plan asynchrone, tel que l'explique la section « Configuration du garbage collection FILESTREAM » plus loin dans ce document. Pour plus d'informations et des exemples d'utilisation de Transact-SQL pour accéder aux données FILESTREAM, consultez la rubrique « Gestion des données FILESTREAM avec Transact-SQL » de la documentation en ligne de SQL Server 2008 (http://msdn.microsoft.com/fr-fr/library/cc645962.aspx). Accès en continu Win32 Pour autoriser l'accès du système de fichiers transactionnel aux données FILESTREAM, une nouvelle fonction intrinsèque, GET_FILESTREAM_TRANSACTION_CONTEXT(), fournit le jeton qui représente la transaction actuelle à laquelle la session est associée. La transaction doit avoir été démarrée mais pas encore validée ou annulée. En obtenant un jeton, l'application lie les opérations de diffusion en continu du système de fichiers FILESTREAM avec une transaction commencée. La fonction retourne NULL si aucune transaction n'est explicitement commencée. Un jeton doit être obtenu pour accéder aux fichiers FILESTREAM. Dans FILESTREAM, le moteur de base de données contrôle l'espace de noms du système de fichiers physique BLOB. Une nouvelle fonction intrinsèque, PathName, fournit le chemin UNC logique de l'objet blob qui correspond à chaque champ FILESTREAM dans la table. L'application utilise ce chemin logique pour obtenir le descripteur Win32 et opérer sur les données BLOB en utilisant des interfaces de système de fichiers Win32 ordinaires. La fonction retourne NULL si la valeur de la colonne FILESTREAM est NULL. Elle souligne le fait qu'un fichier FILESTREAM doit être précréé pour pouvoir être accessible au niveau Win32. Cette opération est réalisée de la façon décrite précédemment. La prise en charge de la diffusion en continu Win32 fonctionne dans le contexte d'une transaction SQL Server. Après avoir obtenu un jeton de transaction et un chemin d'accès, l'API Win32 OpenSqlFilestream permet d'obtenir un descripteur de fichier Win32. Sinon, l'API managée SqlFileStream peut être utilisée. Ce descripteur peut ensuite être utilisé par les interfaces de diffusion en continu Win32, telles que ReadFile() et WriteFile(), afin d'accéder au fichier et de le mettre à jour au moyen du système de fichiers. De nouveau, notez que les fichiers FILESTREAM ne peuvent pas être directement supprimés et ne peuvent pas être renommés dans le système de fichiers. Sinon la cohérence au niveau du lien sera perdue entre la base de données et le système de fichiers (c.-à-d., la base de données est endommagée). L'accès au système de fichiers FILESTREAM modélise une instruction Transact-SQL en utilisant l'ouverture et la fermeture de fichier. L'instruction démarre lorsqu'un descripteur de fichier est ouvert et se termine lorsque le descripteur est fermé. Par exemple, lorsqu'un descripteur d'écriture est fermé, tout déclencheur AFTER possible enregistré sur la table est activé comme si une instruction UPDATE était exécutée. Pour plus d'informations et des exemples d'utilisation des API Win32 pour accéder aux données FILESTREAM, consultez la rubrique « Gestion des données FILESTREAM avec Win32 » de la documentation en ligne de SQL Server 2008 (http://msdn.microsoft.com/fr-fr/library/cc645940.aspx). 6 Sémantique transactionnelle Tous les descripteurs de fichiers doivent être fermés avant que la transaction ne soit validée ou annulée. Si un descripteur est laissé ouvert lorsqu'une validation de transaction se produit, la validation échoue et les lectures et écritures supplémentaires sur le descripteur provoquent une erreur, comme prévu. La transaction doit être restaurée. De même, si la base de données ou l'instance du moteur de base de données s'arrête, tous les descripteurs ouverts sont invalidés. Lorsqu'un fichier FILESTREAM est ouvert pour une opération d'écriture, un nouveau fichier de longueur nulle est créé et la valeur des données FILESTREAM mise à jour complète est écrite. L'ancien fichier est supprimé de façon asynchrone, tel que le décrit la section « Configuration du garbage collection FILESTREAM » plus loin dans ce document. Avec FILESTREAM, lors de la validation, le moteur de base de données garantit la durabilité des transactions pour les données BLOB FILESTREAM modifiées à partir de l'accès en continu au système de fichiers. Cette opération est réalisée en utilisant le journal FILESTREAM indiqué précédemment et un vidage explicite du contenu du fichier FILESTREAM sur le disque. Sémantique d'isolation La sémantique d'isolation est gouvernée par les niveaux d'isolation des transactions du moteur de base de données. Lorsque les données FILESTREAM sont accessibles via des API Win32, seul le niveau d'isolation validé en lecture est pris en charge. L'accès Transact-SQL autorise également les niveaux d'isolation sérialisable et de lecture renouvelée. En outre, avec l'accès Transact-SQL, les lectures erronées sont autorisées par le niveau d'isolation non validé en lecture, ou l'indicateur de requête NOLOCK, mais cet accès n'affiche pas les mises à jour en cours d'exécution des données FILESTREAM. Les opérations d'ouverture d'accès au système de fichiers n'attendent pas de verrous. Au lieu de cela, les opérations d'ouverture échouent immédiatement si elles ne peuvent pas accéder aux données à cause de l'isolation des transactions. Les appels API de diffusion en continu échouent avec ERROR_SHARING_VIOLATION si l'opération d'ouverture ne peut se poursuivre à cause de la violation d'isolation. Mises à jour partielles Pour permettre les mises à jour partielles, l'application peut publier un contrôle FS de périphérique (FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT) afin d'extraire l'ancien contenu dans le fichier auquel le descripteur ouvert fait référence. Il est également possible d'utiliser l'API managée SqlFileStream à l'aide de l'indicateur ReadWrite. Cela déclenchera une copie de l'ancien contenu côté serveur, tel que cela est indiqué précédemment. Pour de meilleures performances d'application et afin d'éviter des dépassements de délais d'attente potentiels lorsque vous travaillez avec de très grands fichiers, vous devez utiliser des E/S asynchrones. Si le FSCTL est publié après l'écriture dans le descripteur, la dernière opération d'écriture persistera et les écritures antérieures effectuées dans le descripteur seront perdues. Pour plus d'informations sur les mises à jour partielles, consultez la rubrique « FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT » de la documentation en ligne de SQL Server 2008 (http://technet.microsoft.com/fr-fr/library/cc627407.aspx). 7 Double écriture à partir de clients distants L'accès du système de fichiers distant aux données FILESTREAM est activé sur le protocole SMB (Block Server Message). Si le client est distant, la mise en cache des opérations d'écriture dépend des options spécifiées et de l'API utilisée. Par exemple, la valeur par défaut pour les API en code natif consiste à exécuter la double écriture, alors que pour les API managées, la valeur par défaut consiste à utiliser la mise en mémoire tampon. Cette différence reflète les commentaires des clients sur les différentes API et leur utilisation dans les versions CTP (Community Technology Preview) de SQL Server 2008. Nous recommandons que les applications qui s'exécutent sur des clients distants consolident les petites opérations d'écriture (par la mise en mémoire tampon) afin d'effectuer moins d'opérations d'écriture avec une taille de données supérieure. En outre, si la mise en mémoire tampon est utilisée, un vidage explicite doit être effectué par le client avant que la transaction ne soit validée. La création de vues mappées en mémoire (E/S mappées en mémoire) à l'aide d'un descripteur FILESTREAM n'est pas prise en charge. Si le mappage mémoire est utilisé pour les données FILESTREAM, le moteur de base de données ne peut pas garantir la cohérence et la durabilité des données, ni l'intégrité de la base de données. À quel moment utiliser FILESTREAM Bien que la technologie FILESTREAM dispose de nombreuses fonctionnalités attrayantes, elle n'est pas optimale dans toutes les situations. Comme indiqué précédemment, la taille des données BLOB et les modèles d'accès sont des facteurs importants lorsque vous décidez si vous allez stocker les données BLOB entièrement dans la base de données ou en utilisant FILESTREAM. La taille affecte les éléments suivants : Efficacité avec laquelle les données BLOB sont accessibles à l'aide de l'un des mécanismes de stockage. Comme indiqué précédemment, l'accès en continu des données BLOB est plus efficace avec FILESTREAM, mais les mises à jour partielles sont (potentiellement) plus lentes. Efficacité de sauvegarde des données combinées structurées et BLOB à l'aide de l'un des mécanismes de stockage. Une sauvegarde qui associe les fichiers de base de données SQL Server et un grand nombre de fichiers FILESTREAM sera plus lente qu'une sauvegarde des fichiers de base de données SQL Server de taille totale équivalente. Cela est causé par la charge supplémentaire de sauvegarde de chaque fichier NTFS (un pour chaque valeur de données FILESTREAM). Cette surcharge est plus notable lorsque les fichiers FILESTREAM sont plus petits (car la surcharge de temps représente un plus grand pourcentage de la durée totale de la sauvegarde par Mo de données). Par exemple, le graphique suivant indique le débit relatif des lectures locales de différentes tailles de données BLOB à l'aide de varbinary (max), FILESTREAM dans Transact-SQL et FILESTREAM dans NTFS. Vous constatez (sur la ligne bleue) que l'accès Win32 des données FILESTREAM devient plusieurs fois plus rapide que l'accès Transact-SQL des données varbinary (max) à mesure que la taille des données augmente. Notez que les mesures de débit sont en mégabits par seconde (Mbit/s). 8 Illustration 1 : Performances de lecture de différentes tailles de BLOB Les chiffres NTFS incluent le temps nécessaire pour démarrer une transaction, pour extraire le chemin d'accès et le contexte de transaction de SQL Server et pour ouvrir un descripteur Win32 dans les données FILESTREAM. Chaque test a été effectué sur le même ordinateur avec quatre cœurs de processeur et un pool de mémoires tampons SQL Server à chaud. L'autre facteur à prendre en considération consiste à savoir si le client ou le niveau intermédiaire peut être écrit (ou modifié) de façon à utiliser les API de diffusion en continu Win32, ainsi qu'un accès normal à SQL Server. Si ce n'est pas le cas, FILESTREAM n'est pas nécessaire, car les meilleures performances sont obtenues avec les API de diffusion en continu Win32. Configuration de Windows pour FILESTREAM Comme avec tout autre déploiement, avant de déployer une application qui utilise FILESTREAM, il est important de préparer le serveur Windows qui va héberger la base de données SQL Server et les conteneurs de données FILESTREAM associés. Cette section explique comment configurer le matériel de stockage et le système de fichiers NTFS en prévision de l'utilisation de FILESTREAM. Elle explique ensuite comment activer FILESTREAM au niveau Windows. Sélection du matériel et configuration Une des causes les plus courantes de charge de travail qui ne fonctionne pas correctement est une configuration matérielle qui n'est pas adaptée. Parfois, la mémoire est insuffisante, ce qui entraîne une surexploitation dans le pool de mémoires tampons de SQL Server, et parfois cela est simplement dû au fait que le matériel de stockage ne possède pas la fonction de débit d'E/S demandée par la charge de travail. Pour les applications qui utilisent FILESTREAM pour la diffusion en continu hautes performances de données BLOB à l'aide des API Win32, le choix et la configuration du matériel de stockage sont essentiels. 9 Les sections suivantes décrivent certaines des meilleures pratiques de sélection et disposition du stockage. Pour une présentation plus approfondie, consultez le livre blanc TechNet relatif à la conception du stockage de base de données physique (http://www.microsoft.com/technet/prodtechnol/sql/2005/ physdbstor.mspx). Après avoir conçu une disposition optimale, il est prudent de réaliser des tests de charge pour valider les performances du sous-système d'E/S. Ce sujet est abordé en détail dans l'article TechNet sur les meilleures pratiques SQL Server intitulé « Meilleures pratiques pour les E/S de prédéploiement » (http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx). Disposition du stockage physique Veillez à prendre en compte la charge de travail anticipée sur un conteneur de données FILESTREAM lorsque vous déterminez son emplacement, ainsi que les charges de travail sur tous les conteneurs de données colocalisés ou fichiers SQL Server. Chaque conteneur de données FILESTREAM devra peutêtre se trouver sur son propre volume, car le fait d'avoir plusieurs conteneurs de données avec un nombre élevé de charges de travail sur un seul volume peut provoquer une contention. Le point à retenir ici est que sans tenir compte des charges de travail impliquées, le fait de tout placer sur un seul volume peut entraîner des problèmes de performances. Le degré de séparation nécessaire varie d'un client à l'autre. Il est également possible de créer un schéma de table dans SQL Server, qui permet l'équilibrage de la charge brute des données FILESTREAM entre plusieurs volumes. Cette opération est décrite dans la section « Équilibrage de la charge des données FILESTREAM ». Option de niveau RAID Les avantages liés à l'utilisation de la technologie RAID sont connus, et on a déjà beaucoup écrit sur la sélection d'un niveau RAID adapté aux besoins de l'application. C'est pourquoi, ce livre blanc n'essaie pas de reprendre toutes ces informations. Comme mentionné précédemment, le livre blanc « Conception du stockage de base de données physique » comporte une excellente section sur les niveaux RAID et la sélection du niveau RAID. Ce qui suit est une simple présentation des facteurs à prendre en compte. Les niveaux RAID diffèrent de plusieurs façons, plus particulièrement en termes de performances de lecture/écriture, de résilience aux défaillances et de coût. Par exemple, RAID 5 est relativement faible coût, il peut gérer l'échec d'un seul lecteur de la baie RAID, et peut ne pas être adapté aux charges de travail avec un nombre d'écritures élevé. En revanche, RAID 10 fournit d'excellentes performances en lecture et en écriture. Ce niveau permet de gérer plusieurs échecs de lecteur (selon le degré de mise en miroir impliqué), mais il est plus coûteux, étant donné qu'au moins la moitié des lecteurs de la baie RAID sont redondants. Voici les trois facteurs principaux impliqués dans la sélection d'un niveau RAID. Le choix du niveau RAID peut être différent pour le volume sur lequel chaque base de données utilisateur est stockée, et peut même être différent entre le volume de stockage des fichiers de données et le volume de stockage des fichiers journaux d'une seule base de données. Si la charge de travail comporte de la diffusion en continu hautes performances de données FILESTREAM, le choix immédiat peut être de faire en sorte que le conteneur de données FILESTREAM utilise le niveau RAID qui offre les performances de lecture les plus élevées. Toutefois, ce choix peut ne pas fournir un niveau élevé de résilience aux défaillances. Par ailleurs, le choix immédiat peut être d'utiliser le même niveau RAID que pour les autres volumes qui stockent les données de la base de données. Cependant, il est possible qu'il ne fournisse pas les niveaux de performances requis par la charge de travail. Pour ce livre blanc, le point à souligner est qu'un choix de niveau RAID conscient doit être effectué pour les volumes de conteneur de données FILESTREAM après avoir évalué les compromis impliqués. Il ne faut pas prendre une décision en fonction d'un seul facteur. 10 Choix de l'interface du lecteur Dans les bases de données classiques liées à des données BLOB, la taille totale des données BLOB peut être plusieurs fois supérieure à la taille totale des données structurées. Lors de l'implémentation d'une solution impliquant des données FILESTREAM stockées dans des volumes distincts, vous souhaiterez peut-être utiliser le stockage le moins cher, tel que IDE ou SATA (appelé simplement « SATA » ci-après), plutôt qu'un stockage SCSI plus onéreux. Avant de faire ce choix, vous devez comprendre les compromis impliqués. Cette section fournit une présentation des différentes caractéristiques de SCSI et IDE/SATA pour prendre une décision en toute connaissance de cause en fonction des performances, de la fiabilité et du coût. Capacité et performances Les lecteurs SATA sont susceptibles d'avoir une capacité plus élevée que les lecteurs SCSI, mais ils ont une vitesse de rotation (tr/min) moins élevée que les lecteurs SCSI. Il existe des lecteurs SATA à 10 000 tr/min, mais la plupart sont à 5 400 ou 7 200 tr/min. Des lecteurs SCSI hautes performances sont disponibles de 10 000 à 15 000 tr/min. Bien que le tr/min puisse être une mesure de comparaison utile, les deux chiffres qui doivent réellement être utilisés pour effectuer une comparaison sont la latence (le délai d'attente jusqu'à ce que la tête du disque soit à la position appropriée sur la surface du disque) et les taux de transfert moyens (volume de données pouvant être transféré vers/à partir de la surface du disque par seconde). Il est également important que les lecteurs soient en mesure de traiter des modèles complexes d'E/S efficacement. Lorsque vous choisissez des lecteurs, vérifiez que les lecteurs SATA prennent en charge NCQ (Native Command Queue) et les lecteurs SCSI prennent en charge CTQ (Command Tag Queue), ce qui leur permet de traiter plusieurs E/S entrelacées pour offrir de meilleures performances. En résumé, les lecteurs SCSI ont généralement une meilleure latence et des taux de transfert plus élevés et fournissent ainsi de meilleures performances de diffusion en continu, mais à un coût plus élevé. Fiabilité SQL Server s'appuie sur un tri des écritures et une durabilité garantis pour fournir fiabilité et récupération via son mécanisme de journal WAL (Write-Ahead Log). Pour plus d'informations sur ces spécifications d'E/S, consultez le livre blanc TechNet « Notions de base sur les E/S SQL Server » (http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx). Pour la fiabilité, SCSI est généralement plus adapté que SATA, car cette technologie prend en charge l'écriture forcée des données sur le disque contrairement à SATA. Cette opération s'effectue par prise en charge de la double écriture, où les données à écrire ne sont pas du tout mises en cache, ou par prise en charge du vidage de force du contenu du cache sur le disque. L'absence de l'une ou l'autre peut avoir un impact sur la récupération après une défaillance matérielle, logicielle ou une panne d'alimentation. Tous les types d'interfaces prennent en charge le remplacement à chaud pour autoriser des réparations tout en préservant la disponibilité. La fonctionnalité FILESTREAM repose sur les garanties de tri des écritures et de durabilité : 11 Durabilité des données lors de la validation des transactions Journalisation WAL pour la création et la suppression de fichiers FILESTREAM La durabilité des données est obtenue par le pilote du système de fichiers FILESTREAM qui effectue un vidage explicite des fichiers modifiés avant de valider des transactions (les détails du mécanisme dépassent l'objet de ce livre blanc). Cela garantit qu'en cas de panne de courant, tous les disques qui n'ont pas de cache protégé par batterie suffisant ne sont pas validés, mais les données FILESTREAM non vidées seront perdues. Si les lecteurs SATA ne prennent pas en charge une opération de vidage forcé, la récupération peut être affectée et des données peuvent être perdues. La journalisation WAL repose sur la cohérence des métadonnées NTFS. Elle-même dépend de la fiabilité des disques sous-jacents. Il n'y a aucun problème avec SCSI, mais si les lecteurs SATA ne prennent pas en charge le vidage forcé, certaines modifications apportées aux métadonnées NTFS peuvent être perdues en cas de panne d'alimentation. Cela peut provoquer un certain nombre de scénarios : Impossible de récupérer NTFS et de monter le volume (c.-à-d., le conteneur de données FILESTREAM est essentiellement hors connexion). NTFS récupère, mais les modifications apportées aux métadonnées NTFS sont perdues et SQL Server ne sait pas restaurer une transaction non validée qui effectue une insertion de données FILESTREAM (c.-à-d., les données FILESTREAM sont perdues). NTFS récupère, mais les modifications apportées aux métadonnées NTFS sont perdues et SQL Server ne sait pas restaurer une transaction non validée qui effectue une suppression de données FILESTREAM (c.-à-d., les données FILESTREAM sont perdues). Notez que ces trois scénarios ne sont pas pires que si les données BLOB étaient stockées en dehors de la base de données sur un volume NTFS avec des lecteurs SATA sous-jacents qui ne prennent pas en charge l'application forcée des données sur le disque. Dans ce cas, l'utilisation de FILESTREAM sur un volume avec des lecteurs SATA est plus adaptée que le stockage des données BLOB dans des fichiers NTFS bruts sur le même volume, car la cohérence au niveau du lien de FILESTREAM fournit un mécanisme pour détecter à quel moment ces corruptions se sont produites (via l'exécution de DBCC CHECKDB sur la base de données). Pour résumer, les données FILESTREAM peuvent être stockées de manière fiable sur des volumes avec stockage SATA sous-jacent, tant que les lecteurs SATA prennent en charge l'application forcée des données sur le disque via le vidage du cache. Configuration NTFS Même le sous-système d'E/S, conçu avec le plus de soin et exécuté sur du matériel hautes performances, peut ne pas fonctionner comme prévu si le système de fichiers (dans ce cas NTFS) n'est pas configuré correctement. Cette section décrit certaines options de configuration qui peuvent affecter une charge de travail impliquant des données FILESTREAM. Pour une présentation plus complète de NTFS, consultez les articles de la bibliothèque TechNet intitulés « Guide de référence technique sur NTFS » (http://technet.microsoft.com/fr-fr/library/cc758691.aspx) et « Utilisation des systèmes de fichiers » (http://technet.microsoft.com/fr-fr/library/bb457112.aspx). Optimisation des performances NTFS Par défaut, NTFS n'est pas configuré pour gérer une charge de travail hautes performances avec des dizaines de milliers de fichiers d'un répertoire du système de fichiers spécifique (c. à-d., le scénario FILESTREAM). Deux options NTFS doivent être configurées pour faciliter les performances FILESTREAM. Il est très important de définir ces options correctement avant d'entreprendre tous les tests de performances ; sinon, les résultats ne seront pas représentatifs des performances FILESTREAM réelles. 12 La première option de configuration consiste à désactiver la génération de noms 8.3 lorsque de nouveaux fichiers sont créés (ou renommés). Ce processus génère un nom secondaire pour chaque fichier, qui est uniquement destiné à la compatibilité descendante avec les applications 16 bits. L'algorithme génère un nouveau nom 8.3, puis doit analyser les noms de fichiers 8.3 existants dans le répertoire pour vérifier que le nouveau nom est unique. Comme le nombre de fichiers du répertoire devient important (généralement plus de 300 000), ce processus prend de plus en plus de temps. Le temps de création d'un fichier augmente et les performances diminuent. Par conséquent, le fait de désactiver ce processus peut accroître les performances de façon significative. Pour désactiver ce processus, tapez la commande suivante à l'invite de commandes, puis redémarrez l'ordinateur : fsutil behavior set disable8dot3 1 Remarque : cette option désactive la génération de noms 8.3 sur tous les volumes NTFS sur le serveur. Si des volumes sont utilisés par les applications 16 bits, ils peuvent rencontrer des problèmes après que vous avez modifié ce comportement. La deuxième option de désactivation consiste à mettre à jour le dernier temps d'accès d'un fichier lorsqu'il est accessible. Si la charge de travail accède brièvement à plusieurs fichiers, un temps disproportionné est consacré à la mise à jour du dernier temps d'accès de chaque fichier. Le fait de désactiver cette option peut aussi augmenter considérablement les performances. Pour désactiver ce processus, tapez la commande suivante à l'invite de commandes, puis redémarrez l'ordinateur : fsutil behavior set disablelastaccess 1 Taille de cluster Tous les systèmes de fichiers Windows possèdent le concept de « cluster », qui est l'unité d'affectation lorsque l'espace disque est alloué. Comme un cluster correspond à la plus petite quantité d'espace disque pouvant être allouée, si un fichier est très petit, une partie du cluster peut être inutilisée (essentiellement gaspillée). La taille de cluster est, par conséquent, généralement assez petite afin que les petits fichiers ne gaspillent pas l'espace disque. Plusieurs clusters peuvent être alloués aux fichiers volumineux, ou la taille des fichiers peut évoluer dans le temps et des clusters peuvent leur être alloués à mesure que leur taille augmente. Si un fichier se développe beaucoup, mais par petits segments, les clusters alloués sont susceptibles de ne pas être contigus sur le disque (c.-à-d., ce sont des « fragments »). Cela signifie que plus les clusters sont petits et plus un fichier se développe, plus il sera fragmenté. La taille de cluster est donc un compromis entre le gaspillage de l'espace disque et la réduction de la fragmentation. Plus d'informations sur les différentes tailles de cluster des systèmes de fichiers Windows sont disponibles dans l'article de la Base de connaissances « Taille de cluster par défaut pour FAT et NTFS » (http://support.microsoft.com/kb/140365). La recommandation pour l'utilisation de FILESTREAM est que les unités individuelles de données BLOB aient une taille minimale de 1 Mo. Dans ce cas, il est recommandé que la taille de clusters NTFS du volume du conteneur de données FILESTREAM soit définie à 64 Ko pour réduire la fragmentation. Cette opération doit être effectuée manuellement, car la valeur par défaut pour les volumes NTFS jusqu'à 2 téraoctets (To) est de 4 Ko. Cela peut être accompli en utilisant l'option /A de la commande format. Par exemple, à l'invite de commandes, tapez : format F: /FS:NTFS /V:MyFILESTREAMContainer /A:64K 13 Ce paramètre doit être associé à des tailles de mémoires tampons volumineuses, comme le décrit la section « Considérations relatives au réglage des performances et aux tests » plus loin dans ce livre blanc. Gestion de la fragmentation Comme décrit précédemment, lorsque plusieurs fichiers se développent sur un volume, ils sont fragmentés. Cela signifie que la collection de clusters allouée au fichier n'est pas contiguë. Lorsque le fichier est lu séquentiellement, les têtes de disque sous-jacentes doivent lire tous les clusters dans l'ordre, ce qui peut signifier qu'ils doivent lire différentes parties du disque. Même si les fichiers ne se développent pas une fois créés, s'ils ont été créés sur un volume où l'espace disponible n'est pas dans un seul segment contigu, ils peuvent être fragmentés immédiatement, car les clusters nécessaires pour les contenir ne sont pas disponibles en contigu. La fragmentation affecte les performances de lecture séquentielle contrairement à lorsqu'il n'y a pas ou peu de fragmentation. Le problème est très semblable à celui de la fragmentation d'index dans une base de données qui ralentit les performances d'analyse d'étendue de requête. Il est, par conséquent, essentiel que la fragmentation soit régulièrement supprimée à l'aide d'un outil de défragmentation de disque de façon à conserver les performances de lecture séquentielle. En outre, si le volume qui va être utilisé pour héberger le conteneur de données FILESTREAM a été précédemment utilisé, ou s'il contient d'autres données, le niveau de fragmentation doit être vérifié et modifié si nécessaire. Compression Les données stockées dans NTFS peuvent être compressées pour économiser de l'espace disque, mais au détriment d'UC supplémentaire pour compresser et décompresser les données lorsqu'elles sont écrites ou lues, respectivement. La compression n'est pas utile si les données sont essentiellement incompressibles. Par exemple, les données aléatoires, les données chiffrées ou les données qui ont déjà été compressées ne vont pas bien se compresser, mais devront être transmises via l'algorithme de compression NTFS et entraîneront une surcharge du processeur. C'est pourquoi, l'activation de la compression n'a de sens que lorsque les données peuvent être fortement compressées, et lorsque l'UC supplémentaire nécessaire n'entraîne pas la diminution des performances de charge de travail. Notez également que la compression ne peut être activée que lorsque la taille maximale de cluster NTFS est de 4 096 octets. La compression peut être activée sur le volume du conteneur de données FILESTREAM lorsqu'il est formaté, avec l'option /C de la commande format. Par exemple : format F: /FS:NTFS /V:MyFILESTREAMContainer /A:4096 /C Un volume existant peut également être activé pour la compression à l'aide des étapes suivantes : 1. Dans Poste de travail ou l'Explorateur Windows, cliquez avec le bouton droit sur le volume à compresser ou à décompresser. 2. Cliquez sur Propriétés pour afficher la boîte de dialogue Propriétés. 3. Dans l'onglet Général, activez ou désactivez la case à cocher Compresser le lecteur pour augmenter l'espace disque disponible, puis cliquez sur OK. 4. Dans la boîte de dialogue Confirmation des modifications d’attributs, indiquez si la compression s'applique au volume entier ou au dossier racine. C'est ce que montre l'illustration suivante. 14 Illustration 2 : Compression d'un volume existant à l'aide de l'Explorateur Windows Gestion de l'espace Bien que plusieurs conteneurs de données FILESTREAM puissent être placés sur un seul volume NTFS, il existe des raisons pour lesquelles il faut disposer d'un mappage 1:1 entre les conteneurs de données et les volumes NTFS. Outre le risque potentiel de contention dépendante de la charge de travail, il est impossible de gérer l'espace du conteneur de données FILESTREAM dans SQL Server. C'est pourquoi, l'utilisation de quotas de disque NTFS est nécessaire, le cas échéant. Les quotas de disque sont suivis par utilisateur, par volume. Ainsi, le fait de posséder plusieurs conteneurs de données FILESTREAM sur un seul volume rend difficile de déterminer quel conteneur de données utilise le plus d'espace disque. Notez que tous les fichiers FILESTREAM sont créés sous le compte de service SQL Server. Si ce paramètre est modifié, de l'espace disque est chargé dans le nouveau compte de service. Il existe un seul pilote de filtre du système de fichiers FILESTREAM pour chaque volume NTFS qui comprend un conteneur de données FILESTREAM, et il en existe également un pour chaque version de SQL Server qui a un conteneur de données FILESTREAM sur le volume. Chaque pilote de filtre est chargé de gérer les conteneurs de données FILESTREAM pour ce volume, pour toutes les instances qui utilisent une version particulière de SQL Server. Par exemple, un volume NTFS qui héberge trois conteneurs de données FILESTREAM, un pour chacune des trois instances de SQL Server 2008, n'aura qu'un pilote de filtre du système de fichiers FILESTREAM SQL Server 2008. 15 Sécurité Il existe deux critères de sécurité pour l'utilisation de la fonctionnalité FILESTREAM. Premièrement, SQL Server doit être configuré pour la sécurité intégrée. Deuxièmement, si l'accès distant est utilisé, le port SMB (445) doit être activé via tous les systèmes de pare-feu. Il s'agit du même port que celui qui est nécessaire pour l'accès standard au partage distant. Pour plus d'informations, consultez l'article de la Base de connaissances « Présentation des services et des exigences de ports réseau pour Windows Server System » (http://support.microsoft.com/kb/832017). Considérations relatives à l'antivirus L'antivirus est omniprésent dans l'environnement actuel. FILESTREAM ne peut pas empêcher le logiciel antivirus d'analyser les fichiers dans le conteneur de données FILESTREAM (cela créerait des problèmes de sécurité). Le logiciel possède généralement un paramètre de stratégie indiquant ce qu'il faut faire lorsqu'un fichier est suspecté d'être contaminé par un virus : supprimer le fichier ou restreindre son accès (opération appelée « mise en quarantaine » du fichier). Dans les deux cas, l'accès aux données BLOB du fichier affecté sera empêché et, dans SQL Server, le fichier semblera avoir été supprimé. Il est recommandé que l'antivirus soit défini de façon à mettre les fichiers en quarantaine, et non pas les supprimer. DBCC CHECKDB peut être utilisé dans SQL Server afin de découvrir quels fichiers semblent être manquants. Ensuite, l'administrateur Windows peut corréler les noms de fichiers par rapport au journal de l'antivirus et effectuer l'action corrective nécessaire. Activation de FILESTREAM dans Windows FILESTREAM est une fonctionnalité hybride qui requiert que l'administrateur Windows et les administrateurs SQL Server effectuent des actions avant que la fonctionnalité ne soit activée. Cela est nécessaire pour conserver la séparation des fonctions entre les administrateurs, surtout si l'administrateur SQL Server n'est pas aussi l'administrateur Windows. L'activation de FILESTREAM au niveau Windows installe un pilote de filtre du système de fichiers, opération pour laquelle seul un administrateur Windows dispose des privilèges nécessaires. Au niveau Windows, FILESTREAM est activé pendant l'installation de SQL Server 2008 ou en exécutant le Gestionnaire de configuration SQL Server. Voici les étapes à suivre : 1. 2. 3. 4. 5. 6. 7. 8. 9. 16 Dans le menu Démarrer, pointez successivement sur Tous les programmes, Microsoft SQL Server 2008, Outils de configuration, puis cliquez sur Gestionnaire de configuration SQL Server. Dans la liste de services, cliquez avec le bouton droit sur Services SQL Server, puis cliquez sur Ouvrir. Dans le composant logiciel enfichable Gestionnaire de configuration SQL Server, recherchez l'instance de SQL Server sur laquelle vous souhaitez activer FILESTREAM. Cliquez avec le bouton droit sur l'instance, puis cliquez sur Propriétés. Dans la boîte de dialogue Propriétés de SQL Server, cliquez sur l'onglet FILESTREAM. Activez la case à cocher Activer FILESTREAM pour l'accès Transact-SQL . Si vous souhaitez lire et écrire des données FILESTREAM à partir de Windows, cliquez sur Activer FILESTREAM pour l'accès en continu aux E/S de fichier. Entrez le nom du partage Windows dans la zone Nom de partage Windows. Si des clients distants doivent accéder aux données FILESTREAM stockées sur ce partage, sélectionnez Autoriser les clients distants à avoir un accès en continu aux données FILESTREAM. Cliquez sur Appliquer. L'illustration suivante montre l'onglet FILESTREAM tel que le décrit la procédure. Illustration 3 : Configuration de FILESTREAM avec le Gestionnaire de configuration SQL Server Cette procédure doit être exécutée pour chaque instance SQL Server qui va utiliser la fonctionnalité FILESTREAM avant de pouvoir être utilisée par SQL Server. Notez qu'il n'y a aucune spécification du conteneur de données FILESTREAM à ce stade. Cette opération est réalisée lorsqu'un groupe de fichiers FILESTREAM est créé dans une base de données après que FILESTREAM a été activé dans SQL Server. Notez qu'il est possible de désactiver l'accès FILESTREAM au niveau Windows même lorsque SQL Server l'a activé. Dans ce cas, une fois l'instance SQL Server redémarrée, toutes les données FILESTREAM sont indisponibles. L'avertissement suivant s'affiche : Illustration 4 : Avertissement affiché lors de la désactivation de FILESTREAM avec le Gestionnaire de configuration SQL Server 17 Configuration de SQL Server pour FILESTREAM Chaque instance SQL Server qui va utiliser la fonctionnalité FILESTREAM doit être configurée séparément, au niveau Windows et au niveau SQL Server. Lorsque FILESTREAM est activé, une base de données doit être configurée pour stocker les données FILESTREAM, et uniquement ensuite des tables comportant des colonnes FILESTREAM peuvent être définies. Cette section explique comment configurer FILESTREAM au niveau SQL Server et comment créer des bases de données et des tables compatibles avec FILESTREAM. Elle explique également comment FILESTREAM interagit avec d'autres fonctionnalités de SQL Server 2008. Considérations relatives à la sécurité FILESTREAM requiert l'utilisation de la sécurité intégrée (authentification Windows). Lorsqu'une application utilisant Win32 tente d'accéder aux données FILESTREAM, l'utilisateur Windows est validé par SQL Server. Si l'utilisateur dispose d'un accès Transact-SQL aux données FILESTREAM, l'accès est également accordé au niveau Win32, tant que le jeton de transaction est obtenu dans le contexte de sécurité de l'utilisateur Windows qui exécute l'ouverture de fichier. La spécification de l'authentification Windows provient de la nature des API d'E/S de fichier Windows. La seule façon de passer l'identité du client de l'application cliente à SQL Server pendant une opération d'E/S de fichier consiste à utiliser le jeton Windows associé au thread du client. Lorsque le conteneur de données FILESTREAM est créé, il est automatiquement protégé afin que le compte de service SQL Server et les membres du groupe builtin/Administrators aient accès à l'arborescence de répertoires du conteneur de données. Vous devez éviter que le contenu du conteneur de données soit modifié, excepté via des méthodes transactionnelles prises en charge, car les modifications apportées via d'autres méthodes entraîneront la corruption du conteneur. Activation de FILESTREAM dans SQL Server La deuxième étape d'activation de FILESTREAM s'effectue dans l'instance SQL Server 2008. Cette opération ne doit pas être effectuée tant que FILESTREAM n'est pas activé au niveau Windows, et le volume NTFS qui va stocker les données FILESTREAM n'a pas été correctement préparé (tel que le décrit la section « Configuration de Windows pour FILESTREAM » plus haut). L'accès FILESTREAM est contrôlé dans SQL Server à l'aide de sp_configure pour affecter un des trois paramètres à l'option de configuration filestream_access_level. Les valeurs possibles sont : 0 : désactiver la prise en charge de FILESTREAM pour cette instance 1 : activer FILESTREAM pour l'accès Transact-SQL uniquement 2 : activer FILESTREAM pour l'accès en continu Transact-SQL et Win32 L'exemple suivant montre comment activer FILESTREAM pour l'accès en continu Transact-SQL et Win32. EXEC sp_configure filestream_access_level, 2; GO RECONFIGURE; GO 18 L'instruction RECONFIGURE est nécessaire pour que la valeur récemment configurée prenne effet. Notez que si FILESTREAM n'a pas été activé au niveau Windows, il n'est pas activé au niveau SQL Server lors de l'exécution du code précédent. Vous trouverez la valeur actuelle configurée à l'aide du code suivant. EXEC sp_configure filestream_access_level; GO Si FILESTREAM n'est pas configuré au niveau Windows, « config_value » dans la sortie de sp_configure est différent (c.-à-d., 0) de « run_value » après exécution de l'instruction RECONFIGURE. Création d'une base de données compatible avec FILESTREAM Une fois que FILESTREAM est activé aux niveaux Windows et SQL Server, un conteneur de données FILESTREAM peut être défini. Cette opération s'effectue en définissant un groupe de fichiers FILESTREAM dans une base de données. Il existe un mappage 1:1 entre les groupes de fichiers FILESTREAM et les conteneurs de données FILESTREAM. Un groupe de fichiers FILESTREAM peut être défini lorsqu'une base de données est créée, ou il peut être créé séparément à l'aide d'une instruction ALTER DATABASE. L'exemple suivant crée un groupe de fichiers FILESTREAM dans une base de données existante. ALTER DATABASE Production ADD FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM; GO La clause CONTAINS FILESTREAM est nécessaire pour différencier le nouveau groupe de fichiers des groupes de fichiers ordinaires de base de données. Si la fonctionnalité FILESTREAM est désactivée, cette instruction échoue avec l'erreur suivante. Msg 5591, Niveau 16, État 3, Ligne 1 La fonctionnalité FILESTREAM est désactivée. En supposant que FILESTREAM est activé aux niveaux Windows et SQL Server, le groupe de fichiers est créé. À ce stade, le conteneur de données FILESTREAM est défini en ajoutant un seul fichier au groupe de fichiers. Le chemin d'accès spécifié est le chemin d'accès du répertoire qui va être créé en tant que racine du conteneur de données. Le chemin d'accès complet jusqu'au nom du répertoire final, mais 19 qui ne le comprend pas, doit déjà exister. L'exemple suivant définit le conteneur de données pour le groupe de fichiers FileStreamGroup1 créé précédemment. ALTER DATABASE Production ADD FILE ( NAME = FSGroup1File, FILENAME = 'F:\Production\FSDATA') TO FILEGROUP FileStreamGroup1; GO À ce stade, le répertoire FSDATA va être créé. Il est vide en dehors de deux éléments : Le fichier filestream.hdr. Il s'agit des métadonnées FILESTREAM du conteneur de données. Le répertoire $FSLOG. Il s'agit de l'équivalent FILESTREAM du journal des transactions d'une base de données. Notez qu'une base de données peut contenir plusieurs groupes de fichiers FILESTREAM. Cela peut être utile pour distinguer le stockage d'objets blob de plusieurs tables de la base de données. Création d'une table pour le stockage de données FILESTREAM Une fois que la base de données possède un groupe de fichiers FILESTREAM, il est possible de créer des tables qui contiennent des colonnes FILESTREAM. Comme indiqué précédemment, une colonne FILESTREAM est définie comme colonne varbinary (max) qui a l'attribut FILESTREAM. Le code suivant crée une table avec une seule colonne FILESTREAM. USE Production; GO CREATE TABLE DocumentStore ( DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID ()) FILESTREAM_ON FileStreamGroup1; GO 20 21 Une table peut avoir plusieurs colonnes FILESTREAM, mais les données de toutes les colonnes FILESTREAM d'une table doivent être stockées dans le même groupe de fichiers FILESTREAM. Si la clause FILESTREAM_ON n'est pas spécifiée, le groupe de fichiers FILESTREAM défini comme étant le groupe de fichiers par défaut est utilisé. Cela peut ne pas être la configuration voulue et peut provoquer des problèmes de performances. Une fois la table créée, le conteneur de données FILESTREAM doit contenir un autre répertoire, correspondant à la table, avec un sous-répertoire qui correspond à la colonne FILESTREAM dans la table. Ce sous-répertoire contiendra les fichiers de données une fois les données entrées dans la table. La structure du répertoire varie en fonction du nombre de colonnes FILESTREAM dont dispose une table et selon que la table est partitionnée ou non. Notez que pour qu'une table possède plusieurs colonnes FILESTREAM, elle doit également avoir une colonne avec le type de données uniqueidentifier qui a l'attribut ROWGUIDCOL. Cette colonne ne doit pas autoriser les valeurs Null et doit avoir une contrainte de colonne unique de type UNIQUE ou PRIMARY KEY . La valeur du GUID de la colonne doit être fournie par une application lors de l'insertion de données ou par une contrainte DEFAULT qui utilise la fonction NEWID() (ou NEWSEQUENTIALID() si la réplication de fusion est configurée, comme indiqué dans la section « Combinaisons de fonctionnalités et restrictions » plus loin dans ce document). Pour plus d'informations sur les détails et les restrictions sur le schéma de table et les options nécessaires, consultez la rubrique « CREATE TABLE (Transact-SQL) » de la documentation en ligne de SQL Server 2008 (http://msdn.microsoft.com/fr-fr/library/ms174979.aspx). Configuration du garbage collection FILESTREAM Les fichiers de données FILESTREAM dans le conteneur de données FILESTREAM ne peuvent pas être partiellement mis à jour. Cela signifie que toute modification apportée aux données BLOB de la colonne FILESTREAM crée un nouveau fichier de données FILESTREAM. L'ancien fichier doit être conservé jusqu'à ce qu'il ne soit plus nécessaire à des fins de récupération. Les fichiers qui représentent les données FILESTREAM supprimées, les insertions restaurées de données FILESTREAM, sont conservés. Les fichiers qui ne sont plus nécessaires sont supprimés par le processus de garbage collection. Ce processus est automatique, contrairement aux services Windows SharePoint®, où le garbage collection doit être implémenté manuellement sur le magasin d'objets blob externe. Toutes les opérations de fichier FILESTREAM sont mappées à un numéro séquentiel dans le journal des transactions de la base de données. Tant que le journal des transactions est tronqué après le LSN d'opération FILESTREAM, le fichier n'est plus nécessaire et ne peut pas être récupéré par le garbage collector. Par conséquent, tout ce qui peut empêcher la troncation du journal des transactions peut également empêcher la suppression physique d'un fichier FILESTREAM. Exemples : 22 Les sauvegardes de journal n'ont pas été effectuées, en mode de récupération FULL ou BULK_LOGGED. Il existe une transaction active de longue durée. Le travail du lecteur du journal de réplication n'a pas été exécuté. Le garbage collection FILESTREAM est une tâche en arrière-plan qui est déclenchée par le processus de point de contrôle de base de données. Un point de contrôle est automatiquement exécuté lorsque le journal des transactions a été généré. Pour plus d'informations, consultez la rubrique « CHECKPOINT et la partie active du journal » dans la documentation en ligne de SQL Server 2008 (http://msdn.microsoft.com/fr-fr/library/ms189573.aspx). Étant donné que les opérations de fichier FILESTREAM font l'objet d'une journalisation minimale dans le journal des transactions de la base de données, quelques instants peuvent s'écouler avant que le nombre d'enregistrements générés dans le journal des transactions déclenche un processus de point de contrôle et qu'une opération de garbage collection se produise. Si cela devient un problème, forcez le garbage collection à l'aide de l'instruction CHECKPOINT. Considérations relatives au partitionnement Si la table qui contient des données FILESTREAM est partitionnée, la clause FILESTREAM_ON doit être incluse et doit spécifier un schéma de partitionnement de groupes de fichiers FILESTREAM et reposer sur la fonction de partitionnement de la table. Cela est nécessaire, car le schéma standard de partitionnement impliquera des groupes de fichiers ordinaires qui ne peuvent pas être utilisés pour stocker des données FILESTREAM. La définition de la table (dans une instruction CREATE TABLE ou CREATE CLUSTERED INDEX … WITH DROP_EXISTING) spécifie les deux schémas de partitionnement. Le schéma de partitionnement FILESTREAM peut indiquer que toutes les partitions sont mappées à un seul groupe de fichiers, mais cela n'est pas recommandé, car cela peut entraîner des problèmes de performances. L'exemple suivant (forcé) illustre cette syntaxe : CREATE PARTITION FUNCTION DocPartFunction (INT) AS RANGE RIGHT FOR VALUES (100000, 200000); GO CREATE PARTITION SCHEME DocPartScheme AS PARTITION DocPartFunction TO (Data_FG1, Data_FG2, Data_FG3); GO CREATE PARTITION SCHEME DocFSPartScheme AS PARTITION DocPartFunction TO (FS_FG1, FS_FG2, FS_FG3); GO CREATE TABLE DocumentStore ( 23 DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID () ON Data_FG1) ON DocPartScheme (DocumentID) FILESTREAM_ON DocFSPartScheme; GO Notez que pour utiliser la colonne DocumentID comme colonne de partitionnement, l'index non cluster sous-jacent qui applique la contrainte UNIQUE sur le DocGUID doit être explicitement placé dans un groupe de fichiers afin que DocumentID puisse être la colonne de partitionnement. Cela signifie que le basculement de partition n'est possible que si les contraintes UNIQUE sont désactivées avant d'effectuer le basculement de partition, car il s'agit d'index non alignés, puis sont réactivées après. Suite de l'exemple précédent, le code suivant crée une table, puis tente un basculement de partition. CREATE TABLE NonPartitionedDocumentStore ( DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID ()); GO ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore; GO Le basculement de partition échoue avec le message suivant. Msg 7733, Niveau 16, État 4, Ligne 1 Échec de l'instruction 'ALTER TABLE SWITCH'. La table « FileStreamTestDB.dbo.DocumentStore » est partitionnée alors que l'index « UQ_Document_8CC1617F60ED59 » n'est pas partitionné. 24 La désactivation de l'index unique dans la table source et une nouvelle tentative donne le code suivant. ALTER INDEX [UQ__Document__8CC331617F60ED59] ON DocumentStore DISABLE; GO ALTER TABLE FileStreamTest3 SWITCH PARTITION 2 TO NonPartitionedFileStreamTest3; GO Le basculement échoue également, avec le message suivant. Msg 4947, Niveau 16, État 1, Ligne 1 Échec de l'instruction ALTER TABLE SWITCH. Il n'y a pas d'index en double dans la table source « FileStreamTestDB.dbo.DocumentStore » pour l'index « UQ_NonParti_8CC3316103317E3D » dans la table cible « FileStreamTestDB.dbo.NonPartitionedDocumentStore ». Les index uniques dans les tables partitionnées et non partitionnées doivent être désactivés avant de poursuivre le basculement. ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON NonPartitionedDocumentStore DISABLE; GO ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore; GO ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON); ALTER INDEX [UQ__Document__8CC331617F60ED59] ON NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON); GO 25 Des informations supplémentaires sur les données FILESTREAM de partitionnement seront incluses dans le prochain livre blanc consacré au partitionnement dans SQL Server 2008. Équilibrage de charge des données FILESTREAM Il est également possible d'utiliser le partitionnement pour créer un schéma de table, qui permet l'équilibrage de la charge brute des données FILESTREAM entre plusieurs volumes. Cela peut être souhaitable pour diverses raisons, notamment des limitations au niveau matériel ou pour autoriser le stockage des zones réactives d'une table sur différents volumes. Le code suivant illustre une fonction et un schéma de partitionnement en fonction de la colonne uniqueidentifier qui répartit efficacement les données FILESTREAM sur 16 volumes, tout en agrégeant les données structurées dans deux groupes de fichiers. USE master; GO -- Créer la base de données CREATE DATABASE Production ON PRIMARY (NAME = 'Production', FILENAME = 'E:\Production\Production.mdf'), FILEGROUP DataFilegroup1 (NAME = 'Data_FG1', FILENAME = 'F:\Production\Data_FG1.ndf'), FILEGROUP DataFilegroup2 (NAME = 'Data_FG2', FILENAME = 'G:\Production\Data_FG2.ndf'), FILEGROUP FSFilegroup0 CONTAINS FILESTREAM (NAME = 'FS_FG0', FILENAME = 'H:\Production\FS_FG0'), FILEGROUP FSFilegroup1 CONTAINS FILESTREAM (NAME = 'FS_FG1', FILENAME = 'I:\Production\FS_FG1'), FILEGROUP FSFilegroup2 CONTAINS FILESTREAM (NAME = 'FS_FG2', FILENAME = 'J:\Production\FS_FG2'), FILEGROUP FSFilegroup3 CONTAINS FILESTREAM (NAME = 'FS_FG3', FILENAME = 'K:\Production\FS_FG3'), FILEGROUP FSFilegroup4 CONTAINS FILESTREAM (NAME = 'FS_FG4', FILENAME = 'L:\Production\FS_FG4'), 26 FILEGROUP FSFilegroup5 CONTAINS FILESTREAM (NAME = 'FS_FG5', FILENAME = 'M:\Production\FS_FG5'), FILEGROUP FSFilegroup6 CONTAINS FILESTREAM (NAME = 'FS_FG6', FILENAME = 'N:\Production\FS_FG6'), FILEGROUP FSFilegroup7 CONTAINS FILESTREAM (NAME = 'FS_FG7', FILENAME = 'O:\Production\FS_FG7'), FILEGROUP FSFilegroup8 CONTAINS FILESTREAM (NAME = 'FS_FG8', FILENAME = 'P:\Production\FS_FG8'), FILEGROUP FSFilegroup9 CONTAINS FILESTREAM (NAME = 'FS_FG9', FILENAME = 'Q:\Production\FS_FG9'), FILEGROUP FSFilegroupA CONTAINS FILESTREAM (NAME = 'FS_FGA', FILENAME = 'R:\Production\FS_FGA'), FILEGROUP FSFilegroupB CONTAINS FILESTREAM (NAME = 'FS_FGB', FILENAME = 'S:\Production\FS_FGB'), FILEGROUP FSFilegroupC CONTAINS FILESTREAM (NAME = 'FS_FGC', FILENAME = 'T:\Production\FS_FGC'), FILEGROUP FSFilegroupD CONTAINS FILESTREAM (NAME = 'FS_FGD', FILENAME = 'U:\Production\FS_FGD'), FILEGROUP FSFilegroupE CONTAINS FILESTREAM (NAME = 'FS_FGE', FILENAME = 'V:\Production\FS_FGE'), FILEGROUP FSFilegroupF CONTAINS FILESTREAM (NAME = 'FS_FGF', FILENAME = 'W:\Production\FS_FGF'); GO USE Production; GO -- Créer une fonction de partition basée sur les 6 derniers octets du GUID 27 CREATE PARTITION FUNCTION LoadBalance_PF (UNIQUEIDENTIFIER) AS RANGE LEFT FOR VALUES ( CONVERT (uniqueidentifier, '00000000-0000-0000-0000-100000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-200000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-300000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-400000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-500000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-600000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-700000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-800000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-900000000000'), CONVERT (, « uniqueidentifier 00000000-0000-0000-0000-a00000000000 »), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-b00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-c00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-d00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-e00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-f00000000000')); GO -- Créer un schéma de partitionnement FILESTREAM qui permet le mappage à 16 groupes de fichiers FILESTREAM CREATE PARTITION SCHEME LoadBalance_FS_PS AS PARTITION LoadBalance_PF TO ( FSFileGroup0, FSFileGroup1, FSFileGroup2, FSFileGroup3, FSFileGroup4, FSFileGroup5, FSFileGroup6, FSFileGroup7, FSFileGroup8, FSFileGroup9, FSFileGroupA, FSFileGroupB, FSFileGroupC, FSFileGroupD, FSFileGroupE, FSFileGroupF); GO 28 -- Créer un schéma de partitionnement de données dans une méthode de tourniquet (round robin) entre deux groupes de fichiers CREATE PARTITION SCHEME LoadBalance_Data_PS AS PARTITION LoadBalance_PF TO ( DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2); GO -- Créer la table partitionnée CREATE TABLE DocumentStore ( DocumentID INT IDENTITY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL DEFAULT NEWID (), CONSTRAINT DocStorePK PRIMARY KEY CLUSTERED (DocGUID), CONSTRAINT DocStoreU UNIQUE (DocGUID) ON LoadBalance_Data_PS (DocGUID) FILESTREAM_ON LoadBalance_FS_PS ; GO L'équilibrage de charge peut facilement être testé à l'aide du code suivant. SET NOCOUNT ON; GO 29 -- Insérer 10000 lignes pour tester l'équilibrage de charge DECLARE @count INT = 0; WHILE (@count < 10000) BEGIN INSERT INTO DocumentStore DEFAULT VALUES; SET @count = @count + 1; END; GO -- Vérifier la distribution SELECT COUNT ($PARTITION.LoadBalance_PF (DocGUID)) FROM DocumentStore GROUP BY $PARTITION.LoadBalance_PF (DocGUID); GO Les résultats d'un exemple de série de test étaient 631, 641, 661, 640, 649, 637, 618, 618, 576, 608, 595, 645, 640, 616, 602 et 623 lignes dans chacun des groupes de fichiers FILESTREAM FS_FG0 à FS_FGF. Combinaisons de fonctionnalités et restrictions Étant donné que la fonctionnalité FILESTREAM stocke des données dans le système de fichiers, il existe certaines restrictions et considérations à prendre en compte lorsque FILESTREAM est associé à d'autres fonctionnalités SQL Server. Cette section fournit une présentation des combinaisons de fonctionnalités à connaître. Pour plus d'informations, consultez la rubrique « Utilisation de FILESTREAM avec d'autres fonctionnalités SQL Server » dans la documentation en ligne de SQL Server 2008 (http://msdn.microsoft.com/fr-fr/library/bb895334.aspx). Réplication La réplication transactionnelle et la réplication de fusion prennent en charge les données FILESTREAM, mais il existe de nombreux éléments à en prendre en compte, notamment : 30 Lorsque la topologie de réplication comprend des instances utilisant différentes versions de SQL Server, il existe des limitations sur la taille des données qui peuvent être envoyées aux instances de bas niveau. Les options de filtre de réplication déterminent si l'attribut FILESTREAM est répliqué ou n'utilise pas la réplication transactionnelle. La taille maximale des données varbinary (max) qui peuvent être répliquées dans la réplication transactionnelle sans répliquer l'attribut FILESTREAM est de 2 Go. Lorsque la réplication de fusion est utilisée, celle-ci ainsi que FILESTREAM requièrent une colonne uniqueidentifier. Soyez vigilant avec le schéma de la table lorsque vous utilisez la réplication de fusion afin que les GUID soient séquentiels (c.-à-d., utilisez NEWSEQUENTIALID() plutôt que NEWID()). Mise en miroir de bases de données La mise en miroir de bases de données ne prend pas en charge FILESTREAM. Un groupe de fichiers FILESTREAM ne peut pas être créé sur le serveur principal. La mise en miroir de bases de données ne peut pas être configurée pour une base de données qui contient des groupes de fichiers FILESTREAM. Chiffrement Les données FILESTREAM ne peuvent pas être chiffrées à l'aide de méthodes de chiffrement SQL Server. Si le chiffrement transparent des données est activé, les données FILESTREAM ne sont pas chiffrées. Clustering de basculement FILESTREAM est entièrement pris en charge par le clustering de basculement. FILESTREAM doit être activé pour tous les nœuds du cluster au niveau Windows, et les conteneurs de données FILESTREAM doivent être placés sur un stockage partagé afin que les données soient disponibles dans tous les nœuds. Pour plus d'informations, consultez la documentation en ligne de SQL Server 2008 : « Procédure : configurer FILESTREAM sur un cluster de basculement » (http://msdn.microsoft.com/frfr/library/cc645886.aspx). Texte intégral L'indexation de texte intégral fonctionne avec une colonne FILESTREAM de la même façon qu'avec une colonne varbinary (max). La table doit contenir une colonne supplémentaire qui contient l'extension de nom de fichier pour les données BLOB stockées dans la colonne FILESTREAM. Instantanés de base de données SQL Server ne prend pas en charge les instantanés de base de données pour les conteneurs de données FILESTREAM. Si un fichier de données FILESTREAM est inclus dans une clause CREATE DATABASE ON, l'instruction échoue et une erreur est levée. Si une base de données contient des données FILESTREAM, un instantané de base de données des groupes de fichiers ordinaires peut être créé. Dans ce cas, un message d'avertissement est retourné et les groupes de fichiers FILESTREAM sont marqués comme étant hors ligne dans l'instantané de base de données. Les requêtes fonctionnent comme prévu sur l'instantané de base de données à moins qu'elles tentent d'accéder aux données FILESTREAM. Si cela se produit une erreur est générée. Un instantané de base de données ne peut pas être rétabli si la base de données contient des données FILESTREAM, car il n'existe aucun moyen de déterminer l'état des données FILESTREAM au moment représenté par l'instantané de base de données. Vues, index, statistiques, déclencheurs et contraintes 31 Les colonnes FILESTREAM ne peuvent pas faire partie d'une clé d'index ou être spécifiées comme colonne INCLUDE dans un index non cluster. Il est possible de définir une colonne calculée qui référence une colonne FILESTREAM, mais la colonne calculée ne peut pas être indexée. Il est impossible de créer des statistiques sur des colonnes FILESTREAM. Il est impossible de créer des contraintes PRIMARY KEY, FOREIGN KEY, et UNIQUE sur des colonnes FILESTREAM. Les vues indexées ne peuvent pas contenir de colonnes FILESTREAM ; contrairement aux vues non indexées. Les déclencheurs Instead-of ne peuvent pas être définis sur des tables qui contiennent des colonnes FILESTREAM. Niveaux d'isolation Lorsque les données FILESTREAM sont accessibles via des API Win32, seul le niveau d'isolation validé en lecture est pris en charge. L'accès Transact-SQL autorise également les niveaux d'isolation sérialisable et de lecture renouvelée. En outre, avec l'accès Transact-SQL, les lectures erronées sont autorisées par le niveau d'isolation non validé en lecture, ou l'indicateur de requête NOLOCK, mais cet accès n'affiche pas les mises à jour en cours d'exécution des données FILESTREAM. Sauvegarde et restauration FILESTREAM fonctionne avec tous les modes de récupération et toutes les formes de sauvegarde et de restauration (complète, différentielle et des journaux). Dans une situation d'urgence, si l'option CONTINUE_AFTER_ERROR est spécifiée sur une option BACKUP ou RESTORE, il est possible que les données FILESTREAM ne soient pas récupérées sans perte (semblable à la récupération des données standard lorsque CONTINUE_AFTER_ERROR est spécifiée). Sécurité L'instance SQL Server doit être configurée pour utiliser la sécurité intégrée si l'accès Win32 aux données FILESTREAM est requis. Copie des journaux de transaction La copie des journaux de transaction prend en charge FILESTREAM. Les serveurs principaux et secondaires doivent exécuter SQL Server 2008 ou une version ultérieure, et FILESTREAM doit être activé au niveau Windows. SQL Server Express SQL Server Express prend en charge FILESTREAM. La limite de taille de base de données de 4 Go n'inclut pas le conteneur de données FILESTREAM. Toutefois, si les données FILESTREAM sont envoyées à/à partir de l'instance SQL Server Express avec Service Broker, soyez vigilant, car Service Broker ne prend pas en charge le stockage des données comme FILESTREAM dans les files d'attente de transmission ou cibles. Cela signifie que si une file d'attente est créée, la limite de taille de base de données de 4 Go peut être atteinte. Une autre solution consiste dans ce cas à utiliser un schéma où la conversation Service Broker produit les notifications dont les données FILESTREAM ont besoin pour être envoyées ou reçues. 32 La transmission réelle des données FILESTREAM s'effectue à l'aide de l'accès à distance et via le partage FILESTREAM du conteneur de données FILESTREAM de l'instance SQL Server Express. 33 Considérations relatives au réglage des performances et aux tests Il existe plusieurs éléments importants à prendre en compte lors du paramétrage d'une charge de travail FILESTREAM : Vérifiez que le matériel est configuré correctement pour FILESTREAM. Vérifiez que la génération de noms 8.3 est désactivée dans NTFS. Vérifiez que le suivi du dernier temps d'accès est désactivé dans NTFS. Vérifiez que le conteneur de données FILESTREAM n'est pas sur un volume fragmenté. Vérifiez que la taille des données BLOB est appropriée pour le stockage avec FILESTREAM. Vérifiez que les conteneurs de données FILESTREAM ont leurs propres volumes dédiés. Un facteur important à préciser est la taille du tampon utilisé par le protocole SMB pour la mise en mémoire tampon des lectures de données FILESTREAM. Dans le test avec le système d'exploitation Windows Server® 2003, les mémoires tampons de plus grande taille sont susceptibles d'obtenir un meilleur débit, avec des tailles de mémoire tampon d'un multiple de 60 Ko. De plus grandes tailles de mémoire tampon peuvent être plus efficaces sur d'autres systèmes d'exploitation. Il existe des éléments supplémentaires à prendre en compte lors de la comparaison d'une charge de travail FILESTREAM par rapport à d'autres options de stockage (une fois la charge de travail FILESTREAM paramétrée) : Vérifiez que le matériel de stockage et le niveau RAID est identique pour les deux. Vérifiez que le paramètre de compression de volume est identique pour les deux. Notez si FILESTREAM effectue la double écriture en fonction de l'API utilisée et des options spécifiées. Considérations relatives à la migration des données Un scénario courant avec SQL Server 2008 est la migration des données BLOB existantes dans le stockage FILESTREAM. Alors que la mise à disposition d'un outil ou d'un ensemble de codes complet pour effectuer ces migrations dépasse l'objet de ce livre blanc, voici un exemple simple de flux de travail à suivre : 34 Passez en revue les considérations de taille des données avec FILESTREAM pour vérifier que la taille moyenne des données impliquées est telle que le stockage FILESTREAM est approprié. Vérifiez les informations disponibles sur les combinaisons de fonctionnalités et sur les limitations pour vous assurer que le stockage FILESTREAM fonctionne avec toutes les autres spécifications de l'application. Suivez les recommandations de la section « Considérations relatives à l'optimisation des performances et aux tests » plus haut. Vérifiez que l'instance SQL Server utilise la sécurité intégrée et que FILESTREAM est activé aux niveaux Windows et SQL Server. Assurez-vous que l'emplacement cible du conteneur de données FILESTREAM dispose de suffisamment d'espace disque pour stocker les données BLOB migrées. Créez les groupes de fichiers FILESTREAM requis. Dupliquez les schémas de table impliqués, en modifiant les colonnes BLOB requises de façon à ce qu'elles soient des colonnes FILESTREAM. Migrez toutes les données de type non blob vers le nouveau schéma. Migrez toutes les données BLOB dans les nouvelles colonnes FILESTREAM. Meilleures pratiques pour l'utilisation de FILESTREAM Cette section regroupe les recommandations qui ont émergé de l'utilisation de FILESTREAM au cours des tests internes et publics de la version préliminaire de la fonctionnalité. Comme avec toutes les recommandations, ce sont des considérations d'ordre général et il est possible qu'elles ne s'appliquent pas à toutes les situations et tous les scénarios. Voici les meilleures pratiques, sans ordre spécifique : Évitez si possible les petits ajouts dans un fichier FILESTREAM, car chaque ajout crée un fichier FILESTREAM. Cela peut s'avérer très gourmand en ressources pour les fichiers FILESTREAM volumineux. Si possible, regroupez plusieurs ajouts dans une colonne varbinary (max), puis dans la colonne FILESTREAM lorsqu'un seuil de taille est atteint. Avec une forte charge de travail d'écriture multithread, envisagez de définir le paramètre AllocationSize des API OpenSqlFilestream ou SqlFilestream. Les tailles supérieures initiales d'allocation limiteront le risque de fragmentation au niveau du système de fichiers, surtout lorsqu'elles sont associées à une taille de clusters NTFS comme décrit précédemment. Si les fichiers FILESTREAM sont volumineux, évitez les mises à jour Transact-SQL qui ajoutent des données dans un fichier. Cela met (généralement) les données en attente danstempdb et dans un nouveau fichier physique, ce qui affecte les performances. Lorsque vous lisez une valeur FILESTREAM, considérez les éléments suivants : o Si les lectures requièrent uniquement la lecture des premiers octets, prenez en compte la fonctionnalité de sous-chaîne. o Si le fichier complet doit être lu, pensez à l'accès Win32. o Si des parties aléatoires du fichier doivent être lues, envisagez d'ouvrir le descripteur de fichier avec SetFilePointer. o Lors de la lecture d'un fichier complet, spécifiez l'indicateur FILE_SEQUENTIAL_ONLY. o Utilisez des tailles de mémoire tampon qui sont des multiples de 60 Ko (comme décrit plus haut). La taille d'un fichier FILESTREAM peut être obtenue sans avoir à ouvrir un descripteur de fichier en ajoutant une colonne calculée persistante à la table qui stocke la taille de fichier FILESTREAM. La colonne calculée est mise à jour lorsque le fichier est déjà ouvert pour les opérations d'écriture. Conclusion Ce livre blanc a décrit la fonctionnalité FILESTREAM de SQL Server 2008, qui permet le stockage et l'accès aux données BLOB en associant SQL Server 2008 et le système de fichiers NTFS. Pour conclure, il utile de rappeler les principaux points examinés dans ce document. Le stockage FILESTREAM n'est pas approprié dans tous les cas. Selon une étude précédente et le comportement de la fonctionnalité FILESTREAM, les données BLOB d'une taille de 1 Mo et supérieure qui ne sont pas accessibles via Transact-SQL sont mieux adaptées au stockage des données FILESTREAM. Vous devez également tenir compte de la charge de travail de mise à jour, car toute mise à jour partielle d'un fichier FILESTREAM génère une copie complète des fichiers. Avec une charge de travail de mise à jour particulièrement importante, les performances peuvent être telles que FILESTREAM n'est pas approprié. 35 Les détails des combinaisons de fonctionnalités doivent être étudiés pour garantir la réussite du déploiement. Par exemple, dans SQL Server 2008 version finale, la mise en miroir de bases de données ne peut pas s'appliquer à des données FILESTREAM utilisées, ni à une version de l'isolement d'instantané. La plupart des autres combinaisons de fonctionnalités sont prises en charge, mais d'autres peuvent présenter des limitations (telles que la réplication). Ce livre blanc ne fournit pas une taxonomie exhaustive des fonctionnalités et de leur interaction. Consultez les sections les plus récentes de la Documentation en ligne de SQL Server avant le déploiement, plus particulièrement car certaines limitations sont susceptibles d'être soulevées dans les versions ultérieures. Enfin, si FILESTREAM est déployé sans configurer Windows et SQL Server correctement, les niveaux de performances anticipés peuvent ne pas être atteints. Les recommandations et les détails de configuration décrits ci-dessus doivent être utilisés pour éviter les problèmes de performances. Pour plus d'informations : http://www.microsoft.com/sqlserver/ : Site Web SQL Server http://technet.microsoft.com/fr-fr/sqlserver/ : TechCenter SQL Server http://msdn.microsoft.com/fr-fr/sqlserver/ : Centre de développement SQL Server Avez-vous trouvé ce document utile ? Nous apprécions vos commentaires. Sur une échelle de 1 (faible) à 5 (excellent), quelle note donneriez-vous à ce document ? Expliquez pourquoi. Par exemple : Avez-vous attribué une bonne note car le document fournit de bons exemples, contient des captures d'écran très utiles, est clairement rédigé, ou pour d'autres raisons ? Avez-vous attribué une mauvaise note car le document fournit de mauvais exemples, contient des captures d'écran pas claires ou est mal rédigé ? Vos commentaires nous aident à améliorer la qualité des livres blancs que nous publions. Envoyez vos commentaires. 36
