Comprendre les plans d’accès et les chemins de données ouverts

ABC Corporation affiche une croissance régulière et de bons résultats. D’où la nécessité de recruter, à l’intérieur et à l’extérieur de l’IT. Mais ABC était dans l’incapacité d’attirer des talents à cause de l’aspect désuet des applications à écran vert existantes et du manque de diplômés formés au RPG.

ABC s’est donc tourné vers un projet de modernisation des applications. Pour l’essentiel, cela consistait à remplacer les écrans verts (passifs) frontaux par des interfaces de navigation sur le Web et à séparer les méthodes d’accès d’I/O RPG en modules d’I/O distincts.

Le projet initial a réussi et compte tenu du bon accueil fait par la communauté utilisatrice, ABC a décidé de poursuivre en convertissant toutes les applications. Les développeurs d’applications ont été autorisés à choisir leur méthode d’accès lors de la création des modules d’I/O. Résultat : les programmeurs de l’ancienne école ont choisi les méthodes d’accès RLA RPG, et les nouvelles recrues ont choisi SQL.

Les temps de réponse interactifs étaient tolérables :
inférieurs à la seconde quelle que soit la méthode d’accès ; en revanche, le processus batch nocturne commençait à souffrir. Au fur et à mesure que la charge de travail a augmenté, le créneau de réalisation du batch nocturne n’a cessé de rétrécir. A tel point que le travail batch a commencé à empiéter sur la productivité de jour, à la grande inquiétude de la direction.

La première enquête menée avec l’outil iDoctor Job Watcher a révélé que beaucoup de temps était consacré aux modules d’I/O SQL par rapport aux modules d’I/O RPG. Cela a causé une division entre les groupes de programmation.
Avant que n’éclate une guerre civile, le CIO (Chief Information Officer) d’ABC a demandé de l’aide à IBM. Peu de temps après, votre serviteur est entré en scène.
La première étape de l’enquête de performance a consisté à créer un environnement de test où les jobs batch pourraient être analysés plus en détail. J’ai utilisé le collecteur de données PEX (Performance Explorer) pendant le test pour identifier les programmes les plus coûteux dans les jobs et les principaux problèmes liés à la performance applicative.

Le graphique de la figure 2 récapitule les principaux modules système i5/OS représentant le temps écoulé le plus long pendant l’exécution du test. Le coût élevé des modules associés à SQL (optimisation et exécution) a validé les constatations du iDoctor Job Watcher :
en substance, une majorité du temps était consacrée aux fonctions SQL.

L’étape suivante a consisté à identifier le ou les programmes qui exécutaient la plupart des fonctions SQL. Il s’est avéré qu’au cours de cette étape du processus nocturne, il n’y avait qu’un programme avec SQL imbriqué. Un examen de celui-ci a révélé qu’on utilisait une option de précompilation médiocre. L’option a été changée, le programme a été recompilé et j’ai effectué un autre test.

Le graphique de la figure 3 montre les résultats de temps d’exécution cumulés avant et après des sessions de tests effectués pendant la visite sur le site. La forte réduction du temps d’exécution a été le résultat de la simple recompilation du programme SQL RPG avec les options de compilation appropriées. Au point que les programmes RPG utilisant RLA sont maintenant en tête de liste des temps d’exécution.

Avant de vous dire quelle était la bonne option de compilation, il est important d’énoncer quelques concepts de base qui s’appliquent à la fois aux programmes RLA et aux programmes contenant le programme SQL imbriqué statique. Ces concepts comportent l’utilisation de plans d’accès et d’ODP. Si les concepts sont les mêmes, leur mise en oeuvre est très différente.