Ne jetez rien à la poubelle

Vous devinez la différence : mes parents adoptaient une approche minimaliste, c’est-à-dire ne prenaient que le strict nécessaire à leurs yeux, tandis que mon oncle et ma tante emportaient le maximum, « au cas où ».

Avant la release 7.1, on pourrait dire que le mécanisme de transport des journaux à distance avait, comme ma tante, une tendance à la surcharge. Si une entrée du journal visible apparaissait côté source, elle était envoyée au côté cible, sans aucune interrogation. Rien de tel avec la version 7.1. Si vous savez que votre fournisseur HA n’est pas intéressé par un certain genre d’entrée de journal ou si des changements journalisés à partir d’un objet particulier assurent la protection du côté source, nul besoin de consommer des cycles de CPU ou de la bande passante TCP/IP pour envoyer des choses inutiles. Vous pouvez ordonner au système d’exploitation d’omettre de telles entrées de journaux. Elles continuent à apparaître côté source, mais ne font pas le voyage vers le côté cible.

Les images « avant » du journal constituent une catégorie importante de telles entrées, particulièrement pour les utilisateurs de SQL. Ce sont les entrées de journaux qui permettent aux transactions SQL de revenir sur les tentatives de changements. Elles sont très utiles du côté source pendant qu’une transaction SQL se déroule, mais la plupart des produits HA les jugent inutiles du côté cible et ne souhaitent pas que vous les y envoyiez. A partir de la 7.1, vous n’aurez plus à le faire !

Pour bénéficier de cette nouvelle possibilité de la 7.1, vous pourriez émettre une commande comme celle-ci :

CHGRMTJRN RDB(NEWYORK)
    SRCJRN(LCLLIB/JOURNAL1)
    TGTJRN(RMTLIB/JOURNAL1) JRNSTATE(*ACTIVE)
    DELIVERY(*ASYNC) FTRIMAGES(*BEFORE)

Notez le mot-clé final : FTRIMAGES. C’est le paramètre Filter Images. Il ordonne au mécanisme de transport du journal à distance sous-jacent du côté source de bloquer par filtrage les images « avant ». Autrement dit, elles ne doivent pas emprunter la liaison et, par conséquent, n’apparaîtront pas du côté cible.

Quand il y a beaucoup d’images « avant », un tel choix allègera considérablement vos lignes de communication TCP/IP qui ne transporteront que l’essentiel. Non seulement vos paquets de communication seront remplis plus efficacement, mais le logiciel de collecte côté cible et le logiciel replay HA auront moins de données inutiles à passer au crible. Tout le monde est gagnant.

En fait, cette nouvelle façon de faire est tellement intéressante pour améliorer l’efficacité de la journalisation à distance, qu’IBM demande d’installer l’accélérateur de performance de journal (aussi connu sous le nom « Option 42 HA Journal Performance » pour l’OS). C’est la même fonction d’accélérateur de journal que beaucoup d’utilisateurs de journaux à distance ont déjà mise en place pour bénéficier du mot-clé Journal Caching (JRNCACHE) pour la commande Change Journal (CHGJRN). On le voit, cet accélérateur de journal facultatif présente un double intérêt : il vous permet de construire des blocs de journaux plus efficaces du côté source pour améliorer l’efficacité, et il permet d’envoyer des paquets plus sélectifs vers le côté cible. La plupart des utilisateurs de journaux qui envisagent une forte activité de journalisation doivent songer sérieusement à installer cette option.