Nous avons récemment travaillé avec un client pour résoudre les problèmes avec une instance SQL Server. Le client dirigeait SQL Server 2012 sur une machine virtuelle. Les applications en cours d’exécution sur le serveur SQL étaient en cours d’exécution dans les problèmes et le client n’était pas sûr de ce que la cause profonde des problèmes a été.
Initialement, nous avons mis en place la surveillance des applications Web avec le client pour envoyer des alertes si l’application Web a commencé à fonctionner plus lentement que d’habitude, nous faisant ainsi savoir la prochaine fois qu’un problème a été rencontré. En fixant un seuil de délai d’attente pour la vitesse de chargement de la page, nous avons pu identifier différentes périodes où le système semblait avoir un problème d’accès aux données du serveur SQL. En utilisant les alertes intégrées, nous avons reçu des e-mails dès qu’un problème a été détecté.
Ensuite, nous voulions configurer sql server surveillance, nous avons donc aidé le client à installer l’agent MetricsView pour recueillir des données Windows Performance Counter à partir du serveur SQL. Une fois que l’agent MetricsView a été installé avec succès, nous avons été en mesure de recueillir toutes les données qui sont rapportées par Windows Performance Counters, y compris l’utilisation du serveur SQL, l’utilisation du processeur, l’utilisation de la bande passante, l’allocation de mémoire et la disponibilité de l’espace disque disque dur.
En surveillant toutes ces mesures, nous avons établi des seuils maximaux et minimaux pour chaque ensemble de données afin d’être alertés si l’une ou l’autre des mesures critiques dépassait les limites prévues. Ce que nous avons trouvé presque immédiatement, c’est qu’il ne s’agissait pas, en fait, d’un problème SQL du tout, mais d’un problème simple avec la façon dont le serveur virtuel a été créé et les disques durs ont été partitionnés.
Ce client particulier avait créé deux partitions sur le lecteur, la première pour simplement le système d’exploitation et la seconde pour le stockage de données. Ce que nous avons rapidement constaté, c’est que le lecteur OS avait encore quelques journaux SQL sur elle qui aurait vraiment dû être stocké sur le lecteur de données, et les journaux SQL ont été à l’origine du lecteur de frapper sa capacité. L’utilisateur avait plusieurs options pour résoudre ce problème. Ils peuvent augmenter la partition du lecteur virtuel, selon qu’il a été mis en place comme un lecteur dynamique, ou ils pourraient modifier leurs paramètres de serveur sql pour stocker les journaux sur le lecteur de données ainsi que mettre en place la troncature automatique des journaux après une période de temps spécifiée.
Le fait que nous avons pu utiliser plusieurs composants de la suite d’outils Dotcom-Monitor pour aider le client à cerner le problème en dit long sur la capacité de Dotcom-Monitor à aller au-delà de la simple surveillance des temps de disponibilité et d’arrêt que nous avons commencé à effectuer il y a plus de 15 ans. Les outils ont vraiment évolué pour contenir des outils de dépannage et des guides de réglage des performances qui vous aident à obtenir une vue complète à 360 degrés de la performance de votre infrastructure et de son incidence sur vos sites Web et applications Web.
Inscrivez-vous dès maintenant pour un essai gratuit de 30 jours pour surveiller les applications Web et les sites Web,du matériel jusqu’à travers le réseau à la réactivité réelle des serveurs SQL et chaque charge de page à partir de dizaines d’endroits à travers le monde.
