Comment faire pour résoudre des problèmes de lenteur d'exécution des requêtes dans SQL Server 7.0 ou dans des versions ultérieures

Traductions disponibles Traductions disponibles
Numéro d'article: 243589 - Voir les produits auxquels s'applique cet article
Ancien nº de publication de cet article : F243589
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article explique comment faire pour gérer un problème de performance que les applications peuvent rencontrer conjointement à Microsoft SQL Server : lenteur d'exécution d'une requête spécifique ou d'un groupe de requêtes. Si vous résolvez un problème de performance, mais que vous n'avez pas associé le problème à une requête spécifique ou à un petit groupe de requêtes qui s'exécutent plus lentement que prévu, consultez l'article suivant dans la Base de connaissances Microsoft avant de continuer :
224587 INF : Résolution des problèmes de performance d'applications sous SQL Server
Cet article suppose que vous avez utilisé l'article 224587 pour réduire l'étendue du problème, et que vous avez capturé une trace du générateur de profils SQL Profiler avec les événements et les colonnes de données spécifiques qui sont détaillées dans l'article 224587.

L'ajustement des requêtes de base de données peut être une opération à plusieurs aspects. Les sections suivantes présentent les éléments courants à examiner lorsque vous étudiez les performances des requêtes.

Remarque Si vous utilisez SQL Server 2005, faites appel à SQL Server Management Studio au lieu de l'Analyseur de requêtes SQL Server, puis à l'assistant Paramétrage du moteur de base de données plutôt qu'à l'Assistant Paramétrage d'index.

Vérifier l'existence des bons index

L'un des premiers contrôles à effectuer en cas de lenteur des temps d'exécution de requêtes est l'analyse d'index. Si vous effectuez des recherches sur une requête seule, vous pouvez utiliser l'option Effectuer l'analyse d'index dans l'Analyseur de requêtes SQL Server ; si vous avez une trace SQL Profiler d'une grande charge de travail, vous pouvez utiliser l'assistant Paramétrage d'index. Ces deux méthodes utilisent l'optimiseur de requête SQL Server pour déterminer quels index seraient utiles pour les requêtes spécifiées. Il s'agit d'une méthode très efficace pour déterminer si les bons index se trouvent dans votre base de données.

Pour plus d'informations sur l'utilisation de l'assistant Paramétrage d'index, consultez la rubrique « Assistant Paramétrage d'index » dans la documentation en ligne de SQL Server 7.0.

Si vous avez mis à niveau votre application à partir d'une version précédente de SQL Server, il se peut que les différents index soient plus efficaces dans SQL Server 7.0, à cause des changements apportés à l'optimiseur et au moteur de stockage. L'Assistant Paramétrage d'index vous aide à déterminer si un changement de stratégie d'indexation améliorerait les performances.

Pour plus d'informations sur l'utilisation de l'assistant Réglage du moteur de base de données au lieu de l'Assistant Paramétrage d'index dans SQL Server 2005, consultez les rubriques suivantes dans la documentation en ligne de SQL Server 2005 :
  • Différences entre l'assistant Réglage du Moteur de base de données et l'Assistant Paramétrage d'index
  • Didacticiel assistant Paramétrage du moteur de base de données

Supprimer tous les indicateurs de requête, table et jointure

Les indicateurs remplacent l'optimisation de requête et peuvent empêcher l'optimiseur de requêtes de choisir le plan d'exécution le plus rapide. À cause des modifications apportées à l'optimiseur, les indicateurs qui amélioraient les performances dans les versions antérieures de SQL Server peuvent n'avoir aucun effet ou un effet néfaste sur les performances de SQL Server 7.0. En outre, les indicateurs de jointure peuvent réduire les performances, pour les raisons suivantes :
  • Les indicateurs de jointure empêchent une requête ad hoc d'être qualifiée pour le paramétrage automatique et pour la mise en cache du plan de requête.
  • L'utilisation d'un indicateur de jointure implique que vous voulez forcer l'ordre de jointure pour toutes les tables de la requête, même si ces jointures n'utilisent pas explicitement d'indicateur.
Si la requête que vous analysez contient des indicateurs, supprimez-les, puis réévaluez les performances.

Examiner le plan d'exécution

Après avoir confirmé que les bons index existent, et qu'aucun indicateur ne restreint la capacité de l'optimiseur de générer un plan efficace, vous pouvez examiner le plan d'exécution de la requête. Pour ce faire, vous avez le choix entre plusieurs méthodes :
  • Générateur de profils SQL

    Si vous avez capturé l'événement MISC:Execution Plan dans SQL Profiler, il survient immédiatement avant l'événement StmtCompleted de la requête pour cet ID de processus système (SPID) particulier.
  • Analyseur de requêtes SQL : Plan de requête graphique

    Avec la requête sélectionnée dans la fenêtre de requête, cliquez sur le menu Requête, puis sur Afficher le plan d'exécution estimé.

    REMARQUE : si la procédure stockée ou le lot crée et référence des tables temporaires, vous devez utiliser une instruction SET STATISTICS PROFILE ON ou créer explicitement les tables temporaires avant d'afficher le plan d'exécution.
  • SHOWPLAN_ALL et SHOWPLAN_TEXT

    Pour recevoir une version texte du plan d'exécution estimé, vous pouvez utiliser les options SHOWPLAN_ALL DÉFINIS et SET SHOWPLAN_TEXT. Pour plus d'informations, consultez les rubriques « SHOWPLAN_ALL (T-SQL) » et « SET SHOWPLAN_TEXT (T-SQL) » dans la documentation en ligne de SQL Server 7.0.

    REMARQUE : si la procédure stockée ou le lot crée et référence des tables temporaires, vous devez utiliser l'option SET STATISTICS PROFILE ON ou créer explicitement les tables temporaires avant d'afficher le plan d'exécution.
  • STATISTICS PROFILE

    Lorsque vous affichez le plan d'exécution estimé, soit graphiquement soit en utilisant SHOWPLAN, la requête n'est pas véritablement exécutée. Par conséquent, si vous créez des tables temporaires dans un lot ou une procédure stockée, vous ne pouvez pas afficher les plans d'exécution estimés, car les tables temporaires n'existeront pas. STATISTICS PROFILE exécute d'abord la requête, puis affiche le plan d'exécution. Pour plus d'informations, consultez la rubrique « SET STATISTICS PROFILE (T-SQL) » dans la documentation en ligne de SQL Server 7.0. Lorsqu'elle s'exécute dans l'Analyseur de requêtes SQL Server, cela apparaît au format graphique sur l'onglet Plan d'exécution dans le volet de résultats.
Pour plus d'informations sur la façon d'afficher le plan d'exécution estimé dans SQL Server 2005, consultez la rubrique « Comment faire pour afficher le plan d'exécution estimé » dans la documentation en ligne de SQL Server 2005.

Examiner la sortie du plan de requête

La sortie du plan de requête fournit un grand nombre d'informations à propos du plan d'exécution que SQL Server utilise pour une requête particulière. Les détails des informations et événements qui sont générés sont présentés au chapitre « Optimisation des performances des bases de données » de la documentation en ligne de SQL Server 7.0. Voici certains aspects de base du plan d'exécution que vous pouvez consulter pour déterminer si vous utilisez le meilleur plan :
  • Utilisation correcte des index

    La sortie du plan de requête affiche chacune des tables impliquées dans la requête et le chemin d'accès utilisé pour en obtenir des données. Avec le plan de requête graphique, déplacez le pointeur sur une table pour voir les détails de chaque table. Si un index est en cours d'utilisation, « Index Seek » s'affiche ; si un index n'est pas en cours d'utilisation, « Table Scan » s'affiche pour un segment de mémoire ou « Clustered Index Scan » pour une table dotée d'un index organisé en cluster. « Clustered Index Scan » indique que la table est analysée à travers l'index organisé en cluster, pas que l'index organisé en cluster est utilisé pour accéder directement aux lignes individuelles.

    Si vous déterminez qu'un index utile existe et qu'il n'est pas utilisé pour la requête, vous pouvez essayer de le forcer, en utilisant un indicateur d'index. Pour plus d'informations concernant les indicateurs d'index, consultez la rubrique « FROM (T-SQL) » dans la documentation en ligne de SQL Server.
  • Ordre de jointure correct

    La sortie du plan de requête indique dans quel ordre les tables qui sont impliquées dans une requête doivent être jointes. Pour les jointures de boucle imbriquée, la première table de la liste est la table externe ; elle doit être la plus petite des deux tables. Pour les jointures de hachage, la table supérieure devient l'entrée de création et doit également être la plus petite des deux tables. Toutefois, notez que l'ordre est moins critique parce que le processeur de requêtes peut inverser la création et tester les entrées au moment de l'exécution s'il se rend compte que l'optimiseur a pris une mauvaise décision. Vous pouvez déterminer quelle table retourne moins de lignes en vérifiant les estimations du nombre de lignes dans la sortie du plan de requête.

    Si vous décidez que la requête peut bénéficier d'un ordre de jointure différent, vous pouvez essayer de forcer l'ordre de jointure avec un indicateur de jointure. Pour plus d'informations concernant les indicateurs de jointure, consultez la rubrique « FROM (T-SQL) » dans la documentation en ligne de SQL Server.

    REMARQUE : l'utilisation d'un indicateur de jointure dans une requête importante force implicitement l'ordre de jointure des autres tables dans la requête, comme si FORCEPLAN avait été défini.
  • Type de jointure correct

    SQL Server utilise les jointures de boucle imbriquée, de hachage et de fusion. Si une requête d'exécution lente utilise une technique de jointure plutôt qu'une autre, vous pouvez essayer de forcer un type de jointure différent. Par exemple, si une requête utilise une jointure de hachage, vous pouvez forcer une jointure de boucle imbriquée en utilisant l'indicateur de jointure LOOP. Pour plus d'informations concernant les indicateurs de jointure, consultez la rubrique « FROM (T-SQL) » dans la documentation en ligne de SQL Server.

    REMARQUE : l'utilisation d'un indicateur de jointure dans une requête importante force implicitement le type de jointure des autres tables dans la requête, comme si FORCEPLAN avait été défini.
  • Exécution parallèle

    Si vous utilisez un ordinateur multiprocesseur, vous pouvez chercher à savoir si un plan parallèle est en cours d'utilisation. Si le parallélisme est en cours d'utilisation, un événement PARALLELISM (Gather Streams) s'affiche. Si une requête particulière est lente lorsqu'elle utilise un plan parallèle, vous pouvez essayer de forcer un plan non parallèle à l'aide de l'indicateur OPTION (MAXDOP 1). Pour plus d'informations, consultez la rubrique « SELECT (T-SQL) » dans la documentation en ligne de SQL Server 7.0.
Pour plus d'informations sur l'utilisation de la sortie du plan d'exécution du plan de requête dans SQL Server 2005, reportez-vous aux rubriques suivantes de la documentation en ligne de SQL Server :
  • Comment faire pour enregistrer un plan d'exécution au format XML
  • Plans de requête XML
  • Sécurité du plan de requête
ATTENTION : l'optimiseur de requête sélectionnant en général le meilleur plan d'exécution pour une requête, Microsoft recommande que vous utilisiez des indicateurs de jointure, de requête et de table uniquement en dernier ressort, et uniquement si vous êtes un administrateur de base de données expérimenté.

Références

Les rubriques suivantes de la documentation en ligne SQL Server 7.0 fournissent des informations à propos de l'optimisation des requêtes :
  • « Optimisation des performances de l'application grâce à une extraction des données efficace »
  • « Ajustage des requêtes »
  • « Recommandations en matière d'ajustage des requêtes »
  • « Conseils concernant Transact-SQL »

Propriétés

Numéro d'article: 243589 - Dernière mise à jour: mardi 17 mai 2011 - Version: 6.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
Mots-clés : 
kbsqlserverengine kbhowtomaster KB243589
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com