Introduction À L'administration D'oracle

Université de Manouba
École Supérieure d’Économie Numérique

Département des Technologies des Systèmes d’Information
Introduction à l’Administration
d’Oracle
Document version 1.5
Dr. Mohamed Anis BACH TOBJI

http://www.bach-tobji.com
Table des matières
CHAPITRE 1 INTRODUCTION ........................................................................... 6
1.1 Oracle : Vue d’ensemble .................................................................................................................... 6
1.2 Oracle Database ................................................................................................................................. 7
1.3 Interaction avec Oracle Database ..................................................................................................... 8
CHAPITRE 2 ARCHITECTURE D’ORACLE DATABASE .................................. 9
2.1 La base de données ............................................................................................................................. 9

2.1.1 Les fichiers de contrôle ................................................................................................................... 9
2.1.2 Les fichiers de données ................................................................................................................. 10
2.1.3 Les fichiers de journalisation ........................................................................................................ 11
2.1.4 Les archives des fichiers de journalisation .................................................................................... 13
2.1.5 Le fichier de paramètres ................................................................................................................ 13
2.1.6 Le fichier de mot de passe ............................................................................................................. 14
2.1.7 Autres fichiers ............................................................................................................................... 14
2.2 L’instance ......................................................................................................................................... 15

2.2.1 Les structures mémoires ................................................................................................................ 15
2.2.2 Les processus ................................................................................................................................ 18
2.3 Le schéma ......................................................................................................................................... 22
2.4 Le dictionnaire de données .............................................................................................................. 23

2.4.1 Les vues statiques .......................................................................................................................... 23
2.4.2 Les vues dynamiques de performance ........................................................................................... 24
2.5 Fonctionnement d’Oracle ................................................................................................................ 25

2.5.1 Pour exécuter une requête SELECT .............................................................................................. 25
2.5.2 Pour exécuter une requête UPDATE .............................................................................................. 26
2.5.3 Lors d’un COMMIT ........................................................................................................................ 26
2.5.4 Lors d’un ROLLBACK ................................................................................................................... 26
CHAPITRE 3 DEMARRAGE/ARRET DE LA BASE DE DONNEES ET

GESTION DE L’INSTANCE ..................................................................................... 28
3.1 Démarrage et Arrêt de la base de données .................................................................................... 28

3.1.1 Démarrage de la base de données.................................................................................................. 28
3.1.2 Arrêt de la base de données ........................................................................................................... 30
3.2 Gestion de l’instance ........................................................................................................................ 31

3.2.1 Paramètres dynamiques et paramètres statiques ............................................................................ 31
3.2.2 Instancier les paramètres via SQL ................................................................................................. 31
3.2.3 Exporter un fichier de paramètres ................................................................................................. 32
CHAPITRE 4 GESTION DES TABLESPACES ................................................. 33
4.1 Tablespaces : types et conseils d’utilisation ................................................................................... 33
4.2 Les tablespaces permanents ............................................................................................................ 34

4.2.1 Création des tablespaces permanents ............................................................................................ 34
4.2.2 Extension des tablespaces permanents .......................................................................................... 35
4.2.3 Basculer entre les modes OFFLINE/ONLINE .............................................................................. 36
4.2.4 Basculer entre les modes READ ONLY/READ WRITE .............................................................. 37
4.2.5 Basculer entre les modes LOGGING/NOLOGGING ................................................................... 37
4.2.6 Basculer entre les modes FORCE LOGGING/NO FORCE LOGGING ...................................... 37
4.2.7 Renommer un tablespace .............................................................................................................. 37
4.2.8 Renommer/déplacer un fichier de données ................................................................................... 37
4.2.9 Suppression d’un tablespace ......................................................................................................... 38
4.3 Gestion de l’espace à l’intérieur des tablespaces ........................................................................... 38

4.3.1 Les tablespaces gérés par le dictionnaire de données .................................................................... 39
4.3.2 Les tablespaces gérés localement .................................................................................................. 40
4.4 Informations sur les tablespaces ..................................................................................................... 41
CHAPITRE 5 GESTION DES UTILISATEURS ................................................. 43
5.1 L’objet USER .................................................................................................................................... 43

5.1.1 La connexion ................................................................................................................................. 43
5.1.2 Création d’un utilisateur ................................................................................................................ 43
5.1.3 Modification d’un utilisateur ......................................................................................................... 44
5.1.4 Suppression d’un utilisateur .......................................................................................................... 45
5.1.5 Informations sur les utilisateurs .................................................................................................... 45
5.2 L’objet PROFILE ............................................................................................................................. 45
5.3 Les privilèges .................................................................................................................................... 46

5.3.1 Les privilèges système .................................................................................................................. 47
5.3.2 Les privilèges objet ....................................................................................................................... 48
5.4 L’objet ROLE .................................................................................................................................... 49

5.4.1 Création et modification d’un rôle ................................................................................................ 49
5.4.2 Attribuer/retirer un privilège à un rôle .......................................................................................... 50
5.4.3 Attribuer/retirer un rôle à un utilisateur......................................................................................... 51
5.4.4 Activer/désactiver un rôle ............................................................................................................. 51
CHAPITRE 6 CREATION D’UNE NOUVELLE BASE DE DONNEES .............. 53

6.1 Créer les répertoires sur le disque : ................................................................................................ 53
6.1.1 La norme OFA .............................................................................................................................. 53
6.1.2 La création des répertoires ............................................................................................................ 55
6.2 Préparer un fichier de paramètres ................................................................................................. 56
6.3 Créer le service associé à l’instance ................................................................................................ 56
6.4 Lancer SQL*PLUS .......................................................................................................................... 57
6.5 Créer le fichier de paramètres serveur .......................................................................................... 57
6.6 Démarrer l’instance ......................................................................................................................... 57
6.7 Créer la base de données ................................................................................................................. 58
6.8 Finalisation de la création du dictionnaire de données ................................................................. 60
CHAPITRE 7 GESTION DES FICHIERS DE CONTROLE ET DE

JOURNALISATION .................................................................................................. 61
7.1 Gestion des fichiers de contrôle ...................................................................................................... 61

7.1.1 Création initiale des fichiers de contrôle ....................................................................................... 61
7.1.2 Création de copies additionnelles, renommage, et déplacement des fichiers de contrôle ............. 62
7.1.3 S’informer sur les fichiers de contrôle .......................................................................................... 62
7.2 Gestion des fichiers de journalisation ............................................................................................ 63

7.2.1 Informations sur les fichiers journaux ........................................................................................... 63
7.2.2 Définir le nombre et les tailles des fichiers de journalisation ........................................................ 64
7.2.3 Gestion des fichiers journaux ........................................................................................................ 65
CHAPITRE 8 GESTION DES INFORMATIONS D’ANNULATION.................... 68
8.1 Segment d’annulation : vue d’ensemble......................................................................................... 68

8.1.1 Utilité des informations d’annulation ............................................................................................ 68
8.1.2 Gestion des informations d’annulation .......................................................................................... 68
8.1.3 Le segment d’annulation SYSTEM .............................................................................................. 69
8.1.4 Fonctionnement d’un segment d’annulation ................................................................................. 69
8.1.5 La durée de rétention des informations d’annulation .................................................................... 69
8.2 La gestion automatique des informations d’annulation ............................................................... 70

8.2.1 La mise en œuvre .......................................................................................................................... 70
8.2.2 Fonctionnement d’un tablespace d’annulation .............................................................................. 71
8.2.3 Création d’un tablespace d’annulation .......................................................................................... 71
8.2.4 Changement du tablespace d’annulation actif ............................................................................... 72
8.2.5 Modification et suppression d’un tablespace d’annulation ........................................................... 72
CHAPITRE 9 GESTION DES TABLES ET DES INDEX ................................... 73

9.1 La gestion des tables ........................................................................................................................ 73
9.1.1 Organisation du stockage dans les blocs ....................................................................................... 73
9.2 Le ROWID ........................................................................................................................................ 76
9.3 Chainage et migration ..................................................................................................................... 76
9.4 Spécifier le stockage d’une table ..................................................................................................... 77
CHAPITRE 10 SAUVEGARDE ET RESTAURATION ....................................... 81
10.1 Archivage des fichiers de journalisation ........................................................................................ 81
10.2 Les stratégies de sauvegarde ........................................................................................................... 83
10.3 Archivage des fichiers journaux ................................................................ Erreur ! Signet non défini.
BIBLIOGRAPHIE ................................................................................................. 86
Chapitre 1 Introduction
Dans ce cours, nous essayerons d’illustrer les notions de base de l’administration d’un serveur
de base de données à travers la technologie Oracle. Le choix se porte sur Oracle parmi une
variété d’éditeurs (IBM, Microsoft etc.) pour diverses raisons :
1- Il s’agit du leader du marché des SGBD.
2- La documentation est abondante sur le Web.
3- En Tunisie, il existe un représentant officiel de la firme (ORADIST), qui aide les
académiques à travers la documentation et les formations des universitaires.
Pour une maitrise parfaite de l’administration d’un serveur de bases de données, il faut passer
par trois étapes, à savoir l’assimilation de l’architecture d’un serveur BD, l’administration du
serveur, et finalement l’optimisation du serveur. Seul le troisième volet ne sera pas évoqué dans
ce cours.
1.1 Oracle : Vue d’ensemble

Oracle Corporation est sans conteste le leader du marché des Systèmes de Gestion de Base de
Données Relationnelles, disposant de la plus grande part de marché (année 2013). Le produit
fondamental commercialisé par Oracle est « Oracle Database », cela n’empêche que la firme
américaine commercialise d’autres types de produits intégrés. La famille de produits Oracle est la
suivante :
- Oracle Database
- Oracle Developer Suite
- Oracle Application Server
- Oracle Applications
- Oracle Collaboration Suite
- Oracle Services
Brièvement, Oracle Database est le SGBD qui permet de stocker, gérer, administrer et
manipuler des données d’un grand volume tout en assurant performance, sécurité et accès
concurrentiel. Les fonctions décrites ci-dessus ne sont naturellement pas exhaustives, mais plutôt
basiques et Oracle ne cesse d’innover en ce sens. La version Database la plus évoluée étant
Oracle 12c (parue fin 2013). Oracle Developer Suite est un ensemble d’outils de conception
(Developer Designer), développement (Developer Forms, JDeveloper), édition d’états (Developer Reports,
Discoverer), implémentation de Data Warehouse (Warehouse Builder) et de déploiement
d’applications basés Web. Oracle Application Server est utilisé pour le déploiement
d’applications Web développés entre autres par Oracle Developer Suite. Ce produit assure la
fiabilité et l’efficacité d’utilisation des applications pour des milliers d’utilisateurs distants. Oracle
Introduction 7
Applications est un ensemble de modules standard prédéveloppés et paramétrables qui gèrent le

personnel, la finance, la production, la vente, les achats, et autres fonctions d’entreprises de
différents secteurs. À noter que ces modules utilisent naturellement Oracle Database, Developer
Suite et Application Server. Oracle Collaboration Suite est un système exhaustif qui intègre des
outils puissants de collaboration et de communication allant de la messagerie électronique
jusqu’aux systèmes de conférences Web en passant par la télécopie, la messagerie instantanée, le
calendrier partagé ainsi que la gestion de documents. Oracle Collaboration Suite utilise aussi
Oracle Database, Oracle Developer Suite et Oracle Application Server. Oracle Services offre
une plateforme complète de support technique aux utilisateurs pour qu’ils puissent choisir,
installer, et configurer leurs outils Oracle de la meilleure manière possible relativement à leurs
besoins spécifiques.
Cette vue d’ensemble nous permet de mieux nous situer par rapport à l’ensemble des produits
d’Oracle. En effet, nous essayerons à travers ce polycopié d’introduire les bases de
l’administration d’un SGBD Oracle, ce qui nous place sur le produit « Database » parmi la
panoplie des produits listés ci-dessus. Architecture basique et minimale d’Oracle Database,
gestion de la mémoire, gestion du stockage physique et gestion de la sécurité seront donc les
principaux axes de ce document.
1.2 Oracle Database

C’est le produit principal d’Oracle, soit le Système de Gestion de Bases de Données
Relationnelles qui est disponible sur plusieurs plateformes telles que Windows, Linux et Unix.
Depuis 1977, année de création de la firme Oracle (jadis appelée SDL pour Software Development
Laboratories), le produit Database est passé de la version 1 à la version 11g en 30 ans. Dans ce
polycopié, nous nous basons sur des documents (voir bibliographie) qui traitent surtout les
versions 10g et 9i. Il est à noter qu’Oracle Database est disponible sous différentes éditions, les
voici :
- Enterprise Edition : inclut toutes les fonctionnalités d’Oracle Database, en standard ou en
option, et gère des données extrêmement volumineuses.
- Standard Edition : inclut les fonctionnalités de base, mais ne permet pas d’exploiter
certaines options avancées. Cette édition est d’ailleurs destinée pour des serveurs avec une
capacité maximale de quatre processeurs.
- Standard Edition One : pratiquement identique à l’édition standard mais limité à des
serveurs biprocesseurs.
- Personal Edition : disponible uniquement sur Windows, destinée aux développeurs pour
une utilisation mono-utilisateur.
- Express Edition : complètement gratuite, destinée pour des machines monoprocesseurs et
spécialement pour les petites entreprises, voire les institutions à but académique.
- Lite Edition : inclut les fonctionnalités requises pour le développement et le déploiement
Administration d’Oracle Database – Document 1.5

Feedbacks à www.bach-tobji.com
Introduction 8
d’applications et de base de données mobiles.

Cela étant dit, les notions de base étalées dans ce polycopié concernent toutes les éditions
voire même les dernières versions. D’ailleurs nous ne manquerons pas de vous signaler une
nouveauté particulière qui correspond à la version 10g.
1.3 Interaction avec Oracle Database

Le moyen le plus basique d’interagir avec les objets d’une base de données Oracle, tels que les
tables, les séquences, les index, les utilisateurs, les vues etc., est le langage SQL servant à définir
(LDD), manipuler (LMD) et contrôler (LCD) les données. Un utilisateur peut formuler des
requêtes SQL via :
- SQL*Plus qui est un éditeur permettant la saisie et l’affichage des résultats de requêtes
SQL. Naturellement, pour accéder aux objets de la base de données, il faut que l’utilisateur
ait un login et un mot de passe et qu’il connaisse la chaîne de connexion (connection
string) de la base de données si elle est distante, sachant que dans ce cas, l’éditeur
SQL*Plus est juste installé sur un poste client.
- iSQLPlus est aussi un éditeur de saisie de requêtes SQL. A la différence de SQL*Plus,
c’est un éditeur Web et donc au poste client (celui de l’utilisateur), il suffit d’avoir un
navigateur Web ainsi que l’URL du serveur hébergeant la base de données, avec bien sur
un login et un mot de passe, pour que la connexion soit réussie.
Il existe d’autres outils d’administration et de développement. Oracle Discoverer par exemple
est un outil graphique qui permet à l’utilisateur de sélectionner les tables qu’il veut interroger en
cliquant dessus. Oracle Forms et Oracle Reports permettent respectivement de développer des
applications Web et d’éditer des états basés sur les données d’Oracle Database. OEM (Oracle
Enterprise Manager) quant à lui est une interface graphique qui permet l’administration et la
configuration d’Oracle Database. Lorsque l’utilisateur change la valeur d’un paramètre dans
l’interface, une requête SQL est générée et est envoyée à la base de données. OEM est disponible
en version Web et donc utilisable à partir de n’importe quel poste client connecté au serveur base
de données (à condition que le processus OEM soit lancé sur le serveur, ou en version client (EM
Client) installable sur la machine client et offre les même possibilités que la version Web.
Le langage1 PL/SQL permet aussi l’interaction avec Oracle Database. C’est un langage
procédural extension du langage SQL qui permet non seulement d’utiliser des structures
conditionnelles et itératives et de traiter les exceptions, mais aussi de créer des fonctions et
procédures personnalisées et de développer des packages et des déclencheurs.
1Il faut bien faire la différence entre langage (tel que SQL et PL/SQL) et outil tel qu’un éditeur ou autre nous
permettant soit de saisir du code, soit de manipuler directement et graphiquement les objets base de données (OEM,
SQL*Plus, iSQLPlus etc.).

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.
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
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 10
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 index1 consomment de l’espace disque
en dehors du dictionnaire de données. Plus précisément, ils occupent de l’espace mémoire sur les
fichiers de données. Les autres types d’objets n’ont qu’une 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 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.
Segment A (Extent 1) Segment A (Extent 2)
Segment B (Extent 2)
Segment B (Extent 1)
Segment C (Extent 1)
Data01.dbf Data02.dbf
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.
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.
1 Il existe en effet d’autres objets occupant de l’espace disque, tel que les vues matérialisées, les tables organisées
en index (IOT), les clusters etc.

Database
Fichier de
Tablespace
données
Segment
Extension
Bloc de donnée Bloc SE
Structure Logique Structure Physique
Figure 3 : Structure logique et physique d'une base de données Oracle
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 V$LOGFILE contient toutes les informations qui concernent les fichiers journaux de la
base de données.

Groupe 1
DELETE DELETE
UPDATE UPDATE
INSERT INTO INSERT INTO
UPDATE UPDATE
UPDATE… UPDATE…
Membre 1 Membre 2
Groupe 2

UPDATE… UPDATE…
DELETE... DELETE...
Membre 1 Membre 2
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
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 conditionnent l’initialisation de
l’instance, et ensuite son fonctionnement. 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 identification
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 ordinaires) car l’instance n’est pas encore chargée en mémoire. La vérification se fait
alors à partir d’un fichier physique qui inclut l’ensemble des administrateurs de la base de données
avec leurs mots de passe ; il s’agit du fichier du mot de passe.
Ce fichier peut être quand même optionnel car l’authentification à Oracle Database peut être
reliée au système d’exploitation qui l’héberge. Cela veut dire qu’une fois que l’administrateur
ouvre une session sur le système d’exploitation (SE), il peut lancer automatiquement l’instance
Oracle sans aucune identification. Pour ce, il suffit de créer au niveau du SE un groupe
d’utilisateur, généralement appelée dba, d’y ajouter les utilisateurs qu’on veut administrateurs de la
base, et de relier ce groupe à Oracle au moment de l’installation d’Oracle.
Le paramètre REMOTE_LOGIN_PASSWORDFILE nous renseigne sur le type d’identification pour
accéder à l’instance. Si sa valeur est mise à none, alors l’identification se produit à travers le SE. Si
la valeur est à exclusive, alors le fichier de mot de passe ne peut concerner qu’une seule base de
données. Dans ce cas, le fichier peut inclure les informations d’identification de l’utilisateur SYS,
ainsi que d’autres utilisateurs ayant reçu les privilèges d’administration (plus précisément, les
privilèges SYSDBA ou SYSOPER qui seront vus plus tard au Chapitre 5). Si la valeur dudit
paramètre est mise à shared, alors le fichier de mot de passe peut être partagé par plusieurs bases
de données. Dans ce cas, le fichier ne peut inclure que les informations d’identification de
l’utilisateur SYS.
2.1.7 Autres fichiers

Il existe d’autres fichiers physiques nécessaires au bon fonctionnement d’Oracle. Parmi ces
fichiers, nous citerons brièvement les fichiers alertes, les fichiers traces et les fichiers de
sauvegarde.
Lorsqu’une erreur interne est détectée par un processus d’arrière plan ou serveur1, ce dernier
inscrit les détails de l’erreur sur un fichier de trace. Certaines des informations écrites sur les
fichiers de trace sont utiles à l’administrateur soit pour débloquer le serveur, soit pour l’optimiser.
Les fichiers de trace écrits par les processus d’arrière plan sont stockés dans le répertoire
renseigné par le paramètre BACKGROUND_DUMP_DEST. Les fichiers de trace écrits par les processus
1 Les processus arrière plan et les processus serveur sont des programmes Oracle en exécution qui permettent à
l’instance de gérer les requêtes utilisateurs en assurant sécurité, intégrité et performance des données traitées. Ils
seront détaillés à la section 2.2.2).

serveurs sont stockés dans USER_DUMP_DEST. Les fichiers de trace portent l’extension .trc.
Les fichiers d’alertes stockent des informations relatives à des évènements et des messages
importants qui correspondent à une base de données. Le chemin des fichiers d’alerte se trouve au
répertoire BACKGROUND_DUMP_DEST. Les fichiers d’alerte portent l’extension .log.
Pour restaurer (reconstituer) un fichier endommagé (de données, de contrôle, de paramètres
etc.), nous avons besoin d’un fichier de sauvegarde. La sauvegarde est supposée déjà faite avant
que le problème endommageant le fichier original ne se produise.
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).
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 :
SGA
Dictionary
Cache
Library
Cache
DB Buffer Shared Redo Log

Cache Pool Buffer
Streams
Java Pool Large Pool
Pool
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.
 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 places 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 paramètre DB_CACHE_SIZE désigne la taille du cache, il doit être naturellement un multiple
de la taille d’un bloc de données.
À noter qu’un 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
l’instance.
- 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é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.
Le paramètre LOCK_SGA est un paramètre booléen (qui prend true ou false). Il permet à
l’administrateur d’obliger (ou non) Oracle à allouer la zone SGA exclusivement en mémoire
physique, sans ayant recours à la mémoire virtuelle.
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
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 (Automatic Shared Memory Management ASMM)

La SGA peut être gérée automatiquement ou manuellement. Une gestion manuelle consiste
tout simplement à instancier les tailles des zones mémoire une par une ; le choix de
l’administrateur s’effectue 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 une quantité de
mémoire précisée par l’administrateur à travers le paramètre SGA_TARGET. La gestion
automatique est donc 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. À noter que la taille du log buffer n’est pas prise en
charge par la gestion automatique, sa taille est déduite du SGA_TARGET.
Lorsque la gestion de la SGA est automatique (vs manuelle), l’instance dispatche la quantité de
mémoire renseignée par le paramètre SGA_TARGET au Shared Pool, DB Buffer Cache, Java Pool,
Large Pool, Streams Pool. Oracle consulte des statistiques et des vues internes pour distribuer la
quantité de mémoire globale aux zones mémoires de manière à maximiser la performance du
serveur. Comme la charge de travail du serveur varie dynamiquement, Oracle se permet de
changer dynamiquement le dispatching de la quantité totale de mémoire aux différentes zones
mémoires de la SGA.
Il est à noter que si la valeur de SGA_TARGET dépasse SGA_MAX_TARGET, alors Oracle met à
jour le deuxième paramètre en l’augmentant.
b. Program Global Area (PGA)
C’est une zone mémoire privée (à la différence de la SGA) dédiée aux utilisateurs. Elle est
créée pour chaque processus serveur quand il est initié. 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 est exclusivement accédée par le processus serveur.
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 aux 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
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.
Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est le
paramètre 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 b).
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
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
fichiers journaux 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
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 relatives à 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 ou en READ ONLY d’un tablespace.
Le checkpoint peut être forcé à travers la requête :
ALTER SYSTEM CHECKPOINT
- 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
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).
- MMAN (Memory Manager) est un processus introduit par Oracle 10g qui gère les tailles des
composantes de la SGA lorsque l’ASMM est activée.
- MMON (Memory Monitor) est un processus introduit par Oracle 10g. Son objectif est de
collecter des statistiques sur la SGA. MMON est déclenché toutes les 60 minutes pour
collecter des statistiques à partir des vues dynamiques et statiques du dictionnaire de
données et les stocker dans des tables de la base de données appelées Automatic
Workload Repository (AWR). Le propriétaire de ces tables est SYSMAN et sont stockées
dans le tablespace SYSAUX. Pour activer l’AWR, il faut instancier le paramètre
STATISTICS_LEVEL. La valeur assignée à ce paramètre détermine le niveau de statistiques
que le MMON doit collecter ; BASIC veut dire que l’AWR est désactivé (ce qui désactive
plusieurs options de monitoring automatique) et que peu de statistiques sont collectées.
TYPICAL est le niveau standard, il s’agit de la valeur par défaut du paramètre. ALL permet
la collecte des statistiques du niveau TYPICAL avec en plus les plans d’exécution ainsi que
d’autres informations reliées au système d’exploitation.
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
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.
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
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ées 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.
RECO 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
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
Figure 6 : L’interaction Instance-Base de données-Utilisateurs
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.
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 vue V$FIXED_TABLE, accessible par SYS contient les
informations de toutes les vues dynamiques. La Table 2 présente certaines de ces vues.
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 :
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
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 BD.

Table 2 : Quelques vues dynamiques de performance
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, de leur ordre etc.) 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.
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 confirmée 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.


Introduction À L'administration D'oracle

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduction À L'administration D'oracle

Transféré par

Droits d'auteur :

Formats disponibles

Université de Manouba

École Supérieure d’Économie Numérique

Dr. Mohamed Anis BACH TOBJI

CHAPITRE 1 INTRODUCTION ........................................................................... 6

1.1 Oracle : Vue d’ensemble .................................................................................................................... 6

1.2 Oracle Database ................................................................................................................................. 7

1.3 Interaction avec Oracle Database ..................................................................................................... 8

CHAPITRE 2 ARCHITECTURE D’ORACLE DATABASE .................................. 9

2.1 La base de données ............................................................................................................................. 9

2.2 L’instance ......................................................................................................................................... 15

2.3 Le schéma ......................................................................................................................................... 22

2.4 Le dictionnaire de données .............................................................................................................. 23

2.5 Fonctionnement d’Oracle ................................................................................................................ 25

CHAPITRE 3 DEMARRAGE/ARRET DE LA BASE DE DONNEES ET

3.1 Démarrage et Arrêt de la base de données .................................................................................... 28

3.2 Gestion de l’instance ........................................................................................................................ 31

CHAPITRE 4 GESTION DES TABLESPACES ................................................. 33

4.1 Tablespaces : types et conseils d’utilisation ................................................................................... 33

4.2 Les tablespaces permanents ............................................................................................................ 34

4.3 Gestion de l’espace à l’intérieur des tablespaces ........................................................................... 38

4.4 Informations sur les tablespaces ..................................................................................................... 41

CHAPITRE 5 GESTION DES UTILISATEURS ................................................. 43

5.1 L’objet USER .................................................................................................................................... 43

5.2 L’objet PROFILE ............................................................................................................................. 45

5.3 Les privilèges .................................................................................................................................... 46

5.4 L’objet ROLE .................................................................................................................................... 49

CHAPITRE 6 CREATION D’UNE NOUVELLE BASE DE DONNEES .............. 53

6.2 Préparer un fichier de paramètres ................................................................................................. 56

6.3 Créer le service associé à l’instance ................................................................................................ 56

6.4 Lancer SQL*PLUS .......................................................................................................................... 57

6.5 Créer le fichier de paramètres serveur .......................................................................................... 57

6.6 Démarrer l’instance ......................................................................................................................... 57

6.7 Créer la base de données ................................................................................................................. 58

6.8 Finalisation de la création du dictionnaire de données ................................................................. 60

CHAPITRE 7 GESTION DES FICHIERS DE CONTROLE ET DE

7.1 Gestion des fichiers de contrôle ...................................................................................................... 61

7.2 Gestion des fichiers de journalisation ............................................................................................ 63

CHAPITRE 8 GESTION DES INFORMATIONS D’ANNULATION.................... 68

8.1 Segment d’annulation : vue d’ensemble......................................................................................... 68

8.2 La gestion automatique des informations d’annulation ............................................................... 70

CHAPITRE 9 GESTION DES TABLES ET DES INDEX ................................... 73

9.2 Le ROWID ........................................................................................................................................ 76

9.3 Chainage et migration ..................................................................................................................... 76

9.4 Spécifier le stockage d’une table ..................................................................................................... 77

CHAPITRE 10 SAUVEGARDE ET RESTAURATION ....................................... 81

10.1 Archivage des fichiers de journalisation ........................................................................................ 81

10.2 Les stratégies de sauvegarde ........................................................................................................... 83

1.1 Oracle : Vue d’ensemble

Applications est un ensemble de modules standard prédéveloppés et paramétrables qui gèrent le

1.2 Oracle Database

Administration d’Oracle Database – Document 1.5

d’applications et de base de données mobiles.

1.3 Interaction avec Oracle Database

Administration d’Oracle Database – Document 1.5

2.1 La base de données

Groupes des fichiers de

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

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

2.1.1 Les fichiers de contrôle

2.1.2 Les fichiers de données

SELECT tablespace_name, file_name FROM DBA_DATA_FILES

Administration d’Oracle Database – Document 1.5

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