" Le Database Buffer Cache
Il stocke les blocs de donn es les plus r cemment utilis es. LorsquOracle est amen ex cuter une requ te SQL et ramener son r sultat lutilisateur, il v rifie si ses donn es (et donc blocs) existent dans le database buffer cache. Si ce nest pas le cas, Oracle lit les blocs de donn es quil faut partir des fichiers de donn es, les places dans le cache selon lalgorithme LRU (en lib rant de lespace sil le faut par limination des blocs les moins r cemment utilis es) et les renvoie lutilisateur. Le param tre DB\_CACHE\_SIZE d signe la taille du cache, il doit tre naturellement un multiple de la taille dun bloc de donn es. noter quun 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 linstance. - 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 dun bloc de donn es unique de mani re ce que la nouvelle valeur ainsi que lancienne 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)
Cest 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 dex cution. Naturellement, le Library Cache a une taille limit e, cest pour cela quil stocke uniquement les requ tes les plus r centes en utilisant lalgorithme LRU (Least Recently Used). Il en d coule quune requ te SQL ex cut e pour la premi re fois est stock e dans le library cache avec son plan dex 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 dex cution optimal. En effet, il retrouve la requ te sous ses trois formes (cit s ci-dessus) et lex cute rapidement. La deuxi me zone m moire du pool partag est le Dictionary Cache. En effet, lorsquune requ te est analys e, Oracle a besoin dacc 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 lutilisateur a le droit de manipuler cette table etc. Toutes ces informations n cessaires lanalyse 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 linstance 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 dautres 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. Cest pour cela quil 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 dautres 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 davoir 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 dune taille donn e (4 Ko, 8Ko, 16 Ko etc.). Le bloc de donn es est la petite unit dE/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 lespace 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 dindex : espace occup par un index - Segment dannulation : espace temporaire utilis pour stocker les donn es n cessaires lannulation dune 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 dun tri, dune jointure, lors de la cr ation dun index etc. En effet, les principaux types dobjets 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 dobjets, seuls les tables et les index1 consomment de lespace disque en dehors du dictionnaire de donn es.
Publicité
Plus pr cis ment, ils occupent de lespace m moire sur les fichiers de donn es. Les autres types dobjets nont quune d finition stock e dans le dictionnaire de donn es.
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 quun segment peut tre tal sur plusieurs extensions chacun sur un fichier unique. Un bloc de donn es est la plus petite unit physique dE/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 dabord, faisons un petit rappel sur la notion de transaction ; une transaction est un ensemble dop 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 (lensemble 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 lutilisateur qui vaut un COMMIT si cest une d connexion normale et un ROLLBACK si elle ne lest 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. Cest dailleurs la raison pour laquelle ces fichiers sont multiplex s et/ou copi s. En dautres 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 dun groupe. Il existe au minimum deux groupes de fichiers journaux et ils sont crits de mani re cyclique, c.- -d., que si les fichiers dun 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 lensemble des param tres de configuration qui conditionnent linitialisation de linstance, et ensuite son fonctionnement. Il est acc d lors du d marrage de linstance, il inclut entre autres le chemin du fichier de contr le ainsi quun ensemble de param tres instanci s d finissant la mani re avec laquelle linstance 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
Publicité
Les processus Oracle permettent aux diff rentes composantes du serveur dinteragir et d changer entre elles ainsi quavec lutilisateur. 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 darri re plan qui assurent le bon fonctionnement de linstance.
1. Les processus-utilisateur et le processus-serveur Linteraction 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, lorsquun 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 sil sagit dune architecture client-serveur ou sur un serveur middle-tier sur une architecture multi-tier. Par la suite, une connexion entre le processus utilisateur et linstance est initi e et maintenue. Une fois la connexion tablie, lutilisateur ouvre une session en sidentifiant (saisie de son nom dutilisateur 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 louverture dune session, Oracle d marre un processus serveur sur le serveur base de donn es, cest ce processus qui se chargera dex cuter les requ tes de lutilisateur 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 linstance est lanc e.
2. Les processus darri re plan
Les processus darri re plan sont utilis s par Oracle afin de maximiser la performance de linstance. La majorit des processus darri re plan sont lanc s lorsque linstance d marre, certains dentre eux pourraient tre lanc s apr s, lorsque linstance en aura besoin. Il est noter que certains processus fonctionnent en plusieurs exemplaires, cest pour cela que leur nom finit par n qui signifie le num ro de lexemplaire du processus.
- Le 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 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 daffecter le nombre dexemplaires 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 :
Publicité
-Lorsque le nombre de block dirty attient un certain limite.
-Un processus serveur ne trouve pas de tampons clean apr s quil 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 lun 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
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 dentr es Redo. Le LGWR est d clench par les v nements suivants :
o Lutilisateur confirme une transaction par un COMMIT
o Toutes les trois secondes.
o Quand le buffer est plein au tiers.
Publicité
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 sappr 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 quil 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) ; cest 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 lespace 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 DBWn.
- 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.