SGBD : Administration des bases de

données, contrôle de concurrences

Dr. SAGAR Samya
Objectifs du cours
} Concrétiser la conception physique des bases de données
} Démystifier les ordres SQL simples (create, select, insert into, …)
} Comprendre les choix de conception physique
} Comprendre la gestion des transactions et accès concurrents
} Les objectifs techniques sous Oracle
} Comprendre et décrire l'architecture d'un serveur de BD Oracle
} Installer et configurer Oracle Database 11g
} Démarrage et arrêt d’une instance et d’une base de données Oracle
} Création d’une base de données opérationnelle
} Gestion des fichiers d'une base de données Oracle
} Gestion de la structure logique(tablespaces, segments, extents et blocs)
} Gestion des utilisateurs, des privilèges et des ressources
} Sauvegarde/restauration/réorganisation des données

2 SAGAR Samya
Pré-requis du cours
} Autour des BD
} Modèle relationnel et BDR
} Langage de requêtes (SQL)
} Transactions
} Langage de programmation et BD

} Autour des systèmes d’exploitation

} Hiérarchie de la mémoire
} Gestion du cache de données
} Politique de défaut de pages

3 SAGAR Samya
 Partie 2
Architecture d’un SGBD : mise
en œuvre avec Oracle

4 SAGAR Samya
Architecture d’Oracle
PLAN
1. Les clients et les serveurs d'Oracle
2. Le serveur Oracle : Les processus, les structures de la
mémoire et les fichiers d'Oracle
3. Traitement d'une requête d'interrogation
4. Traitement d'un ordre de modification / ajout /
suppression
5. Traitement d'un ordre de fin de transaction (commit)

5 SAGAR Samya
Architecture d’Oracle
1. Les clients et les serveurs d'Oracle
1 serveur <--> plusieurs clients
Oracle Oracle
} Utilisateurs
} Connexion directe à l'hôte
} Connexion client/serveur ou deux tiers
} avec les outils OEM;
} ou avec une application développée en Client/Serveur.
} Administrateurs
} chargés de l'entretien du serveur Oracle

6 SAGAR Samya
Architecture d’Oracle
1. Les clients et les serveurs d'Oracle
Connexion à une base de données
} via SQL*Plus ou application tierce => lancement d'un
processus utilisateur sur le poste du client (qui peut être le
serveur)
} lors de la connexion
(login/passwd/service BD)
=> lancement d'un processus serveur sur le serveur
} communication
} inter-processus si les 2 processus s'exécutent sur le même poste
} via un logiciel de réseau sinon
} Session: connexion spécifique entre un utilisateur et un
serveur prêt à l'emploi (un serveur démarré).
7 SAGAR Samya
Architecture d’Oracle
1. Les clients et les serveurs d'Oracle
Processus Utilisateur
} Fonctionne sur la machine du client
} Démarre lors de l'appel d'un outil ou d'une application
} Exécute l'outil ou l'application
(SQL*Plus, Server Manager, OEM, etc.)
} Inclut l'UPI
( User Program Interface)
} Appelle le serveur Oracle

8 SAGAR Samya
Architecture d’Oracle
1. Les clients et les serveurs d'Oracle
Processus Serveur
} Fonctionne sur la même machine que le serveur Oracle
} En cas de serveur dédié, prend en charge un unique
processus utilisateur
} Utilise une PGA exclusive ( Program Global Area)
} Inclut l'OPI ( Oracle Program Interface)
} Traite les appels générés par le client
} Retourne les résultats au client

} En cas de serveur partagé (MTS), plusieurs processus

utilisateurs partagent un processus serveur

9 SAGAR Samya
Architecture d’Oracle
1. Les clients et les serveurs d'Oracle
Types d’architecture
} Architecture à serveur dédié
} Architecture 1processus 1processus
Client Serveur
} la plus simple
} la plus répandue
} Inadapté si beaucoup de clients connectés de façon simultanée
} Architecture à serveur partagé
} Serveur partagé ou n processus 1processus
Clients Serveur
Multi-Thread Server (MTS)
} Gestion d'une file de requêtes des processus clients et de
réponses à retourner
} Dispatcher + Listener

10 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle

Serveur Oracle = instance Oracle+ base de données Oracle

} Le serveur Oracle
} Il s'agit du système installé sur une machine qui va permettre la
gestion de toutes les bases de données disponibles sur la
machine.
} Instance Oracle
} C'est un moyen pour accéder à une base de données Oracle
} Ouvre une unique base de données
} Instance Oracle = SGA + des processus en arrière plan
pour gérer la base + un processus serveur
11 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Instance
Processus
utilisateur Zone de mémoire SGA
partagée

Cache de la
librairie
Processus Cache de Cache de
Cache du dict. données reprise
serveur
de données
PGA

SMON DBWR PMON CKPT LGWR Autres

Fichier de Fichiers de Fichiers de Fichiers de

données contrôle journalisation
paramètres Fichiers journaux
archivés

Fichier de
mots de passe

12 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Instance Oracle : Structure de la mémoire d'Oracle
} Principales composantes sont :
} la SGA (System Global Area)
} la PGA (Program Global Area)
} la zone de Tri (Sort Area Size)
} Gérer essentiellement selon le principe dit LRU (Last Recent
Used)
} La taille de ces zones est déterminée grâce à des paramètres
d'initialisation
} Un sous-dimensionnement peut entraîner des pertes
importantes de performances

13 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Instance Oracle : la SGA
} SGA (Shared Global Area) ou Zone mémoire globale du
système
} Contient les données et les informations de contrôle
pour le serveur Oracle
} Fait le lien avec le processus serveur
} Alloué en mémoire virtuelle par le système d'exploitation
du serveur
} Elle comprend
} Une zone partagée (shared pool)
} Le cache de données (Data buffer cache)
} Le cache de reprise (redo log buffer)
14 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de données (Data buffer cache)
} Objectif :
} minimiser les coûts d'entrées/sorties entre la mémoire centrale et la mémoire
secondaire
} Zone de chargement et de mise à jour en mémoire des blocs de données (blocs les
plus récemment utilisés)
} Ces blocs proviennent des fichiers de données
} Les blocs concernés peuvent être :
} des blocs de tables et clusters
} des blocs d'index (B-tree, Bitmap, Reverse Key, …)
} des blocs des rollback segments
} Le buffer de données est géré selon le mécanisme LRU (Last Recent Used) :
} Seul les blocs les plus récemment utilisés sont maintenus en mémoire. Les blocs
les moins récemment utilisés sont éjectés du Buffer de données, ceux modifiés
écrits dans les fichiers de données

15 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de données (Data buffer cache)
} Paramètres d'initialisation influençant sa taille :
} DB_CACHE_SIZE : nombre de blocs du buffer de données par défaut.
} DB_BLOCK_SIZE : taille du bloc par défaut
} DB_16K_CACHE_SIZE : nombre de blocs du buffer de données de blocs de 16K
} DB_2K_CACHE_SIZE : nombre de blocs du buffer de données de blocs de 2K
} DB_32K_CACHE_SIZE : nombre de blocs du buffer de données de blocs de 32K
} DB_4K_CACHE_SIZE: nombre de blocs du buffer de données de blocs de 4K
} DB_8K_CACHE_SIZE : nombre de blocs du buffer de données de blocs de 8K
} Oracle peut gérer plusieurs buffers de données avec des tailles de blocs
différents si DB_CACHE_SIZE et au moins un DB_xK_CACHE_SIZE sont
posés
} DB_CACHE_SIZE et DB_xK_CACHE_SIZE sont modifiables
dynamiquement via ALTER SYSTEM

16 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de données (Data buffer cache)
} Les Buffers Pools multiples (3 pools)
} Les paramètres d’initialisations BUFFER_POOL_KEEP et
BUFFER_POOL_RECYCLE permettent de définir deux buffers pools
supplémentaires. Le premier étant celui par défaut
} La zone définie par BUFFER_POOL_KEEP permet de définir un espace ou
fixer les objets en mémoire
} La zone définie par BUFFER_POOL_RECYCLE permet de définir un
espace ou fixer les objets qui s’y trouvent libérés aussitôt qu’on ne les
utilisent plus

} NOTE: Seule le buffer de données par défaut définit par le

paramètre d’initialisation DB_CACHE_SIZE peut être géré de la
sorte.
17 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de données (Data buffer cache)
} Les buffers de données sont organisés en deux listes :
} La Dirty List
} contient la liste des blocs en modification. La connaissance de cette Liste permet
d’accélérer l’écriture des blocs modifiés dans les fichiers de données
} référence l'ensemble des tampons notés dirty de la liste LRU
} La LRU list
} contient une série d'éléments (tampons) qui sont triés dans un ordre bien précis; des plus
anciennement utilisés (Least Recently Used) aux plus récemment utilisés (Most recently
Used : MRU).
} Les éléments de cette liste (les tampons) peuvent prendre 3 états :
¨ l'état free (libre) : il faut interpréter cela dans le sens où ce tampon n'est pas référencé par la liste
dirty et donc les données contenues ne nécessitent pas d'être mises à jour dans un datafile,
¨ l'état pinned :qui indique que des données de ce tampon sont en cours d'utilisation pour un
traitement quelconque,
¨ l'état dirty : une donnée de ce tampon est plus récente que son homologue sur le datafile requis, en
conséquence de quoi il faudra mettre à jour ce tampon sur le datafile.

18 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
} SGA : Le cache de données (Data buffer cache)

Fonctionnement du cache de données

19 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de données (Data buffer cache)
} les performances sont bonnes si le ratio R est >= 60 ou 70%
Physical read
R= 1 - -------------------------------------
db block gets + consistent gets

} Physical read : nombre de lecture sur disque

} db block gets + consistent gets : nombre total de lecture sur disque ou en
mémoire.
} Exemple : La table v$sysstat contient les statistiques utiles :
SELECT name, value
FROM v$sysstat
WHERE name IN ('db block gets','consistent gets', 'physical reads');

} Résultats : Name Value

db block gets 85792
consistent gets 278888
physical reads 13182
20 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : Le cache de reprise (redo log buffer)
} Stocke la trace des modifications
} le bloc modifié
} l'emplacement de la modification
} la nouvelle valeur
} les 3 constituent une "entrée redo"
} Pas de distinction sur le type du bloc
} bloc d'index, de données, …
} Sa taille est déterminée par le paramètre
} LOG_BUFFER
} Cache circulaire
} capacité infinie !

21 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : La shared Pool (ou Zone de partage des ordres SQL)
} taille en octet définie par le paramètre
SHARED_POOL_SIZE
} Sert pour l’allocation de mémoire des requêtes SQL et
code PL/SQL
} composée de :
} « library cache »
} contient le texte de la requête, le code analysé et un plan d'exécution
déterminé par l'optimiseur
} cache du dictionnaire de données
} pour l'analyse sémantique de la requête

22 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : La shared Pool (ou Zone de partage des ordres SQL)
} Se compose des données suivantes :
} les plans d'exécution et les résultats d'analyse des ordres venant des processus
utilisateurs
} les procédures stockées (PL/SQL)
} les requêtes récursives (requêtes sur le dictionnaire)

} Condition de partage
} le plan d'exécution et les résultats d'analyse sont encore dans le buffer
} les objets composants la requête n'ont pas évolués
} le texte de la requête est identique au caractère prêt y compris le code PL/SQL

} Exemple:
SELECT * FROM DEPT est différent de Select * FROM DEPT
SELECT * FROM . DEPT est différent de SELECT * FROM .. DEPT
} NOTE : le dba peut nettoyer le buffer via la commande Alter System Flush
Shared Pool

23 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : La shared Pool (ou Zone de partage des ordres SQL)

} Informations sur les requêtes

} v$sqlarea (texte des requêtes)
} v$librarycache (tuning de requêtes partagées)
} v$rowcache (tuning du dictionnaire d'Oracle)

24 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
SGA : La shared Pool (ou Zone de partage des ordres SQL)
} Optimisation du cache de la librairie
SELECT sum(pins) "Executions",
sum(reloads) "Défaut de cache",
sum(reloads) / (sum(pins) + sum(reloads))*100 "R"
FROM v$librarycache ;
} reloads : défaut de lecture dans le cache de librairie d'exécutions
} pins : nombre d'exécutions sans défaut de cache
} si R >= 1% alors augmenter SHARED_POOL_SIZE
} Optimisation du cache du dictionnaire
SELECT sum(gets) "DC Gets",
sum(getmisses) "DC cache get Misses",
sum(getmisses) / (sum(gets)+sum(getmisses))*100 "R"
FROM v$rowcache ;
} R doit être <= 10% ou 15% sinon accroitre SHARED_POOL_SIZE
25 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
La PGA

} La PGA (Program Global Area) est une zone de

mémoire privée
} Un PGA est associé à un processus (et inversement).

} Zone mémoire utilisée par un seul processus serveur

} à la différence de la SGA qui est partagée par tous les
processus serveurs

26 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
La PGA
} Ce PGA sert à temporiser les données que manipule
le processus, toujours dans un soucis d'optimisation.
} Buffer contenant des données et des informations de
contrôle pour un process serveur.

} PGA contient :
} une zone de tri
} des informations sur la session
} l'état du curseur
} ….
27 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
La PGA
} Les tables v$sesstat, v$statname, permettent de
déterminer la taille de la PGA pour une session

Select ss.sid, ss.value, sn.name

FROM v$sesstat ss, v$statname sn, v$session se
WHERE ss.statistic#=sn.statistic#
and sn.name in ('session pga memory')
and se.sid=ss.sid and type != 'BACKGROUND';

28 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
La PGA
} La taille maximum de la PGA est influencée en plus par les paramètres
d'initialisations suivants :
} sort_area_size
} hash_area_size
} bitmap_merge_area_size et create_bitmap_area_size
} D’autres paramètres influence aussi la taille de la PGA d’une session
} OPEN_LINKS : nombre de databases link ouverts
} DB_FILES : nombre de fichiers de données pouvant être ouverts
} En mode serveur dédié il est difficile de gérer l’allocation des paramètres
*_area_size.
} Le DBA peut fixer sa PGA maximale grâce au paramètre :
} PGA_AGGREGATE_TARGET

29 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
PGA : la zone de Tri (Sort Area Size)
} Une zone de tri est associée à un Serveur (dédié ou non) pour traiter des ordres
nécessitant des tris (Group by, Order by, Join, ...)
} la taille de la zone de tri est déterminée par le paramètre SORT_AREA_SIZE (en
bytes)
} Par défaut cette taille est de 65000 bytes
} Si cette zone est pleine un Segment temporaire est généré
} SORT_AREA_RETAINED_SIZE (exprimée en byte, 0 min, Sort_area_size par
défaut et max) : espace à ne pas libérer en cas d'écriture dans le segment
temporaire
} tuning de la zone de tri ; table v$sysstat
SELECT name, value FROM v$sysstat
WHERE name in ('sorts (memory)', 'sorts (disk)');
} NOTE : Si le nombre de tris sur disque croit, augmenter Sort_area_size. Mais
attention au Swapping de l'OS.

30 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Les process autour d’Oracle
} Pour que le système puisse fonctionner, il faut que des
processus (des programmes) se chargent de manipuler toutes
ces données (ainsi que celles stockées sur les fichiers).
} Deux classes de process autour d’Oracle
} Les process utilisateurs (liés à l'exécution d'un outil, d'un programme
d'application, ...)
} Les process Oracle
} Process Oracle
} Les process tâches de fond (SMON, PMON, LGWR, DBWR, CKPT, ARC, RECO,
...)
} Les process serveurs
} autres process
} Note : Certains de ces process sont facultatifs (ARC, CKPT)
31 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Les process utilisateurs
} Process client exécutant le code d'une application (PRO*C,
FORMS, ...) ou d’un Outil Oracle (SQL*PLUS, ENTREPRISE
MANAGER, ...)
} Process souvent exécuté sur une machine différente de celle
ou réside le serveur Oracle
} process qui établit une communication avec Oracle via un
protocole de communication et SQLNET
} La communication est gérée via le User Programme Interface
(UPI)

32 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Les process utilisateurs
} Ces processus sont créés lors de toutes connexions de la part
des utilisateurs.

} Attention ces processus ne sont pas obligatoirement sur la

machine locale : ils n'utilisent donc pas directement des
ressources de la machine. (ils n’appartient pas au serveur
Oracle)

33 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Les Processus Serveurs
} Un process serveur peut être dédié ou non
} Il est aussi appelé shadow process
} Son rôle consiste :
} à assurer la communication directe ou indirecte avec les
process utilisateurs
} à analyser et exécuter les requêtes
} à lire les blocs de données dans les fichiers de données
} à restituer directement ou indirectement le résultat au process
utilisateur
} à déplacer les blocs modifiés dans la DIRTY LIST

34 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Instance Oracle : Processus en arrière plan
} 5 principaux processus sont lancés pour une instance donnée
} DBWR (processus d'écriture des blocs de données)
} LGWR (processus d'écriture du fichier de reprise)
} CKPT : point de synchronisation
} SMON (processus System Monitor)
} PMON ( processus Process Monitor)
} D'autres processus sont lancés
} suivant le type de serveur
} serveur dédié/partagé
} suivant le mode d'archivage
} archivelog ou noarchivelog
} Etc.

35 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : DBWR
} (DBWR) Le process DataBase WRiter : c’est processus
d'écriture des blocs de données)
} Ecrit les blocs de données modifiés de la SGA vers les fichiers
de données
} est optimisé pour minimiser les accès disques

} Objectifs :
} Limiter les coûts d'entrées/sorties en "retardant" (de
façon transparente à l'utilisateur) l'écriture des blocs
modifiés

36 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : DBWR
} Quand s’active DBWR ?
} Lors d'un CHECKPOIN T ; point de synchronisation quand LGWR ou
CKPT l'avertit.
} Pour libérer de la place dans le Buffer de données à la demande du
process serveur
} sur un TIMEOUT (toute les 3 s).

} Il peut avoir un ou plusieurs DBW (DBW1…DBWn)

(DB_WRITER_PROCESSES=n allant de 1 à 20)

37 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : LGWR
} (LGWR) Le Process LoG WRiter : C’est le processus
d'écriture du fichier de reprise
} Objectifs
} Enregistrer toutes les modifications apportées aux données afin
d'assurer la reprise après panne
} Trace le contenu du buffer REDO LOG dans les fichiers
REDO LOG
} Contrôle la mise à jour des données des Redo log files à partir du
tampon Redo log contenu dans le SGA.
} En cas de checkpoint (CKPT absent) LGWR réveille DBWR et
modifie l'entête des fichiers de données et de contrôles

38 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : LGWR
} Quand s’active LGWR ?
} Si un COMMIT à été passé ; une transaction est validée
} Sur un timeout toute les 3 secondes
} Si le buffer REDO LOG est plein au 1/3
} Quand DBWR libère des blocs de données du buffer de données (en cas de
TIMEOUT ou de checkpoint)

} Optimisation
} activer le process CHECKPOINT (CKPT)

39 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : CKPT
} (CKPT) Le Process ChecK PoinT : point de synchronisation
} Ce processus est chargé de coordonner la mise à jour des fichiers de
données et de contrôle, ce à partir des informations contenues dans le
SGA.
} Cette mise à jour se fait à des moments précis appelés check points.
} Ce processus est cependant optionnel.
} Dans le cas où il n'existe pas, c'est le processus LGWR qui se charge de réaliser la
sauvegarde.
} Intérêt d’un checkpoint
} Permet de forcer l’écriture dans les fichiers de données des blocs de données restant
en mémoire car fréquemment modifiés (Mécanisme LRU)
} Permet d’accélérer le recouvrement de données : les données avant le checkpoint
dans le fichier Redo log ne seront plus appliquées au fichiers de données car elles y
sont déjà présentes.

40 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : CKPT
} Un CKPT s'obtient en fixant le paramètre : CHECKPOINT_PROCESS=TRUE
} S’il est présent informe DBWR qu'un CHECKPOINT est intervenu
} Note le Checkpoint dans l'entête des fichiers de données et de contrôles
} Un checkpoint intervient :
} Si le TIMEOUT a été atteint (LOG_CHECKPOINT_TIMEOUT : 0 par défaut)

} Si la fin d'un groupe de fichiers Redo log est atteint

} Si une taille correspondant à LOG_CHECKPOINT_INTERVAL (en blocs OS) a
été écrite dans le fichier Redo Log
} Si les commandes suivantes sont passées :
} ALTER SYSTEM CHECKPOINT (pas de changement de REDO LOG)
} ALTER SYSTEM SWITCH LOGFILE

} Optimisation
} Favoriser le recouvrement ou les performances en dimensionnant mieux
LOG_CHECKPOINT_INTERVAL et LOG_CHECKPOINT_TIMEOUT

41 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : SMON
} (SMON) System MONitor : Ce processus, père de tous les
processus de l'instance.
} Il se charge d'optimiser l'utilisation de la mémoire dans le
système.
} Et d'assurer la reprise du système lors de tout démarrage
d'une instance.
} Il s'occupe notamment de plusieurs autres tâches.
} Répare l’instance au démarrage en cas d'arrêt brutal
} Libère les segments temporaires
} Compacte les extensions libres pour les rendre contiguës (Alter Tablespace
nomtablespace Coalesce)
} Recouvre les process suspendus suite à un crash

42 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : PMON
} (PMON) Process MONitor
} Ce processus se charge notamment de libérer toutes les ressources
acquises par un processus client, lorsque celui-ci se termine.
} Il est aussi chargé de surveiller les processus serveurs et les processus
dispatchers :
} si l'un d'eux s'arrêtait anormalement, le PMON se chargerait de libérer les
ressources de ce processus et de le relancer.
} Fait le ménage en cas de disparition brutale d'un process utilisateur.
} Supprime au niveau Oracle les process en erreur
} Annule les transactions en cours
} Libère les verrous
} Et contrôle les process dispatchers et serveurs. S'ils ne sont plus présents, il les
redémarre.

43 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Processus en arrière plan : ARC
} (ARC) ARChiver
} Ce processus sert à effectuer un archivage des fichiers de Redo log :
} En effet, si vous n'avez que deux redo log files (leur taille est fixe) et que le tampon
Redo log est plein, un des deux fichiers doit être écrasé pour contenir les nouvelles
données.
} Ce processus, s'il est activé, permet de palier ce problème. En effet il archivera
(sauvegaerde) l'ancien redolog file.
} Pour que le processus existe, l'instance doit être en ARCHIVELOG
mode.
} C-à-d la base doit être démarrée en mode avec Archive.
} C'est un process facultatif. Jusqu’à 10 process ARCn peuvent être activés.
} Le paramètre log_archive_max_processes permet de fixer le nombre
maximum.
} Il est conseillé de garder la valeur par défaut car Oracle alloue lui-même de nouveaux
processus en cas de besoin.
44 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Base de Données Oracle
} désignée par un nom (DB_NAME), souvent pris identique
à celui de l'instance correspondante.
} représente les structures physiques des données

} la BD est divisée en plusieurs sous unités.

} Certaines sont physiques (ont une réelle existence tel un
datafile),
} d'autres sont dites logiques dans le sens ou leur existence est
essentiellement liée à des conventions.

45 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Base de Données Oracle

} Se compose de fichiers du système d 'exploitation

} Elle est décrite par :
} Structure logique
} Structure physique

46 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
BD : Structure logique
} Il existe plusieurs niveaux de structures logiques allant du
schema object (la structure la plus importante) au datablock (la plus
petite structure, indépendamment des données, sur laquelle on puisse apposer un
contrôle). Et qui sont :
} Les schema objects
} Les tablespaces
} Les tables
} Les segments
} Les extents
} Les blocks

Note : Voir en détail partie du cours : "Structure Logique d'une Base de

Données Oracle"

47 SAGAR Samya
 Architecture d’Oracle
2. Serveur Oracle
BD : Structure logique
} Place des différentes unités logiques existantes, les
unes en rapport aux autres.

Table Table
Block

Extent Table
Table
Segment Tablespace Tablespace Tablespace

48 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Schema object
} Par Schema objet on entend un moyen d'accès à la BD.
} On y trouve
} les tables,
} les vues,
} les index,
} les clusters,
} les liens,
} les synonymes,
} les procédures PL/SQL
} et les packages PL/SQL.
} L'ensemble de tous les schema objects pour un utilisateur est
appelé user's schema.
49 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les schema objects
} Les tables : permettent directement d'accéder aux données
} Les vues : permettent de donner accès
} à un sous-ensemble d'une table (par exemple, car on peut créer des vues
sur n'importe quel schema object : pourquoi pas une vue sur une vue)
} ou de plusieurs tables (jointes)
} ces vues peuvent être utilisées pour cloisonner le champ d'action d'un
utilisateur (au lieu de lui donner accès à une table complète, on ne lui
accorde que le sous-ensemble requis).
} Les index : un index, similairement à l'index d'un ouvrage,
permet à une instance du serveur d'accéder plus rapidement à
des éléments.

50 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les schema objects
} Les clusters : permettent aussi un accès plus rapide aux données.
L'astuce consiste à supprimer des données doubles et donc à avoir
moins de données à charger à partir des disques.
} Les liens : permettent d'accéder des données sur une DB distante.
} Les synonymes : ils consistent en un nom de remplacement sur un
autre schema object.
} Les procédures et les packages :
} une procédure est un ensemble d'ordres PL/SQL permettant de réaliser
une action sur des données.
} Un package est un ensemble de procédures.
} Pour qu'elles puissent être utilisées, ces unités de stockage ont besoin
d'être stockées sur la BD et comme elles permettent la manipulation
des données, ce sont des schema objects.
51 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les tablespaces
} Cette unité logique rentre dans la constitution de la BD.
} Une BD est constituée d'au moins un tablespace nommé
SYSTEM.
} Celui-ci contient le data dictionnary (dictionnaire de données
(qui contient des informations relatives au système Oracle).
} Quand vous allez créer une nouvelle table, celle-ci sera
contenue soit dans un tablespace existant soit dans un
nouveau que vous créerez.

52 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les tables

} La table est l'élément constitutif d'un tablespace.

} La table est constituée de segments.

53 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les segments
} Un segment est constitué d'extents et rentre dans la
constitution de la table.
} Une table est constituée d'au moins deux segments :
} les data segments
} et le rollback segment.
} Deux autres segments peuvent apparaître dans une table :
} l'index segment
} et le temporary segment.

54 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les segments
} Le data segment : rentre dans la constitution de la
table, sert à stoker toutes les données (les valeurs des
différentes lignes) que contient la table.
} Le rollback segement : ce segment stocke des données
relatives aux transactions.
} Si une transaction ne peut aboutir, la transaction doit être
annulée par la commande ROLLBACK. Dans ce cas, on doit
être capable de restituer la base dans l'état initiale ou elle était
(au départ de la transaction en cours).

55 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les segments
} L'index segment : ce segment optionnel sert à stocker
les informations relatives aux index crées sur la table.
} les index servent notamment a optimiser les temps d'accès aux
données.
} Le temporary segment : utilisé pour stocker les
résultats temporaires d'une requête PL/SQL ne pouvant
directement d'exécuter en mémoire.
} Pour ce faire un segment est alloué pour les traitements
intermédiaires puis d’ésalloué directement à la fin de la
transaction (d'ou son nom).

56 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les extents
} L'extent est un ensemble de blocks consécutifs, et rentre dans
la constitution du segment.
} Autrement dit, un segment est constitué de plusieurs extents.
} Tout comme il existe différents types de segments, il existe
différents types d'extents.
} L'allocation des extents, constituant le segment, est dynamique.
} C'est-à-dire que lorsque qu'un extent, contenant par exemple des
données, est plein, et que des nouvelles données doivent être
ajoutées, un nouvel extent est alloué et ce, s'il y a suffisamment de
place sur le tablespece courant.
} La taille du nouvel extent doit au moins être de la même taille que
l'extent précédent.
57 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les blocks
} Le block est la plus petite unité logique de stockage que peut
manipuler le système.
} Tout les blocs constituant la BD ont tous la même taille.
} Cette taille peut soit être celle par défaut (fixée par le
SGBD), soit être fixée par l'administrateur de la base. Dans
ce dernier cas, le paramètre DB_BLOCK_SIZE du fichier
d'initialisation doit contenir cette valeur (utilisation du
fichier d'initialisation).

58 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure logique : Les blocks
} Un bloc est principalement divisé en trois sous-parties :
} la première contient des informations sur le bloc : c'est le
header. Il indique par exemple à quel type de segment il
appartient, la table et la ligne, ...
} La seconde est une zone vide pouvant être utilisée pour
ajouter de nouvelles données
} La troisième contient les données sur les lignes de la table à
laquelle le block appartient.
} Note : La zone vide est très importante, en contrôlant la taille
de cette dernière, on peut optimiser ou non les temps d'accès
à la BD.

59 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
BD : Structure physique
} Ont distincte :
} fichiers de données ou Data file (>=2)
} fichiers de reprise ou de journalisation ou encore Redo log
(>=2)
} fichiers de contrôle ou Control file(>=1)
} fichier de paramètres
} fichier mot de passe
} fichiers de reprise archivés

Note : Voir en détail partie du cours : "Structure Physique d'une Base

de Données Oracle"

60 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : datafile
} Ces fichiers contiennent l'ensemble des données constituant la BD.
} Autrement dit l'ensemble des données accessibles par les schémas objets.
} Pour faire le lien avec les structures logiques,
} nous pouvons dire qu'un tablespace doit l'ensemble de ses informations
stockées dans un ou plusieurs datafiles.
} Plus précisément, un schéma objet peut être stocké dans un ou plusieurs
datafiles.
} Il est possible de dupliquer une même données dans plusieurs datafiles, ce
pour des raisons de sécurité.
} Si c'est le cas, alors les différents datafiles "clones" devrons être
dispersés sur des disques physiquement séparés (pas des partitions sur
un même disque), sans quoi, cela ne servirait à rien : si le disque se crash,
les deux copies seraient de toute façon détruites.

61 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : datafile
} Exemple :
SQL> select * from V$DBFILE;

FILE#
---------
NAME
--------------------------------------------------
4
C:\ORACLEXE\ORADATA\XE\USERS.DBF
3
C:\ORACLEXE\ORADATA\XE\SYSAUX.DBF
2
C:\ORACLEXE\ORADATA\XE\UNDO.DBF

FILE#
---------
NAME
--------------------------------------------------
1
C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF

SQL>

62 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : Redo log file
} Ce type de fichiers contient l'ensemble des
changements effectués sur la DB
} l'ensembles des transactions sur la BD.

} L'utilité de tels fichiers est de pouvoir reconstruire au

mieux la base, si une panne apparaît :
} en effet dans ce cas, le serveur s'arrêterait sans avoir sauvegardé
l'ensemble des transactions non validées (par un COMMIT) présentes
en mémoire.
} Ces fichiers permettraient alors de reconstituer (de façon consistante)
au mieux la BD.

63 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : Redo log file
} Exemple :
SQL> select * from V$LOGFILE;
GROUP# STATUS TYPE
--------- ------- -------
MEMBER
------------------------------------------

IS_
-------

2 STALE ONLINE
C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\01_MF_2_1XHPQXCQ_.LOG
YES

1 ONLINE
C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\01_MF_1_1XHPQVNZ_.LOG
YES

GROUP# STATUS TYPE

--------- ------- -------
MEMBER
------------------------------------------

IS_
-------

SQL>

64 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : Control files

} Ces fichiers permettent à une instance de serveur d'utiliser les

fichiers précédemment cités :
} en effet, ils stockent les emplacements physiques des fichiers, leur
nature, ...

} Ce n'est pas à vous de contrôler le contenu de ces fichiers. Le

serveur se charge de le faire de manière automatique.

65 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
Structure physique : Redo log file
} Exemple :

SQL> select * from V$CONTROLFILE;

STATUS
-------
NAME
------------------------------------------
IS_ BLOCK_SIZE FILE_SIZE_BLKS
--- ----------- ---------------
C:\ORACLEXE\ORADATA\XE\CONTROL.DBF
NO 16384 430

SQL>

66 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
BD : Le data dictionary
} Ce dictionnaire est un ensemble de tables et de vues
contenant des informations sur la BD.
} En effet, comment se pourrait-il qu'un administrateur puisse
se connecter à la base pour créer la première BD, s'il n'y avait
déjà des informations stockées quelque part ?
} La BD stocke toutes données sous forme de tables. Ce
dictionnaire est généré lors de la création de la BD.
} Ce dictionnaire contient par exemple :
} des informations sur les utilisateurs,
} sur les privilèges qu'ont ces utilisateurs,
} sur les schema objects définis sur la BD,
} ...
67 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
BD : Le data dictionary
} Vous ne pouvez en aucun cas modifier ce dictionnaire.
} Les données qui y sont stockées sont automatiquement mises
à jour lors de l'utilisation de commandes DDL(data defintion
language) sql.
} Si vous créez une nouvelle table, les données seront
automatiquement mises à jour dans la BD.
} On ne peut donc qu'accéder le dictionnaire que pour des
consultations (SELECT).
} Afin d'en simplifier cette consultation, des vues sont définies
sur les tables du dictionnaire.
} Il est déconseillé d'accéder ce dictionnaire directement par les
tables.
68 SAGAR Samya
Architecture d’Oracle
2. Serveur Oracle
BD : Le data dictionary
} Voici quelques exemples de requêtes que l'on peut être amené à réaliser.
} Demande l'ensemble des liens utilisables sur la BD.
SELECT * FROM all_db_links;
} Demande tous les datafiles de la BD.
SELECT * FROM V$DBFILE;
} Demande l'ensemble des processus dispatchers.
SELECT * FROM V$DISPATCHER;
} Encore quelques vues.
V$LOGFILE V$CONTROLFILE V$QUEUE ...
} Si vous désirez avoir une vue exhaustive de tous les éléments contenus
dans ce data dictionary, il vous est possible de lancer le programme
Schema manager (BDA). Celui ci donne accès aux éléments de ce
dictionnaire.
69 SAGAR Samya
Architecture d’Oracle
3. Traitement d'une requête d'interrogation (SELECT)
} Le processus client envoie la requête au processus
serveur
} Utilisation d’un PGA
} Le processus serveur effectue l'analyse syntaxique et
sémantique de la requête
} utilise la shared pool de la SGA pour compiler l'ordre
} retourne l'état (analyse correcte ou incorrecte) au processus client.
} Exécution de la requête
} Récupération des résultats
} le processus serveur envoie les lignes extraites par la requête (à partir
du cache de données si les données y ont déjà été chargées)

70 SAGAR Samya
 Architecture d’Oracle
3. Traitement d'une requête d'interrogation (SELECT)

un RBS (Rollback Un SELECT en cours peut-

Segment) contient t - il accéder à des données
l’état avant des validées (COMMIT) par
transactions en une autre transaction ?
cours

71 SAGAR Samya
Architecture d’Oracle
4. Traitement d'un ordre de mise à jour (DML)
} Similaire à une requête d'interrogation pour la phase d'analyse

} Phase d'exécution différente :

1. } le processus serveur lit des blocs de données et de rollback à partir
} des fichiers de données
} du buffer cache de données
} Si des blocs ne sont pas déjà dans le cache, copie des blocs du disque dans le cache

2. Mise à jour de verrou sur les données

3. 4. et 5.
} Enregistrement des modifications
} à apporter au rollback (image avant)
} et aux données (nouvelles valeurs) dans le cache de reprise(redo log)
} Mêmes opérations dans le cache de données
} Ces blocs sont marqués comme modifiés (différents des blocs stockés sur disque)

72 SAGAR Samya
Architecture d’Oracle
4. Traitement d'un ordre de mise à jour (DML)
Rappel : Rollback Segment
} Permet la gestion des transactions
} COMMIT : valide un ensemble de MAJ
} ROLLBACK : annule un ensemble de MAJ
} Avant d'effectuer une modification des données, le processus
serveur enregistre l'ancienne valeur dans un rollback segment

} Intérêts :
} si la transaction échoue, les modifications "déjà faites" sont annulées
} Assure une lecture cohérente des données par les autres transactions
} en cas de panne, les données sont restaurées dans un état cohérent.

73 SAGAR Samya
Architecture d’Oracle
4. Traitement d'un ordre de mise à jour (DML)

74 SAGAR Samya
Architecture d’Oracle
5. Traitement des validations et Invalidation
} SCN pour System Change Number
} à chaque transaction validée -> 1 identifiant de modification
SCN
} sorte d'horodateur interne
} permet de vérifier la cohérence indépendamment de la date/heure du
SE
} Lorsqu'un ordre COMMIT est effectué:
1. Le processus serveur enregistre dans le cache de reprise 1
SCN
2. LGWR effectue une lecture contiguë de tout le cache de
reprise (SCN inclu) dans les fichiers de reprise
3. L'utilisateur reçoit "commit complete"
4. Le processus serveur libère les verrous
75 SAGAR Samya
Architecture d’Oracle
5. Traitement des validations et Invalidation
} Validation COMMIT

76 SAGAR Samya
Architecture d’Oracle
5. Traitement des validations et Invalidation
} Validation ROLLBACK

L’espace alloué dans le ROLLBACK SEGMENT est -t- il

désalloué immédiatement ?

77 SAGAR Samya
Architecture d’Oracle
5. Traitement des validations et Invalidation
Mise à jour et validation
} Mise à jour
} Transaction associée à un segment d’annulation
} Verrou exclusif placé sur les n-uplets concernés
} Données initiales enregistrées dans le segment d’annulation
} Données modifiées enregistrées dans le cache de journalisation
} Validation
} Écriture du cache de journalisation dans la base de données
} Nettoyage du segment d’annulation

78 SAGAR Samya