Historiquement, les outils de surveillance du comportement des bases de données Oracle collectent de nombreuses informations, dont une grande partie n’est jamais ou que très peu exploitée, du fait notamment des importantes quantités de données impossibles à gérer pour un humain.
De ce fait, une agrégation est réalisée, permettant une lecture statique beaucoup plus aisée des métriques historisées, mais en même temps beaucoup moins précise dans une logique d’analyse d’incident à postériori.
En effet, toutes ces données sont jointes pour calculer des moyennes. Et c’est le point de départ des imprécisions.
Exemple : une base de données consomme 10 % de CPU toute la première moitié de l’heure, puis tout à coup passe et reste à 90 % de CPU pendant la seconde moitié de l’heure. Si l’on agrège ces données pour estimer la consommation moyenne de CPU sur l’heure, on obtient un taux d’occupation de 50 %.
Ce qui ne reflète pas la réalité, car nous n’avons jamais été à 50 %, soit cinq fois moins dans les premières trente minutes, soit quasiment deux fois plus dans les trente dernières. Mais jamais la CPU n’a été consommée à hauteur de 50 % durant l’heure, alors que c’est la valeur remontée.
De plus, si une stratégie de monitoring et d’alertes est basée sur ces informations, pour prévenir par exemple une consommation de la machine supérieure à 75 %, ces alertes ne seraient jamais déclenchées, alors que la machine a largement dépassé cette limite en fin de période.
Ce qui est présenté ici correspond au fonctionnement actuel des outils qui sont basés sur des intervalles dont la durée est beaucoup trop longue pour permettre une analyse fine d’un dysfonctionnement. C’est la raison principale pour laquelle ces outils sont limités.
On pourra néanmoins utiliser ces éléments pour réaliser à froid une étude des tendances de fond, voire pour un objectif de “capacity planning” souvent très utile.
Mais ramener les statistiques collectées à une période plus courte permet d’affiner grandement l’analyse quand il s’agit de comprendre un incident, par exemple.
C’est pour cela qu’il est important d’accéder à des fréquences de collecte et à une finesse d’information bien supérieures. Cela apporte aux équipes une vision beaucoup plus précise dans une logique de troubleshooting.
Dans ce contexte, les fournisseurs de solutions IT doivent apporter une réponse permettant ainsi aux entreprises d’accélérer considérablement la compréhension, mais aussi de ce fait la résolution d’un problème de performance Oracle, en leur apportant à postériori une lecture dynamique et chronologique du déroulement de l’incident.
Pour y arriver, il est nécessaire de proposer une collecte qui sera stockée pour être rejouée à volonté. Cela permettra aux équipes DBA et applicatives de comprendre et d’apporter des réponses rapides aux métiers et sans équivoques sur les problèmes de performance Oracle qui se sont déroulés quelques heures ou quelques jours plus tôt.
Cette collecte devrait permettre aux équipes de travailler sur deux axes :
– le premier permettant de tenir une fréquence de prise de mesures très élevée (de quelques secondes à quelques minutes),
– le second sur la pertinence des informations techniques collectées, tout en limitant bien entendu l’empreinte sur les temps de réponse et sur le volume de données gérées.
Au final, on pourrait donc imaginer collecter un point toutes les 10 secondes, par exemple, là où les solutions classiques permettent d’estimer “en moyenne” ce qui s’est produit durant une heure ou un quart d’heure.
L’utilisation et l’objectif de ces deux mécanismes d’historisation ne sont donc pas comparables, et dans le cadre d’une analyse et d’un diagnostic a postériori, la finesse d’une telle collecte, rapprochée et pertinente, est un véritable atout.
Cela permet également de présenter rapidement aux équipes le problème de performance rencontré : de manière statique au travers de courbes de consommation, ou dynamiquement pour revivre chronologiquement l’incident Oracle avant, pendant et après.
Par Jean-François MAUPOME, Directeur Associé de D.side Software
