Il est question dans ce paragraphe de comprendre le processus de traitement d’une requête avant son exécution et ce, afin de nous permettre de mieux comprendre la gestion des ressources mémoires intervenant ainsi que les techniques à mettre en œuvre afin d’optimiser les requêtes et avoir plus rapidement les résultats de vos requêtes.
Pour ce qui est des zone mémoire, le cache library conserve, à des fin de partage et de réutilisation, 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.
Dans le traitement d’une requête, le chargement d’une instruction SQL est très consommatrice en termes de ressources, raison pour laquelle le cache library partagé est utilisée pour optimiser et ne charger une instruction SQL qu’une et une seule fois pour de multiples exécutions.
En effet, 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 (ou une zone mémoire) est crée et pointe vers une partie du PGA.
Figure : le processus de traitement d’une requête.
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.
Le traitement du code SQL se fait en trois phases :
Analyse parse ;
Execute ;
Fetch.
III.3.4.1. 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 réservé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. Cette optimisation ne signifie pas forcément mettre les codes dans une procédure stockées. Ce qu’il faut, c’est limiter les entrées-sorties.
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 attachés (variable bind) dans le code SQL à la place des variables littérales. C’est ce qu’on appelle du SQL Tuning.
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;
a. Oracle Tuning
Le tuning ou la gestion des performances, concerne les différentes configurations sur le serveur afin de le rendre plus productif et rentable. Le sujet étant vaste et d’une importance capitale pour un administrateur de base de données, il sera abordé dans la deuxième partie du module DBA Associate.
Brièvement retenons que le Tuning s’applique à quatre niveaux et qu’Oracle dispose des outils spécifiques pour mener à bien cette tâche délicate pour des meilleures performances du serveur.
Figure : les quatre niveaux du tuning Oracle.
III.3.4.2. 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.
Figure : l’étape Execute.
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.
III.3.4.3. 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).