RecentChanges
|
FindPage
|
LikePages
|
BackLinks
View Source:
JointureRépartie
Note:
This page has been locked and cannot be edited.
!!! TME Jointure Répartie L'objectif de ce TME est de comprendre l'évaluation d'une requête de jointure entre 2 relations qui sont situées sur 2 sites distincts. * définir le schéma global qui offre un accès transparent à des données de plusieurs bases, * formuler une requête répartie, * comprendre l'ordre et l'emplacement des opérations permettant d'évaluer une requête répartie (quel site traite quelles opérations?). !! Scénario On dispose de 2 SGBD : site 1 et site 2 %%% Données: Le site 1 contient les Clubs (table C), le site 2 contient les Joueurs (table J) %%% La couche BDR est implémentée sur le site 1. !!Installation * créer les tables J,C,F (déjà fait lors du TME précédent) <verbatim> @base3 </verbatim> * supprimer les joueurs J du site 1 (les joueurs seront stockés sur le site 2) <verbatim> drop table J; desc J (doit répondre: "table inconnue") </verbatim> * créer la table J des joueurs dans le site 2 (le serveur du site 2 s'appelle ora10) <verbatim> connect E1234567/E1234567@ora10 --(avec votre propre numéro d'étudiant) @base3 drop table C cascade constraints; drop table F; </verbatim> * Relier les sites : ** La couche BDR (site1) doit pouvoir se connecter au site 2 <verbatim> connect E1234567/E1234567@ora11 drop database link site2; create database link site2 connect to E1234567 identified by "E1234567" using 'ora10'; --(avec votre propre numéro d'étudiant) </verbatim> * Vérifier le bon fonctionnement du lien <verbatim> desc J@site2 </verbatim> ajouter un club dans une nouvelle ville. Ce club n'a que 10 joueurs ce qui permettra, par la suite, de poser une requête de jointure très sélective. <verbatim> insert into C values( 6000, 'petit club', 2, 'Combourg'); </verbatim> !!Construire le schéma global <verbatim> create view J as select * from j@site2; </verbatim> !!Requêtes réparties Pour chaque requête, répondre aux questions * Où est traitée chaque opération (sélection, projection, jointure, ...) ? * Quelles sont les données transférées entre les sites pendant l'évaluation de la requête ? * Activer le mode de visualisation des plans et le chronométrage <verbatim> set timing on set autotrace trace explain stat </verbatim> !R1 : Jointure seule avec un transfert volumineux Afficher les joueurs avec leur club <verbatim> select * from J, C where j.cnum = c.cnum; </verbatim> !R2 : jointure avec sélection <verbatim> select * from J, C where j.cnum = c.cnum and salaire > 59000 </verbatim> La sélection est-elle poussée sur le site 2 ? !R3 Jointure très sélective * R3a : jointure très sélective et avec un transfert volumineux <verbatim> select * from J, C where j.cnum = c.cnum and ville = 'Combourg'; </verbatim> * R3b : jointure très sélective et avec un transfert faible. La directive ''driving_site'' prend en argument le nom de la variable __j1__ associée à la relation stockée sur le site dans lequel oracle doit traiter la jointure (i.e. le site 2). <verbatim> select /*+ driving_site(j1) */ * from J j1, C c1 where j1.cnum = c1.cnum and ville = 'Combourg'; </verbatim> * Proposer d'autres requête pour illustrer les optimisations de requêtes réparties vues en cours. ---- [LesTravauxDirigés], [Accueil]