Résoudre les problèmes de l’ensemble de l’application SQL Server ou de la base de données qui semble être lente

S'applique à : SQL Server

Lorsque vous exécutez des requêtes sur une instance SQL Server ou une application particulière, toutes les requêtes sont lentes. Pour résoudre le problème, procédez comme suit :

Étape 1 : Résoudre les problèmes d’application

Vérifiez la couche d’application. Effectuez une requête à partir de l’application, exécutez-la manuellement sur une instance SQL Server et découvrez comment elle s’exécute. Testez plusieurs requêtes de cette façon. Si les requêtes sont plus rapides sur l’instance SQL Server, le problème peut se trouver sur la couche des applications ou des serveurs d’applications.

Note

Gardez à l’esprit les différences de performances des requêtes entre l’application de base de données et SSMS.

Si l’application s’exécute sur un autre serveur, vérifiez les performances du serveur d’applications (consultez l’étape 2 : Résoudre les problèmes de système d’exploitation pour la résolution des problèmes ). Vous devrez peut-être impliquer l’équipe de développement d’applications pour rechercher les problèmes liés à l’application.

Étape 2 : Résoudre les problèmes de système d’exploitation

Vérifiez si le système d’exploitation où SQL Server est en cours d’exécution répond lentement. Par exemple, la souris se déplace lentement, les fenêtres ne répondent pas pendant de longues périodes, l’accès bureau à distance au serveur est lent ou la connexion à un partage sur le serveur est lente.

Ce problème peut être dû à un autre service ou application. Utilisez Perfmon pour résoudre les problèmes.

Pour d’autres problèmes de performances du système d’exploitation, consultez la documentation sur la résolution des problèmes de performances de Windows Server.

Voici quelques problèmes courants :

Ce problème peut être dû à d’autres applications, au système d’exploitation ou aux pilotes s’exécutant sur le système.

Pour résoudre ce problème, utilisez le Gestionnaire des tâches, Analyseur de performances ou Resource Monitor pour identifier ce problème. Pour plus d’informations, consultez les conseils de résolution des problèmes d’utilisation élevée du processeur.

Étape 3 : Résoudre les problèmes réseau

Le problème peut se trouver dans la couche réseau, provoquant une communication lente entre l’application et SQL Server. Utilisez les méthodes suivantes pour résoudre ce problème :

  • Un symptôme de cela peut être ASYNC_NETWORK_IO attendu côté SQL Server. Pour plus d’informations, consultez Résoudre les problèmes liés aux requêtes lentes résultant de ASYNC_NETWORK_IO type d’attente.

  • Collaborez avec votre administrateur réseau pour rechercher les problèmes réseau (pare-feu, routage, etc.).

  • Collectez une trace réseau et recherchez les événements de réinitialisation et de retransmission du réseau. Pour obtenir des idées de résolution des problèmes, consultez Problème réseau intermittent ou périodique.

  • Activez les compteurs Perfmon pour vérifier les performances réseau au niveau de l’interface réseau (NIC). Il doit y avoir zéro paquets ignorés et paquets d’erreur. Vérifiez la bande passante de l’interface réseau :

    • Interface réseau\Paquets reçus ignorés
    • Interface réseau\Paquets reçus erreurs
    • Interface réseau\Paquets sortants ignorés
    • Interface réseau\Erreurs sortantes de paquets
    • Interface réseau\Nombre total d’octets/s
    • Interface réseau\Bande passante actuelle

Étape 4 : Résoudre les problèmes d’utilisation élevée du processeur dans SQL Server

Si des requêtes nécessitant beaucoup d’UC sont exécutées sur le système, elles peuvent entraîner une insuffisance de capacité du processeur pour d’autres requêtes. Toutefois, plus fréquemment, une utilisation élevée du processeur provenant de requêtes peut indiquer que les requêtes doivent être optimisées. Procédez comme suit pour résoudre le problème :

  1. Tout d’abord, déterminez si SQL Server provoque une utilisation élevée du processeur (à l’aide de compteurs Perfmon).
  2. Identifiez les requêtes contribuant à l’utilisation du processeur.
  3. Mettre à jour les statistiques.
  4. Ajoutez des index manquants.
  5. Examinez et résolvez les problèmes de sensibilité aux paramètres.
  6. Examinez et résolvez les problèmes sargabilité.
  7. Désactivez le suivi lourd.
  8. Corrigez la SOS_CACHESTORE contention du verrouillage de spinlock.
  9. Configurez votre machine virtuelle.
  10. Effectuez un scale-up du système en ajoutant d’autres processeurs.

Pour obtenir des instructions de dépannage détaillées, consultez Résoudre les problèmes d’utilisation élevée de l’UC dans SQL Server.

Étape 5 : Résoudre les problèmes d’E/S excessifs provoquant une lenteur dans SQL Server

Une autre raison courante de la lenteur globale perçue des charges de travail SQL Server est des problèmes d’E/S. La lenteur des E/S peut affecter la plupart ou toutes les requêtes sur le système. Utilisez les méthodes suivantes pour résoudre le problème :

  • Recherchez les problèmes matériels :

    • Configuration incorrecte de SAN (commutateur, câbles, HBA, stockage).
    • Capacité d’E/S dépassée (déséquilibré dans l’ensemble du réseau SAN, pas seulement le stockage back-end, vérifiez le débit d’E/S de tous les serveurs partageant le réseau SAN).
    • Problèmes ou mises à jour des pilotes ou des microprogrammes.

  • Recherchez les requêtes SQL Server non optimales qui provoquent un grand nombre d’E/S et qui saturent des volumes de disque avec des requêtes d’E/S.

    • Recherchez les requêtes qui provoquent un grand nombre de lectures logiques (ou d’écritures) et ajustez ces requêtes pour réduire les E/S de disque à l’aide d’index appropriés est la première étape.
    • Conservez les statistiques mises à jour, car elles fournissent à l’optimiseur de requête suffisamment d’informations pour choisir le meilleur plan.
    • La refonte des requêtes et parfois des tables peut aider à améliorer les E/S.

  • Pilotes de filtre : la réponse d’E/S SQL Server peut être gravement affectée si les pilotes de filtre du système de fichiers traitent le trafic d’E/S lourd.

    • Excluez les dossiers de données de l’analyse antivirus et rencontrez des problèmes de pilote de filtre corrigés par les fournisseurs de logiciels pour empêcher un impact sur les performances des E/S.

  • Autres applications : une autre application sur la même machine avec SQL Server peut saturer le chemin d’E/S avec des demandes de lecture ou d’écriture excessives. Cette situation peut pousser le sous-système d’E/S au-delà des limites de capacité et provoquer la lenteur des E/S pour SQL Server. Identifiez l’application et ajustez-la ou déplacez-la ailleurs pour éliminer son effet sur la pile d’E/S. Ce problème peut également être dû au fait que les applications s’exécutent sur d’autres ordinateurs, mais partagent le même san avec cette machine SQL Server. Collaborez avec votre administrateur SAN pour équilibrer le trafic d’E/S (consultez Vérifier les problèmes matériels).

Pour obtenir une résolution détaillée des problèmes liés aux E/S avec SQL Server, consultez Résoudre les problèmes de performances lentes de SQL Server causés par des problèmes d’E/S.

Étape 6 : Résoudre les problèmes de mémoire

Une faible mémoire sur le système ou à l’intérieur de SQL Server peut entraîner une lenteur lorsque les requêtes attendent des allocations de mémoire (RESOURCE_SEMAPHORE) ou compilent de la mémoire (RESOURCE_SEMAPHORE_QUERY_COMPILE). Utilisez les méthodes suivantes pour résoudre le problème :

  • Recherchez la mémoire externe au niveau du système d’exploitation à l’aide des compteurs Perfmon :

    • Mémoire\Octets Moctets disponibles
    • Process(*)\Working Set (toutes les instances)
    • Process(*)\Octets privés (toutes les instances)

  • Pour la pression de la mémoire interne, utilisez des requêtes SQL Server pour interroger sys.dm_os_memory_clerks ou utiliser DBCC MEMORYSTATUS.

  • Consultez le journal des erreurs SQL Server pour obtenir les erreurs 701 .

Pour obtenir des instructions de dépannage détaillées, consultez Résoudre les problèmes de mémoire insuffisante ou de mémoire insuffisante dans SQL Server.

Étape 7 : Résoudre les problèmes de blocage

L’acquisition de verrous est utilisée pour protéger les ressources dans un système de base de données. Si les verrous sont acquis pendant longtemps et que d’autres sessions finissent par attendre ces verrous, vous êtes confronté à un scénario de blocage.

Le blocage court se produit sur les systèmes de base de données tels que SQL Server tout le temps. Mais le blocage prolongé, en particulier lorsque la plupart ou toutes les requêtes attendent un verrou, peuvent entraîner la perception de l’ensemble du serveur comme ne répondant pas.

Pour résoudre le problème, procédez comme suit :

  1. Identifiez la session de blocage de tête en examinant la colonne blocking_session_id dans sys.dm_exec_requests sortie DMV ou la colonne BlkBy dans la sortie de sp_who2 procédure stockée.

  2. Recherchez la ou les requêtes exécutées par la chaîne de blocage de la tête (ce qui contient des verrous pendant une période prolongée).

    Si aucune requête n’est en cours d’exécution sur la session de blocage de tête, il peut y avoir eu une transaction orpheline en raison de problèmes d’application.

  3. Remaniez ou ajustez la requête de blocage de la tête pour qu’elle s’exécute plus rapidement, ou réduisez le nombre de requêtes à l’intérieur d’une transaction.

  4. Examinez l’isolation des transactions utilisée dans la requête et ajustez.

Pour obtenir une résolution détaillée des scénarios de blocage, consultez Comprendre et résoudre les problèmes de blocage de SQL Server.

Étape 8 : Résoudre les problèmes liés au planificateur (non-rendement, planificateur bloqué, écouteur CIOP sans rendement, moniteur de ressources)

SQL Server utilise un mécanisme de planification coopérative (Planificateurs) pour exposer ses threads au système d’exploitation pour la planification sur l’UC. S’il existe des problèmes liés aux planificateurs SQL, les threads SQL Server peuvent arrêter le traitement des requêtes, des connexions, des déconnexions, et ainsi de suite. Par conséquent, SQL Server peut sembler insensible, partiellement ou complètement, selon le nombre de planificateurs affectés. Les problèmes du planificateur peuvent provenir d’un large éventail de problèmes, notamment les bogues de produit, les pilotes externes et de filtre et les problèmes matériels.

Procédez comme suit pour résoudre ces problèmes :

  1. Vérifiez que votre journal d’erreurs SQL Server présente des erreurs comme celles suivantes au moment de l’absence de réponse signalée de SQL Server :

    • ***********************************************
*
* BEGIN STACK DUMP:
* 03/10/22 21:16:35 spid 22548
*
* Non-yielding Scheduler
*
***********************************************

    • **********************************************
*
* BEGIN STACK DUMP:
* 03/25/22 08:50:29 spid 355
*
* Deadlocked Schedulers
*
* ********************************************


    • * *******************************************************************************                                
*                                                                                                                
* BEGIN STACK DUMP:                                                                                              
* 09/07/22 23:01:04 spid 0                                                                                     
*                                                                                                                
* Non-yielding IOCP Listener                                                                                     
*                                                                                                                
* *******************************************************************************   

    • * ********************************************
*
* BEGIN STACK DUMP:
* 07/25/22 11:44:21 spid 2013
*
* Non-yielding Resource Monitor
*
* ********************************************

  2. Si vous recherchez l’une de ces erreurs, identifiez la version de mise à jour cumulative (CU) de SQL Server que vous utilisez. Vérifiez s’il existe des problèmes résolus dans les unités de certification livrées après votre cu actuel. Pour connaître les correctifs DE SQL Server, consultez Les dernières mises à jour disponibles pour les versions actuellement prises en charge de SQL Server. Pour obtenir une liste de correctifs détaillée, vous pouvez télécharger ce fichier Excel.

  3. Utilisez la résolution des problèmes liés à la planification et au rendement SQL Server pour obtenir plus d’idées .

  4. Recherchez des scénarios de blocage lourds ou des requêtes de parallélisme massives qui peuvent entraîner des planificateurs de blocage. Pour plus d’informations, consultez The Tao of a Deadlocked Scheduler.

  5. Pour un écouteur IOCP sans rendement, vérifiez si votre système est faible en mémoire et que SQL Server est mis en page. Une autre raison peut être le logiciel anti-virus ou la prévention des intrusions intercepte les appels d’API d’E/S et ralentit l’activité du thread. Pour plus d’informations, consultez L’écouteur IOCP écoute-t-il réellement ? et problèmes de performances et de cohérence lorsque certains modules ou pilotes de filtre sont chargés.

  6. Pour les problèmes liés à Resource Monitor, il se peut que vous ne soyez pas nécessairement préoccupé par ce problème dans certains cas. Pour plus d’informations, consultez Le moniteur de ressources entre une condition de non-rendement sur un serveur exécutant SQL Server.

  7. Si ces ressources ne vous aident pas, localisez le vidage de mémoire créé dans le sous-répertoire \LOG et ouvrez un ticket de support avec Microsoft CSS en chargeant le vidage de mémoire à des fins d’analyse.

Étape 9 : Rechercher des traces de profileur nécessitant beaucoup de ressources ou XEvent

Recherchez des événements étendus actifs ou des traces SQL Server Profiler, en particulier celles avec filtrage sur les colonnes de texte (nom de la base de données, nom de connexion, texte de requête, etc.). Si possible, désactivez les traces et vérifiez si les performances des requêtes s’améliorent. Selon l’événement sélectionné, chaque thread peut consommer un processeur supplémentaire provoquant une lenteur globale. Pour identifier les traces actives pour les événements étendus, consultez sys.dm_xe_sessions et pour les traces profileur, consultez sys.traces.

SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces
  • Last updated on