Discussion :

[LoicC]

Depuis que notre base de test est utilisé par un nouveaux pays ayant un volume de données très faible (en comparaison aux pays déja présent) les performances sont catastrophique.

Quand je fait un explain plan avec toad OEM et raptor je ne remarque rien de particulier (aucune évolution, cout raisonable...) pourtant certaines requetes tournent sans jamais s'arréter.

Si je flush la sga ca semble améliorer la situation mais au bout de quelques minutes les problémes reviennent.

J'ai essayé de donner accés uniquement au nouveau pays => méme comportement.

Nous utilisons ORACLE 10gR1 les 40 plus grosses tables sont partitionnées avec comme critére le code pays.

[Mathias44]

Bonjour,

Quand tu dis

Si je flush la sga

et que les performances semblent s'améliorer tu parles de la shared pool j'imagine ? Les variables sont-elles bindées et comment calcules-tu tes statistiques (calcul d'histogrammes?) ? Quelle est la valeur de cursor_sharing ?

[pifor]

Pour analyser un problèmes de performance sur une instance, il faudrait idéalement avoir un rapport Statspack (ou AWR si on a la licence nécessaire) et une analyse par TKPROF d'une session SQL avec la trace activée.

Ne pas oublier non plus que dans certains cas EXPLAIN PLAN ne dit pas la vérité (d'après http://download.oracle.com/docs/cd/B...an.htm#i3305):

19.1.4 EXPLAIN PLAN Restrictions
Oracle does not support EXPLAIN PLAN for statements performing implicit type conversion of date bind variables. With bind variables in general, the EXPLAIN PLAN output might not represent the real execution plan.

From the text of a SQL statement, TKPROF cannot determine the types of the bind variables. It assumes that the type is CHARACTER, and gives an error message if this is not the case. You can avoid this limitation by putting appropriate type conversions in the SQL statement

[fatsora]

Bonjour,

Quand tu dis et que les performances semblent s'améliorer tu parles de la shared pool j'imagine ? Les variables sont-elles bindées et comment calcules-tu tes statistiques (calcul d'histogrammes?) ? Quelle est la valeur de cursor_sharing ?

En 10G tu peux flusher le BUFFER_CACHE

FLUSH BUFFER_CACHE Clause

The FLUSH BUFFER_CACHE clause lets you clear all data from the buffer cache in the system global area (SGA).

[Mathias44]

C'est bien pour cela que j'imagine qu'il s'agit de la shared pool parce qu'observer une amélioration après un flush du buffer cache, personnellement je serais embêté pour trouver une explication !

[pachot]

Bonjour,

Le problème vient probablement du fait que tu utilise une bind variable (ou sinon que tu utilises cursor_sharing=force) pour la requête.
L'optimiseur va choisir son plan d'exécution en fonction de la première exécution: si la valeur de la variable correspond à une petite partition ou à une grande, le plan sera différent. Lorsque tu fais un flush shared_pool, la requête sera reparsée, et fera son choix de plan d'exécution différemment.

La solution dépends de plusieurs choses:
- désactiver le 'bind variable peeking', c'est possible mais non supporté
- changer les requêtes pour avoir la clé de partition en dur au lieu d'une variable
- fixer un plan d'exécution avec les outlines
- etudier les 2 plans d'exécution (quand c'est rapide et quand c'est long)
- ou simplement ne pas partitionner
...

Cordialement,
Franck.

[orafrance]

Je pense plutôt que c'est un problème de plan d'exécution qui reste en mémoire. En effet, on peut imaginer que les requêtes sur les petits volumes font des FTS et si le plan d'exécution est fixé il se tape des FTS même quand ce sont des gros volumes.

Ce qui expliquerait par ailleurs qu'un flush règle le problème