HTML sur un écran, car cette opération engendre de l’overhead et produit une taille de page bien plus grande. Dans la mesure du possible, les requêtes ne doivent renvoyer que les données dont l’application a vraiment besoin. Surveillez, et modifiez éventuellement, les requêtes dont le temps de réponse est susceptible de changer au fur et à mesure que les fichiers grossissent. Quand le fichier croît, l’optimiseur peut effectuer de nouvelles optimisations, ou de nouveaux index peuvent s’avérer nécessaires pour maintenir le même temps de réponse qu’auparavant. Il en est souvent ainsi quand la séquence d’arrivée est utilisée pour accéder à un fichier, ou qu’on utilise un index qui ne couvre pas toutes les conditions de prédicat.

Il vaut toujours mieux avoir un mécanisme intégré dans une application, pour corréler l’activité de la base de données avec une requête utilisateur donnée. Mais si la trace appropriée n’a pas été intégrée dans le code, pas de panique. Pour vous aider à déboguer les problèmes de performances, l’iSeries offre de nombreux outils, comme le moniteur de base de données (livré avec chaque système) et iDoctor. Vous trouverez plus d’informations sur iDoctor à www- 912.ibm.com/i_dir/idoctor.nsf/jw.html.