Avant d'ajouter des processus d'extraction et de réplication

Découvrez les configurations prérequises requises avant de créer des processus Extract et Replicat pour un déploiement Oracle GoldenGate.

Ajouter TRANDATA

Valide pour Db2 pour i, Db2 LUW, Db2 z/OS, Oracle, PostgreSQL, SQL Server et Sybase.

Selon la base de données source, la journalisation supplémentaire doit être activée pour capturer les opérations LMD et peut être activée via le menu Trandata d'une connexion de base de données dans l'interface Web ou dans le client Admin en émettant ADD TRANDATA ou ADD SCHEMATRANDATA (pour Oracle uniquement).

L'ajout de TRANDATA n'est pas requis sur une base de données source pour une extraction de chargement initial. Toutefois, si le processus Extract de chargement initial et le processus Extract de capture des données de modification (CDC) sont utilisés conjointement, pour une instanciation en ligne, TRANDATA doit être ajouté avant de démarrer le processus Extract de chargement initial.

Activer TRANDATA ou SCHEMATRANDATA pour Oracle AI Database

Cette opération peut être effectuée au niveau table, schéma ou global (base de données).

Pour activer la journalisation supplémentaire, connectez-vous à la base de données à partir de la page Connexions de base de données, sélectionnez le menu Trandata, puis procédez comme suit :

Sélectionnez l'option Table ou Schema (Table ou Schéma) selon vos besoins et cliquez sur le signe plus pour l'ajouter.
Entrez le nom de la table pour laquelle vous devez configurer la journalisation supplémentaire. Veillez à entrer le nom complet de la table avec le nom du schéma, par exemple HR.EMP. Vous pouvez également utiliser un caractère générique au lieu d'un nom de table spécifique.
Cliquez sur Soumettre.

Vous pouvez ignorer ADD TRANDATA en cas de chargement initial sans CDC.

Vous pouvez également utiliser les commandes ADD TRANDATA et ADD SCHEMATRANDATA pour configurer trandata et trandata au niveau du schéma.

Remarque : avant d'exécuter la commande ADD TRANDATA, vous devez d'abord vous connecter à la base de données dans laquelle l'extraction sera ajoutée à l'aide de la commande DBLOGIN. En outre, exécutez les commandes ADD TRANDATA ou ADD SCHEMATRANDATA avant d'ajouter l'extraction.

Activer TRANDATA pour les bases de données non Oracle

Valide pour Db2 i, Db2 LUW, Db2 z/OS, PostgreSQL, SQL Server et Sybase.

Cette opération peut être effectuée au niveau table ou global (base de données). Pour activer la journalisation supplémentaire, connectez-vous à la base de données à partir de la page Connexions de base de données, sélectionnez le menu Trandata, puis procédez comme suit :

Sélectionnez l'option Table et cliquez sur le signe plus pour l'ajouter.
Entrez le nom de la table pour laquelle vous devez configurer la journalisation supplémentaire. Veillez à entrer le nom complet de la table, par exemple EMPLOYEE. Vous pouvez également utiliser un caractère générique au lieu d'un nom de table spécifique.
Cliquez sur Soumettre.

Procédure d'activation de la capture des modifications pour Db2 pour i

Pour capturer les modifications apportées à une table dans un journal, vous pouvez exécuter la commande STRJRNPF sur la ligne de commande IBM i ou exécuter la commande ADD TRANDATA à partir du client d'administration. La commande ADD TRANDATA appelle STRJRNPF. Cette méthode est recommandée pour démarrer la journalisation des tables, car elle garantit que l'attribut d'image de journal requis ( (IMAGES): *BOTH) est défini sur la commande STRJRNPF.

La commande ADD TRANDATA est la suivante :

ADD TRANDATA table_specification

Où : table_specification représente l'un des éléments suivants :

*schema.table* [JOURNAL *library/journal*]

*library/file* [JOURNAL *library/journal]*)

Définir une écriture par défaut

Afin de spécifier un journal par défaut pour plusieurs tables ou fichiers dans la commande ADD TRANDATA, au lieu de spécifier le mot-clé JOURNAL, utilisez la commande suivante avant d'exécuter ADD TRANDATA.

DEFAULTJOURNAL *library/journal*

Toute commande ADD TRANDATA utilisée sans journal emploie le journal de DEFAULTJOURNAL.

Pour afficher le paramètre en cours de DEFAULTJOURNAL, vous pouvez émettre la commande avec aucun argument.

Suppression d'une spécification de journal par défaut**

Pour enlever l'utilisation d'un journal par défaut, utilisez la commande suivante :

DEFAULTJOURNAL CLEAR

Pour activer la capture des modifications pour Db2 LUW

Configurez Db2 pour consigner les modifications de données au format développé fourni par la fonctionnalité DATA CAPTURE CHANGES des commandes CREATE TABLE et ALTER TABLE. Ce format fournit à Oracle GoldenGate l'ensemble des images avant et après des lignes qui sont modifiées par des instructions de mise à jour. Exécutez la commande ALTER TABLE comme suit :

Lancez la commande suivante.

ADD TRANDATA owner.table

où owner.table est le nom qualifié complet de la table. Vous pouvez utiliser un caractère générique pour indiquer plusieurs noms de table.

ADD TRANDATA exécute la commande suivante, qui inclut la journalisation de l'image "avant" des colonnes LONGVAR :

ALTER TABLE name DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;

Exemple 7-1 pour exclure la journalisation LONGVAR :

Pour omettre la clause INCLUDE LONGVAR COLUMNS de la commande ALTER TABLE, utilisez ADD TRANDATA avec l'option EXCLUDELONG.

ADD TRANDATA *owner.table*, EXCLUDELONG

Remarque : si les colonnes LONGVAR sont exclues de la journalisation, les fonctionnalités d'Oracle GoldenGate qui nécessitent des images antérieures, telles que les paramètres GETUPDATEBEFORES, NOCOMPRESSUPDATES et NOCOMPRESSDELETES, peuvent renvoyer des erreurs si les tables contiennent ces colonnes. Pour obtenir une solution, reportez-vous aux options REQUIRELONGDATACAPTURECHANGES | NOREQUIRELONGDATACAPTURECHANGES du paramètre TRANLOGOPTIONS.

Ajout d'une table de point de reprise

Une table de points de reprise est requise pour toutes les répliques non parallèles et doit être créée dans la base de données avant d'ajouter une réplication. Un point de reprise réussit ou échoue avec la transaction. Le processus Replicat garantit donc qu'une transaction n'est appliquée qu'une seule fois, même en cas d'échec du processus ou de la base de données.

Vous pouvez afficher la table de points de reprise dans la section correspondante. Pour ajouter une table de point de reprise, connectez-vous à la base de données cible à partir de la page Connexions de base de données, sélectionnez Point de reprise, puis procédez comme suit :

Cliquez sur le signe plus pour activer l'ajout d'une table de points de reprise.
Ajouter le nom de la table de points de reprise au format
```
*table*.*checkpoint_table_name*
```
Cliquez sur Soumettre. Une fois le point de reprise créé, vous pouvez le voir dans la liste des tables de point de reprise.

Pour effectuer cette tâche à partir de la ligne de commande, reportez-vous à ADD CHECKPOINTTABLE dans le manuel Référence d'interface de ligne de commande pour Oracle GoldenGate.

Ajout d'une table de points de reprise avec journalisation dans Db2 pour i

Dans Db2 pour la base de données cible i, chaque point de reprise écrit dans la table de points de reprise doit être journalisé dans la transaction de réplication.

Voici une méthode courante de création de la table de points de reprise avec journalisation :

Sur le système cible, créez le fichier de point de reprise Replicat.

Définissez le nom du journal qui doit être utilisé pour le fichier de point de reprise. La valeur par défaut est GGSCHEMA/OGGJRN.

Vous pouvez le modifier en définissant la valeur par défaut pour la session du client d'administration en cours à l'aide de la commande DEFAULTJOURNAL. La syntaxe de la commande DEFAULTJOURNAL est la suivante :
```
DEFAULTJOURNAL *library_name*/*journal_name*
```
Où : library_name est le nom de la bibliothèque et journal_name est le nom du journal à utiliser pour les opérations suivantes qui peuvent éventuellement avoir un journal spécifié.

Ajoutez la table de points de reprise.

ADD CHECKPOINTTABLE *library_name*.chkptab

Ajoutez une journalisation à la table de points de reprise.
```
ADD TRANDATA *library_name*.CHKPTAB
```

Pour plus d'informations sur la création d'une table de points de reprise, reportez-vous à Ajout d'une table de points de reprise.

Ajouter une table de signal d'activité

Les tables de signal d'activité permettent de surveiller le décalage tout au long du cycle de réplication des données. Les signaux d'activité automatiques sont envoyés de chaque base de données source dans les flux de réplication, en mettant à jour les enregistrements dans une table d'origine des signaux d'activité et une table des signaux d'activité, et en créant un enregistrement d'historique des signaux d'activité.

Chaque processus du flux de réplication met à jour l'enregistrement de signal d'activité avec des informations de suivi qui sont ensuite mises à jour dans la table de signal d'activité de la base de données cible. Ces enregistrements de signal d'activité sont insérés ou mis à jour dans la table de signal d'activité des bases de données cible.

Remarque : la création de la table de signal d'activité est facultative, mais recommandée.

Pour ajouter une table de signal d'activité, connectez-vous à chaque base de données source et cible à partir de la page Connexions à la base de données, sélectionnez le menu Signal d'activité, puis procédez comme suit :

Cliquez sur le signe plus (+) en regard pour ajouter une table de signal d'activité.
Acceptez les paramètres par défaut ou modifiez les valeurs disponibles si nécessaire.

Remarque : pour les bases de données qui ont une option pour Cible uniquement, sélectionnez cette option si cette base de données doit uniquement être utilisée en tant que base de données cible dans le flux de réplication, afin d'éviter de créer des travaux inutiles qui seraient associés à une base de données source.
Cliquez sur Soumettre.

Pour effectuer cette tâche à partir de la ligne de commande et vérifier les limitations importantes propres à la base de données, reportez-vous à ADD HEARTBEATTABLE dans Référence de l'interface de ligne de commande pour Oracle GoldenGate.

Les étapes suivantes décrivent les commandes de configuration de la table de signal d'activité.

Lancez le client Admin à partir de la ligne de commande.

Connectez-vous au déploiement à partir du client Admin.

CONNECT https://remotehost:*srvmgrport* DEPLOYMENT *deployment_name* AS *deployment_user* PASSWORD *deployment_password*

Voici un exemple :

CONNECT https://remotehost:16000 DEPLOYMENT *ggdep_postgres* AS ggadmin PASSWORD P@ssWord

Connexion aux bases de données source et cible à l'aide de la commande DBLOGIN USERIDALIAS. L'exemple suivant illustre la connexion à la base de données source avec l'alias d'informations d'identification ggeast :
```
(https://remotehost:16000 ggdep_postgres)> DBLOGIN USERIDALIAS ggeast
```

Ajoutez la table de signal d'activité :

(https://remotehost:16000 ggdep_postgres)> ADD HEARTBEATTABLE

En option, pour une base de données cible uniquement, qui est utilisée pour la réplication unidirectionnelle uniquement, vous pouvez inclure l'option TARGETONLY qui ne créera pas de fonction de mise à jour d'enregistrement de signal d'activité.

Pour plus d'informations sur les options de commande, reportez-vous à ADD HEARTBEATTABLE.

Exécution de la fonction de mise à jour et de purge du signal d'activité pour PostgreSQL

Oracle GoldenGate pour PostgreSQL prend en charge une configuration de table de signal d'activité, avec certaines limites concernant les tâches de mise à jour et de purge.

La table de signal d'activité et les fonctions associées sont créées à partir de la commande ADD HEARTBEATTABLE. Toutefois, pour PostgreSQL, il n'existe aucun planificateur automatique pour appeler les fonctions.

Une fonction principale contrôle les fonctions de mise à jour de l'enregistrement de signal d'activité et de purge de la table d'historique de signal d'activité. Les paramètres par défaut de ces deux fonctions sont de 60 secondes pour la fréquence de mise à jour et de 1 jour pour la purge des enregistrements d'historique, ce qui supprime tous les enregistrements de plus de 30 jours par défaut.

Pour appeler la fonction d'enregistrement de signal d'activité principale, les utilisateurs doivent créer un travail au niveau du système d'exploitation qui s'exécute

"select ggschema.gg_hb_job_run();"

Lorsque cette fonction est appelée, elle prend en compte les paramètres de fréquence de mise à jour et de purge des enregistrements historiques et utilise ces valeurs indépendamment des paramètres du planificateur pour l'appel de fonction.

Par exemple, les utilisateurs peuvent créer un travail CRON avec la syntaxe suivante et l'exécuter toutes les minutes.

PGPASSWORD="gguserpasswd" psql -U gguser -d dbname -h remotehost -p 5432 -c "select ggschema.gg_hb_job_run();" >/dev/null
 2>&1

Planificateur de tâches Windows, pgAdmin ou pg_cron sont d'autres programmes qui peuvent être utilisés pour planifier l'appel de fonction.

Création de la tâche de nettoyage CDC Oracle GoldenGate

Pour les utilisateurs SQL Server, il est nécessaire de créer des tâches de nettoyage CDC Oracle GoldenGate avant d'ajouter une extraction. Pour ce faire, suivez les étapes décrites dans Détails du processus de nettoyage CDC Oracle GoldenGate.

PostgreSQL : Considérations relatives à l'extraction pour le déploiement à distance

Pour un déploiement distant, la base de données source et Oracle GoldenGate sont installés sur des serveurs distincts. Les déploiements à distance sont la seule option disponible pour prendre en charge les bases de données cloud, telles qu'Azure pour PostgreSQL ou Amazon Aurora PostgreSQL.

Pour les déploiements à distance, l'interdépendance du système d'exploitation entre le serveur de base de données et le serveur Oracle GoldenGate doit être identique.

L'heure et les fuseaux horaires du serveur Oracle GoldenGate doivent être synchronisés avec ceux du serveur de base de données. Si cela n'est pas possible, le positionnement d'une extraction lors de la création ou de la modification d'une extraction devra être effectué par LSN.

Dans les cas d'utilisation de la capture à distance, l'utilisation de SQLEXEC peut introduire une latence supplémentaire, car l'opération SQLEXEC doit être effectuée en série pour chaque enregistrement traité par l'extraction. Si un filtrage spécial nécessitant une valeur SQLEXEC est effectué par un processus Extract hub distant et que l'impact sur les performances est trop grave, il peut s'avérer nécessaire de rapprocher le processus Extract de la base de données source.

Avec les déploiements distants, une faible latence réseau est importante et il est recommandé que la latence réseau entre le serveur Oracle GoldenGate et le serveur de base de données source soit inférieure à 1 milliseconde.