Utiliser PEX pour analyser les statistiques d’I/O

de détails sur les différents types de collecteurs, voir le Work Management Guide à public.boulder.ibm.com/infocenter/ iseries/v5r4/topic/rzahx.pdf.) Dans notre cas, nous opterons pour le collecteur Stats.

Créer une définition. La collecte de données statistiques PEX commence par la création d’une définition PEX. C’est le rôle de la commande ADDPEXDFN (Add PEX Definition). Les données recueillies pour une collection *STATS sont organisées de deux manières : plat (résumé) ou hiérarchique (détaillé). Une collection plate résume par programme, module et procédure à l’intérieur des jobs. Une collection hiérarchique résume par programme, module et procédure au niveau de la relation parent- enfant dans un job. Cette dernière est utile pour une analyse de type « utilisé où ». Généralement, une collection plate ralentit moins l’exécution qu’une collection hiérarchique.

Le DBA a commencé son analyse par le processus de job nocturne. Il a estimé qu’une collection plate, ou résumée, serait le meilleur moyen pour collecter des statistiques pour tout un processus de job batch parce qu’elle lui infligerait moins d’overhead. Voici un exemple de la définition PEX que le DBA a créée pour accomplir cette tâche :

ADDPEXDFN DFN(NIGHTLY1) J
OB((NIGHTLY1))
TEXT(‘Collect Stats Summary Data for a job’)

Dans cette commande, le nom du job batch, NIGHTLY1, est utilisé comme nom de définition et comme nom de job à superviser. Le paramètre JOB permet des noms de jobs simples, des noms de jobs entièrement qualifiés, des noms de jobs génériques, ou des noms d’utilisateurs. Le DBA ne savait pas quel serait le numéro de job ou l’utilisateur pour le job NIGHTLY1, aussi cette information n’est pas fournie dans la définition. Cette omission permet également au DBA de démarrer le collecteur PEX avant le job. Les valeurs par défaut pour une définition et une organisation de données PEX sont *STATS et *FLAT, respectivement.

Une fois les données plates collectées, le DBA a utilisé le collecteur hiérarchique pour procéder à une analyse plus détaillée du job dans un environnement de test. Comme le collecteur de stats hiérarchique ajoute beaucoup plus d’overhead que le collecteur plat, le DBA a décidé de collecter les statistiques dans une session de test beaucoup plus réduite. Il savait parfaitement que la signature de la méthode d’accès aux données (le module QDB) serait la même qu’elle soit appelée 100 fois ou un million de fois. Cela s’explique ainsi : la méthode d’accès HLL est déterminée par les paramètres d’environnement et de compilation, et pas par la quantité de données traitée.

Voici un exemple de définition PEX utilisée pour collecter des données dans l’environnement de test :

ADDPEXDFN DFN(TESTJOB) JOB( (TESTJOB)) DTAORG(*HIER) TEXT(‘Collect Stats Parent-Child Data for a job’)

Le nom de définition TESTJOB sera aussi le nom du job de test soumis par le DBA. Comme stats est la valeur par défaut, le seul autre paramètre nécessaire est le paramètre DTAORG (Data Organization) de *HIER (Hierarchical).