Propager les modifications de l'évolution des tables de la source à la cible

Oracle GoldenGate réplique les modifications apportées à la table, y compris les événements de table manquants. Lorsque AUTOSCHEMA est activé, l'événement de table manquant est détecté lors de la mise en correspondance de table, plus précisément, lors du traitement de l'enregistrement de définition de table (TDR) à partir du fichier trace.

Les étapes suivantes expliquent ce workflow :

  1. Le processus Replicat tente de résoudre les métadonnées de la table cible. Si la résolution des métadonnées échoue avec l'erreur object not found, elle indique que la table cible n'existe pas sur la base de données cible.

  2. Si la fonctionnalité AUTOSCHEMA est activée, l'instruction CREATE TABLE, pour la table cible manquante, est générée en fonction des métadonnées source dans l'enregistrement TDR.

    1. Le modèle de mapping de type de données par défaut, basé sur le type de base de données cible, est utilisé lors de la sélection de types de données appropriés pour les colonnes de la table cible.

    2. L'instruction CREATE TABLE est générée en fonction de la syntaxe SQL de la base de données cible, en tenant compte des préférences utilisateur, le cas échéant. Vous pouvez spécifier les préférences suivantes :

      1. Nom de la table cible tel qu'indiqué dans la clause TARGET du jeu d'états MAP correspondant dans le fichier de paramètres de réplication.

      2. Par défaut, les noms des colonnes de la table cible sont identiques à ceux des colonnes de la table source. Toutefois, vous pouvez sélectionner des noms différents à l'aide de COLMAP.

      3. Vous pouvez sélectionner des noms de type de données personnalisés (disponibles sur la base de données cible) pour des noms de type de données source (ou des colonnes source) spécifiques à l'aide de TYPEMAP. Convient dans les cas où les types de données pris en charge (et leurs limites) peuvent différer entre les bases de données source et cible.

  3. La création de tables à l'aide des instructions CREATE TABLE générées est gérée automatiquement par le processus de réplication, à condition que l'opération réponde aux critères de filtrage configurés (par exemple, les règles INCLUDE/EXCLUDE). En cas de problème temporaire, le système tente d'appliquer la modification plusieurs fois en fonction des paramètres de nouvelle tentative configurés. Si la modification ne peut toujours pas être appliquée après ces nouvelles tentatives, la réplication s'arrête et une erreur est signalée.

Propager l'évolution des colonnes dans les tables cible

La colonne manquante dans l'événement de table cible est détectée lors du mapping de table. Plus précisément, lors du traitement de l'enregistrement de définition de table (TDR).

  1. Le processus Replicat tente de résoudre les métadonnées de la table cible. Dans ce cas, la résolution des métadonnées n'échoue pas, car la table cible existe, mais une structure de définition de table cible valide est renvoyée.

  2. Si AUTOSCHEMA est activé, les métadonnées de la définition de table cible sont comparées aux métadonnées de la table source dans l'enregistrement TDR entrant. Cela permet de détecter toutes les colonnes supplémentaires dans les métadonnées de la table source de l'enregistrement TDR qui ne sont pas disponibles dans la définition de la table cible et qui ont été extraites à l'étape précédente.

    1. Le modèle de mapping de type de données par défaut selon le type de base de données cible est utilisé lors du choix des types de données les plus appropriés pour les nouvelles colonnes de la table cible.

    2. L'instruction ALTER TABLE ADD COLUMN est générée en fonction de la syntaxe SQL de la base de données cible.

      Vous pouvez choisir des noms de type de données personnalisés (disponibles sur la base de données cible) pour des noms de type de données source (ou des colonnes source) spécifiques. Convient dans les cas où les types de données pris en charge (et leurs limites) peuvent différer entre les bases de données source et cible.

  3. Si de telles colonnes supplémentaires sont identifiées, l'instruction ALTER TABLE ADD COLUMN, pour la table cible existante, est générée en fonction des métadonnées source de l'enregistrement TDR (plus particulièrement les colonnes supplémentaires de l'enregistrement TDR).

L'exécution du fichier ALTER TABLE DDL généré est effectuée par l'infrastructure de réplication LDD existante, uniquement lorsque le DDL correspondant transmet les critères de chaîne de fichiers LDD (critères DDL INCLUDE/EXCLUDE avec les options OBJTYPE/OPTYPE/OBJNAME). Etant donné que l'infrastructure de réplication LDD est également utilisée pour AUTOSCHEMA, la logique de nouvelle tentative sur les codes d'erreur non fatals est également utilisée. La logique de nouvelle tentative comporte également un nombre configurable de nouvelles tentatives et un délai entre les nouvelles tentatives. Si l'exécution LDD générée échoue même après les nouvelles tentatives, le processus Replicat est abandonné.