Préparer les tables pour traitement

Vous devez effectuer les tâches suivantes pour préparer vos tables en vue de leur utilisation dans un environnement Oracle GoldenGate pour Db2 LUW.

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 LUW Db2 cible. 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.

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.

  4. 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 des paramètres et des fonctions pour Oracle GoldenGate.

Utilisation de KEYCOLS pour spécifier une clé personnalisée

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.

Empêcher les modifications clés

N'ajoutez pas de colonnes à une clé une fois qu'Oracle GoldenGate a commencé à extraire des données de la table. Cette règle s'applique à une clé primaire, à une clé unique, à une clé KEYCOLS ou à une clé colonne entière. Db2 LUW ne fournit pas d'image before pour les colonnes ajoutées à une table. Si des colonnes d'une clé sont mises à jour sur la source, Oracle GoldenGate a besoin d'une image "avant" pour effectuer une comparaison avec les valeurs en cours dans la table cible lors de la réplication de la mise à jour.

Tenir à jour les tables de requêtes matérialisées

Pour maintenir la parité entre les tables de requêtes matérialisées (MQT) source et cible, vous répliquez les tables de base, mais pas les tables MQT. La base de données cible gère les MQT en fonction des modifications que le processus Replicat applique aux tables de base.

Les règles de configuration de ces tables sont les suivantes :

Créer une table temporelle

Une table temporelle est une table qui gère l'historique de ses données et la période de validité de ses données. Les tables temporelles sont utilisées dans Oracle GoldenGate pour assurer le suivi de toutes les anciennes lignes qui sont supprimées ou mises à jour dans la table. Les tables temporelles sont également utilisées pour maintenir la validité de ses lignes et de ses données. Par exemple, Oracle GoldenGate assure le suivi de la période pendant laquelle une ligne est valide. Il existe trois types de table temporelle : table system-period, table application-period et table bitemporale.

Convertir en table temporelle

Vous pouvez convertir une table existante en une table temporelle, ce qui modifie la structure de la table. Cette section décrit les modifications apportées à la structure des tables. L'exemple de table existante suivant est converti en trois types de table temporelle dans les exemples de cette section :

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

Exemple 1 : conversion d'une table existante en table temporelle de période système

Vous convertissez l'exemple de table existante en une table temporelle de période système en ajoutant les colonnes SYSTEM_PERIOD, transaction id et SYSTEM_TIME comme suit :

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

Vous créez ensuite une table d'historique pour la nouvelle table temporelle à l'aide de l'une des deux méthodes suivantes :

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

La clause RESTRICT ON DROP ne permet pas à la table d'historique d'être supprimée lors de la suppression de la table temporelle de période système. Sinon, la table d'historique est implicitement supprimée lors de la suppression de la table temporelle associée. Vous pouvez créer une table d'historique sans RESTRICT ON DROP. Une table d'historique ne peut pas être supprimée explicitement.

Vous ne devez pas utiliser la clause GENERATED ALWAYS lors de la création d'une table d'historique. La clé primaire de la table temporelle système-période ne s'applique pas non plus ici car il peut y avoir de nombreuses mises à jour pour une ligne particulière de la table de base, ce qui déclenche de nombreuses insertions dans la table d'historique pour le même ensemble de clés primaires. En dehors de cela, la structure d'une table d'historique doit être exactement la même que celle de sa table temporelle de période système associée. La table d'historique doit avoir le même nombre et le même ordre de colonnes que la table temporelle de période système. Les colonnes de la table d'historique ne peuvent pas être explicitement ajoutées, supprimées ou modifiées. Vous devez associer une table temporelle système-période à sa table d'historique avec l'instruction suivante :

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Les colonnes GENERATED ALWAYS de la table sont celles qui sont toujours alimentées par le gestionnaire de base de données. Vous n'avez donc aucun contrôle sur ces colonnes. Le gestionnaire de base de données renseigne ces colonnes en fonction de l'heure système.

Les colonnes SYSTEM_PERIOD et transaction id supplémentaires ont des valeurs par défaut pour les lignes existantes, comme dans les cas suivants :

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

La table d'historique associée est renseignée avec les images "avant" une fois que vous avez commencé à mettre à jour la table temporelle.

Exemple 2 : conversion d'une table existante en table temporelle de période d'application

Vous pouvez convertir l'exemple de table existante en table temporelle de période d'application en ajoutant des colonnes de temps et une période BUSINESS_TIME comme suit :

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Lors de l'ajout de colonnes de temps, vous devez vous assurer que lors de la saisie des valeurs de temps de validité métier des colonnes de temps existantes, la colonne bus_start a toujours une valeur inférieure à bus_end car ces colonnes indiquent la validité métier des lignes.

La nouvelle table temporelle application-period ressemblera à :

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

Exemple 3 : conversion d'une table existante en table bitemporale

Vous pouvez convertir l'exemple de table existante en table bitemporale en ajoutant SYSTEM_PERIOD, des colonnes de temps avec la période SYSTEM_TIME et BUSINESS_TIME comme suit :

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Lors de l'ajout des colonnes d'heure, vous devez vous assurer que lors de la saisie des valeurs d'heure de validité métier de colonnes d'heure existantes, la colonne bus_start a toujours une valeur inférieure à bus_end car ces colonnes indiquent la validité métier des lignes.

Vous créez ensuite une table d'historique pour la nouvelle table temporelle à l'aide de l'une des deux méthodes suivantes :

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;
ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Les colonnes GENERATED ALWAYS de la table sont celles qui sont toujours alimentées par le gestionnaire de base de données. Vous n'avez donc aucun contrôle sur ces colonnes. Le gestionnaire de base de données renseigne ces colonnes en fonction de l'heure système.

Les colonnes SYSTEM_PERIOD et transaction id supplémentaires ont des valeurs par défaut pour les lignes existantes, comme dans les cas suivants :

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

La table d'historique associée est renseignée avec les images "avant" une fois que vous avez commencé à mettre à jour la table temporelle.

Les colonnes de période, d'ID de transaction et d'heure SYSTEM_TIME supplémentaires ont des valeurs par défaut pour les lignes existantes, comme suit :

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

La table d'historique est renseignée avec les images "avant" une fois que l'utilisateur commence à mettre à jour la table temporelle.

Exemple 4 : réplication dans un environnement hétérogène.

Dans une configuration hétérogène dans laquelle vous n'avez pas de tables temporelles côté application, vous pouvez uniquement répliquer les tables système-période et bitemporelles, mais pas les tables d'historique associées. Lors de la réplication dans ce cas, vous devez prendre en charge la valeur des colonnes d'ID de transaction et SYSTEM_PERIOD. Ces colonnes contiennent des valeurs que la base de données cible peut ne pas prendre en charge. Vous devez d'abord utiliser les fonctions de conversion de mapping pour convertir ces valeurs au format pris en charge par la base de données cible, puis mapper les colonnes en conséquence.

Par exemple, MySQL a une plage DATETIME comprise entre 1000-01-01 00:00:00.000000 et 9999-12-31 23:59:59.999999. Vous ne pouvez pas répliquer une valeur d'horodatage de 0001-01-01-00.00.00.000000000000 vers MySQL. Pour répliquer de telles valeurs, vous devez convertir cette valeur en valeur MySQL DATETIME 1000-01-01 00:00:00.000000, puis mettre en correspondance les colonnes. Si la table system-period policy_info contient la ligne suivante :

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Pour répliquer la ligne dans MySQL, vous devez utiliser la fonction colmap() :

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

Répliquer avec des tables temporelles

Vous pouvez choisir l'une des méthodes suivantes pour répliquer une période système ou une table temporelle bitemporale comme suit :

Oracle GoldenGate ne peut pas détecter et résoudre les conflits lors de l'utilisation de la réplication par défaut car la période SYSTEM_TIME et les colonnes transactionstart id restent générées automatiquement. Ces colonnes ne peuvent pas être indiquées dans les clauses set et where. Si vous utilisez le paramètre SUPPRESSTEMPORALUPDATES, Oracle GoldenGate prend en charge la fonction CDR.