Performances des bases de données : trois signaux pour identifier les problèmes

Problèmes de performances : ce qu’il faut considérer

Il existe différents problèmes de performances. Cela complique ainsi leur identification et les raisons premières du problème. Il est par exemple possible que les structures des bases de données ou le code de l’application soient défectueux dès le départ. Une mauvaise décision liée à la conception et des commandes SQL mal codées peuvent alors être une source de dégradation des performances.

Cela peut aussi provenir d’un système pourtant bien conçu, mais dont les modifications récurrentes ont affecté les performances. L’ajout de données ou d’utilisateurs ou encore la variété des patterns d’accès peuvent aussi ralentir la meilleure des applications bâties sur des bases de données. Et même, les opérations de maintenance, voire leurs absences, peuvent y contribuer.

Ces problèmes de performances peuvent être détectés par trois signaux :

• Le ralentissement des applications. L’indication la plus révélatrice est lorsque les applications qui ont des performances généralement élevées fonctionnent moins vite. Cela peut par exemple être le cas des systèmes transactionnels en ligne utilisés par les clients et les employés, ou des batchs qui traitent les données pour du reporting mensuel. Il peut être difficile de monitorer les performances sans outils de gestion adéquats. Dans ce cas, les DBA ont recours à d’autres méthodes pour détecter les problèmes - les plaintes des  utilisateurs, qui rapportent des écrans figés ou des données qui ne chargent pas, par exemple. 

• Panne des systèmes. Lorsqu’un système est en panne, il est évident que les performances globales sont dégradées. Les pannes peuvent être causées par des problèmes des bases de données, comme le manque d’espace de stockage, l’augmentation du volume de données ou le manque de ressources allouées.
• Mises à jour fréquentes du hardware. Les entreprises qui mettent constamment à jour leurs serveurs, avec plus de mémoire et de capacités de stockage sont généralement de bons clients à des ajustements des performances.  Ajuster les paramètres, les commandes SQL et ré-organiser les objets dans la base peut être bien moins couteux que de ré-investir dans du nouveau matériel.

D’un autre côté, l’ajout d’équipement peut parfois être une solution aux problèmes de performances des bases de données. Mais avec les bons outils de monitoring et de gestion, il est possible de minimiser ces coûts de mise à jour en identifiant les causes du problème et les solutions possibles. Par exemple, il peut être plus économique d’ajouter davantage de mémoirs ou d’intégrer des supports de stockage plus rapides pour résoudre un problème de goulet d’étranglement des I/O. Cela est moins couteux qu’un remplacement de serveur.

Les problèmes que les outils peuvent contribuer à gérer

 Lorsque des problèmes de performances apparaissent, il est fort peu probable que les raisons premières soient identifiées d’emblée. Un DBA a la capacité de traduire quelques vagues feedbacks utilisateurs en problèmes concrets susceptibles de dégrader les performances. Mais cela est une opération difficile, qui peut être jonchée d’erreurs, surtout si le DBA ne dispose pas d’outils automatisés pour le guider.

La collecte des bons indicateurs en matière d’usage des bases et identifier les problèmes spécifiques – lorsqu’ils apparaissent – sont certainement ce qui fait la force des outils de gestion des performances. Une fois un retour utilisateur remonté, le DBA peut s’appuyer sur son outil pour comparer les métriques anciennes et récentes. Au lieu de chasser la cause première du problème à la main, l’application examine rapidement la base de données et livre son diagnostic.

La plupart de ces outils peuvent également être utilisés pour mettre en place des paliers de performances, qui, une fois atteint, alertent le DBA d’un éventuel problème, ou modifie la couleur d’un indicateur. Les DBA ont également la possibilité de programmer périodiquement des rapports sur les performances afin d’identifier ce qui doit être réglé. Certains outils, plus avancés que d’autres, peuvent à la fois identifier et contribuer à résoudre les problèmes.

Imaginons un scénario : un utilisateur appelle le DBA pour lui indiquer que l’affichage d’une application répond moins rapidement que d’habitude. Le DBA, armé de son outil de gestion des performances, examine les paliers et recherchent des alertes. En passant en revue les paliers, il peut alors identifier les goulets d’étranglement et trouver la réponse adéquate. Sans outil, il ne sait pas où chercher. 

Parce qu’il existe une grande variété de problèmes susceptibles d’affecter les performances, les outils avancés proposent un arsenal de fonctionnalités. Parmi les plus critiques, on retrouve :

• Passer en revue les performances du code SQL et pouvoir l’optimiser ;
• Analyser l’efficacité des indexes ;
• Considérer l’espace de stockage et défragmenter les disques si nécessaire ;
• Contrôler et gérer l’utilisation des ressources ;
• Simuler la production en environnement de test ;
• Analyser les causes premières.  

Ne plus attendre pour optimiser les performances

Les entreprises qui déploient des outils de gestion de la performance de SGBDR peuvent aussi éviter des périodes prolongées en mode dégradé. Ces outils peuvent en effet limiter le temps nécessaire à résoudre les problèmes, voire aider les entreprises à éviter toutes formes de problèmes et de pannes.  Ils permettent ainsi à un DBA de passer d’un stade réactif à celui de proactif. Au lieu d’attendre la remontée d’un symptôme, les problèmes sont rapidement identifiés et corrigés, soit par le DBA ou automatiquement par l’outil.

A cela s’ajoutent d’autres capacités : ils peuvent aider les entreprises à gérer des niveaux de services, révélateurs des comportements opérationnels. La gestion du SLA garantit que les applications se comportent comme défini, en appliquant les bonnes ressources, et le bon budget, selon leur importance dans l’entreprise. Ces outils de gestion de performance aident les DBA à monitorer et gérer la disponibilité et les temps de réponse des processus.