NFE113 - 8 - Analyseur-Optimiseur

Conception et
Administration des
Bases de Données
Conservatoire National des Arts et
Métiers
Aix-en-Provence
Olivier Michelet
CNAM Aix en Provence -
Conception et Administration des Bases de Données
●
Les systèmes de gestion de bases de données
– Les bases de données, SGBD, Définitions
●
Conception et modélisation des Bases de Données
– La modélisation conceptuelle de données : Le modèle Entité – Association
– La normalisation
– Du modèle conceptuel au modèle relationnel
●
Architecture d’une base de données Relationnelle
– Rappels : Les systèmes de fichiers
– La Structure Physique – La Structure Logique – Le Schéma
●
Architecture d’un SGBDR
– Analyseur syntaxique, Optimiseur de Requêtes, Gestionnaire des Transactions,
Accès Concurrents, Principe de verrouillage des Données, Sécurité / Reprise
●
Mise en œuvre d’une base de données relationnelle
– Algèbre Relationnelle – Opérations Logiques
– Création / Manipulation de Bases de Données
●
Administration / Optimisation / Sécurité / Règles de programmation
●
Approche de la gestion des SI répartis et fédérés
●
Nouvelles technologies et Bases de Données
Olivier Michelet 2
●
Architecture d’une Base de Données Relationnelle
– L’Analyseur de Requête
– L’Optimiseur de Requêtes
– Le Gestionnaire de Transactions
– Les Accès Concurrents
– Les Systèmes de Sécurité – Reprise après Incidents
Olivier Michelet 3
●
Architecture d’un SGBD Relationnel
– Architecture type d’un SGBD

SYNTAXE
SEMANTIQUE
ANALYSEUR SCHEMA
VUES
CONTROLE INTEGRITE
AUTORISATIONS
ORDONNANCEMENT
META-BASE OPTIMISEUR ELABORATION
D'UN PLAN
EXECUTION
EXECUTABLE METHODES
D'ACCES
Olivier Michelet 4
●
– Les composants d’un SGBDR
Optimiseur de requête :
– décide de la meilleure stratégie d ’accès aux données, traite les requêtes et les
transforme en interne pour en faciliter l’exécution
Gestionnaire de méthodes d ’accès :
– effectue les accès physiques aux données, selon la stratégie définie par
l’optimiseur
Gestionnaire de tampon :
– responsable des transferts de page de mémoire secondaire en mémoire centrale
Système de contrôle de la fiabilité :
– préserve le contenu de la BD en cas de panne
Système de contrôle de concurrence :
– régule les accès simultanés
– empêche les incohérences en cas d’interférences entre applications
Olivier Michelet 5
●
– L’Analyseur de Requêtes
C’est un mécanisme interne qui analyse et interprète le code qui lui est soumis, pour
détecter :
- les éventuelles erreurs de codification
- les objets requis à utiliser et à mettre en œuvre pour exécuter ce code
- les éventuelles erreurs de conversion de données
Il est chargé de :
- la vérification syntaxique de la requête, en adéquation avec le langage SQL.
- puis, il doit s’assurer que ces données soient disponibles à l’utilisateur, l’étape
sémantique.
- localiser les données et les retrouver en analysant leurs différents chemins
d’accès.
Olivier Michelet 6
●
L’optimiseur de requêtes constitue la première grande fonction que le SGBDR doit

assurer lors de l’exécution de requêtes (requêtes interactives ou programme
d’application).
Son rôle est de permettre l’exécution la plus optimale (efficace) de la requête SQL.
Il doit donc fournir d’une part la meilleure stratégie d’exécution de cette requête, qui est
appelée le plan d’exécution de la requête et d’autre part libérer le programmeur de la
connaissance du fonctionnement des opérateurs SQL.
La requête de l’utilisateur sera donc analysée dans le détail jusqu’à l’obtention du
meilleur plan pour son exécution, c’est à dire celui qui nécessitera le moins
d’Entrées / Sorties disques, en inspectant les tables système du dictionnaire de
données (DD).
La qualité d’un optimiseur de requêtes est l’un des critères qui permet de juger de la
performance du SGBDR tout entier, aussi bien en terme de temps de réponse que de
charge de travail.
Olivier Michelet 7
●
Toutefois, selon le besoin (interface client ou programme batch), les contraintes peuvent
différer et ainsi requérir des fonctionnements opposés (meilleurs temps de réponse
pour une requête « simple », lecture complète de la table pour un traitement en
masse).
Le programmeur peut laisser le système décider de la meilleure stratégie ou fixer le choix
du mode d'exécution des requêtes
Pour cela, le système nécessite de s'appuyer sur des données collectées pour estimer et
calculer le meilleur plan.
Ces données sont recueillies lors de calcul et de mise à jour de statistiques de
traitement, notamment sur la profondeur de la recherche dans les index et la
distribution des données.
Ces données demandent à être régulièrement mises à jour, selon l'activité de la base.
Elles demandent à être exhaustives et récentes, pour garantir leur pertinence.
Olivier Michelet 8
●
La mise à jour des données de statistiques est effectuée à l'aide d'outils du SGBD :
- DBMS_STATS
qui effectue la collecte des informations
- ANALYZE (commande)
- COMPUTE STATISTICS (clause) sur les ordres CREATE ou ALTER INDEX
Les statistiques ainsi collectées fournissent des informations sur l'unicité et sur la
distribution des données dans la base.
L'optimiseur s'en sert pour établir des plans d'exécution d'un haut niveau de
représentativité.
Olivier Michelet 9
●
Résultat
Requête SQL
Analyse syntaxique Parseur Dictionnaire

Analyse sémantique
statistiques
Optimiseur Optimiseur ? Optimiseur

Syntaxique statistique
Générateur
de lignes
Execution SQL
Olivier Michelet 10
●
– LES ETAPES :
- Analyse de la requête
► correction et simplification des ordres
- Ordonnancement en séquence d'opérations élémentaires

► interrogation du dictionnaire des données
- Emergence des plans d'exécution
- Exécution
Olivier Michelet 11
●
Le transformateur de requête reçoit un ensemble de blocs de requêtes en provenance

du parseur. Il les analyse et examine leur coût relatif, afin de déterminer s'il est plus
avantageux de les modifier ou non.
Selon le résultat de ce calcul, les sous-requêtes sont réécrites.
L'estimateur est le coeur de l'optimiseur statistique. Il estime trois types d'indicateurs :
- la sélectivité
- la cardinalité
- le coût
Ces mesures sont interdépendantes et servent à estimer le coût global d'un plan.
Olivier Michelet 12
●
La sélectivité est calculée à partir d'un jeu de lignes sur lequel on applique le prédicat de
la requête. Elle varie entre 0 (aucune ligne retournée) et 1(toutes les lignes).
En cas d'absence de statistiques, le SGBD se base sur ces valeurs.
La cardinalité correspond au nombre de lignes de la table de base ou du jeu de lignes.

(elle dépend de la requête -jointures, sélections de colonnes,...-).
Le coût est basé sur le nombre d'E/S impliquées dans la résolution de la requête.
Le générateur de plan génère plusieurs plans et extrait celui de moindre coût

De nombreux plans sont possibles, dépendant de la complexité de la requête (tables,
jointures,...). Aussi, dès l'obtention de plan de faible coût, le générateur le sélectionne
et ne poursuit pas ses recherches. Pour accélérer cette obtention de plan, le
générateur lit d'abord les tables de faible cardinalité pour finir par celles de gros
volumes.
Olivier Michelet 13
●
L'optimisation par coût consiste à estimer le coût d’exécution de chaque opérateur d’un
arbre algébrique en fonction :
• du volume de n-uplets manipulés : nombre de pages disque ou de n-uplets lus et écrits,

• des chemins d’accès disponibles pour retrouver dans la base, les n-uplets recherchés
(lecture séquentielle, accès par hachage, utilisation d'index),
• des algorithmes possibles pour exécuter chaque opérateur (il existe 12 algorithmes
pour exécuter une jointure).
• de l’ordre d’exécution de certains opérateurs (notamment les jointures).
La somme de ces coûts donne le coût total d’exécution de l’arbre algébrique.
Olivier Michelet 14
●
Depuis le parseur
Transformateur
de requêtes
Requête transformée
Estimateur Dictionnaire
Requête + estimations
Générateur
de plan
Plan d'exécution
Olivier Michelet 15
●
Calcul de coût
Plans parallèles Plans simples
Coût de la transaction
Plans triviaux Plans simples
Olivier Michelet 16
●
L'optimiseur syntaxique transforme les requêtes notamment sur :
- les constantes
- les opérateurs LIKE, IN, ANY, SOME, ALL, BETWEEN
- NOT
- la transitivité
Olivier Michelet 17
●
– L’Optimiseur de Requêtes – Les arbres relationnels
Olivier Michelet 18
●
Olivier Michelet 19
●
Olivier Michelet 20
●
Exemple :
-Soit la Base de données :

AUDITEUR (no-auditeur, nom-auditeur)
EXAMEN (no-examen, salle, date)
PASSE-EXAMEN (#no-examen, #no-auditeur, note)
-Donnez l'arbre relationnel de la requête suivante :

Quels sont les auditeurs (noms) qui ont eu la moyenne à leur examen ?
Olivier Michelet 21
●
Olivier Michelet 22
●
1. Obtention d’une représentation canonique de la requête

2. Réécriture = transformation par :
- simplification
- ordonnancement des opérations élémentaires
3. Planning = construction des plans d'exécution candidats
- choix des algorithmes pour chaque opérateur,
- calcul du coût de chaque plan,
- choix du meilleur plan.
Etapes 1 et 2 : indépendantes des données

Etape 3 : dépendante des données
Olivier Michelet 23
●
Exécution
• recherche dans les index

• si nécessaire, transfert de blocs en mémoire centrale
• calcul de la réponse
• affichage de la réponse
Deux stratégies d ’optimisation :
• à base de règles (syntaxique)

• à base de coûts
On peut aussi incorporer des directives d’optimisation dans une requête (choix d’index,
par exemple)
Olivier Michelet 24
●
Olivier Michelet 25
●
Limites de l’optimiseur
Tout optimiseur a des limites qu’il est bon de pouvoir cerner :
en nombre maximal de tables manipulées, de jointures, de niveau d'imbrication
de sous-requêtes.
Informations fournies par l’optimiseur
Il est essentiel que l’optimiseur soit capable de fournir des renseignements sur la
façon dont il a calculé (déterminé) le plan d’exécution de la requête.
En effet, ces informations sont capitales pour l’administrateur de la base de
données afin d'ajuster l’organisation de la base de données et pour le
programmeur afin de modifier la structure de ses requêtes.
L’utilitaire le plus connu dans ce domaine est la commande EXPLAIN.
Olivier Michelet 26
●
La commande EXPLAIN affiche les plans d'exécution traités par l'optimiseur sur les
ordres SELECT, INSERT, UPDATE et DELETE
Il est composé de
- l'ordonnancement des tables participant à la requête
- la méthode d'accès pour chacune des tables
- la méthode de jointure
EXPLAIN ne permet pas de déterminer de la performance d'un ordre. Il décrit l'ensemble
des opérations effectuées par le moteur.
D'autres outils sont disponibles, tels que SQL Trace, par exemple, pour fournir plus
d'informations sur le nombre de recherches, le temps écoulé, le nombre de lectures,
le nombre de lignes retournées, etc...
Olivier Michelet 27
●
Olivier Michelet 28
●
Soit la base suivante :
Cinéma (id-cinema*, nom, adresse)

salle (id-salle*, nom, capacite,id-cinema**)
film (id-film*,titre, annee, idrealisateur**)
séance (id-seance*,heuredebut,heurefin,idsalle**,idfilm)
artiste (id-artiste*,nom,datenaissance)
* index unique
** index non unique
^ avec ou sans
Olivier Michelet 29
●
Selection Disjonctive Avec Des Index
SELECT nom FROM salle WHERE IDcinema=1098 OR capacité>150
Avec ID-cinema et Capacité : index non unique
Plan d'exécution :
0 SELECT STATEMENT
1 CONCATENATION
2 TABLE ACCESS BY ROWID SALLE
3 INDEX RANGE SCAN IDX-CAPACITE
4 TABLE ACCESS BY ROWID SALLE
5 INDEX RANGE SCAN IDX-SALLE-CINEMA-ID
Olivier Michelet 30
●
Selection Sans Index
SELECT * FROM cinema WHERE nom='Le Rex';
Plan d ’exécution :
• 0 SELECT STATEMENT
• 1 TABLE ACCESS FULL CINEMA
L'opération 1 est très coûteuse car elle balaie entièrement la table Cinéma
Olivier Michelet 31
●
Selection avec et sans index
SELECT nom FROM salle WHERE IDcinema=1098 OR nom='salle 1'
Avec IDcinema : index non unique, l ’index n ’est pas utilisé
Plan d'exécution :
0 SELECT STATEMENT
1 TABLE ACCESS FULL SALLE
Olivier Michelet 32
●
Jointure avec index
SELECT film.* FROM film, séance

WHERE film.Idfilm=seance.Idfilm;
Avec film.Idfilm : index unique
Plan d'exécution :
0 SELECT STATEMENT
1 NESTED LOOPS
2 TABLE ACCESS FULL SEANCE
3 TABLE ACCESS BY ROWID FILM
4 INDEX UNIQUE SCAN IDFILM_IDX
Olivier Michelet 33
●
Traitement des jointures
4 algorithmes
• boucles imbriquées -> si tables de grande taille Nested loop
• tri-fusion Merge (tempdb)
• hachage Hash (tempdb)
• par groupement -> en cas de cluster
Directives d ’optimisation
Choose : stratégie à base de coûts avec optimisation globale si des stats existent,
sinon à base de règles
Rule : stratégie à base de règles (défaut)
all_rows : à base de coûts avec optimisation globale
first_rows : à base de règles avec minimisation du temps de réponse
Olivier Michelet 34
●
EXEMPLE
Schéma relationnel :
ENSEIGNANT ( no-enseignant, nom, adresse )

UV ( code-uv, #no-enseignant, libellé )
EXAMEN ( numéro-examen, #code-uv, date-examen, nb-présents )
Requête :
SELECT nom
FROM ENSEIGNANT, UV, EXAMEN
WHERE ENSEIGNANT.no-enseignant = UV.no-enseignant
AND UV.code-uv = EXAMEN.code-uv
AND date-examen = 10/06/2002
Olivier Michelet 35
●
Olivier Michelet 36
●
Olivier Michelet 37
●
Parallélisation des requêtes
Olivier Michelet 38

NFE113 - 8 - Analyseur-Optimiseur

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

NFE113 - 8 - Analyseur-Optimiseur

Transféré par

Droits d'auteur :

Conception et

– Architecture type d’un SGBD

– Les composants d’un SGBDR

L’optimiseur de requêtes constitue la première grande fonction que le SGBDR doit

- COMPUTE STATISTICS (clause) sur les ordres CREATE ou ALTER INDEX

Analyse syntaxique Parseur Dictionnaire

Optimiseur Optimiseur ? Optimiseur

- Ordonnancement en séquence d'opérations élémentaires

- Emergence des plans d'exécution

Le transformateur de requête reçoit un ensemble de blocs de requêtes en provenance

La cardinalité correspond au nombre de lignes de la table de base ou du jeu de lignes.

Le générateur de plan génère plusieurs plans et extrait celui de moindre coût

• du volume de n-uplets manipulés : nombre de pages disque ou de n-uplets lus et écrits,

La somme de ces coûts donne le coût total d’exécution de l’arbre algébrique.

Plans parallèles Plans simples

Plans triviaux Plans simples

L'optimiseur syntaxique transforme les requêtes notamment sur :

-Soit la Base de données :

-Donnez l'arbre relationnel de la requête suivante :

1. Obtention d’une représentation canonique de la requête

Etapes 1 et 2 : indépendantes des données

• recherche dans les index

Deux stratégies d ’optimisation :

• à base de règles (syntaxique)

Soit la base suivante :

Cinéma (id-cinema*, nom, adresse)

Selection Disjonctive Avec Des Index

SELECT nom FROM salle WHERE IDcinema=1098 OR capacité>150

Avec ID-cinema et Capacité : index non unique

Selection Sans Index

SELECT * FROM cinema WHERE nom='Le Rex';

Selection avec et sans index

SELECT nom FROM salle WHERE IDcinema=1098 OR nom='salle 1'

Avec IDcinema : index non unique, l ’index n ’est pas utilisé

Jointure avec index

SELECT film.* FROM film, séance

Avec film.Idfilm : index unique

Traitement des jointures

ENSEIGNANT ( no-enseignant, nom, adresse )

Parallélisation des requêtes

Centres d'intérêt liés

Vous aimerez peut-être aussi