Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.

Il y a beaucoup de confusion sur la statistique ‘parse calls‘.
Ce qu’il est important de retenir, c’est qu’elle compte seulement une certain type d’appel à la librairie OCI (Oracle Call Interface – l’API d’accès aux internes natives d’Oracle).
La charge de travail effectuée par un ‘parse call‘ est très variable en fonction des circonstances, et parfois tellement minime qu’il n’y a pas lieu de s’en inquiéter.

Un ‘parse call‘ peut:

• (a) Devoir optimiser la requête car il ne l’a pas trouvée après l’avoir cherchée en library cache.
• (b) Trouver la requête en library cache, mais avoir quand même à l’optimiser pour diverses raisons. Par exemple: le plan d’exécution précédant a été vidé du cache. Ou bien le même texte de la requête s’applique à des objets différents, on fonction de celui qui l’exécute.
• (c) Trouver la requête en library cache, et ne pas avoir à la ré-optimiser parce que le plan est toujours disponible, et que le user a les droits appropriés.
• (d) Passer par le cache des curseurs de la session (session cursor cache) ou celui du moteur pl/sql (pl/sql cursor cache) qui permet d’utiliser un raccourci vers la requête en library cache, sans avoir à faire de recherche.

Lorsque le compteur ‘parse calls‘ est incrémenté, vous devez toujours vous demander si cet appel s’est traduit par la situation (a), (b), (c) ou (d).

Et juste pour embrouiller les choses, oracle peut compter un ‘parse count (hard)‘ sans compter un ‘parse call‘ (voir ici).