Préparer les tables pour le traitement

Les attributs de table suivants doivent être traités dans un environnement Oracle GoldenGate.

Désactivation des déclencheurs et des contraintes en cascade

Désactivez les déclencheurs, les contraintes de suppression en cascade et les contraintes de mise à jour en cascade sur les tables Sybase 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 ou d'une contrainte en cascade. Si le même déclencheur ou la même contrainte 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. Prenons l'exemple suivant, où les tables source sont emp_src et salary_src, et les tables cible emp_targ et salary_targ.

  1. Une suppression est émise pour emp_src.

  2. Il met en cascade une suppression dans salary_src.

  3. Oracle GoldenGate envoie les deux suppressions à la cible.

  4. La suppression parent arrive en premier et est appliquée à emp_targ.

  5. La suppression parent met en cascade une suppression vers salary_targ.

  6. La suppression en cascade de salary_src est appliquée à salary_targ.

  7. Impossible de localiser la ligne car elle a déjà été supprimée à l'étape 5.

Pour configurer le processus Replicat afin de désactiver les déclencheurs cible au début de sa session de base de données, procédez comme suit :

  1. Affectez le rôle de réplication à l'utilisateur Replicat.

  2. Ajoutez l'instruction de paramètre suivante au niveau racine du fichier de paramètres Replicat.

SQLEXEC "set triggers off"

Affecter des identificateurs de ligne

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.

Limiter les modifications de ligne dans les tables qui ne possèdent pas de clé

Si une table cible n'a pas de clé primaire ou de clé unique, des lignes en double peuvent exister. Oracle GoldenGate peut mettre à jour ou supprimer un trop grand nombre de lignes dans la table cible, ce qui entraîne la désynchronisation des données source et cible sans que des messages d'erreur ne 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.

Réplication de données cryptées

Oracle GoldenGate prend en charge les colonnes cryptées avec un mot de passe crypté par le système, mais pas les colonnes cryptées avec un mot de passe défini par l'utilisateur. Vérifiez les tables à partir desquelles vous souhaitez capturer des données par rapport aux limites Oracle GoldenGate suivantes :

Les colonnes cryptées sont cryptées dans les fichiers de données et dans le journal. Le processus Extract doit donc être configuré pour extraire les valeurs en texte clair de la base de données. Pour déclencher cette extraction, utilisez les options FETCHCOLS et FETCHMODCOLS[EXCEPT] du paramètre d'extraction TABLE. FETCHCOLS force une extraction de valeurs qui ne figurent pas dans le journal, et FETCHMODCOLS ou FETCHMODCOLS[EXCEPT] force une extraction de valeurs qui se trouvent dans les journaux. Utilisés ensemble, ces paramètres garantissent que les colonnes cryptées sont toujours extraites de la base de données.

Voici un exemple de configuration de l'extraction pour la prise en charge du cryptage. Dans cet exemple, la colonne cryptée est cardnum.

TABLE ab.payments, FETCHCOLS (cardnum), FETCHMODCOLS (cardnum);

Préparation des journaux de transactions

Pour capturer des opérations LMD, Oracle GoldenGate lit les journaux en ligne. Pour assurer la continuité et l'intégrité du traitement Oracle GoldenGate, les journaux doivent être configurés comme indiqué dans les sections suivantes :

Initialisation du point de troncation secondaire

Définissez un point de troncation de journal secondaire sur le système source avant d'exécuter le traitement d'extraction Oracle GoldenGate. Le processus Extract utilise le point de troncature secondaire pour identifier les données qui restent à traiter.

Pour initialiser le point de troncature secondaire, connectez-vous à la base de données en tant qu'utilisateur disposant des privilèges sa_role, puis exécutez la commande suivante :

dbcc settrunc( 'ltm', valid )

Par défaut, le processus Extract gère le point de troncation secondaire une fois qu'il est établi. N'autorisez pas l'arrêt de l'extraction plus longtemps que nécessaire ; sinon, le journal pourrait se remplir et la base de données s'arrêtera. Le seul moyen de résoudre ce problème est de désactiver le point de troncation secondaire et de le gérer en dehors d'Oracle GoldenGate, puis de purger le journal des transactions. Les données qui ne sont pas encore traitées par le processus Extract seront perdues et vous devrez resynchroniser les données source et cible.

Pour contrôler la gestion du point de troncature secondaire, utilisez le paramètre TRANLOGOPTIONS. Pour plus d'informations, reportez-vous à Référence pour Oracle GoldenGate pour Windows et UNIX.

Dimensionnement et conservation des journaux

Conservez suffisamment de données de journal sur le système source pour que le processus Extract puisse recommencer à partir de ses points de reprise après l'avoir arrêté ou en cas d'incident non planifié. Le processus Extract doit avoir accès au journal qui contient le début de la plus ancienne unité de travail non validée, et à tous les journaux par la suite. Pour déterminer l'emplacement des points de reprise Extract, utilisez la commande INFO EXTRACT. Pour plus d'informations sur INFO EXTRACT, reportez-vous à Référence pour Oracle GoldenGate pour Windows et UNIX.

Si les données dont le processus Extract a besoin pendant le traitement ne sont pas conservées, dans les journaux en ligne ou de sauvegarde, l'une des actions correctives suivantes peut être requise :

Veillez à ne pas utiliser les options de sauvegarde ou d'archivage qui entraînent l'écrasement des anciens fichiers d'archive par les nouvelles sauvegardes sur le système source. Les nouvelles sauvegardes doivent être des fichiers distincts avec des noms différents des anciens. Cela garantit que si le processus Extract recherche un journal particulier, il existe toujours et que les données sont disponibles au cas où cela serait nécessaire pour un dossier de support.

Activation de la journalisation des transactions

Utilisez la commande ADD TRANDATA pour marquer chaque table source pour la réplication. Cette commande utilise les procédures système Sybase sp_setreptable et sp_setrepcol. ADD TRANDATA est la méthode recommandée pour marquer les tables, au lieu d'utiliser ces procédures via l'interface de base de données, mais le propriétaire ou l'administrateur système peut les utiliser si nécessaire. Pour plus d'informations, voir la documentation Sybase.

Pour marquer des tables pour la réplication avec ADD TRANDATA :

Exécutez la commande ADD TRANDATA pour chaque table à marquer. La syntaxe de la commande ADD TRANDATA est la suivante :

ADD TRANDATA SCHEMA.TABLE LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED

LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED détermine si les données de LOB ne sont jamais propagées, propagées uniquement si elles sont modifiées (valeur par défaut) ou toujours propagées. LOBSIFCHANGED est la valeur par défaut si aucune option LOB n'est indiquée. La commande ADD TRANDATA remplace le paramètre de réplication LOB actuellement défini pour la table.

Remarque : certaines options ADD TRANDATA activent l'option ALWAYS_REPLICATE de sp_setrepcol. Si une colonne LOB contient une valeur NULL, puis qu'une autre colonne de la table est mise à jour (mais pas LOB), cette colonne LOB ne sera pas capturée même si ALWAYS_REPLICATE est activé.