Le Result Cache peut amener facilement un gain de performance énorme s’il est bien utilisé: si l’appli fait souvent la même requête avec les mêmes paramètres, il peut suffire de mettre RESULT_CACHE dans la requête ou la fonction pour optimiser cela. C’est beaucoup plus rapide à mettre en oeuvre que de créer un cache au niveau de l’appli, gérer son invalidation, etc.

Mais ce cache n’est pas aussi optimisé que le Buffer Cache, et on peut amener une autre contention lorsque beaucoup de sessions concurrents y accèdent.
Et la raison, c’est qu’il n’y a qu’un seul Latch pour gérer le result cache de l’instance. Le symptôme, c’est une attente sur ‘enq: RC – Result Cache: Contention’

L’analyse complète de cette contention dans la demo.

Le cas le pire: utiliser result_cache avec beaucoup de valeurs différentes, ou lorsque le cache est invalidé souvent. A chaque fois qu’il y a un ‘cache miss’ c’est plusieurs latch exclusifs qui doivent être acquis.

Sur des données statiques, c’est moins grave car le latch n’est pas exclusif sur un ‘cache hit’. Attention: seulement depuis 11gR2. En 11gR1, c’était toujours exclusif.

Donc le Use Case idéal pour Result Cache, c’est plutôt des données statiques (référentiel) accédées souvent – mais pas accédées tout le temps par toutes les sessions !