arrivées qui se trouvent en mémoire et les transfère sur disque.
Ensemble, elles se comportent comme une équipe de football bien entraînée, passant le bloc de journal d’un joueur à un autre, jusqu’à ce qu’il atteigne en bon état la surface du disque sur la machine cible.

Si le bon package d’analyse de performance est installé, vous pouvez émettre WRKSYSACT (Work with System Activity) pour avoir un aperçu de l’activité générée par de telles tâches SLIC et pour avoir une idée de l’overhead qu’elles ajoutent à votre machine. En général, elles ne consomment qu’une modeste quantité de CPU.

Comme le support du transport du journal à distance est concentré sur la réplication des nouvelles images de lignes base de données, aussi rapidement que le matériel le permettra de la machine source à la cible, et parce qu’il s’agit d’un transfert de mémoire à mémoire, une question fréquente vient à l’esprit, « Mais qu’en est-il des voyages vers le disque ? »
Et bien, dans le processus du journal à distance, le job à l’écoute du côté cible (c’est souvent une application Business Partner haute disponibilité) n’est avisé de l’arrivée des nouvelles entrées du journal sur le journal à distance qu’une fois que ces images ont déjà été écrites correctement sur disque et sont donc pérennes. Alors seulement les instances des entrées du journal deviennent visibles. Et, bien sûr, ni la machine source ni vos applications fonctionnant sur le côté source ne doivent attendre que cette étape se déroule.
C’est une partie de ce qui rend généralement ce mécanisme de transport si rapide. La vitesse explique aussi pourquoi la tâche de forçage à distance est séparée de la tâche de réception à distance. Comme une seule tâche n’est pas chargée des deux missions, l’étape d’écriture sur disque n’a pas à retarder l’étape de transport.