Mode CDC Redo log
Le mode Redo/Archive log est uniquement disponible pour les bases de données AS/400 et Oracle Enterprise 11 ou précédent, respectivement. C'est l'équivalent du mode archive log d'Oracle et du mode journal d'AS/400.
Dans une base de données Oracle, un fichier Redo log est un fichier journal historisant les changements apportés à cette base. Dans l'environnement AS/400, les changements sont automatiquement historisés dans le journal interne à la base de données AS/400. Ces changements correspondent aux opérations d'insertion, de mise à jour et de suppression effectuées sur les données.
Le mode Redo/Archive log sont moins intrusifs que le mode Trigger, car, contrairement au mode Trigger, il ne nécessite pas de modifications dans la structure de la base de données.
Avec le mode Redo/Archive log d'Oracle, un seul souscripteur peut avoir accès à la table des changements et ce souscripteur est un utilisateur ou une utilisatrice de la base de données ayant les droits de souscription. Ce souscripteur est un utilisateur ou une utilisatrice de la base de données ayant les droits de souscription. De plus, la table de souscription, contrôlant l'accès aux données des tables des changements au souscripteur. La table des changements de souscription est une table interne globale à l'instance de la base de données Oracle créée lors de l'activation de l'option Redo/Archive log dans la base de données Oracle.
Lors de la mise en place de ce mode dans AS/400, un fichier savf appelé fitcdc.savf et fourni dans votre Studio est restauré dans l'AS/400 et utilisé pour installer un programme appelé RUNCDC. Lorsque le souscripteur va prévisualiser (View all changes) ou consommer (à l'aide du composant tAS400CDC) ces changements afin de les réutiliser, le programme RUNCDC va lire et analyser ce journal et le récepteur attaché depuis la table source et mettre à jour la table des changements en conséquence. Le mode CDC Redo/Archive log (journal) d'AS/400 crée des tables de souscription pour contrôler l'accès aux données des tables des changements par le·s système·s cible·s. Un système cible peut correspondre à n'importe quelle application souhaitant utiliser les données capturées du système source.
Dans cet exemple, le CDC surveille les changements effectués sur une table Produit grâce aux données de log contenues dans les fichiers journaux de la base de données. Le CDC lit ces journaux et capture les changements apportés aux données. Ces deltas sont récupérés et publiés dans la table des changements, et deux souscripteurs, une application CRM et une application Accounting, ont accès à ces données. Ces deux systèmes cible récupèrent les deltas et les utilisent pour mettre à jour leurs données.