CoursBDA AIR3 Optimisation

Administration de Bases de Données
Optimisation
Thierry Hamon
Bureau H202
Institut Galilée - Université Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/BDA-AIR3-2016-2017/
AIR3 – ABD
1/169
Optimisation des performances
Introduction
Optimisation d’une Application ?
Quand décide-t’on d’optimiser ?

Optimiser quoi ?
Qui participe, et Comment ?
Type de l’application (TP ou Batch)
Intérêt de l’application pour l’entreprise
2/169
Introduction
Quand décide-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 réponse est inacceptable
(Agence de voyage, application interne, etc.)
3/169
Acteurs
Qui participe et pourquoi ?
Adminstrateurs de DB, Développeurs, Ingénieurs Système

(IS), Chef de projet
Définition de la puissance de la machine (Nombre de
processeurs, Capacité mémoire, Espace disque nécessaire en
fonction du type de l’application)
Type du SGBD (Oracle, DB2, etc.)
Type de l’application (Batch, TP)
Langage de programmation utilisé (Java, PL/SQL, etc.)
4/169
Objectifs
Qu’est-ce qui reste à faire ?
Les besoins en puissance machine définis

Les acteurs administrateurs BD, (IS), développeurs, etc. au
courant du projet (impliqués, responsable de la réussite du
projet,..)
Optimisation de la base et de l’application ?
5/169
Objectifs
Sur quoi doit-on focaliser les efforts d’optimisation ?
Partie N◦ 1 : Conception des systèmes d’informations et

optimisation des applications
Lors de la conception des systèmes d’informations (si pas trop
tard)
Optimisation des applications
Partie N◦ 2 : Présentation des outils pour assurer le suivi de la
base et garantir sa performance
Optimisation de la mémoire
Optimisation des entrées/Sorties Disque
Identifier les contentions dans la base de données
6/169
Objectifs

Lors de la conception des systèmes d’informations :
(Si pas trop tard)
Système non performant : résultat d’une mauvaise définition
du modèle conceptuel
Modèle conceptuel : au moins sous la 3ème forme Normale
(3NF)
Sauf dans quelque cas (choix volontaire) où la
dé-normalisation apporte une certaine performance au système
d’information (Dataware house)
Lors de la conception : tenir compte l’accès aux données
Analyse de la répartition des données :
réplication de données (sur une ou plusieurs bases, etc.)
agrégation des tables, pour les systèmes décisionnels
etc.
7/169
Objectifs

Optimisation des applications :
l’expérience montre que 80% des problèmes de performances
des applications, sont résolus, par une optimisation des
requêtes SQL
Ordonnancer les Batchs et éviter leur exécution pendant des
heures ou l’utilisation des machine est intense
Dispatcher les Batchs les plus consommateurs en puissance
machine à des heures différentes
7/169
Objectifs

Optimisation de la mémoire :
déterminer 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.
8/169
Objectifs

Optimisation des entrées/Sorties Disque :
Bien dimensionner les fichiers de la base de données
et placer dans des disques prévus pour le type d’application
(Batch ou TP),
pour assurer un temps de réponse acceptable des requêtes
adressées à la Base.
Ne pas oublier de recenser les disques les plus sollicités, les

tablespaces les plus fragmentés, full table scan, etc.
8/169
Objectifs

Identifier les contentions dans la base de données :
Etudier les locks, les latches et les wait events au niveaux de

la base de données, et les éliminer si possible
8/169
Conception des SI et optimisation des Applications
Partie 1
Lors de la conception des systèmes d’informations
Optimisation des applications :

L’expérience montre que l’optimisation des requêtes SQL
résout la majorité des problèmes de performances des
applications
9/169
Objectifs de l’optimisation
Clarifier et situer les différents paramètres internes des SGBD

(relationnel ; objet-relationnel) afin d’améliorer leurs
performances.
Réécrire les codes SQL ; PL/SQL etc..
Restructurer les données, indexer les données, créer des vues
matérialisées
Partager les données, dupliquer les données sur plusieurs
disques, créer des partitions sur les données
10/169
Objectifs de l’optimisation
Intervenants :
Administrateurs de Bases de Données (ABD = DBA)
Programmeurs d’Applications sur SGBD
Objectifs :
Optimiser un système existant et connaı̂tre les impacts de
certains paramètres en fonction du type d’application sur le
système
Choisir un SGBD en ayant comme contrainte les critères de
performances
11/169
Augmentation des performances
Pour augmenter les performances trois grandes solutions

apparaissent :
1 Première solution (d’ordre logique) : optimiser les schémas
conceptuel et logique pour qu’ils collent aux applications
2 Deuxième solution (d’ordre physique) : optimiser les
paramètres internes du SGBD
3 Autre solution (de type matérielle) : augmenter la puissance
machine ou utiliser des ordinateurs spéciaux dédiés à la
gestion des données.
Cette approche est plus connue sous le nom Machine Bases
de Données
12/169
Optimisation logique
Optimisation logique de la Base de Données

Optimisation du Schéma Relationnel
Schéma Conceptuel de Données (SCD),

obtenu à la phase d’analyse
une ensemble d’Entités et d’Associations ou un ensemble de
Classes selon le formalisme utilisé
En EA, transformation en schéma relationnel (Schéma Logique de

Données – SLD), qui permet
Implantation du SCD dans une BD relationnelle
Exploitation par le SGBD et les modules de programmation
13/169

Optimisation du Schéma Relationnel
Normalisation : processus permettant de s’assurer de la Bonne

conception du SLD
non redondance de ses données
Cadre formel pour effectuer la normalisation :
la dépendance fonctionnelle
les formes normales (1ère FN, 2ème FN, 3ème FN, FNBC,
4ème FN, ...)
14/169
Normalisation
Exemple
Avant normalisation :
Relation1 ( Attribut1 , Attribut2 , . . . )
Décomposition 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
Décomposition sans perte d’information
Décomposition sans perte de dépendance fonctionnelle (DF) ...
Après normalisation :
15/169
Normalisation
Les relations obtenues doivent être en 3ème Forme Normale, au

moins
→ bon rapport redondance/espace occupé
Clé Primaire
Pas de DF entre les attributs de la clé primaire ;
Pas de DF entre un sous ensemble d’attributs de la clé
primaire et les attributs qui n’appartiennent pas à la clé
primaire
Pas de DF entre les attributs qui n’appartiennent pas à la clé
primaire
16/169
Normalisation
Illustration
Format d’une relation bien conçue
17/169
Normalisation
Exemple
Soit la relation :
ADRESSES ( V i l l e , Numéro , Rue , C o d e P o s t a l )
Décomposition de la relation
ADRESSES ( r e l a t i o n en 3ème 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 )
18/169
Normalisation
Exemple
ADRESSES
VILLE NUMERO RUE CODE POSTAL
Paris 6 Rue de la Rosière 75015
Paris 16 Rue de la Rosière 75015
Paris 51 Rue des Entrepreneurs 75015
Paris 55 Rue des Entrepreneurs 75015
Paris 8 Avenue des Champs Elysées 75008
Epinay sur Seine 23 Boulevard Foch 93800
CPR CPV
CODE POSTAL RUE CODE POSTAL VILLE
75015 Rue de la Rosière 75008 Paris
75015 Rue des Entrepreneurs 75015 Paris
75008 Avenue des Champs Elysées 93800 Epinay sur Seine
93800 Boulevard Foch
19/169
Normalisation
Exemple
Un client a une adresse :
SLD version 1
CLIENT ( C o d e C l i , NomCli , PrénomCli ,
Numéro , 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 , PrénomCli ,
Numéro , 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 ;
20/169
Bilan
Un schéma relationnel normalisé

contiendra donc un nombre plus important de relations (de
tables)
pourra ainsi pénaliser certaines requêtes, qui seront obligées
de procéder à des jointures plus nombreuses sur la base
Or
La jointure est une opération très coûteuse
Les opérations binaires (qui portent sur deux tables) peuvent
être coûteuses
21/169

Redondance calculée
Technique d’optimisation des requêtes d’interrogation

Introduction volontairement de redondances dans le
schéma logique relationnel
Cette redondance est dite calculée car elle tient compte
des besoins des modules de traitement des données
de leurs exigences en terme de temps de réponse
22/169

Redondance calculée
Deux méthodes de réalisation de la redondance calculée :

le stockages des données déductibles
la dé-normalisation
23/169

Redondance calculée : stockages des données déductibles
Données déductibles
les résultats des requêtes les plus fréquentes
des statistiques historiques
des données issues de calculs complexes
24/169

Dans les trois cas, stockage des données, physiquement dans

la base
(sous la forme de Tables/Vues ou de Colonnes)
Avantage du stockage physique : éviter leur re-génération en
cas de besoin
Inconvénients de la redondance :
1 Place occupée par les données redondante
2 Nécessité de traitements supplémentaires pour les opérations
de mises à jour
3 Risque d’incohérence
25/169

Exemple de requête fréquente
Base de données SportAct : Adhérents à 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 )
Requête fréquente : 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 ;
26/169

Création d’une nouvelle colonne NbrInscr dans 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 opérations très coûteuses :
Une jointure en moins
Un groupement en moins
26/169

Impact sur le reste de la base de données

Prise en compte de cette nouveauté par les opérations de
mises à jours de la table ESTMEMBRE
Modification de la colonne NbrInscr à chaque insertion ou
suppression d’inscription
→ La cohérence est affectée si on ne le fait pas
26/169

Chaque opération INSERT / DELETE implique une opération

UPDATE
INSERT INTO ESTMEMBRE VALUES (....) ; doit être
accompagnée par
UPDATE CENTRE SET N b r I n s c r=N b r I n s c r +1 ;
DELETE FROM ESTMEMBRE WHERE ... ; doit être

accompagnée par
UPDATE CENTRE SET N b r I n s c r=N b r I n s c r −1 ;
26/169

Exemple de Statistiques Historiques
Requête : Nombre d’inscrits par centre et par mois ?

Objectif : éviter le recalcul à chaque fois du nombre d’inscrits
par centre et par mois
Solution : création d’une nouvelle table/vue
STAT_MENS_INSCR
STAT MENS INSCR ( NumC, Mois , N b r I n s c r )
Nécessité d’un nouveau traitement mensuel pour l’actualiser

avec les statistiques du mois écoulé
27/169

Résultat de calcul complexe
Soit la base de données :

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∗ , CodeArt ∗ , QtéComDée )
Requête : Montant de la commande ?
28/169

Résultat de calcul complexe
Obtention du montant de la commande :

SELECT C . NumCom, SUM(D . QtéComDée∗A . P r i x A r t ) AS Montant
FROM COMMANDE C , ARTICLE A , DETAILCOM D
WHERE C . NumCom=D . NumCom AND D . CodeArt=A . CodeArt
GROUP BY C . NumCom ;
Gain d’opération avec la création de la colonne Montant dans

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

FROM COMMANDE ;
28/169

Redondance calculée : dé-normalisation
Autre méthode d’optimisation des interrogations

Transformer, si besoin est, une table de la 3ème FN en 2ème
FN ou en la 1ère FN
Objectif : éviter des jointures successives pouvant être
coûteuses en performances
29/169

Exemple
Soit la table
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, CodeArt ∗ , QtéComDée , P r i x A r t )
DETAILCOM passe de la 3ème FN à la 1ère FN

Requête : Montant de la commande ?
SELECT NumCom, SUM( QtéComDée∗ P r i x A r t ) AS Montant
FROM DETAILCOM
GROUP BY NumCom ;
30/169

Inconvénients de la dé-normalisation : identiques à ceux du

stockage des données déductibles
Place supplémentaire
Pénalisation des traitements d’insertion et de suppression
Risque d’incohérence
Nécessite la création de déclencheurs (triggers)
31/169

Optimisation des ordres SQL
Requête SQL : ordre passé au SGBD pour lui demander de

rechercher des données spécifiées dans la requête
(sans expliciter le comment)
SQL est non procédural
SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY
DISTINCT SUM / MIN / MAX / AVG / COUNT
IN / NOT IN / LIKE / NOT LIKE / EXISTS / NOT EXISTS / =
INSERT / DELETE / UPDATE
CREATE / TABLE / VIEW / INDEX
32/169

Traduction d’une requête exprimée en langage naturel en un

ensemble d’ordres SQL
Plusieurs agencements sont souvent possibles :
au niveau de l’ordre dans lequel les conditions sont exprimées
dans la clause WHERE :
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
33/169

ensemble d’ordres SQL
Plusieurs agencements sont souvent possibles :
au niveau des opérations algébriques
Possibilité d’utiliser plusieurs méthodes différentes pour
exprimer la même chose
La jointure : possibilité d’exprimer l’opération de plusieurs
manières diffé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 ;
33/169

Expression de la jointure
Méthode prédicative
SELECT ∗ FROM R1 , R2 WHERE R1 . A=R2 . A ;
Méthodes 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 <

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

Exemple de durée d’exécution – SQLPlus
SET TIMING ON
Exécution de la requête ; SELECT ... FROM ...
→ Oracle vous donne le temps écoulé
Méthode pré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 é s 451 100 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 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 é s 690 690 u n i t é s
35/169

Exemple de durée d’exécution – SQLPlus
Méthodes 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 ) ;
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 ) ;
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
t1 . table name = t2 . table name ) ;
36/169


ensemble d’ordres SQL :
Plusieurs agencements sont souvent possibles
Possibilité d’utiliser plusieurs méthodes différentes pour
exprimer la même chose
La différence :
R = Différence ( R1, R2 )
SELECT ∗ FROM R1 MINUS SELECT ∗ FROM R2 ;
37/169

Expression de la différence
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 ) ;
38/169

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 ;
39/169

Vues matérialisées
Présentation des vues matérialisées :

Création d’une vue physique d’une table
Duplication des données
Définition de vues matérialisées à partir de tables, de vues, et
de vues matérialisées
Possibilité de décalage entre la table maı̂tre et la vue
matérialisée : gestion de la fraicheur des données de la vue
matérialisée (refresh)
40/169

Vues matérialisées
Utilisation des vues matérialisées :

Optimisation/amélioration des performances
Ré-écriture des requêtes portant sur des tables
select particulièrement complexe ou lourd
réplication de table
41/169

Utilisation de vues matérialisées
Inconvénients :
Résultat de la requête stocké et valable à un instant t
en fonction des paramètres, la vue matérialisée sera tenue à
jour ou non quand la table change
Entretien des vues en temps réel : coûteux (et peu souvent
mis en œuvre)
42/169

Utilisation de vues matérialisées
Avantages
Simple réécriture de requête et exécution de requêtes
imbriquées
Lorsqu’il n’est nécessaire de disposer des données en temps
réel, économie d’interrogation
Exemple : analyse de chiffres économiques de la veille
données figées
intérêt à stocker des résultats (qui ne changeront plus !)
Utilisation dans les datawarehouse : problématique de
performances
43/169
Optimisation physique
Gestion physique des données
Adaptation et enrichissement du SLD pour tenir compte

des spécificités du SGBD
des performances des traitements et de la sécurité
A ce stade d’élaboration du schéma physique de données, on
dispose :
du SLD normalisé ou non
du schéma physique de traitement (description détaillée des
modules)
44/169
Résultat : Schéma Physique des Données (SPD)

représentation de la structure définitive de la base de données
telle qu’elle doit être implantée
prise en compte
des caractéristiques technique du SGBD et du matériel
des exigences en interfaces et en performances des modules de
programmation
Si le matériel ou le SGBD change alors il faut changer le SPD (les
exigences changent)
45/169
Etat des lieux : des tables en 3ème FN, ou autre etc. bien
conçues
Objectifs :
optimisation des accès en choisissant les colonnes qui doivent
être indexées
introduction (éventuellement) de redondances calculées
définition de vues standards et des vues matérialisées
définition des contraintes d’intégrité et des déclencheurs sur
les tables
46/169
création des tables et des colonnes techniques

définition des droits d’accès aux données
répartition des tables sur les sites (en cas de BD réparties)
calcul des paramètres de stockage des tables et des index
etc.
47/169

Colonnes à indexer
les clés primaires (concaténées ou pas) pour garantir l’unicité

et accélérer les recherches
INDEX UNIQUE
les clés étrangères (concaténées ou pas) pour accélérer les
jointures
INDEX NOT UNIQUE
les colonnes servant de critères de recherche (apparaissent
souvent dans la clause WHERE de SQL)
INDEX NOT UNIQUE
48/169

Colonnes à indexer
Remarque :
Un vrai SGBD se caractérise par l’emploi d’un SEUL
fichier pour y stocker la BD
(ou éventuellement quelques fichiers si la BD est trop
importante)
Un faux SGBD Relationnel emploie un fichier pour y
stocker une table
dans ce cas la gestion physique des données est assurée par le
système d’exploitation, interdisant tout paramètre
d’optimisation
49/169
Indexation
Gestion des méthodes d’accès aux données
Méthodes d’accès :
Méthode séquentielle
Méthodes basées sur les index :
Index hiérarchisé,
Arbre-B (B-tree), Arbre-B+, Arbre-B+*, ...
Méthode de hachage
Mise en cluster
50/169
Indexation
Taille d’une Table & Taille d’un Index

Exemple
Table (110 octets par enregistrement) : Clé primaire (10

octets), Informations complémentaires (100 octets)
Index (14 octets par enregistrement) : Clé primaire (10

octets), Adresse Physique (4 octets)
Bloc de 512 octets
Nombre d’enregistrements de l’ordre de 100 000
51/169
Indexation

Exemple
Données (110 octets) Index (14 octets)

Clé primaire Info. compl. Clé 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
1610 info n 1610 @n
52/169
Indexation

Exemple
Données (110 octets) Index (14 octets)
Clé primaire Info. compl. Clé 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
1610 info n
53/169
Indexation

Exemple
Pour les données :

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 données
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
54/169
Indexation
Index
Différents types d’index :

Logique
Index simple (sur une colonne)
Index concaténé (sur plusieurs colonne)
Index unique (colonne ne comportant pas de doublon)
Index non unique (colonne comportant des doublons)
Physique
B-tree
Bitmap
Hash
55/169
Indexation
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 ( no four )
Index concaténé
c r e a t e i n d e x idx commande on ( no four , n c l i e n t )
56/169
Indexation
Index
Exemples
index unique
c r e a t e unique 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
create index 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
nologging
57/169
Indexation
Index
manipulations
Modification d’un Index

A l t e r Index schema . n a m e i n d e x
i n i t r a n s integer
maxtrans integer
s t o r a g e ( i n i t i a l 100M next 20M)
logging | nologging
Reconstruction d’un Index

A l t e r Index p1 . IDX FOUR
R e b u i l d T a b l e s p a c e TBS INDEXES
58/169
Indexation
Index
Manipulation
Modification d’un Index

A l t e r Index schema . n a m e i n d e x
i n i t r a n s integer
maxtrans integer
logging | nologging
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 ;
S e l e c t ∗ from s y s . d b a c l u c o l u m n s ;
59/169
Indexation
Index Bitmap
Création d’un index Bitmap (pour faible cardinalité)

c r e a t e bitmap i n d e x on t t f o u r
( dt livraison )
tablespace TBS Fournisseur ;
60/169
Indexation
INDEX HASH Cluster

Création 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
Mise en cluster d’une table

Create t a b l e C l i e n t
( N c l i number ,
nom varchar2 ( 5 0 ) )
Cluster c l i e n t h a s h ( N c l i ) ;
Création de l’index sur le cluster

Create i n d e x I d x C l i e n t on c l u s t e r c l i e n t h a s h ;
61/169
Indexation
INDEX B-TREE
Préparation de l’utilisation de B-Tree
(à utiliser dans le cas d’une forte cardinalité)
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 TABLE T10MAN COPY 4 AS

SELECT EMPNO, ENAME, JOB , t o c h a r ( mod (EMPNO, 4 ) , ’ 0000000 ’ ) MGR,
HIREDATE , SAL ,COMM,DEPTNO
FROM T10MAN ORG ;
T a b l e c r e a t e d 0 0 0 0 0 0 0 , 0 0 0 0 0 0 1 , 0 0 0 0 0 0 2 , and 0000003 a r e s c a n n e d by t u r n s
62/169
Indexation
INDEX B-TREE
Création d’un index B-Tree

SQL> SELECT MGR FROM T10MAN COPY 4 WHERE ROWNUM < 10 ;
MGR
−−−−−−−−
0000001
0000002
0000003
0000000
0000001
0000002
0000003
0000000
0000001
∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
SQL> CREATE INDEX BTREE 4 ON T10MAN COPY 4 (MGR)
STORAGE ( I N I T I A L 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED ) ;
63/169
Optimisation des requêtes
Visualisation :
Expression Algébrique
Arbre algébrique
Plan d’exécution de la requête
64/169
Plan d’exécution
Sous Oracle, possibilité de connaı̂tre pour chaque requête son
plan d’exécution
Consultation du plan d’exécution selon lequel une instruction
SQL sera exécutée par le SGBD Oracle dans une table
système
Stockage des plans d’exécution dans une table PLAN_TABLE

dont le script de création (fourni par Oracle) se trouve dans
$ORACLE_HOME/rdbms/admin/utlxplan.sql
Etapes en vue de la consultation :
création la table de nom PLAN_TABLE
Eventuellement la détruire et la recréer
exécuttion d’une commande EXPLAIN PLAN sur une requête
Stockage (description) du plan d’exécution de cette dernière)
dans la table PLAN_TABLE
Interrogation de la table PLAN_TABLE
65/169
Exécution d’une commande EXPLAIN PLAN sur une

requête
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%’ ;
66/169
Affichage du plan d’exécution

Interrogation de la table PLAN_TABLE
SELECT LPAD( ’ ’ , 2 ∗ (LEVEL− 1 ) ) | | o p e r a t i o n | | ’ ’ | | o p t i o n s
| | ’ ’ | | 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 ’ ;
Résultat affiché :
-----------------------------------------------
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM
67/169
Remarques et explications
Représentation d’une requête par un arbre
Sous Oracle,
possibilité de représentation et de manipulation
de données ayant une structure de données récursive (arbre)
par une repré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 données quelconques
68/169
Exemples de parcours de
structure de données de type récursif
Structures de données récursives de type Arbres
Exemples :
Arbre Généalogique
Nomenclature d’un produit (Composé, Composant)
Oracle offre la commande CONNECT 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
69/169
Structures hiérarchiques, arborescentes

Arbre Généalogique
Oracle permet la représentation et la manipulation des données

ayant une structure arborescente par le modèle relationnel par
exemple
c r e a t e t a b l e PERSONNES (
NUMERO number ( 7 ) , NOM v a r c h a r ( 1 5 ) , PRENOM v a r c h a r ( 1 5 ) ,
DATENAISSANCE date , SEXE c h a r ( 1 ) , PERE number ( 7 ) , MERE number ( 7 ) ,
c o n s t r a i n t PK PERSONNES p r i m a r y key (NUMERO) ,
c o n s t r a i n t FK PERSONNES PERE PERSONNES f o r e i g n key (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 key (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 ’ ) ) );
70/169

Requête simple sur une table non indexée
DELETE p l a n t a b l e ;
// ( l a t a b l e é t a n t c r é é e une f o i s , il s u f f i t de l a v i d e r )
EXPLAIN PLAN
FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ ;
SELECT LPAD( ’ ’ , 2 ∗ ( LEVEL − 1 ) ) | | o p e r a t i o n | | ’ ’ | | o p t i o n s | | ’ ’ | |

o b j e c t n a m e ” P l a n d ’ e x é c u t i o n ”
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 ’ ;
-----------------------------------------------
SELECT STATEMENT
71/169

Requête simple sur une table indexée
drop i n d e x i nom ;
c r e a t e i n d e x i n o m on e l e v e s ( nom ) ;
EXPLAIN PLAN
FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ ;

------------------------------------------------
SELECT STATEMENT
72/169

Comparaison
Requête simple sur une table non indexée :
---------------------------------------------
SELECT STATEMENT
Requête simple sur une table indexée :
---------------------------------------------
SELECT STATEMENT
73/169

Requête avec un order by sur une table non indexée
drop i n d e x i nom ;
delete plan table ;
EXPLAIN PLAN
FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ o r d e r by nom ;

---------------------------------
SELECT STATEMENT
SORT ORDER BY
TABLE ACCESS FULL ELEVES
74/169

Requête avec un order by sur une table indexée
d r o p i n d e x i n o m ; c r e a t e i n d e x i n o m on e l e v e s ( nom ) ;
delete plan table ;
EXPLAIN PLAN
FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ o r d e r by nom ;

------------------------------------
SELECT STATEMENT
SORT ORDER BY
75/169

Comparaison
Requête avec un order by sur une table non indexée
-----------------------------------------------
SELECT STATEMENT
SORT ORDER BY
Requête avec un order by sur une table indexée
---------------------------------------------
SELECT STATEMENT
SORT ORDER BY
76/169

Requête de jointure avec les deux tables indexées
delete plan table ;
EXPLAIN PLAN
FOR s e l e c t nom , prenom , num co urs , p o i n t s from e l e v e s e ,
resultats r where r . n u m e l e v e = e . n u m e l e v e ;

----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL RESULTATS
INDEX UNIQUE SCAN PK_ELEVES
77/169

L’ordre des 2 tables change
delete plan table ;
EXPLAIN PLAN
FOR s e l e c t nom , prenom , num co urs , p o i n t s from r e s u l t a t s r ,
eleves e where r . n u m e l e v e = e . n u m e l e v e ;
SELECT LPAD( ’ ’ , 2 ∗ ( LEVEL − 1 ) ) | | o p e r a t i o n | | ’ ’ | | options | | ’ ’ | |

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 plan table
CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t id =’ requete3 ’ ;
----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK_RESULTATS
78/169

Comparaison
----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL RESULTATS

(L’ordre des 2 tables change)
----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
79/169

Requête de jointure avec les deux tables indexées et une sélection
delete plan table ;

EXPLAIN PLAN
FOR s e l e c t nom , prenom , num co urs , p o i n t s from e l e v e s e ,
resultats r
where r . n u m e l e v e = e . n u m e l e v e and e . n u m e l e v e = 10 ;

80/169

Requête de jointure avec les deux tables indexées et une sélection
----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
81/169
Outils d’optimisation
Partie 2
Introduction
Présentation
des outils
des méthodes
pour assurer le suivi de la base et garantir sa performance
82/169
Outils d’optimisation
Amélioration du Suivi et de la performance de la base
1 Choix de l’optimiseur et collecte des statistiques

2 Suivi des indicateurs
3 Outils pour améliorer l’optimisation de la base
83/169
Optimiseur Oracle
Historique de l’optimiseur d’Oracle

Optimiseur Syntaxique
Avant la version 7.0 :

optimiseur syntaxique (rule-based optimizer ) avant la
version 7/0 :
Hypothèse de base :
à partir du moment où une instruction SQL validait une règle,
et que le numéro de la règle diminuait, le plan d’exécution
était réputé meilleur.
Fonctionnement :
uniquement optimisation du code en utilisant un ensemble de
règles internes fixes
et en les appliquant à partir d’une analyse syntaxique du code
84/169
Optimiseur Oracle

Optimiseur Syntaxique
Limites de l’optimiseur syntaxique : incapacité à déterminer la

méthode la moins coûteuse
Pas usage de type de fonction de coût ou de statistiques
Mais, initialement conçu pour les BDD transactionnelles (les
Datawarehouses n’existaient pas encore)
85/169
Optimiseur Oracle

Optimiseur Statistique
Apparition avec la version 7.0 d’Oracle

Objectifs :
Utilisation d’un plus grand nombre d’options lors de la
construction des plans d’exécution du code SQL
Mais maturité difficile à atteindre : 7 ans !
A partir de Oracle 7.3 : Possibilité de générer et d’enregistrer des
histogrammes de colonnes
Histogrammes de colonnes : Fonctionnalité capable de déterminer

la distribution effective des données pour une colonne particulière
86/169
Optimiseur Oracle
Initialisation des Paramétrages de l’Optimiseur

Configuration de l’instance Oracle à l’aide du paramètre
OPTIMIZER_MODE
Valeur définie dans le fichier init.ora
Valeur par défaut : ALL ROWS (valeur nécessaire pour
l’optimisation statistique)
Valeurs possibles (selon les versions d’oracle) : RULE (existant,
mais obsolète depuis 11g), FIRST_ROWS, ALL_ROWS,
FIRST_ROWS (1|10|100|1000), CHOOSE (existant, mais
obsolète depuis 11g)
Modification du paramètre au niveau session à l’aide de la

commande suivante :
A l t e r s e s s i o n s e t o p t i m i z e r m o d e= f i r s t r o w s ;
87/169
Optimiseur Oracle
Mode RULE de l’Optimiseur
Valeur RULE : optimisation syntaxique (rule-based optimizer )

Optimisation du code en utilisant un ensemble de règles
internes fixes telles que :
Accès par l’intermédiaire d’un index composite avec toutes les
clés contenues dans la clause where
Accès par l’intermédiaire d’un index sur une colonne, etc.
88/169
Optimiseur Oracle
Optimiseur statistique
Objectif de l’optimiseur statistique :

tenter de tout exécuter en mémoire centrale
et donc diminuer au maximum les E/S (hit Ratio)
Utilisation des calculs statistiques du catalogue Oracle
(dba_tables, dba_indexes, les vues V$, etc ...)
pour générer le plan d’exécution des requêtes
89/169
Optimiseur Oracle
Optimiseur statistique
Remarques :
Pas de mise à jour régulière des catalogues par Oracle
Le DBA qui doit donc s’en charger
Récupération de la date de dernier calcul des statistiques :
Requête dans la vue DBA_TAB_COLUMNS pour afficher
l’information LAST_ANALYZED
s e l e c t owner , t a b l e n a m e , l a s t a n a l y z e d
from d b a t a b c o l u m n s
where l a s t a n a l y z e d > ’ 01−JAN−00 ’ ;
90/169
Optimiseur Oracle
Modes de l’optimiseur statistique
Mode FIRST_ROWS : Utilisation des statistiques pour déterminer le

meilleur plan d’exécution permettant de retrouver rapidement les
premières lignes
Mode ALL_ROWS : Utilisation des statistiques pour déterminer le
meilleur plan d’exécution permettant de retrouver rapidement toutes
les lignes
Mode FIRST_ROWS (1|10|100|1000) : Utilisation des statistiques
pour déterminer le meilleur plan d’exécution permettant de
retrouver rapidement les n lignes
Mode CHOOSE : la présence de statistiques dans le dictionnaire
détermine si l’optimiseur statistique est utilisé (mode ALL_ROWS,
sinon RULE)
91/169
Statistiques
Collecte des statistiques
Calcul des statistiques d’objets :

Utilisation de la commande ANALYZE pour :
collecter ou supprimer des statistiques des tables (ou partition
de table), d’index (ou partition d’index), cluster , ...
valider la structure des tables (ou partition de table), d’index
(ou partition d’index), cluster , ...
identifier des lignes migrées ou chainées d’une table d’un
cluster, ...
92/169
Statistiques
Collecte des statistiques d’une table
Analyse statistique d’une partition (estimation sur la totalité

de la partition)
ANALYZE TABLE emp PARTITION ( p1 ) COMPUTE STATISTICS ;
Analyse statistique et validation de la structure d’une table

ANALYZE TABLE emp VALIDATE STRUCTURE ;
Analyse statistique d’une partie d’une table (exemple 33 %)

ANALYZE TABLE emp ESTIMATE STATISTICS SAMPLE 33 p e r c e n t ;
Analyse statistique d’une table ainsi que de ses indexes

ANALYZE TABLE emp COMPUTE STATISTICS FOR ALL INDEXED COLUMNS ;
93/169
Statistiques
Collecte des statistiques d’un Index
Analyse statistique et validation de la structure d’un index

ANALYZE INDEX p a r t s i n d e x VALIDATE STRUCTURE ;
Analyse statistique ( sur la totalité de l’index)

ANALYZE INDEX i n d x 1 COMPUTE STATISTICS ;
Analyse statistique d’une partie d’un index (exemple 44 %)

ANALYZE INDEX p a r t s i n d e x ESTIMATE STATISTICS SAMPLE 44 p e r
94/169
Statistiques
Suppression des statistiques d’une table et des index
ANALYZE TABLE emp DELETE STATISTICS
95/169
Statistiques
Quelle est la quantité optimale des statistiques nécessaire ?
Si estimation des statistiques des objets en se fondant sur un

échantillon (estimate) :
La taille de celui-ci doit être appropriée
Élément essentiel pour fournir à l’optimiseur des statistiques
dotées d’un bon intervalle de confiance
Un niveau de 20% est souvent utilisé et semble approprié
Si choix de calculer les statistiques (compute) :
Niveau de confiance : 100%
Et les statistiques doivent être parfaitement précises
Nécessite des ressources et du temps pour réaliser ces calculs
96/169
Statistiques
Quelle est la quantité optimale des statistiques nécessaire ?
S’il s’agit d’Oracle 8i ou supérieur, le package DBMS_STATS

pourra analyser les tables en parallèle
Si exécution d’une commande analyze estimate sur une
taille d’échantillon > 49% :
le module calculera les statistiques sur l’ensemble de la table
97/169
Statistiques
Nouveaux packages pour la génération des statistiques
DBMS_UTILITY.ANALYZE_SCHEMA : analyse des schémas

Oracle
DBMS_STATS : (nouveau package) statistique d’objets
d’Oracle8i
98/169
Statistiques
DBMS UTILITY.ANALYZE SCHEMA
Analyse des schémas Oracle

Exécution de la procédure analyze_schema du package
DBMS_UTILITY
Exemple :
Execute d b m s u t i l i t y . a n a l y z e s c h e m a ( ’SCOTT ’ ,
’ e s t i m a t e ’ , e s t i m a t e p e r c e n t =>20) ;
99/169
Statistiques
DBMS STATS
Nouveau package de statistiques d’objets d’Oracle8i

Exécution de calculs avec différentes options
Procédure Description
GATHER_INDEX_STATS Rassemblement de statistiques sur les
index
GATHER_TABLE_STATS Rassemblement de statistiques sur les
index, colonnes et tables
GATHER_SCHEMA_STATS Rassemblement de statistiques sur
tous les objets d’un schéma
GATHER_DATABASE_STATS Rassemblement de statistiques sur
tous les objets d’une base de données
100/169
Statistiques
DBMS STATS
Exemple d’utilisation d’option : Procédure GATHER_TABLE_STATS

DBMS STATS . GATHER TABLE STATS
( ’DEV ’ , −−> Schéma
’ Contrat ’ , −−> T a b l e
NULL, −−> P a r t i t i o n
30 , −−> % de l ’ é c h a n t i l l o n
FALSE , −−> E c h a n t i l l o n de b l o c ?
’FOR ALL COLUMNS ’ , −−> C o l o n n e s
4, −−> Degré de p a r a l l é l i s m e
’DEFAULT ’ , −−> T a b l e e t t o u t e s l e s p a r t i t i o n s
TRUE) ; −−> C a s c a d e v e r s l e s i n d e x
101/169
Statistiques
DBMS STATS
Explications :
La table CONTRAT du user DEV est analysée avec un degré
de parallélisme de 4
Toutes les colonnes sont analysées ainsi que les index
correspondants
L’analyse se fait avec une estimation de 30% au niveau ligne
102/169
Statistiques
DBMS STATS
Syntaxe
BEGIN
DBMS STATS . g a t h e r t a b l e s t a t s ( ’DEV ’ , ’CONTRAT ’ ,

e s t i m a t e p e r c e n t => DBMS STATS . a u t o s a m p l e s i z e ,
CASCADE=>TRUE ) ;
END;
103/169
Statistiques
Restauration des statistiques avec DBMS STATS
Si les statistiques :
semblent fausses
entraine l’Optimiseur à générer des mauvais plans d’exécution
Il faut restaurez les statistiques d’origines comme suit :
BEGIN
DBMS STATS . DELETE TABLE STATS ( ’ s c o t t ’ , ’ emp ’ ) ;
DBMS STATS . IMPORT TABLE STATS ( ’ s c o t t ’ , ’ emp ’ ,
s t a t t a b => ’ s a v e s t a t s ’ ) ;
END;
104/169
Statistiques
Fréquence des statistiques
A quelle fréquence les statistiques doivent être calculées ?
→ Cela dépend
du taux
du volume de changement des données dans la base
105/169
Suivi des Indicateurs
Indicateurs :
Ratios
Alertes (corruption, messages d’erreurs etc.) et les traces
Vues de dépannage et réglage
Tuning des I/O des requêtes couteuses
106/169
Ratios de la base
Buffer cache hit Rate

nombre de fois qu’un block utile à la requête existe dans le
buffer cache
→ il faut que ce pourcentage soit proche de 90%
s e l e c t r o u n d ((1 −( p r . v a l u e / ( bg . v a l u e+cg . v a l u e ) ) ) ∗ 1 0 0 , 2 )
from v $ s y s s t a t pr , v $ s y s s t a t bg , v $ s y s s t a t cg
where p r . name= ’ p h y s i c a l r e a d s ’ −− l e c t u r e s d i s q u e
and bg . name= ’ db b l o c k g e t s ’ −− l e c t u r e s mémoire
and cg . name= ’ c o n s i s t e n t g e t s ’ ; −− l e c t u r e s mémoire
Objectif : avoir en mémoire l’information dont on a besoin

Amélioration de ce ratio : augmenter le db_block_buffers
107/169
Ratio de la base
Library cache get hit Rate

Proportion des requêtes pour obtenir un verrou sur un objet
Les requêtes sont satisfaite en trouvant le descripteur de
l’objet qui doit déjà être en mémoire
ce pourcentage doit être proche de 90%
s e l e c t r o u n d (sum( g e t h i t s ) /sum( g e t s ) ∗ 1 0 0 , 2 )
from v $ l i b r a r y c a c h e ;
Amélioration des performances : Augmentation des valeurs

SHARED_POOL_SIZE, et OPEN_CORSORS dans init.ora
108/169
Ratio de la base
Dictionary Cache Hit Ratio

Mesure du taux de requêtes pour obtenir des informations du
dictionnaire de données, des tables et des vues contenant des
informations sur
la base de données
les structures
les utilisateurs
109/169
Ratio de la base
Remarque :
Au démarrage, le cache du dictionnaire de données est vide
Chaque requête SQL est absente du cache, et entraı̂ne un
défaut
Comme il y devrait y avoir de plus en plus de données lues
dans le cache, le nombre de défaut dans le cache diminuera
La base de données peut atteindre un état stable (steady
state) : les données du dictionnaires les plus fréquemment
utilisées sont dans le cache
110/169
Ratio de la base
Exemple d’utilisation
s e l e c t sum( g e t s −g e t m i s s e s ) ∗ 1 0 0 /sum( g e t s )
from v $ r o w c a c h e ;
Cache du dictionnaire : stocké dans le Shared Pool (partie

du SGA)
Amélioration du ratio : augmentation de la taille du share
pool (SHARED_POOL_SIZE dans init.ora)
NB : A partir de la version 10g, la manipulation du catalogue

est devenue plus intelligente
111/169
Ratio de la base
Sorts in Memory
Mesure de la proportion de données triées qui sont en
mémoire plutôt que sur le disque
Exemple :
s e l e c t r o u n d ( (mem . v a l u e / (mem . v a l u e+d s k . v a l u e ) ) ∗ 1 0 0 , 2 )
from v $ s y s s t a t mem, v $ s y s s t a t d s k
where mem . name= ’ s o r t s ( memory ) ’ and
d s k . name= ’ s o r t s ( d i s k ) ’ ;
112/169
Ratio de la base
Remarques :
Le tri sur disque utilise les tablespaces temporaires
La taille maximal du tri en mémoire est défini par la taille de la
zone de tri (sort area size) – taille dans lequel de PGA est
utilisé
Chaque processus Oracle effectuant un tri réserve autant de
mémoire, même s’il n’en a pas besoin.
L’utilisation de cette mémoire réduit celle disponible pour SGA
Optimisation : augmenter le paramètre SORT_AREA_SIZE
dans init.ora
113/169
Alertes
Les alertes
Fichier alert_ORACLE_SID.log
Exemple : alert_bdaINFO2.log
Contenu d’un fichier d’alerte :
des informations utilisées par le DBA de la base pour une
maintenance, un suivi, ... de la base Oracle
Des traces sont rajoutées dans le fichier Log suite à :
un démarrage de la base,
un arrêt de la base,
une création ou la mise à jour d’un tablespace,
une création, ou la mise à jour d’un rollback segment,
etc ...
114/169
Alertes
Les alertes
Fichiers de trace Oracle_Sid_numero.trc

Ces fichiers contiennent des informations :
utile pour l’optimisation de la base : traces générées par les
utilitaires tkprof, statpack, utlbstat, etc.
ou permettent au DBA, de suivre et de corriger des erreurs,
afin d’éviter le plantage, ou un mauvais fonctionnement de la
base Oracle
115/169
Alertes
Exemple de fichier d’alerte

F r i Sep 12 1 1 : 4 6 : 0 1 2003
S t a r t i n g ORACLE i n s t a n c e ( n o r m a l )
LICENSE MAX SESSION = 0
LICENSE SESSIONS WARNING = 0
LICENSE MAX USERS = 0
S t a r t i n g up ORACLE RDBMS V e r s i o n : 8 . 1 . 7 . 0 . 0 .
System p a r a m e t e r s w i t h non−d e f a u l t v a l u e s :
processes = 320
sessions = 357
timed statistics = TRUE
nls territory = FRANCE
nls date format = YYYY−MM−DD
nls numeric characters = .,
control files = ${ORACLE HOME}/ d b s / o r a d a t a 1 / DWH ctl 1 . c t l ,
${HOME}/ dbdc / o r a c l e / d b s / o r a d a t a 8 / DWH ctl 2 . c t l
db block buffers = 65536
db block size = 16384
ORA−1652: u n a b l e t o e x t e n d temp se gme nt by 64 i n t a b l e s p a c e S TBS INDX

Wed Dec 3 1 2 : 2 5 : 4 9 2003
ORA−1652: u n a b l e t o e x t e n d temp se gme nt by 6400 i n t a b l e s p a c e S TBS DATA
Wed Dec 3 1 2 : 2 8 : 5 1 2003
ALTER TABLESPACE S TBS DATA ADD DATAFILE
’ c : \ o r a c l e \ o r a n t \ o r a d a t \ d b s \TBS DWH DATA 1 . d b f ’ SIZE 512M AUTOEXTEND OFF
Wed Dec 3 1 2 : 2 8 : 5 9 2003
116/169
Catalogue Oracle
Catalogue Oracle:Instance et base de données
V$database : description de la base

V$instance : description de l’instance
V$parameter : paramètres de la base
V$process~: nombre de process actifs
V$waitstat~: statistiques relatives aux attentes
V$system_event : attentes totales pour des évènements
particuliers
117/169
Catalogue Oracle
Parametres de la base : v$parameter

S e l e c t Name , Type , Value , description from v $ p a r a m e t e r
NAME TYPE VALUE DESCRIPTION

timed statistics 1 TRUE maintain i n t e r n a l timing s t a t i s t i c s
trace enabled 1 TRUE e n a b l e KST t r a c i n g
sql trace 1 FALSE e n a b l e SQL t r a c e
db name 2 dwh d a t a b a s e name s p e c i f i e d i n
CREATE DATABASE
utl file dir 2 ∗ utl file accessible directories l i s t
instance name 2 BCR D i n s t a n c e name s u p p o r t e d by t h e i n s t a n c e
db block size 3 16384 Size of database block in bytes
open cursors 3 500 max # c u r s o r s p e r s e s s i o n
sort area retained size 3 6000000 s i z e o f i n−memory s o r t work a r e a
r e t a i n e d between f e t c h ca
db file multiblock read count 3 4 db b l o c k t o be r e a d e a c h IO
max enabled roles 3 148 max number o f r o l e s a u s e r can h a v e
enabled
max rollback segments 3 78 max . number o f r o l l b a c k s e g m e n t s i n
SGA c a c h e
sga max size 6 1178569392 max t o t a l SGA s i z e
shared pool reserved size 6 26843545 size in bytes of reserved area of
shared pool
large pool size 6 0 s i z e in bytes of the l a r g e a l l o c a t i o n
pool
java pool size 6 33554432 s i z e i n b y t e s of the Java pool
118/169
Catalogue Oracle
Statistiques relatives aux attentes
S e l e c t ”CLASS” , ”COUNT” , ”TIME” from v $ w a i t s t a t ;
CLASS COUNT TIME
data block 19866 26102

sort block 0 0
s a v e undo b l o c k 0 0
segment he a d e r 5301 4161
s a v e undo h e a d e r 0 0
free l i s t 0 0
e x t e n t map 0 0
1 s t l e v e l bmb 0 0
2 nd l e v e l bmb 0 0
3 r d l e v e l bmb 0 0
bitmap b l o c k 0 0
bitmap index b l o c k 0 0
f i l e header block 0 0
unused 0 0
s y s t e m undo h e a d e r 0 0
s y s t e m undo b l o c k 0 0
undo h e a d e r 1933 397
undo b l o c k 44 3
119/169
Catalogue Oracle
Attentes totales pour des évènements particuliers
s e l e c t event , t o t a l w a i t s , a v e r a g e w a i t from v $ s y s t e m e v e n t ;
EVENT TOTAL WAIT AVERAGE WAIT
latch free 3740 1

pmon t i m e r 1929737 293
enqueue 10937 103
c o n t r o l f i l e s e q u e n t i a l read 596427 0
control f i l e p a r a l l e l write 1870221 3
b u f f e r busy w a i t s 27144 1
log f i l e s e q u e n t i a l read 1571 0
log f i l e s i n g l e write 1562 1
log f i l e p a r a l l e l write 443272 0
LGWR w a i t f o r r e d o c o p y 12490 0
db f i l e s e q u e n t i a l r e a d 173476 0
db f i l e s c a t t e r e d r e a d 1010050 0
db f i l e s i n g l e w r i t e 104 1
db f i l e p a r a l l e l w r i t e 37096 3
db f i l e p a r a l l e l r e a d 1 6
l i b r a r y cache pin 139 285
l i b r a r y cache l o c k 149 11
l i b r a r y cache load l o c k 3 0
120/169
Catalogue Oracle
Catalogue d’Oracle : Disques
V$datafile : liste des fichiers des données

V$filestat : statistiques relatives aux I/O dans les fichiers
de données
V$tempstat : informations sur les statistiques relatives aux
opérations des I/O pour les fichiers de données des TBS
temporaires
V$segment_statistics : statistiques sur les I/O par
segments
121/169
Catalogue Oracle
Catalogue d’Oracle : Contention
V$lock : verrou externe

V$latch : verrou interne d’Oracle
V$rollstat : statistiques sur les segments d’annulation
V$process : nombre de process actifs
V$waitstat : statistiques sur les contention des blocks
122/169
Catalogue Oracle
Catalogue d’Oracle : Mémoire
V$buffer_pool_statistics : statistiques sur buffer pool

V$db_object_cache : objets de la base, dans le cache
V$rowcache : échec et succès dans le dictionnaire
V$sysstat : statistique sur l’instance d’Oracle
V$librarycache : statistiques sur le librarycache
123/169
Catalogue Oracle
Catalogue d’Oracle : Session
V$session : liste des sessions

V$sesstat : statistiques des sessions
V$session_event : informations sur les attentes d’une
session
V$session_wait : attentes des sessions actives
V$waitstat : statistiques relatives aux attentes
V$open_cursor : liste des curseurs ouverts
124/169
Optimisation des applications – Recettes
Comment améliorer le temps de réponse des applications ?
Partitionnement
Exécution parallèle
Tuning des entrées/sorties
Détection des lignes chaı̂nées ou migrées
Détection des Index inutilisés
Réorganisation des index
Utilisation des Hints
Codes SQL à ne pas utiliser
125/169
Création d’une table partitionnée sous Oracle
Create t a b l e f a c t u r e
( n u m f a c t number ( 5 ) ,
n u m a r t i c l e number ( 5 ) ,
d a t e v e n t e date
)
P a r t i t i o n by r a n g e ( d a t e v e n t e )
(
p a r t i t i o n p 200312 values l e s s than
( t o d a t e ( ’ 2004−01−01 ’ , ’YYYY−MM−DD ’ ) ) ,
( t o d a t e ( ’ 2004−07−01 ’ , ’YYYY−MM−DD ’ ) ) ,
( t o d a t e ( ’ 2005−01−01 ’ , ’YYYY−MM−DD ’ ) )
)
126/169
Exécution parallèle de la création d’index sous Oracle
Create i n d e x i d x t l c n t 1 on t l c n t ( n 0 c n t )
Tablespace tbs index
S t o r a g e ( i n i t i a l 10M next 5M)
parallele 3
Nologging
Local ;
127/169
Tuning des Entrées/sorties
Desc V$filestat
file# : numéro du fichier
phyrds : lecture disque
phywrts : écriture disque
phyblkrd : nbre de block disque lus
phblkwrt : nombre de block disque écrits
readtim : temps de lecture
writetim : temps d’écriture
128/169
Tuning des Entrées/sorties
Pour les fichiers dont la colonne phyrds est importante :

vérifier si les tables sont accédées en full scan
S e l e c t name , v a l u e from V$SYSSTAT
Where name l i k e ’%t a b l e s c a n ( l o n g% ’
Si la valeur value est importante : vérifier les applications ...

→ Définir les bons index
129/169
Détection de l’état de chaı̂nage d’une table

Analyze table scott .EMP compute statistics
S e l e c t num rows , c h a i n c n t
from d b a t a b l e s
where t a b l e n a m e = ’EMP ’ ;
→ Augmenter la valeur de pctfree de la table EMP
130/169
Etat de chaı̂nage au niveau de la base

Détection de l’état de chaı̂nage au niveau de la base :
s e l e c t ∗ from v $ s y s s t a t
where s t a t i s t i c = ’ T a b l e F e t c h C o n t i n u e d Row ’ ;
131/169
Détection des Index inutilisés
Alter index nom index monitoring usage;
Select index name , used

From v $ o b j e c t u s a g e
where i n d e x n a m e = ’NOM INDEX ’ ;
Alter index nom index nomonitoring usage;
132/169
Stratégies d’indexation
Quand faut-il utiliser les index ?

Construction d’index optimaux
Quelques options d’indexation :
Non-unique index (index avec doublons)
Unique index (index sans doublons)
Bitmap index
Hash partitionned index
Composite partitioned index
Reverse-key index
Function-based index
Descending index
etc.
133/169
Stratégies d’indexation
Index de fonction :
Create i n d e x i d x c l t s n o m p r e n
on c l i e n t ( upper ( nom ) , prenom ) ;
Create i n d e x i d x c l t s c a
on c l i e n t ( c a l c u l c a ( i d c l i e n t ) ) ;
−−− c a l c u l c a e s t une p r o c é d u r e PL/SQL
Quand faut-il reconstruire les index ?
134/169
Réorganiser/Reconstruire un index ?
EXECUTE d b m s s t a t s . g a t h e r i n d e x s t a t s
( ’SCOTT ’ , ’ INDEX 1 ’ ) ;
→ Équivalent de ANALYZE INDEX VALIDATE STRUCTURE

Desc Index_stats
lf_rows : Nombre de valeurs présentes dans index

lf_rows_len : Longueur de l’index (en octets)
Del_lf_rows : Nombre de valeur supprimées
del_lf_rows_len : Longueur d’index supprimées (en octets)
135/169
Réorganiser/Reconstruire un index ?
Quand reconstruire un index ?
S e l e c t name ,
( d e l l f r o w s l e n , / l f r o w s l e n )∗100 moyen del
from i n d e x s t a t s ;
→ si moyen_del > 20% alors reconstruire index

a l t e r index s c o t t . i n d e x 1 r e b u i l d ;
136/169
Utilisation des hints

Hint :
indication placée dans une requête pour orienter le plan
d’exécution
ressemble beaucoup à un commentaire, à l’exception du +
après le /*
Exemple :
SELECT /∗+ LE HINT ∗/ c o l o n n e ( s ) FROM t a b l e ( s ) WHERE . . . ;
Remarques :
Il est très important de placer le hint à l’emplacement
approprié du code SQL, idéalement avant la référence à la
première colonne du code SQL
Si le hint inclus est incorrect il sera tout simplement ignoré
par l’optimiseur, sans affichage de la moindre erreur !
137/169

Exemple/syntaxe générique :
SELECT /∗+ LE HINT ∗/ c o l o n n e ( s ) FROM t a b l e ( s ) WHERE . . .
Instantiation de LE_HINT :
FULL(table) : Parcours de toute la table (sans utiliser l’index)

INDEX(table, index) : Force l’utilisation de l’index de la table
NO_INDEX(table, index) : Désactivation de l’index de la table
ORDERED : Force l’ordre de jointure des tables, telles qu’elles
apparaissent dans la clause From
FIRST_ROWS : Force Oracle à choisir le plan d’exécution qui re-
tourne les n premières lignes de manière la plus effi-
cace
PARALLEL(table, n) : Spécification des n serveurs concurrent pouvant être
utilisés pour une requête
etc. :
(voir : http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm#i8327)
138/169
Outils d’aide :
PRECISE : suivi d’une base de production
TOAD : suivi du passage du prototypage à la production
OEM : Oracle Entreprise Manager
etc.
139/169
Utilisation ORDERED : impose à l’optimiseur d’utiliser les tables

dans l’ordre d’apparition dans la requête SQL
S e l e c t /∗ + ORDERED ∗/ d . d e p a r t e m e n t n a m e , e . surname
from e m p l o y e e s e , d e p a r t e m e n t d
where d . d e p a r t e m e n t i d=e . d e p a r t e m e n t i d
and d . d e p a r t e m e n t n a m e = : 1 ;
140/169
Utilisation INDEX : impose à l’optimiseur d’utiliser les indexes

spécifiés par le Hint INDEX
S e l e c t /∗ + INDEX ( e , e m p l o y e i d x ) ∗/ nom
from e m p l o y e e s e
where e . d e p a r t e m e n t i d = : 1
and e . m a n a g e r i d = : 2 ;
ALTER SESSION SET o p t i m i z e r g o a l= r u l e |

f i r s t r o w s | a l l r o w s | choose ;
141/169
Différents types de hints
Optimisation :
FIRST_ROWS, ALL_ROWS : Force Oracle à utiliser les premières
ou toutes les lignes
ORDERED : Accès aux tables dans l’ordrede de la clause FROM
Accès: FULL(tab), ROWID, PARALLEL
142/169
Impact des Hints – Exemple
SQL> EXPLAIN PLAN

2 SET s t a t e m e n t i d = ’ r e q u e t e 4 ’
3 FOR s e l e c t nom , prenom , num cours , p o i n t s from e l e v e s e , resultats r
4 where r . n u m e l e v e = e . n u m e l e v e and e . n u m e l e v e = 10 ;
SQL> SELECT LPAD( ’ ’ , 2 ∗ ( LEVEL − 1 ) ) | | o p e r a t i o n | | ’ ’ | | o p t i o n s | | ’ ’ | |

2 FROM p l a n t a b l e
3 START WITH i d = 0 AND s t a t e m e n t i d = ’ r e q u e t e 4 ’
4 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 4 ’ ;
P l a n d ’ e x é c u t i o n
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
NESTED LOOPS
INDEX UNIQUE SCAN PK ELEVES
INDEX RANGE SCAN PK RESULTATS
6 l i g n e ( s ) s é l e c t i o n n é e ( s ) .
143/169
Impact des Hints

Exemple
SQL> EXPLAIN PLAN

2 SET s t a t e m e n t i d = ’ r e q u e t e 4 ’
3 FOR s e l e c t /∗+ FULL ( e l e v e s ) FULL ( r e s u l t a t s ) ∗/ nom , prenom , num cours , p o i n t s
from e l e v e s e , r e s u l t a t s r
4 where r . n u m e l e v e = e . n u m e l e v e and e . n u m e l e v e = 10 ;
E x p l i c i t é .
SQL> SELECT LPAD( ’ ’ , 2 ∗ ( LEVEL − 1 ) ) | | o p e r a t i o n | | ’ ’ | | o p t i o n s | | ’ ’ | |

2 FROM p l a n t a b l e
3 START WITH i d = 0 AND s t a t e m e n t i d = ’ r e q u e t e 4 ’
4 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 4 ’ ;
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
HASH JOIN
INDEX RANGE SCAN PK ELEVES
6 l i g n e ( s ) s é l e c t i o n n é e ( s ) .
144/169
Impact des Hints

Exemple
Sans le Hint :
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
NESTED LOOPS
INDEX UNIQUE SCAN PK ELEVES
Avec le Hint : FULL(eleves) et FULL(resultat)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
HASH JOIN
INDEX RANGE SCAN PK ELEVES
145/169
Les codes SQL à ne pas écrire

Premier exemple
Eviter l’utilisation des index dans les clauses where
→ Consultation par les instructions SQL d’un plus grand
nombre de blocs de données
en utilisant l’index
plutôt qu’en exécutant un balayage complet de la table
Amélioration :
ajout d’une expression anodine à la colonne d’index
Par exemple :
ajout de +0 à une colonne numérique
concaténation d’une chaı̂ne vide à une colonne alphanumérique
positionnement du hint :
/∗+ FULL s i v o u s u t i l i s e z l ’ o p t i m i s e u r s t a t i s t i q u e .
S e l e c t /∗+ FULL (EMP) PARALLEL (EMP, 2 ) ∗/ from EMP

Where . . . . . .
146/169

Deuxième exemple
Eviter de mélanger ou de comparer des valeurs et des types de

données de colonnes
→ l’optimiseur ignorera l’index
Améliorations :
Si le type de colonne est NUMBER : ne pas ’utiliser de guillemets
pour encadrer la valeur
Ne pas oublier d’encadrer une valeur avec ses guillemets
lorsqu’elle est définie comme de type alphanumérique
Select ... from EMP where SALARY > ’ 1000 ’ ; −− Mauvais

Select ... from EMP where SALARY > 1000 ; −− Bon
Select ... from EMP where MANAGER = SMITH ; −− Mauvais
Select ... from EMP where MANAGER = ’SMITH ’ ; −− Bon
147/169

Troisième exemple : Ne pas utiliser l’opérateur IS NULL dans
une colonne indexée
→ l’optimiseur ignorera l’index
SELECT N emp , name , a d r from EMP name i s n u l l ;
NB: ce n’est plus vrai avec Oracle 11g
Quatrième exemple :
En cas d’utilisation de curseurs ou du SQL dynamique : ne pas
coder pas ls instruction avec des valeurs en dur
Empêche la réutilisation du code SQL dans le pool partagé
→ Utiliser des variables liées :
S e l e c t . . . from EMP where EMPNO = 2324 ; −− Mauvais
S e l e c t . . . from EMP where EMPNO = : 1 ; −− Bon
EXECUTE IMMEDIATE ’ D e l e t e from EMP w h e r e EMPNO = 2324 ’ ; −− Mauvais
EXECUTE IMMEDIATE ’ D e l e t e from EMP w h e r e EMPNO = : 1 ’ USING v a r i a b l e ; −− Bon
148/169
Amélioration de l’utilisation des bind variables à partir de

Oracle 8i
→ Insertion du paramètre CURSOR_SHARING=force dans le
fichier init.ora
NB :
Possibilité de définir le paramètre au niveau session
Mais possibilité d’augmentation des délais d’analyse
Il peut être préférable de réécrire le code
149/169

Pas d’instruction Insert, update ou delete dans une itération
(une boucle PL/SQL) si les opérations peuvent être réalisées
en vrac (bulk)
Declare
C u r s o r . . . s e l e c t from X
Begin
For C u r s o r i n . . . Loop
Insert into Z
values ( Cursor . col1 , Cursor . col2 ∗1.5 , ... ) ;
Commit ;
End l o o p ;
End ; −− Mauvais
Begin
I n s e r t i n t o Z s e l e c t c o l 1 , c o l 2 ∗ 1 . 5 from X where ;
Commit ;
End ; −− Bon
150/169

Evitez l’utilisation des sous-requêtes
→ Impact négatif sur les performances de votre système en
consommant beaucoup de ressources CPU
Solution : utilisation des vues en ligne (inline views),
c’est-à-dire des sous-requêtes dans la clause from de
l’instruction select, disponible depuis la version 7.3
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 t i d = e . d e p t i d ) ; −− M a u v a i s
S e l e c t e . ∗ from EMP e ,
( s e l e c t i . d e p t i d DEP , avg ( i . s a l a r y ) SAL from EMP I
group by d e p t i d ) EMP VUE
where e . d e p t i d = EMP VUE . d e p t i d and
e . s a l a r y > EMP VUE . SAL ; −− Bon
151/169
Evitez les produit cartesien

Ne pas construire la clause from d’une instruction select
avec des tables qui n’apparaissent pas dans les conditions de
jointure de la clause where afin d’éviter de réaliser un produit
cartésien
Regrouper la création des tables et l’insert
Si la table est créée et alimentée, regrouper l’opération :
C r e a t e t a b l e X ( c o l 1 number , c o l 2 v a r c h a r 2 ( 3 0 ) . . . ) ;
I n s e r t i n t o X s e l e c t c o l 1 , c o l 2 from Y . . . ; −− M a u v a i s
C r e a t e t a b l e X ( c o l 1 number , c o l 2 v a r c h a r 2 ( 3 0 ) ... )
as s e l e c t col1 , c o l 2
from Y . . . ; −− Bon
152/169
Eviter l’utilisation de select x from dual

Bien qu’elle semble innocente, elle peut consommer l’essentiel
des performances de votre système
For i i n 1 . . 1 0 0 0 0 l o o p
S e l e c t SEQ . NEXTVAL i n t o m a v a r i a b l e from d u a l ;
Insert into X values ( mavariable , . . . ) ;
End l o o p ; −− Mauvais
For i i n 1 . . 1 0 0 0 0 l o o p
I n s e r t i n t o X v a l u e s (SEQ . NEXTVAL, ... );
End l o o p ; −− Bon
153/169

Eviter l’utilisation de NOT IN
Privilègier l’utilisation de NOT EXISTS plutôt que NOT IN dans
les clauses where (voir l’utilisation d’une jointure externe)
avec not in (lent)
S e l e c t a . nom , a . prenom
From S a l a r i e a
Where a . nom no t i n
( s e l e c t nom from F o n c t i o n
where j o b = ’INFORMATICEN ’ ) ;
avec jointure externe (plus rapide)

S e l e c t a . nom , a . prenom
From S a l a r i e a , F o n c t i o n b
Where a . nom = b . nom(+) and b . nom i s NULL
And b . j o b = ’ INFORMATICIEN ’ ;
154/169

Utiliser l’opérateur LIKE avec un caractère initial plutôt que la
fonction SUBSTR()
Dans le cas de requêtes très complexes contenant de
nombreuses conditions OR
Envisager leur réécriture à l’aide de UNION ALL
Possibilité de découpage de la requête en modules bien
dimensionnés qui pourront être optimisés plus facilement
Rappel :
Opérateur UNION : récupération de l’ensemble des
enregistrements retournés par les deux requêtes
Les doublons ne sont pas pris en compte
Opérateur UNION ALL : récupération de tous les
enregistrements y compris les doublons (contrairement à
l’opérateur UNION)
155/169
Utiliser les index appropriés, les plus sélectifs

La sélectivité des données est le ratio entre le nombre de clés
uniques et le nombre de lignes
Plus elle approche 1.00, meilleur est l’index
Créer des index sur les colonnes de clés étrangères
Utiliser des index composites
Ceux-ci doivent être classés dans l’ordre décroissant de
sélectivité.
156/169
Utiliser des index bitmaps lorsque la clause where

contient des colonnes à faible cardinalité ou des opérations
logiques comme OR, AND ou NOT exécutées sur ces colonnes
renvoit un grand nombre de lignes de la table
(sauf pour les tables supportant un grand nombre d’opérations
DML simultanées, du fait de leur comportement
intrinsèquement bloquant)
157/169
Utiliser des single-table hashs ou des index clusters

Ces méthodes fournissent des performances excellentes sur les
tables relativement statiques mais interrogées sur une large
plage de valeurs
Sachant qu’un cluster enregistre les données dans un bloc de
manière ordonnée, un balayage de plages utilisant un index sur
ce cluster réalisera un plus petit nombre d’opérations
d’entrées-sorties pour répondre à la requête
158/169
Choisir de manière active le type de jointure : nested loop,

merge join ou hash join
Lors de la jointure de trois tables ou plus, essayez de
structurer la requête pour réaliser l’élimination la plus forte
sur la première jointure
→ incorporer toutes les conditions sur une table dans la clause
where.
Privilégier le traitement en vrac (BULK COLLECT / FORALL)
159/169

A partir d’Oracle 8i, remplacer DBMS_SQL par la nouvelle
fonctionnalité execute immediate (fonctionne nettement
mieux)
E x e c u t e immediate ’CREATE TABLE XX AS SELECT ∗ FROM YY ’ ;
En cas d’utilisation de l’optimiseur syntaxique (ce qui ne

devrait plus durer)
Structurer les clauses from de manière à ce que la table la
plus petite soit la dernière définie dans la liste des tables
S’il est nécessaire d’accélérer la création d’un index
Augmenter la valeur du paramètre SORT_AREA_SIZE au
niveau session
→ l’essentiel des tris seront exécutés en mémoire
160/169
Vos requêtes SQL en mode trace
Les étapes du processus d’optimisation
Activation d’une session en mode trace
161/169

1 Vérifier que le paramètre TIMED_STATISTICS est positionné à TRUE au
niveau instance
2 Vérifier que la valeur du paramètre MAX_DUMP_FILE_SIZE est suffisante
Ce paramètre détermine la taille maximale du fichier de trace
3 Déterminer l’emplacement pointé par le paramètre USER_DUMP_DEST
USER_DUMP_DEST : indication de l’emplacement où les fichiers de trace
seront enregistrés
4 Activer le paramètre SQL_TRACE pour la session concernée
5 Exécuter l’application
6 Exécuter tkprof sur les fichiers de trace
7 Etudier le fichier de sortie de tkprof
8 Ajuster les instructions SQL les plus coûteuses
9 Répéter les étapes 4 à 8 jusqu’à ce que l’objectif de performance soit
atteint
162/169
Remarque : Ne pas positionner pas le paramètre SQL_TRACE à

TRUE dans le fichier init.ora :
Toutes les instructions SQL exécutées seraient enregistrées,
aboutissant à un ralentissement sensible du système, ainsi
qu’à la saturation du système de fichiers
163/169
Activation d’une session en mode trace

Exécution de la commande suivante :
a l t e r session set t i m e d s t a t i s t i c s = true ;
a l t e r session set s q l t r a c e = true ;
...
−− e x e c u t i o n de v o s t r a i t e m e n t s . . .
...
a l t e r session set t i m e d s t a t i s t i c s = f a l s e ;
a l t e r session set s q l t r a c e = f a l s e ;
Remarques :
(à partir de la version 7.2) il est possible de désactiver la trace
à partir d’une autre session
Ne pas désactiver la trace en annulant la session (kill)
→ Peut provoquer la troncature du fichier de trace et/ou
introduire des informations erronées dans ce fichier
164/169
TKPROF
TKPROF
Mettre la base ou la session en mode Trace :

Base : mettre SQL_TRACE=TRUE dans init.ora
Session :
a l t e r s e s s i o n s e t SQL TRACE TRUE
s e t a u t o t r a c e on
Utilisation de TKPROF : pour analyser le fichier trace

Syntaxe :
TKPROF fichier_entree.trc fichier_sortie
[Explain=username/password] [sys=no]
[insert=filename] [print=entier]
165/169
TKPROF
Exemple de TKPROF
SELECT NVL(TO_CHAR(CG,’YYYYMMDD’),’ ’)||C01||C02||C03||C04||C05||C06||C07

FROM
D21V2_ENGSEC WHERE CB = :0000
call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 24562 2.64 2.66 0 0 0 0
Execute 24562 1.44 1.23 0 0 0 0
Fetch 24562 0.49 0.33 0 24562 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 73686 4.57 4.22 0 24562 0 0
Misses in library cache during parse: 0

Optimizer goal: RULE
Parsing user id: 34
Rows Row Source Operation

------- ---------------------------------------------------
0 TABLE ACCESS BY INDEX ROWID D21V2_ENGSEC
1 INDEX UNIQUE SCAN (object id 103435)
166/169
TKPROF
Interprétation du résultat de TKPROF

Call : La phase du traitement de l’instruction SQL (
les phases define et bind sont incluses dans la phase parse
Count : Le nombre d’appels et d’exécutions d’une phase
CPU : Le temps CPU (en secondes) consommé pour
l’exécution d’une phase
Elapsed : Le temps CPU (en secondes) écoulé, cumulé avec
l’ensemble des temps utilisés par le SE pour
réaliser les changements de contexte
traiter les interruptions
répondre aux signaux
exécuter les entrées-sorties
attendre les ressources
etc.
167/169
TKPROF
Interprétation du résultat de TKPROF
Disk : Le nombre de blocs Oracle lus sur le disque pour une

phase donnée
Query : Le nombre de blocs Oracle lus en mémoire en mode
cohérent (consistent mode)
Current : Le nombre de blocs Oracle lus en mémoire en
mode courant
Rows Le nombre de lignes traitées dans chaque phase, avec les
valeurs pour les instructions select dans la phase fetch, et
pour les opération insert, update dans la phase execute
168/169
Utilitaires et Outils d’optimisation
Utilitaires et Outils d’optimisation

Résumé
TOAD
OEM
TKPROF (outil capable de générer des traces)
UTLBSTAT/UTLESTAT
STATPACK (UTL et STAT sont des outils équivalents qui
permettent de recenser les requêtes les plus consommatrices)
Scripts du DBAs (le DBA doit développer ses scripts)
169/169

Langue

CoursBDA AIR3 Optimisation

Transféré par

Informations du document

Titre original

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 :

CoursBDA AIR3 Optimisation

Titre original :

Transféré par

Droits d'auteur :

Administration de Bases de Données

Optimisation d’une Application ?

Quand décide-t’on d’optimiser ?

Quand décide-t’on d’optimiser ?

Qui participe et pourquoi ?

Adminstrateurs de DB, Développeurs, Ingénieurs Système

Type du SGBD (Oracle, DB2, etc.)

Type de l’application (Batch, TP)

Langage de programmation utilisé (Java, PL/SQL, etc.)

Qu’est-ce qui reste à faire ?

Les besoins en puissance machine définis

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

Partie N◦ 1 : Conception des systèmes d’informations et

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

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

Partie N◦ 1 : Conception des systèmes d’informations et

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

Partie N◦ 2 : Présentation des outils pour assurer le suivi de la

déterminer la bonne taille des buffers de la base

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

Partie N◦ 2 : Présentation des outils pour assurer le suivi de la

Ne pas oublier de recenser les disques les plus sollicités, les

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

Partie N◦ 2 : Présentation des outils pour assurer le suivi de la

Etudier les locks, les latches et les wait events au niveaux de

Lors de la conception des systèmes d’informations

Optimisation des applications :

Clarifier et situer les différents paramètres internes des SGBD

Augmentation des performances

Pour augmenter les performances trois grandes solutions

Optimisation logique de la Base de Données

Schéma Conceptuel de Données (SCD),

En EA, transformation en schéma relationnel (Schéma Logique de

Optimisation logique de la Base de Données

Normalisation : processus permettant de s’assurer de la  Bonne

Décomposition de la relation Relation1, en deux ou plusieurs

Les relations obtenues doivent être en 3ème Forme Normale, au

Format d’une relation  bien conçue 

en deux relations CPR et CPV (en FN de Boyce et Codd) :

SELECT ∗ FROM CLIENT ;

SELECT ∗ FROM CLIENT , ADRCPR, ADRCPV

Un schéma relationnel normalisé

Optimisation logique de la Base de Données

Technique d’optimisation des requêtes d’interrogation

Optimisation logique de la Base de Données

Deux méthodes de réalisation de la redondance calculée :

Optimisation logique de la Base de Données

Optimisation logique de la Base de Données

Dans les trois cas, stockage des données, physiquement dans

Optimisation logique de la Base de Données

Base de données SportAct : Adhérents à des centres sportifs

Requête fréquente : Nombre d’inscrits dans un centre c ?

Optimisation logique de la Base de Données

Création d’une nouvelle colonne NbrInscr dans la table

Nouvel ordre SQL :

Optimisation logique de la Base de Données

Impact sur le reste de la base de données

→ La cohérence est affectée si on ne le fait pas

Optimisation logique de la Base de Données

Chaque opération INSERT / DELETE implique une opération

DELETE FROM ESTMEMBRE WHERE ... ; doit être

Optimisation logique de la Base de Données

Requête : Nombre d’inscrits par centre et par mois ?

Nécessité d’un nouveau traitement mensuel pour l’actualiser

Normalisation : processus permettant de s’assurer de la Bonne

Format d’une relation bien conçue