Index Evaluator d’iSeries Navigator

iSeries Navigator a toujours été capable d’afficher une liste
d’index et de fichiers logiques avec clés sur une table particulière,
mais les utilisateurs essayant d’affiner les requêtes ne
recevaient qu’une information limitée et incomplète. Qu’on
en juge : iSeries Navigator ne montrait pas l’index interne associé
à  un fichier physique avec clés, alors même que cet index
était à  la disposition de l’optimiseur de requêtes.
Index Evaluator de la V5R3 simplifie l’analyse de tous les
index mis à  la disposition de l’optimiseur de requêtes et, plus
important, informe sur la fréquence avec laquelle l’optimiseur
de requêtes utilise les index. (Remarque : L’Index
Evaluator V5R3 ne figurait pas dans la release V5R3 initiale. Il
a fallu attendre l’iSeries Access Service Pack de septembre
2004 et les PTF SI12938 et SI12873.) L’index Evaluator renvoie
une information qui permet de déterminer beaucoup
plus facilement quels index présentent de l’intérêt et lesquels
méritent d’être supprimés. L’Index Evaluator traite et
renvoie des données sur les index que fournissent les
contraintes de clés primaires, les contraintes de clés étrangères,
les fichiers logiques avec clés et les fichiers
physiques avec clés. L’Index
Evaluator renvoie aussi des données à  propos
des index que crée l’instruction SQL
Server Create Index.
Les index bénéficient de l’optimiseur
de requêtes de deux manières et c’est
pourquoi ils jouent un rôle important dans
le réglage fin de la performance des consultations
et des requêtes SQL. En premier
lieu, un optimiseur de requêtes ou de
consultations utilise un index pour consulter
les statistiques concernant les données de la table sousjacente,
comme le nombre de valeurs de clés distinctes et le
nombre de lignes correspondant à  l’argument search de la
requête (par exemple, StateColumn = ‘MN’). Un optimiseur
de requêtes utilise les index d’une deuxième manière pendant
l’exécution des consultations. L’optimiseur utilise des
index pour renvoyer les données dans un certain ordre ou
pour extraire rapidement une ou plusieurs lignes d’une table
(de la même manière que l’index d’un livre permet de trouver
rapidement une page). Pour plus d’informations sur l’utilisation
des index par l’optimiseur de requêtes, voir le white
paper « Indexing and Statistics Strategy for DB2 UDB for
iSeries » à  ibm.com/servers/enable/site/education/ibo/register.
html/indxng (un enregistrement gratuit est nécessaire
pour consulter ce white paper).
Avant que n’existe l’Index Evaluator, il n’était pas facile
aux utilisateurs de déterminer la fréquence avec laquelle
l’optimiseur de requêtes utilisait un index, ou la dernière fois
qu’il avait utilisé un index dans l’un des modes décrits dans
le paragraphe précédent. On pourrait penser qu’il suffit simplement
d’examiner l’attribut d’objet Last Used Date pour
déterminer au moins la dernière fois que l’optimiseur a utilisé
un index. Malheureusement, cette méthode ne marche
pas parce que l’optimiseur ne met pas à  jour cet attribut
quant il utilise les index pour des statistiques ou pour des requêtes
ou consultations.
Après avoir compris tout l’intérêt de l’Index Evaluator,
apprenons à  l’utiliser. Pour accéder à  cette nouvelle fonction,
faites un clic droit sur objet table et sélectionnez la tâche
Indexes, illustrée figure 1. iSeries Navigator renvoie (dans
une nouvelle fenêtre) les résultats d’évaluation pour tous les
index définis sur la table spécifiée (figure 2).
Les deux premières colonnes contiennent le nom et le
type de l’index (par exemple, l’index a-t-il été fourni par un
index SQL ou par un fichier logique avec clés ?). Les quatre
colonnes suivantes contiennent les données qu’il était difficile
d’obtenir par le passé. Les colonnes Last Query Use et
Last Query Statistics Use contiennent la valeur d’horodatage
de la dernière fois que l’optimiseur a utilisé un objet index
pour des statistiques ou pour l’exécution d’une requête.
Dans le même esprit, les colonnes Query Use Count et
Query Statistics Use indiquent combien de fois l’index a été
utilisé dans l’un de ces buts.
Ces quatre colonnes permettent de répondre à  la question
fréquente : « Quels index dois-je garder et lesquels puisje
supprimer ? » Mais avant de commencer à  supprimer tous les index et les fichiers logiques qui affichent une faible utilisation
et d’anciennes valeurs d’horodatage, sachez que,
comme DB2 n’a commencé que récemment à  suivre ces statistiques
d’utilisation en V5R3, il faudra un certain temps
avant que les valeurs de comptage et d’horodatage ne deviennent
exactes. Ainsi, si vous n’avez pas
exécuté les rapports de fin d’année en V5R3,
les statistiques d’usage et les index ne tiendront
pas compte des index qu’utilise le traitement
du rapport de fin d’année. Moralité :
avant de déclencher la suppression ou le
changement de l’index existant, laissez le
temps à  DB2 de suivre l’usage des index et
prenez le temps d’exécuter tous les rapports
et programmes principaux. Les statistiques
d’usage des requêtes d’index ne reflètent
que les consultations et les requêtes SQL pratiquées sur la
V5R3 et les releases futures.
Le nouvel Index Evaluator présente les index sous un
nouveau jour et devrait donc simplifier considérablement le
réglage des requêtes.