Moins journaliser tout en atteignant les objectifs

En premier lieu, il faut éviter de journaliser les fichiers et les objets qui n’ont pas à l’être.

Par exemple, Vriezen nous dit que la journalisation de fichiers temporaires pertinents pour une seule application active est inutile pour la reprise, la reconstitution, l’audit, ou même la haute disponibilité (HA). Qui plus est, si vous utilisez la journalisation principalement pour la HA, le fichier temporaire sera probablement effacé quand vous lancerez l’application sur le système de secours, après l’indisponibilité du système principal. Donc, la journalisation de ces fichiers temporaires est superflue pour la HA.

Si vous utilisez la journalisation pour faciliter la reprise et l’audit, mais pas la HA, il se peut que certaines données, comme des transactions issues de documents papier, n’aient pas à être journalisées puisqu’elles existent sous forme imprimée. Cependant, avant d’exclure ces fichiers du journal, assurez-vous que les avantages de la non-journalisation l’emportent sur ceux auxquels vous renoncez.

Pour prendre une décision éclairée sur les objets à ne pas journaliser, il vous faut deux types d’informations : les avantages de la journalisation et leur coût. Le mérite de chaque avantage dépend beaucoup de votre environnement et, par conséquent, n’entre pas dans le cadre de cet article. Déterminer le coût de la journalisation est une question plus générique et il existe un outil, le IBM Pseudo Journal Tool, qui peut vous y aider.

Les outils d’évaluation

Pour utiliser le Pseudo Journal Tool vous devez d’abord préciser quels fichiers vous souhaitez journaliser. À ce moment-là, sans activer la journalisation, l’outil surveille toute activité concernant ces fichiers, qui aurait créé des entrées de journal si la journalisation avait été activée. Vous pouvez examiner les résumés de cette activité pour déterminer l’impact de la journalisation sur vos systèmes et sur vos besoins de stockage. Vous pouvez utiliser le Pseudo Journal Tool pour évaluer non seulement le volume mais aussi le rythme des écritures d’entrée de journal potentielles, pour déterminer si le cache du journal (voir ci-dessous) sera suffisant dans votre cas.

Limiter le nombre d’objets à journaliser peut être la première idée qui vient à l’esprit. Mais journaliser moins ne signifie pas forcément journaliser moins d’éléments. La fonction minimized journal entry (MINENTDTA) de l’IBM i réduit le volume de données stockées dans le journal, par des techniques de hashing et en ne capturant que les champs modifiés plutôt que l’enregistrement tout entier. La taille de l’information d’en-tête nécessaire pour pratiquer les minimized journal entries dépasse parfois la quantité de compression d’entrée du journal, mais l’IBM i est assez avisé pour ne pas « minimiser » les entrées du journal dans ces cas.

Par le passé, la fonction minimized journal entry posait souvent un problème, parce que les auditeurs tenaient absolument à lire les entrées du journal. Or les entrées minimisées étaient indéchiffrables. Cette situation a changé avec l’introduction en V5R4 de Auditable Journal Minimal Data – MINENTDTA (*FLDBDY) au lieu de MINENTDTA (*FILE), qui crée des minimized journal entries intelligibles pour les auditeurs.

On peut aussi réduire la quantité de données écrites dans le journal en évitant d’écrire des images-avant et compter plutôt sur les images-après que le journal capture pour chaque changement. Cela n’est probablement pas gênant dans la plupart des sites, parce que le journal ne capture des images-avant que si on le lui demande. Mais il se peut qu’un administrateur système précédent ait activé inutilement cette option sans en informer l’administrateur actuel. Donc, il vaut mieux contrôler. Un inconvénient toutefois : les images-avant sont nécessaires si vous utilisez le contrôle d’engagement ou si vous utilisez la journalisation du chemin d’accès.

La journalisation de l’IBM i donne la possibilité de garder un enregistrement de chaque opération d’ouverture et de fermeture de fichier. Généralement, cela n’est nécessaire que pour déboguer une application. Comme chaque entrée de journal alourdit la charge de traitement et augmente le nombre d’I/O disque, il vaut mieux désactiver la journalisation des ouvertures et fermetures de fichiers pendant l’exploitation normale.

Il existe une autre occasion de réduire la quantité de données journalisées : quand on utilise la journalisation à distance pour maintenir un serveur de secours en hot standby, probablement avec l’aide de l’une des solutions IBM HA Business Partner. Certaines entrées de journal sont stockées sur le système de production, principalement dans le but de rétablir l’intégrité structurelle des chemins d’accès indexés lors d’un IPL. L’IBM i place ces entrées de journal, qui n’ont pas d’utilité sur le système de secours, dans un flux de journal « caché ». Vous pouvez alors utiliser l’option RCVSIZOPT (*RMVINTENT) pour n’envoyer que le flux d’entrées de journal « visible » au serveur de secours, afin de réduire le trafic journal qui y est envoyé.