> Tech > Last Updater fermant un fichier base de données

Last Updater fermant un fichier base de données

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

Le last updater-close se manifeste sous la forme de nombreuses écritures sur disque base de données, se produisant généralement à la fin d’un job. Pour voir l’activité d’I/O disque, utilisez Job Watcher, Collection Services, WRKSYSACT ou PEX DIO Trace and Analysis.

Comme on l’a vu précédemment, IBM indique

Last Updater fermant un fichier base de données

que la fermeture du fichier (sauf pour un shared close) et l’utilisation de l’opération force-end-of-data forcent les mises à jour, suppressions et additions restantes en stockage auxiliaire. En fait, elle devrait dire que quand un job ferme un fichier pour lequel il est le seul job ayant le fichier ouvert pour mise à jour, le système le considère comme une limite de transaction et s’assure que toutes les pages changées du fichier sont écrites avant que l’opération de fermeture ne se termine. Quand le programme utilisateur reprend la main après la fermeture, tous les enregistrements auront été planifiés pour écriture. Cela peut demander des secondes ou des minutes, parce que chaque écriture est planifiée de manière synchrone pour s’assurer qu’elle est reçue à l’IOP disque et que l’écriture peut aller à son terme.

L’utilisateur final doit donc faire un compromis entre la performance et la reprise. Sachant que les fonctions de terminaison système sont plus intelligentes maintenant que par le passé et qu’elles sont généralement capables d’assurer l’intégrité des données, bien souvent Company aBc peut améliorer le temps d’exécution en évitant une grande partie du traitement du flux de données du last closer.

Savez-vous ce qui se passe si Job A est suivi de Job B, luimême suivi de Job C, où chaque job traite le fichier X et est le seul job présent dans le système ? La fermeture de fichier de Job A a lieu avant que Job B ne démarre, et ainsi de suite. Vous pourriez exécuter chaque job dans un environnement de test pour voir s’il peut être traité dans un certain laps de temps. L’opération peut durer plus longtemps quand tout le flux du job est rassemblé et exécuté avec un jeu complet de données et de mémoire disponible. L’une des premières choses à vérifier est la possibilité d’un scénario last updaterclose.

Le correctif suivant a été utilisé dans des flux de job batch et a réduit de plus de 50 % le temps d’exécution, en évitant le last updater-close. Ce n’est certes pas la solution élégante, mais elle marche.

Pour éviter les écueils du scénario last updater-close, je vous conseille de dire au système que, même si un job ferme le fichier, il y a un autre job dans le système qui a le fichier ouvert pour la mise à jour, et par conséquent un forçage de fichier n’est pas nécessaire à cette fermeture. Pour cela, démarrez un job d’application fictif ayant un programme qui ouvre le fichier pour la mise à jour et lit et met à jour un enregistrement dans le fichier. Il ne suffit pas d’ouvrir le fichier. Les fonctions base de données exigent qu’au moins une écriture soit effectuée dans le fichier. Après avoir ouvert le fichier et réécrit un enregistrement, le programme met le job dans un état d’attente de temporisation jusqu’à ce que le flux du job de production se termine. Ensuite, le programme utilise CL pour trouver et annuler le job fictif, lequel est implicitement réveillé et le système ferme les fichiers ouverts. Avant d’annuler le job fictif, vous devez exécuter un close explicite dans le dernier job de production.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010