I.5. DEROULEMENT DE TRAITEMENT D'UN ORDRE SQL
Lorsqu'un utilisateur lance une requête de mise à
jour sur la table quelconque, et que plusieurs tuples sont affectés par
la requête. La requête est passée au serveur par le
processus USER. Le serveur (exactement le query processor) vérifie si la
requête existe déjà dans le cache de bibliothèques.
Si non trouvée, elle est analysée, pour vérifier au cache
du dictionnaire les privilèges et les attributs etc..,
générer un plan d'exécution. La représentation
analysée et le plan d'exécution sont alors sauvés dans le
cache de bibliothèques.
Pour les objets affectés par ladite table, on
vérifie si les blocs de données sont dans le cache de tampons de
blocs de données (Database Buffer Cache). Si non trouvés, le
processus USER, les met dans le cache de tampons de blocs de données.
Avant que la mise à jour des tuples soit faite,
`l'image avant' des tuples est écrite sur les segments de rollback par
le processus DBWr. Pendant que le tampon redo-log est rempli durant la
modification des blocs de mise à jour, le processus LGWR écrit le
contenu du tampon redo-log dans les fichiers redo log.
Après la fin de mise à jour, l'utilisateur
valide la mise à jour par un commit. Tant qu'un commit n'a pas
été exécuté, les modifications peuvent être
annulées par un rollback. Dans ce cas, les blocs de données mis
à jour dans le tampon BD sont écrasés par les blocs
originaux sauvés dans les segments de rollback. Si l'utilisateur
exécute un commit, l'espace alloué pour les blocs dans les
segments de rollback est désalloué, et peut être
utilisé par d'autres transactions.
| 
