> Tech > Utiliser PEX pour analyser les statistiques d’I/O

Utiliser PEX pour analyser les statistiques d’I/O

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

Ayant bien compris les différents types de méthodes d’accès aux données dont disposaient les programmes HLL, le DBA allait recueillir des statistiques sur les méthodes qu’utilisaient les programmes d’application. C’est là où PEX entre en scène. Il existe trois types de collecteurs PEX : Stats, Profile et Trace. (Pour plus

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).

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 - Publié le 24 juin 2010