Ingénierie et Optimisation de Bases de Données - Cedric

Ingénierie et Optimisation de Bases de Données
FIP - ABD
TPs
CNAM Paris
Nicolas.Travers (at) cnam.fr
Table des matières
1 Informations sur la Base de Données
1.1 Informations sur les capacités . .
1.2 Démarrage . . . . . . . . . . . . .
1.3 Commandes pratiques . . . . . .
1.4 Schéma . . . . . . . . . . . . . . .
1.5 EXPLAIN . . . . . . . . . . . . . .
.
.
.
.
.
3
3
3
3
4
5
2 Utilisation de l’outils TOAD
2.1 Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Schéma et Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Interrogation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
8
8
3 Etude de la base de données
3.1 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
11
4 Analyse de plan EXPLAIN
4.1 Instructions . . . . . . . . .
4.2 Étude de plans d’exécution .
4.2.1 Requêtes Simples . .
4.2.2 Requêtes de jointures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
14
14
5 Optimisation
5.1 HINT . . . . . . . . . . .
5.2 Optimisation de requête
5.3 EXPLAIN vers SQL . . .
5.4 Scénario . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1 Informations sur la Base de Données
1.1
Informations sur les capacités
1. Taille totale de la base (tables + index) : 1,438 Go
2. Taille d’une page disque : 8ko
3. Mémoire centrale : 400 Mo (bridée volontairement)
1.2
Démarrage
1. La base de données utilisée pour le TP se trouve sur le serveur UNIX dept25 :
ssh dept25
2. Initialisation des variables d’environnement pour Oracle :
. oraenv (entrée) (Il y a bien un espace entre “." et “oraenv")
ORACLE_SID : orcl
Affichage d’un message Warning que vous pouvez ignorer.
3. Connexion à oracle :
sqlplus (entrée)
Login : NFE106U SER
Mdp : Ademander
Connexion hors CNAM
1. Ouvrir une console SSH (linux/Mac en natif, sinon putty.exe sous Windows qu’il faut trouver
sur le net)
2. Se connecter au serveur vlad.cnam.fr (login/mdp d’auditeur cnam et non pleiad)
3. Executer les commandes vues précédemment à partir de ssh dept25.
1.3
Commandes pratiques
! ! ! N’oubliez pas que vous pouvez sélectionner du texte avec la souris et le copier à l’aide du bouton
du milieu ! ! !
Il est conseillé de travailler avec un éditeur de texte (nedit, emacs, kedit, vim, etc...) et de recopier vos
requêtes dans le navigateur et vis-versa.
1.4. SCHÉMA
CHAPITRE 1. INFORMATIONS SUR LA BASE DE DONNÉES
;
COLUMN <nom de l’attribut> FORMAT A10
SET LINESIZE 30
CLEAR SCREEN
SELECT table_name FROM all_tables
DESC artiste
SELECT constraint_name, table_name, column_name
FROM all_cons_columns Where OWNER=’NFE106_ADMIN’
AND INDEX_NAME NOT LIKE ’%$%’
SELECT index_name, table_name, column_name FROM
all_ind_columns Where INDEX_OWNER=’NFE106_ADMIN’
AND INDEX_NAME NOT LIKE ’%$%’
show PARAMETERS db_block_size;
show PARAMETERS db_block_buffers;
select SEGMENT_NAME, BLOCKS from dba_segments
where segment_name not like ’%$%’ and SEGMENT_TYPE = ’TABLE’;
select COLUMN_NAME, DATA_TYPE, DATA_LENGTH from
ALL_TAB_COLUMNS where table_name =’ARTISTE’;
SET AUTOTRACE TRACE
ALTER SYSTEM FLUSH BUFFER_CACHE
ALTER SESSION SET OPTIMIZER_MODE=RULE
Rappel la dernière commande SQL executée
Permet d’afficher les résultats de sqlplus sur 10 caractères
Permet d’afficher 30 tuples résultats avant qu’il ne répète le schéma
Efface le contenu de l’écran
Affichage de toutes les tables
Schéma de la table artiste
Affichage des contraintes ainsi que leur affectation
Affichage des index et leur affectation
Taille d’un block (page disque)
Taille du cache (plus le cache est grand, moins le système fera d’accès disque)
Taille prise par toutes les segments de type TABLE
(il existe aussi INDEX, INDEX PARTITION, CLUSTER...
Taille prise par chaque attribut dans la table ’Artiste’
Permet d’afficher le plan d’execution EXPLAIN et les
statistiques d’exécution pour chacune des requêtes exécutées. (on peut remplacer TRACE par ON qui affichera
aussi les résultats, ou par EXPLAIN ou encore OFF)
Cette commande vide le cache mémoire réalisé durant
les dernières requêtes. Afin de mieux étudier les statistiques, il est préférable d’exécuter cette commande
avant toute requête.)
Passe en mode sans statistiques
Information pratique : Ecrivez votre requête dans un éditeur de texte (i.e. nedit). Mettez la commande ALTER SYSTEM FLUSH BUFFER_CACHE ; avant celle-ci. Ensuite, sélectionnez les deux requêtes et copiez les dans SQLPLUS via le bouton du milieu de la souris.
1.4
Schéma
Voici une table récapitulative du schéma de la base. Pour chacun, vous pourrez identifier :
– Nom de la table ;
– Attributs et type avec :
1. PK : Attribut faisant parti de la clé primaire (Primary Key) ;
– Le nombre de tuples dans la table ;
– les contraintes et index sur les tables ’table(attributs)’ :
1. FK : Foreign Key, avec table destination
2. BITMAP : ...
3. HASH : ...
CHAPITRE 1. INFORMATIONS SUR LA BASE DE DONNÉES
Table
ARTISTE
Schema
(IDARTISTE PK NUMBER(38), NOM VARCHAR2(30), PRENOM VARCHAR2(24),
DATENAISS DATE)
(CODE PK CHAR(4), NOM VARCHAR2(31), LANGUE VARCHAR2(31))
(IDFILM PK NUMBER(38), TITRE VARCHAR2(24), ANNEE NUMBER(38), IDMES
NUMBER(38), GENRE VARCHAR2(20), RESUME VARCHAR2(300), CODEPAYS
CHAR(4))
PAYS
FILM1
Copies de FILM1
FILM2
FILM3
FILM4
FILM5
FILM6
ROLE
FK :FILM2(IDMES) :ARTISTE, FK :FILM2(CODEPAYS) :PAYS
FK :FILM3(IDMES) :ARTISTE, FK :FILM3(CODEPAYS) :PAYS
FK :FILM4(IDMES) :ARTISTE, FK :FILM4(CODEPAYS) :PAYS
FK :FILM5(IDMES) :ARTISTE, FK :FILM5(CODEPAYS) :PAYS
FK :FILM6(IDMES) :ARTISTE, FK :FILM6(CODEPAYS) :PAYS
(IDFILM PK NUMBER(38), IDACTEUR PK NUMBER(38), NOMROLE VARCHAR2(24))
INTERNAUTE
(EMAIL PK CHAR(40), NOM VARCHAR2(24), PRENOM VARCHAR2(24), REGION VARCHAR2(31))
(IDFILM PK NUMBER(38), EMAIL PK CHAR(40), NOTE NUMBER(38))
1.5. EXPLAIN
Nb tuples
1 000 000
200
500 000
Index
BTREE :ARTISTE(NOM)
Statistiques
FK :FILM1(IDMES) :ARTISTE
Années
de
1990 à 2010
FK :FILM1(CODEPAYS) :PAYS
BTREE :FILM2(ANNEE), BTREE :FILM2(CODEPAYS)
BITMAP :FILM3(ANNEE), BITMAP :FILM3(CODEPAYS)
HASH :FILM4(ANNEE)
HASH :FILM5(CODEPAYS)
ORGANIZATION INDEX
3 000 000
FK :ROLE(IDFILM) :FILM1
FK :ROLE(IDACTEUR) :ARTISTE
NOTATION
500 000
4 000 000
FK :NOTATION(IDFILM) :FILM1
FK :NOTATION(EMAIL) :INTERNAUTE
1.5
EXPLAIN
Plan d’exécution
-------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost |
-------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
14 |
518 |
2 |
|
1 | TABLE ACCESS FULL
| ARTISTE
|
14 |
518 |
2 |
-------------------------------------------------------------------Statistiques
-------------------------------------------------------------------541 recursive calls
0 db block gets
8940 consistent gets
5542 physical reads
332 redo size
2220518 bytes sent via SQL*Net to client
41729 bytes received via SQL*Net from client
3761 SQL*Net roundtrips to/from client
8 sorts (memory)
0 sorts (disk)
56386 rows processed
1. Id : Identifiant de l’opérateur ;
2. Operation : type d’opération utilisée (voir tableau récapitulatif ci-dessous) ;
3. Name : Nom de la relation utilisée ;
4. Cost : C’est le coût estimé. Ici il n’y a pas d’unité de valeur, d’ailleurs il faut prendre avec précaution
la valeur, et y préférer plutôt la lecture du plan. Ici il n’y aura de valeur que pour le CBO (CostBased Optimizer). Attention, si nous sommes en mode CHOOSE et que la requête fait appel à
plusieurs tables dont une n’a pas de statistiques calculées, Oracle choisira quand même le mode
CBO ;
5. Rows : Le nombre de lignes qu’Oracle pense transférer. Ici il faut vérifier que ce nombre est en
adéquation avec le nombre réel de lignes ramenées. Ici il s’agit d’une estimation basée sur les
statistiques de la table, d’où l’importance de calculer ces statistiques. ,
6. Bytes : Nombre d’octets qu’oracle pense transférer.
Notes de 0 à
20
1.5. EXPLAIN
CHAPITRE 1. INFORMATIONS SUR LA BASE DE DONNÉES
Voici un sous-ensemble des OPERATIONS et OPTIONS du plan d’exécution EXPLAIN (non exhaustif) :
OPERATIONS
AGGREGATE
OPTIONS
GROUP BY
AND-EQUAL
CONNECT BY
COUNTING
FILTER
FIRST ROW
FOR UPDATE
INDEX
INDEX
INDEX
UNIQUE SCAN
RANGE SCAN
RANGE SCAN DESCENDING
INTERSECTION
MARGE JOIN+
MARGE JOIN+
MINIUS
NESTED LOOPS
OUTER
NESTED LOOPS
PROJECTION
REMOTE
SEQUENCE
SORT
SORT
SORT
SORT
TABLE ACCESS
TABLE ACCESS
TABLE ACCESS
TABLE ACCESS
UNION
VIEW
OUTER
UNIQUE
GROUP BY
JOIN
ORDER BY
FULL
CLUSTER
HASH
BY ROW ID
SIGNIFICATION
Une recherche d’une seule ligne qui est le résultat de l’application d’une fonction
de group à un groupe de lignes sélectionnées.
Une opération qui a en entrée des ensembles de rowids et retourne l’intersection de
ces ensembles en éliminant les doublants. Cette opération est utilisée par le chemin
d’accès par index.
Recherche de ligne dans un ordre hiérarchique
Opération qui compte le nombre de lignes sélectionnées.
Accepte un ensemble de ligne, appliqué un filter pour en éliminer quelque unes et
retourne le reste.
Recherché de le première ligne seulement.
Opération qui recherche et verrouille les lignes pour une mise à jour
Recherche d’une seule valeur ROWID d’un index.
Recherche d’une ou plusieurs valeurs ROWID d’un index. L’index est parcouru
dans un ordre croissant.
Recherche d’un ou plusieurs ROWID d’un index. L’index est parcouru dans un
ordre décroissant.
Opération qui accepte deux ensembles et retourne l’intersection en éliminant les
doublons.
Accepte deux ensembles de lignes (chacun est trié selon un critère), combine chaque
ligne du premier ensemble avec ses correspondants du deuxième et retourne le
résultat.
MARGE JOIN pour effectuer une jointure externe
Différence de deux ensembles de lignes.
Opération qui accepte deux ensembles, l’un externe et l’autre interne. Oracle compare chaque ligne de l’ensemble externe avec chaque ligne de l’ensemble interne et
retourne celle qui satisfont une condition.
Une boucle imbriquée pour effectuer une jointure externe.
Opération interne
Recherche de données d’une base distante.
Opération nécessitant l’accès à des valeurs du séquenceur
Tri d’un ensemble de lignes pour éliminer les doublons.
Opération qui fait le tri à l’intérieur de groupes
Tri avant la jointure (MERGE-JOIN).
Tri pour un ORDER BY.
Obtention de toutes lignes d’une table.
Obtention des lignes selon la valeur de la clé d’un cluster indexé.
Obtention des lignes selon la valeur de la clé d’un hash cluster
Obtention des lignes on se basant sur les valeurs ROWID.
Union de deux ensembles avec élimination des doublons.
Opération qui utilise une vue et retourne le résultat à une autre opération.
Informations sur les statistiques :
recursive calls
db block gets
consistent gets
physical reads
redo size
sorts (disk)
sorts (memory)
Number of recursive calls generated at both the user and system level. Oracle maintains
tables used for internal processing. When Oracle needs to make a change to these tables, it
internally generates an internal SQL statement, which in turn generates a recursive call.
Number of times a CURRENT block was requested. See also "consistent gets", above.
Number of times a consistent read was requested for a block.
Total number of data blocks read from disk. This number equals the value of "physical reads
direct" plus all reads into buffer cache.
Total amount of redo generated in bytes.
Number of sort operations that required at least one disk write.
Number of sort operations that were performed completely in memory and did not require
any disk writes.
You cannot do much better than memory sorts, except maybe no sorts at all. Sorting is usually
caused by selection criteria specifications within table join SQL operations.
2 Utilisation de l’outils TOAD
L’outils TOAD de Quest© est un produit très utilisé sur le marché par les développeurs et DBA sur
des bases de données (principalement Oracle). Il permet principalement :
– Consulter le schéma et le informations sur la bases de données
– Lancer des requêtes
– Consulter le plan EXPLAIN et les statistiques
– Créer des requêtes (query builder)
– Vérifie et Lance des procédures PL/SQL
– Créer des scripts
– ...
2.1
Connexion
Sous Windows, vous pourrez trouver l’outils TOAD dans le menu :
’Quest Software / TOAD for Oracle / TOAD. . . ’ (figure 2.1)
Figure 2.1 – Ouvrir TOAD
Une fois lancé, une fenêtre de connexion s’affiche. Remplissez les informations ci-dessous :
– User/Schema : NFE106U SERPassword : Ademander
– Onglet ’Direct’ :
– Host : dept25.cnam.fr
– Port : 1521
– cocher ’SID’ : orcl
– connect as : Normal
– appuyer sur ’connect’
Voir la figure 2.2.
2.2. SCHÉMA ET STRUCTURES
CHAPITRE 2. UTILISATION DE L’OUTILS TOAD
Figure 2.2 – Connexion avec TOAD
2.2
Schéma et Structures
Maintenant que vous êtes connecté, vous pouvez consulter le schéma de la base de données, ainsi
que les différentes informations et structures qui la compose. Pour ce faire (Voir la figure 2.3) :
– Menu ’Database / Schema Browser’ (ou deuxième bouton ’Schema Browser’)
– Dans le premier menu déroulant choisir ’NFE106_ADMIN’
– Double clicker sur une table ou choisir dans la liste de gauche pour en voir le schéma
– Sélectionner l’onglet :
– ’Indexes’ pour voir les indexes associés (on pourra également y trouver le clustering Factor
pour les BTree - et IOT pour FILM6)
– ’Data’ pour visualiser quelques données
– ’Script’ pour voir les requêtes associées
– ’Partition’ pour les tables FILM4 et FILM5
– ’Stats’ pour la taille, les extensions, les tuples,
2.3
–
–
–
–
Interrogation
Menu ’Editor / New Tab / SQL Style’ ou premier bouton ’Editor’ (voir figure 2.4)
Ecrire une requête SQL dans la partie edition (il y a une règle au dessus)
Pour exécuter : Bouton ’flèche verte au dessus d’un disque dur’ (touche F9)
Onglet du bas (changent sur passage de la souris) : 1) Data Grid : le résultat de la requête 2) Trace :
Cliquer sur “Enabled” pour autotrace pour avoir les statistiques (il faut réexécuter la requête) les lignes ’DB block gets’ et ’Physical Read’ sont utiles 3) Explain Plan (Ctrl+E) : permet de voir
CHAPITRE 2. UTILISATION DE L’OUTILS TOAD
2.3. INTERROGATION
Figure 2.3 – Consultation du Schéma
le plan d’exécution
– Possibilité d’utiliser le ’Query Builder’ (4° bouton) pour générer des requêtes.
Figure 2.4 – SQL avec TOAD
2.3. INTERROGATION
CHAPITRE 2. UTILISATION DE L’OUTILS TOAD
3 Etude de la base de données
Avant de commencer, veuillez lire le chapitre 1 sur les Informations Pratiques qui vous permettront de mieux appréhender ce TP et de vous permettre de vous connecter à la base de données. Il
vous donne tous les éléments nécessaires au bon déroulement de ce TP.
Le but de ce TP est d’étudier le contenu de la base de données. Vous devrez en extraire la liste
des tables, leur taille en nombre de pages (blocks), et surtout, la liste des indexes. Cette étape est
indispensable car elle vous permettra de déduire et de comprendre les plans d’exécutions que nous
effectuerons dans les TPs suivants.
3.1
Tables
1. Donner la liste des tables du TABLESPACE_NAME ’NFE106’ (ou utilisateur ’NFE106_ADMIN’).
Utiliser la vue ’all_tables’ ;
2. Donner le nombre de segments et de pages (blocks) pour chaques objets de type ’TABLE%’
(utiliser la table OWNER=’NFE106_ADMIN’). Concernant la table FILM6, cherchez le SEGMENT_NAME=’PK_FILKM6’. Calculer pour chacune sa taille en Mo ;
3. Donner le nombre de tuples pour chacunes de ces tables ;
4. Calculer la taille moyenne d’un tuple (en octets). Puis donner la taille maximum de chaque tuple
(requête sur ALL_T AB_COLUMN S) ;
Expliquer la différence visible entre la moyenne et le max, mais aussi le nombre
de segments.
3.2
Indexes
1. Pour chaque table, donner la liste des indexes associés ;
2. Donner pour chacun de ces indexes le nombre de blocs qu’il prend (dba_segments), ainsi que sa
place en Mo (taille d’un bloc 8ko). Expliquer pourquoi certains indexes apparaissent plusieurs
fois ;
3. Donner pour chaque attribut indexé, le nombre de valeurs distinctes et pour chaque valeur
le pourcentage de tuples correspondants. Cela vous permettra de connaître les statistiques du
SGBD dans les requêtes futures.
3.2. INDEXES
CHAPITRE 3. ETUDE DE LA BASE DE DONNÉES
4 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 que vous avez étudié précédemment.
4.1
Instructions
– Nous ne souhaitons voir que le plan EXPLAIN et les statistiques, pas les résultats. Pour ce faire :
SET AUTOTRACE TRACEONLY EXPLAIN STATISTICS;
– Le mode sans statistiques permet de voir l’effet des règles de transformations :
ALTER SESSION SET OPTIMIZER_MODE=RULE;
– Le mode avec statistiques permet de voir un meilleur plan d’exécution 1 :
ALTER SESSION SET OPTIMIZER_MODE=CHOOSE;
– Afin de vider le cache avant chaque exécution 2 :
ALTER SYSTEM FLUSH BUFFER_CACHE
– Pour vous faciliter la tâche de recopie de requêtes, ouvrez un éditeur de texte 3 pour y écrire vos
requêtes puis les copier dans SQLPLUS.
– Pour enregistrer automatiquement le contenu de votre console dans un fichier, utiliser cette
commande 4 :
SPOOL mon_fichier_resultat.txt
4.2
Étude de plans d’exécution
Pour chaque requête à effectuer :
– Exécuter la requête sur les différentes versions demandées de la table FILMi (de 1 à 6) ;
– Expliquer les différences de plan d’exécution et statistiques obtenues 5 ;
– Effectuer cette requête à la fois en mode RULE et en mode STATISTICS. Expliquer les différences
obtenues ;
1.
2.
3.
4.
5.
Toujours en fonction des statistiques qui lui sont fournies
Sélectionnez une requête, puis utilisez la copie avec le bouton centrale de la sourie
nedit par exemple
A chaque exécution de cette commande, un nouveau fichier est créé. Faites le pour chaque groupe de requêtes.
En fonction de l’organisation des tables FILMs que vous avez étudié précédemment
4.2. ÉTUDE DE PLANS D’EXÉCUTION
CHAPITRE 4. 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 ;
4.2.1
Requêtes Simples
1. Toutes les tables :
SELECT TITRE FROM FILMi WHERE IDFILM=50273 ;
2. FILM1 et FILM6 :
SELECT COUNT(!) FROM FILMi WHERE IDFILM BETWEEN 50273 AND 60000 ;
3. Toutes :
SELECT TITRE FROM FILMi WHERE ANNEE=1999 ;
4. FILM2 et FILM3
SELECT COUNT(!) 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 ;
4.2.2
Requêtes de jointures
1. FILM2, FILM3 et FILM4 :
SELECT TITRE, NOM FROM FILMi F, ARTISTE A
WHERE F.IDMES=A.IDARTISTE AND ANNEE=1999;
2. FILM2, FILM3 et FILM5 :
SELECT TITRE, NOM FROM FILMi F, ARTISTE A
WHERE CODEPAYS=’aaej’ AND F.IDMES=A.IDARTISTE ;
CHAPITRE 4. ANALYSE DE PLAN EXPLAIN
4.2. ÉTUDE DE PLANS D’EXÉCUTION
3. FILM3 et FILM5 :
SELECT NOM, COUNT(!) FROM FILMi F, ARTISTE A
WHERE ANNEE=1999 AND F.IDMES=A.IDARTISTE
GROUP BY NOM ;
4. FILM3 et FILM5 :
SELECT NOM, COUNT(!) FROM ARTISTE
WHERE IDARTISTE IN
(SELECT DISTINCT IDMES FROM FILMi
WHERE ANNEE=1999)
GROUP BY NOM ;
5. FILM2, FILM3, FILM5 et FILM6 :
SELECT COUNT(!) 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
GROUP BY IDFILM) N
WHERE F.IDFILM = N.IDFILM AND AVG_NOTE > 15;
4.2. ÉTUDE DE PLANS D’EXÉCUTION
CHAPITRE 4. 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) ;
5 Optimisation
5.1
HINT
Dans cette partie, il vous est demandé d’utiliser le HINT (Full, Index, et USE_NL) dans les requêtes
suivantes. Pour rappel l’utilisateur peut forcer l’optimiseur à faire certains choix, avec la commande
/*+ HINT un_conseil */ insérée juste après le SELECT.
1.
2.
3.
5.2
SELECT TITRE FROM FILMi WHERE CODEPAYS= ’aaej’
SELECT NOM, COUNT(!) FROM ARTISTE
WHERE IDARTISTE IN
(SELECT DISTINCT IDMESFROM FILMi
WHERE ANNEE= 1999)
GROUP BY NOM ;
SELECT TITRE FROM FILMi F, NOTATION N
WHERE F.IDFILM = N. I DFILM
GROUP BY TITRE
HAVING AVG(NOTE) > 15 ;
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
HAVING count(!) > 1);
5.3. EXPLAIN VERS SQL
5.3
CHAPITRE 5. OPTIMISATION
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.
SELECT STATEMENT
HASH JOIN RIGHT SEMI
TABLE ACCESS FULL
TABLE ACCESS FULL
0
1!
2!
3
ROLE
FILM1
1 − access("IDFILM"="IDFILM")
2 − filter("NOMROLE" LIKE ’t%’)
5.4
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 1 200 fois par jour
SELECT TITRE FROM FILMi WHERE CODEPAYS= ’aaej’
R2 300 fois par jour
SELECT NOM, COUNT(!)
FROM FILMi F , ARTISTE A
WHERE ANNEE= 1999 AND F.I DMES = A.I DARTISTE
GROUP BY NOM ;
R3 100 fois par jour
SELECT TITRE FROM FILMi F, NOTATION N
WHERE F.IDFILM = N. I DFI LM
GROUP BY TITRE
HAVING AVG(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. . . )