Cache "library" (library cache)

Le cache "library" conserve, à des fin de partage, des informations sur les commandes SQL et le code PL/SQL les plus récemment utilisées qui ont été soumis par des utilisateurs de la base de données.

Traitement d’une commande SQL :

Le chargement d'une instruction SQL consomme beaucoup de ressources, c’est pourquoi le cache « library » partagé est utilisé pour optimiser et ne charger une instruction SQL qu'une seule fois pour de multiples exécutions.

C'est le processus serveur associé à la session utilisateur qui exécute l'ordre SQL transmis par le processus utilisateur.
Pour le traitement de l’ordre SQL, un curseur est créé. Il pointe vers une zone mémoire SQL privée allouée dans la mêmoire PGA .

Cette mêmoire privée contient les informations nécessaires pour le traitement du curseur (adresses des blocs contenant les lignes à extraire de la base de données, nombre de ligne renvoyé, ligne courante, état du curseur (ouvert ou fermé), …) . Toutes ces informations ne sont utiles que pour la session utilisateur correspondante, c’est pourquoi elles sont placées dans la mémoire privée PGA et seront écrasées à la fermeture de la session.

N.B : Chaque session utilisateur peut ouvrir plusieurs curseurs à la fois dans la limite du paramètre d’initialisation OPEN_CURSORS.

Le traitement du code SQL se fait en trois phases : Analyse parse, Execute, et Fetch.

Phase1 "Analyse parse" :

Durant cette phase d’analyse, Oracle procède à :

1. une analyse syntaxique de l'ordre SQL (une instruction SQL doit respecter, en effet, des règles en termes d'orthographe et d'ordre des mots SQL reservés).
2. une analyse sémantique: Oracle vérifie l’existence dans le dictionnaire de données des objets référencés dans l'ordre SQL (tables, noms de colonnes …) et les droits de l'utilisateur sur les objets référencés.
3. Oracle détermine Le plan d'exécution (execution plan) permettant d’accéder de façon optimale aux données en s'appuyant sur des statistiques (sur les tables et les index) destinés à l'optimiseur. Ces statistiques permettent par exemple de juger qu'un FULL SCAN (parcours séquentiel) d'une table est parfois plus rentable en termes de coût qu'un accès via index lorsque le nombre de lignes est réduit. Seuls les index contribuant à un temps de réponse optimal seront utilisés.
4. Le plan d'exécution détermine les blocs Oracle contenant les données recherchées.
5. Oracle place, ensuite, la requête SQL dans le library cache
6. Oracle utilise un algorithme de hachage pour calculer une valeur qu'il compare aux valeurs calculées pour les autres ordres SQL disponibles dans le cache. Cette valeur détermine s'il est possible de réutiliser un code déjà mis en cache ou non.

Pour éviter autant que possible l'analyse parse qui consomme beaucoup de ressources, il est nécessaire d'optimiser le code SQL.

Idéalement, le code SQL doit être soumis à travers des procédures stockées . Une procédure stockée présente, en effet, l'avantage de stocker dans le dictionnaire de données (sur disque) le plan d’exécution correspondant.

L’utilisation de procédures applicatives garantit d’avoir le même texte de code SQL et donc la même valeur de hachage. Le code SQL est de ce fait facilement réutilisable. Un développeur doit organiser ses programmes en unités réutilisables et éviter autant que possible d’introduire plusieurs blocs anonymes comportant du code SQL similaire mais générant des valeurs de hachage différentes.

Pour les mêmes raisons, il est conseillé d'utiliser des variables bind dans le code SQL à la place des variables littérales:

Exemples

Select * from emp where empno = 200;
Select * from emp where empno = 300;

Ces deux ordres SQL génèrent deux analyses parse. Pour optimiser, il faudra utiliser une variable attaché (bind) comme suit:

Select * from emp where empno = :num;

Phase 2 " Execute" :

Durant cette phase d'exécution, on cherche les blocs de données contenant l’information demandée par la requête SQL. Le processus serveur effectue:

1. des lectures physiques depuis les fichiers de données sur disque (pour les blocs non trouvés en mémoire),
2. des écritures en mémoire pour ces blocs lus depuis le disque,
3. des lectures en mémoire pour préparer la réponse à la requête SQL.

Ainsi, tous les blocs nécessaires à la requête sont disponibles en mêmoire (Database Buffer Cache) pour extraction des lignes de tables recherchées.

Phase 3 "Fetch" :

Pendant cette phase, les enregistrements (colonnes de tables ..) sont transférés depuis les buffers en mémoire vers le processus utilisateur. La réponse à la commande SQL est ainsi envoyée par le processus serveur vers le processus utilisateur.

Le résultat de l’analyse parse et le plan d’exécution sont conservés dans le cache. Ils ne seront pas recalculés dans les prochaines réutilisations du code SQL ainsi partagé.

Le cache "library" est géré par un algorithme LRU (least recently used) pour retirer les instructions SQL ou PL/SQL qui ne sont plus réutilisées afin de libérer de l'espace pour les nouvelles entrées.

En utilisant cette technique, Oracle tient plus longtemps en mémoire les requêtes SQL fréquemment consultées, améliorant ainsi la performance globale du serveur en minimisant l’analyse parse et le calcul du plan d’exécution.

Le cache "library" est lui-même composé de deux structures :

1. La zone SQL partagée pour stocker et partager les instructions SQL exécutées dans la base de données.
2. La zone PL/SQL partagée pour stocker et partager les dernières instructions PL/SQL exécutées, les informations sur les curseurs explicites, les programmes analysés et compilés (fonctions, procédures, déclencheurs (triggers) et packages).