Discussion :

[nico1973]

Bonjour,

J'ai un soucis sur une requête qui donne des temps de réponse différents sur 2 bases à volumétrie comparable.
Sur une BD la réponse est retournée en quelques ms.Sur l'autre il faut attendre 20s !

Le plan d'exécution est identique sur les 2 BD.
La requête porte sur 3 tables à faible volumétrie ( quelques milliers de lignes)
2 des tables sont montées en cache.
Nous sommes en 9i.

En faisant un set autotrace, je vois que la requête la plus couteuse fait 4.859.377 de consistent gets.Sur l'autre il n'y en a que 2.
Je suppose donc que le problème vient de là.

sinon le hit ratio sur le buffer cache est à 99%.

J'ai isolé des évènements de type "cache" mais je ne sais pas vraiment interpréter ces résultats.

EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT TIME_WAITED_MICRO

row cache lock 9579 1675 518055 54 5180554652
library cache pin 778 1 1944 2 19440706
library cache lock 1204 0 5109 4 51090423
library cache load lock 768 45 23383 30 233834120




J'ai beau chercher dans mes cours de tuning je ne vois pas ce qui peut expliquer ce phénomène.

merci d'avance

Nico

[orafrance]

les données ne seraient-elles pas dans le cache dans le cas le plus favorable grâce à une utilisation différente de l'appli ?

[nico1973]

les données ne seraient-elles pas dans le cache dans le cas le plus favorable grâce à une utilisation différente de l'appli ?

Le problème se produit sur une base de production.
L'autre est une base iso-prod dont avec moins d'activité.
D'ailleurs le test a été fait sur plein d'autres BD et le problème n'est rencontré que sur la PROD .
Comme il y a plusieurs process qui exécutent cette requête en parallèle, certaines durent plus de 1 minutes ce qui provoque un Time-out au niveau de l'appli ( bien sûr il n'est pas envisageable d'augmenter ce time-out , d'autant plus que ça marchait bien jusqu'à présent !)

Ce que je ne sais pas interpréter c'est ce nombre élevé de "consistent get" sur la PROD et pas sur les autres BD.

[orafrance]

La prod exécute plus de requêtes et sollicite donc plus le cache, on peut donc imaginer que les blocs sortent plus vite du buffer contrairement aux autres instances. Les advisors de l'Oracle Manager n'indiqueraient pas un gain à attendre en augmentant le buffer cache par hasard ?

[nico1973]

La prod exécute plus de requêtes et sollicite donc plus le cache, on peut donc imaginer que les blocs sortent plus vite du buffer contrairement aux autres instances. Les advisors de l'Oracle Manager n'indiqueraient pas un gain à attendre en augmentant le buffer cache par hasard ?

Merci.
Effectivement au départ j'avais pensé à un problème de vidage de cache dû à la forte activité de la BD.
Mais si c'était le cas on devrait constaté des lectures physiques au moment ou il remonte les tables en cache.
Or, en en exécutant le SELECT en autotrace, on ne constate ni db_block_gets, ni physical reads.
De plus quand on exécute la requête 2 fois de suite en PROD on constate toujours les mêmes problèmes.
Donc tout ça m'avais laissé supposer que ce n'était pas un problème de montée des données en cache.

[orafrance]

c'est quel type de copie de la base de prod que tu as ?

Tu as lu cet article : http://www.dba-oracle.com/m_consistent_gets.htm ? Visiblement la charge CPU pourrait expliquer ce comportement.

[nico1973]

Bonjour,

Merci pour votre aide.
En fait il s'agissait tout simplement d'un plan d'exécution qui n'était pas optimal ce qui expliquait le temps de réponse.L'ajout de "hint" dans la requête a permis de résoudre le problème.

La différence observée entre les différents bases venait du fait qu'elles ne contenaient pas exactement les mêmes données dans la table sur laquelle était exécutée la requête qui posait problème ( même si la volumétrie était équivalente sur cette table d'où le plan d'exécution identique sur les différents bases) .Il a fallut faire un export/import de la table dans une base de test pour mettre ça en évidence.

Nico