Bases de Données Avancées

Transcription

1 Bases de Données Avancées Optimisation Travaux Pratiques ECP Lydia Khelifa, Nicolas Travers

2 Table des matières 1 Etudedelabasededonnées Tables Indexes Analyse de plan EXPLAIN Instructions Étude de plans d exécution Requêtes Simples Requêtes dejointures Optimisation Optimisation de requête EXPLAIN vers SQL Scénario

3 1Etudedelabasededonnées Afin de mieux appréhender le contenu de la base de données pour ce TP, l ensemble des informationsdes tables de la bases est résumé ci-dessous : 1.1 Tables SEGMENT_NAME NB_SEGMENTS PAGES TAILLE(Mo) NB Tuples ARTISTE FILM FILM FILM FILM FILM PK_FILM INTERNAUTE NOTATION PAYS ROLE Avec un total de Mo de données. Le nombre de segments détermine sur combien de tables physiques est stocké une table. Dans le cas de FILM4 et FILM5, ces tables sont stockés à l aide d une table de hachage de taille 20. Il y a donc 20 partitions pour ces deux tables, années pour FILM4 et codepays pour FILM Indexes INDEX_NAME TABLE_NAME COLUMN_NAME SUM(BLOCKS) TAILLE(Mo) BTREE_ARTISTE_NOM ARTISTE NOM BTREE_FILM2_ANNEE FILM2 ANNEE BTREE_FILM2_CODEPAYS FILM2 CODEPAYS BITMAP_FILM3_ANNEE FILM3 ANNEE BITMAP_FILM3_CODEPAYS FILM3 CODEPAYS PK_FILM1 FILM1 IDFILM PK_FILM2 FILM2 IDFILM PK_FILM3 FILM3 IDFILM PK_FILM6 FILM6 IDFILM PK_INTERNAUTE INTERNAUTE PK_NOTATION NOTATION PK_NOTATION NOTATION IDFILM --- PK_PAYS PAYS CODE PK_ROLE ROLE IDACTEUR PK_ROLE ROLE IDFILM ---

4 1.2. INDEXES CHAPITRE 1. ETUDE DE LA BASE DE DONNÉES Soit 433 Mo d index (2/3 des données). Il n y a pas d index de hachage sur FILM4 et FILM5 car la table est déjà partitionnée selon la fonction dehachage. Il n yadoncpas d index à part. L index PK_FILM6 est un index non-dense. Il contient les données de la table (triés sur la clé primaire) et de fait prend plus de places qu un index classique ( pages).

5 2 Analyse de plan EXPLAIN Le but de ce TP est de comprendre le fonctionnement de l optimiseur à travers l outils EXPLAIN. Vous aurez un ensemble de requêtes à effectuer sur la base de données détaillée précédemment. 2.1 Instructions Connexionàla base de données :. oraenv [BDTP] sqlplus BDAUSER //mot de passe:àdemander Nous ne souhaitons voir que le plan EXPLAIN et les statistiques, pas les résultats (à ne faire qu une fois, à chaque connexion). Pour ce faire : SET AUTOTRACE TRACEONLY EXPLAIN STATISTICS; Le mode sans statistiques (avant chaque requête sans statistique) : ALTER SESSION SET OPTIMIZER_MODE=RULE; Le mode avec statistiques (avant chaque requête avec statistique) : ALTER SESSION SET OPTIMIZER_MODE=CHOOSE; Afin de vider le cache(avant chaqueexécution) 1 : ALTER SYSTEM FLUSH BUFFER_CACHE; 2.2 Étude de plans d exécution Pour chaque requête à effectuer : Exécuter la requête sur les différentesversions demandées de la table FILM i (de 1à6); Expliquer les différencesde plan d exécution et statistiques obtenues 2 ; Effectuer cette requête à la fois en mode RULE et en mode STATISTICS. Expliquer les différences obtenues; 1. Sélectionnez une requête, puis utilisez la copie avec le bouton centrale de la souris 2. En fonction de l organisation des tables FILMs que vous avez étudié précédemment

6 2.2. ÉTUDE DE PLANS D EXÉCUTION CHAPITRE 2. ANALYSE DE PLAN EXPLAIN Exemple de suite d exécution pour une requête : ALTER SESSION SET OPTIMIZER_MODE=RULE; alter system flush buffer_cache; select titre, genre from FILM1 f where IDFILM=50273; alter system flush buffer_cache; select titre, genre from FILM6 f where IDFILM=50273; ALTER SESSION SET OPTIMIZER_MODE=CHOOSE; alter system flush buffer_cache; select titre, genre from FILM1 f where IDFILM=50273; alter system flush buffer_cache; select titre, genre from FILM6 f where IDFILM=50273; Requêtes Simples 1. Toutes les tables : SELECT TITRE FROM FILMi WHERE IDFILM=50273; 2. FILM1 et FILM6 : SELECTCOUNT( ) FROM FILMi WHERE IDFILM BETWEEN 50273AND60000; 3. Toutes : SELECT TITRE FROM FILMi WHERE ANNEE=1999; 4. FILM2 et FILM3 SELECTCOUNT( ) FROM FILMi WHERE ANNEE=1999; 5. FILM2, FILM3 et FILM5 : SELECT TITRE FROM FILMi WHERE CODEPAYS= aaej ; 6. FILM1 et FILM6 : SELECT TITRE FROM FILMi WHERE IDFILM>50273; Requêtes de jointures 1. FILM2, FILM3 et FILM4 : SELECTTITRE, NOMFROM FILMi F,ARTISTE A WHERE F.IDMES=A.IDARTISTE AND ANNEE=1999; 2. FILM2, FILM3 et FILM5 : SELECTTITRE, NOMFROM FILMi F,ARTISTE A WHERE CODEPAYS= aaej AND F.IDMES=A.IDARTISTE ;

7 CHAPITRE 2. ANALYSE DE PLAN EXPLAIN 2.2. ÉTUDE DE PLANS D EXÉCUTION 3. FILM3 et FILM5 : SELECTNOM, COUNT( )FROM FILMi F, ARTISTE A WHERE ANNEE=1999 AND F.IDMES=A.IDARTISTE GROUPBY NOM; 4. FILM3 et FILM5 : SELECTNOM, COUNT( )FROM ARTISTE WHERE IDARTISTE IN (SELECT DISTINCT IDMES FROM FILMi WHERE ANNEE=1999) GROUPBY NOM; 5. FILM2, FILM3, FILM5 et FILM6 : SELECTCOUNT( ) FROM FILMi F,ROLE R, ARTISTE A WHERE F.IDFILM=R.IDFILM AND R.IDACTEUR=A.IDARTISTE AND F.IDMES=A.IDARTISTE AND CODEPAYS= aaej AND ANNEE=1999; 6. FILM2, FILM6; SELECT TITRE FROM FILMi F, NOTATION N WHERE F.IDFILM = N.IDFILM GROUP BY TITRE HAVING AVG(NOTE) > 15; 7. FILM2, FILM6; SELECT TITRE FROM FILMi F, (SELECT IDFILM, AVG(NOTE) as AVG_NOTE FROM NOTATION N GROUPBY IDFILM) N WHERE F.IDFILM = N.IDFILM AND AVG_NOTE > 15;

8 2.2. ÉTUDE DE PLANS D EXÉCUTION CHAPITRE 2. ANALYSE DE PLAN EXPLAIN Pour aller plus loin, vous pouvez tester les requêtes mais sans vider le cache avant l exécution (faites deux exécutions successives);

9 3 Optimisation 3.1 Optimisation de requête La requête suivante n est pas optimisée. Étudier le plan EXPLAIN généré (sans cache), et proposer une nouvelle requête SQL produisant le même résultat mais avec moins d entrées/sorties (consistent get/physical read). SELECT titre FROM film1 WHERE exists ( SELECT idfilm FROM ROLE R WHERE film1.idfilm = r.idfilm and nomrole like t% GROUP BY idfilm HAVINGcount( ) > 1); 3.2 EXPLAIN vers SQL Le plan EXPLAIN ci-dessous fait des parties des fichiers de logs du DBA. Trouver la requête SQL ayant produit ce plan d exécution. 0 SELECT STATEMENT 1 HASHJOIN RIGHT SEMI 2 TABLE ACCESSFULL ROLE 3 TABLE ACCESS FULL FILM1 1 access("idfilm"="idfilm") 2 filter("nomrole" LIKE t% ) 3.3 Scénario En consultant les statistiques d accès à la base de données, on constate que celui reçoit régulièrement les trois requêtes ci-dessous avec leur fréquence: R fois parjour SELECT TITRE FROM FILMi WHERE CODEPAYS= aaej R2 300 fois par jour SELECTNOM, COUNT( ) FROM FILMi F,ARTISTE A WHERE ANNEE= 1999ANDF.I DMES = A.I DARTISTE GROUPBY NOM; R3 100 fois par jour

10 3.3. SCÉNARIO CHAPITRE3. OPTIMISATION SELECT TITRE FROM FILMi F, NOTATION N WHERE F.IDFILM = N.IDFI LM GROUP BY TITRE HAVINGAVG(NOTE)>15 ; 1. Donner un tableau de Physical Reads pour chaque requête sur chacunes des tables FILM1 à FILM6. 2. Calculer le coût généré pour chaque Filmi par jour, en fonction de la fréquence de chaque requête (le cache n est pas considéré). En déduire la table la plus optimisée pour notre cas. 3. Peut-on encore améliorer les performances du SGBD? (index supplémentaire, organisation différente, extensions...)