Envoyez-vous des entrées de journaux boursouflées vers le côté cible ?

Cela se manifeste en particulier quand les images de lignes de base de données contenues dans vos entrées de journaux présentent des images de champs interminables représentant des valeurs qui n’ont pas changé. C’est du gaspillage pur et simple.

Envoyez-vous des entrées de journaux boursouflées vers le côté cible ?

Prenons l’exemple suivant : vous gérez une société de transport et vous exécutez un job qui met à jour un champ de suivi chaque fois qu’un colis change de lieu dans son trajet vers le client. Un avion-cargo en provenance de Sydney, Australie, vient d’atterrir à Los Angeles International Airport. Mille colis ont été déchargés et vous êtes sur le point de mettre à jour mille lignes dans votre table de livraison maîtresse, confirmant que chacun de ces colis est à présent en douane. Le seul champ qui est modifié dans chacun de ces enregistrements est le lieu de suivi : pas le numéro du colis, pas l’origine, pas la destination finale, et certainement pas l’identité du client qui a expédié le colis, ni la priorité de ce dernier. Par conséquent, le système cible n’a vraiment pas à connaître des champs qui restent inchangés. Pourtant, si vous n’avez pas validé le paramètre Minimize Entry Data (MINENTDTA) sur votre journal, vous allez non seulement transporter ces champs statiques, mais aussi gaspiller des cycles de CPU du côté cible, parce que votre logiciel HA va reproduire/copier ces champs.

Vous devez donc vous assurer, particulièrement dans un environnement HA de réplication logique de journal à distance que vous avez bien pris en considération la validation du support qui n’enverra que les champs modifiés. Cela peut se faire via CHGJRN MINENTDTA(*FLDBDY). Vous pouvez en lire plus sur cette option dans l’IBM TechNote Journaling: How to View and More Easily Audit Minimized Journal Entries on the IBM System i Platform.