Les processus

Le fonctionnement de la base Oracle est régi par un certain nombre de processus chargés en mémoire.

On distingue généralement deux types de processus :

• les processus utilisateurs (appelés aussi user process ou noyau oracle)
• les processus systèmes (oracle process).

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.

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 Oracle (processus système) se classent en deux catégories :

• Les processus serveurs (process server) gérant les requêtes des utilisateurs. 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.

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

• 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 potes clients-serveur distant 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 DBWR

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 processus LGWR

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

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 de les défragmenter

Le processus PMON

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.

Annotations sur cet article
Lire	Ajouter	Devenir membre	S'identifier	Signaler une erreur