Ecole Suprieure de Technologie et dInformatique

Carthage
Anne Universitaire 2005-2006

Systmes de Gestion de Bases de

Donnes Rparties
&
Mcanismes de Rpartition avec Oracle

Rim Moussa
M.A. lISSATM Universit 7 Nov. Carthage
Email: Rim.Moussa@issatm.rnu.tn
URL: http://ceria.dauphine.fr/Rim/SupportBDR.pdf

Partie I: Les Bases de Donnes Rparties

Table des Matires

Partie I : Les Bases de Donnes Rparties
1. Besoins, Objectifs & Dfinitions .................................................................................... 6
1.1. Problmatique .......................................................................................................... 6
1.2. Buts de la rpartition des bases de donnes ............................................................. 6
1.3. SGBD rparti............................................................................................................ 7
1.4. Objectifs dfinis par C.J. Date ................................................................................. 7
1.5. Problmes surmonter ............................................................................................. 8
2. Conception dune base de donnes rpartie .................................................................... 8
2.1. Conception descendante (top down design)............................................................. 8
2.2. Conception ascendante (bottom up design).............................................................. 9
3. Fragmentation................................................................................................................ 10
3.1. Techniques de Fragmentation ................................................................................ 10
3.2. Dfinition des fragments ........................................................................................ 12
4. Schma dallocation ...................................................................................................... 15
5. Rplication .................................................................................................................... 16
6. Traitement & Optimisation de Requtes Rparties....................................................... 17
6.1. Mise jour de BD rparties ................................................................................... 17
6.2. Requtes sur BDs rparties .................................................................................... 18
7. Gestion des Transactions Rparties............................................................................... 24
7.1. Dfinitions.............................................................................................................. 24
7.2. Exemple de Transactions ....................................................................................... 24
7.3. Interfrences viter .............................................................................................. 25
7.4. Contrle de concurrence ........................................................................................ 27

8. Les Architectures de Systmes Parallles ..................................................................... 30

8.1. Architecture mmoire partage (ang. Shared-Memory)...................................... 30
8.2. Architecture disque partag (ang. Shared-Disk ou cluster)................................. 30
8.3. Architecture mmoire distribue (ang. Shared-Nothing) .................................... 31
8.4.

Architectures hybrides ........................................................................................... 32

Partie II : Mcanismes de Rpartition avec Oracle

9. Introduction Oracle: objets & architecture ................................................................. 34
9.1. Structures logiques de la BD.................................................................................. 35
9.2. Structures BD physiques ........................................................................................ 36
9.3. Structures de mmoire............................................................................................ 36
9.4. Processus darrire-plan ......................................................................................... 37
9.5. Etapes de traitement dun ordre SQL..................................................................... 39
10.

Oracle en rseau ..................................................................................................... 39

11.

Les liens de base de donnes.................................................................................. 40

12.

Transparence demplacement................................................................................. 41

12.1.

Vues.............................................................................................................. 41

12.2.

Synonymes ................................................................................................... 42

12.3.

Procdures .................................................................................................... 42

13.

Mise au point des requtes distribues................................................................... 43

13.1.

Collocated Inline Views ............................................................................... 43

13.2.

Optimisation base sur le calcul des cots ................................................... 43

13.3.

Statistiques ................................................................................................... 44

13.4.

Hints ............................................................................................................. 44

13.5.

Analyse du plan dexcution ........................................................................ 44

14.

Rplication des donnes ......................................................................................... 45

14.1.

Commande COPY........................................................................................ 45

14.2.

Snapshots...................................................................................................... 46

14.3.

Vues matrialises........................................................................................ 47

15.

Administration de grandes bases de donnes......................................................... 47

15.1.

Partitions....................................................................................................... 48

15.2.

Gestion de Clusters....................................................................................... 50

16.

Oracle Parallel Query............................................................................................. 51

1.

Besoins, Objectifs & Dfinitions

1.1.

Problmatique

Les pressions pour la distribution :

Il devient impratif de dcentraliser linformation (cas des multinationales),
Augmentation du volume de linformation (14 fois de 1990 2000),
Augmentation du volume des transactions (10 fois dans les 5 prochaines
annes).

Besoin de serveurs de BDs qui fournissent un bon temps de rponse sur des gros
volumes de donnes.
Prdiction daccroissement:
Vitesse des microprocesseurs : 50% par an,
Capacit des DRAM : 4 fois tous les 4 ans,
Dbit des disques : 2 fois sur les 10 dernires annes.

Goulot dtranglement sur les E/Ss.
Pour amliorer le dbit des E/Ss :
Partitionnement des donnes,
Accs parallle aux donnes,
Utiliser plusieurs nuds (avec un bon cot/ performance), et les faire
communiquer par un rseau.
Les BDRs se sont dveloppes, grce au progrs technologiques raliss au niveau de
linfrastructure rseau et des postes de travail.

1.2.

Buts de la rpartition des bases de donnes

Les bases de donnes rparties ont une architecture plus adapte lorganisation des
entreprises dcentralises.

 Plus de fiabilit : les bases de donnes rparties ont souvent des donnes
rpliques. La panne dun site nest pas trs importante pour lutilisateur, qui
sadressera autre site.
Meilleures performances : rduire le trafic sur le rseau est une possibilit
daccrotre les performances. Le but de la rpartition des donnes est de les
rapprocher de lendroit o elles sont accdes. Rpartir une base de donnes sur
plusieurs sites permet de rpartir la charge sur les processeurs et sur les entres/
sorties.
Faciliter laccroissement: laccroissement se fait par lajout de machines sur le
rseau.

1.3.

SGBD rparti

Une base de donnes centralise est gre par un seul SGBD, est stocke dans sa
totalit un emplacement physique unique et ses divers traitements sont confis une
seule et mme unit de traitement. Par opposition, une base de donnes distribue1 est
gre par plusieurs processeurs, sites ou SGBD.
Un systme de bases de donnes rparties ne doit donc en aucun cas tre confondu
avec un systme dans lequel les bases de donnes sont accessibles distance. Il ne
doit non plus tre confondu avec une multibase ou une BD fdre.
Dans une multibase, plusieurs BDs interoprent avec une application via un langage
commun et sans modle commun.
Dans une BD fdre, plusieurs BDs htrognes sont accdes comme une seule via
une vue commune.
Du point de vue organisationnel nous distinguons deux architectures :
1. Architecture Client-Serveur : les serveurs, ont pour rle de servir les clients.
Par servir, on dsigne la ralisation dune tche demande par le client.
2. Architecture Pair--Pair (Peer-to-Peer, P2P) : par ce terme on dsigne un type
de communication pour lequel toutes les machines ont une importance
quivalente.

1.4.

Objectifs dfinis par C.J. Date

Les principaux objectifs sont:

1. Transparence pour lutilisateur
2. Autonomie de chaque site

__________________
1

Ce terme gnrique englobe les BD rparties, les BD fdres et les BD parallles

3. Absence de site privilgi

4. Continuit de service
5. Transparence vis vis de la localisation des donnes
6. Transparence vis vis de la fragmentation
7. Transparence vis vis de la rplication
8. Traitement des requtes distribues
9. Indpendance vis vis du matriel
10. Indpendance vis vis du systme dexploitation
11. Indpendance vis vis du rseau
12. indpendance vis vis du SGBD

1.5.

Problmes surmonter

1. Cot : la distribution entrane des cots supplmentaires en terme de

communication, et en gestion des communications (hardware et software
installer pour grer les communications et la distribution).
2. Problme de concurrence.
3. Scurit : la scurit est un problme plus complexe dans le cas des bases de
donnes rparties que dans le cas des bases de donnes centralises.

2.

Conception
rpartie

dune

base

de

donnes

La dfinition du schma de rpartition est la partie la plus dlicate de la phase de

conception d'une BDR car il n'existe pas de mthode miracle pour trouver la solution
optimale. L'administrateur doit donc prendre des dcisions en fonction de critres
techniques et organisationnels avec pour objectif de minimiser le nombre de transferts
entre sites, les temps de transfert, le volume de donnes transfres, les temps moyens
de traitement des requtes, le nombre de copies de fragments, etc...

2.1.

Conception descendante (top down design)

On commence par dfinir un schma conceptuel global de la base de donnes rpartie,

puis on distribue sur les diffrents sites en des schmas conceptuels locaux.
8

La rpartition se fait donc en deux tapes, en premire tape la fragmentation, et en

deuxime tape lallocation de ces fragments aux sites.
Lapproche top down est intressante quand on part du nant. Si les BDs existent dj
la mthode bottom up est utilise.

2.2.

Conception ascendante (bottom up design)

Lapproche se base sur le fait que la rpartition est dj faite, mais il faut russir
intgrer les diffrentes BDs existantes en une seule BD globale. En dautres termes,
les schmas conceptuels locaux existent et il faut russir les unifier dans un schma
conceptuel global.

Utilisateurs
Schma
Externe

VE

VE
Schma Conceptuel
BDR

Schma de fragmentation

Schma dallocation

Schma Conceptuel
Local Site 1

Schma Conceptuel
Local Site 2

Schma Conceptuel
Local Site 3

Schma Interne
Site 1

Schma Interne
Site 2

Schma Interne
Site 3

Architecture dune BDR.

La rpartition d'une base de donne intervient dans les trois niveaux de son
architecture en plus de la rpartition physique des donnes :
Niveau externe: les vues sont distribues sur les sites utilisateurs.
Niveau conceptuel: le schma conceptuel des donnes est associ, par
l'intermdiaire du schma de rpartition (lui mme dcompos en un schma de
fragmentation et un schma d'allocation), aux schmas locaux qui sont rparties
sur plusieurs sites, les sites physiques.
Niveau interne: le schma interne global n'a pas d'existence relle mais fait place
des schmas internes locaux rpartis sur diffrents sites.

3.

Fragmentation

La fragmentation est le processus de dcomposition d'une base de donne en un

ensemble de sous-bases de donnes. Cette dcomposition doit tre sans perte
d'information.
La fragmentation peut tre coteuse sil existe des applications qui possdent des
besoins opposs.
Les rgles de fragmentation sont les suivantes :
1. La compltude : pour toute donne dune relation R, il existe un fragment Ri
de la relation R qui possde cette donne.
2. La reconstruction : pour toute relation dcompose en un ensemble de
fragments Ri, il existe une opration de reconstruction.

3.1.

Techniques de Fragmentation

Il existe plusieurs techniques de fragmentation, dfinies par lunit de fragmentation.

3.1.1.

Rpartition des classes d'objet

Cette technique consiste en la rpartition de classes (relation en relationnel, classe en

Orient-objet) qui peuvent tre rparties sur diffrents fragments. Toutes les
occurrences d'une mme classe appartiennent ainsi au mme fragment.



L'opration de partitionnement est la dfinition de sous-schmas.

L'opration de recomposition est la runion de sous-schmas.

Dans l'exemple suivant la base de donnes relationnelle peut tre fragmente en

{Compte, Client} et {Agence}

10

Relation Compte
No client
Agence
174723 Lausanne
177498
Genve
201639 Lausanne
201639 Lausanne
203446
Genve

Type compte
courant
courant
courant
dpt
courant

Somme
123345
34564
45102
325100
274882

Relation Agence
Agence
Lausanne
Genve

Adresse
Rue du lac, 3. 1002 Lausanne
Avenue du Mont Blanc, 21. 1200 Genve

Relation Client
No client Nom client
174723
Villard
177498
Cattell
201639
Tsellis
203446 Kowalsky

3.1.2.

Prnom
Jean
Blaise
Alan
Valdimir

Rpartition
horizontale)

Age
29
38
51
36

des

occurrences

(fragmentation

Les occurrences d'une mme classe peuvent tre rparties dans des fragments
diffrents.


L'oprateur de partitionnement est la slection ()

L'oprateur de recomposition est l'union ()

Dans l'exemple prcdent, la relation Compte peut tre fractionne en Compte1 et

Compte2 avec la fragmentation suivante
Compte1 = [TypeCompte = 'courant'] Compte
et

Compte2 = [TypeCompte = 'dpt'] Compte

La recomposition de Compte est Compte1 Compte2

3.1.3.

Rpartition des attributs (fragmentation verticale)

Toutes les valeurs des occurrences pour un mme attribut se trouvent dans le mme
fragment. Une fragmentation verticale est utile pour distribuer les parties des donnes
sur le site o chacune de ces parties est utilise.


L'oprateur de partitionnement est la projection ()

L'oprateur de recomposition est la jointure

11

Soit le partitionnement de la relation prcdente Client en deux relations :

Cli1 = [NoClient, NomClient] Client
et

Cli2 = [Noclient, Prnom, Age] Client

NoClient

NomClient

NoClient

Prnom

Age

174 723
177 498
201 639
203 446

Villard
Cattell
Tsellis
Kowalsky

174 723
177 498
201 639
203 446

Jean
Blaise
Alan
Vladimir

29
38
51
36

Relation Cli1

Relation Cli2

La relation d'origine est obtenue avec la recomposition suivante : Client = Cli1 * Cli2

3.1.4.

Rpartition des valeurs (fragmentation hybride)

C'est la combinaison des deux fragmentations prcdentes, horizontale et verticale.

Les occurrences et les attributs peuvent donc tre rpartis dans des partitions
diffrentes.
L'opration de partitionnement est une combinaison de projections et de slections.
L'opration de recomposition est une combinaison de jointures et d'unions.
La relation Client est obtenue avec : (Cli3 Cli5) * Cli4 * Cli6
Relation Cli3

[NoClient, NomClient] ([Age < 38]Client)

Relation Cli5

[NoClient, NomClient] ([Age

Relation Cli4

[NoClient, Prnom]Client

Relation Cli6

[NoClient, Age]Client

3.1.5.

38]Client)

Rpartition des Rseaux connexes d'occurrences (frag.

horizontale drive)

Dans l'exemple bancaire prcdent, on peut fragmenter les agences avec leurs clients
avec leurs comptes. On obtient alors deux rseaux d'occurrences lies. Le premier est
relatif Genve, et le deuxime est relatif Lausanne.

3.2.

Dfinition des fragments

Le principe est de baser la fragmentation sur l'ensemble des requtes d'interrogation

ou de mise jour prdfinies. Il faut extraire de ces requtes toutes les conditions de
slections, les attributs projets et les jointures. Les oprations de slection sont la

12

base des fragmentations horizontales, les oprations de projection sont la base des
fragmentations verticales.
Pour viter le risque d'mietter la base de donnes, on peut restreindre le nombre de
requtes prises en considration. On ne s'intresse alors qu'aux requtes les plus
frquentes ou les plus sensibles (celles pour lesquelles le temps de rponse maximum
est born).

3.2.1.

Dfinition des fragments horizontaux d'une classe

Soient c1, c2, ..., cn les conditions de slection qui ont t extraites des requtes.
Comme les fragments horizontaux doivent tre exclusifs, on produit l'ensemble des 2n
conjonctions de condition o chaque condition lmentaire est prise dans sa forme
positive ou dans sa forme ngative :
CC = {

Ci * ou Ci* est soit ci soit ci}.

i = 1,n

On te de cet ensemble les conjonctions de condition qui sont toujours fausses, et on

simplifie les autres.

3.2.2.

Dfinition des fragments verticaux d'une classe

Les fragments verticaux sont exclusifs, sauf en ce qui concerne le (ou les) attribut(s)
de jointure qui sont communs tous les fragments, et ce pour que la dcomposition
soit sans perte d'information.
On procde comme suit,
1. Extraire toutes les expressions de projection concernes par les requtes.
2. Ajouter chacune d'elles le(s) attribut(s) de jointure si elle ne les possde
pas.
3. Gnrer le complment de chaque expression (c'est dire les autres
attributs) en ajoutant le (ou les) attribut(s) de jointure.
L'tape suivante consiste, pour chaque fragment Fi produit par la fragmentation
horizontale, rechercher toutes les requtes qui concernent ce fragment et prendre
les expressions de projection de ces requtes.
A partir des n expressions de projection qui concernent Fi, il faut produire l'ensemble
des 2n intersections des expressions de projection.
Exercice 1
Objectif : Fragmenter la relation Compte (NoClient, Agence, TypeCompte, Somme).
Proposer un schma de fragmentation horizontale, puis verticale en tenant compte des
requtes suivantes :

13

R1 = [NoClient, Agence] ([(TypeCompte = 'courant') (Somme > 100 000)] Compte)

R2 = [Agence = 'Lausanne'] Compte
R3 = [NoClient, Somme] ([(Agence = 'Genve') (TypeCompte = 'courant')] Compte)
Exercice 2
Rmunration (Titre, salaire)
Employ (numE, nomE, Titre)
Projet (numP, nomP, budget, ville)
Affectation (numE, numP, responsabilit, dure)

1. Proposer un schma de fragmentation horizontale pour la relation

Rmunration.
2. A partir des requtes R1 et R2, proposer un schma de fragmentation
horizontale pour la relation Projet.
R1 : SELECT nomP, budget FROM Projet WHERE ville = valeur ;
R2 : SELECT * FROM projet WHERE budget < 200 000 ;
3. Fragmenter Employ selon les fragments de Rmunration.
4. Quels sont les choix de fragmentation de Affectation.

14

Exercice 3
Considrons la relation
Projet (numP, nomP, budget, ville).
Objectif : Trouver un schma de fragmentation verticale pour la relation Projet, en
tenant compte des requtes suivantes :
R1 : SELECT budget FROM projet WHERE numP = valeur;
R2: SELECT nomP, budget FROM projet;
R3: SELECT nomP FROM projet WHERE ville = valeur;
R4: SELECT SUM(budget) FROM projet WHERE ville = valeur;
1. Construire la matrice dutilisation Ut, dfinie comme suit :
Ut(Ri, Aj) = 1 ssi la requte Ri utilise lattribut Aj
Ut(Ri, Aj) = 0 sinon.
2. Construire la matrice daffinit Aff, dfinie comme suit :
Aff(Ai, Aj) = Ut(Rk, Ai)=1 et Ut(Rk, Aj)=1 sites l Ref l (Rk)* Acc l (Rk)
Ref l (Rk) est le nombre daccs aux attributs Ai et Aj pour une excution de Rk sur
le site l.
Acc l (Rk) reprsente la frquence daccs la requte Rk sur le site l.
Sachant que : Rk, site l, Ref l (Rk) = 1
Acc 1 (R1) = 15

Acc 2 (R1) = 20

Acc 3 (R1) = 10

Acc 1 (R2) = 5

Acc 2 (R2) = 0

Acc 3 (R2) = 0

Acc 1 (R3) = 25

Acc 2 (R3) = 25

Acc 3 (R3) = 25

Acc 1 (R4) = 3

Acc 2 (R4) = 0

Acc 3 (R4) = 0

3. A partir de la matrice daffinit obtenue, proposer une fragmentation verticale

pour la relation Projet.

4.

Schma dallocation

L'affectation des fragments sur les sites est dcide en fonction de l'origine prvue des
requtes qui ont servi la fragmentation. Le but est de placer les fragments sur les
sites o ils sont le plus utiliss, et ce pour minimiser les transferts de donnes entre les
sites.

15

Lallocation peut se faire avec rplication ou sans rplication. Sachant que la

rplication favorise les performances des requtes et la disponibilit des donnes,
mais est coteuse en considrant les mises jour des fragments rpliquas.
Exercice 4
Nous associons aux requtes de lexercice 1 : R1, R2 et R3 les origines suivantes :
- R1 peut tre mise de Genve ou de Lausanne,
- R2 est presque exclusivement mise de Lausanne,
- R3 est le plus souvent mise de Genve, mais peut aussi provenir de Lausanne,
- Les mises jour des comptes de Lausanne sont faites partir de Lausanne,
- Les mises jour des comptes de Genve sont faites Genve.
Sachant que, les mises jours sont secondaires par rapport aux requtes dans le sens
o elles peuvent tre effectues en diffr. L'allocation des fragments est donc base
en priorit sur les sites des requtes et en second sur les sites de mises jour.
Proposer un schma dallocation des fragments aux sites de Genve et de Lausanne.

5.

Rplication

Dans le cas o les utilisateurs nauraient pas besoin daccder aux donnes les plus
rcentes, une alternative existe pour viter le trafic quengendre laccs aux donnes
jour. Elle consiste en lutilisation de clichs (ang. snapshot). Un clich reprsente un
tat de la base de donnes un instant donn.
La pertinence d'un clich diminue donc au fur et mesure que le temps passe.
On peut en effet se passer de l'information exacte pour diverses raisons. Certaines
informations ne subissent pas souvent de modification (comme le nom de famille,
l'adresse ou le nombre d'enfants des employs) et par consquent une copie mme
ancienne de ces informations est, dans sa grande majorit, exacte.
Les deux critres qui sont prendre en compte pour dfinir l'intrt d'un clich sont
d'une part l'anciennet du clich, et d'autre part le temps d'attente qui serait ncessaire
avant d'obtenir l'information originale ( jour). Ces deux informations, l'anciennet et
le temps d'attente, peuvent tre pondres par un taux de satisfaction pour le systme
d'information.
Exemple : Dans un milieu bancaire les retraits d'argent par un client ne devraient tre
autoriss que si le compte est suffisamment approvisionn. Comme les ordres de
virement et chques mis au cours des heures coules ne sont pas encore connus et
donc non dbits, la situation relle du compte peut tre bien diffrente de l'tat
correspondant dans la base de donnes. Par consquent, la dcision d'autoriser un
retrait d'argent peut tre prise en fonction d'un clich lgrement ancien plutt que
d'accder l'information originale qui ne sera que lgrement plus fiable. Cependant,
une information exacte permettrait de contrecarrer des retraits d'argent successifs dans
deux distributeurs quelques minutes d'intervalle.
16

Exemples de Taux de satisfaction du clich par rapport l'original en fonction de l'ge

du clich :
5 minutes : 0.95

3 jours : 0.3

1 Heure : 0.9

1 semaine : 0.1

1 jour : 0.7

1 mois : 0.01

Exemples de Taux de satisfaction du temps d'attente pour obtenir l'original :

jusqu' 30 sec : 1

2 min : 0.5

45 sec : 0.9

3 min : 0.1

1 min : 0.7

5 min : 0.01

Si l'on dispose d'un clich vieux d'un jour, le temps d'attente maximum pour la
rception de l'original est dune minute. Pass ce dlai, l'information contenue dans le
clich sera utilise.

6.

Traitement & Optimisation de Requtes

Rparties

Les rgles d'excution et les mthodes d'optimisation de requtes dfinies pour un

contexte centralis sont toujours valables, mais il faut prendre en compte d'une part la
fragmentation et la rpartition des donnes sur diffrents sites et d'autre part le
problme du cot des communications entre sites pour transfrer les donnes. Le
problme de la fragmentation avec ou sans duplication concerne principalement les
mises jours tandis que le problme des cots des communications concerne surtout
les requtes.

6.1.

Mise jour de BD rparties

La principale difficult rside dans le fait qu'une mise jour dans une relation du
schma global se traduit par plusieurs mises jours dans diffrents fragments. Il faut
donc identifier les fragments concerns par l'opration de mise jour, puis
dcomposer en consquence l'opration en un ensemble d'opration de mise jour sur
ces fragments.
Insertion
Retrouver le fragment horizontal concern en utilisant les conditions qui dfinissent
les fragments horizontaux, puis insertion du tuple dans tous les fragments verticaux
correspondants.
Suppression
Rechercher le tuple dans les fragments qui sont susceptibles de contenir le tuple
concern, et supprimer les valeurs d'attribut du tuple dans tous les fragments
verticaux.
Modification

17

Rechercher les tuples, les modifier et les dplacer vers les bons fragments si
ncessaire.
Exercice 5
Dterminer les fragments (de lexercice 1) mis jour par les requtes suivantes :
1.

Cration d'un nouveau compte pour un client.

INSERT INTO compte VALUES (184 177, Genve, courant, 350 000) ;

2.

Ajout de 80 000 francs sur le compte courant d'un client.

UPDATE Compte
SET somme = somme + 80 000
WHERE NoClient = 177 498 AND TypeCompte = 'courant' ;

6.2.

Requtes sur BDs rparties

Comme pour le traitement de requtes en Bases de donnes centralises, on produit

l'arbre algbrique de la requte. Chaque feuille de l'arbre reprsente une relation, et
chaque nud reprsente une opration algbrique. On enrichit larbre avec les
informations sur la rpartition des donnes sur les diffrents sites, en particulier sur le
site o chaque opration de la requte doit tre excute.
La complexit dune requte dans une base de
fonction des facteurs suivants :

donnes rpartie est dfinie en

Entres/ Sorties sur les disques (disks I/Os), cest le cot daccs aux donnes.
Cot CPU : cest le cot des traitements de donnes pour excuter les
oprations algbriques (jointures, slections ...).
Communication sur le rseau : cest le temps ncessaire pour changer un
volume de donnes entre des sites participant lexcution dune requte.
Dans une base de donnes centralise, seuls les facteurs E/Ss et CPU dterminent la
complexit dune requte.
Notons que nous faisons la distinction entre le cot total et le temps de rponse
global dune requte:
Cot total : cest la somme de tous les temps ncessaires la ralisation dune
requte. Dans ce cot, les temps dexcution sur les diffrents sites, les accs aux
donnes et les temps de communication entre les diffrents sites qui entrent en jeu.
Temps de rponse global : cest le temps dexcution dune requte. Comme
certaines oprations peuvent tre effectues en parallle sur plusieurs sites, le
temps de rponse global est gnralement infrieur au cot total.

18

6.2.1.

Transferts de donnes

Le temps de transmission d'un message tient compte du temps d'accs et de la dure

de la transmission (volume des donnes / dbit de transmission). Le temps d'accs est
ngligeable sur un rseau local, mais peut atteindre quelques secondes pour des
transmissions sur de longues distances ou via satellite. Dans ces conditions, un
traitement ensembliste des donnes s'impose. L'unit de transfert entre sites est une
relation ou un fragment, et non une occurrence.

6.2.2.

Traitement de requtes rparties

Le but est d'affecter de manire optimale un site d'excution pour chacune des
oprations algbriques de l'arbre. Pour cela, on associe chacune des feuilles le site
sur lequel la relation va tre puise. Lorsqu'une relation est duplique, le choix du site
de dpart est un lment d'optimisation. On cherche ensuite associer chaque nud
de l'arbre le site sur lequel l'opration algbrique associe ce nud sera excute.
Gnralement, il faut faire localement tous les traitements qui peuvent y tre faits.
Ainsi, lorsque toutes les oprandes d'une mme opration algbrique sont situes sur
le mme site, la solution la moins coteuse pour excuter cette opration est le plus
souvent de l'excuter sur ce site. Ceci est notamment toujours vrai pour les oprateurs
unaires qui font diminuer le volume d'informations (slection, projection).
Pour diminuer le volume de donnes transmis d'un site un autre, il faut limiter les
transferts d'information aux seules informations utiles. Pour cela il faut
systmatiquement rajouter des projections dans l'arbre algbrique pour abandonner les
attributs inutiles. Il faut aussi noter que les parties de requtes indpendantes peuvent
tre excutes en parallle sur des sites diffrents et donc baisser le temps total
d'excution.

6.2.3.

Optimisation dynamique des requtes

Aprs avoir gnr un arbre de requte, la stratgie adopte pour l'excution est
ascendante. C'est dire que l'affectation de chaque nud de l'arbre un site peut tre
dcide en cours d'excution en fonction des diffrents volumes de donnes
intermdiaires obtenus sur les sites. On part donc des feuilles, o l'on connat les
donnes (type, volume, statistiques sur la rpartition des occurrences dans les
domaines de valeurs...) pour remonter au niveau suprieur et prendre une dcision sur
le site d'affectation de l'oprateur. Et ainsi de suite pour les niveaux suprieurs jusqu'
la racine. Il faut cependant noter que cette stratgie n'est pas optimale si elle est
effectue en aveugle.
D'une manire gnrale, il faut tenir compte des volumes de donnes de chaque
relation, et de leur composition. Il est en effet parfois intressant de tenir compte du
calcul effectu par un site avant que les autres sites se mettent travailler.

19

6.2.4.

Semi-jointure

Les BDR ont abouti la dfinition d'un nouvel oprateur, la semi-jointure, qu'il est
parfois intressant d'utiliser. Il s'agit en fait d'une double jointure : le principe est
d'effectuer deux petites jointures plutt qu'une grosse; c'est dire deux petites
transmissions de donnes plutt qu'une seule beaucoup plus volumineuse.
La semi-jointure rduit la taille des oprandes des relations. Elle permet de rduire la
taille des donnes transmettre.
Soient R1 et R2 deux relations se trouvant respectivement sur les sites S1 et S2.
But : Evaluer R1

R2 sur le site S1.

Lalgorithme de semi-jointure se droule comme suit,

S1>

temp1 R1 R2(R1)

S1>

envoi de temp1 vers S2

S2>

temp2 R2

S2>

envoi de temp2 vers S1

S1>

R1

temp1

temp2 (quivalent R1

R2)

Exercice 6
Soit la BDR compose des relations suivantes :
P (NP, NOMP, MADE_IN, COULEUR, POIDS)
U (NU, VILLEU, NOMU)
F (NF, NOMF, VILLEF, ADRESSE, PAYS, COEF)
PUF (NP, NU, NF, DATE, QUANTITE)
Ville(nom, rgion, pays, description)
Les relations U et PUF sont sur le site A.
Les relations F et P sont sur le site B.
Le rseau reliant les deux sites A et B a les caractristiques techniques suivantes :
- temps d'accs d'un site un autre : 0,5 seconde
- dbit de transmission : 9 600 bauds (soit 1 000 octets/ sec)
Un message est donc transfr en ( 0,5 + Nb-d'octets-du-message /1000) secondes.
|F| = 100 enregs, de 120 octets,
|U| = 1000 enregs de 60 octets,
|P| = 10000 enregs de 90 octets,

20

|PUF| = 1 000 000 enregs de 10 octets,

|Ville| = 200 enregs de 240 octets,
P contient 500 produits italiens.
U contient 100 usines de Lausanne.
Nbre de livraisons de produits des usines situes Lausanne : 100000.
Nbre de livraisons de produits italiens : 5000.
Les numros NU, NP et NF sont cods sur 2 octets.
Le nom de la ville sur 30 octets.
Requte1 : "Donner les numros et les noms des fournisseurs qui ont livr un produit
italien une usine situe Lausanne", qui provient du site , correspond la requte
algbrique suivante :
[VILLEU
R = [NOMF, NF] (

= "Lausanne"]U

* PUF * [MADE_IN

= "Italy"]P

* F)

Pour chacune des stratgies suivantes, dessinez larbre de la requte, et calculer le

temps de communication total.
1. Envoyer P et F sur le site A et excution de la requte sur A.
2. Envoyer U et PUF sur le site B et excution de la requte sur B.
3. Slectionner les usines de Lausanne sur A, faire la jointure avec PUF, et la
projection sur (NP, NF). Transmettre la nouvelle relation au site B pour
excution de la requte.
4. Slectionner les numros (NP) des produits italiens sur B. Transmettre ces
numros au site A en lui demandant qu'il renvoie les numros des fournisseurs
qui ont livr un de ces produits une usine de Lausanne. Le site A transmet un
ensemble de numros de fournisseurs B.
Requte2 : "on recherche sur le site A les couples (fournisseur, usine) tel que le
fournisseur habite dans la ville o se trouve l'usine".
Les 100 fournisseurs habitent dans 60 villes diffrentes.
Les 1000 usines sont rparties sur 840 villes diffrentes.
5 fournisseurs habitent dans une ville o se trouve au moins une usine
100 usines sont situes dans une ville o habitent un ou plusieurs fournisseurs
Pour chacune des stratgies suivantes, calculer le nombre doctets transfrs entre
sites
1. Si le site A envoie U B.
2. A envoie B les noms de villes d'usine, puis B renvoie les fournisseurs
retenus.
3. B transmet A les noms de ville diffrents, A lui renvoie le rsultat de la

21

(semi-)jointure entre ces villes des fournisseurs et les villes des usines. Enfin
B fait la seconde semi-jointure et envoie A les fournisseurs retenus.

6.2.5.

Autres Optimisations

Dcomposition de requte
Ce processus est commun aux bases de donnes centralises et rparties.
En premire tape, la requte est rcrite sous forme normalise. La restriction de la
requte (les prdicats qui suivent la clause WHERE) est crite sous la forme
conjonctive, cd une forme de conjonctions de disjonctions de prdicats. La requte
normalise est analyse afin de rejeter les requtes quil serait impossible de traiter,
exemple rejet pour mauvais typage des prdicats. Puis, grce aux rgles
didempotences pour les oprations logiques, les redondances sont limines.
Exercice 7
Rcrire les requtes suivantes :
(R1) SELECT *
FROM square
WHERE length* length < 10 000 ;
(R2) SELECT Title
FROM Employee
WHERE (NOT (Title = programmer) AND ((Title = programmer) OR
(Title = Elect. Eng.)) AND NOT(Title = Elect. Eng.)) OR
(Name = J.Doe);
Localisation des donnes rparties
A ce niveau, on prend en compte que le fait que les donnes sont rparties et
fragmentes. Des slections sur les fragments qui ont des restrictions contraires aux
restrictions qui ont permis de gnrer ces fragments, engendrent des relations vides.
En effet, dans le cas de jointures avec des fragments horizontaux on rencontre les
deux suivants :
1er cas:
A = A1 A2 A

B = ( A1 A2)

B = (A1

B) (A2

B)

Ceci est intressant surtout dans le cas ou B est rplique sur le site qui contient A1 et
sur le site qui contient A2.
2me cas:
A et B sont partitionnes tel que, Ai

Bj = Si i j

22

Exemple : cas des relations Employ et Dpartement partitionnes par ville

dpartement
Paralllisme intra-requtes
Utilisation de plusieurs threads, pour acclrer lexcution des requtes. Par exemple,
un site dsire faire lunion de 3 tampons recevoir de 3 sites diffrents, ncessite au
moins un thread qui rceptionne les tampons et un thread qui traite les tampons reus.
Arbre
Parmi les heuristiques prises en compte, est celle propose par J. D. Ullman. Elle
consiste en lapplication des oprateurs unaires le plutt possible afin de rduire la
taille des relations intermdiaires.
Une autre heuristique concerne la forme de larbre de la requte. On distingue deux
types darbres : les arbres linaires et les arbres broussailleux (ang. bushy trees).

R4
R3
R1

R2
Arbre linaire

R1

R2

R3

R4

Arbre broussailleux

Dans le cas de BDs rparties, lutilisation des oprateurs broussailleux permet

daugmenter le paralllisme et damliorer les temps de rponses des requtes.
Statistiques
Pour une relation R dfinie par les n attributs {A1, A2 ..., An} et fragmente en R1, R2
..., Rr les donnes statistiques sont typiquement :
1. la longueur de chaque attribut Ai, (long (Ai))
2. le nombre de valeurs distinctes pour chaque attribut Ai de chaque fragment Rj,
(card(Ai(Rj)))
3. le minimum et le maximum de valeurs pour chaque attribut ( min(Ai) et
max(Ai) )
4. la cardinalit de chaque attribut, c'est dire le nombre de valeurs uniques sur
le domaine d'un attribut ( card (dom[Ai]) )
5. la cardinalit de chaque fragment ( card(Ri) ).

23

7.

Gestion des Transactions Rparties

7.1.

Dfinitions

Une transaction est un ensemble doprations menes sur une BD,

Ces oprations peuvent tre en lecture et/ou criture,
Une opration est atomique, cest donc une unit indivisible de traitement,
Une transaction est soit valide par un commit, soit annule par un rollback,
soit interrompue par un abort,
Une transaction a une marque de dbut (Begin Of Transaction BOT), et une
marque de fin (End Of Transaction EOT).
La cohrence et la fiabilit dune transaction sont garanties par 4 proprits :
lAtomicit, la Cohrence, lIsolation, la Durabilit qui font lACIDit dune
transaction.


Atomicit : cette proprit signifie quune transaction est traite comme une
seule opration. Toutes les actions sont toutes menes bien ou aucune
dentre elles.

Cohrence : une transaction est un programme qui amne la BD dun tat

cohrent un autre tat cohrent, tel que toutes les contraintes dintgrit
restent vrifies.

Isolation : cest la proprit qui impose chaque transaction de voir la BD

cohrente. Une transaction en excution ne peut rvler ses rsultats dautres
transactions concurrentes avant deffectuer le commit.

Durabilit :cest la proprit qui garantit lorsquune transaction a effectu son

commit, le rsultat sera permanent, et ne pourra tre effac de la BD quelques
soient les pannes du systme rencontres.

7.2.

Exemple de Transactions

Cas de transfert dargent dun compte pargne vers un compte courant.

Begin Transaction TransfertCE/CC
Begin
Input(somme, numClt)
EXEC SQL

UPDATE ComptesEpargne
SET solde = solde somme

24

WHERE numClient = numClt ;

EXEC SQL

UPDATE ComptesCourant
SET solde = solde + somme
WHERE numClient = numClt ;

Output(Transfert compte pargne vers compte courant effectu )

End

7.3.

Interfrences viter

Nous distinguons deux cas dinterfrences problmatiques.



Des interfrences entre crivains, cd transactions dcriture.

Des interfrences entre lecteurs et crivains, cd transactions de lecture et

transactions dcriture.

7.3.1.

Entre crivains
Perte dopration (ang. lost update)
La mise jour faite par la 1re transaction est perdue.

Ecriture inconsistante (ang. dirty write)

25

Initialement, C le crdit dun compte est < 500. Une 1re transaction modifie
le crdit C d'un compte. Une 2me lit C dans ce nouvel tat, puis, constatant
que la provision est suffisante, modifie le dbit D du compte. Aprs annulation
de la 1re transaction, la contrainte d'intgrit D C nest plus vrifie.

7.3.2.

Entre lecteurs et crivains

Lecture inconsistante (ang. dirty read)

La 1re transaction a pour but de faire un virement entre deux comptes A et B,

qui satisfait la contrainte d'intgrit "somme A+B invariante". La deuxime
transaction lit A et B juste aprs que la 1re transaction ait dduit 1000 de A.
Elle trouve A+B diminu.
Lecture non reproductible (ang. non-repeatable read)

26

Une 1re transaction consulte les places libres dans un avion et laisse un temps
de rflexion l'utilisateur. Entre temps, une 2me transaction, qui voit les
mmes places libres, valide deux rservations. La 1re demande nouveau les
places libres: la liste est diminue alors qu'elle n'a pas encore choisi ses
rservations!
Lecture fantme (ang. phantom read)

Cas identique au prcdant mais avec libration au lieu de rservation de place

par la 2me transaction. Il n'y a pas alors de conflit proprement parler mais
seulement interrogation sur la validit de ces "apparitions fantmes".

7.4.

Contrle de concurrence

Plusieurs utilisateurs accdent simultanment la BD. Laccs concurrent permet de

partager les ressources matrielles et damliorer les performances daccs aux
donnes.

27

Le contrle de concurrence est un mcanisme du SGBD, qui contrle lexcution

simultane de transactions de manire produire les mmes rsultats quune
excution squentielle. Cette proprit est la srialisabilit. Une excution dun
ensemble de transactions est dite srialisable si elle donne pour chaque transaction
participante, le mme rsultat que lexcution en squentiel de ces mmes
transactions.

7.4.1.

Les mcanismes utiliss

Les estampilles
Les estampilles permettent dinstaller un ordre total entre les actions, et ainsi de les
srialiser. Lestampille est donc un identifiant unique des transactions qui permet en
plus de les ordonner.
>> chaque transaction est repre par un numro dordre unique dans le systme :
estampille. Lestampille est le couple (valeur compteur : horloge locale, numro du
site).
Linconvnient majeur est la difficult de synchroniser des sites de diffrentes
horloges.
Verrouillage
La technique la plus rpandue pour srialiser les transactions est base sur lutilisation
de verrous. On impose que laccs aux donnes se fasse de manire mutuellement
exclusive.

7.4.2.

Interblocages

Toute mthode base sur le verrouillage peut donner des interblocages lorsque deux
transactions s'entre-attendent. Pour illustrer ce cas, on peut prendre un exemple. Une
transaction Ti dtient un verrou en lecture ou en criture sur la donne x. Une
transaction Tj dtient un verrou en lecture ou en criture sur la donne y. La
transaction Ti attend un verrou en criture sur la donne y et la transaction Tj attend un
verrou en criture sur la donne x. Il y a dans ce cas un interblocage.
Un outil de grande utilit dans l'analyse des interblocages est le graphe des attentes.
Les noeuds du graphe des attentes sont des transactions simultanes et les arcs
orients qui les relient reprsentent l'attente d'une transaction pour une autre. Grce
cette reprsentation, il est facile de caractriser les interblocages : ce sont les cycles
sur le graphe. Dans un environnement rparti, les interblocages peuvent mettre en jeu
diffrents sites. Le graphe des attentes local est donc insuffisant et il faut galement
en maintenir un au niveau global.

28

T1

T2

T1

T2

T1

T5
T3

T4

T5

T3

Graphe Attente Local

au Site 1

T2

T3

Graphe Attente Local

au Site 2

T4

Graphe Attente
Global

La solution est dannuler des transactions concurrentes jusqu' suppression de cycles,

et de les reprendre plus tard.

7.4.3.

Protocole de validation deux phases

Une transaction globale est valide ssi toutes les transactions locales qui la composent
valident. En effet, si au moins une transaction locale ne valide pas, toutes les
transactions sont annules.
Le protocole exige un site coordinateur et des sites participants. Il se compose de
deux phases :
Phase de prparation : le coordinateur demande chaque participant de se
prparer pour valider la transaction locale.
Phase de validation : le coordinateur ordonne tous les participants de valider
ou dannuler leur transaction. La dcision est prise par le coordinateur tenant
compte de la rponse de chaque participant.
Coordinateur

Site1

er
prpar

Site2

prpa
re

Site1

Coordinateur
er
prpar

prpa

r er

prt

prt

rejete

p r t
r
valide

Site2

valide

rejeter

Les transactions distribues prsentent deux avantages : (i) les donnes situes sur
dautres serveurs, peuvent tre mises jour, et les instructions UPDATE peuvent tre

29

gres comme tant une seule unit. (ii) utilisation du 2-PC

lutilisateur.

8.

transparente

Les Architectures de Systmes Parallles

Dans ce qui suit, trois architectures parallles, dfinies selon le critre de partage de
ressources, et une architecture hybride sont prsentes.

8.1.

Architecture mmoire partage (ang. SharedMemory)

Les disques et les mmoires centrales sont partags par les processeurs du systme.
(+) Lespace dadressage global rend le systme facile implanter pour les vendeurs
de SGBDs. La communication inter-processeurs est rapide, vu laccs partag aux
mmoires centrales.
(+) Equilibre de charge entre les processeurs facile raliser.
Lchec dun processeur nentrane pas la non-possibilit daccs donnes.
(-) Cot du systme.
(-) Accs conflictuels aux mmoires centrales peuvent dgrader les performances.
(-) Le nombre de processeurs est limit 20-30, un nombre suprieur cre des goulots
dtranglements.
(-) Architecture non scalable.
Exemples de SGBD // : XPRS (U. de berkeley), DBS3 (Bull).

CPU

8.2.

CPU

CPU

CPU

Architecture disque partag (ang. Shared-Disk

ou cluster)

Chaque processeur a sa mmoire centrale prive, mais les disques sont partags par
tous les processeurs du systme.

30

(+) Equilibre de charge facile raliser.

(+) Lchec dun processeur nentrane pas la non-disponibilit des donnes.
(-) Linconvnient majeur est li la complexit du maintien de la cohrence des
caches des processeurs.
(-) Laccs aux disques peut crer un goulot dtranglement, du la limite de la
capacit du bus.

CPU

CPU

CPU

CPU

Exemples : IMS/VS (IBM), VAX DBMS (DEC)

8.3.

Architecture mmoire distribue (ang. SharedNothing)

Chaque processeur a sa propre mmoire centrale et disque.

(+) Cot abordable, vu que le systme est une collection de PCs.
(-) La haute disponibilit pose un problme. En effet, lchec dun processeur rend
laccs aux donnes impossible. Do la ncessit de techniques de haute disponibilit
(redondance ou duplication). Ceci fait merger un autre problme de maintien de la
consistance des miroirs ou des disques de redondance.
(-) Problme dquilibre de charge d au placement pr-dtermin des donnes.
(-) Cot de transfert sur le rseau de grand volume de donnes, tant le rsultat dune
requte .
Exemples : GAMMA (U. de Wisconsic), BUBBA (MCC),

31

CPU
M

8.4.

CPU

CPU
M

Architectures hybrides

Une architecture hybride deux niveaux, peut tre au niveau interne une architecture
mmoire partage, et au niveau externe une architecture mmoire distribue. De
telles architectures combinent les avantages de chaque architecture, et compensent les
inconvnients respectifs des architectures.
Larchitecture hybride illustre ci-dessous combine lquilibrage de la charge des
architectures mmoire partage et lextensibilit des architectures mmoire
distribue.

CPU

CPU

CPU

CPU

D
D

CPU

CPU

CPU

CPU

Les techniques de distribution des donnes sont au nombre de 3 : par intervalle,

hachage, donneur de carte (ang. round robin).

32

Partie II : Mcanismes de Rpartition

dans Oracle8i

33

9.

Introduction Oracle: objets & architecture

Architecture dOracle
Chaque fois quune BD est lance sur un serveur (ang. instance start up), une partie
de la mmoire centrale dite SGA : System Global Area, est alloue ; et plusieurs
processus darrire-plan sont lancs. Une instance de BD est un ensemble de
structures de mmoire et de processus darrire-plan qui accdent un ensemble de
fichiers de donnes. Dans Parallel Server plusieurs instances peuvent accder la
mme BD.
Les paramtres dinitialisation dune instance sont dans init.ora. Le nom du fichier
inclut en gnral le nom de linstance, si celle-ci est X, le fichier aura pour nom
initX.ora.
Gestion des donnes : table, index, view, materialized view, snapshot
Stockage physique: cluster, tablespace,
Stockage dinstructions : procedure, trigger,
Gestion dutilisateurs: profile, user,

34

9.1.

Structures logiques de la BD

Tablespace : Cest une division logique dune BD. Chaque BD possde au

moins un tablespace appel SYSTEM. La vue USER_TABLESPACES dtaille les
tablespaces existants.

Segments : les segments sont des structures logiques de stockage des donnes
physiques de la base, ils sont assigns des tablespace. Il en existe quatre types :
les segments de donnes, les segments dindex, les segments temporaires, et les
segments de rollback. Les segments dindex, par exemple, stockent les donnes
associes des index. Afin de maintenir la cohrence en lecture entre plusieurs
utilisateurs de BDs, et de pouvoir annuler des transactions, Oracle dispose dun
mcanisme appel segments de rollback. Ces segments servent reconstruire une
image des donnes antrieure leur modification dans le cas de transactions non
valides par un commit. Un segment est constitu de structures appeles extents.

Extent : un extent consiste dune squence de blocs de donnes contigus.
Quand la taille dun objet BD augmente, un extent de plus est allou pour lobjet.

Bloc de donnes: Un bloc dtermine le niveau de granularit le plus fin o les
donnes sont sauves. Un bloc de donnes correspond un nombre spcifique
doctets despace BD physique sur disque.
Les vues USER_SEGMENTS et USER_EXTENTS renseignent sur le nombre de blocs
de donnes allous par objet BD, et le nombre de libres.
Exemple:
SELECT TABLESPACE_NAME, EXTENTS, BLOCKS
FROM USER_SEGMENTS
WHERE SEGMENT_NAME = CLIENT;

Pour les objets BD (table, index, cluster), qui requirent leur propre espace de
stockage, un segment dans le tablespace leur est allou. ORACLE permet de
configurer les paramtres de stockage en utilisant la clause STORAGE.
CREATE TABLE Produit
(
NumProd NUMBER(2)
.)
STORAGE (
INITIAL
MINEXTENTS
50) ;

1M
1

NEXT
MAXEXTENTS 20

400K
PCTINCREASE

INITIAL et NEXT spcifient la taille en octet resp. du 1er et du 2me extent, par dfaut

ont la taille de cinq blocs. La taille dun bloc db_block_size figure dans le fichier
init.ora.

MINEXTENTS spcifie le nombre initial dextensions alloues la cration du

segment, la valeur par dfaut est gale 1.

35

MAXEXTENTS spcifie le nombre maximum dextensions possibles pour le segment

de donnes possible de la table. La clause UNLIMITED annule la valeur de
MAXEXTENTS.
PCTINCREASE dfinit un pourcentage p dont la valeur par dfaut est 50, qui signifie

que chaque nouvelle extension est 1,5 fois plus grande que la prcdente. La
croissance est faite partir du 2me segment.
Pour la table Produit, la taille du 1er extent est 1M, le 2me : 400K, le 3me : 600K, le
4me : 900K etc.
La clause STORAGE dfinit les paramtres de stockage niveau extent. Dautres
paramtres : PCTFREE et PCTUSED, oprent niveau bloc.
PCTFREE : est le pourcentage de lespace libre rserv dans chaque bloc pour les

modifications ultrieures. la valeur par dfaut est gale 10.

PCTUSED : est le pourcentage minimum de remplissage qui est maintenu dans chaque
bloc. la valeur par dfaut est gale 40.

9.2.

Structures BD physiques

Il existe 4 types de fichiers :

Fichiers de donnes : (ang. datafiles) un tablespace est constitu dun ou

plusieurs fichiers de donnes stocks sur disque. Un fichier appartient un
seul tablespace, et une fois quun fichier a t ajout un tablespace, il ne
peut plus en tre retir ni tre associ un autre tablespace.

Fichiers Redo-log : Oracle consigne toutes les transactions de la base dans les
fichiers du journal de reprise. Ces fichiers sont utiliss pour rtablir les
transactions dans lordre appropri en cas de dfaillance de la base.

Fichiers de contrle : larchitecture physique de la base est maintenue au

moyen de ses fichiers de contrle. Ceux-ci enregistrent des informations de
contrle relatives tous les fichiers de la base. Ils garantissent la cohrence
interne et guident les oprations de rcupration.

Fichiers trace et journal dalerte : chaque processus darrire-plan qui

sexcute dans une instance possde un fichier trace associ, qui contient des
informations sur les vnements importants, et les erreurs internes quil
rencontre. En plus des fichiers trace, Oracle maintient un journal dalertes,
qui consigne les messages derreurs, les exceptions et les oprations
administratives.

9.3.

Structures de mmoire

36

Lensemble des structures de mmoire permet damliorer les performances de la BD

en limitant le nombre doprations dE/Ss excutes sur les fichiers de donnes.
La zone SGA, regroupe un ensemble de structures de mmoire partages qui
contiennent les donnes et les informations de contrle concernant une instance
Oracle. Lorsque plusieurs utilisateurs sont connects la mme instance, les donnes
de cette zone sont partages entre eux.

Le cache de tampons de blocs de donnes : (ang. data block buffer cache), ce
cache contient une copie des blocs de donnes lus partir des segments de donnes
de la base, tels que ceux de tables, dindex et de clusters. Le paramtre
DB_BLOCK_BUFFERS, contenu dans le fichier init.ora, indique la taille du cache
en nombre de blocs de donnes. La cache reprsente 1 2% de la taille de la base.
Oracle gre lespace disponible par lalgorithme LRU : Least recently Used.

Le tampon du journal de reprise : (ang. redo log buffer), les fichiers de journal
de reprise dcrivent les modifications apportes la BD. Avant dtre enregistres
dans les fichiers redo log, les transactions sont dabord places dans la zone SGA :
tampon redo log. La base enregistre rgulirement par lots dans les fichiers redo
log. La taille de ce tampon est dfinie au moyen du paramtre LOG_BUFFER du
fichier init.ora.

Le cache du dictionnaire : (ang. dictionary cache), les tables du dictionnaire
contiennent les noms des fichiers de donnes, les noms de segments, les
emplacements des extents, les descriptions de table et les privilges. Lorsque la
base a besoin dun de ce type dinformation, elle lit les tables du dictionnaire, et
place les donnes extraites dans le cache du dictionnaire de la zone SGA. Ce cache
est gr au moyen dun algorithme LRU, il fait partie de la zone SQL partage,
dont la taille est dfinie laide du paramtre SHARED_POOL_SIZE du fichier
init.ora.

Le pool partag : (ang. shared pool), est la partie du SGA utilise par tous les
utilisateurs. Il contient le cache du dictionnaire et le cache de bibliothques (ang.
library cache). Ce dernier, maintient des informations sur les instructions
excutes dans la BD. Ce pool contient la reprsentation analyse (parse tree) et le
plan dexcution et des instructions SQL qui ont t excutes. La deuxime fois
quune instruction SQL identique est mise, les informations analyses du pool
sont exploites pour acclrer son excution. Ce pool est gr au moyen dun
algorithme LRU. La taille du pool est dfinie laide du paramtre
SHARED_POOL_SIZE du fichier init.ora, et est exprime en octets.

9.4.

Processus darrire-plan

La relation entre les structures physiques et les structures de mmoire est maintenue,
et mise en uvre au moyen de processus darrire-plan (ang. background processes).
Ces processus sont ddis une instance. Chaque processus darrire-plan cre un
fichier trace, qui est maintenu pendant la dure dactivit de linstance, dans lequel
sont consigns les vnements majeurs et les erreurs internes quil rencontre.
Dans ce qui suit, on dcrit titre non exhaustif les principaux processus:

37


SMON System Monitor: le processus entreprend une rcupration aprs un

crash. Il nettoie la BD des transactions avortes et les objets impliques, et de la
coalition des extents libres contigus afin davoir des extents larges.

PMON Process Monitor: le processus soccupe de la rcupration de
processus utilisateurs dfaillants. Il libre galement le cache de blocs de donnes
ainsi que les ressources qui taient exploites par lutilisateur.

DBWr Database Writer: le processus dcriture gre le contenu du cache de
blocs de donnes et le cache du dictionnaire en ralisant des oprations dcriture
par lots des blocs de donnes modifis de la zone SGA vers les fichiers de
donnes. Alors quil nexiste quun seul processus SMON ou PMON par instance,
plusieurs processus DBWr peuvent sexcuter. Pour limiter les risques de
contentions, le paramtre DB_WRITER_PROCESSES du fichier init.ora dfinit le
nombre de processus.

LGWR Log Writer: le processus dcriture dans le journal de reprise LGWR
gre lcriture par lots des entres du tampon redo log dans les fichiers redo log.
Ce tampon maintient ltat le plus jour de la base.

CKPT Checkpoint: le processus de contrle CKPT provoque lexcution de
DWRn. Ce dernier dcrit tous les blocs de donnes qui ont t modifis depuis le
dernier point de contrle dans les fichiers de donnes, puis met jour les en-ttes
de ces fichiers. Le paramtre LOG_CHECK_POINT_INTERVAL du fichier init.ora
de linstance dfinit la frquence des points de contrle.

ARCh Archiver: Le processus LGWR crit dans les fichiers redo log. A chaque
fois quun fichier devient plein, il crit dans le suivant, et une fois le dernier fichier
rempli, il crase le contenu du premier. Il est possible de lancer une instance BD en
mode archive-log. Dans ce cas, le processus ARCh copie les fichiers redo-log,
avant que les entres soient crases par le LGWR. Ainsi, il est possible de
restaurer le contenu de la BD une fois que le mode archive lanc.

RECO Recoverer: le processus de rcupration RECO rsout les dfaillances
dans les configurations de bases de donnes distribues, et ce, en tentant daccder
aux bases impliques dans des transactions distribues douteuses. Ce processus est
dfini dans la plate-forme qui supporte loption Distributed, tel que le paramtre
DISTRIBUTED_TRANSACTIONS du fichier init.ora est dfini avec une valeur non
nulle.

SNPn Job Queue: Les processus de file de tches SNPn sactivent
rgulirement.
Ils
actualisent
les
snapshots.
Le
paramtre
JOB_QUEUE_PROCESSES du fichier init.ora dfinit le nombre de processus.

USER : le processus communique avec dautres processus lancs par les
programmes application, tel que SQL*Plus. Le processus USER est alors
responsable de lenvoi des requtes au SGA, a inclut la lecture des blocs des
donnes.

38

9.5.

Etapes de traitement dun ordre SQL

Supposons quun utilisateur, travaillant sur SQL*Plus, mette une requte de mise
jour sur la table T, et que plusieurs tuples sont affects par la requte. La requte est
passe au serveur par le processus USER. Le serveur (exactement le query processor)
vrifie si la requte existe dj dans le cache de bibliothques. Si non trouve, elle est
analyse, vrifier pr au cache du dictionnaire les privilges et les attributs etc..,
gnrer un plan dexcution. La reprsentation analyse et le plan dexcution sont
alors sauvs dans le cache de bibliothques.
Pour les objets affects par la table T, on vrifie si les blocs de donnes sont dans le
cache de tampons de blocs de donnes . Si non trouvs, le processus USER, les met
dans le cache de tampons de blocs de donnes.
Avant que la mise jour des tuples soit faite, limage avant des tuples est crite sur
les segments de rollback par le processus DBWr.
Pendant que le tampon redo-log est rempli durant la modification des blocs de mise
jour, le processus LGWR crit le contenu du tampon redo-log dans les fichiers redolog.
Aprs la fin de mise jour, lutilisateur valide la mise jour par un commit.
Tant quun commit na pas t excut, les modifications peuvent tre annules par un
rollback. Dans ce cas, les blocs de donnes mis jour dans le tampon BD sont crass
par les blocs originaux sauvs dans les segments de rollback.
Si lutilisateur excute un commit, lespace allou pour les blocs dans les segments de
rollback est dsallou, et peut tre utilis par dautres transactions.

10.

Oracle en rseau

* Oracle Net services fournit des solutions de connectivit dans des environnements
distribus. Il est compos de:
1.

Oracle Net

2.

Modules dcoute/listeners
le fichier de configuration LISTENER.ORA contient :
son nom, par dfaut LISTENER
son adresse (HOST et PORT) : (ADDRESS = (PROTOCOL = TCP) (HOST
= localhost) (PORT = 1521)
lesSIDs (Service ID) des BD guettes

3.

Oracle Connection Manager

4.
Outils de configuration et de gestion : Oracle Net Configuration Assistant,
Oracle Net Manager.
* Transparent Network Substrate (TNS) est une sous-couche dOracle Net qui reoit
les requtes et met des ouvertures ou fermetures de session, envoie les requtes et
reoit des rponses.

39

* Lorsque les htes qui supportent les bases de donnes Oracle sont connects via un
rseau, les bases peuvent communiquer via Net8 dOracle (prcdemment appel
SQL*Net). Les pilotes de Net8 sappuient sur le protocole de communication local
pour fournir la connectivit entre deux serveurs.
Afin que Net8 reoive et traite les communications, lhte doit excuter un processus
appel listener : module dcoute sur un port de communication spcifique.
* Passerelle transparente (ang. Oracle Transparent Gateway) Cest la possibilit
daccder des objets non Oracle. La passerelle est excute sur lhte source qui
contient la base exploiter.
* Identification des Objets
Dans une BD centralise, la combinaison du nom du propritaire dun objet et du
nom de lobjet permet de lidentifier de faon unique. Dans les BDR deux couches
didentification sont ajoutes. Le quadruplet [hte, instance, schma, objet] forme un
nom dobjet complet ou FQON.
Fully Qualified Object Name: FQON

Nom
de lhte

Nom
de linstance

Schma

Nom
de lobjet

Pour accder une table distante son identifiant FQON doit tre connu. La
transparence demplacement cache lutilisateur le triplet [hte, instance, schma].

11.

Les liens de base de donnes

Pour interroger une BD distante, il faut crer un lien de base de donnes.

Un lien de base de donnes est un chemin unidirectionnel dun serveur un autre. En
effet, un client connect une BD A, peut utiliser un lien stock dans la BD A pour
accder la BD distante B, mais les utilisateurs connects B ne peuvent pas utiliser
le mme lien pour accder aux donnes sur A.
Lorsquun lien est rfrenc par une instruction SQL, Oracle ouvre une session dans
la base distante et y excute linstruction. La session demeure ouverte au cas o elle
serait de nouveau ncessaire.
En crant un lien de BD, on doit indiquer le nom du compte auquel on se connecte, le
mot de passe de ce compte, et le nom de service associ la base distante. En
labsence dun nom de compte, Oracle utilise le nom et le mot de passe du compte
local pour la connexion la base distante.
CREATE [SHARED|PUBLIC|PRIVATE] DATABASE LINK NomLien

40

CONNECT TO ..
CURRENT_USER
User IDENTIFIED BY password
USING connect_string
Un lien est soit priv ou public. Seul lutilisateur qui a cre un lien priv peut
lutiliser, alors quun lien public est utilis par tous les utilisateurs de la base de
donnes. Le lien partag est propre la configuration de serveur multithreaded.
La clause CONNECT TO active une session vers la base distante.
La clause CURRENT_USER cre un lien BD pour lutilisateur courant. Lutilisateur
doit disposer dun compte valide dans la base distante.
La clause USING connect_string spcifie le nom de service dune base distante. Les
noms de service dinstances sont stocks dans le fichier de configuration utilis par
Net8 intitul tnsnames.ora. Ce fichier spcifie lhte, le port, et linstance associs
chaque nom de service.
Des informations sur les liens de BD publics et privs, figurent respectivement dans
les vues du dictionnaire de donnes : DBA_DB_LINKS et USER_DB_LINKS.
Lexemple suivant cre un lien public de bases de donnes, appel RH_Lien :
CREATE PUBLIC DATABASE LINK RH_Lien
CONNECT TO RH IDENTIFIED BY PUFFINSTUFF
USING hq;
hq dsigne le nom de service de la BD.
Utilisation du lien :
SELECT * FROM Employee@RH_Lien
WHERE office = ANNAPOLIS;

12.

Transparence demplacement

Aprs avoir cre les liens de bases de donnes, plusieurs objets : les vues, les
synonymes et les procdures stockes, peuvent servir cacher la distribution des
donnes aux utilisateurs :

12.1.

Vues

Les vues peuvent fournir une transparence par rapport aux tables locales et distantes.
Par exemple, supposons que la table Employ est sur une BD locale et la table
Dpartement est sur une BD distante. Pour rendre ces tables transparentes aux
utilisateurs. Nous pouvons crer une vue dans la BD locale qui fait la jointure des
donnes locales et distantes, comme ci-dessous : Les utilisateurs accdant cette vue
nont pas besoin de savoir o les donnes sont stockes.
41

Exercice 1:
Ecrire en SQL la commande de cration de la vue Entreprise.

12.2.

Synonymes

Les synonymes sont des noms simples qui permettent didentifier de faon unique
dans un systme distribu les objets quils nomment. Les synonymes peuvent tre
cres pour diffrents objets : Tables, Types, Views, Snapshots, Procedures, Functions,
Packages. Ils figurent dans le dictionnaire de donnes.
CREATE [PUBLIC] nom-synonyme
FOR [schma.]nom-objet[@nom-lien-BD] ;
Exercice 2:
Ecrire en SQL la requte suivante On recherche les employs affects au
dpartement gnie logiciel dans les deux cas suivants :
- La requte est mise du site A o se trouve la table Employ.
- La requte est mise du site B o se trouve la table Dpartement.

12.3.

Procdures

Les units de programmes PL/SQL, peuvent servir (a) rfrer des donnes
distantes, (b) appeler des procdures distantes, (c) utiliser des synonymes pour rfrer
des procdures distantes.
(a) Rfrer des donnes distantes
Considrons la procdure LicencierEmploy :
CREATE PROCEDURE LicencierEmploy (enum NUMBER) AS
BEGIN
DELETE FROM Employ@hq.acme.com
WHERE NumEmp = enum
END;

Quand lutilisateur ou lapplication appelle la procdure LicencierEmploy, il/elle ne

voit pas que la table distante est en cours de mise jour.
Nous pouvons galement crer un synonyme pour le lien la table Employ.

CREATE SYNONYM Emp FOR Employ@hq.acme.com;

La procdure LicencierEmploy devient :

CREATE PROCEDURE LicencierEmploy (enum NUMBER) AS

BEGIN
DELETE FROM Emp WHERE NumEmp = enum;
END;

42

(b) Appeler des procdures distantes (RPC : ang. Remote Procedure Call)
On peut utiliser une procdure locale pour appeler une procdure distante. La
procdure distante pourra excuter les instructions LMD requises.
Exercice 3:
Ecrire le scnario suivant :
Un utilisateur scott identifi par tiger se connecte la BD distante hq.acme.com. Il
cre la procdure FinEmploy, ayant pour paramtre le numro de lemploy, qui
supprime lemploy de la table Employ.
Lutilisateur scott identifi par tiger se connecte la BD locale fin.acme.com. Il cre
la procdure LicencierEmploy, ayant pour paramtre le numro de lemploy, qui
appelle la procdure FinEmploy.

Lemplacement appropri pour une procdure dpend de la distribution et de

lutilisation des donnes. Lobjectif tant de limiter le trafic sur le rseau pour
rsoudre les requtes.

13.

Mise au point des requtes distribues

Un serveur BD Oracle gnre partir dune requte distribue, des requtes distantes,
quil envoie aux nuds distants pour excution. Les nuds excutent alors les
requtes et retournent les rsultats au serveur local. Un post-traitement est excut
pour enfin retourner le rsultat lutilisateur ou lapplication.
Les stratgies dcrites dans ce qui suit, sont utilises pour optimiser les requtes.

13.1.

Collocated Inline Views

Le moyen le plus efficace doptimiser une requte consiste rduire au maximum

laccs aux BDs distantes et de ne rapatrier que les donnes requises. Pour ce, Oracle
utilise des Collocated Inline Views, cest dire des vues de plusieurs tables
distantes et en ligne, afin de forcer les restrictions sur les sites distants.

13.2.

Optimisation base sur le calcul des cots

Oracle utilise une mthode base sur le calcul des cots (ang. Cost based SQL
optimizer : CBO) pour trouver et gnrer la requte SQL qui extrait uniquement les
donnes ncessaires des tables distantes.
Les donnes subissent un premier traitement sur le site distant, puis le site distant
envoie le rsultat au site local, do la requte a t mise.
R-crire la requte suivante :
CREATE TABLE AS (

43

SELECT L.a, L.b, R1.c, R1.d, R1.e, R2.b, R2.c

FROM local L, Remote R1, Remote R2
WHERE (L.c = R1.c) AND (R1.c = R2.c) AND (R1.e > 300)
);

La principale tche excute par loptimiseur consiste r-crire une requte

distribue pour utiliser les collocated inline views. Par contre, si la requte distribue
contient des fonctions agrgats, des sous-requtes, du complex-SQL, loptimisation
base sur le cot ne peut tre utilise.

13.3.

Statistiques

Oracle permet galement de collecter des statistiques sur les diffrentes tables du
systme.
(a) Activation:
Il faut excuter lune des instructions suivantes:
ALTER SESSION OPTIMIZER_MODE = CHOOSE ;
ALTER SESSION OPTIMIZER_MODE = COST ;

(b) Analyse des tables :

ANALYZE TABLE Employ COMPUTE STATISTICS ;
ANALYZE TABLE Dpartement COMPUTE STATISTICS ;

13.4.

Hints

Les hints conviennent aux requtes distribues contenant des fonctions agrgats, des
sous-requtes, ou du complex-SQL.
Voir http://www.oradev.com/hints.jsp pour une liste de hints
 DRIVING_SITE Hint
Linstruction DRIVING_SITE permet de prciser manuellement le site dexcution de
la requte.

Exemple :
SELECT /*+DRIVING_SITE(Dpartement )*/ *
FROM Employ, Dpartement@remote.com
WHERE Employ.NumDept = Dpartement.NumDept ;
La jointure se fera sur le site o se trouve la table Dpartement.

13.5.

Analyse du plan dexcution

Un des aspects les plus importants pour la mise au point de requtes distribues est
lanalyse du plan dexcution dune requte distribue.

44

Avant de pouvoir gnrer et dafficher le plan dexcution, il faut prparer une BD

servant sauver le plan dexcution. Ceci est fait en excutant le script suivant :
SQL>@utlxplan.sql
Ainsi, une table PLAN_TABLE est cre dans le schma courant pour sauver
temporairement le plan dexcution.
La clause EXPLAIN PLAN FOR gnre le plan dexcution.
Exemple : Requte Noms des dpartements auxquels sont attachs plus que 3
employs
EXPLAIN PLAN FOR
SELECT D.NomDept
FROM Dpartement D
WHERE D.NumDept IN (SELECT NumDept
FROM emp@orc2.world
GROUP BY NumDept
HAVING COUNT(NumDept) > 3);

Enfin, pour afficher le plan dexcution sauv dans PLAN_TABLE, il suffit dexcuter
le script suivant:
SQL>@utlxpls.sql
Pour voir lexpression SQL excute sur le site distant, on excute :
SELECT other
FROM plan_table
WHERE operation = REMOTE;
On obtient par exemple:
SELECT DISTINCT A1.NumDept
FROM Employ A1
GROUP BY A1.NumDept
HAVING COUNT(A1.NumDept) > 3

14.

Rplication des donnes

Afin de rduire la quantit de donnes transmises sur le rseau, et amliorer par

consquent les performances des requtes, plusieurs options de rplication peuvent
tre envisages.

14.1.

Commande COPY

La premire option consiste rpliquer rgulirement les donnes sur le serveur local
au moyen de la commande COPY de SQL*Plus.
Exemple:
COPY FROM RH/PUFFINSTUFF@loc CREATE Employes USING
SELECT * FROM Employes

45

WHERE Etat = NM ;
COMMIT ;

La base est identifie par le service nomm LOC. durant la connexion, une session
devrait tre initie par le compte RH avec le mot de passe PUFFINSTUFF.
Linconvnient est que les donnes ne peuvent pas tre mises jour. La commande
REPLACE est utilise pour remplacer le contenu des tables.

14.2.

Snapshots

Cette option utilise des snapshots pour rpliquer les donnes depuis une source matre
vers plusieurs cibles. Les snapshots peuvent tre en lecture seule (ang. read-only) ou
mis jour (ang. updateable). Avant de crer un snapshot, il faut dabord crer un lien
vers la base de donnes source.
Deux types de snapshots peuvent tre cres : simples et complexes. Un snapshot
simple ne contient pas de clause distinct, group by, connect by, de jointure multitables
ou doprations set.
Le snapshot suivant est dfini de faon extraire les donnes matres et renouveler
lopration 7 jours plus tard.
CREATE SNAPSHOT LocalEmp
TABLESPACE data2
STORAGE (INITIAL 100K next 100K PCTINCREASE 0)
REFRESH FAST
START with SysDate
NEXT SysDate+7
AS SELECT * FROM Employes@RH_Lien;

Un REFRESH FAST utilise un snapshot log, pour actualiser le snapshot. Ce fichier se

trouve sur le mme site que la table matre. Dans le snapshot log, sont stockes les
modifications intervenues sur la table matre. Ainsi, pour chaque mise jour, seules
les modifications qui sont envoyes, et non lensemble des donnes. Par contre, un
REFRESH COMPLETE est obligatoire pour les snapshots complexes.
Le snapshot log est crer avant le snapshot:
CREATE SNAPSHOT LOG ON Employes
TABLESPACE DATA
STORAGE (INITIAL 10K NEXT 10K PCTINCREASE 0)
PCTFREE 5 PCTUSED 90;

Une utilisation classique des snapshots en mise jour est le cas du contrle technique
automobile. Tous les centres de contrle stockent des donnes concernant les
vhicules quils ont contrls durant la journe. Chaque nuit, les donnes sont
dverses dans la base nationale qui centralise les donnes de lensemble du parc
automobile du pays. Notons que, les snapshots en mise jour peuvent engendrer des
conflits. Un dclencheur (ang. trigger) sauve les mises jour opres sur le snapshot
et les transmet au site matre au moment du rafrachissement du snapshot.

46

Les snapshots utilisent le package DBMS_JOB pour organiser les rafrachissements,

et ncessitent que le paramtre du fichier init.ora JOB_QUEUE_PROCESSES soit
suprieur 0.
Les
vues
ALL_SNAPSHOTS,
ALL_SNAPSHOT_REFRESH_TIMES,
ALL_SNAPSHOT_LOG dtaillent les caractristiques des snapshots cres.

14.3.

Vues matrialises

Une vue matrialise peut apporter plusieurs avantages au niveau performances.

Selon la complexit de la requte, on peut la remplir avec des changements
incrmentiels, laide du journal de vues matrialises (MATERIALIZED VIEW
LOG), au lieu de la recrer.
A linverse des snapshots, les vues matrialises peuvent tre utilises directement par
loptimiseur, afin de modifier les chemins dexcution des requtes. Pour ce, il faut
disposer du privilge QUERY REWRITE pour pouvoir rcrire la requte, et que
QUERY_REWRITE_ENABLED
soit
QUERY_REWRITE_ENABLED = TRUE).

TRUE

(ALTER

SESSION

SET

Une vue matrialise cre une table locale pour stocker les donnes, et une vue qui y
accde.
Exemple:
CREATE MATERIALIZED VIEW Ventes-par-Mois
TABLESPACE DATA_AGG
REFRESH COMPLETE
START WITH sysdate
NEXT sysdate+1
ENABLE QUERY REWRITE
AS
SELECT mois, SUM(montant)
FROM Ventes
GROUP BY mois;

La clause ENABLE QUERY REWRITE permet loptimiseur de rediriger les requtes

mises sur la table vers la vue matrialise sil le juge appropri.
La clause NEVER REFRESH empche tout type dactualisation de la vue matrialise.
Une vue matrialise ne peut pas contenir les op. UNION, MINUS, INTERSECT.
Les vues DBMS_MVIEW, ALL_MVIEW_ANALYSIS dtaillent les caractristiques
des vues matrialises cres.

15.

Administration
donnes

de

grandes

bases

de

La dfinition dune grande BD change sans cesse. En 1995, cest une BD de taille
suprieure 100Go, de nos jours elle fait plusieurs traoctets.

47

15.1.

Partitions

Au fur et mesure que les tables augmentent en taille, leur maintenance devient
complexe. Une table volumineuse est divise en partitions selon les plages de valeurs
de la colonne de partitionnement. Les index peuvent tre partitionns. Cette
rpartition a pour but damliorer les performances des oprations de maintenance, de
sauvegarde et de rcupration, ainsi que celles des transactions et des requtes.
Oracle8i offre trois types de partitionnements: par plages, par hachage et compos.

15.1.1.

Partitionnement par plages (ang. Range partitioning)

CREATE TABLE Employes (

NumEmp NUMBER(10) PRIMARY KEY,
Nom
VARCHAR2(40),
NumDept NUMBER(2),
Salaire
NUMBER(7,2),
Date_naiss DATE,
NumSecSoc VARCHAR2(9),
CONSTRAINT
FK_NumDept FOREIGN KEY (NumDept) REFRENCES
Dpartement(NumDept) )
PARTITION BY RANGE (NumDept)
(PARTITION E1 VALUES LESS THAN (11) TABLESPACE PART1_TS,
PARTITION E2 VALUES LESS THAN (21) TABLESPACE PART2_TS,
PARTITION E3 VALUES LESS THAN (31) TABLESPACE PART3_TS,
PARTITION E4 VALUES LESS THAN (MAXVALUE) TABLESPACE
PART4_TS ) ;

Lattribut de partitionnement est une un attribut NOT NULL.

Le partitionnement par plages peut se faire sur plusieurs colonnes de partitionnement.
Si on connat le nom de la partition, il est possible dinvoquer le nom de la partition
dans la clause FROM, comme suit,
SELECT *
FROM Employes PARTITION (E2)
WHERE NumDept BETWEEN 11 AND 20;

Par contre, si la plage des valeurs dune partition change, le rsultat ne rpondra plus
la requte. Sachant quOracle place des contraintes de contrle CHECK sur chacune
des partitions, il nest pas recommand dutiliser cette syntaxe.
Oracle utilise les contraintes de contrle des partitions, afin de dterminer la partition
implique.
Lajout dune partition se fait comme suit,

ALTER TABLE Employes

ADD PARTITION E5 VALUES LESS THAN (41) TABLESPACE PART5_TS;

La fusion de partition se fait comme suit,

ALTER TABLE Employes

48

MERGE PARTITIONS E1, E2 INTO PARTITION E2 ;

15.1.2.

Partitionnement par hachage (ang. Hash partitioning)

Une partition par hachage dtermine lemplacement physique des donnes en

excutant une fonction de hachage sur les valeurs de lattribut de partitionnement.
Dans lexemple suivant, le nombre 10 dsigne le nombre de partitions.
CREATE TABLE Employes (
NumEmp NUMBER(10) PRIMARY KEY,
Nom
VARCHAR2(40),
NumDept NUMBER(2),
Salaire
NUMBER(7,2),
Date_naiss DATE,
NumSecSoc VARCHAR2(9),
CONSTRAINT FK_NumDept FOREIGN KEY
Dpartement(NumDept)
)
PARTITION BY HASH (NumDept)
PARTITIONS 10;

(NumDept)

REFRENCES

Lajout dune partition se fait comme suit,

ALTER TABLE Employes ADD PARTITION ;

Lopration inverse, supprime une partition

ALTER TABLE Employes COALESCE PARTITION ;

15.1.3.

Partitonnement compos (ang. Composite partitioning)

Cette technique permet de combiner deux types de partitions. Lexemple suivant

partitionne par plages la table Employs sur la colonne NumDept, et partitionne par
hachage les partitions de cette colonne sur les valeurs de la colonne Nom.
CREATE TABLE Employs (
NumEmp NUMBER(10) PRIMARY KEY,
Nom
VARCHAR2(40),
NumDept NUMBER(2),
Salaire
NUMBER(7,2),
Date_naiss DATE,
NumSecSoc VARCHAR2(9),
CONSTRAINT
FK_NumDept FOREIGN KEY (NumDept) REFRENCES
Dpartement(NumDept))
PARTITION BY RANGE (NumDept)
SUBPARTITION BY HASH (Nom)
SUBPARTITIONS 10
(PARTITION E1 VALUES LESS THAN (11) TABLESPACE E1_TS,
PARTITION E2 VALUES LESS THAN (21) TABLESPACE E2_TS,
PARTITION E3 VALUES LESS THAN (31) TABLESPACE E3_TS,
PARTITION E4 VALUES LESS THAN (MAXVALUE) TABLESPACE E4_TS) ;

49

15.1.4.

Partitionnement par liste

partitioning) Oracle9i

de

valeurs

(ang.

List

CREATE TABLE Departement (

NumDept NUMBER(2) PRIMARY KEY,
NomDept VARCHAR2(14),
Ville
VARCHAR2(13))
PARTITION BY LIST (Ville)
(PARTITION dEst VALUES (NEW YORK),
PARTITION dOuest VALUES (SAN FRANCISCO, LOS ANGELES),
PARTITION dSud VALUES (ATLANTA, DALLAS, HOUSTON),
PARTITION dNord VALUES (CHICAGO, DETROIT));

Un tuple qui comporte une valeur autre que les spcifies est rejet.

15.1.5.

Partitions dindex

Lindex dune table partitionne peut tre partitionn avec les mmes plages de
valeurs que celles de la table.
CREATE INDEX Employs_NumDept
ON Employes(NumDept)
LOCAL

(PARTITION IE1 TABLESPACE IE1_NDX_TS,

PARTITION IE2 TABLESPACE IE2_ NDX_TS,
PARTITION IE3 TABLESPACE IE3_ NDX_TS,
PARTITION IE4 TABLESPACE P IE4_ NDX_TS) ;

Le mot cl LOCAL, cre un index spar pour chaque partition de la table. Un index
global contient des valeurs provenant de plusieurs partitions.
CREATE INDEX Employs_NumDept
ON Employs(NumDept)
GLOBAL

(PARTITION IE1 VALUES LESS THAN (11) TABLESPACE IE1_NDX_TS,

PARTITION IE2 VALUES LESS THAN (21) TABLESPACE IE2_ NDX_TS,
PARTITION IE3 VALUES LESS THAN (31) TABLESPACE IE3_ NDX_TS,
PARTITION IE4 VALUES LESS THAN (MAXVALUE) TABLESPACE IE4_ NDX_TS) ;

15.2.

Gestion de Clusters

Les clusters fournissent une mthode de stockage des tables de donnes. Un cluster
est form de groupes de tables qui partagent les mmes blocs de donnes. Les tables
sont regroupes car elles ont des colonnes en commun, et sont trs souvent interroges
ensemble. Cest le cas par exemple des tables Employ et Dpartement qui ont en
commun lattribut NumDpt. Lattribut NumDpt est dit cl du cluster. Si on met en

50

cluster les deux tables, Oracle stocke physiquement, pour chaque dpartement, le
dpartement et ses employs dans les mmes blocs de donnes.
Les clusters sont viter si les tables sont frquemment accdes individuellement.
Par contre, sont conseills dans le cas o lopration de jointure entre les deux tables,
est frquente.
CREATE CLUSTER EmpDept (NumDept NUMBER(3))
PCTUSED 80
PCTFREE 5
SIZE 600
TABLESPACE users
STORAGE (INITIAL
200K NEXT
300K
MINEXTENTS 2
MAXEXTENTS 20
PCTINCREASE 33 );
CREATE TABLE Departement (
NumDept NUMBER(3) PRIMARY KEY, .)
CLUSTER EmpDept(NumDept);
CREATE TABLE Employe (
NumEmp NUMBER(5) PRIMARY KEY, .,
NumDept NUMBER(3) REFRENCES Departement)
CLUSTER EmpDept(NumDept);

Linstruction suivante supprime un cluster:

DROP CLUSTER EmpDept ; //si le cluster ne contient aucune table
DROP CLUSTER EmpDept INCLUDING TABLES ; // si le cluster contient des tables
Oracle offre une deuxime alternative consistant en le stockage de tables dans des
hash cluster.
CREATE CLUSTER EmpDept (NumDept NUMBER(3))
PCTUSED 80
PCTFREE 5
TABLESPACE users
STORAGE (INITIAL
250K NEXT
50K
MINEXTENTS 1
MAXEXTENTS 3
PCTINCREASE 0 )
HASH IS NumDept HASHKEYS 150;

Le nombre 150 indique le nombre de valeurs gnres par la fonction de hachage.

16.

Oracle Parallel Query

Cette option permet dexcuter certains ordres SQL en parallle. Le paralllisme des
traitements est assur par un processus coordinateur et plusieurs processus parallles.
Les ordres DDL suivants peuvent tre paralllises, si lobjet source ou cible est
fragment:
Create table . . . as select . . .
Create index

51

Rebuild dun index ou dune de ses partitions

Dplacement dune partition
Eclatement dune partition
Les instructions DML suivantes peuvent tre paralllises :
Delete from . . . appliqu sur des tables fragmentes.
Update . . . set . . . appliqu sur des tables fragmentes.
Insert . . . select . . . appliqu sur des tables fragmentes.
SQL*LOADER peut agir en parallle sur des tables fragmentes.
En ce qui concerne les tables partitionnes, un degr supplmentaire de paralllisme
peut tre recherch dans le cas de lutilisation des sous partitions.
Le traitement parallle est activ par lutilisation du hint PARALLEL dans lordre
SQL:
SELECT /*+parallel(matable,3) */ * FROM matable WHERE . . .
Le dictionnaire de donnes et PDML

Dans le dictionnaire de donnes, les vues V$PX_SESSION, V$PX_SESSTAT,

V$PX_PROCESS, V$PX_PROCESS_SYSSTAT fournissent des statistiques concernant
lexcution des requtes en parallle:
Activation de PDML
ALTER SESSION [enable|disable|force] PARALLEL [DML/DDL] [parallel n] ;

Le degr de paralllisme des ordres DML est dict dune manire prioritaire par les
hints. En ce qui concerne les ordres DDL, ils seront excuts avec le degr de
paralllisme par dfaut. Loption force concerne les objets qui nont aucune clause de
paralllisme dans leur clause de stockage ou ceux qui sont attaqus par des requtes
sans HINTS. Dans tous les cas, le degr de paralllisme doit se trouver dans
lintervalle [PARALLEL_MIN_SERVERS, PARALLEL_MAX_SERVERS].
Mme avec PDML actif dans la session, aucune garantie de la ralisation de lordre
en parallle ne peut tre assure.
De nouveaux hints ont t cres pour tre utiliss avec les INSERT : APPEND et
NOAPPEND.

Exemple de requtes paralllises

SQL> commit;
Commit complete.
SQL> alter session enable PARALLEL dml;
Session altered.
SQL> alter session enable PARALLEL ddl;
Session altered.
SQL> select username, pdml_status, pddl_status, pq_status, pdml_enabled
2 from v$session where username is not null;
USERNAME
PDML_STA PDDL_STA PQ_STATU PDM
------------------------------ -------- -------- -------- --SYS
ENABLED ENABLED ENABLED YES
SQL> select * from v$pq_sesstat where statistic like '%Parallel%';

52

STATISTIC
LAST_QUERY SESSION_TOTAL
------------------------------ ---------- ------------Queries Parallelized
0
9
DML Parallelized
0
0
SQL> create table anp.opqb as
2 select * from anp.opq;
Table created.
SQL> select * from v$pq_sesstat where statistic like '%Parallel%';
STATISTIC
LAST_QUERY SESSION_TOTAL
------------------------------ ---------- ------------Queries Parallelized
1
10
DML Parallelized
0
0
SQL> insert /*+parallel (anp.opqb,5) */ into anp.opqb
2 select /*+parallel (anp.opq, 4) */ * from anp.opq;
2560 rows created.
SQL> select * from v$pq_sesstat where statistic like '%Parallel%';
STATISTIC
LAST_QUERY SESSION_TOTAL
------------------------------ ---------- ------------Queries Parallelized
1
11
DML Parallelized
0
0
SQL> commit;
Commit complete.
SQL> UPDATE /*+PARALLEL (anp.opqb,2) */
2 anp.opqb SET c1 = c1*10;
5120 rows updated.
SQL> select * from v$pq_sesstat where statistic like '%Parallel%';
STATISTIC
LAST_QUERY SESSION_TOTAL
------------------------------ ---------- ------------Queries Parallelized
0
11
DML Parallelized
0
0
SQL> UPDATE /*+PARALLEL (anp.opqb,2) */
2 anp.opqb SET c1 = c1*10;
5120 rows updated.
SQL> DELETE /*+PARALLEL (anp.opqb,4) */
2 FROM anp.opqb
3 WHERE to_number(substr(c2,1,1)) < 5;
4096 rows deleted.
SQL> select * from v$pq_sesstat where statistic like '%Parallel%';
STATISTIC
LAST_QUERY SESSION_TOTAL
------------------------------ ---------- ------------Queries Parallelized
0
11
DML Parallelized
0
0
SQL> spool off;
Lexemple prcdent montre lutilisation des processus en parallle pour toutes les
oprations de cration et dinterrogation de tables. La paralllisation na pas t
effectue pour les delete ou update, car ce nest possible que pour les tables
partitionnes.

53

Bibliographie

[1]

S. Spaccapietra, C. Vingenot, Bases de donnes rparties,

http://lbdwww.epfl.ch/f/teaching/courses/slidesBDA/BDR/BDR_se.pdf

[2]

M. T. zsu & P. Valduriez, Principles of Distributed Database Systems,

Prentice Hall 1999.

[3]

D. Kossmann, The State of the Art in Distributed Query Processing,

http://www.db.fmi.uni-passau.de/~kossmann

[4]

D. Donsez, Les SGBDs Parallles, http://www.adele.imag.fr/~donsez/cours/

[5]

D. Donsez, Rpartition, Rplication, Nomadisme, Htrognit dans les

SGBDs, http://www.adele.imag.fr/~donsez/cours/

[6]

Chapitre
8:
La
gestion
mip.fr/cours/concept/chap8.htm

[7]

J. Durbin, L. Ashdown, Oracle8i : Distributed Database Systems, Oracle

Press, 1999.

des

transactions,

http://medias.obs-

http://sunsite.eunnet.net/documentation/oracle.8.0.4/server.804/a58247.pdf
[8]

K. Loney, M. Theriault, Oracle8i DBA Handbook, Oracle Press 2000.

[9]

Oracle8
Product
rohan.sdsu.edu/doc/oracle/

[10]

I. Ben-Gan, T. Moreau, Advanced Transact-SQL for SQL Server 2000,

Chapitre 13 p.459: Horizontally Partitionned Views, a!Press.

Documentation

Library,

http://www-

[11] B. Ducourthial, Les bases de donnes rparties,

http://wwwhds.utc.fr/~ducourth/TX/BDD/

[12] M. Gertz, ORACLE/SQL Tutorial, http://www.db.cs.ucdavis.edu.

[13] Oracle Parallel Query, http://www.tafora.fr/wp/pqo.doc.html.

Note : les exemples et exercices du cours sont extraits principalement des

rfrences suivantes [1][2][8][9][12][13]

54

55