• Le Database Buffer Cache
Il stocke les blocs de données les plus récemment utilisées. Lorsqu’Oracle est amené à exécuter une requête SQL et à ramener son résultat à l’utilisateur, il vérifie si ses données (et donc blocs) existent dans le database buffer cache. Si ce n’est pas le cas, Oracle lit les blocs de données qu’il faut à partir des fichiers de données, les places dans le cache selon l’algorithme LRU (en libérant de l’espace s’il le faut par élimination des blocs les moins récemment utilisées) et les renvoie à l’utilisateur. Le paramètre DB\_CACHE\_SIZE désigne la taille du cache, il doit être naturellement un multiple de la taille d’un bloc de données. À noter qu’un bloc de données au DB Buffer cache (appelé aussi tampon) peut avoir un de ces quatre états : - Free bloc jamais utilisé, et donc disponible. Etat de tous les blocs juste après démarrage de l’instance. - Dirty bloc modifié, mais non encore écrit sur le fichier de données. - Pinned bloc accédé couramment. - Clean bloc prêt à être libéré.
• Le Redo Log Buffer Ce buffer
contient les mises à jour effectuées sur les données, et donc toutes les informations relatives à toute transaction réalisée par les utilisateurs. Il est écrit séquentiellement (ce qui provoque un mélange de transactions) et de manière cyclique ; taille limitée de la zone mémoireoblige. Chaque modification correspond à une entrée redo écrite dans le buffer (redo entry). Une entrée redo est composée de plusieurs vecteurs de changement chacun correspondant à la modification d’un bloc de données unique de manière à ce que la nouvelle valeur ainsi que l’ancienne y soient enregistrées. Le contenu du buffer est écrit par Oracle dans les fichiers de journalisation (Redo Log Files) pour garantir la récupération des données en cas de crash du système. Il est à noter que la taille du buffer redo log est définie par le paramètre LOG\_BUFFER.
• Le Pool Partagé (Shared Pool)
C’est une zone mémoire composée de deux structures ; le Library Cache et le Dictionary Cache. Le Library Cache contient les informations sur les requêtes SQL les plus récemment utilisées. Une requête SQL y est stockée sous trois formes ; le texte, sa version compilée, ainsi que son plan d’exécution. Naturellement, le Library Cache a une taille limitée, c’est pour cela qu’il stocke uniquement les requêtes les plus récentes en utilisant l’algorithme LRU (Least Recently Used). Il en découle qu’une requête SQL exécutée pour la première fois est stockée dans le library cache avec son plan d’exécution. Lorsque cette requête est exécutée de nouveau, Oracle ne perd de temps supplémentaire ni pour une deuxième analyse syntaxique et sémantique, ni pour trouver le plan d’exécution optimal. En effet, il retrouve la requête sous ses trois formes (cités ci-dessus) et l’exécute rapidement. La deuxième zone mémoire du pool partagé est le Dictionary Cache. En effet, lorsqu’une requête est analysée, Oracle a besoin d’accéder au dictionnaire de données pour voir si la table existe, si les colonnes sélectionnées ou conditionnées en font partie, si l’utilisateur a le droit de manipuler cette table etc. Toutes ces informations nécessaires à l’analyse de la requête SQL sont stockées dans le Dictionary Cache. Il est à noter que la taille du pool partagé est définie par le paramètre SHARED\_POOL\_SIZE.
* Les fichiers de contrôle
Ils contiennent des informations de contrôle sur la base de données tel que : - Le nom de la base de données. - Les noms, les chemins et les tailles des fichiers de données et de journalisation. - Les informations de restauration de la base de données en cas de panne. Le fichier de contrôle est primordial pour que l’instance soit lancée correctement. En effet, cette dernière y lit les chemins de fichiers de données, ainsi que ceux des fichiers de journalisation (et d’autres informations nécessaires au lancement). Si ce dernier est endommagé, la base de données ne peut pas être chargée même si les autres fichiers physiques sont intacts. C’est pour cela qu’il est possible (et recommandé) de multiplexer le fichier de contrôle sur des endroits différents du disque dur. Il est à noter que les informations des fichiers de contrôle peuvent être examinées à partir de la vue V$CONTROLFILE.
* Les fichiers de données
Ce sont les fichiers physiques qui stockent les données de la base sous un format spécial Oracle. Les fichiers de données sont logiquement regroupés en structures logiques appelées tablespaces. Une base de données comporte au moins deux fichiers de données relatifs à deux tablespaces différents réservés par Oracle (SYSTEM et SYSAUX, ce dernier étant apparu en Oracle 10g). Ces deux tablespaces ne doivent logiquement contenir aucune donnée applicative. A titre indicatif, le tablespace SYSTEM inclut le dictionnaire de données ainsi que le code PL/SQL (fonctions, procédures etc.). En revanche, une organisation parmi tant d’autres consiste à réunir les tables qui portent sur le même contexte (comptabilité, gestion de stock, gestion de personnel etc.) dans un même tablespace ; le résultat est d’avoir des données regroupés par application/contexte. A noter que les vues DBA\_TABLESPACES et DBA\_DATA\_FILES incluent toutes les informations respectivement relatives aux tablespaces et aux fichiers de données de la base.
La requête suivante liste les fichiers de données utilisés dans la base triés par les tablespaces : REQ 1 SELECT tablespace\_name, file\_name FROM DBA\_DATA\_FILES ORDER BY tablespace\_name; Un fichier de données est un ensemble de blocs d’une taille donnée (4 Ko, 8Ko, 16 Ko etc.). Le bloc de données est la petite unité d’E/S utilisée par Oracle et un fichier de données a forcément une taille qui est multiple de la taille du bloc. Logiquement, un tablespace (étalé sur un ou plusieurs fichiers de données), est un ensemble de segments. Un segment est l’espace occupé par un objet base de données dans un tablespace, il y en a quatre types : - Segment de table : espace occupé par une table - Segment d’index : espace occupé par un index - Segment d’annulation : espace temporaire utilisé pour stocker les données nécessaires à l’annulation d’une transaction, ainsi qu’à la lecture cohérente des données. - Segment temporaire : espace temporaire ou sont stockées des données temporaires utilisées lors d’un tri, d’une jointure, lors de la création d’un index etc. En effet, les principaux types d’objets appartenant à un utilisateur (constituant un schéma) sont les tables, les index, les vues, les synonymes, les séquences et les programmes PL/SQL. Parmi ces différents types d’objets, seuls les tables et les index1 consomment de l’espace disque en dehors du dictionnaire de données.
Plus précisément, ils occupent de l’espace mémoire sur les fichiers de données. Les autres types d’objets n’ont qu’une définition stockée dans le dictionnaire de données.
Publicité
Un segment est à son tour composé de structures logiques appelées extensions. Une extension est un ensemble de blocs contigus dans un même fichier de données, tandis qu’un segment peut être étalé sur plusieurs extensions chacun sur un fichier unique. Un bloc de données est la plus petite unité physique d’E/S des données. Sa taille est définie via le paramètre DB\_BLOCK\_SIZE.
La Figure 2 présente un tablespace composé de deux fichiers de données. Le tablespace inclut trois segments A, B et C. Les segments A et B incluent chacun deux extensions chacune sur un fichier différent, pendant que le segment C inclut une seule extension.
* Les fichiers de journalisation
Tout d’abord, faisons un petit rappel sur la notion de transaction ; une transaction est un ensemble d’opérations (requêtes) de mises à jour (insert, update et delete) qui finit par un COMMIT (validation) ou un ROLLBACK (annulation). La validation/annulation concerne tout le bloc de mises à jour (l’ensemble des opérations) depuis un COMMIT/ROLLBACK ultérieur ou depuis le début de la connexion. Une transaction finit donc par un COMMIT/ROLLBACK ou par une déconnexion de l’utilisateur qui vaut un COMMIT si c’est une déconnexion normale et un ROLLBACK si elle ne l’est pas.
Quant un utilisateur Oracle opère des mises à jour sur les données, celles-ci sont non seulement exécutées mais aussi sauvegardées dans les fichiers de journalisation. Cette mesure de sécurité primordiale permet en cas de crash du système de reconstituer les données perdues à partir des informations sauvegardées dans les fichiers de journalisation. C’est d’ailleurs la raison pour laquelle ces fichiers sont multiplexés et/ou copiés. En d’autres termes, même si un fichier de journalisation est irrécupérable, Oracle peut compter sur sa (ou ses) copie(s). Un ensemble de fichiers journaux multiplexés constitue un groupe de fichiers de journalisation. Si par exemple un groupe inclut trois fichiers journaux, alors ces trois fichiers incluent exactement les mêmes informations, ils sont appelés membres d’un groupe. Il existe au minimum deux groupes de fichiers journaux et ils sont écrits de manière cyclique, c.-à-d., que si les fichiers d’un premier groupe sont pleins, Oracle passe au deuxième groupe et y écrit (dans chaque membre) les transactions nouvellement exécutées quitte à écraser les transactions existantes (voir la Figure 4). La vue V$LOGFILE contient toutes les informations qui concernent les fichiers journaux de la base de données.
Il inclut l’ensemble des paramètres de configuration qui conditionnent l’initialisation de l’instance, et ensuite son fonctionnement. Il est accédé lors du démarrage de l’instance, il inclut entre autres le chemin du fichier de contrôle ainsi qu’un ensemble de paramètres instanciés définissant la manière avec laquelle l’instance va démarrer (notamment la taille des différentes structures mémoires de la SGA).
Il existe deux types de fichiers paramètres, le classique PFILE (Parameter File) et le nouveau (depuis la version 9i) SPFILE (Server Parameter File). Une instance Oracle démarre sur un seul fichier paramètre, par défaut sur un SPFILE.
* Les processus
Les processus Oracle permettent aux différentes composantes du serveur d’interagir et d’échanger entre elles ainsi qu’avec l’utilisateur. Il existe des processus utilisateurs du côté des clients, un ou plusieurs processus serveurs du côté du serveur assurant la communication avec le client et plusieurs processus d’arrière plan qui assurent le bon fonctionnement de l’instance.
1. Les processus-utilisateur et le processus-serveur L’interaction entre les clients et le serveur de base de données est assurée par le processus utilisateur du côté client et par le processus serveur du côté du serveur. En effet, lorsqu’un utilisateur démarre une application (SQL\*Plus, Oracle Enterprise Manager, une application Developer Forms etc.), Oracle démarre un processus utilisateur que ce soit sur sa machine distante s’il s’agit d’une architecture client-serveur ou sur un serveur middle-tier sur une architecture multi-tier. Par la suite, une connexion entre le processus utilisateur et l’instance est initiée et maintenue. Une fois la connexion établie, l’utilisateur ouvre une session en s’identifiant (saisie de son nom d’utilisateur et de son mot de passe). Il est à noter que plusieurs sessions peuvent être ouvertes en même temps, ces sessions peuvent être ouvertes par le même utilisateur. Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est le paramètre SESSIONS. Après l’ouverture d’une session, Oracle démarre un processus serveur sur le serveur base de données, c’est ce processus qui se chargera d’exécuter les requêtes de l’utilisateur et de maintenir une interaction entre le client et le serveur. Un serveur base de données est soit configuré en mode dédié, soit en mode partagé. Lorsque le serveur est configuré en mode dédié, Oracle crée sur le serveur pour chaque utilisateur (et donc pour chaque processus utilisateur) un processus serveur. En mode partagé, plusieurs processus utilisateurs peuvent partager un seul et unique processus serveur. Le mode par défaut est le mode dédié, pour activer le mode partagé, il suffit de modifier le paramètre SHARED\_SERVERS dont la valeur par défaut est 0. La nouvelle valeur indiquerait le nombre de processus serveurs partagés démarrés lorsque l’instance est lancée. 2. Les processus d’arrière plan
Les processus d’arrière plan sont utilisés par Oracle afin de maximiser la performance de l’instance. La majorité des processus d’arrière plan sont lancés lorsque l’instance démarre, certains d’entre eux pourraient être lancés après, lorsque l’instance en aura besoin. Il est à noter que certains processus fonctionnent en plusieurs exemplaires, c’est pour cela que leur nom finit par n qui signifie le numéro de l’exemplaire du processus.
* Le processus DBWn
Publicité
est le processus qui écrit le contenu du cache des données dans les fichiers de données (Database Writer). Le DBW écrit les tampons (buffers) modifiés, dits dirty dans les fichiers de données sur le disque.
Un administrateur Oracle peut spécifier jusqu’à 20 exemplaires de DBW.
si la base de données connait une forte charge transactionnelle.
si non spécifié, Oracle se charge d’affecter le nombre d’exemplaires qui convient selon le nombre de processeurs du serveur
La tâche du DBW est de « nettoyer » le cache des données
Ce processus se déclenche :
-Lorsque le nombre de block dirty attient un certain limite.
-Un processus serveur ne trouve pas de tampons clean après qu’il ait scanné un nombre seuil de tampons.
-Après une certaine période pour faire avancer le point de reprise. Le point de reprise(checkpoint).
On peut se trouver donc dans l’un de deux cas suivants :
Le data base writer écrit des modification non comité dans les fichier de donnée on dit ici que le dbw anticipe.
-des modification confirmé ne sont pas écrites sur les fichiers de données et reste dans la mémoire centrale doc data Base Buffer cache.
* Le processus LGWR
Publicité
est le processus qui écrit le contenu (les entrées Redo) du redo log buffer sur les fichiers de journalisation de manière séquentielle. Une fois les entrées redo sont écrites sur le disque, le processus serveur peut utiliser cet espace (en écrasant les entrées déjà écrites) pour y stocker les informations des nouvelles mises à jour toujours sous la forme d’entrées Redo. Le LGWR est déclenché par les événements suivants :
o L’utilisateur confirme une transaction par un COMMIT
o Toutes les trois secondes.
o Quand le buffer est plein au tiers.
o Avant que le DBWn ne se mette à écrire les blocs modifiés non validés (non « committés ») sur disque. En effet, lorsque le DBWn s’apprête à écrire des blocs dirty non validés, il faut que toutes les entrées Redo en relation avec ses blocs soient écrites sur les Log Files. Cette situation ne peut se produire que si les modifications ne sont pas confirmées par un COMMIT (car sinon le LGWR aurait été déclenché et les entrés Redo en question auraient été déjà écrites).
Si le DBWn sait qu’il va écrire des blocs dirty non confirmés (dont les entrées Redo ne sont pas écrites sur disque), il le signale au LGWR et attend un message de ce dernier lui signalant la fin de sa tâche (écriture sur les Log Files des entrées redo en relation avec les blocs dirty) ; c’est à ce moment là que le DBWn aura le feu vert pour écrire les blocs en question.
* Le processus SMON * Récupération des données au démarrage après un crash. * Optimisation de l’espace disque (libération des segments temporaires, compactage des extensions libres et contiguës) * Le SMON effectue ou bien un ROLLBACK, ou bien un ROLLFORWARD * ROLLBACK : annulation des modifications non-confirmées qui étaient enregistrées sur disque par anticipation du DBW*n*. * ROLLFORWARD : enregistrement des modifications confirmées sur les fichiers de données à partir des fichiers journaux. * **B. PMON**[**▲**](https://oracle.developpez.com/guide/architecture/archiinstance/) * Le processus PMON
-géré processus des utilisateurs.
-Il va servir à annuler les transactions d'une session (lors d'un plantage de la session par exemple)mais aussi servir à relâcher tous les verrous posés par la session,
-et à relâcher toutes les ressources détenues par la session.