ENST

BDA - 2002

page 1 v. :05/03/2003

TP Bases de donnes rparties

requtes rparties

Version corrige
Auteur : Hubert Naacke, rvision 5 mars 2003 Mots-cls: bases de donnes rparties, fragmentation, schma de placement, lien, jointure inter-site, JDBC, plan dexcution, performance.

Configuration de lenvironnement de travail

Installer sur votre compte larchive tpbdr.tar : ouvrir une fentre shell, puis saisir les commandes : cd cp /infres/may/testbd/bdtest/tpbdr/tpbdr.tar . // copier larchive tar xvf tpbdr.tar // extraire les fichiers de larchive cd tpbdr // travailler dans le rpertoire tpbdr source oracle.shenv // configuration pour utiliser Oracle sqlplus bdaxx/bda@chop1 // client Oracle (choisir un user bdaxx dans {bda02 bda36} @creation-plan-table // cration de la table pour visualiser les plans dexcution set autotrace trace // activer le mode de visualisation du plan d'excution des requtes Editer un fichier texte exemple.sql qui contiendra les ordres SQL que vous crirez : xemacs exemple.sql saisir les rponses du TP, puis sauvegarder Remarque: les lignes de commentaires commencent par deux tirets : -- ceci est un commentaire dans un fichier SQL Puis excuter ensuite les ordres SQL du fichier exemple.sql dans la fentre du client Oracle (Sql*Plus) : SQL> @exemple // ne pas saisir le suffixe du fichier (.sql)

Introduction
Le schma relationnel de lapplication est : Producteurs(np, region, ) Recoltes(np, nv, qte) Achat(nb, nv, date, lieu) Buveurs(nb, nomb, prenomb, type) BuveursBig a les mmes attributs que Buveurs, mais est beaucoup plus volumineuse (200 000 tuples). Le domaine de lattribut type dun buveur est {rare, petit, moyen, gros} Les donnes de lapplication sont rparties sur les bases de donnes suivantes : Site nom du service utilisateur mot de passe nom de la BD (SID) chop1 bda02 bda36 bda cours S1 coursv chop2.enst.fr bda01 bda S2 Pour faciliter la mise en uvre du TP, certaines tables sont rpliques sur les 2 sites, mais Oracle na pas connaissance de la rplication pendant loptimisation des requtes Le schma global (schma de placement) sera construit sur le site S1.

Exercice 1 : Placement des relations

1.1) Excution de requte rpartie : transfert de requte / transfert de donnes Donner les ordres SQL pour crer dans S1 le schma de placement suivant : S1 contient Producteurs et Recoltes S2 contient Achats et Buveurs Donnes locales : Producteurs et Recoltes existent dj sur S1. Donnes distantes : crer un lien S1 S2 (voir le fichier ls2.sql) create database link coursv

ENST

BDA - 2002

page 2 v. :05/03/2003

connect to bda01 identified by bda using 'chop2.enst.fr'; crer dans S1 des synonymes S2Achats et S2Buveurs. create synonym S2Buveurs for buveurs@coursv; create synonym S2Achats for achats@coursv; Traiter sur S1 la requte R0 :Quels sont les buveurs qui ont fait des achats ? Mesurer le temps dexcution de la requte (voir le fichier r0a.sql). set timing on select * from S2Achats a, S2Buveurs b where a.nb = b.nb Analyser le plan dexcution : set timing off set autotrace trace select * from S2Achats a, S2Buveurs b where a.nb = b.nb ;
OPERATIONS OPTIONS OBJECTS -------------------------------- -------------------- -------------------MERGE JOIN SORT JOIN TABLE ACCESS ..FULL BUVEURS COURSV.WORLD SORT JOIN TABLE ACCESS FULL ACHATS COURSV.WORLD

La tabulation (espace en dbut de ligne) indique l'arborescence des oprateurs. merge sort table access full Buveurs sort table access full Achats jointure par fusion tri lect. squentielle Buveurs tri lect. squentielle Achats

Nom des oprateurs : merge-join = jointure par fusion sort join = tri prliminaire (avant d'effectuer une jointure par fusion) table access full nom_relation nom_BD = lecture squentielle de tous les tuples de la relation nom_relation sur la base nom_BD. Plan = Jointure-fusion( tri(lecture-squ(Buveurs)), tri(lecture-squ(Achat)) ) Le nom de la base de donnes est COURSV, la requte est excute entirement sur la BD coursv du site 2. Quelles sont les oprations traites sur S2 et S1 ? Quelles sont les donnes transmises entre S1 et S2 ? sur S2 : T1= (Achat Buveurs) puis transfert de T1 de S2 vers S1 puis rsultat sur S1 Oracle dtecte que les donnes sont sur le mme site et transmet la requte sur le site S2. Seul le rsultat de la requte est transfr de S2 vers S1. Cette solution est plus performante que la solution nave vue en cours : envoyer toutes les donnes sur le site o lutilisateur demande la requte (site S1) pour y traiter la requte. Remarque : Lalgorithme de jointure locale utilis dpend de la prsence dun index sur lattribut de jointure :

ENST

BDA - 2002

page 3 v. :05/03/2003

- un index : jointure par boucles + index : (index-nested-loop) (voir le fichier r0.sql) - pas dindex : jointure par tri fusion (sort + merge join) : (voir le fichier r0_noindex.sql) 1.2) Excution de requte avec jointure inter-site Modifier le schma de placement pour que la relation Achat soit locale sur S1 : Sur S1: Producteurs, Recoltes, Achats Sur S2 : S2Buveurs Mesurer le temps dexcution de la requte R1 : Donner le nombre de buveurs qui ont fait des achats ? (voir le fichier r1a.sql). set timing on select count(*) from Achats a, S2Buveurs b where a.nb = b.nb ; Analyser le plan dexcution : set timing off set autotrace trace select * from Achats a, S2Buveurs b where a.nb = b.nb ; Quelles sont les oprations traites sur S2 et S1 ? Quelles sont les donnes transmises entre S1 et S2 ? sur S2 : T1 = Lecture squentielle de Buveurs S2 -> S1 : T1 sur S1 : Achat T1 Tous les tuples de Buveurs sont transmis de S2 S1 Lobjectif est de mesurer le cot du transfert des donnes entre deux sites en tudiant une requte de jointure inter-site avec une relation trs volumineuse (cardinalit leve). Modifier le schma de placement : - les achats sont sur S1 - les buveurs sont dans la relation BuveursBig sur S2.Cette relation contient 200.000 buveurs. Donnes distantes : crer dans S1 le synonyme S2BuveursBig. create synonym S2BuveursBig for BuveursBig@coursv; Analyser la requte R2 : Donner le nombre de buveurs dans BuveurBig qui ont fait des achats ? (voir le fichier r1.sql). set timing on set autotrace trace select * from Achats a, S2BuveursBig b where a.nb = b.nb ; Comparer les temps dexcution de R1 et R2 : Quelle est lorigine de la baisse de performance entre R2 et R1 ? Le temps prpondrant est le transfert des tuples de la relation BuveursBig depuis S2 vers S1. Proposer une solution pour amliorer le temps de rponse de R2. Objectif : rduire le volume des donnes transfres entre les sites S1 et S2. Exigence : la requte est pose sur S1 donc le rsultat de la requte doit tre sur S1. On constate que volume(Achat) + volume(rsultat de la requte) < volume(BuveursBig) Donc il est avantageux de transfrer Achat de S1 vers S2 pour traiter la jointure sur S2 puis de transfrer le rsultat de la requte sur S1. S1 doit transmettre S2 une requte inter-sites pour traiter la jointure sur le site S2 qui contient BuveursBig (la plus grosse relation). Le scnario construire est : L'utilisateur se connecte S1 et pose la requte globale RG1 Pour traiter RG1, S1 se connecte S2 et pose la requte T2 Pour traiter T2, S2 se connecte S1 et pose la requte T1 Excution du scnario : Sur S1: T1 = select * from Achats, puis transfert vers S2 Sur S2: T2 = T1 BuveursBig, puis transfert vers S1

ENST

BDA - 2002

page 4 v. :05/03/2003

Sur S1: rsultat Mise en uvre du scnario : Dans S2 : crer un lien S2 S1 // un lien nest pas bi-directionnel crer un synonyme S1Achats reprsentant les Achats de S1 Dans S1 : crer un synonyme S2S1Achats reprsentant le synonyme S1Achats de S2 traiter la requte : select count(*) from S1S2Achats a, S2BuveursBig b where a.nb = b.nb Le plan dexcution dtermin par loptimiseur dOracle est : Depuis S1 : transmettre S2 la requte de jointure inter-site entre S1Achats et BuveursBig Sur S2 : rcuprer les Achats de S1 vers S2 traiter la jointure renvoyer le rsultat S1

Exercice 2 : Requtes inter-site avec JDBC

Lobjectif est dutiliser JDBC pour traiter la requte R2 plus rapidement. Le plan dexcution optimal est : lecture squentielle de Achats : pour chaque tuple t de Achat : accder la relation BuveursBig de S2 en utilisant lindex sur lattribut nb (attribut de jointure).La requte daccs S2 est : select nb from BuveurBig where nb = t.nb transfrer le rsultat sur S1. Configurer lenvironnement java : cd jdbc source config-jdbc // configuration de lenvironnement pour utiliser le pilote jdbc Implmentation du plan : voir le fichier AccesInterbase.java xemacs AccesInterbase.java M-x font-lock-mode // fichier java avec couleurs syntaxiques Quelle est le gain de performance par rapport au traitement de la mme requte avec Oracle (cf. exercice 1)? javac AccesInterbase.java // compilation du programme java time java AccesInterbase // excution + chronomtrage Modifier le fichier AccesInterbase.java pour remplacer la relation BuveursBig par une relation identique mais qui na pas dindex sur lattribut nb (relation BuveursBig_noindex). Comparer le temps de rponse avec la solution prcdente : quel est le gain de performance apport par lindex ? Proposer un algorithme pour traiter efficacement la requte R3 : Quels sont tous les achats des buveurs (de BuveursBig) dont de numro de buveur est suprieur 100 ? Traiter la slection (nb>100) dabord sur Achat. Le rsultat tant vide, il est inutile daccder BuveursBig. Retourner directement le rsultat vide. Comparer les temps dexcution de R3 avec Oracle et avec JDBC.

Exercice 3 : Fragmentation horizontale

Dfinir sur S1 le schma de fragmentation suivant : Tous les buveurs de la relation BuveurBig sont fragments horizontalement en deux fragments selon le type du buveur : - le fragment BuvRare contient les buveurs dont le type est rare, - le fragment BuvAutre contient les autres buveurs. Lallocation des fragments est la suivante : sur S1 : le fragment BuvAutre sur S2 : le fragment BuvRare

ENST

BDA - 2002

page 5 v. :05/03/2003

Quel est lordre SQL pour crer le fragment BuvAutre sur S1 ? (voir le fichier f1.sql) copy from bda01/bda@chop2 create BuvAutre using ( select * from BuveursBig where type <> rare); commit; Le fragment BuvRare est dj cr sur S2. Dfinir sur S1 la vue VueBuveurs qui reprsente lunion des fragments BuvRare et BuvAutre. create view VueBuveurs as select * from BuvAutre union select * from BuvRare@coursv; Soit la requte RV1 accdant la vue des buveurs : Donner le nombre de gros buveurs. Analyser le plan dexcution (voir le fichier rv1.sql) : select count(*) from VueBuveurs where type = 'gros'; Le plan dexcution est-il optimal ? Proposer un plan dexcution simplifi (voir le fichier rv2.sql) Le plan initial avant simplification est : ( type=gros (BuvAutre)) union ( type=gros (BuvRare))

La slection est distribue avant lunion, mais Oracle nlimine pas laccs au fragement BuvRare car il na pas connaissance de la dfinition algbrique des fragments. Pour simplifier le plan , il faut enlever laccs au fragment BuvRare car

type=gros (BuvRare)
Le plan simplifi est :

type=gros (type = rare(BuveursBig)) = (type = rare AND type=gros (BuveursBig) = ensemble vide

type=gros (BuvAutre)
Dans la relation Achats, le plus grand numro de buveurs est 100. Quelle est la cardinalit du rsultat de R3 : select * from Achats a, BuveursBig b where a.nb = b.nb and a.nb > 100 Rsulat vide : cardinalit nulle Comparer les temps dexcution des 3 requtes suivantes. Expliquer pourquoi les temps dexcution diffrent. En dduire les heuristiques que loptimiseur dOracle utilise. R3a : select * from S2BUVEURSBIG b, ACHATS a where a.nb = b.nb and a.nb > 100; R3a est rapide car la collection intrieure (selection nb>100 de Achat) ne produit aucun tuple donc pas d'accs aux buveurs R3b: select * from ACHATS a, S2BUVEURSBIG b where a.nb = b.nb and a.nb > 100 ; R3b: requte lente car la collection intrieure est BuveursBig. Oracle nutilise pas la commutativit de la jointure : Achats BuveursBig = BuveursBig Achats R3c:

ENST

BDA - 2002

page 6 v. :05/03/2003

select * from S2BUVEURSBIG b, ACHATS a where a.nb = b.nb and b.nb > 100;. R3c : requte lente. La slection (nb>100) n'est pas pousse sur Achats. Oracle ne fait pas la dduction suivante : si (a.nb=b.nb et b.nb > 100) alors a.nb > 100 donc jointure avec la totalit des Achats, puis slection aprs la jointure. Rmq : Le fait dajouter des contraintes dintgrit rfrentielle (Buveur.nb est cl primaire, et Achat.nb est une cl trangre) a-t-il une influence sur les choix de loptimiseur ?