En tant que DBA, résoudre les problèmes de performances est souvent un événement réactif; problème survient, vous devez réagir. Parfois, vous examinez une instance SQL Server que vous connaissez bien, d'autres fois, il peut s'agir de votre première rencontre avec un environnement. Cela se produit également dans le monde du conseil. Lorsque j'aide un client de longue date, j'ai déjà classé les détails sur l'environnement. Cependant, lorsque nous recevons un e-mail de quelqu'un avec qui nous n'avons pas travaillé auparavant, et qu'il s'agit d'une situation d'urgence où ils veulent une aide immédiate, nous n'avons aucune connaissance de l'environnement et n'avons aucune idée de ce dans quoi nous nous dirigeons. Nous fournissons une assistance sans passer par le processus exhaustif de collecte et d'analyse de données qui commence chaque nouvel engagement client.
Pour cette raison, j'ai un ensemble de cinq items que je vérifie immédiatement lorsque je suis confronté à un nouvel environnement. Les informations que je collecte préparent le terrain pour la façon dont j'aborde le dépannage à l'avenir, et bien qu'elles identifient rarement LE problème spécifique, cela m'aide à exclure ce qui n'est PAS le problème, qui est parfois tout aussi important.
Méthodes de collecte de données
Je reconnais que chacun a une approche différente lorsqu'il s'agit d'aborder un nouvel environnement. Il existe plusieurs scripts gratuits et largement disponibles que vous pouvez télécharger et exécuter pour vous donner la "configuration du terrain" pour une instance SQL Server (les scripts DMV de Glenn Berry me viennent à l'esprit). L'accent ici n'est pas comment vous collectez les données, c'est quoi les données que vous collectez et ce que vous analysez en premier .
Propriétés du serveur
La toute première chose que je veux savoir lorsque je regarde une instance est la version et l'édition de SQL Server. Le moyen le plus rapide d'obtenir ces informations est d'exécuter :
SELECT @@VERSION;
Avec cette sortie, je peux vérifier la version pour déterminer les Service Packs, les mises à jour cumulatives et les correctifs appliqués, et je sais quelle édition est utilisée. J'aime aussi savoir si l'instance est en cluster, donc j'exécute également :
SELECT SERVERPROPERTY('IsClustered'); J'ai parfois ces informations du client, mais cela ne fait jamais de mal de vérifier, car la version et l'édition peuvent affecter les étapes de dépannage et les recommandations ultérieures. Par exemple, un client nous a récemment contactés au sujet d'un problème de performances intermittent qu'il a rencontré avec SQL Server 2008. Une vérification rapide de la version a révélé qu'il exécutait SQL Server 2008 SP3, et plusieurs mises à jour cumulatives ont été publiées après SP3 qui traitaient une gamme de les problèmes de performance. Bien que j'aie recueilli plus d'informations avant de leur recommander d'appliquer la dernière CU, cela a été un signal d'alarme immédiat quant à ce qui pouvait causer le problème.
sys.configurations
Cette vue du catalogue aide à construire sur la base commencée avec les propriétés du serveur et nous aide à comprendre comment l'instance est configurée. Avec cette vue, je recherche les paramètres qui ont été modifiés par rapport aux valeurs par défaut, mais qui n'auraient pas dû l'être, et ceux qui n'ont pas été modifié, mais devrait.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Tenez compte du paramètre de mémoire maximale du serveur (Mo), qui limite la quantité de mémoire disponible pour le pool de mémoire tampon. La valeur par défaut est 2147483647, mais elle doit être remplacée par une valeur inférieure à la mémoire totale sur le serveur pour s'assurer qu'il y a suffisamment de mémoire pour le système d'exploitation, d'autres applications et d'autres tâches SQL Server qui nécessitent de la mémoire non extraite du pool de mémoire tampon. . Pour obtenir des conseils sur la définition de la valeur appropriée pour la mémoire maximale du serveur (Mo), je recommande l'article de Jonathan :De combien de mémoire mon serveur SQL a-t-il réellement besoin ?
À l'inverse, le paramètre d'amplification de priorité a une valeur par défaut de zéro et doit toujours être laissé tel quel. En fait, Microsoft recommande de ne pas le modifier, et l'option sera supprimée dans une future version de SQL Server.
sys.databases
Une fois que j'ai compris comment l'instance est configurée, je regarde ensuite ce qui existe au niveau de la base de données.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Lorsque je vérifie la sortie de cette vue de catalogue, je recherche des anti-modèles - tout ce qui apparaît comme inattendu ou atypique - dans les données. La sortie est propice à une analyse rapide - de nombreux paramètres indiquent un 0 ou 1 pour la valeur (off ou on) et je note mentalement ce qui est différent. Je m'attends à ce que les statistiques de création automatique et de mise à jour automatique soient activées (définies sur 1). Je m'attends à ce que la fermeture automatique et la réduction automatique soient désactivées (réglées sur 0). Je regarde quelle est la collation pour les bases de données utilisateur, en particulier si elles ont toutes la même collation et si cette collation est la même que tempdb. Je note également des options de sécurité telles que le chaînage de bases de données croisées et l'option is_trustworthy, toutes deux désactivées (0) par défaut. Si je trouve que l'un de ces paramètres s'écarte de ce que j'attends, je le note et je passe à autre chose. À aucun moment je n'arrête ma collecte ou mon analyse pour apporter un changement, car je collecte simplement des informations aussi rapidement que possible pour avoir une bonne compréhension de l'environnement.
En plus de vérifier les paramètres des bases de données, je prends également note du nombre de bases de données utilisateur. Il n'y a pas de "bon nombre" de bases de données d'utilisateurs pour une instance - une instance peut fonctionner mal avec une base de données, et elle peut fonctionner à merveille avec 100. Il y a une myriade de facteurs en jeu, et le nombre de bases de données est simplement un point de données à noter.
Journaux d'erreurs
J'avoue, j'avais l'habitude de négliger le SQL Server ERRORLOG; c'était comme une réflexion après coup lorsque j'ai enquêté sur un problème de SQL Server. Puis j'ai réalisé l'erreur de mes manières, et je ne l'ai pas prise pour acquise depuis. J'ai tendance à naviguer dans Management Studio pour accéder au journal (dans Gestion | Journaux SQL Server), bien que vous puissiez utiliser la procédure stockée sp_readerrorlog ou parcourir le fichier et l'ouvrir dans votre éditeur de texte préféré.
Dans l'ERRORLOG, je recherche les erreurs récentes – par exemple tout ce qui concerne la mémoire – et je regarde également quels indicateurs de trace, le cas échéant, sont utilisés. Je vérifie également si le verrouillage des pages en mémoire est activé, si le cache est vidé (volontairement ou non) et si une autre activité inhabituelle se produit régulièrement. En fonction de l'urgence du problème, je consulte également les journaux Windows (événements, applications et sécurité), non seulement à la recherche d'erreurs, mais également de modèles de messages inattendus.
Statistiques d'attente
Le dernier domaine de SQL Server que j'examine lorsque j'examine un problème de performances sur une instance inconnue concerne les statistiques d'attente. Chaque instance de SQL Server aura des temps d'attente - peu importe à quel point le code est bien réglé, peu importe la quantité de matériel derrière. En tant que DBA, vous voulez savoir quelles sont vos attentes typiques pour une instance, et lorsque je regarde un nouvel environnement, je ne sais pas immédiatement si les attentes que je vois sont typiques ou dues à un problème de performances. Je demande au client s'il établit des statistiques d'attente de référence, et si ce n'est pas le cas, je demande si je peux les effacer et les laisser commencer à s'accumuler pendant que le problème de performances se produit. Pour vérifier les statistiques d'attente, vous pouvez utiliser le script du message souvent référencé de Paul Randal ou la version des requêtes DMV de Glenn.
Une fois que vous aurez examiné les statistiques d'attente accumulées, vous disposerez de la dernière pièce qui fournit la « vue d'ensemble » de l'instance SQL Server et les informations dont vous avez besoin pour commencer le dépannage. Il n'est pas rare de vérifier d'abord les statistiques d'attente lors du dépannage, mais les attentes seules ne suffisent pas à déterminer ce que vous devez examiner ensuite, à moins que vous ne compreniez également la configuration de base de SQL Server.
Étapes suivantes
Comme je l'ai mentionné plus tôt, il n'y a généralement pas une seule donnée qui vous indique où se situe le problème de performances, ce sont plusieurs points de données obtenus qui vous orientent dans la bonne direction. La façon dont vous capturez ces informations dépend de vous, mais une fois que vous avez examiné la sortie, vous devez avoir une bonne compréhension de la configuration de l'environnement SQL Server, et cette connaissance, combinée aux statistiques d'attente, peut vous aider à décider quoi étudier ensuite. Le dépannage fonctionne mieux avec une approche méthodique, alors commencez par les bases et travaillez, et lorsque vous pensez avoir déterminé la cause première, creusez un peu plus et trouvez un ou deux éléments de preuve supplémentaires qui appuient votre conclusion. Une fois que vous disposez de ces données, vous pouvez faire une recommandation pour améliorer ou résoudre le problème.
