Afin d'obtenir une vue d'ensemble et des données comparables, ma tâche actuelle consiste à créer une référence de performances pour obtenir des chiffres sur les différentes instances productives de SQL Server.
Mes pensées sont:
- Je souhaite utiliser plusieurs DMV
- Je veux inclure une trace de profileur (plans Exec incl.)
- Je souhaite inclure des données perfmon
Donc, ce que j'essaie de réaliser, c'est une surveillance générale des performances démarrable et arrêtable (également programmable) qui renvoie:
Toutes les informations nécessaires pour identifier le succès des tâches d'optimisation des performances en cours
Quelques chiffres agrégés et simples qui aident à visualiser les progrès à long terme. Esp. pour la gestion ;-)
Plans d'exécution ré-exécutables dans la trace du profileur pour comparer les modifications et améliorations individuelles des files d'attente par des tâches d'optimisation d'index
J'ai trouvé quelques informations décrivant la création de lignes de base de performances. La plupart d'entre eux sont soit très compliqués, soit concentrés uniquement sur l'un des indicateurs de performance souhaités (principalement des données de performance).
L'échantillon / description le plus correspondant était le suivant: Création d'une ligne de base de performances pour SQL Server
La question est:
Quelqu'un a-t-il de l'expérience dans la création rapide de ce type de moniteur de performances?
la source
Réponses:
Plus d'un an plus tard, je veux que tout le monde connaisse mon expérience et le résultat final de cette question / sujet.
J'ai commencé par créer des choses par moi-même. Au départ, j'ai suivi l'article Collecter et stocker les données historiques du compteur de performances SQL Server avec les CMV de Tim Ford pour obtenir quelque chose et l'étendre avec toutes les données que je voulais collecter. Donc, une fois par jour, j'exécute plusieurs procédures stockées sur chaque serveur SQL qui collectent des informations spécifiques à partir des DMV et stockent les résultats sur le serveur local à l'intérieur d'une base de données. Cela inclut l'utilisation d'index, les index manquants, les entrées de journal spécifiques comme la croissance automatique, les paramètres du serveur, les paramètres de la base de données d'application, la fragmentation, l'exécution des travaux, les informations du journal des transactions, les informations sur les fichiers, les statistiques d'attente et plus encore.
De plus, j'ai ajouté les résultats d'exécution régulière de sp_blitz de Brent Ozar à ce référentiel pour collecter des indications supplémentaires utiles pour travailler, améliorer et signaler.
Toutes les données sont ensuite collectées à partir de là dans un serveur SQL de surveillance dédié et de cette façon, je crée un magasin groupé pour obtenir des informations pertinentes sur les performances de tous mes serveurs et l'utiliser comme base pour les enquêtes et les rapports.
Ensuite, j'ai créé des feuilles Excel et des rapports en utilisant des services de reporting pour analyser et interpréter. Certains échantillons:
J'ai également configuré certains compteurs de performances de surveillance à l'aide de TYPEPERF inspiré de l'article « Collecter des données de performances dans une table SQL Server » de Fedor Georgiev.
À partir de mon instance de surveillance SQL, je déclenche typeperf pour exécuter et collecter un nombre configurable d'échantillons avec un intervalle d'échantillonnage configurable et stocker les résultats dans ma base de données de surveillance centrale.
Cela me permet d'observer les valeurs de performance à long terme, échantillon:
Après un certain temps à utiliser cela pour collecter des informations de base, il s'est avéré que beaucoup de travaux de maintenance devaient être consacrés à la recherche des travaux échoués, des procédures de débogage (par exemple, dans le cas où une base de données était mise hors ligne, certains scripts ont échoué), le maintien des paramètres après le remplacement d'un serveur ...
De plus, la base de données collectant tous les enregistrements elle-même nécessite une maintenance et un réglage des performances, donc des travaux supplémentaires sont nécessaires pour garder les données utiles ...
Ce qui manque finalement complètement, c'est la capacité de regarder les choses qui se produisent en direct. Dans le meilleur des cas, je serai en mesure de dire ce qui se passait peut-être le lendemain après l'exécution des collecteurs de données. De plus, tous les détails manquent. Je n'ai pas accès aux graphiques de blocage, je ne peux pas regarder les plans de requête des requêtes qui s'exécutaient dans un délai suspect ...
Tout cela m'a poussé à facturer la gestion pour dépenser de l'argent pour une solution professionnelle que je ne suis pas en mesure de créer par moi-même.
Le choix final a été d'acheter SentryOne car par rapport aux autres, il est convaincant et fournit de nombreuses informations nécessaires pour identifier nos points faibles.
En conclusion, je conseillerais à quiconque cherche des réponses à une question similaire de ne pas essayer de créer des choses par lui-même tant que vous n'avez pas un petit environnement fondamentalement sain en place. Si vous avez quelques systèmes et beaucoup de problèmes, mieux vaut opter immédiatement pour une solution professionnelle et utiliser l'assistance du fournisseur sur vos problèmes au lieu de dépenser beaucoup de temps et d'argent pour créer quelque chose de moins utile. Cependant, cette route était toujours très intéressante et m'a fait apprendre beaucoup de choses que je ne veux pas manquer.
J'espère que vous trouverez cela utile une fois que vous aurez rencontré ce fil de questions.
EDIT 20 avril 2017: Brent Ozar a récemment publié l'article suivant sur Facebook qui est une sorte d'approche similaire adoptée par l'équipe SQL Tiger: https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining -rapports-déchaînés-pour-surveillance-entreprise /
la source
Voici quelques bons articles avec des exemples pratiques que vous pouvez trouver ici:
Comment détecter les problèmes de performances de SQL Server à l'aide de lignes de base - Partie 1 - Introduction
Comment détecter les problèmes de performances de SQL Server à l'aide des lignes de base - Partie 2 - Collecte des métriques et des rapports
Comment détecter les problèmes de performances de SQL Server à l'aide de lignes de base - Partie 3
Alors que la partie 1 vous fournira quelques connaissances de base sur ce qu'est la base de référence, dans la partie 2, vous pouvez trouver des informations sur la façon de le faire vous-même en utilisant la méthode "pauvre" (c'est gratuit et bon pour l'apprentissage)
La partie 3 fournit quelques exemples sur la façon dont vous pouvez établir des lignes de base et comment utiliser les lignes de base pour résoudre certains problèmes via ApexSQL Monitor
la source
En tant que DBA assez récemment créé sous le pistolet, j'ai exécuté toute la gamme d'outils gratuits et fait des expériences dans l'espace payant (DPA, SQL Sentry et Foglight) et cela dépend vraiment de ce que vous voulez pour l'outil.
D'après mon expérience, la chose la plus importante n'était pas seulement de communiquer des références de performance (la direction s'en fichait à moins qu'il y ait quelqu'un pour crier), mais de produire quelque chose dans un format facile à consommer qui clarifiait les priorités et était capable de suivre les performances problèmes de production.
Vous pouvez absolument développer vos compétences en empruntant la voie gratuite et les outils pour SQL Server sont excellents.
Avec ces bases de données / tables et travaux et temps supplémentaires, vous pouvez créer un système de surveillance de base (mais ce n'est pas joli) ce sont des outils pour les administrateurs de base de données; à moins que vous ne soyez bon en matière de BI, vous aurez du mal à trouver du temps pour en produire des informations utiles pour les entreprises, bien que l'application Ozar sp_blitz soit plutôt cool.
Après avoir passé environ un an à faire le truc gratuit et à résoudre de nombreux problèmes (mais sans obtenir beaucoup d'adhésion), j'ai pu préciser, après un problème majeur, que le logiciel de surveillance des performances était une priorité, et nous allions l'acheter venez l'enfer ou les hautes eaux.
Après avoir fait la démonstration des clients mentionnés ci-dessus, j'ai choisi DPA parce que la direction pourrait facilement consommer les résultats, bien que j'ai certainement des licences client pour SQL Sentry Plan Explorer Pro (1000% en valeur) et que j'aimais vraiment utiliser la version serveur, cela ne les a tout simplement pas saisis de la même façon.
J'ai également essayé de faire fonctionner SQLNexus à un moment donné mais j'ai fini par travailler beaucoup plus que ce qui m'intéressait, cela peut convenir à vos besoins.
la source
Pour créer rapidement une référence de performances afin d'obtenir des chiffres sur les différentes instances de sql productives, j'utiliserais un essai gratuit d'un outil tiers comme Solarwinds Database Performance Analyzer.
la source
Lis ce livre!!! Tacklebox SQL Server
Il vous montre comment utiliser les requêtes SSIS et TSQL pour collecter des informations de surveillance sur toutes les instances SQL Server de votre environnement.
la source
Je suivais un itinéraire similaire à certaines des affiches ci-dessus, mais je suis tombé sur quelque chose créé par Microsoft.
Il a été mentionné ci-dessus brièvement, mais aucun lien explicite n'a été fourni. L'équipe Microsoft Tiger a développé le «Tiger Toolbix» qui est téléchargeable à partir d'ici: https://github.com/Microsoft/tigertoolbox
Une vidéo Youtube explique la Tiger Toolbox: https://www.youtube.com/watch?v=bx_NGNEz94k
Il y a également https://github.com/sqlcollaborative/dbareports
la source