Mettez votre journal à  distance au régime

L’une des approches les plus efficaces est aussi l’une des plus faciles à appliquer. Elle consiste à placer une bifurcation sur la route et à accorder au journal votre permission pour orchestrer deux écritures disque sur la machine source, au lieu d’une. Les moutons vers la droite, les chèvres vers la gauche. En effet, le journal contient deux sortes d’entrées : celles que vous voulez voir normalement et celles qui sont normalement cachées. La figure 1 illustre ce principe.

Pour les besoins de cet exemple, nous imaginerons deux instances communes d’entrées de journal qui ont tendance à apparaître dans vos récepteurs de journaux: celles qui sont présentes pour ajouter de nouveaux enregistrements à un fichier physique (comme le PT = PUT dans la figure 1) et celles qui sont normalement cachées mais présentes pour le compte des changements du chemin d’accès (par exemple, les fichiers logiques indexés), comme l’AP de la figure 1.

Les entrées de journal visibles traditionnelles sont vos anciennes favorites (R/PT pour un put base de données, R/DL pour un delete base de données). Les entrées cachées sont là uniquement pour aider le système d’exploitation du côté source à récupérer les propriétés statistiques de vos fichiers et récupérer plus rapidement vos chemins d’accès (des moutures comme I/IV, que vous ne pouvez visualiser qu’en ajoutant le paramètre INCHIDENT à la commande DSPLRN). A noter que de telles entrées cachées, bien qu’elles ne soient visibles que si vous faites l’effort de les amener à la surface, n’en sont pas moins là et consomment de l’espace sur le système source.

Les entrées de journal cachées ont certes un rôle important, mais il n’est approprié que sur la machine de production/source. Elles n’entrent en jeu qu’au moment de l’IPL et elles ne bénéficient qu’à l’exhaustivité IPL de la machine source. Cette observation étant faite, on en conclut facilement qu’elles doivent être les chèvres et que la machine cible (et tout logiciel fonctionnant sur cette extrémité du fil de communication, comme votre logiciel de replay haute disponibilité) n’a que faire de telles entrées de journal et vous serait très reconnaissant de ne pas les envoyer. Vous pouvez créer une bifurcation sur la route de cet objectif (en filtrant les entrées cachées) en émettant simplement une commande CHGJRN sur le source, et en spécifiant RCVSIZOPT(*RMNINTENT). C’est aussi simple que cela.

Après quoi, seuls les moutons (les entrées de journal visibles et utiles, nécessaires et appréciées par le côté cible) s’écouleront. Les chèvres seront poussées de côté sur des surfaces disque séparées côté source et ne seront appelées que si un IPL anormal du source survient. Le trafic de communication résultant empruntant le fil sera réduit – souvent spectaculairement.

Voulez-vous avoir une idée de la quantité de gras que vous pourriez ainsi éliminer ? Il suffit d’une opération en deux étapes. Premièrement, affichez le contenu de votre jeu de récepteurs de journaux avec une commande DSP JRN, en spécifiant INCHIDENT afin que les entrées de journal normalement cachées apparaissent. Dirigez les résultats vers un fichier de sortie.

Deuxièmement, interrogez le fichier de sortie résultant, en additionnant les longueurs des entrées de journal qui seraient normalement cachées. Ces entrées sont reconnaissables à leur JOCODE: « I ». La requête résultante ressemblerait à ceci :

 Select sum(JOENTL) from LIB/OUTFILE where JOCODE = ‘I’

A la réflexion, certains lecteurs craignent peut-être que, une fois la bifurcation en place, ils doivent émettre deux écritures disque au lieu d’une. Pas de panique ! Les deux écritures sur le côté source se chevauchent et sont effectuées en même temps sur des unités de disque séparées. Les moutons et les chèvres sont dirigés simultanément vers leurs granges respectives. Comme conséquence, seules les entrées de journal visibles se retrouvent sur le fil de communication et voyagent jusqu’à l’autre côté.

Le résultat est évident : mois de gras sur le fil et moins d’octets à traiter sur la cible, généralement sans augmentation notable du temps de réponse côté source.