Administration d’Oracle

Administration d Oracle

Introduction

 Oracle: Vue d’ensemble
Oracle: Vue d’ensemble
 Oracle est le leader du marché des SGBDR, avec une part 
de marché allant jusqu’à 48.6% en 2007 (Gartner Group).

 Oracle commercialise différents produits; Oracle Database, 
O l i li diffé t d it O l D t b
Oracle Developer Suite, Oracle Application Server, Oracle 
Applications, Oracle Collaboration Suite, Oracle Services…

1
 Introduction

 Oracle Database
 Le produit principal d’Oracle est commercialisée sous 
différentes éditions:
 Enterprise Edition: inclut toutes les fonctionnalités d’Oracle.
 Standard Edition: basique, destinée aux serveurs à 4 processeurs.
 Standard Edition One: basique, destinée aux serveurs biprocesseurs.
Standard Edition One: basique destinée aux serveurs biprocesseurs
 Personal Edition: uniquement sur Windows, destinée aux 
développeurs.
 Express Edition: édition gratuite, fonctionne sur des machines à 1 
processeur.
 Lite Edition: destinée aux machines mobiles.

Introduction

 Interaction avec Oracle Database
Interaction avec Oracle Database
Interface

Une interface permet à un

utilisateur de gérer et de
manipuler les données qui sont
sur le serveur

Utilisateur
‐SQL*Plus
Serveur base de données
‐iSQLPlus
‐ OEM (DB Control)
‐ Oracle Discoverer, Oracle Reports, Oracle Forms
‐ PL/SQL

2
 Architecture d’Oracle
Database

 Composantes principales d’un serveur Oracle
Composantes principales d’un serveur Oracle
1. Base de données
Ensemble de fichiers (sur disque) contenant les données, les 
informations sur les données, le journal de modifications

2 Instance
2.
Ensemble de processus et de zones mémoires (mémoire centrale) qui 
permettent de gérer la base de données.

Base de données

Base de Données

Groupes des fichiers de

Fichiers de données Fichiers de contrôle
journalisation

Fichier de paramètres Archives des fichiers de Fichier de mot de

journalisation passe

3
 Fichier de contrôle

 Fichier de contrôle (Control File)
Fichier de contrôle (Control File)
‐ Contient des informations de contrôle sur la base: Fichier de contrôle

Nom de la base, noms et chemins des fichiers de données 
et de journalisation, informations de restaurations etc…
‐ Premier fichier lu par l’instance lors du démarrage.
‐ La vue V$CONTROLFILE nous renseigne sur le contenu 
du fichier de contrôle.

Fichier de données

 Fichier de données (Data Files)
Fichier de données (Data Files)
‐ Stockent les données sous un format spécial à Oracle. Fichiers de données

‐ Physiquement, un fichier de données est un ensemble de blocs SE. 
Un bloc SE constitue l’unité d’E/S (écriture/lecture) des fichiers.
‐ Les fichiers de données sont logiquement regroupés sous forme de 
tablespaces.
‐ Une BD Oracle 10g inclut au moins deux tablespaces, SYSTEM et 
SYSAUX.

4
 Les tablespaces

 Les tablespaces
Les tablespaces
‐ Un tablespace est une unité logique qui correspond physiquement à 
un ou plusieurs fichiers de données.
‐ L’administrateur (DBA) agit sur les tablespaces et non sur les fichiers 
de données.
‐ Une BD est organisée sous forme de plusieurs tablespaces, chacun 
correspondant à un contexte (thème).
‐ EX: On peut créer plusieurs tablespaces dans une BD d’une Ese
commerciale qui gère la FACTURATION, la GRH, et le PARC INFO.

Les tablespaces

Le tablespace FACTURATION  [Link] et [Link]

‐ Le tablespace FACTURATION  fact01 dbf et fact02 dbf
‐ Les tables FACTURE, LIGNE_FACTURE, PRODUIT, CLIENT, REGLEMENT.
‐ Le tablespace GRH  [Link]
‐ Les tables PERSONNEL, PAIE, SANCTION etc.
‐ Le tablespace PARC  [Link]
‐ Les tables EQUIPEMENT, CATEGORIE, REPARATION, MAINTENANCE etc.
Les tables EQUIPEMENT CATEGORIE REPARATION MAINTENANCE etc
‐ Avantage: On peut administrer par tablespace, et donc par partie (par rapport à la 
BD). Par exemple, pour maintenir certaines tables relatives à la facturation, on peut 
mettre uniquement le tablespace FACTURATION en offline, au lieu de rendre toute 
la base indisponible ce qui touchera des centaines d’utilisateurs qui ont besoin de 
manipuler les données de la GRH, PARC INFO etc.

5
 Les tablespaces

 Les tablespace
Les tablespace
‐ Les vues DBA_TABLESPACES et DBA_DATA_FILES incluent 
toutes les informations relatives aux tablespaces et aux fichiers de 
données de la base.
‐ Pour afficher les noms des fichiers de données ainsi que les 
tablespaces auxquelles ils correspondent:
tablespaces auxquelles ils correspondent:
SELECT tablespace_name, file_name
FROM DBA_DATA_FILES
ORDER BY tablespace_name;

Structure de stockage

Database

‐ C’est l’espace occupé par un objet base
de données (Table ou Index) Fichier de
Tablespace
données
‐ Il existe 4 types de segments:
1. Segment table: espace occupé par une table
Segment

2. Segment index: espace occupé par un index
Segment index: espace occupé par un index
3. Segment d’annulation: espace qui inclut les
Extension

informations d’annulation
4. Segment temporaire: espace annexe à la
Bloc de données Bloc SE
MC pour les opérations volumineuses.
Structure Logique Structure Physique

6
 Le segment d’annulation

 Le segment d’annulation 
Le segment d’annulation sert à stocker les données nécessaires:
tà t k l d é é i
1. A l’annulation

Mémoire centrale

Update table1
Disque
set col1=A
Where col1=B;

Le segment d’annulation

 Le segment d’annulation 
Le segment d’annulation sert à stocker les données nécessaires:
tà t k l d é é i
1. A l’annulation
Update table1
Mémoire centrale Set col1=A
Nouvelle Ancienne
image (A) image (B) Where col1=B;

Segment
table
Di
Disque
Segment
d’annulation
En effet, la MAJ peut être effectuée sur
disque sans attendre un COMMIT.

La nouvelle image est enregistrée dans un segment table, l’ancienne dans un segment d’annulation.
Au cas où un ROLLBACK est effectué, c’est cette image qu’on utilisera pour rétablir les données.

7
 Le segment d’annulation

 Le segment d’annulation 
Le segment d’annulation sert à stocker les données nécessaires:
tà t k l d é é i
1. A l’annulation
2. A la lecture cohérente (ou dite aussi consistante).

Anciennevaleur
Nouvelle valeur
ou ancienne? 11:58
Update table1
set col1=A
Where col2=C;
12:01
Select col1 From table1
Where col2=C;

Le segment d’annulation

 Le segment d’annulation 
Le segment d’annulation sert à stocker les données nécessaires:
tà t k l d é é i
1. A l’annulation
2. A la lecture cohérente (ou dite aussi consistante).
a. Si pas d’anticipation d’enregistrement des MAJ, Alors la lecture 
se fait directement à partir du segment table.
b. Si anticipation d’enregistrement des MAJ, Alors la lecture se fait à 
partir du segment d’annulation.

8
 Le segment temporaire

 Le segment temporaire 
Le segment temporaire sert à stocker les données relatives à des 
tà t k l d é l ti àd
opérations volumineuses si la mémoire centrale ne suffit pas à les 
exécuter.
Exemple d’opérations volumineuses:
‐ Certains tris.
‐ Certaines jointures.
‐ Création d’index.
‐ Etc.

Extension

 Un segment
Un segment est à son tour composé d
est à son tour composé
Database
d’extensions
extensions
 Une extension est un ensemble de blocs
appartenant à un même fichier de 
Tablespace
Fichier de
données
données
 Par contre un segment peut s’étaler sur 
Segment

plusieurs fichiers à travers ses

plusieurs fichiers à travers ses 
extensions. Extension

 La taille d’un bloc de données est définie 
par le paramètre DB_BLOCK_SIZE
Bloc de données Bloc SE

Structure Logique Structure Physique

9
 Exemple

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

Tablespace Fichier de
données

Segment B (Extent 2)
Segment
Segment B (Extent 1)

Extension
Segment C (Extent 1)

Bloc de données Bloc SE

[Link] [Link]
Structure Logique Structure Physique

Structure du tablespace FACTURATION

Fichiers de journalisation

 Les fichiers de journalisation contiennent toutes les modifications 
effectuées sur les données depuis une certaine durée.
 En cas de crash du système, ou d’altération des fichiers de données, 
on peut reconstituer les données à partir des fichiers journaux.
 L’écriture sur les fichiers journaux est multiplexée et cyclique.
 L’ensemble des fichiers multiplexés (qui contiennent donc les mêmes 
p (q
informations) sont appelés membres et forment un groupe.
 L’écriture est donc multiplexée à l’intérieur d’un groupe, et cyclique
entre les groupes.
 La vue DBA_LOG_FILES contient les informations des fichiers 
journaux.

10
 Fichiers de journalisation

Groupe 1

DELETE DELETE
UPDATE UPDATE
INSERT INTO INSERT INTO
UPDATE UPDATE
UPDATE… UPDATE…
INSERT INTO INSERT INTO

Membre 1 Membre 2

Groupe 2

INSERT INTO INSERT INTO

UPDATE… UPDATE…
DELETE... DELETE...

Membre 1 Membre 2

Archives des fichiers

journaux

 L’écriture des fichiers journaux est cyclique, ce qui fait qu’à un certain 
moment, certaines transactions seront écrasées.
 La solution, c’est d’archiver les fichiers journaux avant de les écraser.
 Les fichiers journaux archivés peuvent être stockés sur des disques 
(serveurs) distants ce qui optimisera la sécurité de la BD
(serveurs) distants, ce qui optimisera la sécurité de la BD.
 Une base de données n’est pas forcément en mode ARCHIVELOG, si 
elle ne l’est pas, les fichiers journaux ne sont pas archivés.

11
 Le fichier de paramètres

 Un fichier de paramètres inclut l’ensemble des paramètres de configuration du 
serveur BD.
BD
 L’instance lit ce fichier et fonctionne selon les valeurs des paramètres qui y sont 
spécifiés.
 Il existe deux types de fichiers de paramètres:

PFILE (parameter file) SPFILE (server parameter file)

Fichier texte Fichier binaire
Modifiable via un éditeur texte Modifiable via SQL
Disponible sur la machine de démarrage Centralisé (sur le serveur uniquement)

Nommé init%.ora Nommé spfile%.ora

Modification à froid Modification à chaud

L’instance

 C’est l’ensemble de structures mémoire et de processus qui assurent 

la gestion de la base de données.
 Le fichier de paramètres est utilisé pour configurer l’instance lors de 
son démarrage.
 Une instance ne peut ouvrir qu’une seule base de données.
 Une instance emploie deux zones mémoire principales; la SGA
(System Global Area) et la PGA (Program Global Area).

12
 L’instance

Serveur de BD

Instance: la SGA

 C’est un espace mémoire partagé par tous les processus de l’instance. 
Elle est allouée au démarrage de l’instance et libérée lors de son 
arrêt. Elle inclut 6 zones mémoires (3+3).
 Plus la SGA est grande, plus le serveur est performant. Sa taille 
maximale est définie via le paramètre SGA_MAX_SIZE

13
 Instance: la SGA

SGA

Dictionary
Cache

Library
Cache

DB Buffer Shared Redo Log

Cache Pool Buffer

Streams
Java Pool Large Pool
Pool

Shared Pool

 Elle est composée de deux structures; le library cache et le dictionary

cache. Sa taille est définie via le paramètre SHARED_POOL_SIZE.
 Le LC contient pour chaque requête récemment exécutée trois 
informations:
‐ Son texte
‐ Sa compilation
p
‐ Son plan d’exécution
 Lorsqu’une requête existe encore dans le LC, Oracle ne perd pas son 
temps à la ré‐exécuter.
 Le DC stocke toutes les informations nécessaires à l’analyse 
sémantique de la requête (table? Colonnes? Droits d’accès?...)

14
 DB Buffer Cache

 Il stocke les blocs de données les plus récemment utilisés.
 Lorsqu’une requête est exécutée, Oracle vérifie d’abord si les blocs de 
données à ramener ne soient pas déjà chargés dans le DB buffer.
 Si les blocs à renvoyer n’existent pas dans le DB buffer cache, Oracle 
les y stocke selon l’algorithme LRU (et libère d’autres blocs s’il le faut).
 La taille du DB Buffer Cache est définie via le paramètre
DB_CACHE_SIZE

Redo Log Buffer

 Contient les informations sur les transactions exécutées.
 Le Redo Log Buffer est écrit de manière séquentielle (les transactions 
y sont mélangées) et cyclique (taille limitée de la zone mémoire 
oblige).
 Chaque modification correspond à une entrée Redo. Cette dernière 
est constituée de plusieurs vecteurs, chacun correspond à un bloc de 
t tit é d l i t h dà bl d
données modifié (ancienne + nouvelle valeur).
 Le contenu du Redo Log Buffer est écrit dans les fichiers journaux.
 La taille du Redo Log Buffer est définie via le paramètre
LOG_BUFFER

15
 Autres zones mémoire

 Le JAVA Pool
Le JAVA Pool : Stocke les objets et applications Java les plus 
: Stocke les objets et applications Java les plus
récemment utilisés lorsque la machine virtuelle Java JVM optionnelle 
est utilisée. Paramètre JAVA_POOL_SIZE.
 Le 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é. Paramètre LARGE_POOL_SIZE.
 Le Streams Pool : C’est le cache des données relatives à la queue de 
messages utilisées par Oracle. Paramètre STREAMS_POOL_SIZE.
 A noter que dans la SGA, il y a une petite zone mémoire appelée SGA 
fixe. Elle inclut des infos sur l’état de la base, l’instance, les verrous…
 Les vues V$SGA et V$SGA_DYNAMIC_COMPONENTS.

La gestion automatique de la
SGA

 Les tailles des zones mémoire peuvent être définies manuellement 
ou automatiquement.
 Gestion manuelle : donner une valeur spécifique à chacun des 
paramètres des tailles des zones mémoire. La somme ne doit pas 
dépasser SGA_MAX_SIZE.
 Gestion automatique : activé si SGA_TARGET
G ti t ti ti é i SGA TARGET est différente de zéro.
t diffé t d é
 Dans ce cas, le DB Buffer Cache, le Shared Pool, le Large Pool et le 
Java Pool sont dimensionnés automatiquement. La taille du Log 
Buffer n’est pas prise en charge par la gestion automatique, sa taille 
est déduite du SGA_TARGET.

16
 Récapitulatif SGA

SERVEUR BD = INSTANCE = ZONES MÉMOIRES

Instance Zones mémoires
=
+ + 3 + 3
BD (fichiers) Processus

La PGA

 C’est une zone mémoire privée dédiée aux utilisateurs. Elle est créée 
pour chaque processus serveur.
 Elle stocke des informations spécifiques aux utilisateurs, tel que les 
variables hôtes, les variables de session, l’état des curseurs utilisés, 
des informations de tri etc.
 La PGA totale allouée à tous les processus serveur est appelée PGA 
L PGA t t l ll é à t l t lé PGA
agrégée.
 Le paramètre PGA_AGGREGATE_TARGET définit la taille de la PGA 
agrégée, c’est Oracle qui se charge de la répartir entre les différentes 
processus serveur.

17
 Les processus

 Ils permettent une interaction entre les différentes composantes du 
serveur ainsi qu’avec les utilisateurs.

 Il existe trois types de processus
1. Les processus utilisateur
p
2. Les processus serveur
3. Les processus d’arrière plan

Les processus utilisateur et

serveur

 Le processus utilisateur s’exécute au niveau client.
 Le processus serveur s’exécute au niveau serveur BD.
 L’interaction entre le serveur et les clients se fait en réalité grâce à 
ces deux processus, chacun de son côté.
 Lorsque le client est lié au serveur, on parle d’une connexion.
q , p
 Lorsque l’utilisateur s’identifie, il ouvre une session.
 Plusieurs sessions peuvent être ouvertes en même temps. Elles ne 
doivent pas dépasser la valeur du paramètre SESSIONS.

18
 Les processus utilisateur et
serveur

 Le processus serveur
Le processus serveur (PS) reçoit les requêtes utilisateur, les exécute et 
(PS) reçoit les requêtes utilisateur les exécute et
renvoie le résultat.
 Un serveur BD est soit en mode DÉDIÉ, soit en mode PARTAGÉ.
 En mode dédié, on dédie un PS à chaque utilisateur.
 En mode partagé, on partage un PS pour un ensemble d’utilisateurs.
 Le mode par défaut est le mode dédié. Pour activer le mode partagé, 
il faut modifier la valeur de SHARED_SERVERS (par défaut =0).
 La valeur de SHARED_SERVERS indique le nombre de processus 
serveur partagés.
 Rappelons qu’une zone de mémoire PGA est allouée à chaque PS.

19
 Les processus d’arrière plan

 Assurent le bon fonctionnement du serveur.
Assurent le bon fonctionnement du serveur

 Maximisent la performance du serveur.

 Démarrent avec ou après (sur demande) le démarrage de l
Démarrent avec ou après (sur demande) le démarrage de l’instance.
instance.

 Certains peuvent être exécutés en n exemplaires.

Le DB Writer (DBWn)

 « Nettoie » le DB Buffer Cache des blocs «
» le DB Buffer Cache des blocs « dirty » les moins récemment
» les moins récemment
utilisés en les écrivant sur les fichiers de données.
 Ainsi, les PS trouvent de la place dans le cache pour y charger les blocs 
de données.
 Peuvent fonctionner en 20 exemplaires en cas de forte charge 
transactionnelle (inutile en cas de serveurs monoprocesseurs).
transactionnelle (inutile en cas de serveurs monoprocesseurs).
 Le paramètre qui détermine ce nombre DB_WRITER_PROCESSES.
 L’écriture des blocs modifiés est différée; le COMMIT par exemple ne 
déclenche pas une écriture par le DBWn.

20
 Le DB Writer (DBWn)

 Le DBWn
Le DBWn se déclenche (en écrivant les blocs dirty les moins 
se déclenche (en écrivant les blocs dirty les moins
récemment utilisées sur le disque) par ces deux événements:
1. Le PS ne trouve pas de tampons « clean » après avoir scanné un 
nombre seuil de tampons.

Seuil = 13

DB Buffer Cache

Le DB Writer (DBWn)

 Le DBWn
Le DBWn se déclenche (en écrivant les blocs dirty les moins 
se déclenche (en écrivant les blocs dirty les moins
récemment utilisées sur le disque) par ces deux événements:
2. Après une certaine période pour faire avancer le point de reprise.
1 2 3 4 1
2

CRASH !!!
1. Insert…;
5
3 2. Update…;
4
Le DBW est déclenché !
é l hé
5
DB Buffer Cache LOG Buffer 3. Update…;
Le point de reprise
Le point de reprise est la position 
dans les fichiers journaux à partir 
commit;
12 1 2 3 de laquelle les données sont 
4. Insert…;
4 5 récupérables = le plus ancien 
5. Update…;
tampon dirty du DB cache.
Data Files LOG Files commit;

21
 Le DB Writer (DBWn)

 Le DBWn
Le DBWn ne se déclenche pas à la suite d
ne se déclenche pas à la suite d’un
un COMMIT. Il faut donc 
COMMIT Il faut donc
savoir qu’on peut se trouver dans l’une de ces deux situations:

1. Le DBWn écrit des modifications non‐confirmés (non commités) dans 
les fichiers de données. On dit qu’il anticipe.

2. Des modifications confirmées ne sont pas écrites sur les fichiers de 
données, et restent en mémoire centrale (dans le DB Buffer Cache).

Le LOG Writer (LGWR)

 Le LGWR
Le LGWR écrit le contenu du Redo Log Buffer sur les fichiers journaux 
écrit le contenu du Redo Log Buffer sur les fichiers journaux
pour libérer de l’espace au PS.
 Le LGWR est déclenché par :
1. COMMIT  écriture des entrés redo relatives à la transaction 
confirmée.
2. Après un délai (3 secondes)
è dél ( d )
3. Quand le Redo Log Buffer est plein au tiers
4. Avant que le DBWn n’écrive sur les fichiers de données des blocs dirty 
non confirmés. Ainsi, en cas de crash, l’annulation se fait lors du 
démarrage du serveur.

22
 Le fast COMMIT & le SCN

 La
La notion de fast COMMIT
notion de fast COMMIT est liée à l
est liée à l’écriture
écriture différée
différée des blocs dirty 
des blocs dirty
confirmés sur les fichiers de données.
 Dans le cas où après un COMMIT, seules les entrées Redo de la transaction 
confirmée sont écrites sur les fichiers journaux (les blocs dirty ne sont pas 
écrits sur les fichiers de données par le DBWn), cela s’appelle Fast COMMIT.
 Le SCN (System Change Number) est un code affecté à toute transaction 
confirmée par un COMMIT.
fi é COMMIT
 Le SCN est inscrit sur les entrées redo de la transaction confirmée sur les 
fichiers journaux.
 Ce système de codage est fondamental pour la restauration des données en 
cas de crash du système.

Le Check Point (CKPT)

 Le CKPT
Le CKPT est lancé lorsque le système a besoin de faire un check point 
est lancé lorsque le système a besoin de faire un check point
(point de vérification).
 Lorsqu’un point de vérification est déclenché, le CKPT envoie un 
message au DBWn pour qu’il écrive tous les blocs dirty sur les fichiers 
de données.
 Une
Une fois le DBWn
fois le DBWn termine sa tâche, le CKPT
termine sa tâche, le CKPT écrit le SCN
écrit le SCN de la dernière 
de la dernière
transaction confirmée dans les entêtes des fichiers de données ainsi 
que dans le fichier de contrôle.
 En cas de crash, les transactions récupérées à partir des fichiers 
journaux sont celles dont le SCN est supérieur à celui écrit dans le 
fichier de contrôle.

23
 Le Check Point (CKPT)

 Les événements qui déclenchent un point de vérification (CKPT):
Les événements qui déclenchent un point de vérification (CKPT):

1. Lorsque le LGWR bascule d’un groupe à un autre. En fait le LGWR ne 
prend pas le risque d’écraser des entrées Redo sans écrire les blocs qui 
leurs correspondent dans les fichiers de données.
2. A la fermeture de la base de données.
l f d l b d d é
3. Lors de la mise en offline d’un tablespace.

Exemple

1. Insert…;

1 2 3 4 1 2. Update…;

CRASH !!!
2 Le DBW est déclenché !
5
3
4 3. Update…;
5 commit;
Un message est
envoyé au LGWR
DB Buffer Cache LOG Buffer 4. Insert…;
Check point (fermeture du tblsp) !
Check point (fermeture du tblsp) !
DBW
DBWn CKPT LGWR
5. Update…;
SCN 1 commit;
1234 1 2 3 SCN 1
SCN 1
45
SCN 2
Data Files Control File LOG Files

24
 Le System Monitor (SMON)

 Récupération des données au démarrage après un crash.
Récupération des données au démarrage après un crash
 Optimisation de l’espace disque (libération des segments temporaires, 
compactage des extensions libres et contiguës)
 Le SMON effectue ou bien un ROLLBACK, ou bien un ROLLFORWARD
 ROLLBACK : annulation des modifications non‐confirmées qui étaient 
enregistrées sur disque par anticipation du DBWn.
é d d
 ROLLFORWARD : enregistrement des modifications confirmées sur les 
fichiers de données à partir des fichiers journaux.

Le Process Monitor (PMON)

 Détection du plantage des processus utilisateurs.
Détection du plantage des processus utilisateurs
 Imaginez ce scénario :
1. Un PU qui a déjà lancé une requête UPDATE
2. Les données modifiées sont naturellement verrouillées
3. Le PU
Le PU bloque
 Les données seront verrouillées indéfiniment !
 C’est là que le PMON entre en action, il détecte le PU bloqué, annule la
transaction en cours et libère les verrous

25
 ARCHIVE (ARCn)

 Ecriture du contenu des fichiers journaux dans les fichiers journaux 
Ecriture du contenu des fichiers journaux dans les fichiers journaux
archivés.
 Déclenché par le basculement dans les fichiers journaux d’un groupe à 
un autre.
 Activé si le serveur fonctionne en mode ARCHIVELOG.
 Le paramètre LOG_ARCHIVE_MAX_PROCESSES
L è spécifie le nombre 
é ifi l b
d’exemplaires d’ARCn, même si le LGWR peut spécifier ce nombre de 
manière automatique (si pas d’intervention de l’administrateur).

Les processus d’arrière plan

 Il existe d
Il existe d’autres
autres processus d
processus d’arrière
arrière plan, nous nous arrêterons sur 
plan nous nous arrêterons sur
l’ARCn.

 Le paramètre d’initialisation PROCESSES définit le nombre max de 
processus connectés en même temps à l’instance.

 La vue V$PROCESS inclut les informations de tous les processus en 
cours d’exécution dans l’instance.

26
 PMON SMON

PGA SGA

User Process
Shared Streams
Server Java Pool Large Pool
Pool
Process
DB Buffer Shared Redo Log
Cache Pool Buffer
D000
Dictionary
C h
Cache
User Process

PGA Library
Cache
Dedicated
Server
Process
User Process

DBW0 CKPT LGWR ARC0

Base de Données

Groupes des fichiers de

Fichiers de données Fichiers de contrôle
journalisation

Archives des fichiers de

Fichier de paramètres Fichier de mot de
journalisation
passe

Serveur de Base de Données Oracle

Rappel : Schéma

 Ensemble d
Ensemble d’objets
objets qui ont été créés par un utilisateur.
qui ont été créés par un 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.
 Seuls les tables
l l bl et les index
l d sont stockés sous forme de segments, les 
ké f d l
autres objets correspondent à des définitions dans le dictionnaire de 
données.
 Les objets d’un schéma peuvent être stockés sur différents tablespaces 
tandis qu’un unique tablespace peut inclure plusieurs schémas.

27
 Rappel : Dictionnaire de
données

 Ensemble de tables/vues
Ensemble de tables/vues accédées en lecture seule, créées et 
accédées en lecture seule créées et
maintenues par le système.
 Elles contiennent toutes les informations de toutes les composantes 
logiques et physiques de la base de données ainsi que de l’instance.
 Il est créé dans le tablespace SYSTEM, et c’est l’utilisateur SYS qui en 
est le propriétaire.
est le propriétaire.
 Mise  à jour ?
 Les tables contiennent des données codées. Pour y accéder, on 
consulte les vues.
 Il existe deux types de vues; les vues statiques et les vues dynamiques.

Dictionnaire de données –
Les vues statiques

 Elles sont basées sur des tables créés réellement dans le dictionnaire 
Elles sont basées sur des tables créés réellement dans le dictionnaire
de données.
 Accessibles uniquement si la base est ouverte. Commencent par les 
préfixes: USER_TABLES ?
ALL_TABLES ?
 USER_ concernent les objets possédées par l’utilisateur.
DBA TABLES ?
DBA_TABLES
 ALL_ concernent les objets accessibles
l bj ibl par l’utilisateur.
l’ ili
 DBA_ concernent TOUS les objets de la base. Accessible par 
l’administrateur.
 La vue DICTIONARY inclut des informations sur les vues statiques et 
dynamiques du dictionnaire de données.

28
 Dictionnaire de données –
Les vues statiques

Nom de la
l D
Description
i ti
vue
%_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
%_SEQUENCES T
Toutes l informations
les i f i concernant les
l séquences
é d la
de l base
b de d données.
d é

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

Dictionnaire de données –
Les vues dynamiques

 Elles ne sont pas basées sur des tables du dictionnaire de données. 
Elles ne sont pas basées sur des tables du dictionnaire de données
Leurs informations sont extraites de la mémoire et/ou des fichiers de 
contrôle.

 Commencent par le préfixe V$ et ne sont accessibles que par les 
administrateurs.

 Peuvent être consultées même si la base de données n’est pas ouverte

29
 Dictionnaire de données –
Les vues statiques

N
Nom de
d lla vue D
Description
i i
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_COMPON Informations détaillées sur les zones mémoire de la
ENTS 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.

Fonctionnement d’Oracle –
Requête SELECT (1)

 Le serveur BD reçoit une requête SELECT
Le serveur BD reçoit une requête SELECT
I. Phase de parse : le processus serveur vérifie si la requête existe 
dans le Library Cache.
a. Si elle n’y existe pas (Hard parse)
i. Une vérification syntaxique est faite
ii. Vérification sémantique (exactitude des tables & colonnes utilisées, 
d o ts d accès)
droits d’accès)
1. Si le DC contient les informations sémantiques, pas d’accès au disque
2. Sinon, accès au disque (dictionnaire de données)
iii. Calcul d’un plan d’exécution
b. Si elle existe (Soft parse)
i. Seule la vérification des privilèges est effectuée

30
 Fonctionnement d’Oracle –
Requête SELECT (2)

 Le serveur BD reçoit une requête SELECT
Le serveur BD reçoit une requête SELECT
I. Phase de parse : le processus serveur vérifie si la requête existe 
dans le Library Cache.
II. Phase d’exécution : exécution du plan d’exécution
a. Si les blocs de données sont dans le DBC, OK
b. Sinon, il les récupère des fichiers de données
III. Phase de fetch : renvoi du résultat de la requête par le processus 
h d f h d é l d l ê l
serveur, au processus utilisateur.

Fonctionnement d’Oracle –
Requête UPDATE (1)

 Le serveur BD reçoit une requête UPDATE
Le serveur BD reçoit une requête UPDATE
I. Phase de parse : la même que pour une requête SELECT.
II. Phase d’exécution :
a. Chargement des blocs à modifier dans le DBC, si elles n’y existent pas
b. Verrouillage des lignes à modifier
c. Un Redo Entry est généré pour la requête et est écrit dans le RLB
d. Modification des blocs dans le DBC, et écriture différée (par le DBW) des
Modification des blocs dans le DBC, et écriture différée (par le DBW) des 
modifications sur les fichiers de données
III. Phase de fetch : pas de résultat renvoyé. Juste un message 
décrivant le déroulement de l’opération.

31
 Fonctionnement d’Oracle –
Commande COMMIT

 Le serveur BD reçoit la commande COMMIT
Le serveur BD reçoit la commande COMMIT

I. Affectation d’un numéro SCN, par le LGWR, à la transaction validée

II. Écriture des Redo Entry de la transaction sur les fichiers journaux, par le 
LGWR

III. Suppression des informations d’annulation, en relation avec la 
transaction validée, des segments d’annulation

Fonctionnement d’Oracle –
Commande ROLLBACK

 Le serveur BD reçoit la commande ROLLBACK
Le serveur BD reçoit la commande ROLLBACK
I. Deux scénarii possibles :
a. Les blocs modifiés (dirty) sont déjà enregistrés dans les fichiers de 
données.
 Récupération de l’ancienne image à partir des segments d’annulation
b. Les blocs modifiés sont encore dans le DBC.
L’annulation n’engendre aucune écriture sur le disque.

32
 Démarrage de l’instance (1)

 Le démarrage de la base de données passe par trois étapes :
Le démarrage de la base de données passe par trois étapes :
I. Démarrage de l’instance
‐ Lecture du fichier de paramètres
‐ Allocation de la SGA et des processus selon les valeurs des paramètres
 État NOMOUNT : seuls les vues dynamiques du DD relatives à l’instance 
sont consultables (V$INSTANCE, V$PARAMETER, V$SGA etc.)
 Utilisé généralement pour créer une nouvelle BD
 STARTUP NOMOUNT

Démarrage de l’instance (2)

 Le démarrage de la base de données passe par trois étapes :
Le démarrage de la base de données passe par trois étapes :
II. Démarrage de la base de données
‐ L’administrateur précise une BD à monter
‐ L’instance ouvre le fichier de contrôle dont le chemin est la valeur du 
paramètre CONTROL_FILES
‐ Les chemins des fichiers de données et journaux sont lus, mais pas ouverts
‐ É
État MOUNT : seuls SYSDBA et SYSPOER peuvent interroger la BD
‐ La vue V$DATABASE est interrogeable, mais pas les vues statiques, 
puisque la base n’est pas ouverte
‐ Exemple de tâches : restauration, activation du mode ARCHIVELOG, 
déplacement des fichiers de données et journaux
 STARTUP MOUNT [nom_BD]

33
 Démarrage de l’instance (3)

 Le démarrage de la base de données passe par trois étapes :
Le démarrage de la base de données passe par trois étapes :
III. Ouverture de la base de données
‐ Ouverture des fichiers de données et journaux. État OPEN : tous les utilisateurs 
peuvent accéder à la BD. Toutes les vues du DD sont accessibles
‐ Si un tablespace a été mis en OFFLINE lors de l’arrêt, il le sera aussi à l’ouverture 
de la BD
‐ Si le dernier arrêt a été anormal, alors une opération de récupération est effectuée 
, p p
par SMON
 STARTUP OPEN [nom_BD]
‐ Il est possible d’ouvrir la BD en mode READ ONLY
 ALTER DATABASE OPEN READ ONLY
‐ Pour remettre la BD en mode READ WRITE
 ALTER DATABASE OPEN READ WRITE

Démarrage de l’instance (4)

 Démarrage en mode force
Démarrage en mode force
‐ Si le démarrage normal ne se produit pas, on peut forcer le démarrage
- STARTUP FORCE
 Démarrage en mode restreint
‐ Donne l’accès uniquement aux utilisateurs ayant le privilège RESTRICTED
SESSION
‐ Option utilisée si l’administrateur a des tâches de maintenance exécuter
Option tilisée si l’administrate r a des tâches de maintenance e éc ter
 STARTUP RESTRICT
‐ Pour désactiver le mode restreint
 ALTER SYSTEM DISABLE RESTRICTED SESSION

34
 Démarrage de l’instance (5)

 Démarrage suivant un PFILE
Démarrage suivant un PFILE
‐ Oracle démarre à partir de spfile<sid>.ora, si non trouvé, [Link], 
sinon init<sid>.ora
‐ Pour démarrer à partir d’un fichier PFILE spécifié par l’administrateur
‐  STARTUP PFILE=nom_pfile

 Syntaxe complète de la commande STARTUP
S nta e complète de la commande STARTUP
 STARTUP [NOMOUNT|MOUNT [nom_bd]|OPEN [nom_bd]] [FORCE]
[RESTRICT] [PFILE=nom_pfile]

Arrêt de la base de données

(1)

 La fermeture de la base passe par les mêmes étapes de son ouverture 
La fermeture de la base passe par les mêmes étapes de son ouverture
(mount, nomount et arrêt), mais ne s’arrête pas sur un de ces états
 Il existe 4 types d’arrêt:
I. Arrêt normal
‐ Oracle ne permet plus l’ouverture des nouvelles sessions
‐ Oracle attend q e le dernier tilisate r soit déconnecté po r arrêter l’instance
Oracle attend que le dernier utilisateur soit déconnecté pour arrêter l’instance
‐ Il s’agit d’un arrêt propre (checkpoint avant fermeture)
 SHUTDOWN NORMAL

35
 Arrêt de la base de données
(2)

 Il existe 4 types d
Il existe 4 types d’arrêt:
arrêt:
I. Arrêt normal
II. Arrêt Transactionnel
‐ Oracle ne permet plus le lancement de nouvelles transactions
‐ Oracle attend que la validation/annulation des transactions courantes
‐ Il s’a it d’ n arrêt propre (checkpoint avant fermeture)
Il s’agit d’un arrêt propre (checkpoint a ant fermet re)
 SHUTDOWN TRANSACTIONAL

Arrêt de la base de données

(3)

 Il existe 4 types d
Il existe 4 types d’arrêt:
arrêt:
I. Arrêt normal
II. Arrêt transactionnel
III. Arrêt immédiat
‐ Oracle annule toutes les transactions courantes et ferme la BD
‐ Il s’a it d’ n arrêt propre (checkpoint avant fermeture)
Il s’agit d’un arrêt propre (checkpoint a ant fermet re)
 SHUTDOWN IMMEDIATE

36
 Arrêt de la base de données
(4)

 Il existe 4 types d
Il existe 4 types d’arrêt:
arrêt:
I. Arrêt normal
II. Arrêt transactionnel
III. Arrêt immédiat
IV. Arrêt d’abandon
‐ Oracle ferme la BD sans faire de checkpoint C’est l’arrêt le pl s br tal
Oracle ferme la BD sans faire de checkpoint. C’est l’arrêt le plus brutal.
‐ Au prochain démarrage, une récupération des données, par le SMON, est 
effectuée
 SHUTDOWN ABORT

37