Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

Diagnostics dans SQL Server vous aider à détecter des opérations d'e/s non résolues et bloquées

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: 897284
Résumé
Un système de gestion de base de données (SGBD), tel que SQL Server, s'appuie sur la rapidité du fichier d'entrée et de sortie (e/s) et les opérations. L'un des éléments suivants peut provoquer des opérations d'e/s non résolues ou figées et nuire aux performances et la réactivité de SQL Server :

  • Matériel défectueux
  • Matériel incorrectement
  • Paramètres du microprogramme
  • Les pilotes de filtre
  • Compression
  • Bogues
  • Autres conditions dans le chemin d'accès d'e/s
Ces problèmes peuvent provoquer le comportement suivant se produit :

  • Blocage
  • Contention de verrouillage et les délais d'attente
  • Temps de réponse lent
  • Étirement de limites de ressources
À partir de Microsoft SQL Server 2000 Service Pack 4 (SP4), SQL Server inclut une logique qui permet de détecter bloqué et bloqué des conditions pour les lectures d'e/s et écritures et lectures d'e/s du fichier journal et écrit. Lorsqu'une opération d'e/s est en attente pendant 15 secondes ou plus, SQL Server effectue les étapes suivantes :

  1. Détecte que l'opération a été en attente
  2. Écrit un message d'information dans le journal des erreurs SQL Server

    Le texte du message de journal semblable à la suivante :

    2004-11-11 00:21:25.26 spid1 SQL Server a rencontré 192 occurrence (s) de demandes d'e/s, nécessite plus de 15 secondes pour terminer sur le fichier [E:\SEDATA\stressdb5.ndf] dans la base de données [stressdb] (7). Le handle de fichier de système d'exploitation est 0x00000000000074D4. Le décalage de la plus récente d'e/s longue est : 0x00000000022000 ».

Explication du message d'information

Texte du messageDescription
Nombre > occurrence (s)Le nombre de demandes d'e/s qui ne s'est pas terminé l'opération de lecture ou l'écriture en moins de 15 secondes.
Informations sur les fichiersNom complet du fichier, le nom de la base de données et le numéro d'identification (DBID) de la base de données.
PoignéeLe handle de système d'exploitation du fichier. Vous pouvez utiliser le handle du système d'exploitation avec les débogueurs ou avec d'autres utilitaires pour faciliter le suivi des demandes de paquet (IRP) de demande d'e/s.
DécalageL'offset du dernier bloqué l'opération e/s ou installation de la dernière opération e/s. Vous pouvez utiliser le décalage avec les débogueurs ou avec d'autres utilitaires pour faciliter le suivi des demandes de la Commission de contrôle internationale.

Remarque Lorsque le message d'information est écrit dans le journal des erreurs SQL Server, l'opération d'e/s ne peut plus bloquée ou bloquée.
Ce message d'information indique que la charge en cours peut être confronté à une des conditions suivantes :

  • La charge de travail dépasse les capacités de chemins d'accès e/s.
  • La charge de travail dépasse les capacités du système en cours.
  • Le chemin d'accès d'e/s a logiciel défectueux ; peut-être un microprogramme ou un problème de pilote.
  • Le chemin d'accès d'e/s a des composants matériels ne fonctionne pas correctement.
Pour plus d'informations sur les schémas d'e/s de SQL Server 2000, reportez-vous au site Web de Microsoft suivant :Remarque Cet article TechNet s'applique également à Microsoft SQL Server 2005 et versions ultérieures.
Plus d'informations

E/s bloqué et e/s non résolue

E/s coincé

E/s coincé est défini comme une demande d'e/s qui ne se termine pas. Fréquemment, les e/s coincé indique une IRP coincée. Pour résoudre une condition d'e/s coincée, vous devez en général redémarrer l'ordinateur ou effectuer une action semblable. Une condition d'e/s coincée indique généralement une des opérations suivantes :

  • Matériel défectueux
  • Un bogue dans un composant de chemin d'e/s

E/s non résolue

E/s non résolue est défini comme une demande d'e/s qui se termine, ou qui prend trop longtemps à se terminer. Comportement d'e/s non résolue en général dû à une des raisons suivantes :

  • La configuration matérielle
  • Les paramètres du microprogramme
  • Un problème de pilote de filtre qui requiert une assistance dans le matériel ou le fournisseur du logiciel de suivi et de résoudre

SQL Server bloqué d'e/s et bloqué des e/s de l'enregistrement et de communication

Prise en charge de Microsoft SQL Server gère de nombreux cas chaque année qui impliquent les problèmes d'e/s non résolues ou figés. Ces problèmes s'affichent de différentes manières. Problèmes sont quelques-uns des problèmes plus difficiles à diagnostiquer et à déboguer, et nécessitent beaucoup de temps et de ressources pour le débogage à partir de Microsoft et du client. Les fonctionnalités de création de rapports qui ont été ajoutées à SQL Server 2000 Service Pack 4 et versions ultérieures considérablement réduisent le temps nécessaire pour identifier un problème d'e/s.

La déclaration et l'enregistrement des demandes d'e/s sont conçus sur une base par fichier. La détection et le signalement de requêtes bloquées et bloqués sont deux actions.

Enregistrement

Il existe deux instants lorsqu'une action d'enregistrement se produit dans SQL Server. La première est lors de l'opération d'e/s n'a pas terminé. Si une demande d'e/s prend plus de 15 secondes, une opération d'enregistrement se produit. Le second moment est lors de l'exécution de l'outil d'écriture différée. Lors de l'exécution de l'outil d'écriture différée, l'écriture différée vérifie toutes les données en cours et tous le journaux en attente les demandes d'e/s de fichiers. Si le seuil de 15 secondes a été dépassé, une opération d'enregistrement se produit.

Création de rapports

Création de rapports se produit dans les intervalles sont distants de 5 minutes ou plus. Création de rapports se produit lors de la prochaine demande d'e/s sur le fichier. Si une action d'enregistrement s'est produite et 5 minutes ou plus se sont écoulés depuis le dernier rapport s'est produite, le message d'information qui est mentionné dans la section « Résumée » est écrite dans le journal des erreurs de SQL Server.

Le seuil de 15 secondes n'est pas réglable. Toutefois, vous pouvez désactiver la détection de d'e/s bloquée ou figée à l'aide de l'indicateur de trace 830, bien que nous ne recommandons pas que cela.

Pour désactiver la détection au démarrage de SQL Server, vous devez utiliser le -T830 paramètre de démarrage pour désactiver la détection chaque fois que SQL Server est démarré. Pour désactiver la détection d'une instance de SQL Server en cours d'exécution, utilisez l'instruction suivante :

DBCC traceoff (830, -1)
Ce paramètre est uniquement effectif pour la durée de vie du processus SQL Server.

Remarque Une demande d'e/s qui est bloquée ou bloquée est signalée qu'une seule fois. Par exemple, si le message indique que 10 demandes d'e/s sont bloquées, les 10 rapports pas se produira à nouveau. Si le message suivant indique que 15 demandes d'e/s sont bloquées, cela signifie que 15 des nouvelles demandes d'e/s ralenties.

Le paquet de demande d'e/s (IRP) de suivi

SQL Server utilise les appels d'API de Microsoft Windows standard pour lire et écrire des données. Par exemple, SQL Server utilise les fonctions suivantes :

  • WriteFile
  • ReadFile
  • WriteFileScatter
  • ReadFileGather
La demande de lecture ou d'écriture est gérée par Windows comme un paquet de demande d'e/s (IRP). Pour déterminer l'état de l'IRP, utilisez le des opérations suivantes :

  • Assistance de prise en charge de la plate-forme Microsoft
  • Le débogueur de noyau
Pour plus d'informations sur la Commission de contrôle internationale et la Commission de contrôle internationale (traçage), accédez à la recherche sur le mot-clé « IRP » et le site Web de Microsoft suivants :Remarque Débogage du noyau peut être un processus INVASIF car le débogage du noyau peut vous obliger à arrêter le système pour terminer les actions de débogage. Nous recommandons de vérifier les mises à jour disponibles pour les éléments suivants :

  • Le BIOS
  • Le firmware
  • D'autres composants de chemin d'e/s
Contactez vos fournisseurs de matériel avant de procéder à des actions de débogage supplémentaires. La session de débogage sera certainement amené à un pilote tiers, un microprogramme ou un composant de pilote de filtre.

Les performances du système et les actions de plan de requête

Globalement les performances du système peuvent jouer un rôle clé dans le traitement des e/s. Vous devez tenir compte de l'état général du système lorsque vous étudiez le rapports d'opérations d'e/s non résolues ou figées. Charge excessif peut entraîner l'ensemble du système soit lente. Cela inclut le traitement des e/s. Le comportement du système au moment où le problème se produit peut être un facteur clé pour déterminer la cause du problème. Par exemple, si l'utilisation du processeur devient élevée ou si l'utilisation du processeur reste élevée lorsque le problème se produit, cela peut indiquer qu'un processus sur le système à l'aide de CPU bien qu'autres processus sont affectés.

Compteurs de performance

Pour surveiller les performances, examinez les compteurs de performance suivants pour les informations de chemin d'e/s spécifiques :

  • Moyenne disque s/transfert
  • Longueur de file d'attente de disque moyenne
  • Longueur de file d'attente du disque actuel
Par exemple, la moyenne disque s/transfert durée sur un ordinateur qui exécute SQL Server est généralement moins de 15 millisecondes. Si la valeur moyenne disque s/transfert augmente, cela indique que le sous-système d'e/s non optimale face à la demande d'e/s.

Soyez prudent lorsque vous utilisez les compteurs de performances, car SQL Server tire pleinement parti des fonctionnalités d'e/s asynchrone qui extrait les longueurs de file d'attente de disque très. Par conséquent, plus longues files d'attente de disque seuls n'indiquent pas un problème.

Dans le Moniteur système de Windows, vous pouvez consulter les compteurs de "disque physique : octets disque/s » pour chaque affectés disque et comparer le taux d'activité contre les compteurs « processus : e/s données octets/s » et « processus : e/s d'autres octets/s » pour chaque processus déterminer si un ensemble spécifique de processus génère des e/s excessives les demandes. Diverses autres e/s connexes de compteurs disponibles dans le processus d'objet qui révèle des informations plus granulaires. Si vous déterminez qu'une instance de SQL Server est responsable de la charge d'e/s excessive sur le serveur, consultez la section suivante sur « Index et parallélisme ». Pour plus d'informations sur la détection et résolution des goulots d'étranglement d'e/s, consultez la section « Les goulots d'étranglement d'e/s » dans le livre blanc MSDN Résolution des problèmes de performances dans SQL Server 2008 ou Résolution des problèmes de performances dans SQL Server 2005.

Index et parallélisme

Pics d'e/s se produisent fréquemment, car un index est manquant. Ce comportement peut sérieusement exécute un push du chemin d'e/s. Une étape de l'Assistant de l'activation des Index (ITW) peut aider à résoudre la pression d'e/s sur le système. Si une requête tire parti d'un index plutôt qu'une analyse de table, ou peut-être si elle utilise un tri ou hachage, le système peut bénéficier des avantages suivants :

  • Une réduction est effectuée dans l'e/s physique qui est nécessaire pour terminer l'action qui crée directement des avantages de performances de la requête.
  • Moins de pages dans le cache de données doivent être retournés. Par conséquent, les pages qui sont dans le cache de données restent aux requêtes actives.
  • Trie et les hachages sont utilisés car un index peut être manquant ou parce que les statistiques sont à jour. Vous pouvez réduire tempdb utilisation et le conflit en ajoutant un ou plusieurs index.
  • Une réduction est effectuée dans les ressources, les opérations en parallèle ou les deux. SQL Server ne garantit pas l'exécution de requêtes en parallèle, et parce que la charge sur le système est considéré comme, il est préférable d'optimiser toutes les requêtes pour une exécution en série. Pour optimiser une requête, ouvrez l'Analyseur de requête et définir la valeur de sp_configure de la degré maximal de parallélisme option 1. Si toutes les requêtes sont réglés afin d'exécuter une opération en série les meilleurs, l'exécution en parallèle est souvent simplement un meilleur résultat. Toutefois, plusieurs heures d'exécution en parallèle est sélectionné, car la quantité de données est grande. Un index manquant, un tri de grande taille peut devoir se produisent. Plusieurs travailleurs qui effectuent l'opération de tri va créer une réponse plus rapide. Toutefois, cette action peut augmenter considérablement la pression sur le système. Grande lecture à partir de nombreux travailleurs peuvent provoquer une rafale d'e/s et une meilleure utilisation de l'UC à partir de plusieurs travailleurs. Nombre de fois où une requête peut être optimisée pour s'exécuter plus rapidement et utilisent moins de ressources, si un index est ajouté ou si une autre action de réglage se produit.

Exemples pratiques de prise en charge de Microsoft SQL Server

Les exemples suivants ont été gérés par la prise en charge de Microsoft SQL Server et prise en charge de plates-formes escalade. Ces exemples sont destinés à fournir un cadre de référence et aide vos attentes, environ bloqué et bloqué des situations d'e/s et sur comment un système peut être affecté ou peut répondre. Il n'y a aucun matériel spécifique ou un ensemble de pilotes qui posent tout risque spécifique ou un risque accru sur un autre. Tous les systèmes sont les mêmes à cet égard.

Exemple 1: Une écriture de journal qui est bloqué pendant 45 secondes

Une tentative d'écriture de régulièrement un fichier de journal de SQL Server se bloque pendant environ 45 secondes. L'écriture de journal n'est pas terminée dans un délai raisonnable. Ce comportement crée une condition de blocage qui provoque des délais d'attente du client de 30 secondes.

La demande de la validation de SQL Server, et que la validation est devenu bloquée comme une écriture de journal en attente. Ce comportement provoque la requête pour continuer à maintenir des verrous et de bloquer les demandes entrantes à partir d'autres clients. Ensuite, autres clients commencent à expirer. Cela aggraver le problème car l'application n'annule pas les transactions en cours lorsqu'un délai d'expiration de la requête se produit. Cela crée des centaines de transactions en cours qui sont maintenant des verrous. Par conséquent, une situation de blocage critique se produit.

Pour plus d'informations sur la gestion et le blocage de transaction, consultez l'article suivant de la Base de connaissances Microsoft :L'application des services d'un site Web à l'aide de regroupement de connexions. Plusieurs connexions sont bloquées, le site Web crée davantage de connexions. Ces connexions sont bloquées, et le cycle se poursuit.

Après environ 45 secondes, la fin de l'écriture de journal. Toutefois, à ce stade, des centaines de connexions sont sauvegardés. Les problèmes de blocage entraîner quelques minutes de temps de récupération pour SQL Server et pour l'application. Combiné avec les problèmes de l'application, la condition d'e/s non résolue a un effet très négatif sur le système.
Résolution
Ce problème a été suivi à une demande d'e/s coincée dans un pilote de l'adaptateur de Bus hôte (HBA). L'ordinateur a plusieurs cartes HBA avec prise en charge du basculement. Lorsqu'un adaptateur HBA a été derrière ou a été ne communique pas avec le réseau SAN (Storage Area), la valeur de délai d'expiration « réessayer avant le basculement » a été configurée à 45 secondes. Lorsque le délai d'attente a été dépassé, la demande d'e/s a été routée vers le deuxième adaptateur HBA. Le deuxième adaptateur HBA a géré la demande et rapidement terminé. Pour éviter des conditions de blocage, le fabricant du matériel recommandé un paramètre « réessayer avant le basculement » de 5 secondes.

Exemple 2: Filtrer l'intervention du pilote

De nombreux programmes antivirus et les produits de sauvegarde utilisent des pilotes de filtre d'e/s. Ces pilotes de filtre d'e/s font partie de la pile de la demande d'e/s, et ils ont accès à la demande de la Commission de contrôle internationale. Microsoft Product Support Services a constaté plusieurs problèmes à partir des bogues que vous créez bloqué les conditions d'e/s ou bloqué les conditions d'e/s dans une mise en œuvre du pilote de filtre.

Une condition était un pilote de filtre pour le traitement de sauvegarde permettant une sauvegarde des fichiers qui étaient ouverts lors de la sauvegarde. L'administrateur système avait inclus le répertoire de fichier de données de SQL Server dans les sélections de sauvegarde du fichier. Lors de la sauvegarde, la sauvegarde a essayé de recueillir l'image correcte du fichier au moment où la sauvegarde a commencé. Cette opération retardée les demandes d'e/s. Les demandes d'e/s ont été autorisés à la ne fin qu'un seul à la fois comme elles ont été traitées par le logiciel.

Lorsque la sauvegarde est lancée, les performances de SQL Server abandonnés considérablement l'e/s de SQL Server ont été forcés à la fin d'un à la fois. Pour compliquer le problème, la logique de « un à la fois » a été telle que l'opération d'e/s n'a pas pu être effectuée en mode asynchrone. Par conséquent, lorsque SQL Server prévu pour valider une demande d'e/s et continuer, le travailleur a été bloqué dans l'appel d'écriture ou de lecture jusqu'à la fin de la requête. Tâches de traitement comme un SQL Server lecture anticipée ont été désactivés par les actions du pilote de filtre. En outre, un autre bogue dans le pilote de filtre gauche les actions « un à la fois » dans le processus, même si la sauvegarde a été terminée. Le seul moyen de restaurer les performances de SQL Server a été fermez, puis rouvrez la base de données, ou de redémarrer SQL Server afin que le handle de fichier a été publié et acquis à nouveau sans l'interaction de pilote de filtre.
Résolution
Pour résoudre ce problème, les fichiers de données SQL Server ont été supprimés du processus de sauvegarde du fichier. Le fabricant du logiciel corrigé également le problème reste le fichier en mode « un à la fois ».

Exemple 3: Masquer les erreurs

De nombreux systèmes haut de gamme ont des chemins d'e/s multicanal pour gérer l'équilibrage de charge ou des activités similaires. Support technique de Microsoft a détecté des problèmes avec la logiciel où une demande d'e/s tombe en panne, mais le logiciel ne gère pas correctement l'erreur d'équilibrage de la charge. Le logiciel peut essayer de tentatives infinies. L'opération d'e/s se bloque et que SQL Server ne peut pas terminer l'action spécifiée. De la même manière que le journal écrire la condition qui a été décrit précédemment, de nombreux comportements de fonctionnement du système peuvent se produire une fois que cette condition de coins du système.
Résolution
Pour résoudre ce problème, le redémarrage de SQL Server est souvent nécessaire. Cependant, parfois vous devez redémarrer le système d'exploitation pour restaurer le traitement. Nous vous recommandons également de vous procurer une mise à jour du logiciel auprès du fournisseur d'e/s.

Exemple 4: Le stockage étendu, la mise en miroir et des disques raid

De nombreux systèmes utilisent la mise en miroir ou des étapes similaires pour éviter toute perte de données. Certains systèmes qui utilisent la mise en miroir sont basées sur le logiciel, et certains sont basés sur le matériel. La situation est généralement découverts par le Support Microsoft pour ces systèmes est la latence accrue.

Une augmentation du temps global d'e/s se produit lorsque les e/s doit se terminer à la mise en miroir avant que les e/s est considérée comme terminée. Pour les installations de mise en miroir à distance, les tentatives de réseau peuvent intervenir. Lorsque se produisent les défaillances de disque et le système raid est la reconstruction, le modèle d'e/s peut également être interrompu.
Résolution
Paramètres de configuration strict sont nécessaires afin de réduire la latence sur les miroirs ou aux opérations de reconstruction de raid.

Pour plus d'informations, consultez la configuration requise pour SQL Server prendre en charge la mise en miroir à distance de bases de données utilisateur.

Exemple 5: Compression

Microsoft ne prend pas en charge Microsoft SQL Server 7.0 ou les fichiers de données Microsoft SQL Server 2000 et les fichiers journaux sur des lecteurs compressés. La compression NTFS n'est pas sécurisée pour SQL Server, car le protocole d'écriture Ahead Logging (WAL) les sauts de la compression NTFS. La compression NTFS requiert également une augmentation de traitement pour chaque opération d'e/s. Compression crée « un à la fois » comme un comportement qui entraîne de sérieux problèmes de performances se produit.
Résolution
Pour résoudre ce problème, décompressez les données et les fichiers journaux.

Pour plus d'informations, consultez la Description de la prise en charge des bases de données SQL Server sur les volumes compressés.

Points de données supplémentaires

Délai d'attente PAGEIOLATCH_ * et writelog sys.dm_os_wait_stats, vues de gestion dynamique (DMV) est indictors clés pour étudier les performances et disponibilité. Si vous voyez significative attend PAGEIOLATCH, cela signifie que SQL Server est en attente sur le sous-système d'e/s. Un certain nombre d'attentes PAGEIOLATCH est par défaut et le comportement attendu. Toutefois, si la moyenne PAGEIOLATCH d'attente est toujours supérieure à 10 millisecondes (ms), vous devez rechercher pourquoi le sous-système d'e/s est sous pression. Pour plus d'informations, consultez les documents suivants :



SQL Server nécessite que les systèmes qui prennent en charge « remise garantie sur un support stable » comme indiqué sous les conditions du programme SQL Server d'e/s de la fiabilité. Pour plus d'informations sur la configuration d'entrée et de sortie pour le moteur de base de données SQL Server, consultez l'article suivant de la Base de connaissances Microsoft :

ID de l'événement d'e/s 833

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 897284 - Dernière mise à jour : 09/30/2015 16:01:00 - Révision : 1.0

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, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Enterprise Core, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, Microsoft SQL Server 2012 Business Intelligence, 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 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition

  • kbinfo kbtshoot kbsqlserv2000sp4fea kbmt KB897284 KbMtfr
Commentaires
=">