Journal IBM i, toutes les réponses

Q2 = C : Cette technique se justifiait quand les lecteurs de disques étaient moins fiables et que les sites voulaient avoir deux copies de leurs récepteurs de journaux (souvent résidant dans des pools de stockage auxiliaire (auxiliary storage pools—ASP)) séparés sur la même machine. La création de jumeaux n’est plus pratiquée. A l’heure actuelle, la meilleure méthode consiste souvent à utiliser un journal à distance pour créer une copie de votre récepteur de journaux sur une machine séparée.

Q3 = B : Il n’est vraiment pas nécessaire de passer à la release 6.1 pour mêler des types d’objets multiples et leurs entrées de journaux associées dans le même journal et le même récepteur de journaux. Tous ces objets journalisés peuvent partager le même journal. En fait, si les objets contiennent des données de même nature, il vaut mieux les enregistrer dans le même journal. La présence ou l’absence de contrôle d’engagement n’ajoute aucune restriction à cette stratégie très accommodante. 

Q4 = A : L’IBM i utilise la journalisation write-ahead. Par conséquent, le système d’exploitation garde volontairement l’image de la ligne de la base de données résidente en mémoire principale jusqu’à ce que l’entrée de journal correspondante ait été écrite. Ainsi, dans l’éventualité d’un crash, vous pourrez toujours vous fier au contenu du récepteur de journaux. Ce contenu ne revient jamais au niveau précédent par rapport au contenu du fichier physique. Il s’ensuit que, pendant la phase de reprise de correction du journal d’un IPL anormal qui suit, les éventuelles lignes absentes du PF sont extraites et réactivées à partir du récepteur de journaux.

Q5 = C : Chaque journal impose une limite supérieure quant au nombre de numéros de séquence du journal qu’il attribuera aux entrées qui y résident. Cette limite est influencée par la valeur particulière que vous choisissez pour Receiver Size Option (RCVSZOPT) sur la commande Change Journal (CHGJRN). Le paramètre RCVSIZOPT (*MAXOPT3) permet le plus haut plafond. En sélectionnant ainsi un plafond élevé, vous aurez rarement besoin de marquer une pause pour procéder à la redéfinition de vos numéros de séquence. Par conséquent, le paramètre *MAXOPT3 est probablement le meilleur choix pour la plupart des sites. Bien que les numéros de séquence puissent être redéfinis pour redémarrer à 1, de telles actions ne sont pas automatiques. En effet, il faut une requête CHGJRN explicite avec un mot-clé SEQOPT(*RESET) correspondant pour accomplir cela.

Q6 = A : Le support du journal regroupe les deux images BEFORE et AFTER en mémoire principale, leur attribue des numéros de séquence de journal consécutifs, et écrit la paire conjointement sur disque. C’est mieux que de les écrire individuellement. Cependant, ce sont des entrées de journal distinctes. Il existe certains logiciels tiers et certaines techniques d’analyse d’entrées du journal qui bénéficient de la certitude que les images BEFORE et AFTER sont dos à dos comme entrées de journal consécutives.

Q7 = B : Vous trouverez cet outil séparé sur le site web IBM. L’outil est utile pendant les phases de planification, quand on envisage de fournir le support du journal à un nouvel ensemble de fichiers. Il est particulièrement intéressant pour les sites qui prévoient le support du journal à distance, parce qu’il aide à estimer non seulement le trafic disque local, mais aussi le trafic de la ligne de communication du journal à distance : ces deux trafics ayant augmenté. Cette estimation vous aidera à dimensionner correctement votre bande passante de communication.

Q8 = C : De telles entrées cachées sont généralement présentes pour deux raisons : pour assurer la bonne présentation et le bon formatage quand des images de lignes base de données contenant des tampons horodateurs ou des dates sont présentes, ou pour supporter les étapes de reprise du système d’exploitation. La grande majorité sont généralement présentes pour le compte de la journalisation des fichiers logiques indexés de la base de données (aussi appelé « chemin d’accès »), et les entrées de journal résultantes contiennent des images BEFORE des pages d’index. De telles images sont capturées en hexadécimal interne brut et, par conséquent, leur affichage serait sans intérêt pour l’oeil humain.
Une telle protection journal pour les chemins d’accès est souvent implicite et ne résulte pas de votre action. Cacher à la vue ces entrées internes (situation par défaut) évite de montrer des choses incohérentes et sans intérêt. Les entrées de journal correspondantes sont bien sûr présentes et vous pouvez d’ailleurs voir les numéros de séquence correspondants si vous utilisez le paramètre Include Hidden Entries INCHIDENT(*YES) sur la commande DSPJRN. Par leur présence, de telles entrées cachées accélèrent la reprise IPL anormale, en assurant que les chemins d’accès protégés n’auront pas à être entièrement reconstruits.

Q9 = C : Plus votre seuil de journal (mot-clé THRESHOLD sur la commande Create Journal Receiver—CRTJRNRCV) est haut, et plus grande est la croissance de votre récepteur de journaux attendue par le système d’exploitation. La règle est la suivante : pour chaque 64 Mo d’augmentation du seuil, il faut une unité de disques supplémentaire. Comme le système d’exploitation effectue des écritures sur disque simultanées, le fait d’avoir un seuil de journal plus haut augmente aussi votre bande passante disque efficace, ce qui sera très utile si vous avez tendance à générer beaucoup d’entrées de journal en rafales. Cependant, comme chaque unité de disque supplémentaire ajoute du travail administratif, le système d’exploitation limite généralement à 100 les unités de disques gérées simultanément pour un seul récepteur de journaux, quelle que soit la hauteur de votre seuil.

Q10 = C : L’offre de protection du journal via STRJRNAP garantit que les étapes de reprise d’un IPL anormal se produisent plus rapidement. Pour cela, la phase IPL doit trouver et traiter le journal approprié. Quand il y a plus d’un journal à consulter, cette dualité crée une personnalité divisée pour le fichier logique, ce qui le rend inéligible à toute forme de protection du chemin d’accès. Par conséquent, le fait que les fichiers physiques sous-jacents soient déjà journalisés mais soient en désaccord sur le journal à utiliser, est rédhibitoire. Un tel fichier logique indexé multiformat ne peut être protégé par journal que si tous les fichiers physiques sous-jacents s’accordent sur le journal à utiliser. Quand une personnalité divisée est présente, même SMAPP ne protégera pas un tel chemin d’accès. Si vous avez ce genre de chemin, votre meilleure initiative (outre le fait de vous assurer que les deux PF parlent au même journal) est de donner au moins à SMAPP un peu d’aisance en utilisant le paramètre Include only Eligible Access Paths INCACCPTH(*ELIGIBLE) sur la commande Edit Recovery Access Paths (EDTRCYAP). En procédant ainsi, vous aurez la certitude que votre système ne gaspille pas des ressources en essayant de compenser la nature inéligible de ces fichiers logiques indexés multiformats en s’obstinant à protéger de plus petits chemins d’accès via une journalisation implicite obstinée.

Q11 = B : L’utilisation du paramètre Remove Internal Entries *RMVINTENT sur le mot-clé RCVSIZOPT de la commande CHGJRN établit deux zones sous-jacentes sur disque au-dessous d’un récepteur de journaux. Les entrées internes cachées (c’est-à-dire celles que le côté cible ne pourrait pas et ne voudrait pas utiliser) s’écoulent dans la zone transitoire. Cette zone n’est explorée qu’au moment de l’IPL et par conséquent n’est utile que sur le système source. Par conséquent, les récepteurs de journaux du côté source qui emploient l’attribut *RMVINTENT évitent d’envoyer ces images cachées au côté cible. Cette façon de faire permet souvent de réduire substantiellement le trafic sur la ligne de communication du journal à distance, particulièrement là où beaucoup de nouvelles lignes sont ajoutées à un fichier physique sur lequel des dizaines de fichiers logiques indexés sont construits. Dans certains cas, la réduction peut dépasser 50 % du trafic total du journal à distance. C’est pourquoi la plupart des utilisateurs de journaux à distance devraient activer le paramètre *RMVINTENT.

Q12 = C : Au risque de vous étonner, sachez que le support du journal à distance s’assure simplement que l’instance éloignée de la nouvelle entrée du journal a atteint la mémoire principale (pas la surface du disque) du côté cible avant d’autoriser la poursuite de l’application qui s’exécute du côté source. L’application écrit alors l’entrée du journal original sur le disque du côté source. Rien ne contrôle l’ordre d’arrivée sur le disque entre les deux systèmes. Le mode SYNC n’assure qu’une chose : qu’une copie (une copie en mémoire principale pas une copie sur disque) de l’entrée du journal atteint le côté cible avant qu’une écriture sur disque du côté source similaire s’ensuive. C’est ce transfert de mémoire à mémoire des entrées du journal que votre application attend. Faire attendre votre application côté source pour l’écriture sur disque, plus lente du côté cible, ralentirait beaucoup plus la performance et serait inutile, parce que les entrées du journal existent désormais sur les deux systèmes.

Q13 = B : Le système d’exploitation ne fournit pas de redémarrage automatique. Mais il existe un mécanisme de détection de corruption de données bien amélioré (quoique facultatif). Il se présente sous la forme d’un nouveau mot-clé Validation Check (VLDCHK) sur la commande Change Remote Journal (CHGRMTJRN). Pour pouvoir configurer ce niveau supplémentaire de détection de données brouillées sur le journal à distance, vous devez utiliser la release 6.1. Si vos lignes TCP/IP sont très ordinaires, choisissez donc cette configuration.

Q14 = C : Vous êtes sûrement tenté par la réponse A. Je le comprends parfaitement. Après tout, comme de nouvelles entrées du journal apparaissent souvent pour supporter de nouvelles fonctions du système d’exploitation, et comme les journaux eux-mêmes adoptent souvent de nouveaux comportements et propriétés à l’arrivée d’une nouvelle version, à quoi servirait d’avoir un système source plus intelligent que la cible. Ce serait admettre que le système source pourrait envoyer n’importe quoi au système cible. C’est pourquoi il y a un handshake (passage de témoin) en coulisses entre le système source et cible quand vous exécutez la commande CHGRMTJRN. C’est pendant ce handshaking que chaque côté admet ce qu’il peut traiter. S’il s’avère que le journal du côté source utilise des fonctions avancées que le côté cible n’est pas encore capable d’interpréter et d’honorer, le handshake du journal à distance échoue et la connexion du journal distance reste inactive. Donc, à l’évidence, il est bon que le côté cible soit plus moderne que le côté source. Cependant, ce n’est pas la règle proprement dite qui est examinée et imposée par le système d’exploitation. Au lieu de cela, les attributs particuliers du journal du côté source et de son récepteur de journaux correspondant sont comparés aux possibilités du système cible. Autrement dit, même si le côté source est monté d’un cran en utilisant une nouvelle version du système d’exploitation, pourvu que le journal local emploie encore uniquement les attributs supportés sur la version précédente, le handshake fonctionne. On le voit, ce n’est pas la version du système d’exploitation qui importe, mais plutôt les fonctions du journal qui sont employées.