Bases de Données Avancées Optimisation Travaux Pratiques ECP Lydia Khelifa, Nicolas Travers
Table des matières 1 Etudedelabasededonnées 3 1.1 Tables............................................... 3 1.2 Indexes.............................................. 3 2 Analyse de plan EXPLAIN 5 2.1 Instructions........................................... 5 2.2 Étude de plans d exécution................................... 5 2.2.1 Requêtes Simples.................................... 6 2.2.2 Requêtes dejointures.................................. 6 3 Optimisation 9 3.1 Optimisation de requête.................................... 9 3.2 EXPLAIN vers SQL....................................... 9 3.3 Scénario.............................................. 9
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 1 6528 51 1000000 FILM1 1 14336 112 499999 FILM2 1 14336 112 499999 FILM3 1 14336 112 499999 FILM4 20 14784 115.5 499999 FILM5 20 15568 121.6 499999 PK_FILM6 1 17408 136 499999 INTERNAUTE 1 6272 49 500000 NOTATION 1 1408 11 3999960 PAYS 1 8.0625 200 ROLE 1 12288 96 2999980 Avec un total de 897.1 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 FILM5. 1.2 Indexes INDEX_NAME TABLE_NAME COLUMN_NAME SUM(BLOCKS) TAILLE(Mo) ------------------------- --------------- ----------- ----------- ---------- BTREE_ARTISTE_NOM ARTISTE NOM 3840 30 BTREE_FILM2_ANNEE FILM2 ANNEE 1152 9 BTREE_FILM2_CODEPAYS FILM2 CODEPAYS 1152 9 BITMAP_FILM3_ANNEE FILM3 ANNEE 256 2 BITMAP_FILM3_CODEPAYS FILM3 CODEPAYS 256 2 PK_FILM1 FILM1 IDFILM 1024 8 PK_FILM2 FILM2 IDFILM 1792 14 PK_FILM3 FILM3 IDFILM 1792 14 PK_FILM6 FILM6 IDFILM 17408 136 PK_INTERNAUTE INTERNAUTE EMAIL 3328 26 PK_NOTATION NOTATION EMAIL 41984 328 PK_NOTATION NOTATION IDFILM --- PK_PAYS PAYS CODE 8.0625 PK_ROLE ROLE IDACTEUR 11264 88 PK_ROLE ROLE IDFILM ---
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 (17 408 pages).
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
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; 2.2.1 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; 2.2.2 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 ;
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;
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);
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: R1 1200 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
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...)