5. Des moniteurs de performances DB2 plus rapides et plus intelligents

détaillé.
Le moniteur de performance des bases de données a le
défaut de collecter de gros volumes de données, au grand
dam des ressources disque et CPU du serveur. Nous avons
testé ce point et constaté que l’utilisation du moniteur de
performance des bases de données pouvait ajouter jusqu’à 
20 % d’overhead au système. Pour donner une idée de l’impact
sur le stockage disque, permettez-moi de donner les résultats
d’un autre test effectué sur un système client utilisant
une application ERP : il a entraîné la collecte de trois millions
de lignes de données moniteur en10 minutes !
Pour atténuer l’overhead, DB2 UDB V5R3 possède
quelques nouvelles options (avec les PTF V5R2 disponibles)
qui permettent de diminuer la quantité de données que
10 Le mensuel des professionnels AS/400 & iSeries Février 2005
>> LA FONCTION REPLACE PERMET AUSSI DE TENIR
à€ JOUR DES DONNEES VALIDES
collecte le moniteur de bases de données.
Une réduction de la quantité de
données présente un double avantage
: le moniteur de performance a
moins d’impact sur le système et l’analyse
des données est plus simple tout
simplement parce qu’il y en a moins à 
examiner.
La première nouvelle option est un
réglage pour le fichier QAQQINI, DATABASE_
MONITOR_THRESHOLD. Ce
seuil permet de ne collecter des données
du moniteur que pour les requêtes
de base de données d’exécution
longue. Cette option donne de
bons résultats parce que la plupart des
analyses de données du moniteur de
performance se concentrent sur les
données provenant de consultations
ou d’instructions SQL de plus longue
exécution. Ainsi, si on spécifie une valeur
de 60 pour le paramètre DATABASE_
MONITOR_THRESHOLD dans
le fichier QAQQINI, le moniteur de
base de données ne collecte les données
que sur les requêtes dont l’optimiseur
de requêtes estime que l’exécution
ne dépassera pas 60 secondes.
Bien que ce seuil se fonde sur une estimation,
il est efficace pour éliminer
toutes les données du superviseur collectées
pour des opérations de base de
données d’exécution courte.
L’autre nouvelle option permettant
de réduire la quantité de données collectées
est une option filtre de table associée
à  la commande CL STRDBMON.
Comme IBM a ajouté le filtre de table
après la release V5R3 initiale, il n’était
pas possible d’ajouter un nouveau paramètre
à  la commande. Par conséquent,
il faut spécifier le filtre de table
sur le paramètre COMMENT de la commande
STRDBMON, comme dans
l’exemple suivant :

STRDBMON OUTFILE(mylib/mydata)
COMMENT(‘TABLEFILTER(lib1/tab1,lib2/tab3)’)

Ici, le filtre de table ordonne au
moniteur de collecter des données sur
les consultations et les requêtes SQL
qui font référence aux tables LIB1/
TAB1 et LIB2/TAB3. Le moniteur de
performance de bases de données
ignore les opérations du type base de
données sur toutes les autres tables. Le
filtre de table est appliqué après
que DB2 ait entièrement analysé syntaxiquement
la requête. L’avantage d’appliquer le filtre après que DB2 ait analysé syntaxiquement
l’instruction, est que DB2 peut collecter des instructions
concernant des références indirectes à  la ou aux tables
filtrées. Ainsi, si une vue SQL appelé V1 est définie sur la table
TAB1, le moniteur de bases de données collecte des données
sur les consultations qui référencent V1 parce que, en définitive,
elles accèderont à  la table TAB1.
définitive,
elles accèderont à  la table TAB1.
L’exemple précédent montre que l’option de filtrage de
table oblige à  utiliser un nom de bibliothèque pour qualifier
les noms de tables (le caractère barre oblique servant de délimiteur).
Le nom de table ne doit pas dépasser 10 caractères.
Au-delà , il faut utiliser son nom de système raccourci dans
l’option de filtrage de table. Pour trouver un nom de système
raccourci pour une table SQL, utilisez iSeries Navigator ou
consultez le catalogue SYSTABLES de la bibliothèque QSYS2.
Souvent, c’est une ou deux grandes tables qui demandent
l’essentiel de votre réglage de performance de base de
données. Il est donc intéressant de pouvoir limiter les données
du moniteur à  ces objets DB2. Pour utiliser ces nouvelles
options du moniteur de base de données, il faut que la
dernière PTF Database Group V5R2 ou V5R3 ait été appliquée
au système.
Vous trouverez plus de détails sur le fichier QAQQINI et
son paramétrage dans le guide d’optimisation des performances
et des requêtes sur les bases de données (performance
and query optimization guide) à  l’iSeries InfoCenter
(dans la barre de navigation, cliquez sur Database puis
cliquez sur Performance and optimization). Un autre site
Web donne des informations sur les différents paramétrages
disponibles pour le fichier des options QAQQINI dans la section
« BI – Custom Query Options Builder » du site Virtual
Innovations for Hardware d’IBM à  ibm.com/servers/
enable/site/bi/tuner/index.html.