Dans la nouvelle architecture de type RISC introduite en V4R1/V3R6, IBM a ajouté au système d’exploitation de nouveaux collecteurs de données de performances. Ces collecteurs fournissent les données brutes destinées à une variété d’applications et d’outils d’analyse SQL. Cela inclut la suite d’outils IBM iDoctor (comme Job Watcher, PEX Analyzer) et l’outil IBM SQL Visual Explain, qui fait partie de iSeries Navigator.Ces outils permettent de développer des applications efficaces, que ce soit sous SQL ou par des méthodes d’accès aux données traditionnelles. Malheureusement, dans beaucoup d’entreprises, les développeurs (a) ne connaissent pas l’existence de ces outils, (b) n’ont pas le droit d’y accéder, (c) ne comprennent pas la sortie fournie par eux, ou (d) cumulent les trois handicaps ci-dessus.
Dans cet article et plusieurs autres à suivre, je démontrerai comment ces outils contribueront à la modernisation des bases de données. En particulier, je décrirai l’utilisation du collecteur de statistiques PEX (Performance Explorer) pour l’analyse d’accès aux données traditionnelle et l’utilisation du Database Monitor pour l’analyse d’accès aux données SQL.
Analyser les méthodes d’accès aux données
Acme Enterprises est un client IBM de taille moyenne qui exerce depuis le début des années 1970, quand il a acheté son premier système à cartes : IBM System 3 modèle 10. Au fil des ans, Acme a développé son activité et a fait évoluer son équipement : S38 puis AS/400 840.
Récemment, en prévision d’une acquisition, Acme a grimpé au modèle i595, le tout dernier et le meilleur. A la surprise d’Acme, les anciennes applications (qui n’ont pas beaucoup changé en 20 ans) n’ont pas affiché l’amélioration escomptée. En particulier, le processus batch à une seule file effectué de nuit a mis autant de temps à s’exécuter que sur le système 840.
L’examen des applications d’Acme a conclu à la nécessité d’un remaniement des bases de données. La société a commencé par faire migrer les fichiers critiques vers des tables et des index SQL pour bénéficier des améliorations de DB2 (voir l’article « Remplacer un fichier physique DDS par une table SQL », iSeries News, juillet-août 2005, www.itpro.fr Club Abonnés). L’étape suivante a constitué à nommer l’analyste programmeur le plus ancien au poste d’architecte/analyste de base de données (DBA, database administrator). Avec, à la clé, les responsabilités suivantes :
• Améliorer la performance des anciennes applications,
• Améliorer la performance des programmes plus récents contenant du SQL imbriqué.
Le DBA a commencé par lire plusieurs articles, manuels et whitepapers sur la performance des bases de données. Il en a déduit que le meilleur moyen d’atteindre ses objectifs était de réduire les entrées/sorties (I/O) de base de données associées à la plupart des programmes. Pour identifier ces programmes, le DBA a opté pour les outils PEX et Database Monitor.
Téléchargez cette ressource
État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Analyse Patch Tuesday Juin 2025
- L’IA agentique ouvre la voie à davantage d’alliances stratégiques et d’intégrations technologiques
- Oneytrust, la fintech française référente de la lutte contre la fraude bancaire & e-commerce fête ses 25 ans !
- Prendre en compte le développement durable est un facteur de réussite
- L’IA et le machine learning au service d’une cybersécurité préventive
