Chap2 (anis Bachtobji)

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

Architecture d’Oracle Database

Administration d’Oracle Database – Document 1.0 Feedbacks à [email protected]

8

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.

2.1.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. 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 index incluent des données et occupent donc de l’espace mémoire dans les fichiers de données. Les autres types d’objets n’ont qu’une définition stockée dans le dictionnaire de données.



9

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.

Data01.dbf Data02.dbf

Segment A (Extent 1) Segment A (Extent 2)

Segment B (Extent 1)

Segment B (Extent 2)

Segment C (Extent 1)

Figure 2 : Structure d'un tablespace incluant deux fichiers

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.

La Figure 3 représente la structure logique et physique d’une base de données Oracle, remarquez que le sens des flèches entre les différentes structures indique une relation un à plusieurs.

Database

Tablespace

Segment

Extension

Bloc de donnée

Fichier de données

Bloc SE

Structure Logique Structure Physique Figure 3 : Structure logique et physique d'une base de données Oracle



10

2.1.3 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 DBA_LOG_FILES contient toutes les informations qui concernent les fichiers journaux de la base de données.

Figure 4 : Ecriture cyclique et multiplexée des fichiers journaux

2.1.4 Les archives des fichiers de journalisation

Les fichiers de journalisation (présentés dans la section 2.1.3) sont écrits de manière cyclique. 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. Une solution de



11

sécurité optimale, consiste à archiver les fichiers de journalisation avant de finir le cycle de sauvegarde des transactions et donc avant de les écraser. Il est à noter que les fichiers de journalisations sont archivés si la base de données fonctionne en mode ARCHIVELOG.

2.1.5 Le fichier de paramètres

Il inclut l’ensemble des paramètres de configuration qui permettent l’initialisation de l’instance. 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, mais peut aussi démarrer sur un PFILE si l’administrateur le précise. Un PFILE est un fichier de paramètres de type texte qui devrait figurer sur toute machine susceptible de démarrer l’instance. Pour éviter certains problèmes d’utilisation en réseau (notamment la synchronisation lors de la mise à jour du fichier), Oracle 9i a introduit le SPFILE ; un fichier de paramètres binaire centralisé sur le serveur de la base de données. Le PFILE est généralement nommé init%.ora, il est modifié via n’importe quel éditeur texte. Le SPFILE est nommé spfile%.ora, il est modifiable via SQL. 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. Finalement, 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), pendant que les modifications de certains paramètres du SPFILE peuvent prendre effet à chaud, c-à-d, sans redémarrer la base de données (modification directe en mémoire, sur fichier, ou les deux).

2.1.6 Le fichier de mot de passe

Lorsque l’administrateur d’une base de données tente de démarrer l’instance, son authentification se produit à partir de ce fichier qui inclut son mot de passe. En effet, 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.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. Le fichier de paramètres est utilisé pour configurer l’instance lors de son démarrage. Celle-ci ne peut ouvrir qu’une seule base de données à la fois.

2.2.1 Les structures mémoires

Une instance emploie deux structures principales ; la SGA (System Global Area) et la PGA (Program Global Area).



12

A. System Global Area (SGA)

C’est un espace de la mémoire centrale partagé par les différents processus de l’instance. Elle est allouée au démarrage de la base de données et libéré lors de son arrêt. 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. Depuis la version 9i d’Oracle, sa taille n’est plus obligatoirement fixe, et elle est devenue redimensionnable à chaud, c.-à-d., en cours d’utilisation. Plus la taille de la SGA est grande, plus le nombre d’E/S diminue et plus la performance de l’instance est meilleure. Il est à noter que sa taille n’excède pas la valeur du paramètre SGA_MAX_SIZE. 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 ; 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.



13

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 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.

Le database buffer cache étant un ensemble de blocs 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). Depuis la version 9, le deuxième paramètre n’est plus utilisé, et c’est plutôt le paramètre DB_CACHE_SIZE qu’il faut instancier dorénavant. Celui-ci dimensionne directement le cache, il doit être naturellement un multiple de la taille d’un bloc de données.

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émoire oblige. 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.

Java Pool

Stocke les objets et applications Java les plus récemment utilisés lorsque la machine virtuelle Java JVM optionnelle est utilisée. Elle est dimensionnée par le paramètre JAVA_POOL_SIZE.

Large Pool

Stocke des données lors de l’exécution d’opérations volumineuses. Il est utilisé dans le cas d’une configuration serveur partagé, elle est dimensionnée par le paramètre LARGE_POOL_SIZE.

Streams Pool

C’est le cache des données relatives à la queue de messages utilisées par Oracle. Elle est dimensionnée par le paramètre STREAMS_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 ; elle inclut des informations sur l’état de la base de données, 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, respectivement en résumé (SGA Fixe, SGA variable, Cache des



14

données et celle des journaux) et en détail (chaque composant à part).

REQ 2

SELECT * FROM V$SGA;

REQ 3

SELECT component, current_size FROM V$SGA_DYNAMIC_COMPONENTS;

La gestion automatique de la SGA

Les tailles des composants de la SGA peuvent être gérées manuellement ou automatiquement. Une gestion manuelle consiste tout simplement à instancier les paramètres des tailles un par un ; le choix de l’administrateur s’effectuant selon les besoins de l’application. 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. La gestion automatique est activée si le paramètre SGA_TARGET (taille souhaitée de la SGA) est différent de zéro. Dans ce cas, le database buffer cache, le shared pool, le large pool et le java pool sont dimensionnés automatiquement. A noter que la taille du log buffer n’est pas pris en charge par la gestion automatique, sa taille est déduite du SGA_TARGET.

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.-à-d. que les DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL et JAVA_POOL sont différents de zéro), alors Oracle considère que leurs valeurs sont minimales, c.-à-d. qu’il leur alloue ces valeurs au minimum.

B. 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, les informations de session, l’état des curseurs utilisés, les informations de tri etc.

La PGA totale allouée à tous les processus serveurs est appelée PGA agrégée. Depuis la version 9 d’Oracle, un nouveau mécanisme permet de gérer globalement la PGA agrégée des processus serveurs. 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.

2.2.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. 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.

A. 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



15

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 ou d’autres. Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est 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.

Rappelons qu’une zone de mémoire PGA est créée pour chaque processus serveur, 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.2.1B).

B. 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.

- DBWn 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, du cache de données dans les fichiers de données sur le disque. Un administrateur Oracle peut spécifier jusqu’à 20 exemplaires de DBW, de DBW0 jusqu’à DBW9 et de DBWa jusqu’à DBWj si la base de données connait une forte charge transactionnelle. Il est à noter que les exemplaires des DBW sont inutiles dans le cadre de serveurs monoprocesseurs. Le paramètre d’initialisation DB_WRITER_PROCESSES spécifie le nombre d’exemplaires du DBW. Le maximum est de 20, si non spécifié, Oracle se charge d’affecter le nombre d’exemplaires qui convient selon le nombre de processeurs du serveur hébergeant la base. La tâche du DBW est de « nettoyer » le cache des données en écrivant les blocs dirty les



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. Il faut savoir que l’écriture des blocs dirty par le DBW est différée, c-à-d, qu’Oracle n’écrit pas les blocs modifiés automatiquement après l’exécution de la requête de mise à jour, et pas forcément après la confirmation (COMMIT) de la transaction en question. En d’autres termes, 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.

o Après une certaine période pour faire avancer le point de reprise. Le point de reprise est la position dans les fichiers journaux à partir de laquelle l’instance est récupérable. Cette position est déterminée par le plus ancien tampon dirty dans le cache de données.

- 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. 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.

Remarquez qu’un COMMIT déclenche uniquement le LGWR. Après un COMMIT, 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 notion d’écriture rapide du contenu du log buffer est dite fast commit.

Lorsque le LGWR ne peut pas écrire sur un fichier du groupe courant (endommagement



17

ou indisponibilité du fichier), il le fait sur les autres fichiers du même groupe et signale une erreur sur les fichiers de trace du système. Mais si tous les fichiers du groupe sont inaccessibles, LGWR n’écrit nulle part et le signale aussi au système.

Enfin, il est à noter qu’Oracle affecte un code appelé SCN (System Change Number) à toute transaction validée (COMMIT). Ce code est inscrit par le LGWR sur les entrées Redo dans les fichiers de journalisation. Ce code est très important dans le mécanisme de récupération des données en cas de crash du système.

- CKPT est un processus qui est lancé à la suite de l’événement Checkpoint (point de vérification). Lorsqu’un checkpoint se produit, tous les blocs dirty doivent être écrits sur disque ; c’est toujours le DBWn qui s’en charge à la suite d’un message du CKPT. Après écriture des blocs modifiés, 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 ; ces deux derniers sont dits synchronisés. En cas de crash du système, 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.

La synchronisation se produit lorsque le LGWR bascule d’un fichier journal à un autre. Le LGWR ne se permet pas de basculer de fichier journal, et donc d’écraser des entrés Redo, sans que le DBW n’écrive les blocs dirty du DB buffer cache, le cas échéant, le LGWR pourrait écraser des entrés Redo relatifs à des blocs modifiés non encore écrits sur disque.

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.

- 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. 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.

Si la récupération de certaines transactions échoue à cause de l’indisponibilité d’un tablespace ou d’un fichier, SMON attend qu’ils soient rétablis et récupèrent les transactions en question.

Au cours d’une récupération, 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, et un roll back pour annuler les modifications non confirmées écrites par le DBWn sur les fichiers de données.

- PMON (Process Monitor) est le processus responsable de la récupération lors de l’échec d’un processus utilisateur. Lorsqu’un un processus utilisateur plante, 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.

- ARCn est le processus qui écrit le contenu des fichiers journaux (redo log files) dans des



18

fichiers archives lors de chaque basculement entre les groupes de fichiers journaux. Ce processus n’est actif que si la base fonctionne en mode ARCHIVELOG.

Une instance Oracle peut démarrer jusqu’à 10 exemplaires d’ARCs (d’ARC0 jusqu’à ARC9), 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. Cela étant dit, 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.

- CJQn est le processus coordinateur qui exécute les tâches planifiées par les utilisateurs. Ces tâches sont principalement des programmes PL/SQL planifiés entre autres grâce au package DBMS_SCHEDULER. 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. Le processus CJQn peut exécuter un grand nombre de tâches grâces à ses processus esclaves (J000 J999).

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. La vue V$PROCESS inclut les informations de tous les processus en court d’exécution dans l’instance. La Figure 6 présente toutes les composantes d’un serveur base de données ; les fichiers physiques, 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.

2.3 Le schéma

Un schéma est un ensemble d’objets qui ont été créés par un certain utilisateur. Chaque utilisateur est le propriétaire d’un unique schéma. Les principaux types d’objets d’un schéma sont les tables, les index, les vues, les synonymes, les séquences, les déclencheurs, les fonctions et procédures stockées et les packages PL/SQL. Il est à noter que les objets utilisateur, tablespace, profile, rôle et autres ne font pas partie des objets d’un schéma.

Il faut savoir aussi qu’il n’existe pas de relation directe entre un schéma et un tablespace. En effet, les objets d’un schéma peuvent être stockés sur différents tablespaces tandis qu’un unique tablespace peut inclure plusieurs schémas. L’objet d’un schéma n’a pas forcément une correspondance à un fichier physique de données. En réalité seuls les tables et les index sont stockés sous forme de segments, 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.

2.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, 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. Le dictionnaire de données inclut en fait



19

des données qui décrivent les données de la base de données ; c’est ce qu’on appelle les métadonnées. Il est créé dans le tablespace SYSTEM, et c’est l’utilisateur SYS qui en est le propriétaire. Cela étant dit, il n’existe aucun utilisateur qui peut altérer la structure ou les données de ses tables, seul Oracle comme mentionné ci-dessus les crée et les maintient pour assurer l’intégrité des données.

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. Par exemple si un certain utilisateur JAMES crée une table FACTURE, Oracle insère certaines lignes dans plusieurs tables du dictionnaire de données qui décrivent la nouvelle table, ses colonnes, ses contraintes d’intégrité, le segment utilisé, les extensions, les privilèges de JAMES



20

sur cette table etc.

Les tables du dictionnaire de données, telles que OBJ$ et FILE$, contiennent des données codifiées. Pour faciliter l’accès à ces tables ainsi que leur utilisation par les utilisateurs, Oracle crée des vues qui y sont basées. Il existe deux types de vues du dictionnaire de données ; les vues statiques et les vues dynamiques de performance :

2.4.1 Les vues statiques

Ce sont des vues basés sur des tables créés réellement dans le dictionnaire de données. Elles ne sont accessibles que si la base de données est complètement ouverte. Elles commencent toutes soit par le préfixe DBA_%, soit ALL_%, soit USER_%.

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). 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, celles qui commencent par le préfixe DBA_ concernent tous les objets de la base de données ; ces vues ne sont interrogeables que par un administrateur. La Table 1 inclut quelques vues statiques du dictionnaire de données. Nous remplacerons le préfixe par le caractère %, nous noterons directement le nom significatif des données générées par la vue. Par exemple, la vue %_TABLES est interrogeable soit sous forme de USER_TABLES, ALL_TABLES ou DBA_TABLES. Cela étant dit, certaines vues ne peuvent être consultées que par les administrateurs. C’est pour cette raison que ces vues ne commencent que par le préfixe DBA_ tel que la vue DBA_DATA_FILES.

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.

Nom de la vue Description

%_TABLES Toutes les informations des tables de la base de données.

%_USERS Toutes les informations concernant les utilisateurs de la base de données.

%_VIEWS Toutes les informations des vues de la base de données.

%_SEQUENCES Toutes les informations concernant les séquences de la base de données.

%_TAB_COLUMNS Toutes les informations concernant les colonnes des tables de la base de données.

%_INDEXES Toutes les informations concernant les index de la base de données.

%_OBJECTS Toutes les informations des objets –tous types confondus- de la base de données.

Table 1 : Quelques vues statiques du dictionnaire de données



21

2.4.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. Les noms des vues dynamiques commencent généralement par V$ et ne sont accessibles que par les administrateurs. Il est à noter que les vues dynamiques peuvent être consultées même si la base de données n’est pas ouverte. La Table 2 présente certaines vues dynamiques.

Nom de la vue Description

V$DATABASE Informations de la base de données.

V$INSTANCE Informations sur l’instance.

V$SGA Informations résumées sur la SGA.

V$SGA_DYNAMIC_COMPONENTS Informations détaillées sur les zones mémoire de la SGA.

V$PARAMETER Information sur les différents paramètres de l’instance et de la BD.

V$OPTION Informations des composantes optionnelles installées sur le serveur BD.

V$SQL Informations des requêtes SQL exécutées par tous les utilisateurs de la BD.

Table 2 : Quelques vues dynamiques de performance

2.5 Fonctionnement d’Oracle

2.5.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. Le processus utilisateur envoie une requête SELECT, voici en gros les étapes d’exécution :

1. Phase de parse : Le processus serveur vérifie si la requête existe dans le Library Cache du Shared Pool. Si elle n’y existe pas, 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. L’analyse sémantique est effectuée à partir du Dictionary Cache si les informations en question y existent, sinon Oracle les y charge à partir du dictionnaire de données. Par la suite, un plan d’exécution de la requête est calculé. 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. Dans ce dernier cas, 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.



22

2. Phase d’exécution : Une fois le plan d’exécution calculé, le processus serveur exécute et vérifie si les blocs de données cibles existent dans le DB Buffer Cache. Si ce n’est pas le cas, il les charge à partir des fichiers de données.

3. Phase de fetch : Une fois le processus serveur récupère les données, il les trie si la requête inclut la clause ORDER BY puis il les renvoie au processus utilisateur.

2.5.2 Pour exécuter une requête UPDATE

1. Phase de parse : La même que pour une requête SELECT.

2. 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. Par la suite, 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. Finalement les blocs de données sont modifiés dans le DB Buffer Cache, ils seront écrits de manière différée sur le disque par le DBWn.

3. Phase de fetch : il n’y a pas d’opération fetch dans le cas d’une requête DML, l’utilisateur reçoit juste un message concernant le déroulement de l’opération.

2.5.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. Sur disque et plus précisément sur les segments d’annulation, les informations en relation avec la transaction validée sont libérées.

2.5.4 Lors d’un ROLLBACK

Lorsque l’utilisateur effectue un ROLLBACK, il existe deux scénarii possibles :

1. Les blocs modifiés sont déjà inscrits dans les fichiers de données ; dans ce cas, la récupération de l’ancienne image se fait à partir du segment d’annulation.

2. La modification est encore en mémoire (DB Buffer Cache) et n’a pas été écrite sur disque. L’ancienne image des données existe donc dans les fichiers de données, et l’annulation est beaucoup plus rapide que dans le premier cas.

Documents

Chap2 (anis Bachtobji)