> Tech > Analyser les méthodes d’accès aux données

Analyser les méthodes d’accès aux données

Tech - Par Dan Cruikshank - Publié le 24 juin 2010
email

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

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Dan Cruikshank - Publié le 24 juin 2010