Forum aux questions SQL jouent la carte d'Index
Les index SQL peuvent être problématiques, mais si vous les surveillez et que vous restez vigilant, vous devriez les trouver plus facile à gérer.
Paul s. Randal
Le DBA accidentels
Q. Je suis « DBA officieux » ma société. Nous utilisez plus, SQL Server et ont des instances de SQL Server consacrés à l'entreprise et savoir que nous avons besoin d'un réel DBA vous aider à résoudre. Alors que nous allons embaucher une personne, je dois être en mesure de savoir ce que fait que certaines instances s'exécutent plus lentement. Vous avez des recommandations générales pour où dois-je commencer la recherche ?
**R :**Il s'agit d'une excellente question. Il peut être frustrant pour une instance de SQL Server qui n'effectue pas correctement et ne savez pas où commencer à rechercher la cause. Il existe toutes sortes de choses qui pourraient contribuer à une dégradation des performances, afin que j'ai toujours trouver de plus facile de simplement demander à SQL Server lui-même.
SQL Server effectue le suivi de deux ensembles d'informations : les statistiques d'e/S et les statistiques d'attente. Ces éléments vous donneront une idée de localiser le problème.
La plupart des installations de SQL Server de nos jours sont liées aux e/O-(c'est-à-dire que leurs performances sont limité par quelque chose à faire avec la lecture et écriture de données). Le ralentissement peut être un sous-système d'e/S lent, un réseau lent, un SAN la connexion au serveur, mémoire insuffisante sur le serveur est de forcer SQL Server pour échanger des pages dans et hors de la mémoire, une mauvaise stratégie d'indexation ou un ensemble d'autres éléments.
Vous pouvez utiliser la vue de gestion dynamique (DMV) sys.dm_io_virtual_file_stats pour voir ce que SQL Server sait sur le volume d'e/S, des places et des retards pour toutes les e/S vers les fichiers journaux et de données. Vous pouvez trouver le sous-système d'e/S n'est pas la zone réactive, mais les e/S pourrait être le problème. Le sous-système d'e/S peut être mal gérer la charge d'e/S.
C'est là qu'intervient l'autre partie du puzzle : statistiques d'attente. SQL Server effectue le suivi des chaque fois qu'un thread d'exécution doit attendre une ressource disponible et la durée pendant laquelle le thread d'attente. Vous pouvez également travailler hors de la durée pendant laquelle le thread d'attente après avoir été informés de la disponibilité de la ressource, mais avant de pouvoir exécuter sur un processeur. En regroupant ces données, il est facile de voir les zones supérieur à l'origine des temps d'attente pour SQL Server. Cela vous donne un pointeur où commencer à rechercher la cause.
Il s'agit d'une vue d'ensemble de cette méthodologie. Pour une discussion plus approfondie, y compris un script, que vous pouvez utiliser, lisez mon billet de blog »Statistiques d'attente.” Il comporte également les résultats d'une enquête lecteur plus de 1 800 instances de SQL Server et les types d'attente fréquents avec des explications. Récapitulatif : ne pas perdre de temps poking autour de SQL Server jusqu'à ce que vous avez demandé à SQL Server de quoi il réfléchit au problème.
Analyse d'Index manquant
Q. J'ai juste découvert manquant DMV d'index. Maintenant ils me dites, j'ai des centaines de l'absence d'index sur une seule instance de SQL Server. Dois-je simplement créer chacun d'entre eux ou qui va entraîner des problèmes ?
**R :**Ne créez pas immédiatement tous les index sans effectuer au préalable une analyse. Le processeur de requêtes de SQL Server 2005 et versions ultérieures peut déterminer quand un index bénéficierait du plan pour une requête (ou de lot ou une procédure stockée). Cela lors de la compilation du plan de requête.
Chaque fois qu'il détermine qu'un index manquant, il mentionne. Il conserve également count nombre de fois où chaque index manquant pourrait ont été utilisé, ainsi que le potentiel d'amélioration du plan de requête index existait lors de la compilation du plan de requête.
Vous pouvez accéder à toutes ces informations à l'aide de trois DMV (sys.dm_db_missing_index_groups, sys.dm_db_missing_index_group_stats et sys.dm_db_missing_index_details). Il existe également une DMV indique l'index (sys.dm_db_missing_index_columns) sont manquants dans les colonnes dans une table. Les trois premiers DMV sont plus courantes. Ensemble pour que le moyen le plus simple obtenir ces données de requête. Denis Dehenne largement utilisé script »Vous utilisez manquant Index DMV du SQL ?” peut vous aider.
Cette information est précieuse, mais vous devez le prendre avec un peu de recul. Tout d'abord, il existe un bogue potentiel dans l'index manquant DMV. Il peut vous dire à un index existe réellement est manquant. Ce bogue sera corrigé dans la prochaine version de SQL Server. Vous pouvez en savoir plus sur elle dans mon billet de blog »Bogue de DMV index manquant qui pourrait coûter votre tranquillité d'esprit.”
Deuxièmement, le mécanisme qui détermine un index manquant dans le processeur de requêtes considère uniquement si un index est utile pour la requête en cours de compilation. Il ne tient pas compte les conséquences possibles pour les opérations insert/update/delete qui ont besoin de gérer cet index. Cela peut être énorme si la table a proportionnellement beaucoup plus de modifications que lit. Il ne tient pas compte la taille de l'index créé. C'est un compromis que seulement vous pouvez apporter.
Enfin, il recherche le meilleur index absolu aider le plan de requête compilé. Par exemple, il peut être une table avec 30 colonnes et d'un index ordonné en clusters et d'une requête demande 25 des colonnes du tableau. Le mécanisme de détermination index manquants recommanderais de création d'un index non ordonné en clusters pour couvrir la requête de la colonne de 25. Dans la plupart des cas, qui n'aurait aucun sens.
Utilisez les scripts de Duncan pour examiner la sortie des index manquants agrégées. Examinez les index de 10 ou 20 premiers, puis effectuer des analyses pour déterminer si elles sont vraiment utile de créer. La plupart du temps, vous trouverez certains qui ne sont pas utile de créer, elle est toujours intéressant de cette analyse.
Nous ne pouvons pas tout simplement obtenir de ?
Q. Je suis un d'une équipe d'administrateurs dans la société qui traite des différentes équipes de développement d'application. Il y a animosity constante entre les équipes. Il est préjudiciable à l'environnement de travail. Vous avez des idées lisser les relations entre les équipes ?
**R :**Il s'agit d'un problème courant que peut apporter un environnement de travail désagréables avec animosity, méfiance et grudges. Pas du tout contribue à la productivité et souffre de la société. Heureusement, il existe une solution. Il est facile de décrire, mais il est plus difficile à mettre en pratique :
- Vous devez former les uns des autres. Chaque équipe doit comprendre les motivations de l'autre équipe et leur opinion sont leurs limites de responsabilité. Vous serez surpris par ce que chaque équipe pense que l'autre équipe doit faire.
- Chaque équipe doit comprendre les points faibles pour les autres équipes. Cela de manière anonyme, sans faire les choses personnelles.
- Chaque équipe doit ensuite à informer les autres équipes sur la façon dont les autres équipes de travail influe sur les. Par exemple, imaginez la dev team écrit du code, teste uniquement avec un petit ensemble de données, puis la lève sur le mur en production--et qu'elle échoue spectaculaire. Si l'équipe dev s'attend à résoudre et corriger le code, l'équipe DBA, qui est clairement un processus rompu.
Accusé de réception et de comprendre le problème sont le seul moyen pour motiver les deux côtés à oeuvrer à une solution qui rendra l'environnement de travail à des fins pacifiques et productifs à nouveau.
Difficiles à l'indexation
Q. Je suis un administrateur SharePoint, et je sais également un montant juste sur SQL Server. SQL Server 2008 qui héberge nos bases de données SharePoint dispose de beaucoup de fragmentation des index. Ceci affecte les performances de SharePoint. Je sais que je ne peut pas modifier les index, mais y a-t-il quelque chose que je peux faire en plus de devoir constamment les reconstruire ?
**R :**Reconstruction des index en permanence de génère une lourde charge sur SQL Server en termes d'e/S et UC ressources, génération de journal de transactions et potentiellement bloquent d'autres processus. Même la DMV pour déterminer les index fragmentés sys.dm_db_index_physical_stats d'exécution peut être un drain de ressource excessive.
Nombre d'index fragmenté dans un environnement SharePoint car l'utilisation de schéma de base de données SharePoint GUID clustered index clés. Ma femme, Kimberly aborde ceci dans son billet de blog »GUID en tant que clés primaires et/ou la clé de cluster.”
Lorsqu'un index a ce qui est essentiellement une clé aléatoire, index insertions se produisent de façon aléatoire et conduire à un processus appelé fractionnements de page. Une fragmentation de causes page split, qui est un coûteux traiter (consultez mon blog »Le coût sont les fractionnements de pages de journal de transactions ?”). Un fractionnement de page qui se produit lorsqu'une page est complètement saturée, mais d'espace nécessaire sur cette page (par exemple, lorsqu'une instruction insert se produit dans un index avec une valeur de clé aléatoire qui doit être stockée sur cette page). Une nouvelle page est allouée et environ la moitié des enregistrements à partir de la page entière sont déplacée vers la nouvelle page, créant ainsi l'espace libre. C'est le processus de base.
Impossible de modifier les index dans une base de données SharePoint, comme cela briserait le contrat de support. Vous pouvez, toutefois, modifier leur facteur de remplissage par défaut. Lorsque vous créez ou reconstruisez un index, vous pouvez demander à SQL Server de laisser une certaine quantité d'espace libre dans les pages d'index pour permettre des insertions aléatoires. Cela signifie qu'il est plus susceptible de pages d'index déjà que l'espace sur celles-ci pour les nouveaux enregistrements sans nécessiter un fractionnement de page coûteuses. Si un facteur de remplissage des moyens de 80 pages seront remplies à 80 % de capacité lorsque l'index est reconstruit, laissant suffisamment d'espace libre de 20 pour cent.
La question devient alors, « Quel est le meilleur facteur de remplissage? » Malheureusement, il n'existe aucune bonne réponse. Pour un entrepôt de données où les données ne changent pas et qu'il n'y a aucune activité insert de traitement des transactions en ligne, le meilleur facteur de remplissage est généralement la valeur par défaut de SQL Server de 100 (ne c'est-à-dire aucun espace libre).
Pour un environnement OLTP, la réponse dépend de la rapidité avec laquelle la fragmentation se produit et la fréquence à laquelle vous reconstruisez pour supprimer la fragmentation. Il est conseillé de démarrer avec 70 (30 pour cent d'espace libre) et surveiller la fragmentation pour voir si vous avez besoin déformer le haut ou vers le bas, ou maintenance d'index plus ou moins fréquemment.
.jpg)
Paul s. Randal est le directeur général de SQLskills.com, directeur régional Microsoft et MVP SQL Server. Il a travaillé sur le moteur de stockage SQL Server chez Microsoft de 1999 à 2007. Il a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Expert de la récupération d'urgence, de la haute disponibilité et de la maintenance de base de données, il anime fréquemment des conférences. Il blogue SQLskills.com/blogs/paul et vous pouvez trouver lui sur Twitter à twitter.com/PaulRandal.