Discussion :

[Pomalaix]

Bonjour

La question est toute simple : quels indicateurs suivez-vous pour affirmer que vos bases de données se portent bien ?

Au stade artisanal, on aurait tendance à compter le nombre de coups de fil :si les utilisateurs se manifestent, c'est qu'il y a un problème. Sinon, on considère que tout va bien.

Au stade industriel, il est évident que le mode réactif associé à ce pragmatisme candide ne convient plus. On doit définir des SLA, anticiper les extensions de matériel, identifier les problèmes de performances, la hiérarchie demande qu'on lui fournisse "des courbes de l'activité des bases", etc.
On a alors besoin de 2 éléments : des mesures et des seuils de bon fonctionnement, que l'on associera à des informations extérieures du type "aujourd'hui, la compta a effectué sa clôture trimestrielle".

Par exemple, pour une voiture, on peut suivre la consommation, et dire qu'elle doit se situer entre 6 et 8 litres aux cent. Je suis à 11 litres, mais je suis en plein embouteillage et j'ai mis la clim à fond, donc la valeur exceptionnelle est justifiée.

Un médecin suivra le rythme cardiaque, et dira peut-être qu'une valeur normale se situe entre 50 et 80 battements par minute.

Et pour Oracle, quels sont vos 3 indicateurs clés pour juger de la bonne santé de votre base ?

[orafrance]

Nous on a plusieurs outils :
- Data grid control : si il y a un soucis c'est tout de suite visible
- Perfstat : surtout pour traiter le top 10 des requêtes consommatrices
- v$system_event et v$session_wait : rien de mieux pour détecter les contentions
- alertSID.log : ça peut lever des loups sympa (contention sur REDO par exemple)
- log des process : un sid_dbw.log ou un sid_lgwr.log ça peut montrer des choses très intéressante

Edit : je ne me fie que peu aux ratios

[LeoAnderson]

En fait, s'il s'agit simplement de "prendre le pouls", je me contente des ratios, d'un petit coup d'oeil aux waits (juste voir s'il y en a un qui est démesuré) et une lecture en diagonale de l'alert et des traces. (genre le médecin de famille qui doit faire un certificat médical à un patient qui veut s'inscrire à un club de pétanque le dimanche)
C'est facile à faire, rapide et on a une idée globale correcte.

Par contre, après, si on commence à avoir des doutes et/ou si on a des impératifs de résultats (sportif professionnel de haut niveau), alors là, on passe aux soins intensifs avec la panoplie que propose fred_d.
j'y rajouterais également un statspack.

Mais là, ça dépend réellement de chaque sportif... (sur une base DWH tu ne surveille s pas les mêmes choses que sur une base transactionnelle)

[aline]

Bonjour à tous,

En plus des outils mentionné, j'en affectionne particulierement 1.
Il s'agit de cacti qui nous donne des stats sur l'état du serveur sur lequel sont nos très chères bases.
Rien de tel qu'une page web avec l'historique des espaces, de la charge machine (load + cpu) ainsi que du nombre de connections en cours pour nous dire si on est dans des cas habituels ou non.

[Pomalaix]

Bonjour, et merci pour vos réponses.

Les formules que tu proposes, Fred, restent des solutions manuelles, et ne sont pas transposables en une mesure.

Ce que je cherche se rapproche, dans le principe, de ce que propose Aline.
Mon problème est dans le choix des indicateurs numériques (maxi 5 je dirais), et dans la définition des valeurs limites acceptables.

Dans l'idée, j'aimerais pouvoir dire quelque chose du genre :
Si la somme des attentes non idle par heure dépasse 6 minutes, alors il y a anomalie, et il faut investiguer.

[bouyao]

Moi j'utilise Patrol.

Je définis les seuils : Normal, Warning et Alerts. Dès qu il y'a un problème une lumière s'allume et quand il y a plusieurs problèmes j'ai un superbe arbre de Noel.

Il faut diviser les alertes ou les indicateurs en trois parties :

Normal : OK
Warning : Attention
Alert : Il faut faire tres attention

En plus il faut distingué dans les alertes deux catégories :

Pas grave (ca peut être un problème de performance par exemple)
très grave (ca peut être un disque plein, ...)

un exemple : ICI

[orafrance]

avec seulement 5 indicateurs j'vois mal comment on peut assurer que la base n'a pas de problème

[Pomalaix]

Moi j'utilise Patrol.
un exemple : ICI

Oui, dans ma boîte on utilise aussi Patrol et Tivoli.
Donc côté alertes en temps réel, y a pas de problème, on a l'information.

L'objectif c'est de constituer un historique sur plusieurs mois ou années qui permette de répondre à ces deux questions :
- quelle était la charge de la base à telle date
- quelle était la performance de la base à telle date

Idéalement, je voudrais faire ça sans recourir à un outil particulier. Par contre, je peux tout à fait m'appuyer sur les tables de statspack pour extraire de l'information.

Tout le problème, comme je le disais plus haut, réside dans le choix d'un nombre réduit d'indicateurs pertinents.

nombre de sessions
nombre de bascules de redo par heure (rend compte de la charge en écriture)
... (suggestions bienvenues !!)

Pour les performances, on peut envisager de mesurer le temps d'exécution d'une requête ou d'une transaction type. L'ennui, c'est qu'une requête factice (la même pour toutes les bases) risque de ne pas être très pertinente.
Et une requête spécifique pour chaque application n'est pas une idée très engageante...