INF: Optimisation des performances de Microsoft SQL Server

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

La version anglaise de cet article est la suivante: 110352
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Résumé
Pour optimiser efficacement les performances de Microsoft SQL Server, vous devez identifier les zones qui va produire les améliorations plus grand de performance les plus significatives dans le plus grand nombre de situations et concentrer votre analyse sur ces éléments. Dans le cas contraire, vous pouvez prendre beaucoup de temps et d'efforts sur des sujets qui ne peuvent pas produire les améliorations dimensionnables.

Pour l'essentiel, les informations suivantes ne traite pas les problèmes de performances radical à partir de la concurrence d'accès multi-utilisateur. Il s'agit d'une rubrique distincte et complexe qui est abordée dans le document "Optimisation de base de données la cohérence et simultanéité,» qui se trouve dans la version 4.2 x"Guide de référence du programmeur pour C, «SQL Server l'annexe E et également dans d'autres articles de la base de connaissances. Il n'est pas dans la documentation de la version 6.0, mais peut être trouvé sur le CD-ROM MSDN (Microsoft Developer Network) sous ce titre.

Au lieu d'une discussion théorique, cet article se concentre principalement sur les zones années d'expérience par l'équipe de prise en charge de SQL Server a montré de valeur pratique dans les situations réelles.

L'expérience montre que la prestation plus grande performances de SQL Server peut être obtenue à partir de zones générales de la conception d'une base de données logique, conception de l'index, création de requête et conception de l'application. À l'inverse, les plus grands problèmes de performances sont souvent provoquées par des lacunes dans ces zones mêmes. Si vous êtes soucieux de performances, vous vous devez concentrer sur ces zones tout d'abord, dans la mesure où les améliorations de performances de très grande taille possible souvent avec un investissement de temps relativement petite.

Tandis que les problèmes d'autres performances au niveau du système, tels que mémoire cache de tampons, matériel et ainsi de suite, sont certainement des candidats pour étude, l'expérience montre que le gain de performances à partir de ces zones est souvent incrémentiel. SQL Server gère les ressources matérielles disponibles automatiquement, pour l'essentiel, ce qui réduit le besoin (et par conséquent, l'avantage) de réglage de la main au niveau du système complète.

Microsoft SQL Server 6.0 offre des améliorations de performances avec de grandes quantités de mémoire, multitraitement symétrique, analyse de données en parallèle, améliorations de l'optimiseur et l'entrelacement de nouvelles opportunités de couche de plate-forme. Toutefois, aussi grand que sont ces améliorations, ils sont limitées dans la portée. L'ordinateur plus rapide peut être perde vers le bas avec requêtes inefficaces ou une application mal conçue. Par conséquent, même avec l'augmentation des performances supplémentaires qui permet à SQL Server 6.0, il est extrêmement important optimiser la base de données, index, requête et la conception de l'application.

La plupart des problèmes de performances ne peuvent pas être résolus avec uniquement un focus côté serveur. Le serveur est essentiellement un «puppet» du client, qui contrôle quelles requêtes sont envoyées, et donc quels verrous sont obtenues et libérés. Bien que quelques réglages est possible sur le côté serveur, la résolution des problèmes de performances dépend généralement accuser réception que joue le rôle dominant le client dans le problème et analyser le comportement de l'application client.
Plus d'informations
Voici quelques suggestions qui, en fonction de rencontrer, appelez le des gains de performances significatifs :

Normaliser la conception de base de données logique

Raisonnable de normalisation de la conception logique de la base de données donne de meilleures performances. Un plus grand nombre de tables étroites est caractéristique d'une base de données normalisée. Un nombre moindre de tables larges est caractéristique d'une base de données dénormalisée. Une base de données normalisé est régulièrement associé à des jointures relationnelles complexes, qui peuvent nuire au performances. Toutefois, l'optimiseur de SQL Server est très efficace en sélectionnant des jointures rapides et efficaces, tant qu'index efficaces sont disponibles.

La normalisation présente les avantages suivants :
  • Permet d'accélérer le tri et la création d'index, tables étant plus étroites.
  • Permet à plusieurs index ordonnés en clusters, car il n'y a plus de tables.
  • Index ont tendance à être plus restrictif et plus compact.
  • Moins d'index par table, aidant les performances de UPDATE.
  • Moins de valeurs NULL et moins redondantes des données, l'augmentation de la base de données souci de compacité.
  • Réduit l'impact de simultanéité de diagnostics DBCC, car les verrous de table nécessaire affecteront moins de données.
Avec SQL Server, raisonnable de normalisation souvent permet plutôt que de performances hurts. Au fur et à mesure que la normalisation augmente, cela le nombre et la complexité des jointures nécessaires pour récupérer les données. Sous la forme d'une règle d'or grossière, Microsoft vous suggère de portant sur le processus de normalisation, sauf si cela provoque des nombreuses requêtes pour que les jointures quatre voies ou supérieures.

Si la conception logique de la base de données est déjà fixe et total reconception n'est pas possible, qu'il est possible de normaliser sélectivement une table volumineuse si analyse indique un goulot d'étranglement sur cette table. Si l'accès à la base de données est effectuée à l'aide de procédures stockées, ce changement de schéma avoir lieu sans impact sur les applications. Si ce n'est pas le cas, il est possible de masquer la modification en créant un affichage qui ressemble à une seule table.

Utilisez une conception efficace d'index

Contrairement à nombreux systèmes non relationnelles, les index relationnels ne sont pas considérés comme des faisant partie de la conception de base de données logique. Index peuvent être ignorés, ajoutées et modifiés sans affecter la conception de schéma ou de l'application de la base de données de quelque manière que ce soit autre que les performances. Conception efficace d'index est primordiale dans arriver à de meilleures performances de SQL Server. Pour ces raisons, vous devez hésitez pas à expérimenter différents index.

L'optimiseur choisit de manière fiable l'index le plus efficace dans la majorité des cas. La stratégie de conception d'index global doit être pour fournir une bonne sélection d'index à l'optimiseur et approuver afin de le mettre à la bonne décision. Cela permet de réduire le temps d'analyse et que vous donne des bonnes performances sur un large éventail de situations.

Recommandations de conception d'index sont les suivantes :
  • Examinez la clause WHERE de vos requêtes SQL, car c'est le principal objectif de l'optimiseur.

    Chaque colonne répertorié dans la clause WHERE est un candidat possible pour un index. Si vous avez trop de requêtes pour examiner, choisissez un ensemble représentatif, ou seulement celles lentes. Si votre outil de développement génère de façon transparente des code SQL, c'est plus difficile. La plupart de ces outils autorisent la journalisation de la syntaxe SQL générée pour un fichier ou un écran fins de débogage. Vous souhaiterez peut-être savoir à partir fournisseur de l'outil de si une telle fonctionnalité est disponible.
  • Utiliser les index étroits.

    Les index étroits sont souvent plus efficace que les index multicolonnes, composés. Les index étroits ont plus de lignes par page et moins de niveaux d'index, un renforcement des performances.

    L'optimiseur peut rapidement et efficacement analyser des centaines ou voire de milliers de possibilités d'index et de jointure. Avoir un plus grand nombre d'index étroits fournit à l'optimiseur avec plus de possibilités pour choisir à partir, ce qui permet généralement de performances. Avoir moins larges index multicolonnes fournit à l'optimiseur avec moins possibilités pour choisir à partir, qui peut nuire au performances.

    Il est souvent préférable de ne pas adopter une stratégie d'accentuation d'une requête entièrement recouvert. Il est vrai que si toutes les colonnes dans votre clause SELECT sont traitées par un index non ordonnés en clusters, l'optimiseur peut reconnaître ce et fournir de très bonnes performances. Toutefois, cela souvent se traduit dans les index excessivement larges et trop dépend de l'éventualité que l'optimiseur utilise cette stratégie. En règle générale, vous devez utiliser les index étroits plus nombreux qui fournissent souvent des meilleures performances sur un plus grand nombre de requêtes.

    Vous ne devriez pas avoir d'index plus vaste que sont nécessaires pour atteindre des performances de lecture adéquates en raison de la surcharge impliquée dans la mise à jour de ces index. Toutefois, même la plupart des opérations de mise à jour et orienté impliquent beaucoup plus de lecture que l'écriture. Par conséquent, n'hésitez pas à essayer un nouvel index si vous pensez qu'il va aider ; vous pouvez toujours déposez-le ultérieurement.
  • Utiliser les index ordonnés en clusters.

    Utilisation correcte des index ordonnés en clusters peut augmenter considérablement les performances. Opérations même UPDATE et DELETE sont souvent accélérées par index ordonnés en clusters, car ces opérations impliquent beaucoup lecture. Un seul index ordonné en clusters par table est autorisé, par conséquent utiliser judicieusement cet index. Requêtes qui retournent plusieurs lignes ou des requêtes impliquant une plage de valeurs, sont de bons candidats pour accélération par un index ordonné en clusters.

    Exemples :
          SELECT * FROM PHONEBOOK      WHERE LASTNAME='SMITH'      -or-      SELECT * FROM MEMBERTABLE      WHERE  MEMBER_NO > 5000       AND MEMBER_NO < 6000						
    En revanche, les colonnes LASTNAME ou MEMBER_NO mentionnés ci-dessus sont probablement pas de bons candidats pour un index non cluster si ce type de requête est courant. Essayez d'utiliser des index non ordonnés en clusters sur les colonnes où peu de lignes est renvoyées.
  • Examinez l'unicité de la colonne.

    Cela vous aide à décider quelle colonne est candidate à un index ordonné en clusters, index non ordonné en clusters ou pas d'index.

    Voici un exemple de requête pour examiner l'unicité de la colonne :
          SELECT COUNT (DISTINCT COLNAME)      FROM TABLENAME						
    Ceci renvoie le nombre de valeurs uniques dans la colonne. Comparez cette option pour le nombre total de lignes dans la table. Sur une table de ligne de 10 000, 5 000 valeurs uniques rendrait la colonne un bon candidat pour un index non ordonnés en clusters. Sur la même table, des valeurs uniques 20 sont mieux répondre à un index ordonné en clusters. Trois valeurs uniques doivent être indexés pas du tout. Voici des exemples uniquement, pas les règles durs et rapides. N'oubliez pas de placer les index sur les colonnes individuelles, répertoriées dans les clauses WHERE des requêtes.
  • Examinez la distribution des données dans des colonnes indexées.

    Une requête de longue durée d'exécution se produit souvent car une colonne avec quelques valeurs uniques est indexée, ou une jointure sur une colonne de ce type est effectuée. Ceci est un problème fondamental avec les données et la requête elle-même et ne peut généralement pas résoudre sans identifier clairement la situation. Par exemple, un répertoire téléphonique physique trié par ordre alphabétique en fonction du nom de famille ne pas accélérer recherchant une personne si toutes les personnes dans la ville sont nommés simplement «Smith» ou «Martin». Parallèlement à la requête ci-dessus, ce qui donne une illustration unique d'unicité de la colonne, vous pouvez utiliser une requête GROUP BY pour voir la distribution des données des valeurs de clé indexées. Cela fournit une image de résolution plus élevée des données et une meilleure perspective pour la façon dont l'optimiseur consulte les données.

    Voici un exemple de requête pour examiner les données de distribution des valeurs de clé indexées, en supposant une clé de deux colonnes sur COL1, COL2 :
          SELECT COL1, COL2, COUNT(*)      FROM TABLENAME      GROUP BY COL1, COL2						
    Elle retournera une ligne pour chaque valeur de clé, avec un décompte des instances de chaque valeur. Pour réduire le nombre de lignes renvoyées, il peut être utile exclure certains avec une clause HAVING. Par exemple, la clause
          HAVING COUNT(*) > 1						
    Exclut toutes les lignes qui ont une clé unique.

    Le nombre de lignes renvoyées dans une requête est également un facteur important dans la sélection d'index. L'optimiseur considère qu'un index non ordonné en clusters au moins une page d'e/S par ligne retournée de coût. À cette vitesse, elle devient rapidement plus efficace pour analyser l'intégralité du tableau. Il s'agit d'une autre raison pour limiter la taille du jeu de résultats ou pour rechercher le résultat volumineux avec un index ordonné en clusters.
Ne correspondent pas toujours l'utilisation des index avec bonnes performances et l'inverse. Si l'utilisation d'un index a toujours produit les meilleurs résultats, travail l'optimiseur serait très simple - toujours utiliser n'importe quel index disponible. En fait, les choix incorrect de récupération indexée peut entraîner de très mauvaises performances. Par conséquent, tâche l'optimiseur consiste à sélectionner la récupération par index dans lequel il va améliorer les performances et éviter récupération indexée où nuire au performances.

Utilisez une conception de requête efficace

Certains types de requêtes sont naturellement gourmandes en ressources. Ceci est lié à base de données fondamental et index problèmes courants pour la plupart des systèmes de gestion de base de données relationnelle (SGBDR), pas spécifiquement à SQL Server. Elles ne sont pas inefficaces car l'optimiseur implémentera les requêtes de manière plus efficace possible. Toutefois, ils sont gourmandes en ressources et la nature orientée sur un ensemble de SQL peut rendre apparaissent inefficace. Aucun degré d'intelligence de l'optimiseur ne peut éliminer le coût en ressources inhérent de ces constructions. Elles sont intrinsèquement coûteuses comparées à une requête plus simple. Bien que SQL Server utilise le plan d'accès optimal, il est limité par ce qui est fondamentalement possible.

Par exemple :
  • Grands jeux de résultats
  • IN, NOT IN et ou requêtes
  • Clauses WHERE hautement non uniques
  • ! = opérateurs de comparaison (non égal)
  • Certaines fonctions de colonne, telles que somme
  • Conversions de données ou des expressions dans la clause WHERE
  • Variables locales dans la clause WHERE
  • Des vues complexes avec GROUP BY
Différents facteurs peuvent nécessiter l'utilisation de certains de ces constructions de requête. L'impact de ces va être réduite si l'optimiseur peut limiter le jeu avant d'appliquer la partie gourmandes en ressources de la requête de résultats. Voici quelques exemples.

Gourmandes en ressources :
   SELECT SUM(SALARY) FROM TABLE				

Moins gourmandes en ressources :
   SELECT SUM(SALARY) FROM TABLE WHERE   ZIP='98052'				

Gourmandes en ressources :
   SELECT * FROM TABLE WHERE   LNAME=@VAR				

Moins gourmandes en ressources :
   SELECT * FROM TABLE   WHERE LNAME=@VAR AND ZIP='98052'				

Dans le premier exemple, l'opération de somme ne peut pas être accélérée avec un index. Chaque ligne doit être lu et additionné. En supposant qu'il existe un index sur la colonne ZIP, l'optimiseur va probablement permet cela pour initialement restreindre le jeu avant d'appliquer la somme de résultats. Cela peut être beaucoup plus rapide.

Dans le deuxième exemple, la variable locale n'est pas résolue jusqu'au moment de l'exécution. Toutefois, l'optimiseur ne peut pas différer le choix du plan d'accès jusqu'au moment de l'exécution ; elle doit choisir au moment de la compilation. Encore au moment de la compilation, lors de la génération du plan d'accès, la valeur de @ VAR n'est pas connue et par conséquent ne peuvent pas être utilisée comme entrée de sélection d'index.

La technique détaillée d'amélioration consiste à restreindre le jeu de résultats avec une clause AND. Comme technique d'alternative, utilisez une procédure stockée et passer la valeur de VAR @ en tant que paramètre à la procédure stockée.

Dans certains cas, il est préférable d'utiliser un groupe de requêtes simples à l'aide de tables temporaires pour stocker les résultats intermédiaires que d'utiliser une seule requête très complexe.

Jeux de résultats volumineux sont coûteuses sur la plupart des SGBDR. Vous devez essayer de ne pas retourner un grand jeu de résultats au client pour la sélection de données finale par navigation. Il est beaucoup plus efficace pour limiter la taille du jeu de résultats, autorisant le système de base de données exécuter la fonction pour laquelle il a été prévu. Cela réduit les e/S réseau et vous rend l'application plus adaptés pour déploiement sur les liaisons de communication à distance lentes. Il améliore également les performances liées à la concurrence d'accès que l'application évolue vers le haut pour plus d'utilisateurs.

Utilisez une conception d'application efficace

Dans le cas le rôle de la conception de l'application performances de SQL Server ne peut pas être exagérée. Plutôt que le serveur dans le rôle dominant image, il est plus précise à l'image du client comme une entité de contrôle et le serveur comme un puppet du client. SQL Server est entièrement sous la commande du client, ce qui concerne le type de requêtes, lorsqu'elles sont soumises et comment les résultats sont traités. Cela a à son tour un impact majeur sur le type et la durée des verrous, montant de la charge d'e/S et processeur sur le serveur, et par conséquent, si des performances sont bonnes ou mauvaises.

Pour cette raison, il est important de prendre les décisions appropriées lors de la phase de conception de l'application. Toutefois même si vous rencontrez un problème de performances à l'aide d'une application clé en main où les modifications apportées à l'application cliente semblent impossibles, cela ne modifie pas les facteurs essentiels qui affectent les performances, à savoir que le client joue un rôle dominant et de nombreux problèmes de performances ne peut pas être résolu sans apporter de modifications client.

Avec une application bien conçue, SQL Server est capable de prendre en charge des milliers d'utilisateurs simultanés. Avec une application mal conçue, même la plate-forme serveur la plus puissante peut bog vers le bas avec seulement quelques utilisateurs.

À l'aide de l'une des opérations suivantes pour la conception de l'application client apportera les bonnes performances de SQL Server :
  • Utilisez les petits jeux de résultats. Extraction de résultats inutilement volumineux définit (par exemple, des milliers de lignes) pour la navigation sur le client accroît la charge des e/S réseau et du CPU, réduit les capacités d'utilisation à distance l'application et pouvez limiter l'évolutivité multi-utilisateur. Il est préférable de conception de l'application pour inviter l'utilisateur à saisir des entrées suffisantes afin que les requêtes sont soumis qui génèrent des jeux de résultats limités.

    Techniques de conception d'application qui facilitent ceci comprennent la limitation de l'utilisation de caractères génériques lors de la création de requêtes, Mandat de certains champs d'entrée et interdiction improvised requêtes.
  • Utiliser dbcancel() correctement dans les applications DB-Library. Toutes les applications doivent autoriser l'annulation d'une requête en cours. Aucune application ne doit contraindre l'utilisateur à redémarrer l'ordinateur client pour annuler une requête. Pas suite à ce principe peut entraîner des problèmes de performances qui ne peut pas être résolus. Lorsque dbcancel() est utilisée, doit être portée concernant le niveau de la transaction. Pour plus d'informations, consultez l'article suivant dans la base de connaissances Microsoft :
    117143: INF: quand et comment utiliser dbcancel() ou sqlcancel()
    Les mêmes problèmes s'appliquent aux applications de ODBC, si l'appel de sqlcancel() ODBC est utilisé.
  • Toujours traiter tous les résultats jusqu'au dernier. Ne permet pas de concevoir une application ou d'utiliser une application clé en main qui interrompt le traitement des lignes de résultat sans annuler la requête. Cela entraîne généralement lentes et blocage des performances.
  • Toujours mettre en œuvre un délai d'attente de requête. Ne pas autoriser les requêtes à exécuter indéfiniment. Rendre la DB-Library appropriée ou les appels ODBC pour définir un délai d'attente de requête. Dans DB-Library, cette opération terminée avec l'appel dbsettime() et, dans ODBC avec SQLSetStmtOption().
  • N'utilisez pas un outil de développement d'applications qui n'autorise pas un contrôle explicite sur les instructions SQL envoyées au serveur. N'utilisez pas un outil qui génère de façon transparente des instructions SQL basées sur les objets de niveau supérieur, à moins qu'il fournit des fonctions essentielles telles que l'annulation de requêtes, délai d'expiration de requête et le contrôle de transaction complète. Il est souvent pas possible pour maintenir de bonnes performances ou pour résoudre un problème de performances si l'application tout en lui-même génère «transparent SQL», car cela n'autorise pas de contrôle explicite sur transactionnelle et de verrouillage de problèmes qui sont essentiel à l'image de performances.
  • Ne pas mélanger des requêtes (OLTP) de traitement transactionnel en ligne à la décision et.
  • Ne permet pas de concevoir une application ou d'utiliser une application clé en main qui oblige l'utilisateur à redémarrer l'ordinateur client pour annuler une requête. Cela peut entraîner un grand nombre de problèmes de performances sont difficiles à résoudre en raison de connexions orphelines possibles. Pour plus d'informations, consultez l'article suivant dans la base de connaissances Microsoft :
    137983 : Comment faire pour résoudre les problèmes de connexion orpheline dans SQL Server aux

Techniques d'analyse de faibles performances

Il peut être tentant de résoudre un problème de performances uniquement par le réglage des performances du serveur au niveau du système. Par exemple, la quantité de mémoire, le type de système de fichiers, le nombre et le type de processeurs et ainsi de suite. L'expérience de prise en charge de SQL Server a montré que la plupart des problèmes de performances ne peut pas être résolus de cette manière. Ils doivent être traités par l'analyse de l'application, les requêtes l'application soumet à la base de données et la façon dont ces requêtes interagissent avec le schéma de la base de données.

Tout d'abord isoler l'ou les requêtes sont lents. Souvent, il apparaît qu'une application entière est lente, lorsque quelques seulement des requêtes SQL sont lentes. Il est généralement pas possible de résoudre un problème de performances sans décompose le problème et d'isoler les requêtes lentes. Si vous disposez d'un outil de développement qui génère de façon transparente SQL, vous pouvez utiliser n'importe quel mode de débogage de cet outil de diagnostic disponible ou pour capturer le code SQL généré. Dans de nombreux cas, les fonctionnalités de trace sont disponibles, mais ils ne peuvent pas être ouvertement documentés. Contactez le support technique pour votre application déterminer si une fonctionnalité de traçage existe pour l'analyse les instructions SQL générées par l'application.

Pour les outils de développement d'applications qui utilisent embedded SQL, c'est beaucoup plus facile - le code SQL est ouvertement visible.

Si votre application d'outil ou l'utilisateur final de développement ne fournit pas une fonctionnalité de traçage, il existe plusieurs alternatives :
  • Utilisez l'indicateur de trace 4032 conformément aux instructions fournies dans SQL Server 4.2 x «Guide de dépannage» et SQL Server 6.0 «Référence de Transact-SQL». Ceci permettra la capture des instructions SQL envoyées au serveur dans le journal des erreurs SQL.
  • Surveiller les requêtes via un analyseur réseau tel que Microsoft Network Monitor, qui fait partie de Systems Management Server.
  • Pour les applications ODBC, utilisez le programme d'administration ODBC pour sélectionner le traçage des appels ODBC. Consultez la documentation ODBC pour plus d'informations.
  • Utilisez un utilitaire de côté client tiers qui intercepte l'instruction SQL au niveau des couches de DB-Library ou ODBC. Inspecteur SQL de Lagoon Blue Software est un exemple de cela.
  • Utilisez l'outil d'analyse SQLEye fourni à titre d'exemple dans le CD-ROM Microsoft TechNet. Remarque : SQLEye n'est pas prise en charge par le support technique Microsoft.
Une fois la requête lente est isolée, procédez comme suit :
  • Exécuter la requête lente soupçonné d'être en isolation, à l'aide d'un outil de requête tel que ISQL et vérifiez qu'il est lent. Il est souvent préférable d'exécuter la requête sur l'ordinateur serveur lui-même à l'aide de ISQL et les canaux locaux et rediriger la sortie vers un fichier. Cela permet d'éliminer complicating facteurs, tels que le réseau et d'écran d'e/S et de mise en mémoire tampon de résultats application.
  • Utilisez SET STATISTICS IO ON pour examiner les e/S utilisée par la requête. Notez le nombre d'e/S de page logique. Objectif l'optimiseur d'empêcher globalement l'est de réduire le nombre d'e/S. Notez le nombre d'e/S logique. Ceci constitue une base par rapport à laquelle mesurer l'amélioration. Il est souvent plus efficace pour concentrer exclusivement sur la sortie STATISTICS IO et faire l'expérience de requête différent et indexer les types que d'utiliser SET SHOWPLAN ON. L'interprétation et appliquer efficacement la sortie du SHOWPLAN peuvent nécessiter certaines étudier et peuvent consommer temps peut être passé plus efficacement sur les tests empiriques. Si votre problème de performances n'est pas résolu par ces recommandations simples, vous pouvez utiliser SHOWPLAN pour étudier le plus possible de comportement de l'optimiseur.
  • Si la requête implique une vue ou procédure stockée, extraire la requête à partir de la vue ou une procédure stockée et exécuter séparément. Ainsi, le plan d'accès changent à mesure que vous faites des essais avec différents index. Il permet également de localiser le problème à la requête, par rapport à la façon dont l'optimiseur traite les vues ou procédures stockées. Si le problème n'est pas dans la requête elle-même mais uniquement lorsque la requête est exécutée en tant que partie d'une vue ou procédure stockée, l'exécution de la requête seul permettra de déterminer cela.
  • N'oubliez pas de déclencheurs possibles sur les tables impliquées peuvent générer en toute transparence des e/S que le déclencheur s'exécute. Vous devez supprimer tous les déclencheurs impliquées dans une requête lente. Cela permet de déterminer si le problème se trouve dans la requête elle-même ou le déclencheur ou vue, et par conséquent, vous aide à diriger votre focus.
  • Examinez les index des tables utilisées par la requête lente. Utiliser les techniques répertoriées précédemment pour déterminer si elles sont de bons index et les modifier si nécessaire. Sous la forme d'un effort premier, essayez de l'indexation de chaque colonne dans votre clause WHERE. Souvent les problèmes de performances sont provoqués en n'ayant pas simplement une colonne dans la clause WHERE indexée, ou en n'ayant pas un index utile sur une telle colonne.
  • À l'aide des requêtes mentionnés précédemment, examinez l'unicité des données et de distribution pour chaque colonne mentionnée dans la clause WHERE et en particulier pour chaque colonne indexée. Dans de nombreux cas simple d'inspection de la requête, table, index et données affichera immédiatement la cause du problème. Par exemple, des problèmes de performances sont souvent provoquées par ayant un index sur une clé avec seulement trois ou quatre valeurs uniques, ou effectuer une jointure sur une telle colonne ou retourner un nombre excessif de lignes au client.
  • Selon cette étude, procédez aux modifications nécessaires à l'application, une requête ou un index. Exécutez la requête à nouveau après avoir apporté la modification et observez aucune modification du nombre d'e/S.
  • Après avoir en notant d'amélioration, exécutez l'application principale pour voir si les performances globales sont préférable.
Vérifiez le programme pour le comportement d'e/S ou liées aux UC. Il est souvent utile déterminer si une requête est d'e/S ou de l'UC lié. Cela permet de concentrer vos efforts d'amélioration sur le goulot d'étranglement true. Par exemple, si une requête est lié de l'UC, ajoutant que davantage de mémoire à SQL Server va probablement pas améliorer les performances, car davantage de mémoire améliore uniquement le cache de taux de présence, qui est dans ce cas, déjà élevé.

Procédure pour analyser le comportement d'e/S et requêtes liées aux UC :
  • Utilisez Analyseur de performances pour l'observation d'e/S par rapport à l'activité de l'UC. Regardez toutes les instances du compteur "% temps du disque" du disque logique objet. Également regarder le «total % temps processeur "compteur du système d'objet. Pour afficher des informations sur les performances de disque valide, vous devez avoir précédemment activé le paramètre de Windows NT DISKPERF en émettant "diskperf -Y" à partir d'une invite de commande et le redémarrage du système. Consultez la documentation de Windows NT pour plus d'informations.
  • Au cours de la requête, si le graphique de l'UC est constamment élevé (par exemple, supérieure à 70 pour cent) et la valeur de «% temps du disque» est régulièrement faible, cela indique un état lié aux UC.
  • Lors de l'exécution de la requête, si le graphique de l'UC est régulièrement faible (par exemple, inférieure à 50 pour cent) et "% temps du disque" est constamment élevé, cela indique une e/S liée état.
  • Comparez le graphique de l'UC avec les informations STATISTICS IO.

Conclusion

SQL Server est capable de très hautes performances sur des bases de données volumineuses. Cela est particulièrement le cas avec SQL Server 6.0. Pour obtenir ce potentiel de performances, vous devez utiliser la base de données efficace, index, requête et la conception de l'application. Ces zones sont les meilleurs candidats pour l'obtention d'amélioration des performances significative. Essayez de rendre chaque requête aussi efficaces que possible, afin que lorsque votre application peut prendre en plus grand nombre d'utilisateurs, la charge multi-utilisateur collective est prise en charge. Étude du comportement de l'application client, les requêtes soumises par l'application et l'expérimentation avec des index à l'aide des instructions fournies dans ce document est vivement recommandé. Une approche méthodique à l'analyse des problèmes de performances donnera souvent amélioration significative pour relativement peu investissement de temps.
sql6 4.20 Windows NT optimisation sqlfaqtop

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 110352 - Dernière mise à jour : 12/04/2015 09:57:30 - Révision : 3.1

Microsoft SQL Server 4.21a Standard, Microsoft SQL Server 6.0 Standard, Microsoft SQL Server 6.5 Édition Standard

  • kbnosurvey kbarchive kbmt kbinfo kbother KB110352 KbMtfr
Commentaires