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

Résumé

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

Toutefois, vous pouvez configurer SQL Server pour stocker une base de données sur un serveur en réseau ou NAS. Les serveurs qui sont utilisés à cet effet doivent répondre aux exigences de SQL Server pour le classement des écritures de données et les garanties d’écriture. Celles-ci sont détaillées dans la section « Informations complémentaires ».

Les conditions suivantes décrivent l’utilisation de fichiers de base de données de réseau qui sont stockés sur un serveur en réseau ou NAS :

  • Cette utilisation est activée par défaut dans Microsoft SQL Server 2008 R2 et versions ultérieures.

  • Cette utilisation requiert la «-T1807 » indicateur de trace démarrage à travailler dans Microsoft SQL Server 2008 et les versions antérieures. Pour plus d’informations sur la façon d’activer les indicateurs de trace de démarrage, consultez la rubrique suivante de la documentation en ligne de SQL Server :

    À l’aide des Options de démarrage du Service SQL Server

Windows Hardware Quality Lab WHQL qualifié de périphériques

Serveurs Microsoft Windows et les serveurs réseau ou serveurs de stockage NAS sont qualifiés par WHQL Windows Hardware Quality Lab automatiquement respecter l’ordre d’écriture de données et les garanties d’écriture directe requises pour prendre en charge d’un périphérique de stockage de SQL Server. Microsoft prend en charge les applications et les problèmes liés au stockage dans ces configurations.

Remarque Pour être pris en charge par SQL Server, la solution de stockage NAS doit en outre respecter toutes les spécifications sont répertoriées dans le document de transfert suivants :

Conditions du programme de fiabilité SQL Server d’e/s

Autres périphériques

Si vous utilisez un périphérique de stockage de non –-le logo 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 SQL Server et les applications basées sur SQL Server. Toutefois, des problèmes, ou dû, le périphérique ou au sous-système de stockage sera désigné au fabricant du périphérique. Si vous utilisez un périphérique de stockage de non –-le logo WHQL qui 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 de SQL Server ou des applications basées sur SQL Server. Pour déterminer si votre périphérique de stockage de non –-le logo WHQL prend en charge les garanties d’e/s pour une utilisation de base de données transactionnelle qui sont décrits dans cet article ou sont conçus pour une utilisation de 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 base de données transactionnelle.

Plus d'informations

Par défaut, dans SQL Server 2008 et les versions antérieures, Impossible de créer une base de données SQL Server sur un partage de fichier réseau. Toute tentative de créer un fichier de base de données sur un lecteur mappé ou un emplacement réseau UNC génère un des messages d’erreur suivants :

Message d’erreur 1

5105 « erreur d’Activation périphérique »


Message d’erreur 2

5110 « le fichier 'nom_fichier' est sur un périphérique réseau non pris en charge pour les fichiers de base de données. »


Ce comportement est normal. L’indicateur de trace 1807 ignore la vérification et vous permet de configurer SQL Server avec des fichiers de base de données basée sur le réseau. Utilisent SQL Server et la plupart des autres systèmes de base de données d’entreprise, un journal de transactions et une logique de récupération associée pour maintenir la cohérence des transactionnelle de la base de données en cas de défaillance du système ou d’une fermeture non gérée. Ces protocoles de récupération comptent sur la possibilité d’écrire directement sur le support de disque afin que lorsqu’un système d’exploitation d’entrée/sortie et demande d’écriture (e/s) renvoie au Gestionnaire de base de données, le système de récupération peut être sûr que l’écriture est réellement complète ou que l’exécution de l’écriture peut être garantie. Tout en n’importe quel composant logiciel ou matériel à honorer ce protocole peut provoquer une perte de données partielle ou totale ou une altération en cas de défaillance du système. Pour plus d’informations sur ces aspects d’enregistrement et de récupération de protocoles dans SQL Server, cliquez sur le numéro ci-dessous pour accéder à l’article suivant dans la Base de connaissances Microsoft :

Description 230785 des algorithmes de stockage de journalisation et des données qui étendent la fiabilité des données dans SQL ServerMicrosoft ne gère pas les fichiers de base de données SQL Server en réseau NAS ou les serveurs de stockage en réseau qui ne répondent pas à ces exigences à écriture et ordre d’écriture.

En raison des risques d’erreurs réseau compromettant l’intégrité des base de données, ainsi que des conséquences de performance possibles qui peuvent résulter de l’utilisation de partages de fichier réseau pour stocker des bases de données, Microsoft vous recommande de stocker les fichiers de base de données sur les sous-systèmes de disque locaux 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 du fichier de base que les clients joignent par le redirecteur réseau en utilisant un protocole réseau (tel que TCP/IP). Par défaut, 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 par un chemin d’accès UNC (par exemple, \\Servername\Sharename) sur le réseau, le système de stockage de disque n’est pas supporté en tant qu’emplacement pour les bases de données SQL Server.

Problèmes de performances

SQL Server, similaires à d’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 facteurs de performances d’e/s majeurs à prendre en compte :

  • La bande passante : la bande passante globale, mesurée en général en mégaoctets par seconde qui peut être maintenue sur un périphérique 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 requête est terminée

  • Coût de l’UC : le coût de l’UC hôte, mesuré en général 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 de 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é via la pile réseau et est soumis aux limitations de la bande passante du réseau lui-même. Cela peut créer des problèmes de performances et données fiabilité, surtout dans les programmes qui requièrent des niveaux extrêmement élevés d’e/s de fichier telles que SQL Server. Dans certaines configurations NAS testées par Microsoft, le débit d’e/s a été environ un tiers (1/3) direct attaché solution de stockage sur le même serveur. Dans cette même configuration, le coût de l’UC pour réaliser 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 mémoires tampons de base de données et que vous ne rencontrez pas les goulets d’étranglement d’e/s indiqué, les performances sur un système basé sur NAS sont probablement suffisante pour votre application.

Considérations relatives à la sauvegarde et de restauration

SQL Server fournit le Virtual Device Interface (VDI) pour la sauvegarde. L’infrastructure VDI fournit des éditeurs de logiciels de sauvegarde un moyen hautes performances, évolutif et fiable pour effectuer des sauvegardes à chaud et pour restaurer les 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 beaucoup de trafic réseau supplémentaire pendant la sauvegarde et de restauration. Lors de la sauvegarde via l’interface VDI, SQL Server lit les fichiers à distance et transmet les données au logiciel de sauvegarde tiers qui s’exécute sur l’ordinateur SQL Server. L’opération de restauration est similaire.

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

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

Attention Vous pouvez rencontrer une corruption de base de données dans la sauvegarde si vous utilisez des technologies de sauvegarde NAS sans prise en charge de SQL Server VDI. Ce type de corruption inclut les pages déchirées ou des incohérences entre les fichiers journaux et de données s’ils sont stockés 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 à des données endommagées. Microsoft ne prend pas en charge l’utilisation des technologies de sauvegarde NAS qui ne sont pas coordonnées avec SQL Server.

Prise en charge de sauvegarde et le fournisseur NAS prise en charge SQL Server VDI varie. Vérifiez auprès de votre NAS et les fournisseurs de logiciels de sauvegarde pour plus de détails concernant la prise en charge de l’infrastructure VDI.

Microsoft recommande aux clients qui envisagent un déploiement d’une solution NAS pour les bases de données SQL Server de consulter son fournisseur NAS pour s’assurer que la conception de la solution de bout en bout est pour une utilisation de base de données. Nombreux fournisseurs NAS possèdent des guides des meilleures pratiques et configurations certifiées pour cette utilisation. Microsoft recommande également les clients évaluent leurs performances d’e/s pour vous assurer qu’aucun des facteurs d’e/s mentionnés précédemment ne provoque un goulet d’étranglement dans leur application.

La liste suivante 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 qui est 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 \\Servername\Sharename.

  • Dans SQL Server 7.0 sans indicateur de suivi 1807, si vous utilisez la syntaxe DISK INIT à compatibilité ascendante suivie d’une instruction CREATE DATABASE avec soit mappé ou la syntaxe UNC, l’erreur 5105 se produit.

  • Dans SQL Server 7.0 avec l’indicateur de trace 1807, si vous utilisez la syntaxe DISK INIT à compatibilité ascendante suivie d’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, l’erreur 5105 se produit.

  • Dans SQL Server 2005, SQL Server 2000 ou dans SQL Server 7.0, sans indicateur de suivi 1807, si vous exécutez une instruction CREATE DATABASE avec mappé ou syntaxe UNC, l’erreur 5105 se produit dans SQL Server 7.0 et l’erreur 5110 se produit dans SQL Server 2000.

  • Dans SQL Server 2005, SQL Server 2000 ou SQL Server 7.0, avec indicateur de suivi 1807, une instruction de créer une base de données est effectuée à l’aide de mappé ou la syntaxe UNC est réussie.

La liste suivante décrit la prise en charge des fichiers réseau sur des clusters de basculement de SQL :

Remarques supplémentaires

L’utilisation incorrecte des logiciels 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 des pertes de données, y compris la perte de la base de données total. Si le logiciel de périphérique ou un réseau NAS ne respecte pas complètement les garanties données, comme le classement des écritures ou à écriture, puis matériel, des logiciels ou même des pannes d’alimentation peuvent sérieusement endommager l’intégrité des données.

Références

Pour plus d’informations sur l’utilisation de partages réseau pour les bases de données SQL Server, consultez l’article de Blog de moteur de stockage de SQL Server suivant :

Bases de données SQL sur des partages de fichier - il est temps de reconsidérer le scénarioPour plus d’informations sur le classement des écritures ou à écriture pour SQL Server, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :

234656

À l’aide de la mise en cache du lecteur de disque avec SQL Server

Pour plus d’informations sur les indicateurs de trace de SQL Server, consultez la rubrique de la documentation en ligne de SQL Server suivante :

Indicateurs de trace (Transact-SQL)SQL Server nécessite des systèmes pour prendre en charge la « remise garantie sur un support stable » comme indiqué sous le conditions du programme de fiabilité SQL Server d’e/s. Pour plus d’informations sur la configuration d’entrée et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :

967576
Configuration requise de Microsoft SQL Server de base de données moteur d’entrée/sortie

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×