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. 11. 12. Oracle en rseau ..................................................................................................... 39 Les liens de base de donnes.................................................................................. 40 Transparence demplacement................................................................................. 41 Vues.............................................................................................................. 41 Synonymes ................................................................................................... 42 Procdures .................................................................................................... 42

12.1. 12.2. 12.3. 13.

Mise au point des requtes distribues................................................................... 43 Collocated Inline Views ............................................................................... 43 Optimisation base sur le calcul des cots ................................................... 43 Statistiques ................................................................................................... 44 Hints ............................................................................................................. 44 Analyse du plan dexcution ........................................................................ 44

13.1. 13.2. 13.3. 13.4. 13.5. 14.

Rplication des donnes ......................................................................................... 45 Commande COPY........................................................................................ 45 Snapshots...................................................................................................... 46 Vues matrialises........................................................................................ 47

14.1. 14.2. 14.3.

15.

Administration de grandes bases de donnes......................................................... 47 Partitions....................................................................................................... 48 Gestion de Clusters....................................................................................... 50

15.1. 15.2. 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 Interne Site 1

Schma Conceptuel Local Site 2 Schma Interne Site 2

Schma Conceptuel Local Site 3 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 Prnom Jean Blaise Alan Valdimir Age 29 38 51 36

3.1.2.

Rpartition horizontale)

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 174 723 177 498 201 639 203 446 NomClient Villard Cattell Tsellis Kowalsky NoClient 174 723 177 498 201 639 203 446 Prnom Jean Blaise Alan Vladimir Age 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 Relation Cli5 Relation Cli4 Relation Cli6 [NoClient, NomClient] ([Age < 38]Client) [NoClient, NomClient] ([Age [NoClient, Prnom]Client [NoClient, Age]Client
38]Client)

3.1.5.

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 1 (R2) = 5 Acc 1 (R3) = 25 Acc 1 (R4) = 3 Acc 2 (R1) = 20 Acc 2 (R2) = 0 Acc 2 (R3) = 25 Acc 2 (R4) = 0 Acc 3 (R1) = 10 Acc 3 (R2) = 0 Acc 3 (R3) = 25 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 1 semaine : 0.1 3 jours : 0.3 1 jour : 0.7 1 Heure : 0.9 1 mois : 0.01

Exemples de Taux de satisfaction du temps d'attente pour obtenir l'original : jusqu' 30 sec : 1 3 min : 0.1 2 min : 0.5 1 min : 0.7 45 sec : 0.9 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. 2. Cration d'un nouveau compte pour un client. INSERT INTO compte VALUES (184 177, Genve, courant, 350 000) ; 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> S1> S2> S2> S1> 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, temp1 R1 R2(R1) envoi de temp1 vers S2 temp2 R2 temp1

envoi de temp2 vers S1 R1 temp2 (quivalent R1 R2)

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 : R = [NOMF, NF] ([VILLEU
= "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
Des interfrences entre crivains, cd transactions dcriture. Des interfrences entre lecteurs et crivains, cd transactions de lecture et transactions dcriture.

Nous distinguons deux cas dinterfrences problmatiques.

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 T5

T2

T1 T5 T3

T2

T3

T4

T3
Graphe Attente Local au Site 2

T4

Graphe Attente Local au Site 1

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.
Site1 Coordinateur
er prpar

Site2
r

Site1

Coordinateur
er prpar

Site2
r er

prpa re

prpa

prt
p r t
r valide

prt
rejete r

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.

transparente

8.

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

CPU

CPU

CPU

8.2.

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 M

CPU M

CPU M

CPU M

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 D

CPU
M D

CPU
M D

8.4.

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.

Les techniques de distribution des donnes sont au nombre de 3 : par intervalle, hachage, donneur de carte (ang. round robin).

CPU CPU

CPU

M M

M M

CPU

M
D D

CPU CPU

CPU

D D

D
32

CPU

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

ont la taille de cinq blocs. La taille dun bloc db_block_size figure dans le fichier init.ora. segment, la valeur par dfaut est gale 1.

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

MINEXTENTS spcifie le nombre initial dextensions alloues la cration du

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

Il existe 4 types de fichiers :

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

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.

SMON System Monitor: le processus entreprend une rcupration aprs un

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. 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. RECO Recoverer: le processus de rcupration RECO rsout les dfaillances

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. 2. Oracle Net 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.
CREATE SYNONYM Emp FOR Employ@hq.acme.com;

Nous pouvons galement crer un synonyme pour le lien la table Employ.

CREATE PROCEDURE LicencierEmploy (enum NUMBER) AS BEGIN DELETE FROM Emp WHERE NumEmp = enum; END;

La procdure LicencierEmploy devient :

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.
ALTER TABLE Employes ADD PARTITION E5 VALUES LESS THAN (41) TABLESPACE PART5_TS;

Lajout dune partition se fait comme suit,

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] [2] [3] [4] [5] [6] [7]

S. Spaccapietra, C. Vingenot, Bases de donnes rparties, http://lbdwww.epfl.ch/f/teaching/courses/slidesBDA/BDR/BDR_se.pdf M. T. zsu & P. Valduriez, Principles of Distributed Database Systems, Prentice Hall 1999. D. Kossmann, The State of the Art in Distributed Query Processing, http://www.db.fmi.uni-passau.de/~kossmann D. Donsez, Les SGBDs Parallles, http://www.adele.imag.fr/~donsez/cours/ D. Donsez, Rpartition, Rplication, Nomadisme, Htrognit dans les SGBDs, http://www.adele.imag.fr/~donsez/cours/
Chapitre 8: La gestion mip.fr/cours/concept/chap8.htm des transactions,

http://medias.obs-

J. Durbin, L. Ashdown, Oracle8i : Distributed Database Systems, Oracle Press, 1999. http://sunsite.eunnet.net/documentation/oracle.8.0.4/server.804/a58247.pdf

[8] [9] [10]

K. Loney, M. Theriault, Oracle8i DBA Handbook, Oracle Press 2000. Oracle8 Product rohan.sdsu.edu/doc/oracle/ Documentation Library, http://www-

I. Ben-Gan, T. Moreau, Advanced Transact-SQL for SQL Server 2000, Chapitre 13 p.459: Horizontally Partitionned Views, a!Press.

[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