Profond, très profond, dans le microcode

et préparé pour être écrit sur le disque local de la machine de production, un transport simultané sur la mémoire principale de la machine cible est planifié par le support du journal à distance asynchrone sous-jacent.

En orchestrant cette réplication d’images d’entrées de journal à une telle profondeur dans la machine, i5/OS peut souvent s’avérer très efficace. Et c’est précisément ce qu’ont reconnu les clients qui ont utilisé le support de journal à distance. Beaucoup d’utilisateurs du journal à distance indiquent régulièrement que les images atteignent la machine cible avec plus d’exactitude que par toute technologie précédente.

Et les fichiers base de données et les tables SQL ne sont pas les seuls à bénéficier de cette belle tuyauterie. Tout objet dont les changements récents sont confiés au journal local sur la machine de production peut compter sur le support du journal à distance sous-jacent pour voir ses changements transportés vers le côté cible. Une fois que les images du journal arrivent côté cible et résident dans le récepteur du journal à distance, il suffit d’employer le logiciel de votre choix pour récolter et retraiter les données.

Certains sites accomplissent cette étape de retraitement grâce à un package Business Partner haute disponibilité.
D’autres préfèrent écrire leur propre support de récolte et de traitement ou émettre périodiquement une commande Apply Journal Change (APYJRNCHG) ou APYJRNCHGx. En fait, i5/OS a récemment introduit l’API QDBRPLAY dans le but précis de rendre de telles opérations de retraitement moins chères quand il s’agit de répliquer des opérations de base de données complexes. QDBRPLAY permet aux deux packages – de récolte et retraitement maison et commercial haute disponibilité – de se lier au même support construit pour APYJRNCHG.

Il est vrai que de tels changements peuvent être envoyés entre les deux machines en mode synchrone ou en mode asynchrone. En mode synchrone, le job d’application sur la machine de production attend confirmation de l’arrivée dans la mémoire principale de la machine cible ; tandis qu’en mode asynchrone, l’acte de transmission des images du journal est sous-traité à une tâche SLIC esclave s’exécutant sur la machine de production. La plupart des clients préfèrent l’asynchrone et presque tous signalent que les images du journal sont généralement sur la liaison en route vers le côté cible en une fraction de seconde.