Performances du journal à  distance

Si le lien du journal à distance prend du retard, nous pouvons soit diminuer la quantité de données envoyées, soit augmenter la taille de la ligne de communication.

On peut réduire de plusieurs manières la quantité de données à l’intérieur d’un récepteur de journal. Tout d’abord, analysons l’environnement de journalisation. Peut-être avons-nous plusieurs bibliothèques, toutes associées au même journal, alors que notre journal à distance n’a besoin que de quelques-unes. Si tel est le cas, divisez le journal en deux et n’envoyez que la première partie au système à distance.
Nous pouvons réduire le nombre d’entrées du journal en ne journalisant que les images après au lieu des images avant et après, ou en omettant les entrées d’ouverture et de fermeture pour les fichiers.

Nous pouvons aussi diminuer la taille de chaque entrée du journal en réduisant l’information capturée dans l’en-tête de chaque entrée. Souvent, quand nous mettons un jour une ligne, nous ne changeons qu’un ou deux champs de tout l’enregistrement. Par défaut, tout l’enregistrement est journalisé. Cela consomme beaucoup de place pour rien puisque la plus grande partie de l’enregistrement n’a pas changé. Nous pouvons atténuer cela par un concept appelé « minimized entry-specific data ».

Il y a aussi des entrées internes qui peuvent être stockées dans une partie spéciale du journal. Pour permettre le déplacement des entrées internes dans un espace où elles ne seront pas envoyées à un journal à distance, nous utiliserons l’option Remove Internal Entries (RMVINTENT) sur le journal. Ces plans d’amaigrissement du journal sont couverts en détail dans les « Journal TechNotes ».

Après avoir réduit au maximum les récepteurs de journaux, nous pouvons nous tourner vers la ligne de communication. Pour prévoir sa taille, nous devons tenir compte de celle des récepteurs de journaux à envoyer, de la charge supplémentaire que représentent les en-têtes TCP et IP, et de tout autre trafic sur la même ligne. Rappelons que les données envoyées sur TCP/IP sont en paquets, d’environ 1400 octets. Chaque paquet un en-tête IP de 20 octets et un second en-tête TCP de 20 octets. À eux seuls, ces en-têtes ajoutent presque 3 % de trafic.

Compte tenu de cela et d’autres considérations de ligne, le débit réel représente environ 75 % du débit théorique de la ligne. Si vous craignez avoir un problème, vous trouverez dans le System i Knowledge Base Document 396656252 d’IBM, une méthodologie pour suivre votre usage des journaux et des lignes.

Une pierre angulaire technologique

Les informations de base présentées ici vous permettront de choisir la bonne méthode pour établir votre journalisation à distance. Mais ne perdez jamais de vue qu’un journal à distance déplace simplement les récepteurs de journaux du système source vers le système cible. Le moment est venu de confier ces journaux à distance à votre logiciel HA pour parachever votre environnement.

Suite du Dossier :

Ajouter un journal à  distance · iTPro.fr