Discussion :

[big1]

Bonjour,
sur ma base de données (9.2.0 sous Linux red hat) je suis confronté au problème de performance suivant :
Parse to execute ratio 65%
et cela dès le démarrage de la base.
Je regarde la vu v$sqlarea

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select EXECUTIONS, PARSE_CALLS from v$sqlarea

et je trouve 311 enregistrements avec le rapport Parse/Execute > 60%.
COmment peut-on dans ce conditions repérer la cause de ce "Parse to execute ratio 65%" et l'éliminer car :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
In an operational environment, optimally a SQL statement should be parsed once and executed many times. This alert could indicate poor cursor reuse. Find out what specific SQL statements have a parse count that is equal to the execute count. These statements are contributing to ineffective cursor sharing

D'avance merci.

[pifor]

La cause principale de ce problème est en général la non utilisation des binds variables dans le code SQL, càd l'utilisation abusive de SQL dynamique avec des valeurs littérales en dur au lieu de bind variables: le code est à chaque exécution compilé ("hard parse") au lieu d'utiliser un plan en mémoire qui existe déja ("soft parse") suite à une compilation qui a déjà eu lieu.

Tom Kyte ne dira pas le contraite (c'est un peu son dada ).

Voir par exemple: http://asktom.oracle.com/pls/ask/f?p...:2588723819082

[orafrance]

il faut voir le parametre cursor_sharing (attention c'est pas anodin quand même) et/ou revoir le dév pour introduire plus de variables

[orafrance]

la non utilisation des binds variables dans le code SQL, càd l'utilisation abusive de SQL dynamique avec des valeurs littérales en dur au lieu de bind variables

pourquoi dynamique ??? SQL tout court avec des valeurs en dur plutôt que des variables alors que le cursor_sharing est EXACT plutôt que SIMILAR.

[big1]

Merci à tous pour ces éclaircissements. Je n'ai pas bien compris , vaut-il mieux dans ce cas avoir cursor_sharing en EXACT ou en SIMILAR ?
D'avance merci.

[pifor]

pourquoi dynamique ??? SQL tout court avec des valeurs en dur plutôt que des variables alors que le cursor_sharing est EXACT plutôt que SIMILAR.

Oui: c'est vrai. Le SQL venant du client est toujours par définition dynamique.
Côté serveur, le SQL dans le PL/SQL utilise par défaut les bind variables sauf s'il est construit dynamiquement avec EXECUTE IMMEDIATE sans la clause USING et le paramètre cursor_sharing a la valeur EXACT.

[pifor]

vaut-il mieux dans ce cas avoir cursor_sharing en EXACT ou en SIMILAR ?

Dans votre cas, il est probable que SIMILAR devrait limiter les hard parse.
Mais on ne peut que vous conseiller de le tester sur un environnement représentatif de votre système de production (idéalement une copie complète) et de comparer les temps d'exécutions de l'ensemble des requêtes et le ratio en question. Attention: changer ce paramètre peut améliorer les performances dans certains cas et les dégrader dans d'autres cas...

[bouyao]

J'ajoute seulement, que c'est normal pendant les premiers heures de démarrage de la base que tu a Parse to execute ratio 65%, il faut laisser à Oracle le temps de charger les données dans la mémoire.

[orafrance]

en effet, la base doit subir une période de "rodage" pour monter les objets en cache et parser les requêtes... avant cela, les ratios sont moins significatif