Administration de Bases de Données

(1)

Administration de Bases de Donn´ ees

Optimisation

Thierry Hamon

Bureau H202 Institut Galil´ee - Universit´e Paris 13

&

LISN - Universit´e Paris-Saclay hamon@limsi.fr

https://perso.limsi.fr/hamon/Teaching/P13/ABD-INFOA3-2021-2022/

INFOA3 – ABD

(2)

Optimisation d’une Application ?

Quand d´ecide-t’on d’optimiser ? Optimiser quoi ?

Qui participe, et Comment ?

Type de l’application (TP ou Batch) Int´erˆet de l’application pour l’entreprise

(3)

Quand d´ ecide-t’on d’optimiser ?

Application Batch

L’application n’est pas disponible `a partir d’une certaine heure Application transactionnelle

L’utilisateur constate que le temps de r´eponse est inacceptable (Agence de voyage, application interne, etc.)

(4)

Qui participe et pourquoi ?

Adminstrateurs de DB, Développeurs, Ingénieurs Système (IS), Chef de projet

Définition de la puissance de la machine (Nombre de processeurs, Capacité mémoire, Espace disque nécessaire en fonction du type de l’application)

Type du SGBD (Oracle, DB2, etc.) Type de l’application (Batch, TP)

Langage de programmation utilis´e (Java, PL/SQL, etc.)

(5)

Qu’est-ce qui reste ` a faire ?

Les besoins en puissance machine d´efinis

Les acteurs administrateurs BD, (IS), développeurs, etc. au courant du projet (impliqués, responsable de la réussite du projet,..)

Optimisation de la base et de l’application ?

(6)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Partie N^◦1 : Conception des syst`emes d’informations et optimisation des applications

Lors de la conception des syst`emes d’informations (si pas trop tard)

Optimisation des applications

Partie N^◦2 : Pr´esentation des outils pour assurer le suivi de la base et garantir sa performance

Optimisation de la m´emoire

Optimisation des entr´ees/sorties disque

Identifier les contentions dans la base de donn´ees

(7)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Lors de la conception des syst`emes d’informations : (Si pas trop tard)

Système non performant : résultat d’une mauvaise définition du modèle conceptuel

Mod`ele conceptuel : au moins sous la 3`eme forme Normale (3NF)

Sauf dans quelque cas (choix volontaire) o`u la

d´e-normalisation apporte une certaine performance au syst`eme d’information (Dataware house)

Lors de la conception : tenir compte l’accès aux données Analyse de la répartition des données :

réplication de données (sur une ou plusieurs bases, etc.) agrégation des tables, pour les systèmes décisionnels

(8)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Optimisation des applications :

l’expérience montre que 80% des problèmes de performances des applications, sont résolus, par une optimisation des requêtes SQL

Ordonnancer les Batchs et ´eviter leur ex´ecution pendant des heures ou l’utilisation des machine est intense

Dispatcher les Batchs les plus consommateurs en puissance machine `a des heures diff´erentes

(9)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Optimisation de la m´emoire :

d´eterminer la bonne taille des buffers de la base

(shared_pool, buffer cache, log buffer, etc) par l’utilisation des outils tels que Utlbstat/Utlestat, ou Statpack, etc.

(10)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Optimisation des entr´ees/sorties disque :

Bien dimensionner les fichiers de la base de donn´ees et placer dans des disques pr´evus pour le type d’application (Batch ou TP),

pour assurer un temps de réponse acceptable des requêtes adressées à la Base.

Ne pas oublier de recenser les disques les plus sollicit´es, les tablespaces les plus fragment´es, full table scan, etc.

(11)

Sur quoi doit-on focaliser les efforts d’optimisation ?

Identifier les contentions dans la base de donn´ees :

Etudier les locks, les latches et les wait events au niveaux de la base de donn´ees, et les ´eliminer si possible

(12)

Partie 1

Lors de la conception des syst`emes d’informations Optimisation des applications :

L’expérience montre que l’optimisation des requêtes SQL résout la majorité des problèmes de performances des applications

(13)

Objectifs de l’optimisation

Clarifier et situer les différents paramètres internes des SGBD (relationnel ; objet-relationnel) afin d’améliorer leurs

performances.

R´e´ecrire les codes SQL ; PL/SQL etc..

Restructurer les données, indexer les données, créer des vues matérialisées

Partager les données, dupliquer les données sur plusieurs disques, créer des partitions sur les données

(14)

Objectifs de l’optimisation

Intervenants :

Administrateurs de Bases de Donn´ees (ABD = DBA) Programmeurs d’Applications sur SGBD

Objectifs :

Optimiser un système existant et connaˆıtre les impacts de certains paramètres en fonction du type d’application sur le système

Choisir un SGBD en ayant comme contrainte les crit`eres de performances

(15)

Augmentation des performances

Pour augmenter les performances trois grandes solutions apparaissent :

1 Premi`ere solution (d’ordre logique) : optimiser les sch´emas conceptuel et logique pour qu’ils collent aux applications

2 Deuxi`eme solution (d’ordre physique) : optimiser les param`etres internes du SGBD

3 Autre solution (de type matérielle) : augmenter la puissance machine ou utiliser des ordinateurs spéciaux dédiés à la gestion des données.

Cette approche est plus connue sous le nom Machine Bases de Donn´ees

(16)

Optimisation logique de la Base de Donn´ ees

Optimisation du Sch´ema Relationnel

Schéma Conceptuel de Données (SCD), obtenu à la phase d’analyse

une ensemble d’Entit´es et d’Associations ou un ensemble de Classes selon le formalisme utilis´e

En EA, transformation en schéma relationnel (Schéma Logique de Données – SLD), qui permet

Implantation du SCD dans une BD relationnelle

(17)

Optimisation logique de la Base de Donn´ ees

Optimisation du Sch´ema Relationnel

Normalisation : processus permettant de s’assurer de la Bonne conception du SLD

non redondance de ses donn´ees

Cadre formel pour effectuer la normalisation : lad´ependance fonctionnelle

les formes normales(1êre^` FN, 2ême^` FN, 3ême^` FN, FNBC, 4ême^` FN, ...)

(18)

Normalisation

Exemple

Avant normalisation :

R e l a t i o n 1 ( A t t r i b u t 1 , A t t r i b u t 2 , . . . )

D´ecomposition de la relation Relation1, en deux ou plusieurs relations qui contiennent moins d’anomalies de mises `a jour (peu ou pas du tout) :

On parle de

D´ecomposition sans perte d’information

D´ecomposition sans perte de d´ependance fonctionnelle (DF) ...

Apr`es normalisation :

R e l a t i o n 1 1 ( A t t r i b u t 1 1 , A t t r i b u t 1 2 , . . . )

(19)

Normalisation

Les relations obtenues doivent ˆetre en 3^eme^` Forme Normale, au moins

→bon rapport redondance/espace occup´e Cl´e Primaire

Pas de DF entre les attributs de la clé primaire ; Pas de DF entre un sous ensemble d’attributs de la clé primaire et les attributs qui n’appartiennent pas à la clé primaire

Pas de DF entre les attributs qui n’appartiennent pas `a la cl´e primaire

(20)

Normalisation

Illustration

Format d’une relation bien con¸cue

(21)

Normalisation

Exemple

Soit la relation :

ADRESSES ( V i l l e , Num´ero , Rue , C o d e P o s t a l ) D´ecomposition de la relation

ADRESSES ( r e l a t i o n en 3`eme FN)

en deux relations CPR et CPV (en FN de Boyce et Codd) : CPR ( C o d e P o s t a l , Rue )

CPV ( C o d e P o s t a l , V i l l e )

(22)

Normalisation

Exemple

ADRESSES

VILLE NUMERO RUE CODE POSTAL

Paris 6 Rue de la Rosi`ere 75015

Paris 16 Rue de la Rosi`ere 75015

Paris 51 Rue des Entrepreneurs 75015

Paris 55 Rue des Entrepreneurs 75015

Paris 8 Avenue des Champs Elys´ees 75008 Epinay sur Seine 23 Boulevard Foch 93800

CPR CPV

CODE POSTAL RUE CODE POSTAL VILLE

75015 Rue de la Rosi`ere 75008 Paris

75015 Rue des Entrepreneurs 75015 Paris

75008 Avenue des Champs Elys´ees 93800 Epinay sur Seine 93800 Boulevard Foch

(23)

Normalisation

Exemple

Un client a une adresse : SLD version 1

CLIENT ( C o d e C l i , NomCli , P r´e n o m C l i , Num´ero , Rue , C o d e P o s t a l , V i l l e ) SELECT ∗ FROM CLIENT ;

SLD version 2

CLIENT ( C o d e C l i , NomCli , P r´e n o m C l i , Num´ero , A d r C l i∗ )

ADRCPR ( A d r C l i , Rue , C o d e P o s t a l∗) ADRCPV ( C o d e P o s t a l , V i l l e )

SELECT ∗ FROM CLIENT , ADRCPR, ADRCPV WHERE CLIENT . A d r C l i=ADRCPR . A d r C l i

AND ADRCPR . C o d e P o s t a l=ADRCPV . C o d e P o s t a l ;

(24)

Bilan

Un sch´ema relationnel normalis´e

contiendra donc un nombre plus important de relations (de tables)

pourra ainsi pénaliser certaines requêtes, qui seront obligées de procéder à des jointures plus nombreuses sur la base Or

La jointure est une opération très coûteuse

Les op´erations binaires (qui portent sur deux tables) peuvent ˆ

etre coˆuteuses

(25)

Optimisation logique de la Base de Donn´ ees

Redondance calcul´ee

Technique d’optimisation des requˆetes d’interrogation Introduction volontairement de redondances dans le sch´ema logique relationnel

Cette redondance est ditecalculée car elle tient compte des besoins des modules de traitement des données de leurs exigences en terme de temps de réponse

(26)

Optimisation logique de la Base de Donn´ ees

Redondance calcul´ee

Deux méthodes de réalisation de la redondance calculée : le stockages des données déductibles

la d´e-normalisation

(27)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles

Donn´ees d´eductibles

les résultats des requêtes les plus fréquentes des statistiques historiques

des donn´ees issues de calculs complexes

(28)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles

Dans les trois cas, stockage des donn´ees, physiquement dans la base

(sous la forme de Tables/Vues ou de Colonnes)

Avantage du stockage physique : éviter leur re-génération en cas de besoin

Inconv´enients de la redondance :

1 Place occup´ee par les donn´ees redondantes

2 Nécessité de traitements supplémentaires pour les opérations de mises à jour

3 Risque d’incoh´erence

(29)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles Exemple de requête fréquente

Base de donnéesSportAct: Adhérents à des centres sportifs CENTRE ( NumC, NomC, V i l l e C , C o u t i n s c )

ESTMEMBRE ( NumA, NumC∗, D a t e i n s c )

Requˆete fr´equente : Nombre d’inscrits dans un centre c ?

SELECT C . NumC, C . NomC, COUNT( E . NumA) FROM CENTRE C , ESTMEMBRE E

WHERE C . NumC = E . NumC AND C . NumC= c GROUP BY C . NumC ;

(30)

Optimisation logique de la Base de Donn´ ees

Cr´eation d’une nouvelle colonne NbrInscrdans la table CENTRE:

CENTRE ( NumC, NomC, V i l C , C o u t i n s c , N b r I n s c r ) Nouvel ordre SQL :

SELECT NumC, NomC, N b r I n s c r FROM CENTRE WHERE NumC=c ;

→ Suppression de 2 opérations très coûteuses : Une jointure en moins

Un groupement en moins

(31)

Optimisation logique de la Base de Donn´ ees

Impact sur le reste de la base de donn´ees

Prise en compte de cette nouveauté par les opérations de mises à jours de la table ESTMEMBRE

Modification de la colonne NbrInscr`a chaque insertion ou suppression d’inscription

→La coh´erence est affect´ee si on ne le fait pas

(32)

Optimisation logique de la Base de Donn´ ees

Chaque op´erationINSERT / DELETE implique une op´eration UPDATE

INSERT INTOESTMEMBREVALUES(....) ; doit ˆetre accompagn´ee par

UPDATE CENTRE SET N b r I n s c r=N b r I n s c r +1 ; DELETE FROM ESTMEMBREWHERE... ;doit ˆetre accompagn´ee par

UPDATE CENTRE SET N b r I n s c r=N b r I n s c r−1 ;

(33)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles Exemple de Statistiques Historiques

Requˆete : Nombre d’inscrits par centre et par mois ?

Objectif : ´eviter le recalcul `a chaque fois du nombre d’inscrits par centre et par mois

Solution : cr´eation d’une nouvelle table/vue STAT_MENS_INSCR

STAT MENS INSCR ( NumC, Mois , N b r I n s c r )

Nécessité d’un nouveau traitement mensuel pour l’actualiser avec les statistiques du mois écoulé

(34)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles Résultat de calcul complexe

Soit la base de donn´ees :

CLIENT ( C o d e C l i , NomCli , . . . )

ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t ) COMMANDE ( NumCom, C o d e C l i∗, DateCom ) DETAILCOM ( NumCom∗, C o d e A r t∗, QtéComDée ) Requête : Montant de la commande ?

(35)

Optimisation logique de la Base de Donn´ ees

Redondance calculée : stockages des données déductibles Résultat de calcul complexe

Obtention du montant de la commande :

SELECT C . NumCom, SUM(D . Qt´eComD´ee∗A . P r i x A r t ) AS Montant FROMCOMMANDE C , ARTICLE A , DETAILCOM D

WHERE C . NumCom=D . NumCom AND D . C o d e A r t=A . C o d e A r t GROUP BY C . NumCom ;

Gain d’op´eration avec la cr´eation de la colonne Montant dans la tableCOMMANDE

COMMANDE ( NumCom, C o d e C l i , DateCom , Montant ) SELECT NumCom, Montant

FROM COMMANDE ;

(36)

Optimisation logique de la Base de Donn´ ees

Redondance calcul´ee : d´e-normalisation

Autre m´ethode d’optimisation des interrogations

Transformer, si besoin est, une table de la 3ème FN en 2ème FN ou en 1ère FN

Objectif : éviter des jointures successives pouvant être coûteuses en performances

(37)

Optimisation logique de la Base de Donn´ ees

Redondance calcul´ee : d´e-normalisation Exemple

Soit la table

CLIENT ( C o d e C l i , NomCli , . . . )

ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t ) COMMANDE ( NumCom, C o d e C l i∗, DateCom ) DETAILCOM ( NumCom∗, C o d e A r t∗, Qt´eComD´ee )

DETAILCOM passe de la 3ème FN à la 1ère FN

ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t ) COMMANDE ( NumCom, C o d e C l i∗, DateCom )

DETAILCOM ( NumCom, C o d e A r t∗, Qt´eComD´ee , P r i x A r t )

Requˆete : Montant de la commande ?

SELECT NumCom, SUM( Qt´eComD´ee∗P r i x A r t ) AS Montant FROM DETAILCOM

GROUP BY NumCom ;

(38)

Optimisation logique de la Base de Donn´ ees

Redondance calcul´ee : d´e-normalisation

Inconvénients de la dé-normalisation : identiques à ceux du stockage des données déductibles

Place suppl´ementaire

P´enalisation des traitements d’insertion et de suppression Risque d’incoh´erence

Nécessite la création de déclencheurs (triggers)

(39)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL

Requête SQL : ordre passé au SGBD pour lui demander de rechercher des données spécifiées dans la requête

(sans expliciter le comment) SQL est non proc´edural

SELECT /FROM/WHERE/ GROUP BY/ HAVING /ORDER BY DISTINCT

SUM /MIN /MAX/AVG / COUNT IN /NOT IN / LIKE /NOT LIKE / EXISTS /NOT EXISTS / =ANY/>ALL INSERT /DELETE /UPDATE

CREATE /TABLE / VIEW/ INDEX

(40)

Optimisation logique de la Base de Donn´ ees

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL

Plusieurs agencements sont souvent possibles :

au niveau de l’ordre dans lequel les conditions sont exprim´ees dans la clauseWHERE :

WHERE c o n d i t i o n 1 AND c o n d i t i o n 2 WHERE c o n d i t i o n 2 AND c o n d i t i o n 1

(41)

Optimisation logique de la Base de Donn´ ees

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL

Plusieurs agencements sont souvent possibles : au niveau des op´erations alg´ebriques

Possibilité d’utiliser plusieurs méthodes différentes pour exprimer la même chose

La jointure : possibilité d’exprimer l’opération de plusieurs manières différentes

R = Jointure ( R1, R2, {R1.A=R2.A} )

= Jointure ( R2, R1, {R2.A=R1.A} )

SELECT ∗ FROM R1 , R2 WHERE R1 . A = R2 . A ; SELECT ∗ FROM R2 , R1 WHERE R2 . A = R1 . A ;

(42)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Expression de la jointure

M´ethode pr´edicative

SELECT ∗ FROM R1 , R2 WHERE R1 . A=R2 . A ; M´ethodes ensemblistes

SELECT ∗ FROM R1 WHERE A IN (SELECT A FROM R2 ) ; SELECT ∗ FROM R1 WHERE A =ANY (SELECT A FROM R2 ) ; SELECT ∗ FROM R1 WHERE EXISTS

(SELECT ∗ FROM R2 WHERE R1 . A=R2 . A ) ; SELECT ∗ FROM R1 WHERE 0 <

(43)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Exemple de dur´ee d’ex´ecution – SQLPlus SETTIMINGON

Ex´ecution de la requˆete ; SELECT...FROM ...

→ Oracle vous donne le temps écoulé Méthode prédicative :

s e l e c t ∗ from a l l t a b l e s t1 , a l l c o n s t r a i n t s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ; temps CPU : 1 091 480 u n i t é s 451 100 u n i t é s s e l e c t ∗ from a l l c o n s t r a i n t s t1 , a l l t a b l e s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ; temps CPU : 976 790 u n i t é s 690 690 u n i t é s

(44)

Optimisation logique de la Base de Donn´ ees

Exemple de dur´ee d’ex´ecution – SQLPlus

M´ethodes ensemblistes :

s e l e c t ∗ from a l l c o n s t r a i n t s where t a b l e n a m e i n (s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU : 138 350 u n i t ´e s 139 230 u n i t ´e s s e l e c t ∗ from a l l c o n s t r a i n t s where t a b l e n a m e

= any (s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU : 139 630 u n i t ´e s 139 890 u n i t ´e s s e l e c t ∗ from a l l c o n s t r a i n t s t 1 where e x i s t s

(s e l e c t ∗ from a l l t a b l e s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ) ;

(45)

Optimisation logique de la Base de Donn´ ees

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL :

Plusieurs agencements sont souvent possibles

Possibilité d’utiliser plusieurs méthodes différentes pour exprimer la même chose

La diff´erence :

R = Diff´erence ( R1, R2 )

SELECT ∗ FROM R1 MINUS SELECT ∗ FROM R2 ;

(46)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Expression de la diff´erence

SELECT A FROM R1 MINUS SELECT A FROM R2 ;

SELECT A FROM R1 WHERE A NOT IN (SELECT A FROM R2 ) ; SELECT A FROM R1 WHERE NOT EXISTS

(SELECT A FROM R2 WHERE R1 . A=R2 . A ) ; SELECT A FROM R1 WHERE 0 =

(SELECT COUNT(∗) FROM R2 WHERE R1 . A=R2 . A ) ;

(47)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Utilisation des vues

Mauvais code :

S e l e c t e .∗ from EMP e where e . s a l a r y > (

s e l e c t avg( s a l a r y ) from EMP i

where i . d e p i d = e . d e p i d ) ;

Bon code

S e l e c t e .∗ from EMP e ,

(S e l e c t i . d e p i d DEP , avg( i . s a l a r y ) SAL from EMP i group by i . d e p i d ) EMP VUE where e . d e p i d = EMP VUE . d e p i d and

e . s a l a r y > EMP VUE . SAL ;

(48)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Vues mat´erialis´ees

Présentation des vues matérialisées :

Cr´eation d’une vue physique d’une table Duplication des donn´ees

Définition de vues matérialisées à partir de tables, de vues, et de vues matérialisées

Possibilité de décalage entre la table maˆıtre et la vue matérialisée : gestion de la fraicheur des données de la vue matérialisée (refresh)

(49)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Vues mat´erialis´ees

Utilisation des vues mat´erialis´ees :

Optimisation/amélioration des performances Ré-écriture des requêtes portant sur des tables

selectparticuli`erement complexe ou lourd r´eplication de table

(50)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Utilisation de vues mat´erialis´ees

Inconv´enients :

Résultat de la requête stocké valable à un instant t

en fonction des paramètres, la vue matérialisée sera tenue à jour ou non quand la table change

Entretien des vues en temps r´eel : coˆuteux (et peu souvent mis en œuvre)

(51)

Optimisation logique de la Base de Donn´ ees

Optimisation des ordres SQL Utilisation de vues mat´erialis´ees

Avantages

Simple réécriture de requête et exécution de requêtes imbriquées

Lorsqu’il n’est nécessaire de disposer des données en temps réel, économie d’interrogation

Exemple : analyse de chiffres économiques de la veille données figées

intérêt à stocker des résultats (qui ne changeront plus !) Utilisation dans les datawarehouse : problématique de performances

(52)

Gestion physique des donn´ ees

Adaptation et enrichissement du SLD pour tenir compte des sp´ecificit´es du SGBD

des performances des traitements et de la sécurité A ce stade d’élaboration du schéma physique de données, on dispose :

du SLD normalis´e ou non

du schéma physique de traitement (description détaillée des modules)

(53)

Gestion physique des donn´ ees

Résultat : Schéma Physique des Données (SPD)

représentation de la structure définitive de la base de données telle qu’elle doit être implantée

prise en compte

des caract´eristiques technique du SGBD et du mat´eriel des exigences en interfaces et en performances des modules de programmation

Si le mat´eriel ou le SGBD change alors il faut changer le SPD (les exigences changent)

(54)

Gestion physique des donn´ ees

Etat des lieux : des tables en 3`eme FN, ou autre etc. bien con¸cues

Objectifs :

optimisation des acc`es en choisissant les colonnes qui doivent ˆ

etre index´ees

introduction (éventuellement) de redondances calculées définition de vues standards et des vues matérialisées définition des contraintes d’intégrité et des déclencheurs sur les tables

(55)

Gestion physique des donn´ ees

création des tables et des colonnestechniques définition des droits d’accès aux données

répartition des tables sur les sites (en cas de BD réparties) calcul des paramètres de stockage des tables et des index etc.

(56)

Gestion physique des donn´ ees

Colonnes `a indexer

les clés primaires (concaténées ou pas) pour garantir l’unicité et accélérer les recherches

INDEX UNIQUE

les clés étrangères (concaténées ou pas) pour accélérer les jointures

INDEX NOT UNIQUE

les colonnes servant de crit`eres de recherche (apparaissent souvent dans la clause WHERE de SQL)

INDEX NOT UNIQUE

(57)

Gestion physique des donn´ ees

Colonnes `a indexer

Remarque :

Un vraiSGBD se caract´erise par l’emploi d’un SEUL fichier pour y stocker la BD

(ou ´eventuellement quelques fichiers si la BD est trop importante)

Un fauxSGBD Relationnel emploie un fichier pour y stocker une table

dans ce cas la gestion physique des données est assurée par le système d’exploitation, interdisant tout paramètre

d’optimisation

(58)

Gestion des m´ ethodes d’acc` es aux donn´ ees

Méthodes d’accès : Méthode séquentielle

Méthodes basées sur les index : Index hiérarchisé,

Arbre-B (B-tree), Arbre-B+, Arbre-B+*, ...

M´ethode de hachage Mise en cluster

(59)

Index

Diff´erents types d’index : Logique

Index simple (sur une colonne)

Index concat´en´e (sur plusieurs colonnes)

Index unique (colonne ne comportant pas de doublon) Index non unique (colonne comportant des doublons) Physique

B-tree Bitmap Hash

(60)

Type d’index

Séquentiel (index dense) Séquentiel indexé (index creux)

Arbres B+ (par d´efaut dans ORACLE) Bitmap

Hashage

(61)

Index s´ equentiel dense

Toutes les cl´es de recherche sont pr´esentes dans l’index

Donn´ees

Num. Bloc Cl´e primaire Info. compl. Num. Enreg.

30 info1 0

0 20 info2 1

150 info3 2

50 info4 3

120 info5 4

1 60 info6 5

100 info7 6

110 info8 7

80 info9 8

2 10 info10 9

40 info11 10

70 info 12 11

Index

10 9

20 1

30 0

40 10

50 3

60 5

70 11

80 8

100 6

110 7

120 4

150 2

(62)

Index s´ equentiel creux

Donn´ees

10 info10 9

0 20 info2 1

30 info1 0

40 info11 10

50 info4 3

1 60 info6 5

70 info 12 11

80 info9 8

100 info7 6

2 110 info8 7

120 info5 4

150 info3 2

Index

10 0

50 1

100 2

Non dense (creux) Index plus petit

(63)

Index type B-arbre (B-tree)

Exemple

Chaque cl´e est atteinte en au plus 3 acc`es Recherche dicothomique

Recherche dans un tableau tri´e

(64)

Index type Bitmap

Exemple

Table contenant les identifiants de Professeur et les classes dans laquelles ils interviennent (valeurs de l’attribut : 1, 2, 3)

NumProf ... civilit´e ...

23 M

12 Mme

45 M

76 Melle

87 M

19 Mme

34 M

56 M

97 Melle

civilit´e Valeur Index

M 001

Mme 010

Melle 100

Recherche des éléments de civilité Melle: opération ET binaire entre la valeur de l’index et’100’

(65)

Hash Index (Index de hachage)

Principe du Hashage : utilisation d’une fonction (h) qui appliquée à la clé h(cle) fournit l’adresse o`´ u se trouve l’enregistrement

Problèmes : Conflits entre clés (deux valeurs de clés ont la même valeur de hachage)

Nécessité de disposer d’algorithme de résolution des conflits

Donn´ees

15 info10 9

0 30 info2 1

60 info1 0

120 info11 10

10 info4 3

1 70 info6 5

100 info 12 11

130 info9 8

20 info7 6

2 50 info8 7

80 info5 4

cl´e = 70

h(70) = 10 mod 3

(66)

Index sous Oracle

B-arbre Bitmap Hash Cluster

(67)

Index

Exemples

Index simple

c r e a t e i n d e x i d x n o f o u r on t t f o u r ( n o f o u r ) Index concat´en´e

c r e a t e i n d e x idx commande on t t f o u r ( n o f o u r , n c l i e n t )

(68)

Index

Exemples

Index unique

c r e a t e u n i q u e i n d e x i d x u n i q u e

on t a b ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40

p c t u s e d 60 i n i t r a n s 10 m a x t r a n s 100

Index non unique

c r e a t e i n d e x i d x n o n u n i q u e

on t a b ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40

p c t u s e d 60 i n i t r a n s 10 m a x t r a n s 100

(69)

Index

manipulations

Modification d’un Index

A l t e r I n d e x schema . n a m e i n d e x i n i t r a n s i n t e g e r m a x t r a n s i n t e g e r

s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g|n o l o g g i n g

Reconstruction d’un Index A l t e r I n d e x p1 . IDX FOUR

R e b u i l d T a b l e s p a c e TBS INDEXES

(70)

Index

Manipulation

Modification d’un Index

A l t e r I n d e x schema . n a m e i n d e x i n i t r a n s i n t e g e r m a x t r a n s i n t e g e r

s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g|n o l o g g i n g

Catalogue Oracle pour la gestion des Index et des Clusters S e l e c t ∗ from s y s . d b a u s e r s ;

S e l e c t ∗ from s y s . d b a i n d e x c o l u m n s ; S e l e c t ∗ from s y s . d b a c l u s t e r s ;

(71)

Index Bitmap

Cr´eation d’un index Bitmap (pour faible cardinalit´e) c r e a t e b i t m a p i n d e x i d x l i v r f o u r on t t f o u r

( d t l i v r a i s o n )

t a b l e s p a c e T B S F o u r n i s s e u r ;

(72)

INDEX B-TREE

Pr´eparation de l’utilisation de B-Tree (lors d’une forte cardinalit´e)

SQL>DESC t 1 0 m a n c o p y

NAME NULL? TYPE

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− −−−−−−−− −−−−−−−−−−−−−

EMPNO NOT NULL NUMBER

ENAME VARCHAR2( 2 0 )

JOB VARCHAR2( 1 8 )

MGR NUMBER( 4 )

HIREDATE DATE

SAL NUMBER( 7 , 2 )

COMM NUMBER( 7 , 2 )

DEPTNO NUMBER( 2 )

EMPNO r a n g e s from 1 t o 1 0 0 0 0 0 . I u s e t h i s t a b l e t o c r e a t e MGR row w i t h c a r d i n a l i t y 4 . I u s e MOD f u n c t i o n .

MOD (m, n ) f u n c t i o n r e t u r n s a r e m a i n i n g o f m d i v i d e d by n . I a l s o u s e t o c h a r t o make column l e n g t h e v e n .

∗∗∗∗∗∗∗∗∗∗ SQL t o make d a t a i n MGR row be c a r d i n a l i t y 4 ∗∗∗∗∗∗∗∗∗∗∗

SQL>CREATE TABLET10MAN COPY 4 AS

SELECTEMPNO, ENAME, JOB , t o c h a r ( mod (EMPNO, 4 ) , ’ 0 0 0 0 0 0 0 ’ ) MGR,

(73)

INDEX B-TREE

Cr´eation d’un index B-Tree

SQL>SELECTMGRFROMT10MAN COPY 4WHEREROWNUM<10 ; MGR

−−−−−−−−

0 0 0 0 0 0 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1

∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

SQL>CREATE INDEX BTREE 4ONT10MAN COPY 4 (MGR)

STORAGE ( I N I T I A L 2KNEXT2K PCTINCREASE 0 MAXEXTENTS UNLIMITED ) ;

(74)

INDEX HASH Cluster

Cr´eation du cluster

Create c l u s t e r c l i e n t h a s h ( N u m c l i number ( 9 ) s i z e 512 HASHKEY 500

s t o r a g e ( i n i t i a l 2M next 1M) Mise en cluster d’une table

Create t a b l e C l i e n t ( N c l i number,

nom v a r c h a r 2( 5 0 ) ) C l u s t e r c l i e n t h a s h ( N c l i ) ; Cr´eation de l’index sur le cluster

(75)

Taille d’une Table & Taille d’un Index

Exemple

Table (110 octets par enregistrement) : Clé primaire (10 octets), Informations complémentaires (100 octets) Index (14 octets par enregistrement) : Clé primaire (10 octets), Adresse Physique (4 octets)

Bloc de 512 octets

Nombre d’enregistrements de l’ordre de 100 000

(76)

Taille d’une Table & Taille d’un Index

Exemple

Données (110 octets) Index (14 octets) Clé primaire Info. compl. Clé primaire Adresse physique

(10 octets) (100 octets) (10 octets) (4 octets)

10 info1 10 @1

15 info2 10 @2

20 info3 10 @3

30 info4 10 @4

40 info5 10 @5

50 50

55 55

77 77

80 80

10 10

150 150

250 info k 250 @k

(77)

Taille d’une Table & Taille d’un Index

Exemple

Données (110 octets) Index (14 octets) Clé primaire Info. compl. Clé primaire Adresse physique

(10 octets) (100 octets) (10 octets) (4 octets)

10 info1 30 @Bloc1

15 info2 77 @Bloc2

20 info3 150 @Bloc3

30 info4 1610 @Bloc4

40 info5

50 info6

55 info7

77 info8

80 info9

10 info10

150 info11

250 info k

(78)

Taille d’une Table & Taille d’un Index

Exemple

Pour les donn´ees :

Pour un nombre entier d’enregistrements par bloc (512/110) Nombre maximal d’enregistrements par bloc est 4

Il faudrait donc (100 000/4) = 25000 blocs de donn´ees Pour les index :

Pour un nombre entier d’enregistrements par bloc (512/14) Nombre maximal d’enregistrements par bloc est 36

Il faudrait donc (100 000/36) = 2778 blocs d’index

(79)

Optimisation des requˆ etes

Visualisation :

Expression Alg´ebrique Arbre alg´ebrique

Plan d’ex´ecution de la requˆete

(80)

Diff´ erents arbres alg´ ebriques

s e l e c t nom , prenom , n u m c o u r s , p o i n t s from e l e v e s e , r e s u l t a t s r

where r . n u m e l e v e = e . n u m e l e v e and p o i n t s > 10 ;

eleves resultat

./

σ^points^>¹⁰ Q

nom, prenom, num_cours

resultat

σ^points^>¹⁰

eleves

./

Q

(81)

Diff´ erents plans d’ex´ ecution

s e l e c t nom , prenom , n u m c o u r s , p o i n t s from e l e v e s e , r e s u l t a t s r

where r . n u m e l e v e = e . n u m e l e v e and p o i n t s > 10 ;

eleves resultat

./ jointure par tri-fusion

σ^points^>¹⁰ Q

eleves resultat

./ jointure par hachage

σ^points^>¹⁰ Q

(82)

Plan d’ex´ ecution

Ensemble des opérations à effectuer pour calculer une requête Trace du chemin d’accès d’une requête

Chaque opération sur un objet est notée avec : L’ordre d’évaluation de l’expression

Le chemin d’acc`es aux objets consult´es (table, index, cluster, vue, ...)

Le type d’op´erateurs physiques

(83)

Chemin d’acc` es

Parcours s´equentiel (balayage complet) TABLE ACCESS FULL

Acc`es direct par adresse

TABLE ACCESS BY (INDEX|USER|...) ROWID Acc`es par index

INDEX (UNIQUE|RANGE|...) SCAN Acc`es par hachage

TABLE ACCESS HASH Acc`es par cluster

TABLE ACCESS CLUSTER

Accès à un extrait de la base (spécifié dans la requête)

(84)

Op´ erateurs physiques

Jointure

Boucles imbriqu´ees: NESTED LOOPS Tri-fusion: SORT JOIN, MERGE JOIN Hachage: HASH JOIN

Autres op´erations

Union d’ensembles d’articles: CONCATENATION, UNION Intersection d’ensembles d’articles: INTERSECTION Diff´erence d’ensembles d’articles: MINUS

Filtrage d’articles d’une table bas´e sur une autre table: FILTER Intersection d’ensembles de ROWID: AND-EQ

(85)

Op´ erations dans le plan d’ex´ ecution

Type d’op´eration Op´eration Options

Type d’acc`es `a une table table access full,by rowid, hash, etc.

Tri en ´eliminant les doublons sort unique

Tri avant jointure par fusion sort join

Tri d´efini dans la requˆete sort order by

Jointure par boucles imbriqu´ees nested loop

Jointure externe par boucles imbriqu´ees nested loop outer

Jointure par tri-fusion merge join

Jointure externe par tri-fusion merge join outer Semi-jointure par tri-fusion merge join semi

Interrogation d’une vue view

(86)

Coˆ ut des op´ erations physiques

Evaluation des performances d’une requˆete en fonction du

Temps d’accès (E/S) à la mémoire de stockage (accès disque) Temps de traitement de l’UC (négligeable par rapport au temps d’accès)

Espace en mémoire centrale Espace en mémoire de stockage NB : Les accès disque sont les plus coûteux

(87)

Op´ erations ` a optimiser

Jointure de deux tables

boucles imbriqu´ees, jointure tri-fusion, jointure par hachage.

S´election de lignes selon une cl´e parcours, index, hashage, etc.

Tri des lignes d’une table algorithme tri-fusion

(88)

Quel type de jointure utilis´ e ?

Jointure imbriqu´ee : double boucle

Lorsque peu de lignes doivent ˆetre jointes

La seconde table est accédée rapidement à partir de l’attribut de jointure

Jointure par tri fusion : tri puis fusion de chaque opérande Lorsque les sources sont déjà triées

La condition de jointure est une in´egalit´e

Jointure par hachage : la table la plus petite est hach´ee en m´emoire

Lorsque la table hach´ee tient en m´emoire Un seul parcours de chaque table

Jointure cart´esienne : produit cart´esien, pas de condition de jointure

(89)

Plan d’ex´ ecution

Sous Oracle, possibilité de connaˆıtre pour chaque requête son plan d’exécution

Consultation du plan d’exécution selon lequel une instruction SQL sera exécutée par le SGBD Oracle dans une table

syst`eme

Stockage des plans d’ex´ecution dans une table PLAN_TABLE dont le script de cr´eation (fourni par Oracle) se trouve dans

$ORACLE_HOME/rdbms/admin/utlxplan.sql

(90)

Plan d’ex´ ecution

Etapes en vue de la consultation :

Création la table de nom PLAN_TABLE Eventuellement la détruire et la recréer

Exécution d’une commandeEXPLAIN PLAN sur une requête Stockage (description) du plan d’exécution de cette dernière) dans la table PLAN_TABLE

Interrogation de la table PLAN_TABLE

(91)

Ex´ ecution d’une commande EXPLAIN PLAN sur une requˆ ete

EXPLAIN PLAN

SET s t a t e m e n t i d= ’ e x e m p l e 1 ’ // i d e n t i f i a n t

FOR // e x e m p l e de r e q u ˆe t e

SELECT ∗∗∗ FROM ∗∗∗WHERE ∗ ∗ ∗;

Exemple :

EXPLAIN PLAN

SET s t a t e m e n t i d = ’ r e q u e t e 1 ’

FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ ;

(92)

Affichage du plan d’ex´ ecution

Interrogation de la tablePLAN_TABLE

| |’ ’| |o b j e c t n a m e ” P l a n d ’ e x ´e c u t i o n ” FROM p l a n t a b l e

START WITH i d = 0 AND s t a t e m e n t i d = ’ r e q u e t e 1 ’ CONNECT BY PRIOR i d = p a r e n t i d

AND s t a t e m e n t i d = ’ r e q u e t e 1 ’ ;

R´esultat affich´e :

Plan d’ex´ecution

--- SELECT STATEMENT

TABLE ACCESS FULL ELEVES

(93)

Remarques et explications

Repr´esentation d’une requˆete par un arbre Sous Oracle,

possibilit´e de repr´esentation et de manipulation

de données ayant une structure de données récursive (arbre) par une représentation tabulaire et avec la commande SQL :

SELECT . . . FROM . . .WHERE . . .

CONNECT BY PRIOR c o l o n n e o p ´e r a t e u r c o l o n n e [CONNECT BY c o l o n n e o p ´e r a t e u r PRIOR c o l o n n e ] START WITH . . .

LEVEL . . .

Extensible des donn´ees quelconques

(94)

Exemples de parcours de structure de donn´ ees de type r´ ecursif

Structures de donn´ees r´ecursives de type Arbres Exemples :

Arbre G´en´ealogique

Nomenclature d’un produit (Compos´e, Composant) Oracle offre la commandeCONNECT BY

SELECT . . . FROM . . .WHERE . . .

CONNECT BY PRIOR c o l o n n e o p ´e r a t e u r c o l o n n e CONNECT BY c o l o n n e o p ´e r a t e u r PRIOR c o l o n n e

START WITH LEVEL

(95)

Structures hi´ erarchiques, arborescentes

Arbre G´en´ealogique

Oracle permet la représentation et la manipulation des données ayant une structure arborescente par le modèle relationnel par exemple

c r e a t e t a b l e PERSONNES (

NUMEROnumber( 7 ) , NOM v a r c h a r( 1 5 ) , PRENOM v a r c h a r( 1 5 ) ,

DATENAISSANCE d a t e, SEXE c h a r( 1 ) , PERE number( 7 ) , MEREnumber( 7 ) , c o n s t r a i n t PK PERSONNES p r i m a r y k e y (NUMERO) ,

c o n s t r a i n t FK PERSONNES PERE PERSONNES f o r e i g n k e y( PERE ) r e f e r e n c e s PERSONNES , c o n s t r a i n t FK PERSONNES MERE PERSONNES f o r e i g n k e y(MERE) r e f e r e n c e s PERSONNES , c o n s t r a i n t CK SEXE PERSONNES c h e c k ( SEXE i n ( ’M’ , ’ F ’ ) ) ) ;