Chapitre 2 Architecture d’Oracle Database

Un serveur de base de données Oracle inclut deux composantes importantes, l’instance et la base de données. La base de données est l’ensemble de fichiers qui contiennent entre autres les données, les informations de la base ainsi que le journal de modification des données. L’instance quant à elle est un ensemble de processus et d’emplacements mémoire qui facilitent l’accès et la manipulation de la base de données.

2.1 La base de données
La base de données est constituée d’un ensemble de fichiers physiques situés sur les disques durs du serveur hébergeant la base. La Figure 1 montre les différents types de ces fichiers, il est à noter que les archives des fichiers de journalisation, le fichier de paramètres ainsi que le fichier des mots de passe ne font pas partie prenante de la base de données, mais y sont étroitement reliés.

Figure 1 : Les fichiers physiques d'une base de données

2.1.1

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

Un fichier de données est un ensemble de blocs d’une taille donnée (4 Ko. 16 Ko etc. Les fichiers de données sont logiquement regroupés en structures logiques appelées tablespaces. Segment temporaire : espace temporaire ou sont stockées des données temporaires utilisées lors d’un tri. ainsi qu’à la lecture cohérente des données. Parmi ces différents types d’objets. En effet. A titre indicatif. Les autres types d’objets n’ont qu’une définition stockée dans le dictionnaire de données.rnu. ce dernier étant apparu en Oracle 10g).Architecture d’Oracle Database 8 cela qu’il est possible (et recommandé) de multiplexer le fichier de contrôle sur des endroits différents du disque dur. Un segment est l’espace occupé par un objet base de données dans un tablespace.) dans un même tablespace .). En revanche. d’une jointure.).0 Feedbacks à anis. 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. file_name FROM DBA_DATA_FILES ORDER BY tablespace_name. un tablespace (étalé sur un ou plusieurs fichiers de données). lors de la création d’un index etc. est un ensemble de segments. Il est à noter que les informations des fichiers de contrôle peuvent être examinées à partir de la vue V$CONTROLFILE. 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. 8Ko. les séquences et les programmes PL/SQL. 2. les synonymes. procédures etc.tn . Ces deux tablespaces ne doivent logiquement contenir aucune donnée applicative. les principaux types d’objets appartenant à un utilisateur (constituant un schéma) sont les tables. le tablespace SYSTEM inclut le dictionnaire de données ainsi que le code PL/SQL (fonctions. les vues. gestion de personnel etc. 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. seuls les tables et les index incluent des données et occupent donc de l’espace mémoire dans les fichiers de données. le résultat est d’avoir des données regroupés par application/contexte. 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. Administration d’Oracle Database – Document 1.1. 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. une organisation parmi tant d’autres consiste à réunir les tables qui portent sur le même contexte (comptabilité. les index. Logiquement. gestion de stock.2 Les fichiers de données Ce sont les fichiers physiques qui stockent les données de la base sous un format spécial Oracle.bach@isg.

tandis qu’un segment peut être étalé sur plusieurs extensions chacun sur un fichier unique.bach@isg. La Figure 3 représente la structure logique et physique d’une base de données Oracle. Une extension est un ensemble de blocs contigus dans un même fichier de données.tn .rnu.Architecture d’Oracle Database 9 Un segment est à son tour composé de structures logiques appelées extensions.0 Feedbacks à anis.dbf Data02. Le tablespace inclut trois segments A. pendant que le segment C inclut une seule extension. Database Tablespace Fichier de données Segment Extension Bloc de donnée Bloc SE Structure Logique Structure Physique Figure 3 : Structure logique et physique d'une base de données Oracle Administration d’Oracle Database – Document 1. remarquez que le sens des flèches entre les différentes structures indique une relation un à plusieurs. Sa taille est définie via le paramètre DB_BLOCK_SIZE. Segment A (Extent 1) Segment A (Extent 2) Segment B (Extent 2) Segment B (Extent 1) Segment C (Extent 1) Data01. Un bloc de données est la plus petite unité physique d’E/S des données. B et C.dbf Figure 2 : Structure d'un tablespace incluant deux fichiers La Figure 2 présente un tablespace composé de deux fichiers de données. Les segments A et B incluent chacun deux extensions chacune sur un fichier différent.

que si les fichiers d’un premier groupe sont pleins. Oracle peut compter sur sa (ou ses) copie(s).1.rnu. La vue DBA_LOG_FILES contient toutes les informations qui concernent les fichiers journaux de la base de données.0 Feedbacks à anis.3 Les fichiers de journalisation Tout d’abord.-à-d.3) sont écrits de manière cyclique. 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.Architecture d’Oracle Database 10 2. En d’autres termes. Il existe au minimum deux groupes de fichiers journaux et ils sont écrits de manière cyclique.1. ils sont appelés membres d’un groupe. 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.. 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. même si un fichier de journalisation est irrécupérable. Quant un utilisateur Oracle opère des mises à jour sur les données. Une solution de Administration d’Oracle Database – Document 1.tn . faisons un petit rappel sur la notion de transaction .4 Les archives des fichiers de journalisation Les fichiers de journalisation (présentés dans la section 2. Figure 4 : Ecriture cyclique et multiplexée des fichiers journaux 2.1. Un ensemble de fichiers journaux multiplexés constitue un groupe de fichiers de journalisation. alors ces trois fichiers incluent exactement les mêmes informations. update et delete) qui finit par un COMMIT (validation) ou un ROLLBACK (annulation). c. 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). une transaction est un ensemble d’opérations (requêtes) de mises à jour (insert. Si par exemple un groupe inclut trois fichiers journaux. Il en découle que les données ne peuvent être récupérables qu’à partir de la plus ancienne transaction non écrasée dans l’un des groupes de fichiers de journalisation.bach@isg. C’est d’ailleurs la raison pour laquelle ces fichiers sont multiplexés et/ou copiés.

Le fichier de paramètres est utilisé pour configurer l’instance lors de son démarrage. sur fichier. Oracle 9i a introduit le SPFILE .5 Le fichier de paramètres Il inclut l’ensemble des paramètres de configuration qui permettent l’initialisation de l’instance. un fichier de paramètres binaire centralisé sur le serveur de la base de données. Une instance Oracle démarre sur un seul fichier paramètre. c-à-d. Le SPFILE est nommé spfile%. En effet. 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 est modifiable via SQL.2. Finalement. 2. pendant que les modifications de certains paramètres du SPFILE peuvent prendre effet à chaud. la SGA (System Global Area) et la PGA (Program Global Area). Celle-ci ne peut ouvrir qu’une seule base de données à la fois.2 L’instance L’instance est l’ensemble de structures mémoires et de processus qui assurent l’accès et la gestion d’une base de données. Il est à noter qu’on peut créer un fichier PFILE à partir d’un fichier SPFILE et vice versa à l’aide de la requête CREATE PFILE/SPFILE FROM SPFILE/PFILE. le classique PFILE (Parameter File) et le nouveau (depuis la version 9i) SPFILE (Server Parameter File). mais peut aussi démarrer sur un PFILE si l’administrateur le précise. la vérification du mot de passe ne peut pas se produire à partir du dictionnaire de données (comme pour les autres utilisateurs) car l’instance n’est pas encore chargée en mémoire. 2.ora. Il est à noter que les fichiers de journalisations sont archivés si la base de données fonctionne en mode ARCHIVELOG. par défaut sur un SPFILE.1 Les structures mémoires Une instance emploie deux structures principales . son authentification se produit à partir de ce fichier qui inclut son mot de passe. consiste à archiver les fichiers de journalisation avant de finir le cycle de sauvegarde des transactions et donc avant de les écraser.tn .1. 2.Architecture d’Oracle Database 11 sécurité optimale. ou les deux).ora. 2. Pour éviter certains problèmes d’utilisation en réseau (notamment la synchronisation lors de la mise à jour du fichier). Il est accédé lors du démarrage de l’instance. il est modifié via n’importe quel éditeur texte. Un PFILE est un fichier de paramètres de type texte qui devrait figurer sur toute machine susceptible de démarrer l’instance. Administration d’Oracle Database – Document 1. Le PFILE est généralement nommé init%.1. les paramètres modifiés dans un fichier PFILE ne prennent effet que lors du prochain démarrage du système (modification sur fichier uniquement).bach@isg. sans redémarrer la base de données (modification directe en mémoire.0 Feedbacks à anis.6 Le fichier de mot de passe Lorsque l’administrateur d’une base de données tente de démarrer l’instance.rnu. Il existe deux types de fichiers paramètres.

rnu. System Global Area (SGA) 12 C’est un espace de la mémoire centrale partagé par les différents processus de l’instance. Il est à noter que la taille du pool partagé est définie par le paramètre SHARED_POOL_SIZE. ni pour trouver le plan d’exécution optimal.bach@isg. plus le nombre d’E/S diminue et plus la performance de l’instance est meilleure. le Library Cache et le Dictionary Cache. La SGA inclut les structures suivantes : Figure 5 : Les composantes de la SGA  Le Pool Partagé (Shared Pool) C’est une zone mémoire composée de deux structures .0 Feedbacks à anis.-à-d. En effet. La deuxième zone mémoire du pool partagé est le Dictionary Cache. Oracle ne perd de temps supplémentaire ni pour une deuxième analyse syntaxique et sémantique. 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. sa taille n’est plus obligatoirement fixe. Le Library Cache contient les informations sur les requêtes SQL les plus récemment utilisées. Elle est constituée de trois zones obligatoires et de trois zones optionnelles qui sont allouées au démarrage en fonction des valeurs des paramètres du fichier de paramètres. en cours d’utilisation. Naturellement. si les colonnes sélectionnées ou conditionnées en font partie. c’est pour cela qu’il stocke uniquement les requêtes les plus récentes en utilisant l’algorithme LRU (Least Recently Used).tn . si l’utilisateur a le droit de manipuler cette table etc. Lorsque cette requête est exécutée de nouveau. Toutes ces informations nécessaires à l’analyse de la requête SQL sont stockées dans le Dictionary Cache. Oracle a besoin d’accéder au dictionnaire de données pour voir si la table existe. le Library Cache a une taille limitée. le texte. il retrouve la requête sous ses trois formes (cités ci-dessus) et l’exécute rapidement. c.. Il est à noter que sa taille n’excède pas la valeur du paramètre SGA_MAX_SIZE. Elle est allouée au démarrage de la base de données et libéré lors de son arrêt.Architecture d’Oracle Database A. Plus la taille de la SGA est grande. sa version compilée. et elle est devenue redimensionnable à chaud. Une requête SQL y est stockée sous trois formes . Depuis la version 9i d’Oracle. lorsqu’une requête est analysée. En effet. Administration d’Oracle Database – Document 1. ainsi que son plan d’exécution.

Si ce n’est pas le cas. et c’est plutôt le paramètre DB_CACHE_SIZE qu’il faut instancier dorénavant. 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. Il est à noter que la taille du buffer redo log est définie par le paramètre LOG_BUFFER. taille limitée de la zone mémoire oblige. Celui-ci dimensionne directement le cache. SGA variable. Cache des Administration d’Oracle Database – Document 1. Le database buffer cache étant un ensemble de blocs de données.  Java Pool Stocke les objets et applications Java les plus récemment utilisés lorsque la machine virtuelle Java JVM optionnelle est utilisée.  Streams Pool C’est le cache des données relatives à la queue de messages utilisées par Oracle. il doit être naturellement un multiple de la taille d’un bloc de données. sa taille est le produit des valeurs des paramètres DB_BLOCK_SIZE (taille d’un bloc) et DB_BLOCK_BUFFERS (nombre de blocs dans le cache).rnu. 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 utilisé dans le cas d’une configuration serveur partagé. le deuxième paramètre n’est plus utilisé. Depuis la version 9. respectivement en résumé (SGA Fixe. Il est écrit séquentiellement (ce qui provoque un mélange de transactions) et de manière cyclique . elle est dimensionnée par le paramètre LARGE_POOL_SIZE. Notons la présence dans la SGA d’une autre zone mémoire de petite taille (de l’ordre de centaines de Ko) appelée SGA fixe .tn .Architecture d’Oracle Database  Le Database Buffer Cache 13 Il stocke les blocs de données les plus récemment utilisées. et donc toutes les informations relatives à toute transaction réalisée par les utilisateurs. Elle est dimensionnée par le paramètre STREAMS_POOL_SIZE. les place 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. sur l’instance et sur les verrous. Les vues V$SGA et V$SGA_DYNAMIC_COMPONENTS permettent d’afficher les tailles de zones mémoire composant la SGA. Oracle lit les blocs de données qu’il faut à partir des fichiers de données.0 Feedbacks à anis. il vérifie si ses données (et donc blocs) existent dans le database buffer cache.bach@isg. Lorsqu’Oracle est amené à exécuter une requête SQL et à ramener son résultat à l’utilisateur.  Large Pool Stocke des données lors de l’exécution d’opérations volumineuses. elle inclut des informations sur l’état de la base de données. Chaque modification correspond à une entrée redo écrite dans le buffer (redo entry).  Le Redo Log Buffer Ce buffer contient les mises à jour effectuées sur les données. Elle est dimensionnée par le paramètre JAVA_POOL_SIZE.

Une gestion manuelle consiste tout simplement à instancier les paramètres des tailles un par un . REQ 2 SELECT * FROM V$SGA. le database buffer cache. Program Global Area (PGA) C’est une zone mémoire non partagée créée pour chaque processus serveur. Elle stocke les informations spécifiques aux utilisateurs telles que les variables hôtes. 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. Sa taille est dimensionnée par le paramètre PGA_AGGREGATE_TARGET et c’est Oracle qui se charge de répartir cette mémoire entre les différents processus serveurs.-à-d. Depuis la version 9 d’Oracle. les informations de tri etc. REQ 3 SELECT component. Une gestion automatique est effectuée par l’instance elle-même qui ajustera les tailles des composantes selon la taille maximale de la SGA (et donc du paramètre SGA_MAX_SIZE) ainsi que de la charge du système. current_size FROM V$SGA_DYNAMIC_COMPONENTS.2 Les processus Les processus Oracle permettent les différentes composantes du serveur d’interagir et d’échanger entre elles ainsi qu’avec l’utilisateur. lorsqu’un Administration d’Oracle Database – Document 1. La PGA totale allouée à tous les processus serveurs est appelée PGA agrégée. A noter que la taille du log buffer n’est pas pris en charge par la gestion automatique. Dans ce cas. 14 La gestion automatique de la SGA Les tailles des composants de la SGA peuvent être gérées manuellement ou automatiquement. les informations de session. Il existe des processus utilisateurs du côté des clients.tn . l’état des curseurs utilisés. qu’il leur alloue ces valeurs au minimum. le shared pool.Architecture d’Oracle Database données et celle des journaux) et en détail (chaque composant à part). 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. Il faut savoir que si la gestion automatique est activée (SGA_TARGET différente de zéro) et que les tailles des composantes de la SGA ont été définies manuellement (c. SHARED_POOL_SIZE.0 Feedbacks à anis. En effet. c. alors Oracle considère que leurs valeurs sont minimales. un nouveau mécanisme permet de gérer globalement la PGA agrégée des processus serveurs.rnu. LARGE_POOL et JAVA_POOL sont différents de zéro).-à-d. 2. A. que les DB_CACHE_SIZE.bach@isg.2. La gestion automatique est activée si le paramètre SGA_TARGET (taille souhaitée de la SGA) est différent de zéro. le large pool et le java pool sont dimensionnés automatiquement. le choix de l’administrateur s’effectuant selon les besoins de l’application. sa taille est déduite du SGA_TARGET. B.

elle inclut entre autres les variables hôtes et les variables de session utilisées dans les requêtes/programmes envoyés par l’utilisateur (voir section 2. ces sessions peuvent être ouvertes par le même utilisateur ou d’autres. Un administrateur Oracle peut spécifier jusqu’à 20 exemplaires de DBW. Oracle crée sur le serveur pour chaque utilisateur (et donc pour chaque processus utilisateur) un processus serveur. La majorité des processus d’arrière plan sont lancés lorsque l’instance démarre.tn . plusieurs processus utilisateurs peuvent partager un seul et unique processus serveur. si non spécifié. soit en mode partagé. Le DBW écrit les tampons (buffers) modifiés. Oracle Enterprise Manager. Oracle se charge d’affecter le nombre d’exemplaires qui convient selon le nombre de processeurs du serveur hébergeant la base.Architecture d’Oracle Database 15 utilisateur démarre une application (SQL*Plus. La nouvelle valeur indiquerait le nombre de processus serveurs partagés démarrés lorsque l’instance est lancée. Le paramètre d’initialisation DB_WRITER_PROCESSES spécifie le nombre d’exemplaires du DBW. 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. Oracle démarre un processus serveur sur le serveur base de données.bach@isg.rnu. DBWn est le processus qui écrit le contenu du cache des données dans les fichiers de données (Database Writer).). il suffit de modifier le paramètre SHARED_SERVERS dont la valeur par défaut est 0. Rappelons qu’une zone de mémoire PGA est créée pour chaque processus serveur. Le mode par défaut est le mode dédié. 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. Une fois la connexion établie. du cache de données dans les fichiers de données sur le disque. Il est à noter que les exemplaires des DBW sont inutiles dans le cadre de serveurs monoprocesseurs. de DBW0 jusqu’à DBW9 et de DBWa jusqu’à DBWj si la base de données connait une forte charge transactionnelle. Un serveur base de données est soit configuré en mode dédié. Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est SESSIONS. Par la suite.2. Lorsque le serveur est configuré en mode dédié. une connexion entre le processus utilisateur et l’instance est initiée et maintenue. La tâche du DBW est de « nettoyer » le cache des données en écrivant les blocs dirty les Administration d’Oracle Database – Document 1. l’utilisateur ouvre une session en s’identifiant (saisie de son nom d’utilisateur et de son mot de passe). Il est à noter que certains processus fonctionnent en plusieurs exemplaires. Il est à noter que plusieurs sessions peuvent être ouvertes en même temps. c’est pour cela que leur nom finit par n qui signifie le numéro de l’exemplaire du processus.0 Feedbacks à anis. pour activer le mode partagé.1B). En mode partagé. une application Developer Forms etc. dits dirty. certains d’entre eux pourraient être lancés après. Le maximum est de 20. 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. lorsque l’instance en aura besoin. Après l’ouverture d’une session. B.

o Avant que le DBWn ne se mette à écrire les blocs modifiés non validés (non « committés ») sur disque. Il faut savoir que l’écriture des blocs dirty par le DBW est différée.Architecture d’Oracle Database 16 moins récemment utilisés dans le fichier des données de manière à ce que le(s) processus serveur trouve(nt) aisément des tampons clean pour y charger les blocs de données qu’il faut (à la suite d’une interrogation utilisateur) à partir des fichiers de données. c-à-d. c’est à ce moment là que le DBWn aura le feu vert pour écrire les blocs en question. Après un COMMIT. 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). Le point de reprise est la position dans les fichiers journaux à partir de laquelle l’instance est récupérable. Une fois les entrées redo sont écrites sur le 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) . o Quand le buffer est plein au tiers. o Après une certaine période pour faire avancer le point de reprise. LGWR 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. il faut que toutes les entrées Redo en relation avec ses blocs soient écrites sur les Log Files. lorsque le DBWn s’apprête à écrire des blocs dirty non validés. 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. Remarquez qu’un COMMIT déclenche uniquement le LGWR.0 Feedbacks à anis. Cette notion d’écriture rapide du contenu du log buffer est dite fast commit. ce n’est pas l’exécution de la transaction ni sa confirmation qui déclenchent le fonctionnement du DBW. Ce processus est plutôt déclenché par les événements suivants : o Un processus serveur ne trouve pas de tampons clean après qu’il ait scanné un nombre seuil de tampons. Le LGWR est déclenché par les événements suivants : o L’utilisateur confirme une transaction par un COMMIT o Toutes les trois secondes. Lorsque le LGWR ne peut pas écrire sur un fichier du groupe courant (endommagement Administration d’Oracle Database – Document 1. En d’autres termes.tn . les entrées Redo (du log buffer) en relation avec la transaction confirmée sont toutes écrites sur les log files et un message de confirmation de la mise à jour est renvoyé à l’utilisateur. Cette position est déterminée par le plus ancien tampon dirty dans le cache de données. et pas forcément après la confirmation (COMMIT) de la transaction en question. qu’Oracle n’écrit pas les blocs modifiés automatiquement après l’exécution de la requête de mise à jour.bach@isg. En effet. 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).rnu.

PMON annule la transaction de ce dernier et libère les verrous posés sur les données modifiées à cause de la transaction en cours. tous les blocs dirty doivent être écrits sur disque . Lorsqu’un checkpoint se produit. le cas échéant. PMON (Process Monitor) est le processus responsable de la récupération lors de l’échec d’un processus utilisateur. CKPT est un processus qui est lancé à la suite de l’événement Checkpoint (point de vérification).tn - . Au cours d’une récupération. SMON attend qu’ils soient rétablis et récupèrent les transactions en question.Architecture d’Oracle Database 17 ou indisponibilité du fichier). LGWR n’écrit nulle part et le signale aussi au système. La synchronisation se produit lorsque le LGWR bascule d’un fichier journal à un autre. et un roll back pour annuler les modifications non confirmées écrites par le DBWn sur les fichiers de données. le LGWR pourrait écraser des entrés Redo relatifs à des blocs modifiés non encore écrits sur disque. sans que le DBW n’écrive les blocs dirty du DB buffer cache. SMON effectue un roll forward qui consiste à enregistrer sur les fichiers de données les modifications confirmées qui n’ont pas été écrites par le DBWn. il est à noter qu’Oracle affecte un code appelé SCN (System Change Number) à toute transaction validée (COMMIT). c’est toujours le DBWn qui s’en charge à la suite d’un message du CKPT. il le fait sur les autres fichiers du même groupe et signale une erreur sur les fichiers de trace du système. En cas de crash du système.bach@isg. Le LGWR ne se permet pas de basculer de fichier journal. Si la récupération de certaines transactions échoue à cause de l’indisponibilité d’un tablespace ou d’un fichier. Ce code est très important dans le mécanisme de récupération des données en cas de crash du système. La synchronisation se produit aussi lors de la fermeture de la base de données ou lors de la mise hors ligne d’un tablespace. Il est aussi chargé de libérer les segments temporaires inutilisés et de compacter les extensions libres et contiguës des tablespaces gérés par le dictionnaire de données. ARCn est le processus qui écrit le contenu des fichiers journaux (redo log files) dans des Administration d’Oracle Database – Document 1. ces deux derniers sont dits synchronisés. Enfin. le CKPT écrit le SCN de la dernière transaction confirmée sur les entêtes (headers) des fichiers de données ainsi que dans le fichier de contrôle .0 Feedbacks à anis. le point de reprise est défini par ce SCN et Oracle récupère à partir des fichiers de journalisation toutes les transactions qui ont été confirmées après le SCN inscrit sur le fichier de contrôle/entêtes de fichiers de données. Lorsqu’un un processus utilisateur plante. Après écriture des blocs modifiés. et donc d’écraser des entrés Redo. SMON (System Monitor) est le processus qui récupère les données au démarrage de l’instance si cette dernière s’est arrêtée de manière anormale.rnu. Ce code est inscrit par le LGWR sur les entrées Redo dans les fichiers de journalisation. Mais si tous les fichiers du groupe sont inaccessibles.

Une instance Oracle peut démarrer jusqu’à 10 exemplaires d’ARCs (d’ARC0 jusqu’à ARC9). les structures mémoire et les processus ainsi que l’interaction entre ces différentes composantes que ce soit à l’intérieur du serveur ou avec les clients et leurs processus utilisateurs. c’est le LGWR qui démarre un nouvel exemplaire d’ARC à chaque fois que ceux qui fonctionnent déjà sont insuffisants pour écrire de manière efficiente. Les informations concernant les tâches (jobs) planifiées d’une base de données sont stockés dans la table DBA_SCHEDULER_JOBS du dictionnaire de données. La vue V$PROCESS inclut les informations de tous les processus en court d’exécution dans l’instance. les objets d’un schéma peuvent être stockés sur différents tablespaces tandis qu’un unique tablespace peut inclure plusieurs schémas. rôle et autres ne font pas partie des objets d’un schéma. Il est à noter que les objets utilisateur. En réalité seuls les tables et les index sont stockés sous forme de segments.Architecture d’Oracle Database 18 fichiers archives lors de chaque basculement entre les groupes de fichiers journaux. l’administrateur peut anticiper une charge importante d’archivage et spécifier dès le départ le nombre d’exemplaires qu’il faut via le paramètre d’initialisation LOG_ARCHIVE_MAX_PROCESSES. 2. CJQn est le processus coordinateur qui exécute les tâches planifiées par les utilisateurs. Il faut savoir aussi qu’il n’existe pas de relation directe entre un schéma et un tablespace.3 Le schéma Un schéma est un ensemble d’objets qui ont été créés par un certain utilisateur. les synonymes. L’objet d’un schéma n’a pas forcément une correspondance à un fichier physique de données. les vues. Le dictionnaire de données inclut en fait Administration d’Oracle Database – Document 1. Le processus CJQn peut exécuter un grand nombre de tâches grâces à ses processus esclaves (J000  J999). La Figure 6 présente toutes les composantes d’un serveur base de données . Cela étant dit. Chaque utilisateur est le propriétaire d’un unique schéma. En effet. la plupart des autres objets correspondent tout simplement à des définitions dans le dictionnaire de données puisqu’ils ne consomment pas d’espace disque comparés aux tables et aux index. les séquences. les fonctions et procédures stockées et les packages PL/SQL.tn . Il faut savoir que le nombre maximum de processus exécutés en même temps dans l’instance est contrôlé par le paramètre d’initialisation PROCESSES. 2.0 Feedbacks à anis.bach@isg. Ce processus n’est actif que si la base fonctionne en mode ARCHIVELOG. les fichiers physiques. créées et maintenues par le système et contenant toutes les informations de toutes les composantes logiques et physiques du serveur de base de données. profile. les déclencheurs.rnu. Les principaux types d’objets d’un schéma sont les tables. les index. Ces tâches sont principalement des programmes PL/SQL planifiés entre autres grâce au package DBMS_SCHEDULER. tablespace.4 Le dictionnaire de données Le dictionnaire de données est un ensemble de vues et de tables accédées en lecture seule.

Architecture d’Oracle Database 19 des données qui décrivent les données de la base de données . Il est créé dans le tablespace SYSTEM. les privilèges de JAMES Administration d’Oracle Database – Document 1. et c’est l’utilisateur SYS qui en est le propriétaire. ses contraintes d’intégrité.rnu. seul Oracle comme mentionné ci-dessus les crée et les maintient pour assurer l’intégrité des données. les extensions. Par exemple si un certain utilisateur JAMES crée une table FACTURE. Figure 6 : L’interaction Instance-Base de données-Utilisateurs Le dictionnaire de données est mis à jour entre autres lorsque les utilisateurs exécutent des requêtes LDD.bach@isg. c’est ce qu’on appelle les métadonnées. ses colonnes. le segment utilisé. Cela étant dit. Oracle insère certaines lignes dans plusieurs tables du dictionnaire de données qui décrivent la nouvelle table. il n’existe aucun utilisateur qui peut altérer la structure ou les données de ses tables.tn .0 Feedbacks à anis.

Toutes les informations des objets –tous types confondus. Toutes les informations concernant les séquences de la base de données.de la base de données. La Table 1 inclut quelques vues statiques du dictionnaire de données. ALL_TABLES ou DBA_TABLES. Les vues qui commencent par le préfixe USER_ concernent uniquement les objets possédés par l’utilisateur qui les interroge (les objets de son schéma). Oracle crée des vues qui y sont basées. C’est pour cette raison que ces vues ne commencent que par le préfixe DBA_ tel que la vue DBA_DATA_FILES. Elles commencent toutes soit par le préfixe DBA_%. ces vues ne sont interrogeables que par un administrateur. Il existe deux types de vues du dictionnaire de données . Elles ne sont accessibles que si la base de données est complètement ouverte.bach@isg. celles qui commencent par le préfixe DBA_ concernent tous les objets de la base de données . soit USER_%. nous noterons directement le nom significatif des données générées par la vue. Nous remplacerons le préfixe par le caractère %.rnu.0 Feedbacks à anis. telles que OBJ$ et FILE$.4. Pour faciliter l’accès à ces tables ainsi que leur utilisation par les utilisateurs. Par exemple. La vue DICTIONARY du dictionnaire de données possède pratiquement la même structure que la Table 1 et inclut des commentaires sur toutes les vues statiques et dynamiques de la base de données. la vue %_TABLES est interrogeable soit sous forme de USER_TABLES.Architecture d’Oracle Database sur cette table etc. Cela étant dit. Toutes les informations des vues de la base de données. Table 1 : Quelques vues statiques du dictionnaire de données Administration d’Oracle Database – Document 1. Toutes les informations concernant les colonnes des tables de la base de données. Celles qui commencent par le préfixe ALL_ concernent les objets accessibles par l’utilisateur (ses tables ainsi que celles dont il a eu certains privilèges). Finalement.tn . Toutes les informations concernant les index de la base de données. certaines vues ne peuvent être consultées que par les administrateurs. Toutes les informations concernant les utilisateurs de la base de données. 20 Les tables du dictionnaire de données. contiennent des données codifiées. les vues statiques et les vues dynamiques de performance : 2.1 Les vues statiques Ce sont des vues basés sur des tables créés réellement dans le dictionnaire de données. soit ALL_%. Nom de la vue %_TABLES %_USERS %_VIEWS %_SEQUENCES %_TAB_COLUMNS %_INDEXES %_OBJECTS Description Toutes les informations des tables de la base de données.

sinon Oracle les y charge à partir du dictionnaire de données.4. Les noms des vues dynamiques commencent généralement par V$ et ne sont accessibles que par les administrateurs. Le processus utilisateur envoie une requête SELECT. un plan d’exécution de la requête est calculé. voici en gros les étapes d’exécution : 1. Dans ce dernier cas.Architecture d’Oracle Database 21 2. une analyse syntaxique est effectuée (vérification de l’exactitude des mots réservés) suivie par une analyse sémantique qui consiste à (1) vérifier l’existence des tables et des colonnes consultées dans la requête via le dictionnaire de données et (2) à vérifier les privilèges de l’utilisateur en cours. Table 2 : Quelques vues dynamiques de performance 2.rnu.5 Fonctionnement d’Oracle 2. seule la vérification des privilèges de l’utilisateur est effectuée et toutes les autres opérations (vérification syntaxique et calcul du plan d’exécution) sont épargnées.5. La Table 2 présente certaines vues dynamiques. Information sur les différents paramètres de l’instance et de la BD. Informations détaillées sur les zones mémoire de la SGA. Informations des composantes optionnelles installées sur le serveur BD. Informations sur l’instance. L’analyse sémantique est effectuée à partir du Dictionary Cache si les informations en question y existent. Informations des requêtes SQL exécutées par tous les utilisateurs de la BD. Par la suite. Phase de parse : Le processus serveur vérifie si la requête existe dans le Library Cache du Shared Pool. Nom de la vue V$DATABASE V$INSTANCE V$SGA V$SGA_DYNAMIC_COMPONENTS V$PARAMETER V$OPTION V$SQL Description Informations de la base de données. Administration d’Oracle Database – Document 1. Si elle n’y existe pas.0 Feedbacks à anis.1 Pour exécuter une requête SELECT Nous supposons que l’instance a déjà démarré et que la connexion entre un processus utilisateur et un processus serveur est établie. Ce parse est appelé « hard parse » puisqu’il consomme beaucoup de ressources comparé à un « soft parse » qui se produit dans le cas où la requête est trouvée dans le Library Cache.bach@isg. Il est à noter que les vues dynamiques peuvent être consultées même si la base de données n’est pas ouverte.2 Les vues dynamiques de performance Les vues dynamiques ne sont pas basées sur des tables du dictionnaire de données. et les informations qu’elles contiennent sont plutôt extraites de la mémoire et/ou des fichiers de contrôle. Informations résumées sur la SGA.tn .

Phase d’exécution : Une fois le plan d’exécution calculé.5. Phase de fetch : il n’y a pas d’opération fetch dans le cas d’une requête DML. 2. il les trie si la requête inclut la clause ORDER BY puis il les renvoie au processus utilisateur.0 Feedbacks à anis. Les blocs modifiés sont déjà inscrits dans les fichiers de données . le Redo Entry correspondant à la requête (incluant entre autres l’image avant et après des données) est stocké dans le Redo Log Buffer.Architecture d’Oracle Database 22 2. Phase de parse : La même que pour une requête SELECT. ils seront écrits de manière différée sur le disque par le DBWn. 2.tn .5. la récupération de l’ancienne image se fait à partir du segment d’annulation.5. Sur disque et plus précisément sur les segments d’annulation. La modification est encore en mémoire (DB Buffer Cache) et n’a pas été écrite sur disque. le processus serveur exécute et vérifie si les blocs de données cibles existent dans le DB Buffer Cache. 2.2 Pour exécuter une requête UPDATE 1. 2. Par la suite. Phase d’exécution : Le processus serveur charge dans le DB Buffer Cache les blocs de données à modifier si elles n’y sont pas déjà et verrouille les lignes à modifier. Si ce n’est pas le cas. 3. dans ce cas.4 Lors d’un ROLLBACK Lorsque l’utilisateur effectue un ROLLBACK. L’ancienne image des données existe donc dans les fichiers de données. Phase de fetch : Une fois le processus serveur récupère les données.3 Lors d’un COMMIT Le LGWR assigne un SCN (System Change Number) à la transaction validée et écrit par la suite toutes les entrées Redo de la transaction dans les fichiers de journalisation à partir du Redo Log Buffer. il existe deux scénarii possibles : 1. l’utilisateur reçoit juste un message concernant le déroulement de l’opération. et l’annulation est beaucoup plus rapide que dans le premier cas. Administration d’Oracle Database – Document 1. 2. Finalement les blocs de données sont modifiés dans le DB Buffer Cache. il les charge à partir des fichiers de données. les informations en relation avec la transaction validée sont libérées. 3.rnu.bach@isg.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.