Facteurs clés à prendre en compte lors de l'évaluation des systèmes de cache de fichiers tiers avec SQL Server

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 917043
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Résumé
Cet article présente certains des facteurs clés, les clients doivent être conscients lors de l'évaluation d'un fichier tiers la mise en cache système.

Les implémentations de cache fichier tiers peuvent augmenter les performances des bases de données Microsoft SQL Server lors de la mise en œuvre correcte. Toutefois, les implémentations spécifiques et les configurations de ces produits peuvent laisser des bases de données SQL Server à un risque élevé de perte de données. Les clients doivent tester totalement la configuration pour vous assurer de l'intégrité des données appropriés.

Informations dans ce document, y compris les URL et autres références à des sites Web Internet, sont sujettes à modification sans préavis. Sauf mention contraire, les sociétés, organisations, produits, noms de domaine, adresses électroniques, logos, personnes, lieux et événements mentionnés dans les exemples sont fictifs. Aucune association avec n'importe quel société, organisation, produit, nom de domaine, adresse de messagerie, logo, personne, lieu ou événement est destinée ou peut être déduite. Respecter toutes les lois sur le copyright applicables est la responsabilité de l'utilisateur. Aucune partie de ce document peut être reproduite ou transmise sous quelque forme ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou à toute fin, sans la permission expresse et écrite de Microsoft Corporation.

Microsoft peut avoir des brevets, brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle couvrant un sujet dans ce document. Sauf disposition expressément stipulée dans un contrat de licence écrit de Microsoft, la fourniture de ce document non permet de vous concéder une licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.

© 2006 Microsoft Corporation. Tous droits réservés.

Microsoft, Windows, Windows Server et SQL Server sont soit des marques déposées ou des marques déposées de Microsoft Corporation aux États-Unis et/ou dans d'autres pays.

Cet article est écrit spécifiquement pour SQL Server, mais s'applique généralement aux bases de données Jet utilisés par ainsi que des produits de Active Directory et Exchange Server.
Plus d'informations
Cette section décrit les exigences et fournit des exemples détaillés qui doivent être complètement décrites avec un fournisseur tiers avant de déployer une solution. Les clients doivent également prendre soin de tester différents scénarios de restauration pour vous assurer que l'intégrité des données sont correctement gérée.

Exigences d'entrée/sortie (e/s) de SQL Server

N'importe quel fichier de sauvegarde ou de la base de données SQL Server nécessite des principes de base de stockage prenant en charge le protocole Write-Ahead Logging (WAL). Ces principes sont décrits dans les articles suivants :
Notions de base d'e/s de SQL Server 2000
http://technet.Microsoft.com/en-us/library/cc966500.aspx
Remarque L'article s'applique également à SQL Server 2005 et versions ultérieures.
230785 La journalisation SQL Server 7.0, SQL Server 2000 et SQL Server 2005 et des algorithmes de stockage étendent la fiabilité des données
Voici une liste de certaines conditions :
  • Ordre d'écriture doit être maintenue.
  • Cohérence des écritures dépendantes doit être maintenue.
  • Écritures doivent toujours être sécurisés dans ou sur stablemedia.
  • Déchirée prévention d'e/s doit se produire.

Certifications de produits partenaires ne sont pas une garantie de la sécurité et la compatibilité

Un produit tiers ou un fournisseur particulier peut recevoir un logo de certification Microsoft. Toutefois, certification partenaire ou un logo de Microsoft spécifique ne certifie pas la compatibilité ou l'adéquation à un usage particulier pour SQL Server, Exchange Server ou Active Directory.

FILE_FLAG_WRITETHROUGH et FILE_FLAG_NO_BUFFERING

Produits de base de données Microsoft spécifiquement utilisent l'écriture continue et aucun indicateur de mise en mémoire tampon lors de l'ouverture des fichiers de base de données pour éviter toute perte de données. Toute demande d'écriture sur ces fichiers doit être sécurisé sur un support stable. Dans le cas contraire, perte de données peut se produire. Vous trouverez ci-dessous des exemples spécifiques qui peuvent exposer des caches de système de fichiers :
  • Combinaison d'écriture et écriture réorganisation
    Pour réduire les demandes d'e/s physiques, les caches de base hors batteries souvent combinent et réorganiser les opérations d'écriture, les exigences du protocole WAL immédiatement à la rupture.
  • Taille du bloc d'e/s
    Semblable à l'écriture de la combinaison et la réorganisation des sont de taille de bloc d'e/s. Les caches tentera d'effectuer des e/s basée sur la taille de bloc du chemin d'e/s. Là encore, peut fournir une amélioration des performances mais s'ouvre la base de données aux dommages et interrompt immédiatement les exigences du protocole WAL.

Exemples et points de discussion

La section suivante fournit des exemples de clés et points de discussion relatifs à la sécurité et l'intégrité des données. Il utilise coupure sous la forme d'un point commun de défaillance et de clarté, mais cela peut souvent être remplacé avec divers autres problèmes menant à des problèmes d'intégrité de base de données similaires.

Exemple 1: Perte de données et les altérations physiques ou logiques

Considérez le scénario suivant :
  1. Un enregistrement de journal est écrit pour la page 100 dans la base de données.
  2. Un enregistrement de journal est maintenu dans le cache non basé sur batterie, mais que le moteur de base de données est signalé à que l'écriture de journal est « sécurisé pour stable media » complète.
  3. Le moteur de base de données considère que le LSN renforcé et problèmes d'écriture pour la page 100.
  4. Page 100 est également conservé dans cache en fonction de non-batterie.
  5. COMMIT transaction se termine sans erreur.
Le moteur de base de données continue le traitement comme si elle été validée avec succès les opérations d'écriture sur un support stable. Une panne de courant à ce stade, toutefois, provoque perte immédiate des données, car les modifications existaient jamais physiquement à l'extérieur du cache sauvegardé batterie non. Récupération après incident n'indique pas une erreur, car la récupération sur incident ne connaît pas l'enregistrement du journal perdues et ne tentera pas de recommencer. Plusieurs scénarios de modification d'objet (clé primaire, par exemple, les insertions de clé étrangères) développent les différents types de dommages de base de données qui peuvent se produire.

Il existe plusieurs autres problèmes qui pourraient se poser avec des modifications mineures apportées à la manière dont le cache gère les e/s. Une dérivation brève suppose que la transaction a été restaurée, mais media page 100 apportée physique. Récupération après incident à nouveau ne connaît pas l'enregistrement du journal (jamais créé pour stable media), page 100 permettra de ne pas recevoir des opérations d'annulation au cours de la récupération après incident, en laissant la base de données logiquement et physiquement éventuellement endommagé.

Exemple 2: La base de données suspecte

Certains fournisseurs permettent de « opt plus de fichiers » et est souvent recommandé de laisser le fichier journal (.ldf pour SQL Server) a choisi le cache. La stratégie « opt out » est telle que l'administrateur a spécifiquement marquer les fichiers ignorés par le logiciel de mise en cache. Dans le cas contraire, le fichier est automatiquement inclus.

Il s'agit d'une hypothèse médiocre, comme le suivant met en évidence. Microsoft vous recommande de toutes les bases de données et les fichiers de sauvegarde est choisi de renoncer à une telle mémoire cache.
  1. Le fichier journal est choisi, afin d'obtenir des écritures sur un support stable.
  2. Page 100 est modifié.
  3. Le moteur de base de données exécute une opération de point de contrôle.
  4. Le moteur est signalé à toutes les pages de la base de données et les enregistrements de journal sont sécurisés (point dans le temps jusqu'à considéré comme un point de contrôle renforcé). Toutefois, les pages de données ne sont pas toutes stockées sur ou dans les milieux stable.
  5. La base de données SQL Server est en mode de récupération « SIMPLE », sorte de checkpoint tronque maintenant les enregistrements du journal.
  6. 100 page qui était juste à cocher pointé est à nouveau modifié.
Cette situation a exposé à la base de données à une perte de données et se traduit généralement par une base de données suspecte. Encore une fois, si une panne de courant a lieu, récupération sur incident n'a aucun enregistrement de journal car ils n'existent plus en raison d'une troncation. Le moteur de base de données ne comporte aucune information indiquant que les pages de base de données sont manquantes qui devraient être sécurisées pendant le point de contrôle. Récupération sur incident tente d'analyser la seconde modification de page 100 mais échoue parce que la page 100 n'était pas correctement sécurisé sur un support stable au moment du point de contrôle.

Récupération sur incident utilise la valeur LSN stockée dans l'en-tête de page afin de déterminer les besoins de récupération.
  • Si le numéro LSN de la page est égal à ou plus récente que celle de l'enregistrement du journal, récupération n'aucun travail supplémentaire sur la page car la page est déjà cohérente avec l'enregistrement du journal basé sur la comparaison LSN.
  • Si le numéro LSN de la page est plus anciens que celle de l'enregistrement du journal, les besoins de récupération effectuer les opérations appropriées pour retourner la page à l'état correct. Échec de la récupération si la récupération a permis de découvrir une condition de données manquants et ne peut pas retourner correctement la page à son état légitime.
À partir de l'exemple, le LSN précédent stocké dans l'enregistrement de journal pour la deuxième modification de la page 100 n'existe pas dans l'en-tête de page, et il n'y a aucun enregistrement de journal précédente pour rétablir la page. Par conséquent, la base de données est marquée comme suspecte, comme la récupération ne peut pas continuer en toute sécurité.

Exemple 3: Sauvegardes ne sont pas valides - saut de la chaîne de sauvegarde en mode silencieux

Exemple 2 est qu'une fraction de ces types de problèmes qui ont peuvent être connus. Pour cet exemple, au lieu du mode de restauration « SIMPLE », nous mettre la base de données en mode « Récupération complète » mais effectuer des sauvegardes régulières des journaux et de base de données. Dans un premier temps, il apparaît que ce serait plus efficace car vous disposez d'une chaîne de journaux intacte et il vous suffit d'exécuter une séquence de restauration pour corriger le problème.

Cela est une hypothèse valide, que certaines implémentations de cache utilisent la stratégie « opt out » afin que le fichier de sauvegarde ou de la partie peut être inattendu mis en cache. Lorsque SQL Server vide le fichier de sauvegarde, SQL Server requiert que toutes les écritures sur le support de sauvegarde sont stockées correctement sur ou dans les milieux stable à l'aide de la fonction API Win32 FlushFileBuffers . Par conséquent, si le fournisseur de cache n'assure pas de toutes les écritures sont vidées correctement, lors de l'appel de fonction FlushFileBuffers , stable media avant que l'opération se termine correctement, la base de données engine peut tronquer le journal sans une sauvegarde sécurisée. Là encore, une panne de courant provoque à ce stade une condition dans laquelle les enregistrements du journal approprié sont manquants et peuvent provoquer l'échec de la restauration de blocage. Le plus important est que la récupération sur incident n'est peut-être pas en mesure de détecter ce fait les enregistrements du journal manquant dans la base de données et la chaîne de sauvegarde est endommagée en mode silencieux. Uniquement lors de la tentative de restauration de la sauvegarde du moteur de base de données sera en mesure d'indiquer que la sauvegarde a été endommagée.

Exemple 4: Les États de base de données non valide

Les fichiers de base de données contiennent des dépendances entre eux nécessitant une écriture via strict et l'ordre de la conformité à appliquer à tous les éléments en tant que groupe. Point de contrôle, les changements de taille de fichier, les sauvegardes différentielles, opérations non journalisées et le mode de récupération BULK LOGGED sont parmi les quelques unes des activités clés de la base de données qui requièrent l'écriture par le biais de se pour produire sur les fichiers de données, rendre des stratégies telles qu'opt-out uniquement dans le fichier journal une hypothèse non valide.

Exemple 5: Perte de données de base de données de Snapshot – peut être en mode silencieux

SQL Server 2005 introduit des bases de données de capture instantanée pour un point dans le temps. Il utilise la technologie de copie à l'écriture de base de données pour aider à sécuriser une copie d'une page de données dans la base de données de capture instantanée avant une nouvelle modification est apportée à la page de données dans la base de données de. Ce processus requiert que la page soit sécurisé dans la base de données de capture instantanée avant que la transaction puisse se poursuivre. Si la page n'est pas sécurisée sur ou dans les milieux stable, problèmes d'intégrité des données seront persistante. La base de données de capture instantanée ne contient-elle pas un journal de transactions, afin que l'écriture de la page est critique. Si quelque chose comme une panne de courant a eu lieu, il peut être possible que la page principale de la base de données a été modifiée mais que la capture instantanée ne reflète pas l'image précédente, car l'écriture en cache a été perdue.

Comment faire pour configurer

Comment faire pour configurer un produit fournissant le cache des fichiers à partir de quelque chose comme non-batterie de secours cache est spécifique à l'implémentation de fournisseur. Quelques règles, cependant, peuvent être appliquées :
  • Toutes les écritures doivent être terminées dans ou sur un support stable avant le cache indique au système d'exploitation que l'e/s est terminée.
  • Données peuvent être mise en cache tant qu'une demande de lecture pris en charge à partir du cache renvoie la même image comme se trouvant dans ou sur un support stable.
Essentiellement, ces règles signifient que le cache sauvegardé batterie non efficace pour les opérations de lecture, mais ne doit pas être utilisé pour les requêtes d'écriture. Avec la configuration appropriée, il peut fournir un gain de performance pour le moteur de base de données. Cela devrait, toutefois, être testées avec soin, car consacrant quelque chose comme RAM qui pourrait être utilisé par SQL Server peut dégrader les performances globales. SQL Server peut être en mesure d'utiliser la mémoire supplémentaire avec plus de précision qu'un mécanisme de cache générique.

Bases de données en lecture seule

Bases de données en lecture seule peuvent être un bon exemple dans lequel excel ces types de produits. Si la base de données a été tout d'abord créé et stocké sur ou dans les milieux stable afin de garantir l'intégrité des données, l'instruction ALTER DATABASE permet de marquer la base de données en lecture seule et la base de données affectées par la suite au mécanisme de mise en cache, des gains de performances peuvent être rencontrées. Certaines implémentations de conserver les images compressées des pages de base de données dans le cache, les données physiques supplémentaires doivent être extraites du cache et de réduire les e/s physiques.

Attention La base de données ne doit jamais être faite lecture et écriture lorsque affecté à un cache qui ne pas respecter le protocole WAL.

Sécurité

Introduction d'un cache, tels que le cache du système de fichiers basé sur la mémoire vive, introduit un autre emplacement « en mémoire » pour les données. Produits comme un moteur de base de données peuvent assumer les données critiques ont été stockées dans ou sur un support stable et conservent correctement les protections de l'accès contrôle liste (ACL). Le cache de mémoire vive pourrait exposer les données à un ensemble de problèmes de sécurité sont uniques par rapport aux médias stable. Par exemple, si l'application est conçue pour utiliser quelque chose comme la fonction SecureZeroMemory chaque fois qu'il a fini d'utiliser les informations critiques, l'application a attend que les données n'existent plus dans la mémoire vive. Toutefois, si un formulaire de données peut rester en mémoire cache lorsque l'application attendue dans ou sur un support stable, il pourrait modifier les considérations de sécurité.

Vérifications de l'intégrité des données

Microsoft recommande d'utiliser une stratégie de l'intégrité des données fort et clair. Cela doit inclure, mais n'est pas limitée à, la restauration des sauvegardes et des opérations régulières de DBCC CHECKDB sur la production et de la base de données restaurée.

Microsoft vous recommande également d'augmenter la fréquence de ces essais de sécurité lors de l'évaluation et la mise en oeuvre des modifications apportées à l'environnement ou si des problèmes se posent concernant la stabilité de l'environnement.

Pour plus d'informations sur l'utilisation de l'utilitaire SQLIOStress, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
231619 Comment faire pour utiliser l'utilitaire SQLIOStress à souligner un sous-système de disque tel que SQL Server

La base de données TEMPDB

Il est possible de localiser la base de données TEMPDB sur certains systèmes de mise en cache. Plusieurs facteurs doivent être considéré comme avec soin et testés lors de l'évaluation de l'emplacement de stockage de la base de données TEMPDB dans cette configuration. L'article suivant de la Base de connaissances Microsoft décrit les exigences d'e/s, des limites de support associés et des gains de performance possibles.
917047 Exigences en matière de sous-système d'e/s de Microsoft SQL Server pour la base de données TEMPDB

Prise en charge

Prise en charge de Microsoft SQL Server va aider les clients, à l'aide de techniques de récupération de données standard. Si les produits installés sur le dessin ordinateur l'intégrité des données en question, Microsoft SQL Server, Active Directory et prise en charge d'Exchange peuvent demander que le produit est désinstallé et ne pas avoir d'analyse des causes premières jusqu'à ce le problème peut être reproduit sans dudit produit.

Microsoft ne certifie ni valider que des produits tiers fonctionnent correctement avec SQL Server. En outre, Microsoft ne fournit pas toute garantie, garantie ou déclaration d'adéquation de tout produit tiers pour une utilisation avec SQL Server.
Références
Étudiez attentivement les informations supplémentaires fournies par les références suivantes pour évaluer l'amélioration des performances de SQL Server :

826433 Diagnostics SQL Server supplémentaires ajoutés pour détecter des problèmes d'e/s non signalés
828339 Message d'erreur 823 peut indiquer des problèmes de matériel ou système dans SQL Server
234656 À l'aide de la mise en cache du lecteur de disque avec SQL Server
304261 Description de la prise en charge pour les fichiers de base de données réseau dans SQL Server
910716 Prise en charge des solutions de mise en miroir à distance tiers utilisé avec SQL Server 2000 et 2005 bases de données utilisateur
913945Microsoft ne certifie pas que des produits tiers fonctionneront avec Microsoft SQL Server
Optimisation de votre requête Plans avec le SQL Server estimation de cardinalité 2014

Performances des requêtes

SQL Server nécessite des systèmes pour prendre en charge des « remise garantie sur un support stable » comme indiqué sous le MConditions du programme fiabilité d'e/s de SQL Server.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

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 917043 - Dernière mise à jour : 12/09/2015 05:15:09 - Révision : 3.0

Microsoft SQL Server 7.0 Standard, Microsoft SQL Server 2000 Standard, Microsoft SQL Server 2000 Édition Entreprise, Microsoft SQL Server 2000 Édition Développeur, Microsoft SQL Server 2000 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Édition Personelle, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Analysis Services, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Express with Advanced Services, Microsoft SQL Server 2008 R2 Parallel Data Warehouse, Microsoft SQL Server 2008 R2 Reporting Services, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Standard Edition for Small Business, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2012 Analysis Services, Microsoft SQL Server 2012 Business Intelligence, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, SQL Server 2012 Enterprise Core, SQL Server 2012 Reporting Services, Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web, SQL Server 2014 Reporting Services

  • kbnosurvey kbarchive kbexpertiseadvanced kbinfo kbmt KB917043 KbMtfr
Commentaires