Chaque requête SQL que vous envoyez à un serveur doit passer par trois (quatre – en cas de SÉLECTION) étapes. Tout d’abord, Oracle recherchera un hachage SQL correspondant dans le cache de la bibliothèque. Si le hachage est trouvé, il récupérera simplement le plan d’explication associé et l’exécutera. Sinon, une analyse difficile est appelée – >, ce qui signifie que les étapes suivantes doivent être exécutées.

1. ANALYSER
   • vérification de la syntaxe
   • vérification de la sémantique
   • vérification des privilèges
2. BIND
   • remplace les variables bind/host par des valeurs réelles
3. EXEC
   • exécution réelle basée sur un plan explain
4. FETCH (instructions SELECT uniquement)
   • renvoie un jeu de résultats à un utilisateur

Permettez-moi d’expliquer chaque phase dans l’exemple suivant.

Vous avez exécuté cette requête:

SELECT *FROM employee;

Le processus serveur générera un hachage pour la requête SQL issues. Le hachage est une valeur hexadécimale générée à partir du texte de la requête SQL. Voici la partie très importante!! Même le moindre changement (majuscule à minuscule et vice versa; ajout / suppression d’un espace; …) changera le hachage et pourrait donc générer une analyse dure (plus sur l’analyse dure vs analyse douce ci-dessous). Vous devez être très prudent et essayer de vous en tenir à un seul code – c’est pourquoi les procédures fonctionnent le mieux (en plus de cela – elles utilisent principalement des variables de liaison qui génèrent des requêtes identiques aux yeux d’Oracle).

Vous pouvez facilement le vérifier par vous-même en exécutant les requêtes ci-dessous:

-- first run this querySELECT * FROM dual;-- then run this one again with all uppercase lettersSELECT * FROM DUAL;-- check the sql hashes SELECT sql_id, sql_text, hash_valueFROM v$sqlWHERE 1=1AND lower(sql_text) LIKE '%select%from dual%'; sql_id | sql_text | hash_value--------------------------------------------------0x735fvggtnu6 | SELECT * FROM DUAL | 37411111103vyt9wdmca69b | SELECT * FROM dual | 1724193067-- As you can see Oracle evaluated it as two different queries.

Une fois le hachage généré, Oracle vérifie si cette requête a déjà été exécutée dans cette instance. Comment ? En vérifiant si le hachage existe déjà dans la zone SQL.

En supposant que cette requête n’est pas encore disponible, une zone SQL sera créée avec la valeur de hachage pour cette requête et l’Oracle lancera la première étape du traitement de la requête et c’est l’ANALYSE.

• Lors de la vérification de la syntaxe, Oracle vérifiera si la requête est syntaxiquement correcte (SELECT au lieu de SELECT; l’ordre correct des commandes – > SELECT* FROM table ORDER BY col1 WHERE col2=’John’; etc.).
• L’étape suivante consiste à vérifier la sémantique où Oracle vérifie si les noms de colonnes et les noms d’objets sont corrects. Comment ? En les recoupant avec le cache du dictionnaire de données
• À la dernière étape de l’étape d’ANALYSE, Oracle vérifie si l’utilisateur/l’application dispose des autorisations correctes pour accéder aux objets interrogés.

Une fois cela terminé, la zone SQL est valide et un autre outil d’Oracle appelé OPTIMIZER générera un plan d’exécution – cela signifie que l’OPTIMISEUR décidera de la façon dont la requête sera exécutée. Une fois le plan de meilleure exécution sélectionné, Oracle lie toutes les variables et passe à la troisième étape – l’exécution.

Que va-t-il se passer ici ? Oracle lira les blocs de données liés aux objets interrogés et les amènera dans le cache tampon (s’ils n’y sont pas encore présentés. S’ils sont là, Oracle ne les relira plus !). Ce processus va générer des E / S (ce qui, comme je l’ai mentionné dans l’article Architecture informatique, est très lent par rapport à la lecture de la mémoire). Je vais m’arrêter ici pendant un moment et insister sur la génération d’E / S. Dans le cas d’une analyse douce, toutes les données sont lues dans la mémoire (cache tampon), ce qui est beaucoup plus rapide que de les lire à partir d’un disque. C’est pourquoi vous devez vous efforcer de recycler / réutiliser vos requêtes autant que possible. Chaque modification d’une requête générera un nouveau hachage et générera donc très probablement des E / S. Tout cela est toujours géré par le processus du serveur.

Maintenant, que les données sont déjà dans la mémoire (cache tampon), l’instruction SELECT est traitée et l’étape finale (RÉCUPÉRATION) est déclenchée et le jeu de résultats est renvoyé à l’utilisateur.

Si la même requête est à nouveau exécutée, le hachage est généré et, comme la zone SQL de ce hachage existe déjà, l’étape d’ANALYSE est ignorée et seuls EXEC et FETCH sont exécutés.