Résoudre le mystère

de choix sur la manière
d’exécuter la requête (d’index à  index).

Ce problème pouvait être réglé de
deux manières. La première consistait
à  créer l’index « parfait ». Nous le définissons
comme un index racine contenant
les colonnes nécessaires pour
fournir des statistiques (sélection locale)
et pour satisfaire les jointure,
groupage et/ou classement demandés.
En outre, cet index peut contenir les
colonnes qui font partie du jeu de résultats,
pour réaliser l’accès par index
seulement.

La deuxième possibilité consistait à 
donner à  l’Optimizer l’autorisation de
trier le jeu de résultats. Pour cela, on
met le paramètre ALWCPYDTA à  *OPTIMIZE.
SDFG a choisi cette possibilité
plutôt que de construire davantage
d’index. La figure 5 montre la sortie obtenue
de la commande PRTSQLINF
après recompilation du module
SQL_ORDER3 et mise à  jour et exécution
du programme SQL_SERVER.

La simple recompilation du programme
avec le nouveau paramètre a
fait chuter le temps d’exécution estimé
de 18 secondes à  1 seconde. La consommation de CPU est passée
d’environ 3 secondes à  environ 143
millisecondes – soit une réduction de
95 % de consommation de CPU. SDFG
a constaté une réduction globale de
50 % d’utilisation de la CPU système,
après application du changement. Bien
que le temps écoulé de l’index build
n’ait été que de 0,6 seconde, DB2 avait
utilisé cinq processeurs (en moyenne)
pour accomplir la tâche.

Ce cas démontre deux points importants.
Premièrement, l’Optimizer
est très complexe et est influencé par
plusieurs facteurs. (Deux d’entre eux
étant les index et les options de compilation.)
Deuxièmement, l’Optimizer
a plusieurs choix pour mettre en
oeuvre une instruction SQL unique.

Sans une bonne compréhension
de l’Optimizer et des méthodes d’accès
de données disponibles, il est pratiquement
impossible de déceler et de
résoudre les problèmes d’optimisation
et de performances qui frappent les
applications à  base de requêtes.