Introduction à l’Administration d’Oracle · 2015-10-10 · CHAPITRE 6 CREATION D’UNE...

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

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

Administration d’Oracle Database – Document 1.5 Feedbacks à www.bach-tobji.com

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

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.

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

Fichiers de données Fichiers de contrôleGroupes des fichiers de

journalisation

Archives des fichiers de

journalisationFichier de paramètres

Base de Données

Fichier de mot de

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.



11

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.

Data01.dbf Data02.dbf

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

Segment B (Extent 1)

Segment B (Extent 2)

Segment C (Extent 1)

Figure 2 : Structure d'un tablespace incluant deux fichiers

La Figure 2 présente un tablespace composé de deux fichiers de données. Le tablespace inclut

trois segments A, B et C. Les segments A et B incluent chacun deux extensions chacune sur un

fichier différent, pendant que le segment C inclut une seule extension.

La Figure 3 représente la structure logique et physique d’une base de données Oracle,

remarquez que le sens des flèches entre les différentes structures indique une relation un à

plusieurs.

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.



12

Database

Tablespace

Segment

Extension

Bloc de donnée

Fichier de

données

Bloc SE

Structure Logique Structure Physique

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

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.



13

INSERT INTO

UPDATE…

DELETE...

INSERT INTO

UPDATE…

DELETE...

DELETE

UPDATE

INSERT INTO

UPDATE

UPDATE…

INSERT INTO

DELETE

UPDATE

INSERT INTO

UPDATE

UPDATE…

INSERT INTO

Membre 1 Membre 2

Membre 1 Membre 2

Groupe 1

Groupe 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



14

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



15

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 :

Dictionary

Cache

Library

Cache

DB Buffer

Cache

Shared

Pool

Redo Log

Buffer

Java PoolStreams

PoolLarge Pool

SGA

Figure 5 : Les composantes de la SGA



16

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



17

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



18

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.



19

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



20

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



21

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,



22

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



23

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



24

DBA_DATA_FILES.

Java PoolStreams

PoolLarge Pool

SGA

Fichiers de données Fichiers de contrôleGroupes des fichiers de

journalisation

Archives des fichiers de

Base de Données

DBW0 LGWR ARC0CKPT

RECO SMONPMON

D000

Fichier de paramètres journalisationFichier de mot de

passe

Serveur de Base de Données Oracle

User Process

User Process

User Process

Dictionary

Cache

Library

Cache

DB Buffer

Cache

Shared

Pool

Redo Log

Buffer

PGA

Shared

Server

Process

PGA

Dedicated

Server

Process

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



25

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.



26

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.



27

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 · 2015-10-10 · CHAPITRE 6 CREATION D’UNE...

Documents

Transcript of Introduction à l’Administration d’Oracle · 2015-10-10 · CHAPITRE 6 CREATION D’UNE...