Préparer les tables pour traitement

Cette section explique comment préparer les tables pour le traitement. La préparation des tables nécessite les tâches suivantes.

Garantir l'unicité des lignes pour les tables

Oracle GoldenGate requiert une forme d'identificateur de ligne unique sur les tables source et cible afin de localiser les lignes cible appropriées pour les mises à jour et les suppressions répliquées.

Sauf si une clause KEYCOLS est utilisée dans l'instruction TABLE ou MAP, Oracle GoldenGate sélectionne un identificateur de ligne à utiliser dans l'ordre de priorité suivant :

  1. Clé primaire

  2. Première clé unique alphanumérique ne contenant pas d'horodatage ni de colonne calculée non matérialisée.

  3. S'il n'existe aucun des types de clé précédents (même si d'autres types de clé peuvent être définis dans la table), Oracle GoldenGate construit une pseudo-clé de toutes les colonnes. que la base de données permet d'être utilisée dans une clé unique, à l'exclusion de celles qui ne sont pas prises en charge par Oracle GoldenGate dans une clé ou de celles qui sont exclues de la configuration Oracle GoldenGate.

Remarque : s'il existe d'autres clés non utilisables sur une table ou s'il n'y a aucune clé dans la table, Oracle GoldenGate consigne un message approprié dans le fichier de rapport. La création d'une clé à partir de toutes les colonnes entrave les performances d'Oracle GoldenGate sur le système source. Sur la cible, cette clé entraîne l'utilisation par le processus Replicat d'une clause WHERE plus grande et moins efficace.

  1. Si une table n'a pas de clé appropriée ou si vous préférez que les clés existantes ne soient pas utilisées, vous pouvez définir une clé de substitution si la table comporte des colonnes qui contiennent toujours des valeurs uniques. Vous définissez cette clé de substitution en incluant une clause KEYCOLS dans le paramètre d'extraction TABLE et le paramètre de réplication MAP. La clé indiquée remplacera toute clé primaire ou unique existante détectée par Oracle GoldenGate. Reportez-vous à TABLE | MAP dans Référence pour Oracle GoldenGate.

Tables avec une clé primaire dérivée d'un index unique

En l'absence de clé primaire sur une table, MySQL promeut un index unique en clé primaire si la colonne indexée est NOT NULL. S'il existe plusieurs de ces index non NULL, le premier qui a été créé devient la clé primaire. Pour éviter les erreurs de réplication, créez ces index dans le même ordre sur les tables source et cible.

Par exemple, supposons que les tables source et cible nommées ggvam.emp comportent chacune des colonnes nommées premier, milieu et dernier, et que toutes sont définies comme NOT NULL. Si vous créez des index uniques dans l'ordre suivant, Oracle GoldenGate abandonne la cible car les définitions de table ne correspondent pas.

Source :

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

Cible :

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

Le résultat de cette séquence est que MySQL promeut l'index sur la colonne source "first" en clé primaire, et promeut l'index sur la colonne cible "last" en clé primaire. Oracle GoldenGate sélectionne les clés primaires comme identificateurs lorsqu'il crée son enregistrement de métadonnées et que les métadonnées ne correspondent pas. Pour éviter cette erreur, choisissez la colonne que vous souhaitez promouvoir en tant que clé primaire, puis créez d'abord cet index sur la source et la cible.

Indiquer votre propre clé à utiliser par Oracle GoldenGate

Si une table n'a pas l'un des types d'identificateur de ligne précédents ou si vous préférez que ces identificateurs ne soient pas utilisés, vous pouvez définir une clé de substitution si la table contient des colonnes qui contiennent toujours des valeurs uniques. Vous définissez cette clé de substitution en incluant une clause KEYCOLS dans le paramètre d'extraction TABLE et le paramètre de réplication MAP. La clé indiquée remplacera toute clé primaire ou unique existante détectée par Oracle GoldenGate.

Limiter les modifications de ligne dans les tables ne comportant pas de clé

Si une table cible n'a pas de clé primaire ou de clé unique, des lignes en double peuvent exister. Dans ce cas, Oracle GoldenGate peut mettre à jour ou supprimer un trop grand nombre de lignes cible, ce qui entraîne la désynchronisation des données source et cible sans que des messages d'erreur vous alertent. Pour limiter le nombre de lignes mises à jour, utilisez le paramètre DBOPTIONS avec l'option LIMITROWS dans le fichier de paramètres de réplication. LIMITROWS peut augmenter les performances d'Oracle GoldenGate sur le système cible car une seule ligne est traitée.

Considérations relatives aux déclencheurs et aux contraintes en cascade

Déclencheurs

Désactivez les déclencheurs sur les tables cible ou modifiez-les pour ignorer les modifications apportées par l'utilisateur de base de données Oracle GoldenGate. Oracle GoldenGate réplique les instructions LMD résultant d'un déclencheur. Si le même déclencheur est activé sur la table cible, il devient redondant en raison de la version répliquée et la base de données renvoie une erreur.

Considérations relatives aux contraintes en cascade

Les mises à jour et les suppressions en cascade capturées par Oracle GoldenGate ne sont pas consignées dans le journal binaire. Elles ne sont donc pas capturées. Cette valeur est valide pour MySQL et MariaDB. Par exemple, lorsque vous exécutez l'instruction de suppression dans la table parent avec une relation parent-enfant entre les tables, les suppressions en cascade (le cas échéant) se produisent pour la table enfant, mais elles ne sont pas consignées dans le journal binaire. Seul l'enregistrement de suppression ou de mise à jour de la table parent est consigné dans le journal binaire et capturé par Oracle GoldenGate.

Pour plus d'informations, reportez-vous à https://mariadb.com/kb/en/replication-and-foreign-keys/ et https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html.

Pour gérer correctement la réplication des opérations en cascade, il est recommandé de désactiver les suppressions et les mises à jour en cascade sur la source et de coder votre application pour supprimer ou mettre à jour explicitement les enregistrements enfant avant de modifier l'enregistrement parent. Vous devez également vous assurer que la table parent cible a les mêmes contraintes en cascade configurées que la table parent source, mais cela peut entraîner une désynchronisation entre la source et la cible, en particulier en cas de réplication bidirectionnelle.