IBMi, Avez-vous placé la barre trop haut pour votre journal ?

L’objectif est clair : s’assurer que la plupart des chemins d’accès n’auront pas à être reconstruits après une grave panne machine.

Cependant, dans le but de réduire une durée IPL anormale, certains sites ont dépassé le paramétrage par défaut et sont devenus gourmands. Ils ont alors utilisé la commande Edit Recovery for Access Paths (EDTRCYAP) pour réduire la durée de reprise IPL. Dans un environnement HA, cet objectif de reprise plus ambitieux peut entraîner des excès et du gaspillage du côté source, particulièrement si les petits chemins d’accès sont nombreux. Il en est ainsi parce que, en coulisses, le temps de reprise global demandé (par exemple, 20 minutes) est converti en une allocation de durée de reprise par index. Si, par exemple, nous prévoyons cinq petits index ouverts et susceptibles d’être reconstruits, le système d’exploitation fixe une sorte de barre interne à une hauteur de quatre minutes (5 x 4 minutes est inférieur ou égal à notre objectif de 20 minutes).

IBMi, Avez-vous placé la barre trop haut pour votre journal ?

En s’exécutant, vos applications ouvrent et ferment des fichiers. Elles ajoutent et suppriment des lignes. Pendant toute cette activité, les index reçoivent ou perdent des clés. Et c’est précisément cette arrivée ou ce départ de clés qui mettent en danger le chemin d’accès environnant. Au moment où un chemin d’accès entre dans cette zone de risque, le système d’exploitation demande :  « quelle est donc votre taille ? » la réponse vient sous la forme d’un temps estimé nécessaire pour reconstruire l’index en cas de crash machine.

Les index dont le temps de reconstruction estimé est inférieur à celui de la barre (4 minutes dans notre exemple) sont autorisés à continuer sans subir le fardeau de la journalisation cachée, mais les index plus grands ne sont pas autorisés à continuer. Cette séparation du bon grain de l’ivraie aide le système d’exploitation à choisir quels chemins d’accès il doit journaliser. Si sa supposition est exacte, l’objectif de durée de reprise de 20 minutes est atteint.

En revanche, si le système d’exploitation règle la barre à la mauvaise hauteur, c’est raté. Au fur et à mesure, le système d’exploitation apprend votre profil et réajuste le paramétrage de la barre pour se rapprocher de l’objectif fixé.

Comme il y a un overhead par chemin d’accès associé à l’activation de la protection par journal, auquel s’ajoute un overhead par clé associé à la journalisation des changements, plus la barre est basse, et plus il y a d’overhead. Si le système d’exploitation est obligé de placer la barre très bas, vous en tirerez peu d’avantages. Il travaille très dur (en consommant votre CPU et disque) pendant les dernières minutes du temps de reprise.

L’équipe de développement du journal IBM a vu certains sites où l’objectif de reprise est fixé tellement bas et où il y a tant de petits index exposés, que cela revient à « faire bouillir l’océan. » En fait, presque chaque index en vue inonde le journal d’activité. Pour savoir si vous êtes en train de « faire bouillir l’océan, » vous pouvez afficher les nouveaux écrans 6.1 qui vous dévoilent l’intérieur de la machine pour voir quels chemins d’accès sont protégés (voir le « V6R1 Journal Recovery Enhancements, Part 2 »).

Un choix plus judicieux, particulièrement pour les sites qui ont une machine cible HA active attendant de prendre le relais, consiste à hausser la barre du côté source. Autrement dit, laissez au côté source un tout petit peu plus de temps de reprise si cela permet d’améliorer la performance globale des applications.