Description de la prise en charge des fichiers de base de données réseau dans SQL Server

Microsoft recommande généralement d'utiliser un réseau SAN (Storage Area) ou un disque connecté localement pour le stockage de vos fichiers de base de données Microsoft SQL Server, car cette configuration optimise les performances de SQL Server et de fiabilité. Par défaut, l'utilisation de fichiers de base de données réseau (stockés sur un serveur réseau ou un stockage rattaché au réseau [NAS]) n'est pas activée pour SQL Server.

Toutefois, vous pouvez configurer SQL Server pour stocker une base de données sur un serveur réseau ou un serveur de stockage NAS. Les serveurs utilisés à cet effet doivent répondre aux exigences SQL Server classement des écritures de données et write through garanties, lesquels sont détaillés dans la section « Informations complémentaires ».

Périphériques WHQL Windows Hardware Quality Lab () qualifié

Serveurs Microsoft Windows et les serveurs réseau ou les serveurs de stockage NAS WHQL Windows Hardware Quality Lab () certifiés automatiquement répondent à l'ordre d'écriture données et write through garanties requises pour prendre en charge un périphérique de stockage SQL Server. Microsoft prend en charge les applications et les problèmes liés au stockage dans ces configurations.

RemarquePour être pris en charge par SQL Server, la solution de stockage NAS doit également satisfaire aux prescriptions qui figurent sur le site Web Microsoft suivant :

Autres périphériques

Si vous utilisez un périphérique de stockage qualifiés non WHQL avec SQL Server qui prend en charge les garanties d'e/S pour une utilisation de base de données transactionnelle décrite dans cet article, Microsoft fournira une prise en charge complète pour les applications SQL Server et SQL Server. Toutefois, les problèmes avec, ou dus, le périphérique ou au sous-système de stockage sera désigné pour le fabricant du périphérique. Si vous utilisez un périphérique de stockage qualifiés non WHQL ne prend pas en charge les garanties d'e/S pour une utilisation de base de données transactionnelle décrite dans cet article, Microsoft ne peut pas fournir de prise en charge des applications SQL Server ou SQL Server. Pour déterminer si votre WHQL-non qualifié stockage périphérique prend en charge les e/S garanties pour l'utilisation de base de données transactionnelle décrite dans cet article et/ou est conçu pour une utilisation de la base de données, vérifiez auprès de votre fournisseur de périphérique. En outre, contactez votre fournisseur de périphérique pour vérifier que vous avez correctement déployé et configuré le périphérique pour une utilisation de la base de données transactionnelle.

Par défaut, vous ne pouvez pas créer une base de SQL Server sur un partage de fichiers réseau. Si vous tentez de créer un fichier de base de données sur un mappé ou un emplacement réseau UNC génère un des messages d'erreur suivants :

Message d'erreur 1
Message d'erreur 2
Ce comportement est normal. Indicateur de trace 1807 ignore la vérification et permet de configurer les SQL Server avec des fichiers de base de données basée sur le réseau. SQL Server et la plupart des autres systèmes de base de données d'entreprise, emploient un journal des transactions et la logique de récupération associée pour garantir la cohérence transactionnelle de la base de données en cas de défaillance du système ou une fermeture non gérée. Ces protocoles de récupération s'appuient sur la possibilité d'écrire directement sur le média disque afin que lorsqu'une système d'exploitation d'entrée/sortie (e/S) demande d'écriture renvoie au Gestionnaire de base de données, le système de récupération est garanti que l'écriture est réellement terminée ou que l'exécution de l'écriture peut être garantie. Tout manquement par n'importe quel composant logiciel ou matériel à honorer ce protocole peut entraîner une perte partielle ou totale des données ou la corruption en cas de défaillance du système. Pour plus de détails sur ces aspects d'enregistrement et de récupération de protocoles dans SQL Server, reportez-vous à l'article suivant dans la Base de connaissances Microsoft :Microsoft ne gère pas les fichiers de base de données SQL Server en réseau NAS ou des serveurs de stockage en réseau qui ne répondent pas à ces exigences write through et ordre d'écriture.

En raison des risques d'erreurs réseau compromettant l'intégrité de base de données, ainsi que les conséquences de performance possibles qui peuvent résulter de l'utilisation de partages de fichiers réseau pour stocker des bases de données, Microsoft vous recommande de stocker les fichiers de base de données sur des sous-systèmes de disque local ou sur les réseaux de stockage (SAN).

Un système de stockage (NAS) connectés au réseau est un système de stockage de fichier de base de clients joignent par le redirecteur réseau en utilisant un protocole réseau (tel que TCP/IP). Si l'accès à une ressource de disque requiert qu'un partage soit mappé ou si la ressource de disque apparaît comme un serveur distant via un chemin d'accès UNC (par exemple, \\NomServeur\NomPartage) sur le réseau, puis par défaut, le système de stockage de disque n'est pas pris en charge en tant qu'emplacement pour les bases de données SQL Server.

Problèmes de performances

SQL Server, similaires aux autres systèmes de base de données d'entreprise peut placer une charge importante sur un sous-système d'e/S. Dans la plupart des grandes applications de base de données, physique configuration d'e/S et le réglage jouent un rôle important dans les performances globales du système. Il existe trois principaux facteurs de performances d'e/S à prendre en considération :

• La bande passante d'e/S: la bande passante, généralement exprimée en mégaoctets par seconde qui peut être maintenue à une unité de base de données
• Latence d'e/S: la latence, généralement exprimée en millisecondes, entre une demande d'e/S par le système de base de données et le point où la demande d'e/S est terminée.
• Coût UC: le coût du processeur central hôte, généralement exprimé en microsecondes UC, pour le système de base de données effectuer une seule e/S

Chacun de ces facteurs d'e/S peut devenir un goulet d'étranglement et vous devez prendre en compte tous ces facteurs lorsque vous concevez un système d'e/S pour une application de base de données.

Dans sa forme la plus simple, une solution NAS utilise une pile logicielle du redirecteur réseau standard, carte d'interface réseau standard (NIC) et des composants Ethernet standard. L'inconvénient de cette configuration est que toutes les e/S de fichier est traité par le biais de la pile réseau et est soumis aux limitations de bande passante du réseau lui-même. Cela peut créer des performances et des problèmes de fiabilité de données, surtout dans les programmes qui nécessitent des niveaux extrêmement élevés de fichier e/S, tel que SQL Server. Dans certaines configurations NAS testées par Microsoft, le débit d'e/S était environ un tiers (1/3) direct attaché solution de stockage sur le même serveur. Dans cette même configuration, le coût UC pour effectuer une e/S par le périphérique NAS était environ deux fois plus que d'une e/S locale. Comme les périphériques NAS et l'infrastructure réseau évoluent, ces rapports peuvent également améliorer par rapport au stockage en attachement direct ou SAN. En outre, si vos données d'application sont principalement mis en cache dans le pool de tampons de base de données et ne pas rencontrer tous les goulots d'étranglement d'e/S décrites, performances sur un système basé sur NAS sont probablement suffisante pour votre application.

Considérations relatives à la sauvegarde et restauration

SQL Server fournit le Virtual Device Interface (VDI) pour la sauvegarde. Virtual Device Interface fournit des éditeurs de logiciels de sauvegarde avec un moyen hautes performances, évolutif et fiable pour effectuer des sauvegardes à chaud et de restauration des bases de données SQL Server.

Logiciel de sauvegarde fonctionne sur les fichiers de base de données stockés sur les périphériques NAS via l'interface VDI sans prise en charge spéciale spécifique au NAS. Toutefois, cela entraîne une grande quantité de trafic réseau supplémentaire pendant la sauvegarde et restauration. Lors de la sauvegarde via l'interface VDI, SQL Server lit les fichiers à distance et transmet les données pour le logiciel de sauvegarde tiers est en cours d'exécution sur l'ordinateur SQL Server. L'opération de restauration est analogue.

Pour éviter le réseau supplémentaire surcharge, le fournisseur de sauvegarde doit fournir un support NAS spécifique par le fournisseur de sauvegarde et le fournisseur NAS. SQL Server VDI permet au logiciel de sauvegarde tirer parti du matériel (miroir scindé) ou pris en charge par les périphériques NAS pour effectuer des copies rapides des fichiers de base de données local pour le NAS des technologies logicielles (copy on write). Ces technologies éviter non seulement la surcharge de copie des fichiers sur le réseau pour la sauvegarde, ils peuvent également réduire les temps par ordres de grandeur.

Les sauvegardes sont stockées sur NAS sont vulnérables aux mêmes défaillances affecte les fichiers de base de données qui sont stockés sur le serveur NAS. Vous devez envisager de protéger ces sauvegardes en les copiant dans un autre média.

Attention :Vous pouvez rencontrer une corruption de base de données dans la sauvegarde si vous utilisez les technologies de sauvegarde NAS sans prise en charge SQL Server VDI. Ce type de corruption comprend les pages déchirées ou incohérences entre les fichiers journaux et de données si elles sont stockées sur des périphériques distincts. SQL Server peut ne pas détecter les pages déchirées ou incohérences jusqu'à ce que vous restaurez la base de données et accéder aux données endommagées. Microsoft ne prend pas en charge l'utilisation des technologies de sauvegarde NAS qui ne sont pas coordonnés avec SQL Server.

Support de sauvegarde et de fournisseur NAS prend en charge pour SQL Server VDI varie. Vérifiez avec votre NAS et les fournisseurs de logiciels de sauvegarde pour plus d'informations concernant le support VDI.

Microsoft recommande aux clients qui envisagent un déploiement d'une solution NAS pour consulter leur fournisseur NAS pour vous assurer que la conception de la solution de bout en bout pour la base de données utilisent des bases de données SQL Server. De nombreux fournisseurs NAS ont des guides des meilleures pratiques et les configurations homologuées pour cet usage. Microsoft recommande également que les clients évaluent leurs performances d'e/S pour s'assurer qu'aucun des facteurs d'e/S mentionnés précédemment ne provoque un goulot d'étranglement dans leur application.

Le texte qui suit décrit le comportement des fichiers de base de données réseau sur Microsoft SQL Server 2005, Microsoft SQL Server 2000 et Microsoft SQL Server 7.0, avec et sans indicateur de suivi 1807. Syntaxe mappée fait référence à une lettre de lecteur associée à un chemin d'accès réseau par la commande NET USE. Syntaxe UNC se rapporte à une référence directe à un chemin d'accès réseau, tel que \\NomServeur\NomPartage.

• Dans SQL Server 7.0, sans indicateur de trace 1807, si vous utilisez la syntaxe de compatibilité descendante DISK INIT suivie par une instruction CREATE DATABASE avec soit mappé ou UNC, erreur 5105 se produit.
• Dans SQL Server 7.0, avec l'indicateur de trace 1807, si vous utilisez la syntaxe DISK INIT à compatibilité descendante suivie par une instruction CREATE DATABASE avec une syntaxe mappée, la création du fichier réussit. Si vous utilisez DISK INIT avec la syntaxe UNC, erreur 5105 se produit.
• Dans SQL Server 2005, SQL Server 2000 ou 7.0 de SQL Server, sans indicateur de trace 1807, si vous exécutez une instruction CREATE DATABASE avec mappé ou syntaxe UNC, erreur 5105 se produit dans SQL Server 7.0 et erreur 5110 se produit dans SQL Server 2000.
• Dans SQL Server 2005, SQL Server 2000 ou SQL Server 7.0, avec l'indicateur de trace 1807, une instruction CREATE DATABASE qui est effectuée à l'aide de mappé ou la syntaxe UNC est réussie.

Notez que SQL Server fournit une prise en charge uniquement pour les fichiers réseau qui utilisent l'indicateur de trace 1807 pour les installations de basculement en cluster de SQL Server. Basculement des installations en clusters de SQL Server ne fonctionnent pas avec les fichiers réseau car SQL Server 2005 et SQL Server 2000 nécessitent que les périphériques de stockage soient reconnus et enregistrés par l'administrateur de Cluster Microsoft Cluster Service (MSCS).

Remarques supplémentaires

Utilisation incorrecte du logiciel de base de données avec un produit NAS, ou l'utilisation de base de données avec un produit NAS incorrectement configuré, peut entraîner une perte de données, y compris la perte totale de la base de données. Si le logiciel de périphérique ou un réseau NAS ne respecte pas complètement les garanties données, telles que l'ordre d'écriture ou write through puis matériel, logiciel ou de la même puissance échecs pourraient gravement compromettre l'intégrité des données.

RÉFÉRENCES

Pour plus d'informations sur le classement des écritures ou write-through pour SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :SQL Server documentation en ligne ; rubrique: « Indicateurs de Trace »