0% ont trouvé ce document utile (0 vote)

7 vues61 pages

Architecture des SGBD et modèles de données

Transféré par

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

0% ont trouvé ce document utile (0 vote)

7 vues61 pages

Architecture des SGBD et modèles de données

Transféré par

Daouda Gueye

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

2004-04-05

Chapitre 2
Architecture fonctionnelle du logiciel SGBD

2.1 Système de gestion de base de données

Un système SGBD est un logiciel capable de gérer adéquatement au moins un modèle de
données et de faire des mises à jour, des suppressions et des ajouts dans une base de données. Il
assure aussi la persistance des données pour les applications. Il est un composant essentiel dans
lʹarchitecture plus générale que sous-tend un Système à Base de Données (SBD).

SBD = (n x BD = (données + dictionnaire)) + SGBD avec n >= 1

La complexité du SGBD dépend des fonctionnalités implémentées dans lʹenvironnement

informatique. Le Système de Gestion de Base de Données (SGBD) peut être exploité dans
lʹenvironnement de la micro ou de l’informatique des grands systèmes avec une architecture
centralisée, Client/Serveur ou répartie. Quelle que soit l’approche le moteur SGBD joue un rôle
central dont l’essentiel est presque toujours le même.
Modèle de données
C’est un outil externe de représentation des données à caractère générique, c’est-à-dire qui ne
retient que l’essentiel dans la spécification des données et cela, au moyen des éléments de
modélisation suivants :
a) Types de données b) Associations
c) Contraintes syntaxiques et sémantiques d) Méthodes des classes

Le modèle de données est exploité par un jeu d’opérateurs primitifs capables de réaliser les
manipulations sur les données conformément aux contraintes et aux possibilités imposées par la
structure du modèle. Il est très souvent représenté par un graphe connexe, cʹest-à-dire dont les
éléments sont tous reliés.
Modèles conceptuels de données
Plusieurs modèles (1) sont proposés pour lʹorganisation et la représentation générique des
données. Seuls quelques-uns marqués par un astérisque s’imposent dans la pratique :

a) Modèle E/R* d) Modèle à objets*

b) Modèle relationnel* e) Modèle sémantique et fonctionnel
c) Modèle relationnel-objet* f) Modèle logique ou déductif

Avec le développement des systèmes hypertextes, de nouveaux modèles de données intègrent

non seulement les données, le son et les images, mais aussi les mécanismes de navigation
possibles prévus pour une application(2), (3). Par exemple, le modèle RMDM2 propose une
démarche intégrée pour le développement des applications hypertextes: lʹanalyse de besoins
concernant les données et la navigation, la modélisation des classes, des facettes et des chemins
de navigation, la conception des interfaces, la traduction du modèle RMDM vers le modèle

Source : [Link]
© André Gamache
Chapitre 2 Architecture fonctionnelle du SGBD

dʹimplantation et finalement, lʹévaluation de lʹapplication hypertexte. La modélisation des bases

de hypertextes fait lʹobjet de plusieurs travaux articulés autour des systèmes DEXTER(4), HB(5)
et TREILLIS(6).
Schéma de la base de données
Le schéma de la base de données est la description complète du modèle logique de données au
moyen d’un langage spécialisé de définition, appelé le DDL (Data Definition Language). Cette
description change relativement peu en cours d’exploitation de la BD. La problématique de la
répartition des données pourrait entraîner des modifications de l’emplacement des données,
mais pas nécessairement des changements au modèle conceptuel. Dans le contexte du
relationnel, le schéma de la base de données est lʹensemble du schéma de chaque table
relationnelle.
Instance de la base de données
L’instance de la base de données est lʹensemble de données stockées dans la base au moment t.
Plusieurs auteurs décrivent maintenant les données comme des objets. Lʹinstance de la base de
données devient alors un ensemble dʹobjets. Ils supposent que chaque donnée est atomique et
qu’elle est associée à un ensemble de méthodes ou de procédures communes pour la recherche,
la mise à jour et la suppression. Ces méthodes sont en quelque sorte factorisées au niveau de la
classe pour être concrètement implémentées par des fonctions.

Création du schéma logique

2 1 4

Création des Création des

schémas internes schémas
Dictionnaire
(physiques) externes
3 5

Transformation des clauses d’accès 7 Transformation des clauses d’accès

conceptuels en accès internes externe vers le conceptuel

9
6

Transformation des clauses d’accès

Application
externe vers le conceptuel

BD
Figure 2.1
Architecture ANSI/SPARC

On peut voir les données dʹun point de vue différent selon que lʹon est DBA ou développeur.
Cette vision à trois niveaux favorise une meilleure séparation entre les applications et la
structure physique des données de la base. Lʹarchitecture ANSI/SPARC propose trois niveaux
de modélisation des données :
a) Niveau conceptuel : Description logique de toutes les données selon la réalité perçue par le
concepteur.
b) Niveau externe : Description des données utilisées par une application selon les
caractéristiques imposées par les traitements de chaque application. Il correspond aux vues.
c) Niveau interne : Description des structures physiques nécessaires ou disponibles pour la
représentation des données sur un ou plusieurs disques.
La figure 2.1 illustre le rôle de chaque processeur de schéma et illustre les différentes étapes
dans la transformation des ordres du DML.
Indépendance logique
L’indépendance logique est la possibilité de modifier le schéma conceptuel en perturbant le
moins possible le fonctionnement des applications, c’est-à-dire la vue (ou modèle externe) ou en
d’autres mots, les éléments du modèle utilisés par une application. En cours d’exploitation, elle
favorise la productivité et une continuité des opérations.
Indépendance physique
L’indépendance physique est la possibilité de modifier le schéma interne des données sans
modifier le schéma conceptuel. Par exemple, le gestionnaire de la base de données peut modifier
l’emplacement des données sur les disques ou définir des structures de données plus adéquates
pour les accès à la base de données sans perturber le fonctionnement des applications.
Langage de données
Les niveaux du langage de données correspondent à ceux du modèle exploité, à savoir le
conceptuel, lʹexterne ou lʹinterne. La tendance actuelle est de spécifier ces trois niveaux avec le
même langage de données dont certains ordres sont particuliers à chaque niveau. Les quatre
facettes courantes sont les suivantes :
a) DDL (Data Definition Language ou Langage de Définition de Données): spécification du
schéma conceptuel (MCD) et des vues.
b) VDL (View Definition Language): pour définir les vues ou le modèle externe (similaire au DDL
du modèle conceptuel avec quelques restrictions).
c) SDL (Storage Definition Language): pour spécifier les détails de stockage physique.
d) DML (Data Manipulation Language ou Langage de Manipulation des Données): pour mettre à
jour et supprimer les données de la base en fonction des structures définies au préalable par
le langage de définition de données.
Caractéristiques des langages de données
Chaque SGBD peut avoir son langage de données qui lui est propre et même cohabiter avec un
autre plus universel. Les fonctionnalités d’un langage de données sont caractérisées ainsi :

1. Déclaratoire, c’est-à-dire une requête qui formule quoi rechercher dans la base.
2. Procédural, c’est-à-dire qui formule comment rechercher les données dans la BD.

3. Intégré dans un langage hôte : insertion du DML dans une application L3G.
4. Langage de requête : limité souvent à la recherche.
5. Convivial : les interfaces conviviales du langage facilitent la construction des requêtes par
lʹentremise des interfaces graphiques (GUI).
Manipulations des données
Les ordres DML pour l’insertion, la modification et la suppression des données sont disponibles
dans tous les systèmes avec une syntaxe qui n’est pas normalisée. Il en résulte souvent des
formes de DML différentes d’un SGBD à l’autre.

Ajout : INSERT INTO ADD TO STORE

Suppression : DELETE FROM DROP, ERASE,
Mise à jour : UPDATE, CHANGE MODIFY

La recherche est formulée par un langage de requête propre au SGBD ou de type SQL.
Exemples de requêtes formulées dans divers langages:
Voici comment peut être formulée dans différents langages, une requête pour trouver les
matricules des employés dont le nom contient les lettres ‘tson’.
Recherche :
a) Oracle : SQL
SELECT nom FROM Employe
WHERE nom LIKE '%tion%';

b) INTERBASE : requête en gdml

PRINT nom OF Employe
WITH nom matching '*tion*';

c) Vax/DBMS : requête pour le modèle de données réseau

FIND ANY Employe WHERE nom .CONTAINS. '*tion*'
PRINT [Link]
Langage de définition des données (DDL)
Le langage DDL permet de décrire le schéma conceptuel (et souvent le schéma externe) de la
base de données. Le schéma est préparé avec un éditeur sous forme d’un fichier de texte qui est
par la suite traduit par un compilateur propre à chaque SGBD. Ou encore, il est sous la forme de
commandes interactives, lesquelles sont lʹobjet dʹune interprétation et dʹune exécution en ligne.
Dictionnaire
Le dictionnaire des métadonnées (data dictionary) est le dépôt de toutes les informations
concernant la base de données incluant des procédures et des déclencheurs (triggers) définis sur
la base. Le dictionnaire est dit passif lorsquʹil est en différé relativement aux opérations sur la
base. Il sert davantage pour les phases d’analyse et permet de renforcer lʹuniformisation des
libellés et de la sémantique des données lors dʹune ré ingénierie des processus. Le dictionnaire
actif est, de par sa fonction, essentiel au fonctionnement du SGBD; il est en ligne avec le noyau
du logiciel. L’ensemble des dictionnaires d’une organisation est désigné maintenant comme une
encyclopédie des données, un concept sous-tendu par le Data Warehousing.

Évolution des modèles et des langages de définition

Le dictionnaire de métadonnées est souvent différent d’un système à l’autre. Avec les diverses
générations des SGBD, la séparation entre la définition logique et la spécification physique est
plus marquée et le langage de définition des modèles plus riche dans sa capacité à capturer la
sémantique des données. Cette évolution a marqué sensiblement les caractéristiques des
premiers systèmes SGBD. Dans les exemples suivants, cette évolution au niveau du schéma
graphique est illustrée à lʹaide dʹun fragment de MCD spécifié au moyen des premiers DDL de
quelques SGBD, dont certains ne sont plus des logiciels vedettes, mais ils sont encore
opérationnels.
Schéma source d’une base de données de commandes (SGBD IDMS)
Voici un fragment du schéma source de la figure 2.3 qui est une partie dʹun modèle réseau
spécifié avec IDMS (version 1980). Les liens sont de type 0-n et sont représentés par la notion de
set.

Commande
noCommande*
montant
dateCommande
Aera: region-commande
Commande-Article

LigneArticle
noArticle
qte: (comp)
qteCom;
qteLiv
prix
remarques (mv)

Figure 2.3
record name is LIGNE-ARTICLE
record id is 621
location mode is via commandeArticle set
within regionCommande area
03 noArticle pic x(8),
03 qte
05 qteCom pic 9(7),
05 qteLiv pic 9(7),
03 prix pic 9(4).
03 remarques occurs 0 to 10 times
depending on nb-rem.

Après la compilation, le schéma transformé est rangé dans le dictionnaire. Ce schéma exécutable
contient certaines informations, non pertinentes au niveau conceptuel, lesquelles concernent
l’identification des enregistrements (records), le placement des données et leur mode d’accès.

Schéma TOTAL : base de données sur les Ressources humaines

Ce schéma TOTAL (version1978) illustré ci-dessous comporte peu d’indépendance logique et

physique en raison de son architecture à un seul niveau, intégrant le conceptuel, le logique et le
physique.

Ce schéma confond dans son langage les trois niveaux en incluant les informations descriptives
du niveau physique avec celles du niveau conceptuel. De plus, l’obligation inutile de fournir la
longueur des champs alourdit les modifications subséquentes au schéma du modèle.

Employe
nom *
adresse
telephone

Departement
Fichier-maître
no-dep*
site

Figure 2.4
.
begin-data-base-generation emplnom = 30
data-base-name= PERSONNEL empltel =10
share-io empladr = 50
ioarea = mas1 end-data
ioarea = mas2 drive = 12, 48, mt32
... total-logical-records = 200
end-io logical record-length = 104
begin-master-data-set logical-records-per-block = 9
data-set-name = Dep end-master-data-set
... ...
data-set-name = empl end-variable-entry-data-set
ioarea = mas1 end-data-base-generation
master-data
emplroot = 8 --8 octets
emplctrl = 6

Dans ce schema, il faut noter la présence de la notion de fichier

indexé qui implémente le fichier-maître Dep (master-data-set).
Schéma ADABAS (version 1983) de la base de données dʹune société de distribution
--- Schéma ADABAS (version 1983) ----
clients (001)
01, nc, 5,u,DE -- u indique attribut numérique
01, nm, 15, a,DE -- a un attribut alphabétique
01, pc, 15, a -- DE indique un attribut indexé
01, ac nu -- supprime des blancs dans un champ alpha
02, no,4,u
02, ru,15,a 01, np, 4, u, DE
02, vi, 15,a,de 01, qp, 5, u

02, te, 7, u 01, al

01, es, 3, a, nu 02, ci. 4, u
02, ru, 15,a
commandes (002) produits (003)
01, nc, 7, u, de 01, np,6,u
...

Clients
Produits 001
003
n n
n
1 m

Entrepots Commandes
04 002

n 1 n

n 1 1

ComEntrepot Vendeurs
006 006

Figure 2.5

Cette partie de schéma ADABAS des années 80 est un exemple de langage de description peu
significatif pour les développeurs d’applications. Néanmoins, ce logiciel a l’avantage de gérer
une base de données avec des structures de données directement adaptées aux liens complexes
(n-m) réciproques sans la création de classes logiques supplémentaires. Ce lien complexe est créé
au besoin par une table de couplage (Table Coupling) implémentée par une structure de données
inversée. Cette caractéristique en faisait un logiciel fort adapté aux modèles conceptuels,
puisque le passage au modèle logique demandait moins de transformations.
Modèle de Vax/DBMS
Le schéma d’une base de données réseau gérée par ce système se rapproche de celui
recommandé par CODASYL. Les informations ayant trait au niveau conceptuel sont séparées du
niveau physique voire même de celles régissant les accès aux données (7). Ce système gère les
modèles conceptuel, externe, interne et de sécurité.

Schéma DDL/ Vax DBMS

*Scénario 2 - Base de données académique
schéma name is BD_SC2
*Description de l'entité FACULTE
record name is FACULTE within FAC_DEPT
item CODE_FAC type signed longword
item NOM_FAC type character 30
*Description de l'entité DEPARTEMENT
record name is DEPARTEMENT within FAC_DEPT
item CODE_DEPT type signed longword

item NOM_DEPT type character 30

* Description de l'entité PROFESSEUR
record name is PROFESSEUR within DEPT
item N_A_S_PROF type signed longword
item NOM_PROF type character 20
item PRENOM_PROF type character 20
item ADRESSE_PROF type character 15 occurs 3 times
item DATE_NAIS_PROF type character 10
item TITRE type character 20
item SALAIRE type signed longword check is SALAIRE gt 0
... * Description du groupement INSCRIT
set name is INSCRIT
owner is DEPARTEMENT
member is ETUDIANT
set selection is current of set
insertion is manual
retention is optional
order is sorted by
ascending MATRICULE
duplicates are not allowed
. . .

Faculte
code_fac
nom fac
Compose_de

Departement
code_dep
nom fac
Emploie Inscrit Dispense

Professeur Etudiant Cours

nas_prof matricule titre_cours
prenom_prof nom_etud nb_credit
adresse_prof prenom_etud
titre adresse_etud
salaire adress_perm
data_nais_prof date_nais_etud
date_inscr

Modèle conceptuel réseau DBMS

Figure 2.6
Le langage de schéma de ce SGBD est plus riche en types de données que les précédents, ce qui
permet de représenter quelques types complexes comme les groupes et les vecteurs. En outre, la

description demeure au niveau logique des données et ne fait aucune référence aux aspects
physiques. Ces derniers font l’objet d’un schéma interne complètement séparé.
Environnement de traitement centralisé
Cet environnement, fort populaire avant l’avènement des réseaux et encore très utilisé dans les
grandes organisations, est articulé autour d’une seule machine dite centrale, puissante et
partagée avec plusieurs autres logiciels étrangers à la base de données. De plus, cet ordinateur
gère souvent un grand nombre de terminaux au moyen dʹun logiciel de communication de type
moniteur de transactions (TP pour Transaction Processing monitor). Ce dernier permet de fournir
et de recevoir des données en transit vers une application particulière qui tourne sur la machine
centrale. Dans le cas le plus simple, le SGBD ne répond quʹà une seule requête à la fois (single
thread). Les requêtes simultanées qui proviennent de différentes applications sont mises alors en
file dʹattente par le moniteur de transactions. Dans le cas d’une configuration dite
d’entrelacement d’exécution (multithreading), plusieurs requêtes en provenance d’autant
d’applications (terminaux) peuvent être traitées en concurrence. Un tel service exige un OS
multitâche et une gestion fine du partage des données.
Multithreading avec un processeur de transactions sur machine centrale
Chaque écran transmet les données nécessaires pour effectuer une transaction (en mode
autonome) au processeur de transactions (PT) qui les gère en tenant compte des priorités
respectives. Le module de traitement des transactions crée un processus pour chaque requête.
Ce nouveau processus concurrence les autres processus actifs pour les accès à la BD. Le système
de répartition de l’OS se charge de gérer les différentes tâches associées à l’application pour
réaliser ainsi l’entrelacement des traitements. Lorsquʹune tâche fait, par exemple, une lecture sur
disque pour une application, une autre tâche peut alors prendre le contrôle du processeur et
poursuivre son exécution. Pour une meilleure performance, le processus du moniteur TP de la
figure 2.7a une très grande priorité pour l’OS de manière à obtenir fréquemment le contrôle du
CPU. Deux cas sont possibles :

Cas 1 : exécution séquentielle (single-thread)

Un seul DML d’une application est exécuté à la fois (pas de concurrence entre les applications).
Cʹest une approche non performante, maintenant caduque.
file des requêtes

Moniteur Ecran 8
Ecran 1
TP

Application-1
Une seule transaction traitée à BD
la fois et entièrement par SGBD
l’application.

Figure 2.7

Le processeur transactionnel de transactions (TP) couplé au moteur SGBD améliore quelque peu
le traitement en partageant le même moteur SGBD avec les terminaux actifs.
Cas 2 : interclassement des transactions en provenance de plusieurs terminaux pour le
traitement de données (multithreading). Ces transactions sont exécutées en concurrence et gérées
par le répartiteur du système dʹexploitation (OS) tel que cela est illustré à la figure 2.8. Chaque
transaction est exécutée par un processus dupliqué pour exécuter le code correspondant à
l’application. Il y a aura donc autant de processus concurrents que d’écrans actifs.

Cette récupération des cycles du CPU par les processus chargés de traiter un ordre DML sera
aussi nécessaire dans une architecture client/serveur où le nombre de processus est susceptible
d’être encore plus important. De plus, chaque application sʹexécute sur la station-client et, seul
lʹordre DML est transmis au serveur. Il est donc capital d’avoir un système d’exploitation
multitâche performant pour la gestion du serveur de bases de données avec une machine
capable de répondre à la charge créée par les clients.

Transaction :
ecran-1 no-transaction id-application valeur-1 valeur-2 valeur-3

Les système OS/2, Unix et Windows NT sont les plus utilisés sur les plates-formes micro, tandis
que les systèmes propriétaires IBM-MVS, IBM-AIX, Sun-Solaris et Sun-OS dominent le matériel
de niveau station de travail ou celui des ordinateurs centraux.

station 1 Moniteur
de TP station 4

Table des
proc-3
applications
proc-2
proc-1
proc-1
proc-3 proc-2

SGBD

Entrelacement dʹexécution (Multithreading)

Figure 2.8
Les environnements client-serveur et les architectures fédérées ne changent pas
fondamentalement le fonctionnement général du moteur SGBD, mais le situent dans un contexte
opérationnel plus diversifié qui permet notamment une meilleure performance et des ressources
matérielles plus adaptées à lʹenvironnement de traitement (scalability). Il faudra une architecture

parallèle pour escompter encore des gains de performance. Toutefois, l’approche client-serveur
est bien adaptée à l’exploitation par réseau. Dans un tel cadre, les applications sont développées
au niveau de chaque station en utilisant les ressources logicielles disponibles localement. L’accès
à la base de données se fait par lʹentremise dʹun ou de plusieurs réseaux hétérogènes qui
véhiculent chaque requête au serveur lequel agit comme une ressource centrale. Plusieurs
auteurs préconisent l’approche fédérée dans l’exploitation des données. Cette approche met
aussi en oeuvre l’architecture client-serveur mais en y ajoutant la possibilité de répartir la base
de données sur plusieurs serveurs hétérogènes. Bien sûr, une telle base de données doit être
gérée de façon à maintenir la cohérence, l’intégrité et la transparence des données quel que soit
le site d’émission de la requête.
Modèle fonctionnel du logiciel
Nous reprendrons le modèle fonctionnel présenté schématiquement au chapitre 1. On peut
décrire un logiciel SGBD sous un angle fonctionnel, car les aspects d’implémentation varient
largement selon la plate-forme, voire même d’une version à lʹautre du même logiciel. En outre,
le développement de nouveaux systèmes d’exploitation offrira sans doute des moyens
d’implantation encore plus puissants. Cette description schématique comprendra :
a) Les fonctions présentes dans un SGBD;
b) La coopération entre les fonctions internes du système pour la gestion efficace et cohérente
des données.
2. 2 Architecture générale dʹun SGBD
Voici l’architecture fonctionnelle vue auparavant :

Analyse syntaxique
Analyseur
Analyse sémantique

Traduction Génération du plan dʹexécution

Métabase Contrôle dʹintégrité
Contrôle des autorisations

Optimisation Modification du plan dʹexécution

selon les coûts et les règles

Sous-système
dʹaffichage Calcul Contrôle de la concurrence
Atomicité de la transaction
Exécution des opérateurs

Base de
données
Accesseur

Figure 2.9

Le SGBD est composé de plusieurs modules agissant en coopération dans l’enchaînement des
opérations pour calculer la réponse. Il comprend deux composants principaux : lʹExécuteur et
lʹAccesseur.

Voici le rôle général de chaque module d’un SGBD :

Analyseur : Le traitement de la requête débute par une analyse syntaxique pour en établir la
conformité avec la grammaire. Puis, une analyse sémantique vérifie que seuls les objets typés
connus par la vue sont utilisés.
Traducteur : Lorsque la requête utilise une vue (sous-schéma), le passage des références des
objets de la vue à ceux du schéma est effectué par le module de traduction. De plus, ce module
vérifie si la requête a les droits d’accès aux données pour les opérations quʹelle compte effectuer.
La dernière phase de la traduction consiste à générer un arbre de requête formé avec les
opérateurs de l’algèbre relationnelle. Finalement, lorsqu’il s’agit d’une modification ou d’un
ajout de données, le module vérifie si les contraintes d’intégrité sont respectées par les actions
demandées à faire sur la base de données.
Optimiseur : Le rôle de ce module est de transformer la requête initiale en une autre
équivalente dont le plan d’exécution est de nature à fournir un calcul plus rapide. Ce plan est
une véritable feuille de route pour la réalisation du calcul : lecture de l’index Y, accès aux
enregistrements dʹun fichier par une méthode d’accès. Ensuite, l’optimiseur établit le coût du
calcul de la réponse selon un modèle de performance (relatif au temps en fonction du volume de
données), qui sert de base dans le développement du plan d’accès optimisé.
Calcul : Le plan optimisé est exécuté par le module du Calcul du SGBD qui réalise le calcul de la
réponse pour lʹopérateur à exécuter en utilisant les index et les tables de la BD. Il est aussi chargé
de la gestion de la concurrence et assure l’atomicité et au besoin, le recouvrement des
transactions. Ce module est notamment composé dʹune fonction de gestion transactionnelle et
dʹune autre chargée de la répartition des actions de lecture et dʹécriture. L’exécuteur dédié ou
partagé est un processus qui exploite aussi les primitives disponibles dans le contexte d’un
système d’exploitation particulier.
Accesseur : C’est le module chargé de trouver et de placer en zone de mémoire partagée les
pages demandées par l’exécuteur. Il est aussi chargé de les écrire sur disque. Il gère aussi les
listes de pages de données (LRU) placées dans la ZMP. Ce module exécute les procédures
Input(no-page) et Output(no-page). Lʹadresse dʹune page est formée essentiellement dʹun
numéro de page et de lʹindice dʹune entrée dans le répertoire de la page. Le couple est appelé un
rid ou un rowid.

Dans les pages suivantes, nous ferons un rappel des notions de base implémentées dans les
SGBD dont la complexité le classe quasiment dans la famille des systèmes concurrents, près du
système d’exploitation..
Rôle des processus dans les architectures SGBD
Définition du processus
Un processus est une unité (segment de code) d’exécution gérée par le système dʹexploitation; il
est doté dʹun espace mémoire propre (RAM), de son code (segment de texte), d’un espace de

données (segment de données), d’une pile d’exécution (segment de pile, le contexte) et d’un
compteur ordinal. Il a aussi sa propre table de descripteurs, sa table des signaux et ses trois
ʺtimersʺ maintenus en son nom par lʹOS. C’est donc un programme en exécution géré par l’OS au
moyen de la table de processus Unix proc[]. Toutefois, plusieurs processus différents peuvent
exécuter le même programme. Le noyau dʹun SGBD met en oeuvre plusieurs processus
coopérants pour stocker et retrouver les données.
États dʹun processus
Un processus peut avoir plusieurs états mutuellement exclusifs :
a) Prêt à l’exécution (ready) : il a toutes les ressources nécessaires sauf celle du processeur; il
attend le feu vert du répartiteur de lʹOS.
b) En attente bloquée (blocked) : attend la fin d’une autre activité pour poursuivre la sienne; il a
déjà démarré son exécution, mais il est suspendu en attente de la libération dʹune ressource.
c) En exécution (running)
Répartition (scheduling) des tâches
Le répartiteur (scheduler) du système dʹexploitation choisit le processus à exécuter parmi ceux
qui sont prêts. Cette répartition tient compte du niveau de priorité spécifié pour chacun des
processus. Dans le contexte dʹun SGBD, les processus qui font lʹobjet dʹune répartition par lʹOS
seront ceux du noyau du SGBD. Le rôle d’un système d’exploitation n’est donc pas neutre dans
le fonctionnement du SGBD.
Alternance de processus (swapping)
Un processus en attente ou prêt peut être évacué au besoin (swapped) pour faciliter l’exécution
d’un autre qui exige de la mémoire RAM supplémentaire. Cette vidange (swapping) est réalisée
par l’OS et les pages sont rangées dans un fichier spécialisé à cette fin sur un disque. Cette
opération suppose l’exécution d’un appel au superviseur accompagné d’une sauvegarde du
contexte du processus courant.
Conséquence négative de l’alternance
La présence de nombreux processus en mémoire accroît l’activité I/O qui affecte directement la
performance du SGBD. L’alternance se manifeste par des temps de réponse variables. La
première stratégie consistait à évacuer toutes les pages d’un processus afin de libérer la mémoire
pour un processus en phase de démarrage. Dans le système SYSTEM V (Unix) une évacuation
graduée, à la page (demand paging), a éliminé l’échange inutile de pages (swapping).
Processus sous-jacents au fonctionnement SGBD
Le fonctionnement du SGBD suppose la mise en oeuvre de plusieurs modules coopérant entre
eux :

1. Un Exécuteur, éventuellement plusieurs, est créé pour le service aux requêtes. Leur nombre
dépendra de celui des clients actifs. La décision de lancer plusieurs Exécuteurs est prise par
le DBA.

2. Plusieurs autres processus pour implanter le noyau du SGBD (entre 1 et 8). Leur taille est
souvent supérieure à 1 Mo. Ils sont la propriété du compte système DBA. Leur rôle consiste

à gérer la mémoire, le journal des requêtes (transactions), le calcul de la réponse et le

lancement de reprise. Ces processus occupent un espace important dans la RAM. En règle
générale, pour maintenir une bonne performance en cours d’exploitation d’une base, il faut
maintenir au plus bas lʹactivité de pagination.
Appel au Superviseur (SVC-SuperVisor Call)
La gestion des différents processus a un effet négatif sur la performance du noyau d’un SGBD.
Parmi les facteurs de ralentissement, il y a le nombre d’appels au superviseur (SVC) pour
obtenir des services du système d’exploitation comme les opérations de I/O sur disque, certaines
communications entre processus (IPC) et leur synchronisation. De plus, la commutation du
contexte système demandé à chaque SVC constitue une charge pour le processeur notamment
au début et à la fin de chaque SVC, puisque la sauvegarde des registres, des piles et des caches
exige une activité I/O relativement importante. La fréquence de la sauvegarde du contexte est
variable selon la machine. Elle peut varier de 1500 bascules/sec pour un micro-ordinateur à plus
de 10 000 bascules/sec pour les ordinateurs de puissance.
Multiplication des processus
Un processus peut en créer d’autres par une fonction système [comme la fonction C fork()] pour
diviser, au profit des utilisateurs, le travail global à effectuer par le processus parent. Cette
multiplication des processus n’est pas neutre et accroît la charge de travail de lʹOS :
a) Augmentation du nombre de commutations de contexte.
b) Accroissement de la charge pour le répartiteur qui doit gérer plus de processus.

Un processus ainsi créé est dit processus enfant et hérite du descripteur du processus parent lui
permettant dʹavoir accès aux mêmes fichiers et aux mêmes sockets qui appartiennent au
premier. Pour un SGBD, lʹutilisation de ce mécanisme exige quʹun premier processus soit lancé
par le compte DBA et quʹensuite, les autres soient créés par la primitive fork(). Cʹest ainsi que le
nombre de processus Exécuteurs pourrait être augmenté lorsque le nombre de clients atteint une
certaine limite.
Thread (compteur ordinal + pile + code)
Un processus peut avoir plusieurs threads pour exécuter en parallèle divers traitements. Le
thread se distingue du processus par le fait quʹil a le même espace dʹadressage que celui du
processus qui lʹa lancé. Il a donc accès aux mêmes données en mémoire et aux mêmes
ressources de fichiers et de sockets que ceux du parent. Cependant, il a une pile propre, son
propre code et son compteur ordinal. Si un même ordre DML est exécuté par plusieurs threads,
la performance sera dʹautant plus grande si chacun est exécuté par un processeur distinct tout en
utilisant une partition différente des données. A terme, la réunion des résultats de chaque thread
fournira la réponse à la requête DML. Ce parallélisme dans le calcul de la réponse à une requête
permet d’avoir des performances sensiblement meilleures avec les bases de grande taille.
Mécanismes de communication interprocessus
La communication avec et entre les processus du noyau (IPC) pour échanger un ordre DML (ex.
SQL) ou dʹautres données de contrôle ou pour retourner les données de la réponse calculée sous-
tend lʹexécution de fonctions de système par lʹOS afin dʹimplanter les diverses fonctionnalités à
savoir le stockage, le recouvrement et la cohérence de la base de données au niveau du serveur.

Deux cas de figure sont importants :

a)Communication interprocessus sur une seule machine au moyen des mécanismes suivants :
tube, queue, mémoire partagée.
b) Communication interprocessus sur plusieurs machines par sockets et RPC (pour les bases de
données réparties et lʹarchitecture client/serveur).

En gros, un SGBD est un ensemble de programmes, donc autant de processus appartenant au

même groupe de processus (groupid). Ces processus coopèrent entre eux, se mettent en attente et
se réveillent périodiquement pour effectuer des actions de lectures ou de mises à jour sur la base
de données, notamment par lʹaccession à une page de données, la vidange des données de la
RAM ou la réalisation dʹun point de reprise (checkpoint).

Mécanismes IPC sur une seule machine

Le tube (pipe) avec le modèle lecteur/écrivain est un mécanisme implémenté directement
comme une primitive du système Unix.

tube 1 Figure 2.10

Processus 1 Processus 2

tube 2

OS
Buffer géré par le noyau
OS table
table descripteur
descripteur
Le buffer est créé dans lʹespace géré 0 stdin
0 stdin par lʹOS 1 stdout
1 stdout

C’est un mécanisme simple unidirectionnel qui sʹapparente aux fichiers et qui est applicable
entre processus appartenant au même groupe de processus et ayant le même parent (process
group), car cʹest par lʹhéritage dʹune table de descripteurs dʹun ancêtre commun que les deux
processus vont pouvoir communiquer. La fonction pipe(fd) génère deux descripteurs de fichier
et alloue un buffer interne, lequel est géré par le noyau du système OS . Par exemple, pour
communiquer à un processus 1024 caractères rangés dans un tableau nommé tabA, le
processus2 utilisera la fonction write(fd,tabA,1024).

Les étapes sont les suivantes :

a) création du tube : int pipe(p)
Cette fonction de système est exécutée avant le fork(). Lʹargument p est un tableau p[2] de type
entier. Un premier descripteur doit remplacer celui en position 0 (stdin) et le deuxième celui en
position 1 (stdout) de la table des descripteurs de lʹautre processus qui est identique à celle du
premier. Le tampon interne est généralement limité à une taille de 4 Ko.

b) les fonctions read et write sont utilisées pour lire et écrire sur un tube comme dans un fichier.
Ces fonctions font un appel SVC (appel au système), donc amorcent une commutation de
contexte avec un effet négatif sur la performance. Lʹécrire de 1024 caractères rangés dans le
tableau tabA au moyen du stdout dont le descripteur est 1, est fait par la fonction suivante :
write ( 1, tabA, 1024); -- écrire 1024 car. dans le tube 1

La lecture de 1024 caractères dans le stdin dont le descripteur est 0, est faite par la fonction
suivante :
read(0, buf , 1024); -- lecture du buffer interne

Le tube a lʹinconvénient dʹimplémenter un échange sur une même machine et dʹavoir un tampon
limité à 4096 octets. Si deux processus doivent échanger des données simultanément dans les
deux sens, ils doivent avoir un parent commun afin de pouvoir établir deux tubes entre les
processus en question. Finalement, le tube est bloquant dans ce sens que si la lecture est moins
rapide que lʹécriture, le processus écrivain sera suspendu.
Mémoire partagée (ZMP)
Ce mécanisme permet à deux processus dʹéchanger des données en partageant lʹaccès à une
même zone de mémoire RAM par la même adresse du début de la dite zone.

Processus 1 Processus 2

Espace géré par lʹOS Pages de données

Zone non structurée explicitement

Figure 2.11
En créant cette zone de mémoire commune, l’OS assigne une clé d’accès à cette zone figée qui
reste généralement en mémoire principale et qui est accessible sans appel au superviseur (SVC).
Cette clé dʹaccès est rendue accessible aux applications par une fonction système shmat(cle,0,0).
Cette ZMP est logiquement constituée dʹun seul espace, mais selon les OS, elle peut être
constituée de plusieurs segments partagés de mémoire RAM, alloués par le système. La zone de
mémoire partagée est créée par lʹOS qui fournit aussi une clé dʹaccès à cette même zone.

La mise en oeuvre dʹune ZMP peut se faire de la façon suivante :

a) Création dʹune ZMP de 4Ko avec la fonction:
cleZ = shmget(cleU, 4096);

La clé reçue, cleZ est la donnée essentielle pour le rattachement à la ZMP. Elle est calculée à
partir de la cléU (un très grand entier) fournie par le processus ou lʹutilisateur au moment de la
création de cette zone.

b) Un processus serveur, SP, sʹattache la ZMP par la fonction: char *shmat(cleZ).

Le processus obtient la clé dans la liste de paramètres transmise par un module temporaire
chargé du lancement du processus pour ensuite disparaître. Lʹadresse dʹattachement est fournie
comme valeur de retour de la fonction.

c) Le processus peut alors accéder à la ZMP comme si cʹétait une mémoire locale, cʹest-à-dire
comme étant une partie de son espace adressable. Dans le contexte dʹun moteur SGBD, cʹest un
module spécialisé qui sera chargé dʹaccéder aux pages de cette zone.

d) Chaque processus doit contrôler lʹaccès à la ZMP et plus particulièrement aux pages par des
sémaphores mis en oeuvre par la fonction système shmctl()ou par la définition dʹun sémaphore
pour chaque page de la ZMP. Il est aussi possible de déléguer à un autre processus la mission
de contrôler les accès aux données des pages en gérant une liste de verrous attribués à chaque
transaction.
Avantage de la zone de mémoire partagée (ZMP)
Par cette technique efficace, un processus accède à la ZMP dont il se doit de connaître la
structure et cela, afin de pouvoir accéder aux données rangées dans cette zone. L’échange de
données est possible sans faire de nombreux appels répétitifs au système (SVC). Lorsqu’un
processus réalise son attachement par un premier SVC, il peut par la suite y accéder directement
sans autre SVC et sans changement de contexte, puisqu’il utilise la même clé d’accès obtenue
lors du premier SVC. Ayant accès à la ZMP, un processus peut accéder aux différentes
structures internes au moyen dʹune structure de répertoire créée au préalable par le processus
qui a créé la ZMP.

La ZMP est généralement paginée au cours de sa création de sorte que le processus qui accède
aux pages en connaît la structure de page et peut accéder à son contenu par lʹentremise dʹun
répertoire créé pour chaque page. S’il devait y avoir une ZMP pour chaque processus
Exécuteur/Accesseur, la ZMP bloquerait une bonne partie de la RAM, avec lʹapparition de
problèmes concernant la synchronisation des accès. Finalement, bien que cette zone puisse être
l’objet d’un échange (swap), il est préférable de la fixer (pin down) pour obtenir une meilleure
performance. Une activité de pagination qui est croissante est un indicateur pour le DBA que la
mémoire RAM est insuffisante et que le SGBD peut manifester des symptômes de sous-
performance.
Queue de messages
Cette technique permet lʹéchange de messages entre deux processus en les plaçant dans une
queue. Chaque message est ensuite repris par un des processus (modèle de la boîte postale). Les
primitives SEND() et RECEIVE() utilisent les appels SVC de lʹOS (System Supervisor Call) pour
lire ou déposer des messages. Il y a donc à chaque écriture, une commutation de contexte. La
queue est gérée par le noyau de l’OS (Unix SYSTEM V).

écrire msg( SVC)

OS Processus 3
Processus -7 (pid = 3)
(pid = 7)
queue 4

Échange dʹun message entre deux processus de la même machine

Figure 2.12
Une fois paramétrée correctement, la queue peut accepter un tas de messages de longueur
variable. Le processus qui transmet et celui qui reçoit nʹont pas nécessairement un parent
commun. La figure 2.12 illustre la communication interprocessus utilisant la queue de messages.
Le processus 3 place une requête SQL dans une queue particulière, par exemple la 4. Elle sera
reprise par le processus 7 pour être exécutée et fournir les tuples de la BD. À chaque
communication, il y a un appel SVC et un changement de contexte afin d’assurer la reprise et la
poursuite correcte du programme courant. Cette méthode permet dʹéchanger des données après
que le processus émetteur soit inactif ou disparu.Lʹutilisation dʹune queue de messages fait
appel aux fonctions suivantes :
a) Création dʹune queue et son ouverture par la fonction : wid = msget().
b) Envoi ou réception dʹun message : retour = msgsnd(0) et retour = msgrcv().
c) Contrôle et suppression de la queue par la fonction système msgctl().
Caractéristiques de la queue de messages
L’usage d’un appel système SVC pour lire/écrire un message dans une queue génère un
changement de contexte donc une charge I/O pour l’échange (swapping). La queue de messages
demeure en RAM tant quʹelle nʹest pas détruite par le processus qui lʹa créée. En cas
dʹannulation de ce processus, la mémoire doit être libérée par un processus de service de lʹOS.
La taille d’un message doit être raisonnable, car elle est limitée par l’espace alloué à la queue.
Prise (socket)
Cette technique a été implémentée en premier dans Unix BSD 4.x pour être ensuite
graduellement adoptée par plusieurs systèmes dʹexploitation.

Espace OS
sd = 4 sd = 9

Application Socket client Socket

serveur
réseau
(no-machine, no-port) (no-machine, no-port)
Couche TCP du logiciel de communication

Figure 2.12a

La particularité de cet IPC est la possibilité d’avoir une communication entre processus d’une
même machine (famille AF_UNIX) ou de différentes machines distantes (famille de protocole
PF_UNIX) pour lʹIPC au moyen dʹune communication basée sur la technologie TCP/IP.
Association des deux extrémités identifiées par le couple (machine, port) mise en œuvre par le
système dʹexploitation ou par un logiciel de communication. Une prise (socket) est créée par un
processus client au moyen de la fonction socket(): un numéro de prise (sd) et deux tampons
internes à lʹOS sont créés pour la lecture et lʹécriture des messages. Le processus émetteur écrit
dans une prise par une primitive write() comme il le fait pour un fichier. Dʹun autre point de vue
du logiciel, la prise ou la socket est en quelque sorte une interface de programmation avec les
fonctions de la librairie système de TCP/IP. Le descripteur dʹune prise est inscrit dans la table
des descripteurs du processus de lʹapplication qui lʹa créée. Du côté serveur, une prise est aussi
créée et lʹassociation technologique entre ces deux prises est établie en utilisant lʹadresse Internet
des machines et le numéro de port.
La prise ou socket peut donc être vue comme un ensemble de primitives - socket(), listen(),
bind(), ... dʹinterface avec lʹOS pour implémenter l’échange les données entre deux machines
distantes en masquant la couche transport qui sera implémentée par le noyau de lʹOS via une
technologie de communication appropriée. La communication distante entre deux processus est
présumée implémentée par une technologie matérielle et se manifeste au niveau des clients et
du serveur par une communication entre deux extrémités logiques appelées extrémités de
connexion où chaque processus a accès à une socket. Le mécanisme de communication
schématisé ci-dessous fait appel à des tampons-systèmes (buffer) créés de chaque côté par les
primitives socket().
Port
Un port est identifié par un numéro et associé à une queue de messages gérée par lʹOS. Par
exemple, une queue de messages connue comme le port 5, un processus en fait la lecture en
référant au port numéro 5. Les fonctions disponibles pour l’implémentation d’une prise par un
appel au système dʹexploitation sont les suivantes (8).

RAM-OS RAM-OS
out socket 6

out port 80 In

In
TCP-IP socket 9

read()
socket 7
write()
Client accept()
Serveur
read()
write()

Figure 2.12b

a) Création d’une prise côté client :

Le système OS construit une prise dans la table des descripteurs de lʹapplication et retourne le
numéro de la prise (fd_sock_c), i.e. du descripteur au client. Deux tampons systèmes y sont
associés, un premier pour la sortie et lʹautre pour lʹentrée.
fd_sock_c = socket (domaine, type_de_socket, protocole);
Exemple :
fd_sock_c = socket (AF_UNIX, TCP, AF_INET);
où fd_sock_c est le descripteur (un entier) de la socket dans la table du processus client et qui
est aussi gérée par lʹOS du client. Du côté serveur, la fonction exécutée pourrait être la suivante :
fd_sock_s = socket(domaine, type_de_socket, protocole);

Dans le cas du serveur cʹest une prise dite passive, car il ignore encore lʹadresse IP du prochain
client. Le processus serveur est à lʹaffût de tout message écrit dans une prise associée à un port
particulier que le serveur va surveiller attentivement.

b) Association de l’adresse du descripteur d’une prise, i.e. de point de communication cible (IP,
port).
- Pour le processus client
Lʹadresse IP et le port de la machine cible (soit celle du serveur ciblé) doivent être connus, car ils
sont fournis comme arguments dans lʹappel du connect() lancé par le client:

res_c = connect(fd_sock_c,&sock_c,&sock_s,sizeof(sock_s))

où sock_s fournit le IP et le port du serveur et sock_c fournit le IP et le port local. La fonction

peut aussi utiliser la struct prédéfinie sockaddr_in qui contient ces mêmes données. A ce
moment, le client a fait connaître à son module local de TCP, le IP et le no du port quʹil entend
utiliser pour transmettre et recevoir des informations à distance à partir du client au moyen
dʹappels read() et write().

- Pour le processus serveur

Le serveur a créé une socket dès son lancement; il a utilisé la fonction socket(). Le point de
communication (IP et no de port) est inscrit subséquemment par la fonction bind() lancée par
le serveur
Res = bind(fd_sock_s, &adres_sock_s, sizeof(&sock_s))
A ce moment, le serveur a 2 tampons-systèmes: un pour recevoir (IN) et un autre pour
transmettre (OUT).

c) Envoi d’un message par le client au moyen de sa socket locale et en utilisant son descripteur
de socket, cʹest-à-dire lʹindice de son entrée dans la table du processus :
sf = fdopen(fd_sock_c, "w"); --ouverture de la socket client
write(sf, tamponout, 1024);

Si le client ferme la socket, il ne pourra pas recevoir de réponse du serveur, mais son message de
sortie sera quand même transmis au point de communication cible, soit le serveur.

d) Réception d’un message par un serveur: Listen () et Accept ()

La fonction Listen() place la prise du serveur dans son état passif et informe lʹOS du serveur
de mettre en file les x prochains messages reçus par la socket :
res = Listen(fd_sock_s,5); - 5 messages en queue

La fonction Accept() extrait le prochain message de la socket (via son tampon IN) de la
manière suivante : création dʹune nouvelle socket (fd_sock_ns) où lʹOS placera le message
trouvé dans le tampon IN. En ce faisant, le serveur garde en disponibilité la socket initiale pour
recevoir sans délai un autre message éventuellement dʹun client différent. Il pourrait aussi faire
un fork()pour traiter le message reçu.

rf = accept(fd_sock_s, NULL, NULL);

processus client processus serveur

sfd = socket() sfd = socket() Création de la socket serveur

res = bind() Association de lʹadresse IP

du serveur à la socket

connect() Socket devient passive et

res = listen()
à lʹécoute

Socket devient active

Prise de message dʹune socket
res = accept() particulière et création dʹune
nouvelle pour le serveur

read() Acquisition des données de la

write()
nouvelle socket

read() write()
Transmission des données par le
serveur
close() close()

Figure 2.12c
Le serveur logiciel boucle à lʹinfini :
do {
if ((sd = accept()) == -1) exit(0); -- boucle
do
{ ch = getc(sd);
. . .
close (fd_sock_ns);-- socket créée par le serveur pour avoir accès --
au contenu de la socket d'origine
}; . . .
} while (TRUE);

e) Fermeture d’une prise avec suppression et libération des tampons-

systèmes :
result = close(fd_sock_ns)

La socket fd_sock_ns est fermée. Le serveur continue toujours à recevoir des messages par
lʹentremise de la socket dʹorigine (fd_socket_s) qui est toujours active. Ce mécanisme IPC est
mis en oeuvre dans certaines composantes d’un SGBD, notamment dans le module de gestion
du réseau qui est présent sur chaque station client (module dʹécoute). La prise créée par le client
utilise lʹadresse IP du serveur distant pour établir la connexion. Le serveur connaîtra la
provenance de la communication parce que la trame TCP comprend lʹadresse IP du client ainsi
que le numéro de port du client.
Table des descripteurs
( 1 par processus)
Structure de données dʹune socket

IN
famille : PF_INET
OUT
service: SOCK_STREAM
local IP
remote IP

socket local port

remote port

Structure de socket gérée par lʹOS-Unix

Figure 2.12d
Un module dʹécoute au niveau du serveur permet de détecter une connexion TCP spécifiée par
une adresse et un numéro de port prédéterminée. Comme nous l’avons décrit, à lʹarrivée d’un
message, le serveur en attente accepte immédiatement le message et effectue la création dʹune
nouvelle socket pour y copier le message reçu et cela, pour permettre au serveur de continuer à
recevoir des messages (concurrence) sur la socket dʹorigine. Ce mécanisme fait appel à des
fonctions de système pour établir la connexion, mais lʹéchange peut se faire directement par
lʹintermédiaire des fonctions TCP de la bibliothèque du logiciel de communication. Cette
opération nʹest pas très lourde en termes de commutations de contexte pour le serveur et le
client.

La connexion nécessaire pour la communication entre deux processus distants est considérée
comme réalisée au plan technologique dès lors que le quintuplet suivant est déterminé et connu
sur chaque site-client et serveur - voulant établir une communication :

{protocole, adresse_serveur, port_site_serveur, adresse_site_client, port_site_client}

Communication RPC entre deux processus (GABASSI, 1992)
Le mécanisme de communication RPC (Remote Procedure Call) entre les processus distants est
synchrone en mode connecté ou non. Il permet de transmettre une information à un autre

processus distant comme un appel de procédure standard. Le processus appelant émet le RPC()
et attend le résultat avant de poursuivre son activité au niveau de la station client. Le serveur
reçoit l’appel et les arguments de la procédure, exécute la tâche sous-tendue par cet appel et
retourne les résultats. La gestion de la synchronisation et du rendez-vous est prise en charge par
les procédures du RPC. Cette technique se prête bien à l’exécution de lʹordre DML d’une
application client, car cet ordre doit être exécuté entièrement avant que l’application poursuivre
son traitement local. Le RPC est une couche par dessus la socket et constitue de ce fait une
interface plus conviviale pour le développement des applications.

Application-RPC
...
sqlrpc(ʹselect nas, nom FROM Ouvrierʹ)
Serveur :
(désencapsulage de lʹappel rpc)
exécution de lʹordre
(encapsulage du résultat)
retour des données par le serveur
suite de lʹapplication : au processus appelant)
récupération de la réponse et calcul.
...

Figure 2.12d
Appel dʹune procédure distante dans une architecture client-serveur
Ce mécanisme dʹéchange de données entre deux processus est de plus en plus utilisé. Le schéma
de la figure 2.12d inspiré par celui présenté par Gray et Reuter (9) illustre les étapes dʹexécution
dʹun appel RPC entre deux processus distants.

Lʹencapsulage (packaging) peut être fait par un langage spécialisé comme le IDL (Interface
Description Language) qui, une fois compilé donnera un code que le serveur cible pourra
compiler pour générer un code quʹil pourra exécuter. Chaque RPC est associé à un point de
communication différent (IP, port) de sorte que le retour de lʹappel RPC se fait sans ambiguïté.
Avec tous ces mécanismes pour la communication, chaque appel à une fonction système génère
une commutation de contexte qui nʹest pas neutre en terme de charge sur le CPU. Cʹest souvent
un facteur limitatif pour la performance dʹun SGBD.
Architecture fonctionnelle générale du SGBD
L’architecture générale(10) d’un SGBD a plusieurs variantes entre les deux configurations
extrêmes ci-dessous. Le choix d’une variante dépend entre autres choses des ressources du
serveur, du nombre de clients sur le réseau et de la nature des traitements effectués par les
applications.
Exécuteurs dédiés et un Accesseur
Avec cette configuration, chaque client est associé à un serveur de processus dédié (Exécuteur)
qui est chargé dʹexécuter chaque ordre DML reçu de son client. Si aucun client ne transmet un
ordre, le serveur est en attente dans la RAM.

Les processus dʹarrière plan du noyau du SGBD ont le même parent soit le compte DBA. Ils
peuvent communiquer entre eux au moyen de tubes, de sockets et par une mémoire partagée.
La socket a lʹavantage de rendre le noyau portable dans un environnement réparti, tandis que la
mémoire partagée privilégie la performance dans lʹaccès aux données. Avec l’architecture de la
figure 2.13, les ordres qui arrivent d’une même station sont traités par le même serveur de
processus (SP) dédié à ce client. Il pourra y avoir plusieurs Exécuteurs tant que leur nombre ne
dépasse pas celui autorisé par le DBA via le paramètre système approprié.

Usager 1 Usager 2 Usager 3

TCP-IP TCP-IP TCP-IP

Réseau

Serveur TCP-IP

Exécuteur Exécuteur Exécuteur

BD
Accesseur
Zone Mémoire Partagée

Figure 2.13

Une fois la réponse calculée, les tuples sont retournés à la station client par lʹexécuteur dédié via
le lien TCP/IP entre le serveur Oracle et le client en question. Ce lien reste ouvert tant et aussi
longtemps que lʹapplication ne ferme pas la base par un ordre Close. Cette architecture est
caractérisée par un usager connecté servi par un exécuteur dédié. Si le nombre dʹusagers
dépasse le nombre dʹexécuteurs autorisés, la connexion ne sera pas établie immédiatement.
Cette configuration est pratique lorsque le nombre de clients est raisonnable et que les
ressources informatiques sont largement disponibles. De plus, cette configuration ne comprend
quʹun seul Accesseur chargé des accès aux pages, au service de tous les Exécuteurs.
Avantage
Le serveur de processus est dédié à un client; il est en attente lorsque ce dernier effectue des
calculs locaux. Il est mis en veilleuse après la fermeture de la communication avec le client. Il
demeure inactif tant que le client l’est aussi.
Inconvénients
Le nombre dʹExécuteurs concurrents croît avec celui des usagers. La charge du répartiteur
sʹaccroît dʹautant et cela peut se traduire par une diminution de la performance du SGBD,

accompagnée dʹun encombrement plus important de la RAM. Cette architecture exige un

ordinateur puissant, des disques rapides de préférence de type RAID et une mémoire RAM très
importante, afin de réduire au minimum la pagination. En effet, la multiplication des Exécuteurs
accapare la mémoire nécessaire pour assurer une bonne performance et minimiser les échanges
de pages. Finalement, le partage des données par plusieurs Exécuteurs nécessite un contrôle
centralisé des accès à la ZMP qui demeure unique.
Exécuteurs partagés et un seul Accesseur
Une autre configuration met en oeuvre une plus grande coopération entre quelques exécuteurs
qui traitent les requêtes en provenance de plusieurs clients. Pour réaliser cette architecture, il
faut un module de réponse pour chaque communication établie avec un client. Cʹest le module
Dispatcher Di qui joue ce rôle de prendre en note lʹadresse du client, de recevoir la requête et de
la formater correctement avant de lʹinsérer dans la queue associée à un Exécuteur. Ce dernier
sera partagé entre plusieurs clients. Le rôle du répartiteur de lʹOS sera de voir au partage du
processeur entre les deux Exécuteurs en tenant compte de leur priorité respective. Bien entendu,
un système à deux processeurs serait plus performant, car chacun aurait son propre Exécuteur.

Usager 1 Usager 2 Usager 3 Usager 3

TCP-IP TCP-IP TCP-IP TCP-IP

Réseau

Serveur TCP-IP
module D2 module D1

OUT IN
OUT IN
Exécuteur
Exécuteur
BD

Accesseur Zone Mémoire Partagée

Figure 2.14

Dans ce cas de figure, un seul Accesseur gère le transfert des pages de la ZMP. En effet, le travail
de l’Accesseur est plus léger que celui de l’Exécuteur; il peut donc être partagé avec profit entre
plusieurs Exécuteurs et cela, sans perte significative de performance. Pour isoler le client de
lʹExécuteur, un processus intermédiaire (D) est créé avec la mission de recevoir la requête dʹun
client et dʹagir en son nom au niveau du serveur.

LʹOS doit être multitâche et préemptif. Les Exécuteurs de même priorité obtiennent à tour de
rôle le processeur pour faire progresser leur traitement jusqu’à l’épuisement de leur quantum de

temps CPU. À ce moment, le répartiteur de lʹOS passe le contrôle du CPU à un autre processus
Exécuteur qui retire une requête dans une file dʹentrée dʹun client.
Avantages de cette architecture multiexécuteur partagé
Le nombre dʹExécuteurs est plus petit que celui des clients puisquʹils sont partagés. Ceci se
traduit par un encombrement moindre de la RAM et donc une charge de swapping plus faible.
Comme il y a moins de processus actifs, il y a aussi moins de commutations de contexte.
Finalement, cette configuration se prête naturellement à lʹexécution parallèle lorsquʹil y a
plusieurs processeurs partageant la même mémoire RAM. Lʹinconvénient a trait au temps de
réponse avec un système monoprocesseur. En effet, comme le client nʹa pas dʹExécuteur dédié, le
temps de réponse risque dʹêtre parfois plus long si la transaction précédente ou concurrente est
longue.
Ressources du logiciel client
Chaque client doit avoir les ressources en logiciels nécessaires pour établir la communication et
gérer les échanges. Avec plusieurs versions du système Oracle, il y a notamment le module
SQLPlus, le Developer/2000 et le module SQLNET. La gestion des échanges avec le serveur est
faite par le module SQLNET de la station qui gère la communication réseau, notamment les
couches inférieures du modèle OSI. L’exécution dʹun ordre DML est sous la responsabilité du
serveur de processus (Exécuteur) et, pour certains logiciels clients, le caractère procédural peut
être pris en charge par un module du serveur capable dʹexécuter un bloc PL/SQL.
Communication client-SGBD avec Oracle
L’architecture générale du système Oracle, version 7.x comporte plusieurs processus distincts
pour le noyau, un processus de communication et une zone de mémoire partagée pour la
communication interprocessus au sein de la machine serveur. Nous utiliserons celle-co comme
exemple en précisant que d’autres architectures sont possibles.

client 1 client 2 Réseau

SQLNET
Serveur de processus (SP)
SGA OUT IN
D3

Processus de service DBWR

Serveur

Configuration avec entrelacement de l’exécution (multithreading)

Figure 2.15

Voici une vue plus détaillée de deux des modules :

Serveur de Processus (SP)

Processus de service:
RECO CKPT PMON ARCH LGWR SMON

BD + DD
Journal

Figure 2.16

La communication entre les processus est assurée par les mécanismes IPC connus : zone de
mémoire commune (SGA) et le RPC, soit l’appel de procédure distante. Du côté de l’usager, le
processus client gère les échanges de données avec le noyau du SGBD qui sʹexécute sur le
serveur.
Connexion dʹun client
La procédure générale est la suivante :
a) Le client signale sa présence au Module d’Écoute du Réseau (MER ou Listener de SQLNET)
au moyen de son adresse (IP, no-port). La requête de communication est ensuite transmise par
le client.
b) Du côté du MER, s’il y a un répartiteur (dispatcher) qui reconnaît son adresse IP et place la
requête du client dans la file du serveur. Il y a retour de l’adresse d’écoute (adresse Ethernet) qui
est valide pour la session en cours.
c) Le client transmet la requête SQL au répartiteur qui la met, sʹil y a lieu, en file d’attente avant
son traitement par un serveur de processus (Exécuteur).
d) En mode entrelacement d’exécution (multithreading), la queue est servie par un nombre limité
de serveurs de processus (SP).

S’il n’y a pas de serveur de processus disponible (Exécuteur) et si un autre peut être autorisé par
le DBA, il pourrait y avoir création automatique d’un serveur de processus (SP) pour le client
concerné. Le nombre de SP ne peut cependant pas dépasser une limite fixée par le DBA.
Fonctionnement schématique d’un SGBD
Le fonctionnement général d’un SGBD est représenté à la figure 2.17. Le schéma illustre les
principales fonctions généralement implémentées par un moteur de SGBD qui tourne sur un
serveur dans une approche client/serveur.

Séquences des traitements

Le traitement dʹun ordre DML est réalisé complètement avant le passage à lʹexécution dʹun autre
ordre DML du même programme. La figure 2.18 présente schématiquement les enchaînements
dans le traitement dʹune requête ou dʹun DML :
1)Réception de lʹordre DML par lʹExécuteur en vue dʹune première étape dʹanalyse
lexicographique. La transaction est ensuite dirigée vers le module dʹanalyse.

Analyse lexicographique

Analyse syntaxique et
Dictionnaire
sémantique
de données

Traduction DML ou requête

Vérification des droits ZMP

dʹaccès
page 2 Journal
interne

copie arbre schémas :conceptuel

Mapping de la requête
réutilisable externe et interne

Optimiseur

Accesseur BD
Exécution de lʹordre :
gestion de la transaction

RAM Zone de travail

Retour de la réponse au
client via le dispatcher de
processus

Journal
Journalisation
externe

Figure 2.17

2) Vérification syntaxique et sémantique de l’ordre en se référant au dictionnaire de données

(DD) afin de valider les attributs. Dans le cas du DDL, il peut y avoir de nouvelles entrées dans
le DD.

3) L’ordre est ensuite traduit pour construire un arbre d’exécution non optimisé qui est rangé
dans la ZMP afin de pouvoir être réutilisé au besoin par dʹautres clients (cas des requêtes
OLTP). Pour un SGBD relationnel, lʹarbre est constitué avec les opérateurs algébriques et les
relations de base référées au niveau des feuilles seulement.

4) Le module de contrôle des accès vérifie les droits dʹaccès de l’utilisateur pour les données
requises par le calcul de la réponse. Il y a aussi accès au dictionnaire.

5) Chargement dans la ZMP des schémas de relation stockés dans le dictionnaire et de la liste
des droits dʹaccès.

6) Pour une requête d’interrogation : remplacement des attributs de la vue par ceux du schéma
conceptuel et référence au schéma actuel.

7) Lʹarbre de requête est optimisé afin dʹobtenir une requête arborescente équivalente qui
permet un calcul plus rapide de la réponse.

Pour la mise à jour : augmentation de l’arbre par une vérification des contraintes spécifiées dans
le schéma. Les procédures sont chargées par le module de vérification de l’intégrité de la BD.

8) Génération du plan d’exécution optimisé, lequel est rangé dans la ZMP.

9) Exécution de chaque plan par le module de calcul. Il y a alors intervention du module de

gestion transactionnelle incluant le répartiteur de transactions. LʹExécuteur doit à ce moment
avoir toutes les informations nécessaires au calcul de la requête ou à la réalisation du DML.

10) Journalisation interne (redo log buffer) des seules transactions d’écriture et de mise à jour.

11) Lecture ou écriture des pages demandées. L’adresse de la 1re page est obtenue du DD.

12) Au besoin, le recouvrement de la base de données est fait avec le journal des transactions
internes pour reconstituer la base de données dans un état cohérent antérieur.

13) La réponse est placée dans la queue de sortie et lʹouverture dʹune socket permet le transfert
des tuples au client.

A lʹexécution dʹun COMMIT, les écritures de la transaction sont transférées du journal interne
vers le journal externe (log file) créé sur disque dur. Au contraire, avec le ROLLBACK, les

modifications et les écritures effectuées sont défaites pour revenir à lʹétat de la base
correspondant à celui du début de la transaction.
Exemple d’un traitement d’un ordre de requête simple
Le MRD de la base utilisée correspond à un MCD fort simple composé dʹune seule relation
appelée aussi une table et qui décrit les attributs des employés. La clé de cette table est le nas
identifiée par un astérisque .

Employe (nas*, nom, ville, salaire, no-projet)

Schéma externe (vue de la BD)
La vue relationnelle est définie sur la relation de base Employe comme étant une autre vision de
la table, soit un sous-ensemble de ses attributs, au besoin différement nommés :

Employev (matricule*,cite, no-projet)

Cette vue Employev définit un mapping entre la table de base et la table virtuelle représentée
par la vue.
Attributs de la table Attributs de la vue
nas ----> matricule (nom différent)
nom ----> (attribut absent)
ville ----> cite (nom différent)
salaire ----> (attribut absent)
noProjet ----> noProjet (idem)

La vue correspond à une projection relationnelle des attributs de Employe sur ceux de la vue.
Cet opérateur sera étudié au chapitre de l’algèbre reltionnelle. Cette vue est associée à
lʹapplication lors de lʹouverture de la base de données.
Approche ensembliste
Le traitement de la requête ci-dessous n’est présenté quʹà titre dʹillustration et ne représente pas
nécessairement lʹimplémentation dʹune telle requête dans les SGBD actuels.

Trouver le matricule et la cité des employés assignés au projet ʹP9ʹ. ?

Sous forme d’un DML fictif, cette question pourrait s’écrire :

TROUVER [Link], [Link] AVEC [Link] = 'P9'

Analyse lexicale et syntaxique : validation des mots clés et de la syntaxe de la requête :

TROUVER <liste-attributs> AVEC <prédicat>

Traduction de la requête par l’intégration d’un appel de procédure dans le langage hôte :

CALL DMLSGBD
(dml, `matricule, cite’,’Employev’,noProjet = 'P9', reponse, codeRetour)

où lʹargument dml = 1 correspond à lʹordre TROUVER. La fonction DMLSGBD() assure

notamment la communication avec le SGBD via une socket ou un RPC.
Au niveau du serveur, il y aura consultation du dictionnaire de données (DD) pour vérifier si la
vue utilisée par l’application autorise l’accès aux données (étape 3).

Ensuite, il y a génération dʹun arbre de requête par le SGBD intégrant la transposition des
éléments de la vue pour tenir compte du schéma de la base (étape 4).

Pour une requête d’interrogation, il y a optimisation de l’arbre de requête pour privilégier

lʹusage de lʹindex existant sur no-projet de la table Employe. Un plan dʹexécution est préparé
pour lʹétape suivante.

Génération du plan d’exécution de la mise à jour.

Les adresses de la première page de lʹindex et des données sont dans le dictionnaire du SGBD.
Ainsi, le système peut savoir quel index utiliser et où le trouver sur le disque :

(4) Affichage de la réponse

(3) Transposition : nas devient matricule et ville devient cite

(2) Extraction de nas et ville

(1) Recherche du projet P9

Début

Employe
Figure 2.18
...
WHILE code_succes = SUCCES
read index Employe avec noProjet = 'P9'— trouve no de page
read page Employe avec l'adresse de la page (no de page)
write [Link], [Link] (+ mapping des noms d’attributs)
Fin while
. . .

8) Exécution du plan : l’accès aux fichiers sur disque est fait par lʹAccesseur.
9) Dans le cas dʹune modification de la table, il y a écriture dans le journal interne et
éventuellement dans le journal externe (à la validation) des données avant et après
modification.
10) La page est placée dans le tampon du moteur SGBD (la Zone de Mémoire Partagée) avec un
verrou approprié demandé par lʹExécuteur. Ce dernier garantit lʹintégrité en refusant ou en
autorisant le partage des données avec les autres utilisateurs.

11) Le module de recouvrement demeure inactif, car l’opération est présumée avoir été
complétée correctement.
12) LʹExécuteur accède à la ZMP pour calculer la réponse et retourner les données à l’application
conformément au schéma externe (sʹil y a lieu, transposition des noms dʹattribut).
Remarque : Cette exécution sert seulement d’illustration générale et n’est pas nécessairement
typique ni de l’interface entre une application et le SGBD, ni des techniques d’implémentation
des SGBD qui varient dʹun système à lʹautre.
Gestion et répartition transactionnelle par lʹExécuteur
Le module Calcul est responsable de construire la réponse et comprend, notamment dans les
sous-modules de Gestion Transactionnelle (GT) et de Répartition Transactionnelle (RT) des
actions de lecture et dʹécriture sur le disque. On peut représenter ces deux derniers modules par
le schéma général ci-dessous. Lors du traitement de deux ordres disincts en provenance de deux
applications différentes, lʹExécuteur peut les traiter en concurrence par un métissage du
traitement des deux transactions. Ainsi lʹordre r1 est une lecture de page appartenant à la
transaction T1 et r2 une autre lecture associée à la transaction T2.

Train de lectures et écritures de pages :

c1, r1, e1, r1 c2, r2, e2, r2 Répartiteur c1, r1, c2, r2, e1, r1, e2, r2
Transactionnel
RT
T1 T2 séquence modifiée

Figure 2.18a

Le rôle du module GT est de voir à ce que chaque transaction se termine correctement, sinon la
transaction en cause est défaite entièrement. Il prend note du début de chaque transaction et
lancera au besoin le processus de recouvrement transactionnel (en utilisant le journal interne ou
la trace transactionnelle) qui se traduit par défaire toutes les modifications effectuées par une
transaction sur la BD, sans perturber les autres transactions en cours.

Le rôle du Répartiteur Transactionnel (RT) est plus complexe; il est important pour assurer un
meilleur temps de réponse pour lʹexécution des diverses requêtes. En effet, lʹexécution de
chaque ordre SQL correspond à une séquence dʹécritures et de lectures qui peut être exécutée
intégralement pour fournir un temps de réponse qui pénalise les autres usagers, notamment
lorsque la requête en cours est longue. La figure ci-dessus illustre ce problème avec deux
transactions {r1, e1, r1,} et {r2, e2, r2}. La première correspond à une suite dʹactions sur la base de
données composée d’une lecture r1, suivie dʹune écriture e1 et qui se termine par une simple
lecture r1.

Le répartiteur a pour mission dʹintercaler les actions de lecture et dʹécriture en provenance de

différentes requêtes de manière à ce que leur exécution respective progresse en parallèle pour
fournir plus rapidement une réponse partielle aux clients. Cet entrelacement des lectures et des
écritures ne se fait pas arbitrairement. Il est créé par le répartiteur transactionnel de telle sorte
que le résultat final soit identique à celui quʹil serait si lʹexécution avait été séquentielle. Il faut

remarquer que le SGBD fournit ainsi son propre répartiteur différent de celui de lʹOS. Ce
répartiteur transactionnel (RT) permet dʹavoir une exécution multithreading plus fine des
requêtes. De plus, lʹaccès aux données doit se faire tout en préservant lʹintégrité de la base. Si les
requêtes étaient exécutées de façon séquentielle, aucun verrouillage sur les données ne serait
nécessaire, mais la performance serait médiocre. Par contre, avec lʹaction du RT, il devient
parfois essentiel dʹutiliser les verrous sur les données sous le contrôle exclusif du SGBD. Le
système dʹexploitation hôte nʹintervient pas directement, sinon pour donner le contrôle au SGBD
qui devrait normalement avoir une plus grande priorité que celle des autres processus qui
cohabitent et se concurrencent pour le même CPU.

Contenu général de la zone de mémoire partagée

L’espace global de la ZMP sert au rangement de données de la base, des métadonnées du
dictionnaire, des schémas de table et de certaines données concernant lʹexécution de chaque
ordre DML ou de chaque requête.

ZMP
pages importées pages validées journal interne reprise transactionnelle (LRT)

transactions actives (TA) liste DIRTY

liste LRU

no-trans. 5

fin
MRU m Table des pages
modifiées (TPM)

Zone partagée : Zones privées :

Schéma conceptuel, externes, interne PGA pour chaque application : P1 et P2
Packages et triggers r : page en lecture Processus P1 Processus P2
Plans dʹexécution m : page modifiée code re retour code retour

réutilisables c : page clouée

Figure 2.19

Ces diverses listes sont au cœur du fonctionnement du moteur SGBD :

a) Les pages de données de la base qui sont demandées (pages importées) par les requêtes et
obtenues par le travail de lʹAccesseur sur demande de lʹExécuteur. Au niveau de
lʹimplémentation, cette zone peut être constituée de plusieurs segments physiques dont le
contenu varie avec les activités en cours de réalisation par le SGBD. La ZMP est gérée
dynamiquement; chaque liste occupe lʹespace dont elle a besoin à un instant donné. L’espace
ZMP logique est entièrement découpé en pages, lesquelles sont enchaînées pour former
différentes listes de la ZMP. Cela est illustré sommairement par la figure 2.19 .

b) Les pages où sont rangées les entrées du journal interne comprennent les images avant (AV)
et après (AP), le numéro de transaction, lʹadresse de la donnée (rowid) et le type de transaction.

c) Les pages de métadonnées (dictionnaire) : schéma conceptuel (liste des Entitiés, des
attributs,…), schéma interne et les schémas externes.

d) Les pages de recouvrement (Rollback Segment) formant la liste LRT permettant de ranger la
valeur avant (AV) de chaque donnée modifiée par une même transaction. Ces pages
représentent une information aussi inscrite dans le journal interne (JI). Ces pages LRT
permettent de recouvrer plus rapidement une transaction particulière sur lʹordre ROLLBACK.
Le recouvrement est plus rapide avec le LRT quʹà partir du journal interne et surtout, ne
perturbe pas l’exécution des autres transactions.

e) Un espace PGA pour chaque application en cours de traitement par un processus serveur
(SP). Cet espace contient une référence à lʹordre DML source, une référence à son plan
dʹexécution dans la cache partageable et le ou les premiers tuples de la réponse et une référence
à la queue ou à la liste des tuples de la réponse constituée des tuples calculés par le module
Exécuteur. Cette zone de la ZMP permet de poursuivre lʹexécution du traitement dʹune requête
interrompue.

f) Un espace pour stocker les triggers et les packages dont les pages peuvent être au besoin
clouées dans la ZMP.

g) Un espace partagé pour ranger lʹarbre de requête source et sa version optimisée de manière à
pouvoir le partager ou le réutiliser avec dʹautres transactions.

h) Dans certains cas, les files de sortie et la file dʹentrée des réponses aux requêtes sont
implantées dans la ZMP.
i) Les pages de la table des transactions actives (TA) : avec le no de transaction et la dernière
entrée dans le JI.

Les pages rangées dans la ZMP sont insérées dans diverses listes leur conférant un statut
particulier :
• Page modifiée (m : liste LRU) : Page de la BD lue par lʹAccesseur et éventuellement modifiée
(incluant les ajouts) après leur transfert dans la ZMP. Ces pages modifiées sont validées
lorsque toutes les transactions qui ont effectué des modifications ont exécuté un COMMIT.
Elles sont non validées si au moins un COMMIT reste à faire pour confirmer un ou
plusieurs changements dans la page. Ces pages seront transférées éventuellement dans la
liste DIRTY en cours de recherche.
• Page clouée (c ) : une page de la base de données et qui est en cours dʹaccès en modification
ou en écriture.
• Page libre (∗) : une page de la base de données entièrement validée ou libérée après lecture.

En cas de besoin dʹespace dans la ZMP, les pages de la liste Dirty sont en premier transférées sur
le disque. Au besoin, les pages de la liste LRU peuvent aussi être stockées temporairement sur
disque.
Lecture dʹune page de données de la base
a) Lors du calcul dʹune réponse, lʹExécuteur accède aux pages de données pour lire les tuples.
Cette opération comprend les étapes suivantes :
b) Le serveur de processus, i.e. lʹExécuteur, cherche la page en premier dans la liste LRU et
ensuite dans la liste DIRTY de la ZMP.
c) Dès que la page est trouvée, elle est normalement enchaînée vers la partie MRU de la liste
LRU, sauf si le traitement sous-tend un balayage complet dʹune table. Dans ce cas, la page
pourrait être gardée dans sa position courante dans la liste (LRU).
d) Si la page n’est pas trouvée dans la ZMP, l’exécuteur remplace une page de la liste LRU
(partie LRU) par une autre obtenue de lʹAccesseur. Si nécessaire, une page de la liste DIRTY
sera écrite par lʹAccesseur sur disque afin de faire de la place pour ranger de nouvelles
pages. Dans le cas limite correspondant à une liste DIRTY vide et à une liste de pages
entièrement validées tout aussi vide, alors une page de la partie LRU sera placée sur disque
même si elle nʹest pas marquée r de manière à pouvoir importer la page demandée.
Modification dʹune page de données de la base
Cette opération de mise à jour dʹune donnée sous-tend les étapes suivantes :
a) Recherche de la page dans les listes LRU; en cours de recherche, transfert des pages
modifiées antérieurement et validées par toutes les transactions : de la liste LRU vers la liste
des pages DIRTY.
b) Si la page n’est pas trouvée, il y a un défaut de page. Il sʹen suit une lecture de la page
demandée sur le disque, suivie de son placement dans la liste LRU (généralement dans la
partie MRU de la liste).
c) La page importée dans la ZMP en vue dʹune modification est marquée comme étant clouée
(pinned page). Après modification, elle sera marquée modifiée jusquʹau COMMIT. Si elle
nʹest que lue, la page est marquée r pour en permettre le remplacement éventuel.
d) Si la page demandée est trouvée dans la ZMP, elle est marquée clouée en mémoire (pinned
page) et lʹaccès aux données est rendu possible. Par contre, si une page recherchée nʹest pas
trouvée dans la ZMP et que toutes les pages sont marquées clouées, lʹAccesseur évacuera
une page clouée pour la remplacer par la page demandée en provenance du disque. Cette
page exportée demeure clouée. En cas de panne, le module de recouvrement utilisera les
images AV pour défaire les modifications qui nʹont pas été validées par un COMMIT. Ces
pages clouées exportées sur disque seront au besoin importées à nouveau dans la cache, dès
lors quʹun Accesseur y réfère dans le calcul dʹune requête. Pour éviter autant que possible
cette évacuation dʹune page clouée, il faut favoriser les transactions courtes dont la fin est
marquée par lʹexécution dʹun ordre COMMIT.
Écriture de pages modifiées et validées sur disque par lʹAccesseur
Lʹécriture dʹune page de données sur disque est réalisée par lʹAccesseur lorsqu’un des
événements suivants est activé :

- Sur demande de lʹExécuteur ou lorsque la longueur de la liste DIRTY a atteint une valeur
critique (lw).
- Sur demande de lʹExécuteur, lorsque lʹespace disponible est insuffisant et introuvable dans
la ZMP.
- Sur un dépassement du temps alloué (time-out), par exemple toutes les 2 secondes, l’écriture
est demandée par l’Accesseur.
- Lors dʹun point de reprise (checkpoint), amorcé par le DBA ou par un changement de journal
externe.
- L’Accesseur peut écrire au besoin un bloc de pages de la liste des pages modifiées (DIRTY)
dans une seule opération I/O. Cette écriture en vrac (pipeline) est plus rapide que celle d’une
suite de pages exigeant une suite d’opérations consécutives. Les pages écrites en bloc doivent
avoir des numéros de page contigus
2.3 Journalisation transactionnelle
Après chaque modification dʹun tuple dans une page de la ZMP, lʹExécuteur (avec Oracle, cʹest
le Serveur de processus (SP)) écrit certaines informations dans le journal interne (JI) : le numéro
de transaction, la nature du DML, lʹadresse de la donnée sous forme dʹun rid (row identifier),
lʹheure, lʹimage avant de la donnée (AV) et lʹimage après (AP) en plus dʹautres informations
nécessaires pour gérer les listes du journal interne, notamment un numéro de séquence, JSN, qui
identifie chaque entrée dans le journal. La structure du journal des transactions est propre à
chaque SGBD. Les entrées du JI peuvent être écrites au besoin dans le JE de manière à libérer de
lʹespace dans le journal JI.
Ex. Entrée type dans le journal interne :

numéro numéro de la type de page_id offset Image Image

JSN précédent transaction transaction (no de slot) AV AP

Chaque entrée a son numéro de journal (JSN) et les entrées dʹune même transaction sont chaînées.
Figure 2.19a
Les entrées dʹune même transaction peuvent être chaînées les unes aux autres par un pointeur
arrière, le JSN_précédent. Ce pointeur permet de parcourir rapidement les entrées dʹune
transaction lorsque celle-ci fait une opération rollback transactionnelle. Le journal interne est
organisé en une liste circulaire de sorte que les entrées finissent par être réutilisées par de
nouvelles entrées après lʹatteinte de la fin de la liste. Par conséquent, les entrées du JI nʹont pas
besoin dʹêtre effacées lors dʹun COMMIT ou dʹun CHECKPOINT. A titre indicatif, voici le
contenu partiel et lisible d’un journal interne. En pratique, les entrées font l’objet d’un codage de
sorte à compacter le journal interne.

no : JSN précédent no transaction type page_id offset AV AP

1 nil Tr13 U 2 32 24 28
2 nil Tr24 U 6 34 23 9
3 2 Tr24 U 2 3 23 8
4 nil Tr2 D 8 29 4 12

page_id premier JSN compteur no trans. dernier JSN

2 1 2 Tr13 1
6 1 Tr24 3
8 4 1 Tr2 5
Table des pages modifiées (TPM) Table des transactions actives
avec compteur des modifications (TA)

Journal interne et quelques tables de contrôle du SGBD

Figure 2.19b

Chaque page modifiée par une transaction est inscrite dans la Table des Pages Modifiées (TPM)
de la figure 2.19b comportant aussi un compteur cpt qui est augmenté après chaque mise à jour.
Lors du commit de la transaction t124, les entrées du JI associées à cette transaction sont copiées
dans le JE et le compteur cpt est décrémenté. Ainsi, lorsque le compteur est à 0, cela signifie que
toutes les modifications de cette page sont validées et que la page pourrait être transférée dans
la liste DIRTY, qui est celle qui fournit en priorité les pages à évacuer en cas de manque dʹespace
dans la ZMP (Défaut de page). La table TPM comprend la première entrée du journal interne
correspondant à la modification de cette page; elle fournit le numéro de cette première
transaction dans le journal interne à partir de laquelle il faudra refaire les mises à jour en cas de
panne de système.

N.B. chaque page peut aussi avoir dans son en-tête une petite liste de numéros uniques de
transaction qui ont modifié les données de la page ou encore la dernière entrée du journal, soit le
dernier_JSN qui a modifié cette page.
Calcul dʹune réponse
LʹExécuteur chargé du calcul de la réponse a souvent à manipuler plusieurs tables de base, et
parfois autant dʹindex, pour obtenir tous les tuples de la réponse (active set ou result set). Ce
calcul peut être fait en mémoire en rangeant les tuples dans des pages temporaires allouées en
dehors de la ZMP ou encore en utilisant des fichiers de travail pour y loger les tuples
intermédiaires.

Au terme du calcul, lʹExécuteur connaît le nombre de tuples de la réponse. Il place un ou

plusieurs tuples de celle-ci (1 par défaut) dans un CURSEUR implicite créé et associé au PGA de
lʹapplication. Il peut y avoir plusieurs curseurs implicites ouverts en même temps pour une
même application. À lʹexécution dʹun ordre CLOSE, implicite ou explicite, cet espace de
rangement temporaire est libéré et le curseur associé est supprimé.

ZMP (SGA) PGA de lʹutilisateur U2

curseur C1 Pages
temporaires
pour les
tuples de la
curseur C2 réponse

Queue de
sortie
1er tuple de
la réponse

Figure 2.20

Le premier tuple est retourné immédiatement à lʹapplication, tandis que les autres sont transmis
seulement par lʹexécution dʹun ordre FETCH inséré dans lʹapplication. La queue de sortie (et
dʹentrée) est implémentée dans la ZMP, elle pourrait être constituée dʹune liste de pages
contenant les tuples de la réponse. En sortie, une entrée dans la queue est constituée dʹun
pointeur, éventuellement en indirection par lʹentremise du PGA, sur la liste des pages contenant
la réponse
Validation dʹune transaction
La validation dʹune transaction T1 est lancée par lʹordre COMMIT. Tous les changements
effectués par T1 deviennent alors visibles aux autres transactions concurrentes qui nʹont pas lu
ces tuples auparavant et qui débuteront après la validation.

Les effets d’un COMMIT sont les suivants :

a) La persistance des modifications réalisées par la transaction est assurée grâce à lʹécriture des
entrées du journal interne vers le journal externe, et cela depuis le dernier commit inscrit dans le
journal interne pour cette transaction.

b) Les données modifiées deviennent visibles pour les autres transactions qui débutent après le
temps t du Commit. Les modifications restent cependant invisibles aux transactions qui ont
débuté avant le temps du Commit (cohérence de lectures répétitives) et qui ont peut être lu les
mêmes tuples sans voir leurs modification ultérieures. Par contre, si ces mêmes tuples nʹont pas
été lus par dʹautres transactions, ils deviennent alors visibles immédiatement.
c) Le Commit termine une transaction et en débute une autre avec un numéro différent et
toujours unique. Après un Commit, il devient impossible de faire un retour arrière par un
Rollback. Les données validées sont rendues persistantes.
Journalisation et reprise
Une transaction est définie comme une unité logique de traitement sur la BD, définie par le
traitement entre deux validations. Elle doit se réaliser entièrement ou pas du tout lorsque

survient une panne ou une erreur en cours d’exécution. La panne peut être un arrêt de
lʹapplication client, la perte de lʹinstance du SGBD ou une défaillance sur un média.

Actions sur BD Entrées dans le JI Sémantique

T1 Début 13:45;T1;Début; début de T1 (V = 25)
T1: Lire X->50
T1: Ecrire X->75 13:46;T1;E;X,50,75; modification de X par T1
T2 Début 13:48;T2;Début; début de T2
T2: Lire V-> 25
T2: Ecrire V->10 13:50;T2;E;V,25,10; modification de V par T2
T1: Lire V-> 25 valeur V au début de T1
T1: Lire Z-> 35
T2: COMMIT 13:52;COMMIT; copie JI-> JE; nouvelle
(msg de confirmation) transaction T2
T1: Ecrire Z-> 10 13:53;T1;E,35,10; modification de V par T1
T2: Lire V–>10 lecture de V par T2
T2: Ecrire V->15 13 :55;T2;E,10,15; écriture de V par T2
***panne d'instance ***********
Figure 2.20a

Pour recouvrer un état stable et cohérent de la BD, il faut défaire une ou plusieurs transactions.
Lorsquʹil sʹagit de lʹexécution dʹun Rollback, la reprise transactionnelle n’implique que cette
transaction. Pour une transaction particulière non encore validée, il faut défaire toutes les
modifications quʹelle a effectuées depuis son début. Le rollback dʹune transaction peut être fait à
partir du journal interne, mais il est de préférence fait à partir des segments de rollback (liste
LRT) implémentés dans certains SGBD avec les images AV dʹune transaction. Le journal interne
fournit lʹimage avant (AV) et après (AP) des données modifiées par chaque ordre DML des
transactions. Il est donc possible de revenir en arrière avec les images avant et dʹannuler toutes
les actions effectuées par une ou plusieurs transactions non validées avant que les applications
transactionnelles soient relancées.

Dans cet exemple, il y a lecture et ensuite écriture du tuple avec un champ X modifié pour avoir
50 comme nouvelle valeur. Deux transactions (T1 et T2) sont actives au moment de la panne
générale.

Après la panne du SGBD, la reprise est lancée en défaisant les modifications des deux
transactions jusquʹà leur dernier Commit. Dans lʹexemple de la figure 2.20a toutes les
modifications effectuées par T1 seront annulées, tandis que seule la 2e transaction de T2 sera
annulée. La reprise des applications avec de nouvelles données lues après le Commit permet de
poursuivre les traitements sans perte de données et dʹéviter les incohérences dans la base.
Une autre propriété importante de la transaction est son isolement par rapport aux autres
transactions. Dès quʹune transaction T1 débute, lʹétat de la base de données à cet instant
apparaîtra à T1 comme étant invariant ou isolé par rapport aux actions des autres transactions
concurrentes. En fait, une autre transaction T2 peut lire les données modifiées par T1, mais elle
obtiendra la valeur validée au moment du début T2. En effet, le système peut toujours remettre

temporairement une donnée dans son état antérieur stable (par exemple, avec les segments de
rollback transactionnel) et cela, tant que la donnée nʹest pas validée. Après la validation, la
donnée devient visible aux autres transactions. En se comportant ainsi, le SGBD satisfait en cela
lʹisolement transactionnel des transactions.

Lʹexemple de la figure 2.20a du journal interne hypothétique dont les entrées sont celles des
deux transactions T1 et T2. Lorsque T1 effectue la lecture de V, elle obtient la valeur qui était
validée au moment du début de la transaction T1 et non pas la valeur mise à jour par T2.
Lorsque survient une panne dʹinstance suivie de la perte de la ZMP, les seules données
disponibles pour récupérer sont celles du JE. Il faut donc défaire les modifications (UNDO)
effectuées par les transactions non validées au moment de la panne, et faire en sorte, sʹil y a lieu,
que les modifications des transactions validées soient nécessairement toutes reconstituées et
écrites sur disque (REDO). Les opérations dʹinsertion et de suppression sont traitées de façon
similaire.
Procédure générale pour le recouvrement après une panne
Il y a plusieurs phases dans le recouvrement ou reprise après une panne ou un arrêt imprévu du
SGBD :
1- Le module de recouvrement fait une lecture inverse des entrées du JE (qui est généralement
un fichier séquentiel sur disque) pour faire une liste des transactions non validées TNV et une
autre TV des transactions validées. Toutes les entrées du JE sont traitées jusquʹà la première,
i.e. la plus ancienne. Sans une borne dʹarrêt spéciale, le retour sera fait jusquʹau début du
journal externe!
2- Le ROLLBACK: Avec la liste TNV, les entrées du JE sont lues de la plus récente à la plus
ancienne et cela, pour défaire avec lʹimage AV les modifications sur la base de données.
3- Le ROLL FORWARD : Avec la liste TV, le module refait en ordre chronologique les
modifications sur la base de données avec lʹimage AP. Lʹopération REDO débute avec la plus
ancienne entrée du JE.

Cette opération devient longue si le nombre dʹentrées dans le JE est très important. Pour
accélérer les recouvrements, il faudra notamment raccourcir le JE en posant une borne dʹarrêt
par lʹexécution périodique dʹun point de reprise générale (nommé CHECKPOINT) . Ce dernier
consiste à établir à un moment approprié et sur disque un état cohérent de la BD. En ce faisant,
une entrée de point de reprise générale est inscrite dans le JE et joue le rôle dʹun butoir dans le
retour arrière. La procédure de recouvrement traite les entrées du JE jusquʹau point de reprise
générale ou à proximité de celui-ci dépendant de la procédure de checkpoint utilisée. En effet, si
le checkpoint est du type synchronisé avec la ZMP, il pourrait être nécessaire de dépasser le
checkpoint général pour défaire certaines transactions actives au moment où a eu lieu
lʹopération de CHECKPOINT.
Point de sauvegarde (PS)
Il est possible pour une application de contrôler seulement la reprise de ses actions
transactionnelles, particulièrement utile avec une transaction longue, en insérant des points de
sauvegarde dans celle-ci. Un point de sauvegarde transactionnel B est généré par la clause

SAVEPOINT B. Un point de sauvegarde (PS) dʹune transaction est inscrit dans le JI et

correspond à un point de retour en arrière dʹune transaction contrôlé par lʹapplication.

SET TRANSACTION READ WRITE;

USE ROLLBACK SEGMENT rbk_seg1;
-- recouvrement transactionnel
while code = not OK
Update Empl set salaire = 20 0000
where nom = 'Gagnon';
SAVEPOINT A;
while code = not OK
Insert Into Usine set capital = capital *2;
SAVEPOINT B;
…
If Total_Cap > 100 000 then ROLLBACK TO SAVEPOINT
A; else … end if;
Commit T;

Figure 2.21
Si une transaction doit être défaite, elle pourrait lʹêtre jusquʹà un de ses points de sauvegarde ou
jusquʹau début de sa transaction. et cela, par la commande ROLLBACK TO B. Lors de cette
opération, les modifications défaites sont autant dʹactions sur la BD qui sont aussi inscrites dans
le journal interne, pour éventuellement reprendre les opérations en cas de panne qui
surviendrait durant ce retour arrière (Rollback).

L’annulation des modifications faites par une transaction (figure 2.21) ne perturbe pas le
fonctionnement des autres transactions, puisque celles-ci n’ont pas accès aux données modifiées
par la première en raison de lʹisolement des transactions. Dans plusieurs systèmes, le point de
sauvegarde est inscrit dans le JI et en plus dans une page de la liste LRT de recouvrement
propre à chaque transaction (Rollback Segment de Oracle) . Avec la commande ROLLBACK, les
tuples modifiés avant le point de sauvegarde A sont conservés verrouillés, tandis que ceux
insérés après ce point A sont annulés. Ces dernières données sont aussi déverrouillées et
deviennent dès lors visibles aux autres transactions. Les données modifiées avant le point de
sauvegarde A demeurent encore invisibles aux autres transactions. Elles sont toutefois toujours
disponibles pour la transaction en cours. Si la transaction est relativement courte, le retour en
arrière pourra être fait à partir de la liste LRT (segment de rollback). Cette opération est donc
rapide.
2.4 Procédure de checkpoint
En cas de défaillance, le système doit être capable de recouvrer un état cohérent de la base de
données et cela, après le redémarrage du SGBD. Il existe plusieurs approches de checkpoint,
chacune ayant une procédure particulière de recouvrement qui se manifeste par un arrêt plus ou
moins long des activités transactionnelles sur la BD. Nous en verrons deux : le checkpoint avec
une cohérence au regard du Commit et un autre avec une cohérence par rapport à la ZMP.

Checkpoint synchronisé avec le Commit

Cette procédure est définie pour synchroniser toutes les validations de transaction et cela afin
dʹassurer quʹau moment de la réalisation du checkpoint, aucune transaction nʹétait active et que
la base de données était reconnue comme intègre à ce moment (figure 2.22).

CHKPT

commit

T2 commit

panne
T3

temps

Figure 2.22

Les étapes sont les suivantes:

1- Après le lancement du checkpoint par le DBA, aucune nouvelle transaction ne peut démarrer.
Le système attend la fin des transactions actives.

2- Les opérations transactionnelles en cours sur la base de données se poursuivent tant quʹil y a
une transaction non validée par un COMMIT.

3- Lors du checkpoint, les entrées du JI sont copiées dans le JE et toutes les pages de données
(LRU et celles de lʹextrémité MRU) modifiées sont aussi écrites sur disque. A ce moment
toutes les pages ont été validées par un Commit puisque toutes les transactions sont validées.

4- A la fin de lʹécriture des pages modifiées par le module chargé du checkpoint, il y a

inscription dʹune entrée de checkpoint dans le JE et la procédure se termine. Les activités
transactionnelles peuvent alors reprendre.
Recouvrement avec une telle approche
La procédure de recouvrement de base permet de revenir au dernier checkpoint pour avoir un
état cohérent de la base. Ensuite, il suffit dʹappliquer la procédure de reprise.
Checkpoint cohérent avec les données de la ZMP
Ce type de checkpoint évite dʹattendre celui des transactions actives en leur interdisant
cependant, toute nouvelle opération sur la base de données pour la durée du checkpoint (figure
2.23). Lʹavantage de cette approche est dʹaffranchir le SGBD des transactions longues.

Les étapes de cette approche sont les suivantes :

1- Après le début du checkpoint lancé par le DBA, aucune autre nouvelle transaction ne peut
démarrer.

2- Les transactions actives ne sont ni arrêtées, ni en attente, mais elles ne peuvent plus
temporairement effectuer des modifications sur la base. Lʹexécution dʹune transaction est donc
interrompue momentanément.
Checkpoint
Panne

temps

Figure 2.23

3- Les entrées du journal JI sont copiées dans le JE et toutes les pages de données modifiées de la
ZMP sont aussi écrites sur disque pour en assurer la persistance.

4- À la fin du checkpoint, une entrée spéciale est faite dans le JE pour y inclure la liste des
transactions actives (TA) au début de la procédure de checkpoint.
Recouvrement
La procédure de recouvrement débute par un ROLLBACK des transactions actives (TA) suivie
par un ROLL FORWARD des transactions actives non validées. Les entrées du journal
fournissent pour chaque donnée, la valeur avant (AV) et la valeur après (AP) :

1- Le journal est lu dans le lʹordre inverse pour détecter le plus récent checkpoint et obtenir la
liste des transactions actives (TA).
2- Au cours de cette lecture à rebours des entrées du JE, les transactions validées rencontrées
sont notées dans une nouvelle liste temporaire TV.
3- Lorsque la lecture du JE atteint le CHECKPOINT, la liste TA est alors modifiée pour y enlever
les transactions validées.
4- Toutes les transactions sont défaites par un ROLLBACK. Ce retour en arrière peut aller en
amont du checkpoint et sʹarrête avec le début de la plus ancienne transaction parmi celles de
la liste TA.

5- Il faut refaire les transactions de la liste TV à partir du checkpoint et cela, en ordre

chronologique.

Voici un cas simple illustrant cette procédure de checkpoint avec cohérence des données :

Traitements Entrée dans le JI Sémantique :

T1: début 18:00;T1;D début de T1
T1: lire X -> 50
T1: écrire X-> 60 18:01;T1;E;X,50,60;
T1: Commit 18:02;T1;COMMIT; fin de T1 et JI-> JE et
TA vide
T2: début 18:03;T2;D; début de T2
T2: lire Z-> 5
T3: début 18:06;T3;D; début de T3
T3: lire G -> 20
T2: écrire Z->8 18:07;T2;E;Z,5,8;
T4: début 18:09;T4;D; début de T4
T4: lire M-> 100
CKPT <--- 18:12;CKPT; [Link]: T2, T3, T4
T3: écrire G -> 25 18:14;T3;E;G,20,25;
T3: Commit 18:15;T3;COMMIT; fin de T3 et JI -> JE
T4: lire G->25
T4: écrire G->35 18:16;T4;E;G,25,35;
** panne ** panne : T2,T4 actives

D : début CKPT : checkpoint

E : écrire TA : liste des transactions actives
S : supprimer

Les entrées du journal externe (JE) sont les suivantes :

Entrées du JE phase ROLLBACK(1) phase ROLL FORWARD(2)

18:00;t1-D TA : vide
18:01;T1;E;X,50,60;
18:02;T1;COMMIT;
18:03;T2;D;**
18:06;T3;D;** Début avec T3
18:07;T2;E;Z,5,8;** T2: défaire Z->5
18:09;T4;D;** TA - TV = ( T2, T4)
18:12;CKPT;(T2,T3,T4) TA : T2, T3, T4
18:14;T3;E;G,20,25; T3: refaire G-> 25
18:15;T3;COMMIT; TV: T3 TV : T3
(début du rollback) (début du rollback) (début du roll forward)

Pour la procédure du ROLL FORWARD, il suffit, à partir du checkpoint, de refaire les

transactions de la liste TV établie lors du rollback. Le retour en arrière est prolongé au delà du
point de reprise pour défaire ainsi la transaction active la plus ancienne au moment du
lancement du checkpoint. Cette procédure de point de reprise nʹarrête pas les traitements locaux
des applications. Si le recouvrement est fait avec un journal léger, le temps de reprise pourrait
être à peine perceptible par les utilisateurs des applications.

Avec lʹune ou lʹautre des deux procédures, une panne dʹinstance ou dʹapplication peut être
traitée sans lʹintervention du DBA. Il en sera autrement pour une panne de média comme un
disque. Dans ce cas, le DBA aura un rôle important dans la procédure de recouvrement pour
identifier la copie de sécurité à réutiliser pour reconstruire la partie de la base qui était sur le
disque en panne.

2.5 Architecture client/serveur

Lʹarchitecture client/serveur (11) est un environnement qui localise les traitements de
lʹapplication sur les données du côté des utilisateurs. Cette architecture vient donc enrichir le
fonctionnement général du SGBD en ajoutant des fonctions de traitement au niveau du client
qui travaille désormais en coopération avec les fonctionnalités du SGBD. Le serveur offre, pour
l’essentiel, les mêmes fonctionnalités que celles implémentées sur une machine centrale à savoir
le traitement et lʹexécution des ordres DML. La répartition du traitement, et éventuellement des
données, tend à maintenir la performance totale même lorsque le nombre de clients augmente.
Le point dʹinflexion dans la décroissance de la performance (figure 2.24) est reporté vers la
droite par rapport à une configuration de traitement centralisé.

Avec une approche centralisée, l’augmentation du nombre des terminaux se traduit à partir dʹun
certain point par une baisse de performance qui peut être compensée par le remplacement de la
machine par une autre plus puissante ou par une deuxième machine centrale.

Temps de réponse
architecture
architecture
centralisée
client-serveur

Avec le même CPU

Nombre dʹutilisateurs
Figure 2.24
Une deuxième machine centrale apporte cependant sa propre charge au niveau de la gestion des
processus qui annule en partie les effets escomptés au niveau de la performance générale pour
les clients. Le traitement est cependant toujours effectué au niveau de la machine centrale.
Lʹarchitecture client/serveur permet de maintenir plus facilement le niveau de performance en
dépit de lʹaugmentation de la charge générale parce que les traitements sont transférés vers les
clients. Le protocole de communication entre les machines du réseau est organisé en couches
autonomes.

Il devient donc possible de concevoir la communication simplement comme un échange entre

deux couches de même niveau. Ceci permet de masquer toute modification des couches
inférieures aux autres couches de lʹarchitecture.

Le modèle OSI favorise l’interopérabilité des systèmes en isolant les caractéristiques des diverses
technologies dans des couches spécifiques et en normalisant les interfaces entre celles-ci. Ce
modèle normalisé par l’ISO (figure 2.25) se généralise chez les constructeurs et facilite
grandement l’intégration des ressources informatiques du monde entier. Il est une des pierres
d’assise des inforoutes qui visent à mailler la planète avec des nœuds de communication
implémentés par des ordinateurs très divers et utilisant des environnements fort variés.

Une configuration en réseau relie les stations par un bus Ethernet utilisant un lien de
communication rapide. Ce lien permet des vitesses de lʹordre de 100 mégabits par seconde. Ce
type de réseau est diffusant (broadcasting) et donc fait référence à une technologie multipoint.
Chaque machine reçoit les messages, mais ne retient que ceux qui la concerne. Ce type de
configuration est conforme au modèle ISO/OSI.

Site 1 Site 2

Application (7) Application (7) Désassemblage de la structure

du message reçu

Présentation (6) Présentation (6) Encodage spécifique

Session (5) Session (5) Échange de transactions

Protocole de transport

Transport (4) Transport (4) Échange de messages ou fichiers

circuit virtuel (connecté)

Échange de paquets
Réseau (3) Réseau (3)

Liaison (2) Liaison (2) Échange de trames

Physique (1) Physique (1) Échange des impulsions

Figure 2.25
À titre de rappel, voici les fonctions générales des différentes couches du modèle OSI :
Couche physique (1)
La couche physique transmet des bits sur le canal physique de transmission conformément à un
standard reconnu (Exemples : RS-232C, RS-449). A ce niveau, la technologie utilisée prend à sa

charge la transmission des impulsions électriques ou photoniques, la gestion des pertes de

signaux et les reprises inévitables. La couche gère le protocole utilisé pour la transmission
physique des bits.
Couche liaison de données (data link) (2)
Le paquet dʹoctets reçu de la couche 3 est divisé en trames (frames). Chaque trame est complétée
par une adresse d’origine et une adresse de destination et elle est encadrée par des marqueurs
de début et de fin. Ce travail dʹétablissement de la liaison est réalisé par deux sous-couches : la
sous-couche MAC pour s’assurer, par une écoute, que le réseau est libre et, au besoin, gérer les
collisions, et la sous-couche LLC pour réguler le flux de transmission des trames et vérifier que
la réception d’une trame soit sans parasite. Au besoin, la retransmission des trames est assurée
par le LLC. En mode réception, les opérations inverses sont effectuées.
Couche réseau (3)
La couche réseau achemine les paquets obtenus par division du message reçu de la couche 4
vers un noeud du même réseau, incluant la passerelle. A lʹinverse, les trames par la couche data
link sont regroupées en paquets. Le rôle principal de cette couche est dʹétablir le routage
(routing) selon un algorithme parmi les suivants : prédéterminé, calculé, par répertoire statique,
par répertoire dynamique ou routage adapté. Dans un réseau commuté de lignes (ex. service
avec connexion), le chemin complet de la source à la destination est déterminé et figé pour toute
la session (Dans le cas dʹun incident, un nouveau chemin est établi par reconfiguration du
routage) . Cette approche connectée est souvent utilisé par les grands réseaux où le trafic justifie
la monopolisation des circuits. La couche réseau mise au point dans le réseau ARPANET ,
appelée protocole Internet (IP), utilise une approche connectée. Dans cette couche, il y a
contrôle de flux (avec lecture/écriture bloquantes).

Par contre, dans un réseau commuté non connecté et par paquet (ou datagrammes), le chemin
est déterminé pour chaque paquet de données (approche sans connexion). Le circuit virtuel est
refait à chaque transmission dʹun paquet. Cette couche prend donc à sa charge la conversion
dʹadresses et le routage entre réseaux. Dans un réseau de diffusion comme celui de lʹEthernet,
toutes les trames sont diffusées et le rôle de cette couche réseau est plutôt limité.
Couche transport (4)
La couche transport communique des messages (en provenanc de la couche 5) entre deux
nœuds en utilisant, pour les couches inférieures, la technologie propre au réseau sur lequel sont
connectées les machines source et cible. Pour ce faire, le message est divisé en paquets (packets)
qui sont réassemblés à destination par la machine réceptrice pour reconstituer le message
dʹorigine. C’est la couche TCP de ARPANET (Transport Control Protocol). Cette couche est
généralement utilisée en conjonction avec le protocole IP pour obtenir le protocole appelé
TCP/IP. Cette couche prend la relève de lʹécriture des octets dans une socket de lʹOS, pour
générer plusieurs appels de transport sur le réseau. Ces opérations sont effectuées par le logiciel
TCP/IP et sont donc masquées à lʹapplication.

Couche session (5)

La couche session gère lʹéchange intensif et bi-directionnel entre deux applications. Ce qui est
échangé est une transaction composée de données en volume plus ou moins grand selon la
nature de lʹapplication. Cʹest le cas typique des divers services aux utilisateurs, notamment la
connexion à distance (remote login), le transfert de fichier (ftp), le Telnet, le Gopher et le fureteur
du web (browser). Ces utilitaires sont développés en utilisant les procédures dʹinterface de la
couche session dont les paramètres réfèrent à la notion de transactions. Par exemple, la
transaction avec ftp est une transaction longue constituée avec les données du fichier.
Couche présentation (6)
Cette couche présente l’information transmise après transcodage approprié (Unicode vers ASCII
vers EBCDIC ou vers ISO Latin-1), suivi du déchiffrement et du décompactage des données des
transactions. La couche aura aussi un rôle important lorsque lʹusage de lʹUNICODE sera
répandu ou deviendra un standard de facto (les caractères Unicode sont codés sur 16 bits).
Couche application (7)
La couche application traite les protocoles particuliers comme la messagerie électronique, le
protocole d’échange des données de laboratoire HL-7 (12) l’échange des données commerciales
EDI et bientôt le commerce électronique. Ces protocoles définissent la structure des messages
échangés en associant une sémantique à chaque champ ou élément du message. Entre deux
stations, lʹéchange est réalisé par un circuit virtuel en ce sens quʹil sʹappuie sur les
fonctionnalités des couches inférieures.
Vue schématique du protocole IP
Par définition, un protocole désigne un ensemble bien défini de règles et de conventions pour
assurer la communication entre deux logiciels en exécution. Le protocole IP comporte une trame
universelle (couche liaison) qui est indépendante des technologies des divers réseaux.

message 1
message 2 paquet 1 Suite de bits
paquet 2 trame 1 transformée
…
trame 2 en
message i …
trame 3 impulsions
Transaction paquet j

Éclatement dʹun message lors de lʹéchange entre deux ordinateurs

Figure 2.25a

Structure dʹune trame technologique (frame)

Les données structurées échangées entre deux points identifiés du réseau au moyen du
protocole de liaison de données (data link) sont représentées par une trame contigue de bits.

Cette trame est encapsulée conformément au protocole Internet. Le schéma général de la trame
est donné ci-dessous.

en-tête de trame IPsource IP cible données de la trame Internet

Figure 2.25b
La trame technologique est transmise dʹune adresse IP source à une adresse IP cible (la
destination). Chaque adresse IP ( appartenant à une des classes A, B, C) comporte une partie
client (machine) et une partie réseau. Selon la classe de lʹadresse (identifiée par les deux
premiers bits), le nombre de bits alloués pour coder le réseau et la machine varie. Il devient
possible de représenter quelques réseaux et de nombreuses machines jusquʹau cas de figure
composé dʹun grand nombre de réseaux et dʹun petit nombre de machines.

Cette trame de données peut être transmise à travers les réseaux hétérogènes à la condition
quʹun GATEWAY puisse prendre en charge la transposition successive du format de la trame
technologique dʹorigine vers celui des destinations du réseau auquel est connecté le GATEWAY.
Chaque adresse dans une trame comporte deux parties spécifiées sur 32 bits : partie numéro du
réseau et partie numéro de machine. Par contre, si le lien se fait entre deux réseaux de même
nature, un BRIDGE ou un ROUTER (avec plus dʹintelligence) est utilisé pour acheminer les
paquets. Lorsque quʹune trame est destinée à une site au sein dʹun même réseau, la couche IP du
logiciel de télécommunication de la station demande à toutes les machines de ce réseau de faire
connaître leur adresse physique (adresse de liaison). Une fois lʹadresse physique connue et
ʹcachéeʹ par la station émettrice, le message est transmis en utilisant la trame propre au réseau
permettant ainsi de lʹacheminer directement sans autre transposition. Si un message doit être
transmis à une adresse IP hors du réseau dʹorigine, il est alors transmis en premier à sa
passerelle (gateway) qui lʹencapsule avec une trame technologique adéquate avant de lʹacheminer
à la passerelle ou au router suivant, dit de proximité.
segment réseau 1
50 ohms
réseau 2 (autre
répéteur gateway technologie)
transceiver

Router 2

machine 1
machine 2 réseau 3

Schéma général d’un réseau hétérogène

Figure 2.25c

Sur réception de la trame par la passerelle suivante, celle-ci peut détecter si le message est arrivé
au réseau de destination ou sʹil doit être relayé à une autre passerelle. Les passerelles sont de
véritables ordinateurs, donc des nœuds essentiels dans un réseau de communication à grande
vitesse. Leur vitesse est critique, notamment lorsquʹil sʹagit de réseaux ATM ou à bande large.

Présentement, les vitesses de communication courantes sont de lʹordre de 100 mégabits par
seconde. Une nouvelle technologie de Nortel-Canada (OC-192) offre des possibilités encore plus
grande, soit de lʹordre du 10 gigabits par seconde. La technologie des communications se
développe donc avec une vitesse effarante. Il est question de vitesse frôlant les Pétabits par
seconde, soit un quadrillion de bits par seconde. Avec de telles vitesses, la téléphonie et la
télévision Internet deviendront des réalités. Il ne peut pas y avoir plus de 2.5 km entre deux
points de segments différents sans faire intervenir un répétiteur. Le protocole IP est nécessaire
puisque le transfert de la machine 1 à la machine 2 est effectué à travers des réseaux de
technologie différente.
Fonctions générales du client dans lʹexploitation dʹune base de données
La station cliente a une certaine puissance de traitement qui est mise à contribution pour des
opérations locales (13 ):

a) Gestion de l’interface et du traitement local des données transmises par le serveur. La

puissance de traitement local est alors exploitée adéquatement.

b) Le client transmet chaque requête (ordre DML) au serveur pour des fins d’analyse et
d’exécution.

c) Les fonctions d’un client sont exécutées sur un ordinateur qui est différent de celui du
serveur et plus adapté aux besoins locaux tout en assurant une meilleure extensibilité de
l’architecture (scalabitlity).

2.6 SGBD ORACLE

Le SGBD Oracle a une architecture générale constituée dʹun ensemble de processus (tâches) et
de structures de données complexes gérées en mémoire. Ces ressources partagées permettent
lʹaccès concurrent aux données de la base avec une bonne performance pour le service aux
clients. La mémoire partagée utilisée par le SGBD ORACLE est représentée sommairement par
les entités SGA (System Global Area) et PGA (Program Global Area). Lʹespace PGA est utilisé par le
serveur pour y loger les données propres à lʹétat de chaque processus client en cours de
traitement. Le SGA est accessible à tous les processus de lʹinstance ORACLE. Cet espace doit
être le plus grand possible (>500Mo) et comprend plusieurs zones structurées en listes de pages :

a)La zone des pages de données et des pages temporaires pour loger les résultats intermédiaires.

b) La zone des pages du journal interne (redo log buffers).

c) La zone contenant les packages et les triggers, sous forme de code exécutable et optimisé. Un
package est chargé lors du premier appel d’une de ses procédures.

d) La zone des pages pour les données privées des applications dites PGA. Par exemple, les
constantes d’un ordre DML sont stockées dans une zone PGA privée qui est associée au curseur,
tandis que l’ordre DML source et son plan dʹexécution sont placés dans un autre espace du SGA
et dont lʹadresse est placée dans le curseur. Le curseur d’un ordre contient le nom de cet espace
dans le SGA.
Coopération entre les processus du SGBD Oracle en mode multithreading ( MTS)
Le système Oracle utilise deux catégories de processus, qualifiés respectivement d’utilisateur et
de système. La première est créée lors d’une connexion établie avec le SGBD et cela à travers un
réseau.

LGWR
Serveur de
station processus
client Dx
réseau (Accesseur)

Serveur de DBWR
Dx : processus créé pour gérer processus
(Accesseur)
les échanges avec le client.

Figure 2.30
Cette connexion est concrétisée, dans le cas dʹune configuration avec des Exécuteurs partagés,
par la création dʹun processus Dx, créé du côté du serveur et particulier à un protocole de réseau
(figure 2.30), dont le rôle est de voir aux échanges avec les clients incluant celui dʹacheminer
l’ordre DML au serveur de processus (SP). Cʹest aussi le processus Dx qui retourne la réponse à
lʹutilisateur. Ces processus Dx jouent en quelque sorte le rôle du client du côté du serveur. Si la
connexion entre le serveur de processus et le client est rompue, alors le module Dx pour ce client
devient orphelin et le module du SGBD chargé de libérer les ressources (PMON) pourra
identifier le processus orphelin et le supprimer. Normalement, la connexion reste ouverte et
active tant que l’application n’exécute pas un CLOSE (bd). Cette façon de faire est différente du
WEB dont la communication est ouverte et fermée pour chaque requête GET ou POST.

La deuxième catégorie comprend plusieurs processus qui coopèrent pour effectuer le calcul de
la réponse de la requête :DBWR, LGWR, CKPT, SMON, PMON, ARCH, Dx et LCKx. Ces
modules sont associés à un même processus Parent, soit celui correspondant au compte SYS.
Nous discuterons brièvement du rôle de chacun.
Serveur de processus (SP)
Ce serveur-logiciel est chargé de la communication avec les utilisateurs représentés au niveau
du serveur par les processus Dxxx. Cʹest essentiellement un serveur multi-threads de requêtes en
provenance des clients. Ce serveur-logiciel spécialisé est chargé de traduire l’ordre DML, de
créer l’espace curseur privé et public pour loger les tuples de la réponse, de demander la lecture
des pages de la BD au DBWR. Il a accès au SGA pour extraire les tuples et construire

graduellement la réponse. Le client communique avec le SP via un ordre FETCH pour obtenir
un ou plusieurs tuples placés au préalable dans un curseur. Généralement, la communication est
maintenue jusquʹà la fermeture explicite de la connexion par le client.
Instance du noyau du SGBD Oracle
La notion d’instance Oracle est associée aux processus du logiciel et non à la base de données.
Le couplage entre lʹinstance et la base donne lieu à un système de BD. Au démarrage du SGBD,
un espace SGA est alloué et les processus dʹarrière-plan sont lancés.

page page page ZMP

i 1+ 1 1+2

Sur requête dʹun autre module DBWR

(ex. le SP)
fichiers

Figure 2.31
Cette combinaison espace mémoire et processus, appelée instance, est identifiée par un suffixe
fourni par la variable système SID ou par le nom de la base de données rangé dans le fichier de
paramètres [Link]. Dans un environnement réparti, chaque instance doit avoir un
identificateur unique.

page page page

i i+ 1 i+2
Journal
externe no 1

LGWR

ARCH

Fichier Journal
archive externe no 2

En cas de saturation, réécriture circulaire dans le JE

Figure 2.33

Une même base de données peut être rendue accessible à plusieurs instances, mais une instance
n’a accès qu’à une seule base de données à la fois. Les techniques d’implémentation peuvent

changer selon les versions afin de tirer profit des nouvelles architectures matérielles disponibles.
Récemment, la commercialisation des serveurs multiprocesseurs a permis de mieux exploiter
lʹarchitecture multiserveur du SGBD, qui peuvent utiliser le parallélisme dans le calcul des
requêtes et offrir de meilleures performances.
Les processus du SGBD Oracle exécutés en arrière-plan constituent lʹinstance du SGBD :
DBWR (Database Writer) Ce processus effectue la lecture et lʹécriture des pages dans le SGA. Lors
dʹune recherche amorcée par le serveur de processus (SP), un premier accès au dictionnaire
fournit lʹadresse de la première page de chaque table et de chaque index disponible pour le
calcul.
A partir de ces index, lʹaccès aux pages de données est possible par la fonction INPUT(no-page).
La recherche dʹun emplacement pour lʹinsertion dʹune page de données dans le SGA par
lʹAccesseur débute par le parcours de la liste LRU sur une certaine longueur (lw) après quoi, le
DBWR évacue les pages DIRTY pour obtenir lʹespace nécessaire. La longueur de la liste à
parcourir est déterminée par un paramètre système initialisé dans le fichier [Link].
L’écriture dʹune page modifiée sur disque peut être nécessaire lorsque l’espace manque dans le
SGA. Lʹopération peut se dérouler selon une politique LRU de remplacement des pages.

Après la validation d’une transaction (par lʹordre COMMIT) les pages modifiées ne sont pas
écrites immédiatement sur disque, tandis que les entrées du journal de la transaction validée
sont transférées obligatoirement sur disque externe par le module LGWR. Lors de la création
dʹune table il est possible de spécifier que chaque page lue de la table soit plutôt placée dans la
partie LRU de la liste des pages (option CACHE de lʹordre CREATE TABLE). Ce placement
favorise les balayages séquentiels successifs dʹune même table.

Lʹécriture des pages sur disque par le DBWR est lancée sur les événements suivants :

a- Activation dʹun checkpoint par le DBA ou par le changement du journal;

b- La liste des pages modifiées présentes dans le SGA devient saturée;
c- La recherche infructueuse dʹune page disponible pour une évacuation, i.e. marquée r;
d- d-Un time-out de x sec dʹinactivité du DBWR, i.e. au terme duquel le DBWR ( ex:: x = 3 sec)
amorcera lʹécriture des pages validées.

2- Le processus de journalisation, le LGWR (Log Writer) voit à transférer les entrées du journal
interne appartement à une transaction sur le disque renfermant le journal externe (JE). Cette
écriture est faite lors de la validation d’une transaction ou si l’espace du SGA alloué au journal
interne vient à manquer. Lors dʹune validation transactionnelle, seules les entrées de celle-ci sont
écrites sur le journal externe.

3- CKPT (Checkpoint) À des intervalles réguliers ou lors de la saturation dʹun journal externe ou
lors de la bascule vers le deuxième journal externe, le contenu du SGA est écrit sur disque, ce
qui assure que les pages les plus actives (MRU) finissent par y être placées. En effet, avec une
politique LRU, ces pages MRU pourraient demeurer indéfiniment dans le SGA. Pour éviter cette

situation, le module CKPT signale au DBWR de vidanger périodiquement la liste LRU du SGA.
Lors de cette opération, une estampille est écrite dans le journal externe et dans lʹen-tête des
fichiers modifiés suite à lʹécriture des pages transférées. Le module de checkpoint permet donc
de vidanger toute la zone ZMP des données validées afin dʹobtenir une base de données
cohérente.

page page page page JI

i i+ 1 i+2 …

CKPT

fichiers fichiers

Figure 2.34

4- SMON (System Monitor) et le recouvrement transactionnel. Processus chargé de recouvrer une

instance Oracle au moment du démarrage par récupération et libération des segments (espaces)
temporaires et les ressources du système OS . Cʹest aussi le module chargé de faire la reprise
dʹune transaction avortée et cela à partir des segments de reprise (ROLLBACK SEGMENT). Lors
de périodes de faibles activités, SMON réorganise lʹespace des tablespaces en défragmentant
celui-ci pour créer des extents de plus grande taille.

5 -PMON (Process Monitor) Processus chargé de surveiller les divers autres processus (du
système et des usagers) et en cas dʹarrêt, de libérer les ressources acquises et, au besoin, les
relancer. Si une application-client est annulée, le module PMON est capable de détecter la
disparition dʹun usager (processus orphelin) via celle du processus Dxxx et dʹeffectuer un
rollback de la transaction en cours qui appartiendrait à ce client.

6- ARCH (Archiver) Processus chargé de copier le journal externe saturé vers un espace disque
d’archivage. Cʹest la seule façon de garantir la base contre toute défaillance du média du journal
externe ou dʹassurer la garde des pages du journal externe, qui seraient écrasées par la
réutilisation cyclique de lʹespace du journal externe ( JE).

7- Dx (Dispatcher) Ce processus léger est créé lors de l’établissement de la communication d’un

client avec le serveur de processus non dédié (SP). Il y aura autant de Dx que de stations
connectées. Ce processus est chargé d’acheminer les ordres DML reçus de la station vers le SP et
de retourner la réponse calculée par le serveur SP.
Journalisation et segment de recouvrement
Lorsqu’un ordre DML d’une transaction est exécuté, les modifications qu’il effectue peuvent
être d’abord placées dans un segment de rollback du SGA (image avant seulement). La

modification est aussi placée dans un journal interne (JI) qui enregistre toutes les modifications
faites par la transaction (images AV et AP) ainsi que celles des autres transactions. Si l’ordre
DML ne peut pas être complété correctement ou si lʹutilisateur effectue volontairement un
retour en arrière (Rollback), le retour en arrière se fait à partir de ces segments de reprise
(segment Rollback) piloté par le processus SMON. Cʹest ainsi que le système garantit l’atomicité
de chaque ordre DML. Ce retour est plus rapide parce que les segments de rollback dʹune
transaction ne contiennent que les modifications dʹune transaction.
Fichiers de contrôle
Lʹinstance SGBD utilise deux fichiers de contrôle pour accéder aux différents espaces de données
critiques gérés par le noyau SGBD. Au lancement, lʹinstance nʹa pas accès au dictionnaire, car
elle ne connaît pas lʹemplacement physique de la métabase (dictionnaire). Cʹest grâce aux
fichiers de contrôle que le SGBD peut connaître la localisation physique des divers fichiers,
notamment ceux du dictionnaire et des journaux de recouvrement. Tout changement aux
ressources physiques de la base de données comme lʹajout dʹun fichier, est noté dans le fichier de
contrôle par le SGBD. Ces fichiers de contrôle sont essentiels pour lancer et réussir une
opération de reprise et ils sont répliqués sur plusieurs disques et tous sont maintenus à jour
automatiquement par le SGBD.
2.7 Performance des logiciels SGBD
La mesure de la performance du traitement des transactions par un SGBD (en mode OLTP) est
complexe en raison des nombreux échanges qui interviennent entre les processus et des diverses
technologies qui sont mises en oeuvre dans lʹimplémentation dʹun tel logiciel. Avec une telle
complexité, il devient pratiquement impossible dʹévaluer la performance du logiciel par la seule
analyse des différentes techniques mises en oeuvre. Il faut faire appel aux bancs dʹessai. Ces
mesures empiriques sont significatives dans la mesure où les bancs dʹessai ont des structures
équivalentes, quʹun même protocole de test est utilisé et que lʹenvironnement matériel est
comparable.

Pour les bases de données relationnelles, le groupe Transaction Processing Performance Council
(composé de près de 40 sociétés et institutions, TPC) a élaboré un banc dʹessai connu sous le
nom de TPC-A destiné à mesurer la performance des SGBD relationnels (OLTP) capables de
fournir un rendement de lʹordre de 100 transactions par seconde (TPS). Les résultats de ces
mesures sont publiées et doivent être utilisés selon un code dʹéthique formulé par les membres
du TPC. En effet, la concurrence entre les manufacturiers de SGBD est telle que les résultats du
TPC-A peuvent devenir un argument de vente pour gagner de nouveaux marchés. Les écarts de
conduites sont dénoncés et les délinquants parfois sanctionnés par des rappels à lʹordre
(sanction en 3 étapes) et éventuellement par des pénalités financières.
Structure de la base de données du test TPC-A
La base de données est composée de 4 tables relationnelles exploitées par un grand nombre de
transactions (1000) concurrentes dont chacune comprend 3 mises à jour et une insertion. Voici la
composition de la base de données et de la transaction type utilisée pour les mesures.

Table nb tuples taille du tuple clé primaire

Compte 1 000 000 100 octets noCompte
Guichet 1000 100 octets noGuichet
Succursale 100 100 octets noSuc
Journal variable 50 octets noCompte, estampille
Figure 2.35
Transaction type
La transaction ci-dessous est exécutée sans erreur par 1000 transactions concurrentes :

/* read au guichet no-cpt, noSuc, noGuic, montant */

Set Transaction READ WRITE—début de la transaction
UPDATE Compte set solde = solde + montant
WHERE no-compte = noCpt
INSERT into Journal values
(noCpt, noGuichet, noSuc, montant, estampille
UPDATE Guichet set [Link] = [Link] + montant
UPDATE Succursale set [Link] = [Link] + montant
COMMIT
/* write 200 octets au guichet */

Les valeurs lues par les transactions ont été générées aléatoirement de sorte que la probabilité de
mise à jour dʹun tuple quelconque soit constante pour le test.
Contraintes opérationnelles
Le temps dʹun cycle (TC) est composé du temps de réponse (TR) plus le temps de réflexion de
lʹutilisateur (TU).
--- TC = TR + TU
Le TC doit être en moyenne dʹenviron 10 sec. En outre, 90% des transactions doivent avoir un
TR <= 2 sec, et le TU en moyenne égale ou plus grand que 8 sec. Voici un exemple de résultats
du banc dʹessai TPC-A pour quelques SGBD relationnel.

SGBD Matériel TPS Coût/TPS $ date

ORACLE7 Vax cluster 425 16 326 5-92
Unify 2000 Pyramid Server 468 5 971 3-92
Informix 4.1.0 IBM RISC 6000/970 110 2789 7-92
SYBASE Symmetry 2000/250 173 2770 3-92

La mesure de la performance est exprimée par le nombre de transactions par seconde (TPS) qui
traduit une puissance transactionnelle brute sans égard aux coûts du matériel. Le facteur coût
regroupe les investissements, notamment pour la machine et les disques.
Il existe une certaine relation proportionnelle entre le TPS et le ratio Coût/TPS. Lʹaugmentation
de la performance TPS entraîne celle du coût par transaction. Ainsi, un même SGBD pourrait
avoir une performance bonifiée avec un facteur Coût/TPS. Pour un même ratio coût/TPS, les
différences de rendement peuvent être dues à lʹimplémentation des fonctionnalités du SGBD ou
à la configuration matérielle utilisée.

Évolution des bancs dʹessai du TPC

Les bancs TPC-A et TPC-B ont été abandonnés en décembre 95 et remplacés par le TPC-C et
TPC-E. Le TPC-D a été développé pour mesurer la performance relative des SGBD relationnels
en mode décisionnel (Data Warehouse ou Entrepôt de données) et cela pour des tailles de base
de données différentes (scaling factor). De nouveaux paramètres sont utilisés (ex.: QphD@100GB,
Query per hour qui est calculé en utilisant une moyenne géométrique) et un nouvel ensemble de
questions et de transactions a été formulé. On peut consulter les résultats des tests en consultant
le site http: //[Link]/.

TPC-D Paramètres @100GB IBM DB2 Teradata delta

Throughput 207 217 5%
QphD 133 192 44%
prix/QphD 33 640 28 272 16%

Sommaire
L’évolution des modèles gérés par les SGBD renforce l’indépendance logique et physique des
applications et des données. L’importance grandissante des architectures client/serveur modifie
la répartition des tâches de traitement en laissant une plus grande place au site client qui pourra
maintenant mettre à profit sa capacité locale de traitement et de stockage. En dépit de ce
changement d’architecture, le rôle critique dans la gestion des données est toujours assuré par
un processeur principal appelé le serveur qui doit gérer adéquatement le multitâche
incontournable, l’entrelacement de données (multithreading) devenu essentiel, l’écoute du réseau,
synchroniser des actions sur la base de données et assurer la transmission des résultats vers le
client.

En allégeant la charge du SGBD par lʹapproche client/serveur, on obtient un gain intéressant

dans le rapport performance/prix. Toutefois, cette approche engendre de nouvelles activités à
savoir une gestion de réseau et une autre pour la base de données qui deviennent plus
importantes lorsque les clients sont distants.

Le serveur multiprocesseur augmentera la puissance nette des traitements en divisant la tâche et

en la répartissant parmi deux ou quatre processeurs. Avec de bons algorithmes de
synchronisation des traitements parallèles, des mémoires RAM et cache de taille inégalée
jusqu’ici et des disques RAID, les nouveaux serveurs s’attaquent au défi d’atteindre des
performances transactionnelles de l’ordre de plus de 800 TPS (voire même 1000 TPS). Ce niveau
de performance exigeant une fraction de l’investissement jusqu’ici nécessaire pour les machines
centrales de grande puissance. L’ère des base de données sur les grosses machines n’est pas
nécessairement terminée, mais son marché a été modifié considérablement et ramené
principalement aux bases de données de très grande taille pour des applications dont les
contraintes temporelles et la charge de traitement imposées dépassent encore de beaucoup le
potentiel des stations de travail. Lʹévolution de la technologie viendra encore certainement
modifier ces configurations.

Exercices

1- Supposez que la contrainte ci-dessous soit définie sur la base de données. Identifiez les
transactions qui se termineront toujours correctement et celles qui peuvent se terminer
incorrectement en entourant le commit dʹune transaction qui se termine correctement. Justifiez
chaque réponse pour chaque transaction. Les transactions débutent et se terminent dans lʹordre
croissant de leur numéro : T1< T2 < T3. Une transaction est exécutée entièrement avant que la
suivante débute.

La contrainte définie sur les données : 0 < X < Y. Au début la base de données est cohérente.

set transaction t1 set transaction T2 set transaction t3

lire X lire X lire X
lire Y lire Y lire Y
X=X+Y X=Y+1 Y=X+Y
update X update X update Y
Y=X+Y Y=X+1 X=X+Y
update Y update Y update X
commit commit commit

2- Complétez le journal interne ci-dessous pour lʹexécution de la transaction t4. Chaque

SAVEPOINT donne lieu à une entrée SVPT dans le JI et chaque ROLLBACK à un ou
plusieurs changements sur la BD. La valeur initiale de X est 5 et celle de Y est 7.

Transaction sur client Journal - Interne

ordre-DML AV AP
set transaction t4
lire X
lire Y
X=X+Y
SAVEPOINT S1
update X
ROLLBACK TO S1
Y=X+Y
update Y
commit

Références Chapitre 2

1 CODD, E. F., Data Models in Database Management, Proceedings Workshop on Data Abstraction,
Databases and Conceptual Modeling, ACM SIGMOD v. 11, no 2, 1981.
2 GARZOTTO, F., PAOLINI, P., SCHWABE, D., HDM: A model-based approach to hypertext
application design , ACM Transactions of Office Information System, v. 11, no 1, 1993, p. 1-26.
3 ISAKOWITZ, T., STOHR, E., BALASUBRAMANIAN, P., RMM: A Methodology for Structured
Hypermedia Design , Communications of the ACM, v. 38, no 8, 1995, p. 34-44.
4 HALASZ, F. G., SCHWARTZ, M., The DEXTER hypertext reference model, Communications of
the ACM, v. 37, no 2, 1994, p. 30-39.
5 SCHNASE, J. L., LEGGETT, J. J., HICKS, D. L., SZABO, D. L., Semantic data modeling of
hypermedia associations , ACM Transactions of Information System, v. 11, no 1, 1993, p. 27-50.
6 STOTTS, P. D., FURUTA, R., Programmable Browsing Semantics in TREILLIS, In Hypertext
ʹ89 Proceedings, ACM Press, NY, 1989, p. 27-42.
7 GAMACHE, A., Base de données réseau VAX/DBMS, Librairie des Presses de l’Université Laval,
Québec, 1993, 100 p.
8 COMER D.E., STEVENS D. L., Internet Working with TCP/IP, Client/Server Programming
and Applications, volume 3, p.53
9 GRAY, J. REUTER A., Transaction Processing : Concepts and Techniques, Morgan Kaufmann
Publishers, 1993, ISBN 1-55860-190-2
10 ULKA, R., Unix Database Management Systems, Yourdon Press, Computing Series,1990, ISBN
0-13-945593-0.
11 SMINE, Hatem, ORACLE Architecture, Administration et Optimisation, Eyrolles, 1993, ISBN 2-
212-68016.
12 HL-7, Health Level Seven, version 2.1, Chicago, Illinois, Heath Level Seven Inc, 1990.
13 MIRANDA, S., RUOLS, A., Client-serveur : concepts, moteurs SQL et architectures
parallèles, Eyrolles, 1994, ISBN 2-212-08816-7.

Vous aimerez peut-être aussi

Concepts des Bases de Données Relationnelles
Pas encore d'évaluation
Concepts des Bases de Données Relationnelles
224 pages
Introduction aux SGBD et Modèles de Données
Pas encore d'évaluation
Introduction aux SGBD et Modèles de Données
130 pages
Systèmes d'Information et Bases de Données
Pas encore d'évaluation
Systèmes d'Information et Bases de Données
60 pages
Méthodes d'analyse et DFD en modélisation
Pas encore d'évaluation
Méthodes d'analyse et DFD en modélisation
178 pages
Normalisation des bases de données expliquée
Pas encore d'évaluation
Normalisation des bases de données expliquée
45 pages
Introduction aux bases de données MySQL
Pas encore d'évaluation
Introduction aux bases de données MySQL
41 pages
Passage du MCD au MLD en SI
Pas encore d'évaluation
Passage du MCD au MLD en SI
10 pages
Introduction aux bases de données INF240
Pas encore d'évaluation
Introduction aux bases de données INF240
32 pages
Introduction aux bases de données
Pas encore d'évaluation
Introduction aux bases de données
32 pages
Comprendre le Modèle Relationnel en DB
Pas encore d'évaluation
Comprendre le Modèle Relationnel en DB
8 pages
Bases de Données Avancées et SGBD
Pas encore d'évaluation
Bases de Données Avancées et SGBD
93 pages
Modèle Relationnel : Étapes Clés
Pas encore d'évaluation
Modèle Relationnel : Étapes Clés
47 pages
Comprendre les bases de données et données
Pas encore d'évaluation
Comprendre les bases de données et données
17 pages
Use Case Global Site Web
Pas encore d'évaluation
Use Case Global Site Web
3 pages
Introduction à XML et bases de données
Pas encore d'évaluation
Introduction à XML et bases de données
53 pages
Cours 3
Pas encore d'évaluation
Cours 3
49 pages
Cours de Base de Donnees
Pas encore d'évaluation
Cours de Base de Donnees
224 pages
Dictionnaire et Modèle de Données Relationnelles
Pas encore d'évaluation
Dictionnaire et Modèle de Données Relationnelles
11 pages
Modèle logique de données et normalisation
Pas encore d'évaluation
Modèle logique de données et normalisation
46 pages
Modèle Relationnel de Données et MLD
Pas encore d'évaluation
Modèle Relationnel de Données et MLD
13 pages
Introduction aux bases de données SQL
Pas encore d'évaluation
Introduction aux bases de données SQL
31 pages
Analyse Structurée des Systèmes Logiciels
Pas encore d'évaluation
Analyse Structurée des Systèmes Logiciels
4 pages
Types de bases de données distribuées
Pas encore d'évaluation
Types de bases de données distribuées
22 pages
Modèle Relationnel des SGBD
Pas encore d'évaluation
Modèle Relationnel des SGBD
48 pages
Définition et Exemples de SGBDR
Pas encore d'évaluation
Définition et Exemples de SGBDR
69 pages
Introduction aux bases de données relationnelles
Pas encore d'évaluation
Introduction aux bases de données relationnelles
18 pages
Modèle Conceptuel des Données et DF
Pas encore d'évaluation
Modèle Conceptuel des Données et DF
1 page
Bases de données temporelles expliquées
Pas encore d'évaluation
Bases de données temporelles expliquées
39 pages
Bases de Données Relationnelles
Pas encore d'évaluation
Bases de Données Relationnelles
93 pages
Diagrammes de Cas d'Utilisation et Classes
Pas encore d'évaluation
Diagrammes de Cas d'Utilisation et Classes
4 pages
Architecture 3 niveaux ANSI/SPARC
Pas encore d'évaluation
Architecture 3 niveaux ANSI/SPARC
3 pages
Méthodes de conception de bases de données
Pas encore d'évaluation
Méthodes de conception de bases de données
41 pages
Association binaire et CIF en MLD
Pas encore d'évaluation
Association binaire et CIF en MLD
5 pages
Passerelles en BPMN : Guide Pratique
Pas encore d'évaluation
Passerelles en BPMN : Guide Pratique
23 pages
Diagramme de Bloc Interne : Guide Pratique
Pas encore d'évaluation
Diagramme de Bloc Interne : Guide Pratique
3 pages
Modèle relationnel des données expliqué
Pas encore d'évaluation
Modèle relationnel des données expliqué
19 pages
Systèmes de gestion d'ascenseurs
Pas encore d'évaluation
Systèmes de gestion d'ascenseurs
42 pages
Diagramme Relationnel et Modèle Relationnel
Pas encore d'évaluation
Diagramme Relationnel et Modèle Relationnel
37 pages
Modèle logique relationnel en base de données
Pas encore d'évaluation
Modèle logique relationnel en base de données
58 pages
Conception et Modélisation de BDD
Pas encore d'évaluation
Conception et Modélisation de BDD
22 pages
Resume BD SQL Examen-1
Pas encore d'évaluation
Resume BD SQL Examen-1
10 pages
Tutoriel sur MicroStation PDS et Modélisation
Pas encore d'évaluation
Tutoriel sur MicroStation PDS et Modélisation
16 pages
Tables SAP PM et leur utilisation
Pas encore d'évaluation
Tables SAP PM et leur utilisation
8 pages
Structure de Mémoire de Masse
Pas encore d'évaluation
Structure de Mémoire de Masse
1 page
Transactions de base en gestion technique
Pas encore d'évaluation
Transactions de base en gestion technique
4 pages
Protocole FTP : Guide et Configuration
Pas encore d'évaluation
Protocole FTP : Guide et Configuration
23 pages
Comprendre le protocole FTP en détail
Pas encore d'évaluation
Comprendre le protocole FTP en détail
26 pages
Protocole MDB : Communication Série Simplifiée
Pas encore d'évaluation
Protocole MDB : Communication Série Simplifiée
3 pages
Iut A' Paul Sabatier Dépt Informatique ASR Réseaux: Res2
Pas encore d'évaluation
Iut A' Paul Sabatier Dépt Informatique ASR Réseaux: Res2
8 pages
Configuration IP sur ATM avec PVCs
Pas encore d'évaluation
Configuration IP sur ATM avec PVCs
3 pages
Installation et configuration de VSFTPD
Pas encore d'évaluation
Installation et configuration de VSFTPD
10 pages
Protocole de Transfert de Fichiers FTP
Pas encore d'évaluation
Protocole de Transfert de Fichiers FTP
3 pages
FDDI vs Autres Technologies Réseau
Pas encore d'évaluation
FDDI vs Autres Technologies Réseau
1 page
Serveur TFTP Ftps SFTP PDF
Pas encore d'évaluation
Serveur TFTP Ftps SFTP PDF
21 pages
Guide complet sur le serveur FTP
Pas encore d'évaluation
Guide complet sur le serveur FTP
5 pages
Interfaces de Disques Durs : Types et Rôles
Pas encore d'évaluation
Interfaces de Disques Durs : Types et Rôles
62 pages
Transfert de données asynchrone expliqué
Pas encore d'évaluation
Transfert de données asynchrone expliqué
5 pages
Simulation TCP et UDP avec Packet Tracer
Pas encore d'évaluation
Simulation TCP et UDP avec Packet Tracer
6 pages
Profibus-DP : Historique et Architecture
Pas encore d'évaluation
Profibus-DP : Historique et Architecture
4 pages
Introduction aux Systèmes de Gestion de Bases de Données
Pas encore d'évaluation
Introduction aux Systèmes de Gestion de Bases de Données
166 pages
Budgétisation de la production expliquée
Pas encore d'évaluation
Budgétisation de la production expliquée
6 pages
Budgétisation des ventes en contrôle de gestion
Pas encore d'évaluation
Budgétisation des ventes en contrôle de gestion
8 pages
Définitions clés de l'économie politique
Pas encore d'évaluation
Définitions clés de l'économie politique
30 pages
Introduction au Contrôle de Gestion
Pas encore d'évaluation
Introduction au Contrôle de Gestion
5 pages
Comprendre la Taxe sur la Valeur Ajoutée
Pas encore d'évaluation
Comprendre la Taxe sur la Valeur Ajoutée
4 pages
Définition et Utilisation des MIB SNMP
Pas encore d'évaluation
Définition et Utilisation des MIB SNMP
13 pages
Flux et Enregistrements en Comptabilité
Pas encore d'évaluation
Flux et Enregistrements en Comptabilité
20 pages
Administration des Réseaux et QoS
Pas encore d'évaluation
Administration des Réseaux et QoS
17 pages
Notion de Patrimoine et Bilan en Comptabilité
Pas encore d'évaluation
Notion de Patrimoine et Bilan en Comptabilité
16 pages
SMI et ASN.1 : Guide des types SNMP
Pas encore d'évaluation
SMI et ASN.1 : Guide des types SNMP
8 pages
Proxy-agents et sondes RMON en SNMP
Pas encore d'évaluation
Proxy-agents et sondes RMON en SNMP
6 pages
Bases de la communication humaine
Pas encore d'évaluation
Bases de la communication humaine
23 pages
Concepts et versions du protocole SNMP
Pas encore d'évaluation
Concepts et versions du protocole SNMP
5 pages
Normalisation des bases de données en informatique
Pas encore d'évaluation
Normalisation des bases de données en informatique
72 pages
Analyse des Flux Financiers CAFG
Pas encore d'évaluation
Analyse des Flux Financiers CAFG
1 page
Modèles et architectures SGBD détaillés
Pas encore d'évaluation
Modèles et architectures SGBD détaillés
35 pages
Optimisation des requêtes SQL en SGBD
Pas encore d'évaluation
Optimisation des requêtes SQL en SGBD
38 pages
Normalisation des bases de données expliquée
Pas encore d'évaluation
Normalisation des bases de données expliquée
89 pages
Sécurité des Réseaux et Systèmes Informatiques
Pas encore d'évaluation
Sécurité des Réseaux et Systèmes Informatiques
140 pages
Gestion de trésorerie : enjeux et prévisions
Pas encore d'évaluation
Gestion de trésorerie : enjeux et prévisions
58 pages
Budget des approvisionnements et optimisation
Pas encore d'évaluation
Budget des approvisionnements et optimisation
4 pages
Table des quantiles de la loi normale
Pas encore d'évaluation
Table des quantiles de la loi normale
1 page
Vocabulaire Anglais des Affaires BEC
Pas encore d'évaluation
Vocabulaire Anglais des Affaires BEC
3 pages
Protocole IPv4 : Caractéristiques et Fonctionnalités
Pas encore d'évaluation
Protocole IPv4 : Caractéristiques et Fonctionnalités
41 pages
Problèmes de définition des externalités
Pas encore d'évaluation
Problèmes de définition des externalités
24 pages
Introduction à la finance et ses domaines
Pas encore d'évaluation
Introduction à la finance et ses domaines
9 pages
Guide complet pour créer une entreprise
Pas encore d'évaluation
Guide complet pour créer une entreprise
22 pages
Algorithme pour construire un graphe PERT
Pas encore d'évaluation
Algorithme pour construire un graphe PERT
10 pages
Transformation alimentaire au Québec : métiers et enjeux
Pas encore d'évaluation
Transformation alimentaire au Québec : métiers et enjeux
66 pages
Introduction au Marketing en Afrique
Pas encore d'évaluation
Introduction au Marketing en Afrique
90 pages
Entrepôt de données et systèmes décisionnels
Pas encore d'évaluation
Entrepôt de données et systèmes décisionnels
47 pages
Outils IA pour gagner du temps efficacement
Pas encore d'évaluation
Outils IA pour gagner du temps efficacement
11 pages
Configuration d'un routeur Cisco
Pas encore d'évaluation
Configuration d'un routeur Cisco
49 pages
Exposer un Web Service RESTful avec Angular
Pas encore d'évaluation
Exposer un Web Service RESTful avec Angular
41 pages
Introduction à iOS et son Architecture
Pas encore d'évaluation
Introduction à iOS et son Architecture
68 pages
Configuration du Service DHCP sous Linux
Pas encore d'évaluation
Configuration du Service DHCP sous Linux
25 pages
Introduction à Thingspeak pour IoT
Pas encore d'évaluation
Introduction à Thingspeak pour IoT
7 pages
Méthode Merise : Principes et Applications
Pas encore d'évaluation
Méthode Merise : Principes et Applications
17 pages
Application Android de gestion financière
Pas encore d'évaluation
Application Android de gestion financière
9 pages
Types de Tests en Java : Guide Complet
Pas encore d'évaluation
Types de Tests en Java : Guide Complet
6 pages
Outils et Interfaces de Développement Web
Pas encore d'évaluation
Outils et Interfaces de Développement Web
19 pages
Logiciels Open Source et Payants en SI
Pas encore d'évaluation
Logiciels Open Source et Payants en SI
4 pages
Supervision Automatisée en Industrie
Pas encore d'évaluation
Supervision Automatisée en Industrie
10 pages
Configuration OSPF sur Routeurs Cisco
Pas encore d'évaluation
Configuration OSPF sur Routeurs Cisco
8 pages
Outils de détection et surveillance réseau
Pas encore d'évaluation
Outils de détection et surveillance réseau
6 pages
Entreprise Presentation
Pas encore d'évaluation
Entreprise Presentation
14 pages
Étude de cas GBI : Systèmes d'information ERP
Pas encore d'évaluation
Étude de cas GBI : Systèmes d'information ERP
2 pages
Travail Collaboratif et Numérique
Pas encore d'évaluation
Travail Collaboratif et Numérique
137 pages
TP de Sécurité Informatique 2024-2025
100% (2)
TP de Sécurité Informatique 2024-2025
3 pages
Introduction au Data Mining
Pas encore d'évaluation
Introduction au Data Mining
17 pages
Service ToIP avec Asterisk à Béjaia
Pas encore d'évaluation
Service ToIP avec Asterisk à Béjaia
99 pages
Introduction à la programmation en C
Pas encore d'évaluation
Introduction à la programmation en C
63 pages
Bases de Données Relationnel-Objet
Pas encore d'évaluation
Bases de Données Relationnel-Objet
30 pages
Formation RH124 : Administration RHEL 9
Pas encore d'évaluation
Formation RH124 : Administration RHEL 9
4 pages
TP 1 Access
Pas encore d'évaluation
TP 1 Access
3 pages
Application de Gestion de Parc Informatique
Pas encore d'évaluation
Application de Gestion de Parc Informatique
5 pages
Sécurité et fonctionnement du DNS
Pas encore d'évaluation
Sécurité et fonctionnement du DNS
54 pages
Audit des Systèmes d'Information Comptables
Pas encore d'évaluation
Audit des Systèmes d'Information Comptables
5 pages
Audit Informatique : Méthodes et Objectifs
Pas encore d'évaluation
Audit Informatique : Méthodes et Objectifs
45 pages
Principes de la Programmation Orientée Objet
Pas encore d'évaluation
Principes de la Programmation Orientée Objet
14 pages