IBMi, Envoyez-vous des paquets chétifs par la ligne de communication vers la machine cible ?

C’est excellent pour assurer la survie, mais très cher en performance. Dans un environnement de réplication logique HA par journal à distance, les inconvénients s’accumulent : taille maigrelette des paquets de communications, lots (bundles) de journaux minuscules, et charge supplémentaire du système pour réveiller sans cesse le logiciel de replay HA chaque fois qu’un nouveau paquet arrive.

IBMi, Envoyez-vous des paquets chétifs par la ligne de communication vers la machine cible ?

Souvent, il est préférable d’utiliser d’emblée un lot de journaux plus large. Ces tailles de lot plus larges sont obtenues en appliquant le paramètre JRNCACHE(*YES) à la commande Change Journal (CHGJRN), parce que la mise en cache permet à plusieurs entrées de journal de s’unir pour un seul voyage vers le disque. Pourtant, beaucoup de sites qui disposent d’un produit HA, ont rechigné à faire cela du côté source. Leur crainte (souvent renforcée par leur fournisseur HA) a été que le temps supplémentaire nécessaire pour remplir un lot plus large côté source, risque de réduire sensiblement l’intérêt du transport vers le côté cible.

Si de telles craintes étaient fondées avant la release 6.1 (voir l’IBM TechNote Journal Caching: Understanding the Risk of Data Loss) elles ne le sont plus depuis la présence du nouveau paramètre CACHEWAIT sur la commande Change Journal Attributes (CHGJRNA). Vous pouvez avoir le beurre et l’argent du beurre : de belles tailles de lots/paquets, optimisées pour le transport, sans sacrifier le degré d’opportunité souhaité. Vous pouvez en lire plus sur cette option dans « V6R1 Journal Recovery Enhancements, Part 2. » (July 2008, article ID 61358).

Si vous vous demandez ce que valent vos lots de journaux actuels, c’est facile à déterminer. Affichez simplement le contenu de votre récepteur de journaux dans un fichier de sortie avec la commande Display Journal (DSPJRN), puis utilisez le contenu du fichier de sortie pour discerner la taille de lot moyenne. Le site web IBM a un outil pour effectuer ce calcul. Dans la section « Journal Analysis Utilities », recherchez l’outil nommé « Journal Bundling Analysis Program. »

Règle générale : les lots de journaux dont la moyenne est de 100 Ko ou plus sont efficaces. Ceux qui se trouvent à l’autre extrémité, de quatre Ko ou moins chacun, sont inefficaces. Si vos lots ne sont pas satisfaisants, installez l’option HA Journal Performance, validez journal caching, et appliquez à nouveau l’outil d’analyse pour savoir si votre comportement s’est amélioré.

S’il est encore insatisfaisant, il vous faudra creuser davantage. Il existe aussi certaines pratiques antiques (par exemple fermer vos fichiers fréquemment et/ou employer un ratio d’écriture forcée dans la base de données de 1) qui peut aussi vider le buffer bien avant qu’il n’atteigne la taille optimale. Si vous pâtissez encore d’un tel comportement, il est peut-être temps de confesser ces péchés et de chercher une meilleure méthode.