Le fonctionnement de la base Oracle est régi par un certain nombre de processus chargés en mémoire permettant d'assurer la gestion de la base de données.
On distingue généralement deux types de processus :
- les processus utilisateurs (appelés aussi user process ou noyau oracle)
On distingue deux types de processus utilisateurs :
- Oracle Server Code, aussi appelé noyau d'Oracle, est chargé d'interpréter et d'exécuter les requêtes SQL, ainsi que de gérer la mémoire et les fichiers de données
- Code spécifique de l'outil, l'implémentation qui exécute réellement les commandes SQL.
- les processus systèmes (oracle process).
Les processus Oracle (processus système) se classent en deux catégories :
- Les processus serveurs (process server) gérant les requêtes des utilisateurs provenant des connections à la base de données générées par des outils tels que SQL*Plus. Le processus serveur est chargé de la communication entre la SGA et le processus utilisateur. Il permet ainsi d'analyser et d'exécuter
les requêtes SQL des utilisateurs, de lire les fichiers de données et de placer les blocs de données correspondants dans la SGA.
- Les processus d'arrière-plan (background process) chargés d'assurer le fonctionnement interne du SGBD Oracle (gestion de la mémoire, écriture dans les fichiers, ...).
Un processus utilisateur est créé pour chaque programme exécuté par un utilisateur (par exemple Oracle Forms ou Server Manager) afin de fournir
l'environnement nécessaire à l'exécution de celui-ci. Le processus utilisateur ainsi créé communique avec les processus
systèmes à travers le programme interface.
Chaque processus a pour nom ora_nomduprocessus_SID où SID représente le nom de l'instance à laquelle le processus est associé.
Les 4 principaux processus systèmes sont :
- DBWR (DataBase Writer ou Dirty Buffer Writer), le processus chargé d'écrire le contenu des buffers
dans les fichiers de données
- LGWR (Log Writer), le processus chargé d'écrire le contenu des buffers
dans les fichiers Redo Log
- PMON (Process Monitor), le processus chargé de nettoyer les ressources, les verrous et les processus utilisateurs non utilisés
- SMON (System Monitor), le processus chargé de vérifier la cohérence de la base de données et éventuellement
sa restauration lors du démarrage si besoin
Il existe également d'autres processus d'importance secondaire :
- CKPT (CheckPoint), le processus chargé d'écrire le contenu des buffers
dans les fichiers de données
- RECO (Recoverer), il s'agit d'un processus optionnel permettant de résoudre les transactions interrompues brutalement dans un système de bases de données
distribuées (par exemple un système de réplication de bases de données)
- ARCH (Archiver). Ce processus est optionnel et n'existe qu'en mode ARCHIVELOG. Il permet de dupliquer les fichiers Redo-Log dans un espace d'archivage.
- Dnnnn (Dispatcher, nnnn représente une suite de nombre entiers) : Ce processus est optionnel et n'est présent que dans les configurations MTS (multi-threaded server). Il permet de router les requêtes des postes clients-serveurs distants vers les autres serveurs.
Il existe au moins un processus Dnnnn pour chaque protocole de communication
- Snnnn (Server, nnnn représente une suite de nombre entiers) :
Ce processus est n'est également présent que dans les configurations MTS. Il permet de recevoir les demandes de connexions distantes envoyées par le processus Dnnnn d'un serveur distant.
- LCKn (Lock) est un processus de verrouillage utilisé lorsque Oracle Parallel Server est installé.
Le processus Database Writer (DBWR) a pour but de transférer les blocs de données modifiés (appelés dirty blocks) de la System Global Area vers les fichiers de la base de données,
afin de sauvegarder de manière permanente les données de la base. Ainsi, lorsqu'un ordre SQL modifie la base de données (c'est-à-dire lorsqu'une requête SQL DELETE, INSERT ou UPDATE est reçue),
les blocs de données affectés sont modifiés dans le fichier de données associé.
Le rôle du processus LGWR (Log Writer) est de mettre à jour les fichiers journaux (Redo Log) dans la SGA et sur le disque.
Ainsi ce processus est chargé d'écrire le contenu du cache Redo Log de la SGA dans
le fichier Redo Log à chaque fois qu'un ordre COMMIT est réceptionné.
Le processus SMON (System Monitor) est chargé de vérifier la cohérence du système et de la rétablir suite à un incident au démarrage de la base suivant.
Ainsi, si la base n'a pas été stoppée correctement, le processus analyse les informations stockées dans les rollback segments (les rollback segments sont les zones de stockage des opérations n'ayant pas encore été
validées) puis annule toutes les informations en attente mais pour lesquelles aucune validation n'a été enregistrées (appelées deadlocks).
Ainsi SMON a un rôle de libération des ressources utilisées inutilement par le système.
D'autre part SMON surveille les espaces libres des fichiers de la base de données et les réorganise si nécessaire afin de
les défragmenter.
Le processus PMON (Process Monitor) a pour but de récupérer les ressources associées
à des défaillances de processus utilisateurs. Ainsi il supprime les processus en erreur, il annule les transactions n'ayant pas été
validées (par exemple si un client est déconnecté brutalement lors de la transaction); il libère les verrous, et libère
les ressources utilisées inutilement dans la SGA.
|
