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.
télécharger 194.54 Kb.
|
Présentation de FILESTREAMFILESTREAM 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. 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 BLOBUne 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 :
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). 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). 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. |
similaire:
 | | «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | |
 | | «Système de gestion de base de données relationnelles» dont le moteur de base de données est sql server | |
| «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | | |
| | ||
| |