Discussion :

[temoanatini]

Bonjour,
je sais que le titre peut faire peur et on va se demander s'il ne va pas couvrir 1 000 hectares de connaissance...

Ne vous inquiétez pas, je voudrais juste poser une question sur les "static sql".

Il me semble qu'au niveau perfs, c'est ce qu'il y a de meilleur (même pas de soft parse (si, non ?)).

Je voulais savoir s'il y a d'autre moyen que d'utiliser du PL/SQL pour "arriver" à ne faire "qu' " exécuter et ne pas parser un select par exemple.

[pachot]

Oh oui, bien sûr.
En java par exemple, tu fais un PreparedStatement, avec des variables, puis tu l'exécute autant de fois que tu veux avec des nouvelles valeurs à chaque fois. Et il sera parsé qu'une seule fois.

Dans tous les langages, c'est possible, heureusement !

[temoanatini]

lorsque tu dis qu'il ne sera parsé qu'une seule fois, c'est justement là que j'ai cette petite incertitude...

Il ne sera HARD-PARSÉ qu'une seule fois, c'est bien ça ?
Par contre, avec des valeurs différentes de binding, on aura bien à chaque fois un SOFT PARSE, non ?

[pachot]

prepareStatement() est l'appel qui parse la requête, et qui retourne un curseur.
Cela signifie que le curseur a été lu (parsé) syntaxiquement, puis sémantiquement, et ensuite optimisé, pour établir le plan d'exécution.

Ce parse peut être 'hard' s'il y a tout à faire, ou 'soft' si après la première analyse syntaxique et semantique il apparait comme identique à un SQL déjà optimisé. Ou même pas soft si après analyse syntaxique il est trouvé dans le cache des curseurs de session. Dans tous les cas, c'est un 'parse call'. Qui va être plus ou moins lourd (en latch et en cpu) suivant qu'il est 'hard', 'soft' ou 'session cursor cache hit'

Alors, chaque appel à execute n'a plus rien à parser: le plan d'exécution déjà établi est appliqué avec les valeurs des variables. Exactement comme un programme déjà compilé.

Par contre, avec des valeurs différentes de binding, on aura bien à chaque fois un SOFT PARSE, non ?

Donc non. Pas de parse call du tout. Donc pas de parse ... sauf si entre temps le curseur a été invalidé (pour faire de la place dans le cache ou parce qu'il y a eu du DDL qui remet en cause le plan d'exécution). A ce moment là, pas de parse call (donc pas de 'parse count (total)' incrémenté) mais il y aura un hard parse quand même. Le nom de ces statistiques sont trompeuses. C'est expliqué ici (traduction d'un article de Jonathan Lewis).

Franck.

[temoanatini]

j'avais oublié de fermer ce thread

[Ahmed AANGOUR]

Ou même pas soft si après analyse syntaxique il est trouvé dans le cache des curseurs de session. Dans tous les cas, c'est un 'parse call'. Qui va être plus ou moins lourd (en latch et en cpu) suivant qu'il est 'hard', 'soft' ou 'session cursor cache hit'

Tom Kyte appelle les 'session cursor cache hit' des "softer soft parse".
J'aime bien ce terme...
A noter que pour qu'un curseur soit placé dans le cache des curseurs fermés, il doit avoir été exécuté 3 fois. Le but étant d'éviter de mettre en cache des curseurs qui ne seront exécutés qu'une seule fois.
Le nombre de curseur "cachables" dans la UGA est défini par le paramètre d'instance SESSION_CACHED_CURSORS

Ahmed

[mnitu]

...
A noter que pour qu'un curseur soit placé dans le cache des curseurs fermés, il doit avoir été exécuté 3 fois. Le but étant d'éviter de mettre en cache des curseurs qui ne seront exécutés qu'une seule fois.
...

Je m'imagine que vous allez nous fournir une petite démonstration de ce comportement, n'est pas vrai ?

[Mohamed.Houri]

Bonjour,
je sais que le titre peut faire peur et on va se demander s'il ne va pas couvrir 1 000 hectares de connaissance...

Je voulais savoir s'il y a d'autre moyen que d'utiliser du PL/SQL pour "arriver" à ne faire "qu' " exécuter et ne pas parser un select par exemple.

Il existe quand même une possibilité de faire beaucoup de parse et de remplir la shared pool (library cache) même en n'utilisant que du static PL/SQL.

La question est : savez vous comment ?

Bien respectueusement

Mohamed Houri

[mnitu]

Il existe quand même une possibilité de faire beaucoup de parse et de remplir la shared pool (library cache) même en n'utilisant que du static PL/SQL.

La question est : savez vous comment ?

...

Pour réutiliser un curseur il est nécessaire que le texte de la requête et l’environnement d’optimisation soit identiques.

[Mohamed.Houri]

Pour réutiliser un curseur il est nécessaire que le texte de la requête et l’environnement d’optimisation soit identiques.

Bonjour,

Correct; mais ce n'est pas ceci que je visais.
La situation est telle que nous n'avons aucun 'stand alone' SQL; nous ne faisons qu'utiliser des procédures PL/SQL stockées qui ne contiennent pas du SQL dynamique mais n'empêche que le select suivant

Code :

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

1
2
3
4
 
select sql_text, executions
from v$sql
where executions <= 2;

retourne beaucoup de records. Il existe trop d'instructions dans le shared pool qui ne sont pas re-executées (qui ne sont pas partagées ''shared'').

Le but de cette question est uniquement de transmettre le message suivant:
il ne suffit pas d'utiliser du PL/SQL statique pour être sûr que les bind variables soient correctement utilisées. Il faut aussi être sûr qu'une autre chose
soit bien utilisée. C'est tout simple mais c'est très important.

Bien à vous

Mohamed Houri