SQLH2 - SQL Server Health and History Tool

SQL Server met à disposition des DBA un ensemble d'outils pour le monitoring des performances en temps réel comme les rapports intégrés, les DMV / DMF à partir de SQL Server 2005 ou encore les performances dashboards. Cependant ces outils ne conviennent plus lorsqu'un DBA doit surveiller un ensemble de serveurs SQL et / ou constituer une base de données de référence de certaines métriques de performances (appelée baseline) destinée à une future analyse. SQLH2 est un outil créé par Microsoft qui peut aider le DBA à la réalisation de ces 2 tâches.

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

SQLH Server Health and history (SQLH2) est un outil de surveillance et de monitoring pour des serveurs de bases de données SQL Server. Il permet de collecter différents types de données concernant les serveurs et les instances SQL Server puis les stocke dans une base de données nommée Repository. Cet outil, développé par l'équipe Microsoft en 2004, a été repris par une équipe développeur sur le site codeplex. La version d'origine a été mise à jour pour supporter un plus grand nombre de fonctionnalités et répondre à une forte demande d'évolution. SQLH2 est un outil gratuit et son code source est mis à disposition. Les possibilités d'amélioration restent donc ouvertes.

II. Les avantages

Pourquoi utiliser SQLH2 ?
Voici un aperçu des avantages qu'offre cet outil :

  • Il n'est pas nécessaire d'installer d'agents de surveillance sur les serveurs.
  • Les ressources monopolisées sont très faibles sur le serveur de surveillance (moins de 1%).
  • L'ajout de serveurs à monitorer ou de compteurs de performances restent une opération relativement simple.
  • Des rapports prêts à l'emploi sont fournis et il est possible d'en ajouter ou développer d'autres selon les besoins.
  • Les architectures 32bits et 64 bits sont pris en charges.
  • SQLH2 est modulaire. Il est possible d'installer chaque partie sur des serveurs distincts.
  • La documentation de configuration ainsi que la documentation technique sont complètes et explicites.

III. Les inconvénients

SQLH2 présente quelques inconvénients qu'il est utile de connaître avant de décider de son utilisation.

  • SQLH2 n'est pas un outil de surveillance en temps réel et n'est pas destiné à cela.
  • Il ne fonctionne pas sur des architectures en cluster.
  • Les versions antérieures à SQL Server 2000 ne sont pas gérées.
  • Il n'existe pas de gestion d'alertes avec cet outil.

IV. Architecture

L'architecture SQLH2 est modulaire. Elle composée de 3 parties distinctes. Deux d'entre elles sont composées d'agents de collecte (SQLH2 Performance Collector et SQLH2) qui fonctionnent avec WMI (Windows Management Instrumentation). WMI est un système de gestion interne de Windows qui prend en charge la surveillance et le contrôle des ressources systèmes à l'aide d'interfaces. La dernière partie concerne le Reporting (SQLH2 Reports) et repose sur une architecture SSRS (SQL Server Reporting Services).

Image non disponible

IV-A. Agent SQLH2 Performance Collector

Cet agent extrait les données des différents compteurs de performance d'un ou plusieurs serveurs à intervalle régulier. Ces données sont ensuite stockées dans un fichier texte. SQLH2 Performance Collector est présent sous la forme d'un service Windows. Lorsqu'un fichier texte atteint une taille limite paramétrée, ce service redémarre et un nouveau fichier est créé.

IV-B. Agent SQLH2

Cet agent extrait des informations matériel et logiciel concernant des instances SQL Server. Les informations collectées sont de plusieurs types et concernent :

  • Les services et fonctionnalités installées sur le serveur
  • Les informations du système d'exploitation, la configuration du serveur SQL ainsi que celle des bases de données.
  • Un historique des périodes d'indisponibilité des instances SQL Server.
  • Les données des compteurs de performance provenant de l'agent SQLH2 Performance Collector (facultatif).

L'agent stocke ensuite les informations collectées dans une base de données (Repository). La collecte et le stockage des données se fait régulièrement à l'aide d'une tâche planifiée prévue à cet effet.

IV-C. Les reporting

La partie Reporting se présente sous la forme de rapports SSRS permettant l'affichage des données collectées. Voici quelques exemples de rapports intéressants :

Rapports des compteurs de performance

Image non disponible

Configuration matériel et logiciel des serveurs

Image non disponible

V. Installation

V-A. Pré-requis

Des pré-requis existent pour le bon fonctionnement de SQLH2. Certains composants doivent êtres installés et configurés avant l'installation de SQLH2 comme :

  • Le Framework 1.1 ou 2.0 minimum selon la version de SQLH2 installée.
  • Un serveur de rapports (SSRS) configuré
  • Les fournisseurs WMI sur chaque serveur. L'activation des fournisseurs WMI se fait par la console d'ajout / suppression de programmes, ajouter ou supprimer des composants windows, outils de gestion et d'analyse et Fournisseur Windows installer WMI

V-B. Installation et configuration

SQLH2 étant modulaire, chaque partie possède ses propres procédures et fichiers d'installation. De la même manière chaque partie peut faire l'objet d'une mise à jour de façon indépendante. Il est possible d'installer chaque partie sur un serveur distinct. Selon la situation un paramétrage supplémentaire peut être aussi nécessaire pour que toutes les parties de SQLH2 puissent dialoguer entre elles.

V-B-1. SQLH2 : (H2Setup.msi)

L'installation crée une hiérarchie de dossiers et de fichiers à la racine nécessaire au bon fonctionnement de SQLH2.

Image non disponible

La configuration de l'agent SQLH2 se fait soit par l'utilitaire de configuration SQLH2 Configuration Utility prévu à cet effet soit directement par le fichier de configuration H2Config.xml.

Image non disponible

Les différents menus permettent de configurer la base de données SQLH2Repository (Menu Repository), de modifier la configuration de l'agent SQLH2 (Menu Config file) ou de lancer l'assistant de configuration (Menu Wizard) pour une configuration automatique et guidée.

Image non disponible

Le menu config File permet de définir la configuration globale de l'agent SQLH2 à savoir :

  • Le serveur qui hébergera la base des données collectées (section Server).
  • Le nom de cette base (section Database).
  • Les serveurs cibles à collecter (section Targets).
  • Le(s) serveur(s) sur le(s)quel(s) se situe(nt) le(s) collecteur(s) de données des compteurs de performance. Il est tout à fait possible d'exécuter plusieurs instances de l'agent SQLH2 Performance Collector.


Exemple de fichier de configuration de l'agent SQLH2

Image non disponible

V-B-2. SQLH2 Collector : (SQLH2PerfSetup.msi et SQLH2Perf.cab)

L'installation crée une hiérarchie de dossiers à la racine et installe une clé de registre nécessaire au bon fonctionnement et au dialogue des agents SQLH2 Performance Collector et SQLH2.

Image non disponible

La configuration de SQLH2 Performance Collector se fait dans le fichier H2PerfConfigFile.xml. Ce fichier est divisé en 2 parties distinctes.

La 1ère partie permet le paramétrage de l'intervalle d'échantillonnage de données collectées (paramètres CollectionIntervalSeconds et RetryIntervalSeconds), la taille maximale du fichier de collecte (paramètre MaxFileSizeMB) et la gestion du format des dates françaises (paramètre UseInvariantCulture).

La 2ème partie permet de définir les compteurs de performance des serveurs qui seront collectés. Par défaut 27 compteurs de performances sont paramétrés pour l'instance locale (paramètres TARGET et PERFCOUNTER).


Exemple d'un fichier de configuration

Image non disponible

V-B-3. SQLH2 Reporting : ReportV2.cab

L'installation de la partie Reporting est la plus simple. La 1ère partie consiste à créer une source de données sur le serveur de rapports configuré au préalable et de copier les rapports livrés sur le serveur. La partie Reporting est maintenant prête à l'emploi.

Image non disponible

V-C. Planification des agents de collecte

V-C-1. Planification de l'agent SQLH2

Par défaut l'agent SQLH2 collecte à la fois les données concernant les instances SQL Server et les données provenant de l'agent SQLH2 Performance Collector. Ceci peut poser un inconvénient majeur car les informations de configuration des instances SQL Server sont plus ou moins statiques par rapport aux informations provenant des compteurs de performance. L'intervalle d'intégration des données dans la base Repository ne peut donc pas être le même pour chaque type d'information.

Une petite astuce existe et consiste à scinder le fichier de configuration de base H2PerfConfigFile.xml en 2 fichiers de configuration distincts où sera gérer les instances SQL Server pour lesquels on veut récupérer les informations d'une part et les compteurs de performances d'autre part. Il suffit ensuite de créer 2 travaux avec une planification différente avec ces 2 fichiers de configuration.

Par exemple :

Un fichier H2Config.xml pour la gestion des informations des instances SQL Server avec une planification d'exécution hebdomadaire avec la commande suivante :

 
Sélectionnez

> SQLH2.exe /CH2Config.xml

(Le commutateur /C permet la prise en compte du fichier de configuration)

Image non disponible


... et un fichier H2ConfigPerf.xml pour la gestion des compteurs de performance avec une planification d'exécution quotidienne toutes les 10 min pendant 24 heures avec la commande suivante :

 
Sélectionnez

> SQLH2.exe /CH2ConfigPerf.xml

(Le commutateur /C permet la prise en compte du fichier de configuration)

Image non disponible

V-C-2. Planification de l'agent SQLH2 Performance Collector

Par défaut les données concernant les compteurs de performances sont collectées toutes les 2 minutes (cf. fichier de configuration). Il est possible de réduire cet intervalle d'échantillonnage au besoin ou d'augmenter la taille maximale du fichier de collecte. Les paramètres de configuration sont pris en compte à chaque redémarrage du service Microsoft SQLH2 Performance collector.

VI. Déinstallation

La désinstallation de SQLH2 et de SQLH2 Collector ne suppriment pas entièrement certains composants installés à savoir :

  • La structure complète des dossiers SQLH2.
  • Les tâches planifiées associées
  • La base de données SQLH2Repository

Cela signifie que certaines données restent préservées et qu'il est possible lors d'une réinstallation à postériori de ne pas repartir avec une base de données vierge. Il faudra cependant en tenir compte dans le cas contraire et supprimer tous ces composants avec la réinstallation.

VII. Retour d'expérience

Le fonctionnement des agents SQLH2 et SQLH2 Performance Collector peut parfois poser quelques problèmes selon l'environnement sur lequel ils opèrent. Voici un résumé des erreurs que j'ai le plus souvent rencontré et qui ne sont pas répertoriés dans la documentation SQLH2. (Une liste de problèmes et de résolution existe également sur codeplex).

La mauvaise gestion des apostrophes :

Si SQLH2 fonctionne parfaitement dans un environnement où la lange par défaut est l'anglais, il n'en est pas de même dans un environnement où la langue par défaut est le français. En effet il est possible de rencontrer des problèmes d'intégration des informations provenant des journaux d'événements si ceux-ci comportent des commentaires en français avec introduction d'apostrophes. La seule solution, pour le moment, est de modifier le code source et de générer un nouvel exécutable SQLH2.exe (Une demande de correctif doit être faite sur CodePlex).

Problème de registre avec les architectures 64 bits compatibles 32 bits :

Sur ce type d'architecture, la clé de registre servant au bon fonctionnement de l'agent SQLH2 Performance Collector et au dialogue avec l'agent SQLH2 pour l'intégration des fichiers peut être installée sur un noeud différent de la ruche que celui prévu par défaut. Dans ce cas, SQLH2 génère une erreur de lecture de clé du registre et l'intégration s'arrête. La seule solution pour le moment est aussi la modification du code source en rajoutant ou modifiant le nouveau chemin de la clé. (Un Hotfix est également prévu sur CodePlex).

De plus, cela signifie qu'à la désinstallation éventuelle de SQLH2, la suppression de la clé de registre n'est pas prise en charge. Il faudra le faire manuellement.

Les informations concernant les versions 2000 de SQL Server ne sont pas collectés :

Ceci est un bug présent dans l'agent SQLH2. Il est possible de modifier le code source pour rajouter la prise en charge de cette version de SQL Server ou d'attendre un hotfix sur CodePlex.

En résumé la résolution des problèmes que j'ai rencontré passe soit par une mise à jour d'un des modules de SQLH2 (ces mises à jour sont disponibles sur le site de Microsoft ou sur CodePlex) soit par la modification du code source.

VIII. Conclusion

SQLH2 est un très bon outil pour la surveillance et la mise en place d'une base de données de référence pour les métriques de performance et ceci pour un ensemble de serveurs SQL. La présence de certains bugs peuvent être un frein à l'utilisation de cet outil mais les modifications restent cependant assez simple à effectuer ou sont déjà résolus avec des hotfix. La facilité d'installation et de configuration de cet outil en font un de ses points forts et la partie reporting par défaut permet de travailler rapidement sur certaines métriques.

Les outils permettant une bonne gestion de la capacité à travers le service informatique pour les entreprises sont devenus indispensables. SQLH2 peut s'inscrire dans cette lignée d'outils !!

IX. Sources webographiques

X. Remerciements

Je remercie Fadace pour la relecture attentive de cet article.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2009 David BARBARIN. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.