Architecture en couche d un SGBD. Modèle de stockage. Hiérarchie mémoire. Architecture en couche d un SGBD. Disques. Disques optiques.

Transcription

1 Architecture en couche d un SGBD Interface Méthodes d accès aux données Gestion de Mémoire Analyseur sémantique Optimiseur Moteur d exécution Opérations relationnelles Gestion de Verrous Système opérationnel Gestion des Journaux Cours - Les techniques - Dans Oracle - Etude de cas Cours - Les techniques - Dans Oracle - Etude de cas Modèle de stockage Luc.Bouganim@inria.fr Parties du support empruntées à N. Anciaux, P. Pucheral, P. Bonnet, D. Shasha, Mohammed J. Zaki Architecture en couche d un SGBD Hiérarchie mémoire Interface atio Prix (approx) Accès (ns) Débit (Mo/s) Analyseur sémantique Optimiseur 0 Cache processeur 0 Go/s Moteur d exécution AM 0 Go/s (x0 - ) Opérations relationnelles Méthodes d accès aux données 0.0 Disques 0 7 0ms 00 Mo/s (x0 - ) Gestion de Mémoire Gestion de Verrous Système opérationnel Gestion des Journaux 0.00 Disques optiques 0 0 qq sec 0 Mo/s (x0 - ) 4

2 Disques Magnétiques () Utilisés comme support de stockage secondaire Les accès en lecture/écriture se font Par pages (ou blocs disque), et le coût dépend de la localisation de la page par rapport à la position de la tête de lecture Les accès disque sont donc Séquentiels (accès plus rapide à des blocs contigus) et par bloc (déterminé par la taille du bus d IO) (NB: bien sur l accès aléatoire par bloc est possible mais plus coûteux) NB : Comportement très différent des accès AM, qui sont Aléatoires (temps d accès identique pour toutes les cellules) et directs (accès unitaire aux mots mémoire, ex. b) le placement sur disque joue sur les performances des SGBDs 5 Tout stocker en mémoire? La mémoire coûte cher Octet 00 fois plus coûteux que sur disque Mémoire volatile Toujours besoin d un disque (durabilité) La hiérarchie typique pour le stockage des données Mémoire centrale (AM) Données accédées couramment Stockage primaire Disque Base de données originale Stockage secondaire CD/bandes Archive des anciennes versions Stockage tertiaire 6 Disques Magnétiques () Disques Magnétiques () Caractéristiques mécaniques Vitesse de rotation : tpm Nombre de plateaux : à 0 Nombre de pistes : jusqu à Nombre d octets/piste : Tête de lecture Arbre Pistes Secteur Coûts de lecture/écriture Latence = appel au contrôleur + déplacement du bras sur la piste + placement sur le secteur Débit = vitesse de transfert des données piste plateau levier arbre tête de lecture Mouvement du bras Plateaux Ordre de grandeur des performances actuelles Appel au contrôleur = 0. ms déplacement du bras = 5 ms placement sur le secteur = 5 ms Transfert des données = 00Mo/s Contrôleur bras Bras Latence très importante à minimiser Interface (IDE, SCSI) Dennis Shasha, Philippe Bonnet Mohammed J. Zaki, Luc Bouganim, Philippe Pucheral 7 Comment optimiser les performance? 8

3 Evolutions matérielles Progression moyenne des disques Capacité + 60% par an Latence + 5% par an la plus faible des progressions Débit + 40% par an Futures technologies FLASH NAND Capacité 00 Go Latence < ms Débit 0 Mo/sec 00 fois plus cher qu un disque magnétique MEMS/NEMS (Micro/Nano Electro-Mechanical Systems) Capacité To Latence < ms Débit 00 Mo/s Pas encore opérationnel Optimisations logicielles Prefetching Le SGBD peut anticiper les patterns de requêtes Ainsi, il peut pré-charger (prefetch) des données en AM NB: le prefetching doit être géré au niveau du SGBD (vs. OS) Clustering egroupement physique des blocs de données Quand ils contiennent des données souvent utilisées ensemble Placement de ces blocs sur La même piste physique Le même cylindre physique Compromis entre bon placement et trop de perte de place Allocation d un ensemble de blocs par «granule» Calibrer la taille du granule pour chaque objet DB 9 0 Modèles de stockage des données Les données sont stockées sous forme de attributs, de taille fixe ou variable... stockés eux-mêmes sous forme de tuples... stockés dans des pages (blocs disques)... stockés dans des fichiers Stockage des tuples (attributs de taille fixe) Att Att Att Att4 T T T T4 Adresse de base (B) Adresse = B+T+T champs tuples pages fichiers appel : le SGBD gère un cache de pages en AM à la façon d une mémoire virtuelle Les informations concernant les types/tailles d attributs Sont partagées par tous les tuples d un fichier Sont stockées dans le catalogue système Accéder au i ème attribut la lecture totale du tuple

4 Stockage des tuples (att. de taille variable) Pages : tuples de taille fixe Deux alternatives de stockage (le nombre d attributs est fixe): Att Att Att Att4 4 $ $ $ $ Emplacement Emplacement Emplacement N Trou Emplacement Emplacement Emplacement N Le nombre d attributs Att Att Att Att4 Tableau d offsets des attributs La deuxième alternative offre Un accès direct au i ème attribut Un petit coût de stockage supplémentaire (taille de «offset» > taille «$») N Page compacte (pas de trou) Nombre de tuples... 0 M M... Bitmap (0=trous) Page éparse Emplacement M Nombre d emplacements Identifiant d un tuple (ecord id) : id = < id page, emplacement #> emarque la Clé d un tuple est un «pointeur logique», le id est un «pointeur physique» 4 Pages: tuples de taille variable id = (i,n) Page i id = (i,) id = (i,) Fichiers non ordonnés Soit la table Doctor suivante Le modèle de stockage N-aire (N-ary Storage Model) id number(4) first_name char(0) Maria Antonio Dominique gender char() F M F specialty char(0) Pediatrics Dermatology Psychology N... Pointeurs d emplacements Pointeur N vers l espace libre Nombre d emplacements Déplacement des tuples dans la page sans changer le id 5 Maria F Pediatrics Antonio M Dermatology Le modèle de stockage décomposé (Decomposition Storage Model) Optimisation des I/O Le modèle de stockage PAX (Partition Attributes Across) Optimisation du cache ID ID ID Maria ID ID Antonio ID F ID M ID F ID Pediatrics ID ID Dermatology Dominique ID ID ID Maria Antonio F M Pediatrics Dermatology ID Dominique Dominique F Psychology F Psychology Psychology 6

5 Organisations indexées Objectifs Offrir un accès rapide à tous les tuples d un fichier satisfaisant un même critère A partir d une clé (mono ou multi-attributs) Sur des fichiers ordonnés sur cette clé, ou non ordonnés, ou ordonnés sur une autre clé Moyen Créer une structure de données accélératrice associant des valeurs de clés aux adresses de tuples Index Table (ou hiérarchie de tables) implantant cet accélérateur Index primaire ou plaçant (primary or clustered) Catégories d index () Tuples du fichier organisés par rapport à l index Les tuples sont stockés «dans» l index seul index primaire par table Souvent construit par le SGBD sur la clé primaire Index secondaire ou non plaçant (secondary or unclustered) Tuples organisés indépendamment de l index Seuls les id des tuples sont «dans» l index Plusieurs index secondaires possibles par table K K Kn Page Page Page i Tuples triés sur K Clé K Clé L K K Kn Page Page Page i Tuples non triés sur L 7 8 Index dense (dense) Contient toutes les clés Adresse tous les tuples Catégories d index () Index non dense (sparse) Ne contient pas toutes les clés N adresse pas tous les tuples (e.g., adresse une seule fois chaque page) Nécessite que le fichier soit trié sur les clés Contient alors la plus grande clé de chaque bloc + l'adresse relative du bloc tuple tuple tuple Page Page Page i tuple tuple tuple Page Page Page i Catégories d index () Mais au fait Peut-on créer un index non dense non plaçant? Peut-on créer un index dense et plaçant? Peut-on créer un index primaire (c.à.d, plaçant) sur une clé secondaire (c.à.d, non discriminante)? Peut-on créer un index secondaire (c.à.d, non plaçant) sur une clé primaire (c.à.d, discriminante)? NB : Densité d un index : nb clés dans l'index nb clés dans la table 9 0

6 Catégories d index (4) Index hiérarchisés ou multi-niveaux Permet de gérer de gros index (i.e., très gros fichiers) Principe : chaque index est indexé Fonctionnement L index est trié (mais trop gros peu performant) Pourquoi l index à indexer doit-il être trié? On index l index Par un second index non dense ( ème niveau) On peut continuer (jusqu à obtenir un index non dense qui tiennent dans une seule page) Modèles de stockage des index appel : index = table(s) d association tuples (id) clé La question : comment organiser/stocker cette table? Modèle de stockage non ordonné? (Peu ou) pas utilisé pour stocker les index dans les SGBD Organisation en tas recherche séquentielle de la clé! Modèle de stockage ordonné? index bitmap, Join index Organisation arborescente e.g. index B+ Modèles basés sur du hachage Beaucoup moins utilisé (prédicats d inégalité) Index Bitmap Index Bitmap = index secondaire dense non trié A chaque clé, on associe un bitmap entrée par tuple /0 = contient oui/non la valeur Utilisési Art Berthe Nurse Zouk ) clé varie sur un domaine de faible cardinalité ) requêtes multi-critères sans sélectivité dominante Peut être vu comme une façon de compresser les listes inversées (listes de id) Art Zouk Berthe Art Zouk Berthe Art Zouk Nurse Join Index Utilisé pour retrouver une association (jointure) Stocké sous forme de tables ( seule au minimum) J : clés = clés primaire tuples = clés étrangères J : clés = clés étrangères tuples = clés primaires DocId J VisId Ex. v.visid Ex. v.docid Ex. v.docid Ex. v.visid J VisId DocId Visit (v) date price 4

7 Arbre B+ Organisation arborescente e.g., index stockés sous forme d Arbre B+ Peuvent être plaçant ou non plaçant Plaçant = les tuples sont stockés «dans» l index Non plaçant = les id sont stockés «dans» l index appel : Arbre-B+ Pour les SGBD disques, l arbre B+ est le plus utilisé Arbre B+ = index hiérarchisé (multi-niveaux) Clés des noeuds intermédiaires dupliquées dans les feuilles Feuilles chaînées accès séquentiel trié rapide 5 Utilisation d index multicritères cas part. Construction d index couvrant une requête Accès à l index (sans accès à la relation) permet de répondre Accélération drastique d un pattern de requêtes particulier Attributs à mettre dans l index couvrant Tous les attributs nécessaires à la requête Attributs intervenant dans les sélections Attributs intervenant dans les projections Exemple Pattern de requête SELECT P.nom FOM Personne P WHEE P.salaire > Y; Index couvrant Index sur la clé suivante : P.salaire, P.nom 6 Oracle Support emprunté à Pascale Borla Salamet Oracle France 7 8

8 Hiérarchie logique et physique Base de données Logique Tablespace Segment Datafiles Physique Extent Bloc OACLE Bloc OS 9 0

9 Data blocs Un data bloc est l unité de gestion de l espace disque Il est la plus petite unité d E/S Entête Tuples (row data) Espace libre (PCTFEE, PCTUSED) épertoire de tuples (row directory) épertoire de tables (table directory) 4 PCTFEE et PCTUSED Paramètre PCTFEE Pourcentage d un bloc réservé aux mises à jour futures (ordre SQL UPDATE) Quand PCTFEE est atteint : le bloc est retiré de la freelist Le paramètre PCTUSED Pourcentage d un bloc devant être libre pour pouvoir à nouveau insérer des données dans le bloc Quand PCTUSED est atteint : le bloc est remis dans la freelist 40%, par défaut Pourquoi si faible? La taille moyenne d un tuple suffirait Si Oracle remet les bloc dans la liste des blocs libre alors que ces blocs disposent de peu d espace libre, le coût des insertions nombreuses (de plusieurs tuples) sera très élevé (jusqu à IO par tuple inséré) Utilisation de PCTFEE et PCTUSED PCTFEE=0, PCTUSED=40 INSETION (Max 80% du bloc) Mise à jour SUPPESSION églage Par le DBA Par l ASS = Automatic Segment Space Management (>Oracle 8i) 5 Si PCTUSED>40, alors les insertions peuvent être effectuées 6

10 Chaînage des tuples et migration Un tuple ne tient pas dans un data block Car ce tuple est trop grand Oracle stocke les données en trop dans un espace réservé pour le segment Oracle chaîne les données Car ce tuple est mis à jour est ne tient plus (plus assez d espace libre) Oracle migre le tuple en entier dans un nouveau data block

11 Index Bitmap: combinaison de critères 4 4 Architecture en couche d un SGBD - Gestion de la mémoire - Opérateurs - Exécution de requête Interface Analyseur sémantique Optimiseur Moteur d exécution Opérations relationnelles Méthodes d accès aux données Gestion de Mémoire Gestion de Verrous Système opérationnel Gestion des Journaux 4 44

12 Objectif du module gestion de mémoire Occupation mémoire sur un serveur BD endre les pages de la BD accessibles en mémoire Mapping des pages BD en mémoire Garanti l adresse de la page pendant un laps de temps Garanti la cohérence de plusieurs copies de pages Optimiser les performances Cache des pages Coûts réseau (cohérence) Forte connexion avec le gestionnaire de verrous et de journalisation Sur un serveur SGBD, la mémoire est occupée par : le logiciel des pages BD des pages temporaires des structures de données du SGBD (globales au SGBD) des structures liées aux transactions Si le serveur n est pas dédié, on a aussi des données, programmes, etc... Intérêt d un serveur dédié? Gestion par l OS vs. par le SGBD L OS considère toutes les pages comme équivalentes Pas de connexion avec le verouillage/journalisation Application d heuristiques (LU) Utilisation d un disque de swap Le SGBD a une connaissance du contenu des pages Il peut utiliser les infos fournies aux modules de gestion de verrous et de journaux Il contrôle complètement la mémoire disponible Influence sur les algorithmes utilisés Il peut contrôler le swap Influence sur la journalisation Les caches peuvent être optimisés suivant d autres critères BD: Partie chaude / froide / active Taille de la base de données Place sur le disque du fichier BD Taille de la base de données active Taille des pages accédées à un instant donné par toutes les transactions Taille de la base de données chaude (80% des accès) Taille des pages accédées très fréquemment par toutes les transactions Taille de la base de données froide (0% des accès) Taille des pages accédées peu fréquemment par toutes les transactions La modélisation des workloads est complexe... et a une grande influence sur les algorithmes à utiliser 47 48

13 Ordres de grandeur Mémoire Virtuelle Taille de mémoire vive (AM) disponible pour le SGBD To BD mémoire...??? 00 Go BD hautes performances 0 Go BD production (banque, etc..) Go BD PME Mémoire Physique système Swapping Zone de swap Mémoire Virtuelle Systèmes bits 4 Go Systèmes 64 bits 8 exa-octets (8 millions de Tera-octets) 0, Go BD personnelles (PC...) -0 Ko Pico-BD (carte à puce) 49 P P P P 4 50 Option : Single Level Storage Option : Mapping OS / Swapping BD Mémoire Physique Mémoire Physique Swapping Mémoire Virtuelle Mémoire Virtuelle SGBD Fichier BD Fichier BD Zone de swap Le système est responsable du mapping du fichier BD sur la mémoire virtuelle mapping de la mémoire virtuelle sur la mémoire physique swapping Le système est responsable du mapping du fichier BD sur la mémoire virtuelle mapping de la mémoire virtuelle sur la mémoire physique Il peut déléguer une partie des fonctions (external pager) 5 5

14 Option : Mapping BD / Swapping BD Option 4: Mapping BD / Swapping OS Physical memory Mémoire Physique Working Memory Virtual Memory Mémoire Virtuelle Memory Cache Management Operating system Memory Cache Manager système Mapping Swapping Swapping Mapping Swapping DB Disk Swap BD Swapping disk Zone BD Zone de swap 5 54 Comment répartir la mémoire Problème de la répartition de la mémoire Query Query Op. Op. Op. Disponible Nécessaire Approche d Oracle (8i) SOT_AEA_SIZE HASH_AEA_SIZE Tuning Comment répartir la mémoire? Dans un opérateur, entre les opérateurs? Entre les requêtes? Une moyenne? Max au Min? Quand répartir la mémoire? Au moment de la compilation de la requête? Au démarrage de l exécution? Pendant l exécution? Entre les requêtes Entre les opérateurs Dans un opérateur Problème complexe!!! Et très important

15 Adapter les opérateurs à la mémoire! Le choix de la bonne implémentation d un opérateur relationnel (select, project, join, union, etc.) dépend de la requête qui le contient des caractéristiques des inputs de ses paramètres (prédicat de jointure, de sélection, etc.) des caractéristiques des données des structures d indexation existantes et beaucoup de la quantité de mémoire disponible Quels sont les différents choix? Objet de ce cours Comment choisir? Problématique d optimisation Architecture en couche d un SGBD Gestion de Mémoire Interface Analyseur sémantique Optimiseur Moteur d exécution Opérations relationnelles Méthodes d accès aux données Gestion de Verrous Système opérationnel Gestion des Journaux Les opérateurs Sélection (σ), sélection d un sous ensemble des tuples d une table Par Scan, par index Projection (π), sélection d un sous ensemble d attributs d une table Par Scan, par index, par tri ou hachage (si élimination des doublons) Jointure ( ), combinaison de deux tables sur critère Par boucles imbriquées Par index Par tri ou hachage Autres opérateurs Groupement, agrégats Différence (-), Union ( ), Intersection ( ) Chaque opérateur prend en entrée une ou deux tables et renvoie une table possibilité de composer les opérateurs pour former des plans (arbres) d exécution de requêtes Sélection σ: par Scan Algorithme Select (, Q) : For each page p de do { ead (p); For each tuple t de p { if CheckS (t, Q) then result = result t ;} ; } La solution la plus simple et la meilleure quand la sélectivité est très faible (ex: chaque page contient au moins un tuple qualifié) esult = S*, avec 0 S ATTENTION: Sélectivité faible = S élevé et vice-versa 59 60

16 Sélection σ : utilisation d un index Quand utiliser l index? Ex. Si la sélectivité est forte (S très petit) car coût(i/o aléatoire) >> coût(i/o séquentielle) SQL> SELECT * > FOM Medicament > WHEE M.Nom = N%'; Comparer les coûts d accès: ) Sans index; ) Avec index plaçant sur Nom; ) Avec index non plaçant sur Nom Médicaments = tuples, 000 pages contiguës; Noms uniformément distribués; I/O = 0ms + nbpages x 0,ms Il y a 5 % de médicaments commençant par un N (= N% ) NB : optimisation des accès aux données par index non plaçant Trouver dans l index les id qualifiés Trier les id qualifiés Accéder les tuples sur disque dans l ordre des id (pour ne pas accéder fois la même page) 6 Sélection σ : utilisation de plusieurs index Identification des index les plus sélectifs Intersection et union de listes de id de ces index Accès aux tuples dont les identifiants sont retenus Vérification du reste du critère sur les tuples résultat Exemple : (SPEC= Dentiste O SPEC= Stomatologie ) AND (ADESSE = Versailles ) AND (AGE>0) L = (S S) A Accéder aux tuples de L et vérifier le critère AGE Index bitmap permettent de combiner efficacement des critères peu sélectifs 6 Projection L opération coûteuse est l élimination des doublons SQL n élimine pas les doublons (sauf si la clause DISTINCT est spécifiée dans la requête) Algorithme SQL> SELECT DISTINCT V.id, V.doc > FOM Visite V ; Basé sur du hachage Basé sur du tri emarques sur l approche tri Le résultat est trié C est l implantation standard choisie par les éditeurs de SGBD Coût du Tri Problème récurrent en base de données La table à trier ne tient pas en mémoire Solution = algorithme de tri-fusion Nombre de passes = + log B- N / B (N = Nbre de pages à trier, B = Nbre de pages mémoire) Coût I/Os = N x (nombre de passes) Lecture et écriture (complète) des pages de la table à chaque passe Ex. 5 pages en AM, pour trier 08 pages Passe 0: 08 / 5 = monotonies triées de 5 pages chacune (sauf la dernière qui contient pages) Passe : / 4 = 6 monotonies triées de 0 pages chacune (resp. 8 pages) Passe : monotonies triées de 80 pages (et 8 pages) Passe : fichier trié de 08 pages Coût total = *08*4 = 864 I/O 6 64

17 Jointure (et opérateurs similaires) L opérateur le plus étudié en BD car le plus coûteux Variations de l algorithme de jointure Par boucle Jointure par boucles imbriquées (Block Nested Loop Join) Jointure par boucles imbriquées avec un index (Index Join) Par index Jointure par index (Index Join) Par tri Jointure par tri fusion (Sort Merge Join) Par hachage Jointure par hachage (Hash Join) Jointure par hachage de Grace (Grace Hash Join) Jointure par hachage hybride (Hybrid Hash Join) NB : ces d algorithmes peuvent êtres adaptés à d autres opérateurs binaires (intersection, différence, etc.) 65 Comparaison des algorithmes de jointure On veut joindre les tables DOCteur et VISite DOC Coût = Nombre d I/O id Nom 5 spécialité Pédiatre adiologue Pneumologue - on ne distingue pas I/O séquentielles et aléatoires - on ne compte pas le coût d écriture du résultat final (identique pour tous) Paramètres DOC = Nombre de pages occupées par DOC DOC = Nombre de tuples dans DOC DOC << VIS M = Nombre de pages mémoire disponibles (NB : quelques approximations pour simplifier les formules) 66 VIS id docid date prix Jointure Brute-Force : Nested Loop Jointure : Block Nested Loop Algorithme Join(DOC, VIS, Q) For each page p de DOC For each page q de VIS For each tuple tp de p For each tuple tq de q if Check (t, Q) then result = result (tp tq) ; Coût I/O = DOC + DOC * VIS Fonctionne quel que soit Q et quel que soit M Très sous-optimal dès que M > Algorithme DOC = table externe (outer relation) de la jointure Chargement par bloc de M- pages Choisir la table la plus petite comme table externe VIS = table interne (inner relation) de la jointure Chargement par bloc d une page en AM VIS Page V DOC Page D Page Page Page Page IN M- IN M- Coût en I/Os avec M pages de AM = DOC + DOC /M VIS IN IN AM OUT M DOC VIS Page K Page Page 67 68

18 Jointure par index Hypothèses Un index sur l attribut de jointure de VIS (ou de DOC) L index a n niveaux et tient sur p pages Principe (équi-jointure) Choisir comme table interne celle qui a un index sur l attribut de jointure (ex. VIS) et utiliser l index FO EACH tuple t D IN DOC Accède les tuples t V de VIS de clé t D.join_key // index Ajoute t D t V au résultat END FO Ex. pour chaque docteur, récupérer la clé de jointure, parcourir l index sur visite et retrouver les visites partageant cette clé Coût Coût = DOC + DOC (n+) si M= Coût = DOC + p + VIS si M = VIS + p 69 Jointure par Tri Fusion : Sort-Merge Join Principe de l algorithme : (équi-jointure DOC.id = VIS.docid) Trier DOC (resp. VIS) sur DOC.id (resp. VIS.docid) Parcourir simultanément DOC et VIS pour fusionner les tuples Produire les tuples résultat Coût du Sort-Merge Join 5 adiologue adiologue Tri des deux tables DOC ( + log M- DOC /M ) // ou 0 si DOC déjà triée VIS ( + log M- VIS /M ) // ou 0 si VIS déjà triée Fusion DOC + VIS 4 4 Etc. id 5 DOC Nom 5 Pneumologue 5 5 spécialité Pédiatre adiologue Pédiatre Pédiatre 4 4 Etc. 5 6 VIS id docid date 70 Jointure par hachage (Hash Join) Principe de l algorithme : (équi-jointure DOC.id = VIS.docid) Phase de construction (build) Charger DOC, hacher en AM en n paquets, avec n le plus grand possible Jointure par hachage (Grace Hash Join) Principe de l algorithme : (équi-jointure DOC.id = VIS.docid) Phase de construction (build) : Hacher DOC et VIS sur disque avec la même fonction h Hachage en n partitions, n est calculé de façon à ce que partition M- Phase de test (probe) Parcourir VIS, pour chaque tuple tester la table de hachage et produire les résultats VIS Page V DOC Page D Page Page Page h = h = Coût Identique à la jointure (Block-) Nested Loop! Optimise simplement le coût CPU de la jointure Page IN AM IN AM h h h= h= h= DOC h= h= h= DOC IN IN IN M- h = DOC DOC OUT M M- pages Page D+V DOC VIS Page Page 7 DOC Page V Page D VIS Coût I/O du Build = ( DOC + VIS ) Phase de test (probe) : Joindre DOC et VIS par partition Les tuples d partition de DOC joignent uniquement avec partition de VIS Charger partition de DOC (M pages), et le hacher avec h h Parcourir la partition correspondante de VIS en appliquant h Page Page Coût I/O du Probe = DOC + VIS Page Page Page Page Page Page 4 Page 5 Page Page D Page Page Page Page V Page IN AM AM IN AM h h h h=n h= h =m h= h = h = h h= h=n IN IN IN M IN IN IN M- OUT Page Page Page Page 4 Page 5 Page Page D Page Page Page Page V DOC VIS Page D+V Page Page Page 7

19 Jointure par hachage Hybride (Hybrid Hash Join) L approche Hybrid Hash Join est optimiste On suppose (espère) que la plus petite table (DOC) tient en mémoire Build : On hache cette table en n paquets comme dans l algorithme Hash join Si cette table tient en AM, build optimal Sinon, sélectionner des partitions qui vont déborder sur disque Jointure par hachage (Hybrid Hash Join) Probe Appliquer la même fonction de hachage h aux tuples de VIS Si h(t V ) correspond à une partition de DOC en mémoire, produire les résultats Sinon, écrire la partition correspondante de VIS sur disque (i.e., Build partiel) DOC VIS IN IN IN IN DOC Page Page Page D IN AM h h= h= h=n IN IN IN IN IN IN IN IN IN M VIS Page Page IN h IN IN IN IN DOC VIS IN Page Page h= h= h=n IN IN IN Page OUT IN IN Page V AM IN M IN IN IN 7 Probe Joindre (si besoin) les partitions disque de DOC et de VIS selon l algorithme Grace Hash Join 74 Coût de la jointure (Hybrid Hash Join) Coût I/O Hypothèse M = DOC /k //optimal avec k= Build : DOC + DOC (k-)/k Probe : VIS + VIS (k-)/k Probe : DOC (k-)/k + VIS (k-)/k Total = ( DOC + VIS ) x ( + (k-)/k) I/Os Avec n = ( DOC + VIS ) I/Os Technique implantée dans la plupart les SGBD commerciaux Oracle, MS SQL Server, IBM DB, 75 Condition générale de jointure NB : pour l instant, equi-jointure mono-attribut Equi-jointure multi-attributs Jointure par boucle Supporte sans modification toute condition de jointure Jointure par index Sans modification si index multi-attributs Sinon, utilisation de l index mono-attribut suivi d un test systématique des autres prédicats de la condition Jointure par tri fusion ou hachage Prendre en compte la combinaison des attributs comme clé de jointure Inequi-jointures Jointure par boucle Sans modification (et probablement optimal pour ce type de jointure) Jointure par index et tri-fusion adaptables mais avec un coût très Jointure par hachage inappliquable 76

20 Groupements et agrégats Autres opérateurs Les tuples peuvent être groupés par tri ou hachage Optimisation: calculer l agrégat en même temps que le groupement évite une seconde passe et réduit le nb d I/O du groupement en maintenant en AM le calcul intermédiaire plutôt que de la liste des tuples membres) Union ( ), intersection ( ) et différence ( ) Adaptation des algorithmes de jointure (exemples) S Évaluer la condition de jointure sur tous les attributs clé et projeter sur les attributs d une seule des deux tables S Évaluer la condition de jointure sur tous les attributs clé etirer de tous les tuples qui joignent et produire le résultat S Calculer ( S) + S, où + est une simple concaténation 77 CONCLUSION Pour chaque opérateur de l algèbre, plusieurs implémentations possibles Pas d'algorithme systématiquement meilleur! Le bon choix dépend de : La taille des tables opérandes La quantité de AM affectée à l opérateur L organisation des tables (indexées, hachées) la sélectivité de la condition de jointure (PS: 90% des jointures sont des équi-jointures sur clé) Nécessité d'un modèle de coût précis et d un optimiseur de requêtes Mais encore faut-il que l administrateur BD ait produit les conditions d un bon choix! 78 Architecture en couche d un SGBD Exécution d une requête Interface Analyseur sémantique Optimiseur Moteur d exécution Combinaison d opérateurs physiques Ex. Implantation physique de la jointure Deux opérateurs Build : construction de la table de hachage Probe : test avec la table de hachage Les opérateurs physique s interfacent σ π Probe Build Scan Scan DOC VIS Gestion de Mémoire Opérations relationnelles Méthodes d accès aux données Gestion de Verrous Gestion des Journaux eprésentation sous forme d arbre d opérateurs alternatives d exécution d un arbre d opérateurs Avec matérialisation En pipeline Système opérationnel 79 80

21 Exécution pipeline () Plusieurs opérateurs fonctionnent simultanément Sans écrire de résultat intermédiaire (se passe directement les tuples résultats) π Ils forment alors une chaîne pipeline Ex. Dans l arbre ci-contre σage > Accéder VIS et construire la table de hachage Accéder DOC et sélectionner (age > ) Scan DOC Passer chaque tuple résultat au probe Lire les DOC sélectionnés et tester avec la table de hachage Passer chaque tuple résultat à la projection Lire le résultat de la jointure et effecteur les projection Probe Build Scan VIS Implantation sous forme d itérateur Le modèle iterateur Interface uniforme et générale pour tous les operateurs physiques Chaque opérateur est décomposé en trois méthodes Open() alloue la mémoire, effectue l initialisation Next() renvoie un tuple résultat (ou end of file eof) Close() libère la mémoire et rend la main Efficacité du pipeline Moins de résultat temporaire moins d I/Os Les opérateurs produisent des tuples dès qu ils en consomment 8 8 Execution d un arbre d itérateurs () Execution d un arbre d itérateurs () scans S probe project probe build build scan scant T project.open(){ probe.open{ build.open() { // hach table de T scant.open(); t = scan.next() while (! eof) { t = scant.next(); insert t in table } scant.close(); } build.close(); probe.open() { build.open() { // hash table de...} build.close(); scans.open(); } } 8 scans S probe project probe build build scan scant T } project.next(){ probe.next { probe.next() { s = scans.next(); test table de avec s; return tuple rs; } test table de T avec rs; return tuple rst; } rstp=projection(rst); return rstp; 84

22 L architecture d Oracle 8 Définition d une instance Oracle A chaque démarrage Oracle lance des processus, de différents types Processus utilisateurs Processus serveurs Processus background Oracle alloue un espace mémoire Partagé par tous les processus (SGA, System Global Area) Privé à chaque processus du système (PGA, Program Global Area) Ce qui définit une Instance Oracle : SGA + processus background de cette SGA + leurs PGAs Une instance peut être dans 4 états Stoppée; démarrée; démarrée et montée; démarrée montée et ouverte BD totalement utilisable instance démarrée montée et ouverte NB: instance correspond à N utilisateurs La Structure Mémoire d Oracle () La Structure Mémoire d Oracle () Décomposée de la façon suivante Zone de code logicielle (Software Code Area) Stocke le code Oracle Zone mémoire des Instances Oracle (SGAs) Zone mémoire partagée par les instances Oracle (Shared Pool) Cache de données du dictionnaire Espace de travail mémoire d Oracle (requêtes), etc Zone mémoire propre à une instance Oracle Cache de données de la base (Buffer Cache) Cache de mises à jour (edo Log Buffer), etc Zone mémoire privée (PGA) Zone de tris, infos de sessions, etc 87 Le paramétrage des zones mémoire les performances En particulier, la taille des Buffers du SGA Cette tâche incombe au DBA 88

23 Les Buffers du SGA Shared Pool : Stocke les méta données Structures système, procédures, et autre méta données Paramétrage : shared_pool_size Buffer Cache : Stocke les blocks lus du disque Paramétrage db_block_buffers ( Oracle8i) db_cache_size ( Oracle9i) edo log buffer : stocke les modifications (avant report sur le fichier EDO) Contient uniquement les données modifiées (et pas tout le block) (NB: le fichier EDO sert à rejouer les transactions perdues) Paramétrage : log_buffer Fonctionnement du Buffer Cache Les blocs de la liste ont états possibles free : bloc non utilisé actuellement, et non modifié consistant/disque pinned : en cours d'utilisation ce block ne peut être ré-attribué dirty : modifié non consistants/disque Structures maintenues Une table de Hachage Mapping : adresse block sur disque entrée du block en AM Une Liste LU (blocks free, pinned, dirty) Chaînage des blocs du plus récemment utilisé au moins récemment utilisé NB: utilisé = en consultation (SELECT) ou en modification (UPDATE) Une Liste DITY (blocks dirty) eportée sur le disque par le processus DBW (DataBase Witer) Les Processus Background () Les Processus Background () Une instance est partagée par plusieurs utilisateur il faut centraliser les taches (évite les problèmes de concurrence) Au démarrage de l instance PMON, SMON, DBW, LGW, CKPT, ACH PMON (Processus MONitor) Nettoie les connections terminées de façon anormales Libère les verrous Libère les ressources Défait les transactions non consolidées (commit) À l aide des ollback Segment (cf. cours transactions) SMON (System MONitor) estauration automatique des instances (e.g., sur panne CPU) 9 DBW (DataBase Writer) Participe à la gestion du buffer cache son but est de conserver le cache propre eporte les blocks modifiés (dirty) sur le disque Dans l ordre indiqué par la liste DITY Libère la mémoire correspondante aux blocs reportés LGW (LoG Writer) esponsable de l écriture du edo Buffer sur le disque Il s exécute à chaque COMMIT toutes les secondes quand le buffer est rempli au premier tiers À chaque intervention du DBW 9

24 Les Processus Background C est quoi? () CKPT (ChecKPoinT) Gestion des checkpoint ACH (ACHiver) Effectue l archivage du fichier EDO LOG Les Processus Serveur Leur tâche Analysent et exécutent les requêtes SQL Lisent les blocks de données du disque vers les Buffers de la SGA amènent les données pour l application utilisateur NB: Si l application et Oracle tournent sur la même machine les processus utilisateur et serveur sont combinés 9 94 Le dictionnaire de données Oracle 95 Support emprunté à L. Bouganim 96

25 Contenu du Dictionnaire Oracle Dictionnaire Oracle = tables systèmes en lecture seule Accès avec SQL Utilisation du dictionnaire Evolution du dictionnaire Généré au moment de la création de la DB Mis à jour automatiquement Contient des informations sur la structure de la BD Utilisateurs (privilèges, rôles) Noms et caractéristiques des objets (tables, vues, index, clusters, triggers, packages,...) Contraintes d'intégrité essources physiques allouées à la base Valeurs par défaut pour des colonnes Les autres informations générales sur la base des données Utilisé par le DBA et les utilisateurs Consultation d informations sur la structure de la BD Seulement des droits en lecture sur des vues du dictionnaire NB: seulement par des requêtes SELECT (lecture seule) Utilisé par Oracle A la connexion et pendant l exécution des requêtes Consultation d informations sur les utilisateurs et leurs privilèges Consultation d informations sur les objets de la BD Lors des requêtes SQL DDL (Data Definition Language) Modification du dictionnaire Structure Tables de base = tables fondamentales contenant les informations sur la BD Conservées dans le tablespace SYSTEM Vues de ces tables = présentation dépendant du rôle de celui qui consulte Différentes vues Les vues USE Description des objets logiques créés par un utilisateur Objets logiques = tables, index, vues, triggers, procédures SQL> SELECT table_name, comments > FOM dictionary > WHEE table_name LIKE '%CONSTAINTS%'; TABLE_NAME COMMENTS ALL_CONSTAINTS Constraint definitions on accessible tables DBA_CONSTAINTS Constraint definitions on all tables USE_CONSTAINTS Constraint definitions on user's own tables rows selected. Exemples de vues USE_ USE_TABLES Tables créées par l utilisateur USE_INDEXES Index créés par l utilisateur USE_CONSTAINTS Contraintes créées par l utilisateur USE_VIEWS Informations sur les vues créées par l utilisateur SQL> SELECT table_name > FOM dictionary > WHEE table_name LIKE '%USE_%'; TABLE_NAME USE_VIEWS USE_HISTOGAMS 5 row(s) selected. La vue DICTIONAY permet d accéder aux noms/desc. des vues DBA, ALL, USE, V$ USE_USES Information sur l utilisateur 00

26 Ces vues décrivent Les vues ALL les objets créés par l utilisateur connecté (comme dans user_tables) Et aussi tous les objets accessibles à cet utilisateur Les vues ALL : exemple La vue ALL_CONSTAINTS Contraintes des tables accessibles à l utilisateur Dans user_tables SQL> desc user_tables; Nom TABLE_NAME Dans all_tables SQL> desc all_tables; Nom OWNE TABLE_NAME Exemples de vues ALL_ SQL> SELECT table_name FOM all_tables; SQL> SELECT username FOM all_users; SQL> SELECT index_name FOM all_indexes; SQL> SELECT table_name, constraint_name FOM all_constraints; 0 0 Les vues DBA () Décrivent tous les objets de la base Sur certains objets, la description est plus complète Accessibles qu aux utilisateurs Ayant le rôle SELECT_CATALOG_OLE Ou ayant le privilège système SELECT ANY DICTIONAY Ex. La vue DBA_SEGMENTS SQL> SELECT tablespace_name, sum(bytes)/04 "OCCUPE (K)" > FOM dba_segments > GOUP BY tablespace_name; TABLESPACE_NAME OCCUPE (K) CWMLITE 6080 DSYS 787 EXAMPLE SYSTEM 457 TOOLS 5888 UNDOTBS 5480 Ex. La vue DBA_TABLES Les vues DBA () Ex. La vue DBA_SYS_PIVS Privilèges systèmes octroyés aux utilisateurs et aux rôles SQL> SELECT * FOM dba_sys_privs > WHEE grantee='dba'; GANTEE PIVILEGE ADM DBA ALTE ANY CLUSTE YES DBA ALTE ANY INDEX YES DBA ALTE ANY LIBAY YES... SQL> SELECT table_name, num_rows, blocks, < empty_blocks, avg_space > FOM dba_tables > WHEE table_name= Livre ; TABLE_NAME NUM_OWS BLOCKS EMPTY_BLOCKS AVG_SPACE LIVE row(s) selected. 6 row(s) selected. 0 04

27 Les vues dynamiques V$ () Vues dont les informations sont «dynamiques» Evoluent du démarrage de l instance jusqu à son arrêt Décrivent l activité de la DB et de l instance Sont appelées «dynamiques» mais en fait, elle externalise l état de variables internes à Oracle Usage de ces données Principalement pour l amélioration des performances de la BD Les vues dynamiques V$ () Ex. V$SGA (voir premier cours...) Informations sur la «System Global Area» (SGA) SQL> SELECT * FOM V$SGA; NAME VALUE Fixed Size 495 Variable Size Database Buffers edo Buffers 778 Ex. V$Session SQL> SELECT sid, serial#, username, type, status > FOM v$session; V$LOGFILE : détail des fichiers redo-log SID SEIAL# USENAME TYPE STATUS BACKGOUND ACTIVE 8 6 HEUTEL USE INACTIVE Le DBA peut déconnecter les utilisateurs avec la commande suivante SQL> SELECT * FOM v$logfile; GOUP# STATUS MEMBE STALE E:\OANT\DATABASE\LOG4OCL.OA STALE E:\OANT\DATABASE\LOGOCL.OA STALE E:\OANT\DATABASE\LOGOCL.OA 4 E:\OANT\DATABASE\LOGOCL.OA SQL> ALTE SYSTEM KILL SESSION 8,6 ; Table DUAL Elle permet de récupérer la date système (SYSDATE) tester le formatage de données de type DATE tester le bon «parenthésage» d'expressions etc. Possède une seule colonne (DUMMY) et un seul tuple SQL> SELECT TO_CHA(SYSDATE,'DD-MM-YYYY HH4:MI') > FOM DUAL; TO_CHA(SYSDATE,'DD-MM-YYYY HH4:MI') :05 SQL> SELECT 89456/56 FOM dual; 89456/ Quelques vues intéressantes () Instance Oracle V$DATABASE: Statut de la base de données V$INSTANCE: Détails sur l instance V$PAAMETE: Paramètres d initialisation de l instance V$POCESS: Processus lancés par l instance et les utilisateurs V$SGASTAT: Détail de l occupation mémoire de votre SGA Structure logique DBA_EXTENTS : Description des Extents composant les Segments de la base de données DBA_FEE_SPACE : Extensions libres dans tous les Tablespaces DBA_SEGMENTS : Allocation d espace disque de tous les Segments de la base de données 08

28 Quelques vues intéressantes () Optimisation de equêtes Structure physique V$CONTOLFILE : Liste des fichiers de contrôle de votre BD V$DATAFILE: Détail des fichiers de données de la BD V$TABLESPACE : Tablespaces de la base de données Utilisateurs et droits DBA_OLE_PIVS : ôles reçus et donnés de la BD DBA_USES : Informations concernant les utilisateurs déclarés de la base de données V$SESSION : Détail de toutes les sessions actives de l instance Objets du schéma DBA_TABLES : Description des tables relationnelles de la BD DBA_INDEXES: Description de tous les index de la BD DBA_CLUSTES: Description de tous les clusters de la BD Introduction Evaluation de requêtes Etape. Contrôle syntaxique et sémantique Etape. Simplification de requêtes Etape. estructuration algébrique Etape 4. Choix du meilleur plan Etape 5. Exécution Difficultés de l optimisation L optimisation dans Oracle Etude de cas Support construit à partir des slides de N.Anciaux, P Borlat (Oracle Fr), P. Pucheral et. amakrishnan 09 0 Architecture en couche d un SGBD Traduction SQL Algèbre Interface Analyseur sémantique Optimiseur Select From Where Moteur d exécution Opérations relationnelles Méthodes d accès aux données equête SQL Arbre logique Arbre Physique Gestion de Mémoire Gestion de Verrous Système opérationnel Gestion des Journaux Traduction

29 Optimisation «logique» Optimisation «Physique» Patients π σ Select Patients.Nom, Patients.Prénom From Patients, Visites Where Patients.Id-P = Visites.Id-P and Patients.Ville = Paris and Visites.Date = 5 juin π σ Visites Patients π π σ Visites π σ Patients π π σ Visites Jointure Nested Loop Join? Index Join? Hash Join? Sort Merge Join? Sélection FTS (Full Table Scan)? Index Scan (B+tree)? Index Scan (Bitmap)? 4 Optimiser : pour quoi faire? Qui optimise? Une question Plusieurs expressions équivalentes en SQL Plusieurs expressions équivalentes en algèbre Plusieurs algorithmes équivalents Coût Plans sémantiquement équivalents Variation de performance de plusieurs ordres de magnitude Ex: 5 jointures 60 plans possibles 0 jointures 7 Milliards de plans 5 Dans la théorie requêtes SQL équivalentes (i.e., donnant le même résultat) doivent, après optimisation, produire le même plan d exécution (i.e., le meilleur)! Seuls les concepteurs de SGBD (noyau) devraient avoir besoin de comprendre l optimisation pour développer un bon optimiseur de requêtes Mais dans la pratique Les algorithmes ont leurs limites ( requêtes équivalentes peuvent ne pas être identifiées comme telles) Le bon choix dépend souvent des données (distribution, taille, sélectivité), dont la connaissance est approximative Le bon choix dépend également de ce que l on souhaite optimiser (ressources, temps d exécution, latence?) Enfin, seuls les plans d exécution rendus possibles par le schéma physique de la BD sont évalués 6

30 Qu est-ce qu un plan optimal? But de l optimisation Trouver le plan d exécution optimal pour une requête? Ce qu on entend par optimal Donnant les résultats le + vite. Optimisation pour le temps de réponse Minimisant la consommation de ressources Optimisation du travail total Minimisant le temps de délivrance des premiers tuples Optimisation de la latence (temps de retour du premier tuple) Etape : Contrôle syntaxique & sémantique Analyse syntaxique Vérification de la syntaxe de la requête Et sa cohérence vis-à-vis du schéma de la base elations et attributs impliqués, typage, etc. Analyse sémantique Vérification de la signifiance de la question Voir si la requête est correcte, non contradictoire, faisable, etc notions permettant l analyse sémantique des requêtes Graphe de connexion des relations Graphe de connexion des attributs 7 8 Exemple On considère le schéma de base de données suivant Visites (vis_id, nom_patient, prénom_patient, adresse, region) Presc (vis_id,med_id, date, quantité) Medic (med_id, labo, region, type, label) La requête suivante «Nom et prénom des patients visités dans le Béarn à qui on a prescrit des médicament du laboratoire OCHE de type antibiotique de numéro de label < 4 après le 0 août 006» Vérifier la correction de la question () Notion : Construction du graphe de connexion des relations Un sommet est associé à chaque relation Une jointure est représentée par un arc Une sélection par une boucle sur une relation Une projection par un arc vers le noeud résultat P.date>=" " P Exprimée en SQL SELECT nom_patient, prénom_patient FOM Medic M, Presc P, Visites V WHEE M.type = 076 AND M.label < 4 AND M.labo = "OCHE" AND P.date >= " " AND V.region = "BEAN" AND V.vis_id = P.vis_id AND P.med_id = M.med_id 9 ésultat nom_patient, prénom_patient V.vis_id=P.vis_id V V.région="Béarn" M.med_id=P.med_id Graphe non connexe Question incorrecte (relation isolée) Un graphe est connexe si et seulement si points quelconques du graphe sont toujours reliés par un chemin M M.label<4 & M.labo="oche" 0

31 Vérifier la correction de la question () Notion : Construction du graphe de connexion des attributs Un sommet est associé à chaque référence d attribut ou de constante Un arc de la forme ai c aj représente ai aj+c Une inégalité est matérialisée par arcs valués par 0 graphe avec un cycle dont la somme des valuations est négative Question contradictoire 0 M.label 4 M.labo 0 0 oche 0 P.date V.region V.vis_id P.med_id BEAN P.vis_id M.med_id Vérifier la correction de la question () Ex. SELECT * FOM Medic M, Presc P WHEE M.type = 978 AND P.date <= 976 AND M.type = P.date M.type Cycle de valuation - sélection infaisable P.date Etape : Simplification de requêtes (). Utilisation de la logique des prédicats Ex. equête initiale SELECT * FOM Medic M WHEE ((M.label = ) O (M.labo = WHITEHALL') O (M.labo = AVENTIS')) AND NOT ((M.labo = WHITEHALL') O (M.labo = AVENTIS ')); Critère: ((P Q ) NOT (Q )) P NOT Q NOT equête équivalente avec critère simplifié SELECT * FOM Medic M WHEE (M.label = ) P AND NOT (M.labo = ' WHITEHALL') Q AND NOT (V.labo = 'AVENTIS'); P Q Q Pourquoi une requête aussi stupide? ) c est une requête sur une vue ) une requête construite par programme ) une requête générée par une IHM avec clics successifs... Simplification de requêtes (). Utilisation de contraintes d intégrité Contraintes contradictoires avec la qualification SELECT * FOM Medic WHEE labo = 'oche AND label < 0 Contrainte d intégrité sur Medic : labo = 'oche' label > SELECT * FOM Medic WHEE labo = 'oche' AND label < 0 AND label > Inutile d exécuter la requête : 0 tuple résultat Complément de la requête SELECT * FOM Medic WHEE labo = 'oche' Il existe un index sur Medic.label (mais pas sur Medic.labo) SELECT * FOM Medic WHEE labo = 'oche AND label > L index est utilisable pour évaluer la requête 4

32 Etape : estructuration algébrique Ex. Plan d exécution candidat () Convention de représentation des opérateurs Selection Projection M.labo= OCHE V.med_id, V.labo Jointure Group by S Ξ.a = S.b Différence Union _ U S S Produit Cartésien X S Intersection _ S 5 equête «Nom des patients visités dans le Béarn à qui on a prescrit des médicaments du laboratoire OCHE de numéro de label = 7 après le 0 août 006» vis_id = med_id vis_id med_id V P M Plan candidat N = V.nom_patient labo = oche" ^ egion = Béarn" ^ date > "0/08/006" ^ label = 7 6 vis_id Ex. Plan d exécution candidat () = egion = Béarn" Plan candidat N Plan candidat N med_id vis_id = date> "0/08/006" nom_patient prénom_patient med_id labo = oche" ^ label = 7 vis_id = egion = Béarn" nom_patient prénom_patient vis_id med_id = date > "0/08/006" med_id labo = oche" ^ label = 7 estructuration algébrique : objectif Problème Suivant l ordre des opérateurs algébriques dans un arbre, le coût d exécution est différent Pourquoi? Certains opérateurs diminuent le volume de données alors que d autres peuvent l augmenter Le coût des algorithmes varie en fonction du volume de données à traiter (progression logarithmique, linéaire, exponentielle) Certains opérateurs/algorithmes changent l organisation (tri, placement) des tables opérandes V P M V P M De ces arbres, lequel est le meilleur? Le premier est sûrement moins bon, mais les derniers? 7 La restructuration algébrique Consiste à transformer l arbre pour en minimiser le coût En exploitant les équivalences d expression de l algèbre relationnelle 8

33 Equivalences de l algèbre relationnelle Deux expressions algébriques sont équivalentes SSI elles produisent le même résultat Exemples de règles d équivalence Sélections σ c (σ c ( σ cn (Doc))) σ c c cn (Doc) (Groupement) σ c (σ c (Doc)) σ c (σ c (Doc)) (Commutativité) Projections π a (π a ( π an (Doc))) π a,, an (Doc) (Groupement) Jointures Doc (Vis Pres) (Doc Vis) Pres (Associativité) Doc Vis Vis Doc (Commutativité) (etc) Ces équivalence permettent notamment de Changer l ordre des opérations de jointure Pousser les sélection/projection avant les jointures Autres règles d équivalence Projection commute avec sélection si la projection conserve les attributs utilisés par la sélection (Semi commutativité) Ex. π Nom (σ Nom> %D (Doc)) σ Nom> %D (π Nom (Doc)) Une sélection sur commute avec S (distributivité de σ / ) σ C ( S) (σ C ()) S, avec C critère sur attributs de σ C ( S) (σ C ()) (σ C (S)), avec C critère sur attributs de et S Si une projection suit une jointure S, on peut la pousser en retenant seulement les attributs de (et de S) nécessaires à la jointure (ou aux projection finales) (distributivité de π / ) Ex. π Nom, Date (Doc Vis) π Nom (π Nom, id (Doc) π Date, docid (Vis)) 9 0 Bilan sur les règles d équivalences Heuristique d'optimisation 5 Commutativité des.aj = a et S.Aj = b S S S Groupabilité des π Ai Aj.Ai = a Distributivité des σ / Ai,Aj S.Aj = a S Ai = a Aj = b Associativité des S Groupabilité des σ Ai = a et Aj = b A,..,Ai Aj = a T A,..,Ai Aj = a Aj et A,..,Ai S 4 T Appliquer d'abord les opérations réductrices (sélections et projections) en les groupant sur chaque relation. Dégrouper les sélections (ègle ). approcher les sélections des feuilles (ègles 4, 5 et 7). Grouper les sélections aux feuilles (ègle ) 4. approcher les projections des feuilles (ègles 4, 6 et 8) L'ordre des unions, différences et jointures est inchangé!!! Et aussi 6 Distributivité des π / Distributivité des σ / Unions & différences 7 Semi commutativité de π avec σ Distributivité des π / Unions 8

34 nom_patient prénom_patient labo = "oche" ^ egion = Béarn" ^ Label = 7 ^ date > " " vis_id = med_id vis_id V P M Exemple d'optimisation = med_id vis_id date > " " vis_id = egion = Béarn" med_id med_id nom_patient prénom_patient vis_id med_id V P M = vis_id med_id nom_patient prénom_patient nom_patient prénom_patient med_id labo = "oche" ^ Label = 7 Etape 4. Optimisation heuristique Optimisation indépendante des données Heuristiques classiques: Appliquer les heuristiques indiquées précédemment Utiliser les indexs disponibles Utiliser les meilleurs algorithmes de jointure. Hash join. Sort merge join. Nested Loop join avec index 4. Nested loop join L ordre des opérations dépends de l expression SQL Présent dans Oracle (ule Based Optimizer ou BO) 4 Etape 4. Optimisation basée coût Dépend des caractéristiques des données Présent dans Oracle (Cost Based Optimizer ou CBO) Plus efficace que le BO! Difficultés de l optimisation basée coût Espace de recherche très grand (plans candidats) n algorithmes par opérateur p ordonnancement pour les opérations binaires Graphe d'opérations Plans d'exécution (espace de recherche) Générateur de Plans Statégie de echerche Modèle de coût Plan d'exécution Optimal Schéma interne Bibliothèque de transformations Heuristiques de choix 5 Modèle de coût (choix du plan) Difficulté pour estimer le coût de chaque opérateur Difficulté encore plus importantes pour estimer la taille des résultats intermédiaires (permettant de calculer l opérateur suivant) Propagation exponentielle des erreurs (dans l arbre d exécution)! 6