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

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

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Dan Cruikshank, Mis en ligne le 07/06/2006 - Publié en Février 2006

Dans l’article « Comparaison des performances entre fichiers définis par DDS et fichiers définis par SQL » (iSeries News juillet 2005, www.itpro.fr Club abonnés), j’expliquais les différences architecturales entre les objets base de données créés par SQL DDL et DDS. J’indiquais aussi comment reconditionner les bases de données DDS existantes pour que les programmes HLL existants puissent bénéficier des améliorations SQL. Cette stratégie constitue la phase 1 de ma méthodologie de réingénierie de base de données et de transformation des programmes applicatifsIci, je commence à examiner la phase 2 :
l’isolation de la base de données. En fait, la phase 1 était la première étape vers cette isolation. En essence, tous les objets et membres source PF (Physical File) DDS ont été convertis en objets et membres source LF (Logical File) DDS. Le code source LF DDS existant a été modifié pour partager les chemins d’accès index 64 K SQL et, si nécessaire, partager le format du fichier physique original transformé (figure 1).

Les environnements de la phase 2 sont caractérisés par la séparation de la fonction d’I/O base de données d’une part, des processus de gestion et de présentation de l’application d’autre part. Cela a porté plusieurs noms (développement d’application n-tier, Model-View-Controller, par exemple).
Pour obtenir les meilleurs résultats avec SQL, je vous conseille de commencer avec une base de données créée par SQL (phase 1) et d’effectuer tous les accès base de données via des instructions DML (Data Manipulation Language) SQL imbriquées dans les modules d’I/O HLL (phase 2).

J’évoque d’autres changements architecturaux notables concernant la manière dont un programme HLL RLA (Record Level Access) et un programme HLL contenant du SQL imbriqué statique, sont activés puis exécutés. En particulier, je compare la vérification du format d’enregistrement RLA et la validation du plan d’accès SQL et je parle de la faculté de réutilisation d’ODP (Open Data Path).

Je suis la structure de la série Performance Mystery écrite avec James Stewart. Pour commencer, je présente une situation client réelle, en comparant les résultats avant et après.
Ensuite, j’entre dans le détail de la solution à apporter au problème client. Je clos le débat avec quelques considérations et recommandations.
Dès lors que les développeurs d’applications comprennent le mécanisme de base de l’initiation, de l’exécution et de la terminaison des programmes, ils pourront écrire un code meilleur et plus efficace dès la première fois, évitant ainsi de rendre une visite coûteuse à votre serviteur. Parfois, ces visites ne sont pas très agréables.

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.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro.fr - Publié le 24 juin 2010