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
Publicité
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.
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.
Publicité
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
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.
a. 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
Publicité
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.
b. 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 :
-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 :
Publicité
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.
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
q R cup ration des donn es au d marrage apr s un crash.
q Optimisation de lespace disque (lib ration des segments temporaires, compactage des
extensions libres et contigu s)
q Le SMON effectue ou bien un ROLLBACK, ou bien un ROLLFORWARD
v ROLLBACK : annulation des modifications non-confirm es qui taient enregistr es sur disque par
anticipation du DBWn.
v ROLLFORWARD : enregistrement des modifications confirm es sur les fichiers de donn es
partir des fichiers journaux.
v B. PMON
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.