Discussion :

[Doctor Z]

Bonsoir,

Lorsque les temps de réponses d'une base de données sont longs, que
regarder/analyser ?

Merci pour vos réponses.

[lalystar]

Si d'une manière générale, les perfs se dégradent sans qu'on puisse l'imputer à un traitement/requête particulier, je pense qu'il faut se tourner vers les rapports Statspack.


Laly.

[Doctor Z]

Si d'une manière générale, les perfs se dégradent sans qu'on puisse l'imputer à un traitement/requête particulier, je pense qu'il faut se tourner vers les rapports Statspack.


Laly.

C'est à dire ?

[Jaouad]

Est ce que les performances sont bonnes et qu'elles ont chutés ? Voir le paramétrage ou une montée en charge

Est ce que les performances on toujours été longues ? PEFSTAT te donnera des indices .

Est ce que cela concerne également un ou deux traitement ? Dans ce cas la il faut tracer le traitement

[lalystar]

Statspack est un outil qui affiche des rapports de performance au niveau de l'instance : Cf. http://download-west.oracle.com/docs...3/statspac.htm


Laly.

[orafrance]

l'important c'est déjà d'essayer de savoir ce qui a pu déclencher cette baisse des perfs : modification de paramétrage des disques, paramétrage OS, upgrade OS ou RDBMS, livraison d'un nouveau programme, augmentation de la charge, etc... Ensuite, on peut confirmer cette "impression" par des mesures objectives via statpack par exemple

[lalystar]

C'est toujours mieux d'avoir déjà installé Statspack et d'avoir au moins un rapport généré pour une période calme afin d'avoir un point de comparaison lorsqu'il semble que les perfs se sont dégradées...


Laly.

[Doctor Z]

C'est toujours mieux d'avoir déjà installé Statspack et d'avoir au moins un rapport généré pour une période calme afin d'avoir un point de comparaison lorsqu'il semble que les perfs se sont dégradées...


Laly.

Bonjour et merci par avance de vos réponses.

Effectivement, en laissant un rapport avec l'outil Statspack lorsque la base
de données et au mieux de ces performances et que je génère ensuite un
autre rapport lorsque les temps de réponses de celle-ci ont chutté, je pourrai
effectivement avoir un moyen de comparaison et savoir comment réagir.

Cependant, quels sont les problèmes les plus courants ?

Par avance, merci.

[13thFloor]

Bjr,
Les problèmes que j'ai souvent rencontrés en clientèle sont :
- statistiques à rafraîchir (ou à retirer quand elles ont été mises et que les requêtes répondaient plus vite en RBO) si optimiseur=choose ou %_rows
- accroissement du volume de données + jointure hash => io importante (surtout temp), pga_aggregate_target ou hash_area_size trop petite -> augmenter ces paramètres si la ram du serveur le permet et si le serveur ne swappe pas
- index devenu unusable -> à reconstruire
- déséquilibre dans la structure d'un index -> à reconstruire
- rechargement de packages en mémoire -> utiliser dbms_keep et/ou acrroître la shared_pool (impact limité sur les perf)
- présence de lignes chaînées -> move de la table (rebuild des index de la table à effectuer ensuite car ils seront devenus invalides car rowid table modifiés)
- nouvelle requête : à tuner -> vérifier plan d'exécution (sans bind variable si possible), tkprof, hints, indexation, parralélisme... il y a de quo ifaire, le sujet est vaste.

Voila, ce n'est pas exhaustif mais ça peut aider.

Si les perf se dégradent brusquement, un changement a dû intervenir : paramètrage, statistiques, parallélisme sur des tables, nouvelle requête, suppression d'index...

Pense à déterminer quelles sont les attentes subies (au niveau Oracle)pendant les périodes de dégradation.

[thomasjcj]

juste un petit rectificatif sur la liste qui par ailleurs est un bon resumé de problemes classiques!

- déséquilibre dans la structure d'un index -> à reconstruire

C'est un mythe qui a la vie dure!
La gestion de Index B*Tree par Oracle ne peut entrainer de déséquilibre de l'arborescence. L'ajout de nouvelles valeurs dans un indice n'a de conséquences éventuelle que sur le degré de l'arborescence (rajout de niveaux).
Pour infos voir l'article suivant:
http://www.dbazine.com/jlewis13.shtml

[lalystar]

C'est vrai qu'en général je suis assez sceptique sur les politiques de reconstruction systématique d'indexes.

L'ajout de nouvelles valeurs dans un indice n'a de conséquences éventuelle que sur le degré de l'arborescence (rajout de niveaux).

Justement : si tu as un index qui à 6 niveaux ca veut dire que pour accéder à une ligne tu dois faire 6 I/O plus une supplémentaire pour accéder à la ligne correspondante via le rowid.

En général, un index a une profondeur de 3.


Laly.

[Doctor Z]

Merci pour toutes ces précisions, ça me donne une piste pour amorcer une
idée.