Détection et résoudre automatiquement les conflits

Lorsqu'Oracle GoldenGate réplique des modifications entre les bases de données Oracle, vous pouvez configurer et gérer la détection et la résolution automatiques des conflits Oracle GoldenGate dans les bases de données Oracle. Remarque : la fonctionnalité de détection et de résolution automatiques des conflits est disponible à partir d'Oracle Database 12c version 2 (12.2) et versions ultérieures et fonctionne avec Oracle GoldenGate 12c (12.3.0.1) et versions ultérieures. Il existe une fonctionnalité manuelle de détection et de résolution des conflits, appelée CDR (Oracle GoldenGate Conflict Detection and Resolution). Le CDR Oracle GoldenGate est configuré dans le fichier de paramètres Replicat. Pour en savoir plus sur le CDR Oracle GoldenGate, reportez-vous à Détection et résolution manuelles des conflits.

A propos de la détection et de la résolution automatiques de conflits

Lorsqu'Oracle GoldenGate réplique des modifications entre les bases de données Oracle, vous pouvez configurer et gérer automatiquement la détection et la résolution des conflits Oracle GoldenGate dans ces bases de données.

Cette fonctionnalité est destinée aux configurations actives-actives, dans lesquelles Oracle GoldenGate doit assurer la synchronisation des données entre plusieurs bases de données contenant les mêmes ensembles de données.

Remarque : fonctionnalité de détection et de résolution automatiques des conflits (ACDR) disponible uniquement lors de l'utilisation d'Oracle GoldenGate avec Oracle AI Database. Pour les bases de données non Oracle, une fonctionnalité de détection et de résolution manuelles des conflits est disponible avec Oracle GoldenGate. Le CDR Oracle GoldenGate est configuré dans le fichier de paramètres Replicat.

Détection et résoudre automatiquement les conflits

Vous pouvez configurer la détection et la résolution automatiques des conflits dans une configuration Oracle GoldenGate qui réplique les tables entre les bases de données Oracle. Pour configurer la détection et la résolution automatiques des conflits pour une table, vous devez appeler la procédure ADD_AUTO_CDR dans le package DBMS_GOLDENGATE_ADM. Prérequis pour la configuration de la détection et de la résolution automatiques des conflits, l'utilisateur Oracle GoldenGate doit disposer des privilèges appropriés. Pour en savoir plus sur les privilèges utilisateur, reportez-vous à Octroi de privilèges utilisateur pour Oracle AI Database 26ai et supérieur et à Octroi de privilèges utilisateur pour Oracle Database 21c et inférieur.

L'administrateur doit être connecté à la base de données pluggable appropriée lors de l'appel de ADD_AUTO_CDR. Les constantes suivantes, qui représentent des indicateurs de bit, sont maintenant ajoutées :

L'exemple suivant utilise une commande ALTER pour la table HR.EMPLOYEES :

BEGIN
 dbms_goldengate_adm.alter_auto_cdr
 (schema_name => 'HR'
 ,table_name => 'EMPLOYEES'
 ,additional_options => DBMS_GOLDENGATE_ADM.ADDITIONAL_OPTIONS_ADD_KEY_VERSION );
END;
/

Reportez-vous à la description de additional_options dans le document ADD_AUTO_CDR Procedure du manuel Oracle AI Database PL/SQL Packages and Types Reference.

Lorsque Oracle GoldenGate capture des modifications qui proviennent d'une base de données Oracle AI Database, chaque modification est encapsulée dans un enregistrement de modification logique de ligne (LCR). Un LCR de ligne est une représentation structurée d'un changement de ligne LMD. Chaque LCR de ligne inclut le type d'opération, les anciennes valeurs de colonne et les nouvelles valeurs de colonne. Plusieurs LCR de ligne peuvent faire partie d'une transaction de base de données unique.

Lorsque plusieurs répliques d'une table permettent d'apporter des modifications à la table, un conflit peut survenir lorsqu'une modification est apportée à la même ligne dans deux bases de données différentes à peu près en même temps. Oracle GoldenGate réplique les modifications à l'aide des LCR de ligne. Il détecte un conflit en comparant les anciennes valeurs de la ligne LCR pour la modification initiale à partir de la base de données d'origine avec les valeurs actuelles de la ligne de table correspondante dans la base de données de destination identifiée par les colonnes de clé. Si une valeur de colonne ne correspond pas, un conflit survient.

Une fois qu'un conflit est détecté, Oracle GoldenGate peut résoudre le conflit en remplaçant les valeurs de la ligne par certaines valeurs du LCR de ligne, en ignorant les valeurs du LCR de ligne ou en calculant un delta pour mettre à jour les valeurs de ligne.

La détection et la résolution automatiques des conflits ne nécessitent pas de modifications d'application pour les raisons suivantes :

Conditions requises pour la détection et la résolution automatiques des litiges

Voici les principales conditions requises pour configurer la fonction CDR automatique dans Oracle GoldenGate :

Compatibilité et migration

Si la table de base de la base de données source ne contient pas la colonne KEYVER$$, mais que la table de base cible le contient, DELETE et les mises à jour de clé primaire génèrent une erreur dans la base de données cible pour les résolutions EARLIEST TIMESTAMP, DELETE ALWAYS WINS et SITE PRIORITY.

Lors de la réplication à partir d'une table de base, qui a une valeur KEYVER$$ vers une table cible, ce qui n'est pas le cas, la colonne KEYVER$$ est ignorée.

Groupes de colonnes

Un groupe de colonnes est un regroupement logique de colonnes dans une table répliquée. Lorsque vous ajoutez un groupe de colonnes, la détection et la résolution des conflits sont effectuées sur les colonnes du groupe de colonnes séparément des autres colonnes de la table.

Lorsque vous configurez une table pour la détection et la résolution des conflits Oracle GoldenGate avec la procédure ADD_AUTO_CDR, toutes les colonnes scalaires de la table sont ajoutées à un groupe de colonnes par défaut. Pour définir d'autres groupes de colonnes pour la table, exécutez la procédure ADD_AUTO_CDR_COLUMN_GROUP. Toutes les colonnes de la table qui ne font pas partie d'un groupe de colonnes défini par l'utilisateur restent dans le groupe de colonnes par défaut de la table.

Les groupes de colonnes permettent à différentes bases de données de mettre à jour les différentes colonnes d'une même ligne à peu près en même temps sans provoquer de conflit. Lorsque des groupes de colonnes sont configurés pour une table, les conflits peuvent être évités même si différentes bases de données mettent à jour la même ligne dans la table. Aucun conflit n'est détecté si les mises à jour modifient les valeurs des colonnes de différents groupes de colonnes.

Figure 1 : Groupes de colonnes

Image de la suite

Cet exemple illustre la réplication d'une ligne dans les bases de données A et B. Les deux groupes de colonnes suivants sont configurés pour la table répliquée dans chaque base de données :

Ces groupes de colonnes permettent à la base de données A et à la base de données B de mettre à jour la même ligne quasiment en même temps sans provoquer de conflit. Plus précisément, les modifications suivantes sont apportées :

Etant donné que la colonne Office et la colonne Title appartiennent à des groupes de colonnes différents, les modifications sont répliquées sans qu'un conflit soit détecté. Il en résulte que les valeurs de la ligne sont identiques dans les deux bases de données après la réplication de chaque modification.

Mises à jour des objets LOB par morceaux

Un ensemble d'opérations LOB composé de LOB WRITE, LOB ERASE et LOB TRIM est une mise à jour de LOB par morceaux. Lorsqu'une table contenant des colonnes LOB est configurée pour la détection et la résolution des conflits, chaque colonne LOB est placée dans son propre groupe de colonnes et le groupe de colonnes a sa propre colonne d'horodatage masqué. La colonne d'horodatage est mise à jour sur la première opération LOB par morceaux.

Pour une colonne LOB, un conflit est détecté et résolu de l'une des manières suivantes :

Détection et résolution de conflits d'horodatage au plus tôt

Les colonnes portant les noms CDRTS$ column group et CDRTS$ROW sont utilisées pour contenir des horodatages qui reflètent les heures de modification des groupes de colonnes et de la ligne.

Remarque : les tables avec des symboles $ ou $$ sont des tables internes ou masquées.

DBMS_GOLDENGATE_ADM inclut les procédures suivantes pour la configuration de la résolution d'horodatage la plus ancienne et la plus récente :

Le champ ADDITIONAL_OPTIONS dans ADD_AUTO_CDR() et ALTER_AUTO_CDR() active l'utilisation de l'horodatage le plus ancien. L'activation de l'horodatage le plus ancien active automatiquement la gestion des versions, ce qui ajoute une nouvelle colonne masquée KEYVER$$ (numéro de version) de type horodatage. Une nouvelle valeur d'indicateur est ajoutée pour indiquer la première utilisation de l'horodatage. Ce champ est également ajouté à la table DELETE TOMBSTONE. Les conflits de suppression sont la raison pour laquelle un numéro de version est nécessaire. Avec une résolution d'horodatage la plus ancienne, les conflits de suppression, qui peuvent être transparents, peuvent non seulement réussir de manière incorrecte, mais également empêcher de nouvelles insertions de la ligne (nouvelles versions). Avec un horodatage de version, la suppression peut être résolue correctement par rapport à une instruction LMD de ligne pour la même version de ligne.

L'insertion initiale de la ligne reçoit l'horodatage actuel de sa valeur par défaut. La suppression de cette ligne insère ensuite le numéro de version et l'heure à laquelle cette ligne a été insérée dans la table de pierre tombale en cas de suppression. Par défaut, lors d'une nouvelle insertion, le numéro de version reçoit à nouveau l'horodatage actuel, évitant ainsi un faux conflit avec les entrées de suppression présentes dans la table de pierre tombale.

Exemple

Supposons que vous disposez d'une table tab1 qui est globalement cohérente entre les bases de données du site 1 et du site 2.

La table contient une clé (principale). L'ACDR gère automatiquement une version de clé (kv) et un horodatage (ts) en tant que colonnes pour la table de base (masquée) et la table de pierre tombale. Pour la version de clé kv et l'horodatage ts

Base de données 1 : insert tab1 key1 kv1 ts1

Base de données 2 : delete tab1 key1 kv1 ts1

Insertion pour supprimer la table TOMBSTONE key1 kv1 ts1

Base de données 1 : insert tab1 key1 kv2 ts2

Si vous n'utilisez pas la version de clé, l'insertion est ignorée, l'horodatage de suppression est antérieur. La version de clé étant utilisée, vous savez que kv2 n'est pas la version de la ligne qui a été supprimée et que l'insertion réussit.

Détection et résolution de conflits de l'horodatage le plus récent

Lorsque vous exécutez la procédure ADD_AUTO_CDR dans le package DBMS_GOLDENGATE_ADM afin de configurer une table pour la détection et la résolution automatiques des conflits Oracle GoldenGate, une colonne d'horodatage masqué est ajoutée à la table. Cette colonne d'horodatage masquée enregistre l'heure d'un changement de ligne et ces informations sont utilisées pour détecter et résoudre les conflits.

Lorsqu'un LCR de ligne est appliqué, un conflit peut survenir pour une opération INSERT, UPDATE ou DELETE. Le tableau suivant décrit chaque type de conflit et la façon dont il est résolu.

Opération Détection des conflits Résolution des conflits
INSERT Un conflit est détecté lorsque la table a la même valeur pour une colonne de clé que la nouvelle valeur dans le LCR de ligne.

Si l'horodatage du LCR de ligne est postérieur à l'horodatage de la ligne de table, les valeurs du LCR de ligne remplacent les valeurs de la table.

Si l'horodatage du LCR de ligne est antérieur à l'horodatage de la ligne de table, le LCR de ligne est ignoré et les valeurs de table sont conservées.

UPDATE

Un conflit est détecté dans chacun des cas suivants :

  • La valeur d'horodatage de la ligne LCR ne correspond pas à celle de la ligne correspondante de la table.

  • La non-concordance entre une ancienne valeur d'un groupe de colonnes dans le LCR de ligne ne correspond pas à la valeur de colonne dans la ligne de table correspondante. Un groupe de colonnes est un regroupement logique de colonnes dans une table répliquée.

  • La ligne de table n'existe pas. Si la ligne se trouve dans la table de pierre tombale, il s'agit d'un conflit de mise à jour/suppression.

S'il existe une non-concordance de valeurs et que l'horodatage du LCR de ligne est postérieur à l'horodatage de la ligne de table, les valeurs du LCR de ligne remplacent les valeurs de la table.

S'il existe une non-concordance de valeurs et que l'horodatage du LCR de ligne est antérieur à l'horodatage de la ligne de table, le LCR de ligne est ignoré et les valeurs de table sont conservées.

Si la ligne de table n'existe pas et que l'horodatage du LCR de ligne est postérieur à l'horodatage de la ligne de table de pierre tombale, le LCR de ligne est converti d'une opération UPDATE en une opération INSERT et inséré dans la table.

Si la ligne de table n'existe pas et que l'horodatage du LCR de ligne est antérieur à l'horodatage de la ligne de table de pierre tombale, le LCR de ligne est ignoré.

Si la ligne de la table n'existe pas et qu'il n'y a pas de ligne correspondante dans la table de pierre tombale, le LCR de ligne est converti d'une opération UPDATE en une opération INSERT et inséré dans la table.

DELETE

Un conflit est détecté dans chacun des cas suivants :

  • La valeur d'horodatage de la ligne LCR ne correspond pas à celle de la ligne correspondante de la table.

  • La ligne de table n'existe pas.

Si l'horodatage du LCR de ligne est postérieur à l'horodatage de la table, supprimez la ligne de la table.

Si l'horodatage du LCR de ligne est antérieur à l'horodatage de la table, le LCR de ligne est supprimé et les valeurs de la table sont conservées.

Si la suppression réussit, enregistrez le LCR de ligne en l'insérant dans la table de pierre tombale.

Si la ligne du tableau n'existe pas, enregistrez le LCR de ligne en l'insérant dans la table de pierre tombale.

L'image suivante présente la résolution des conflits entre la base de données A et la base de données B : Dernière résolution de conflit d'horodatage à l'aide de la dernière méthode d'horodatage.

Cet exemple illustre la réplication d'une ligne dans les bases de données A et B. Les colonnes de base de données sont Name, RowTS, Office, Title et Salary. La colonne RowTS est la colonne invisible dans les deux bases de données. La colonne Office de la base de données A contient une mise à jour et la colonne Title de la base de données B contient une mise à jour. Cela provoque un conflit et la résolution de ce conflit est effectuée en appliquant la dernière méthode d'horodatage.

Résolution delta des conflits

Avec la détection de conflit delta, un conflit se produit lorsqu'une valeur de l'ancienne liste de colonnes du LCR de ligne diffère de la valeur de la ligne correspondante dans la table.

Pour configurer la détection et la résolution des conflits delta pour une table, exécutez la procédure ADD_AUTO_CDR_DELTA_RES dans le package DBMS_GOLDENGATE_ADM. La méthode de résolution delta ne dépend pas d'un horodatage ou d'une colonne de résolution supplémentaire. Avec la résolution des conflits delta, le conflit est résolu en ajoutant la différence entre les nouvelles et les anciennes valeurs du LCR de ligne à la valeur de la table. Cette méthode de résolution est généralement utilisée pour les données financières telles que le solde d'un compte. Par exemple, si un solde bancaire est mis à jour simultanément sur deux sites, la valeur convergée compte pour tous les débits et crédits.

La figure suivante fournit un exemple illustrant la détection et la résolution des conflits delta.

Figure 2 : Détection et résolution des conflits dans le delta

La description de l'image suit

Cet exemple illustre la réplication d'une ligne dans les bases de données A et B. La colonne Balance est désignée comme la colonne sur laquelle la résolution des conflits delta est effectuée, et la colonne RowTS est la colonne d'horodatage invisible pour suivre l'heure de chaque modification apportée à la colonne Balance. Une modification est apportée à la valeur Balance de la ligne dans les deux bases de données quasiment en même temps (@T20 dans la base de données A et @T22 dans la base de données B). Ces modifications entraînent un conflit, et la résolution delta des conflits est utilisée pour résoudre le conflit de la manière suivante :

Après la résolution des conflits delta, la valeur de la colonne Balance est la même pour la ligne de la base de données A et de la base de données B.

Code CDR de priorité du site

Remarque : la résolution SITE PRIORITY est prioritaire sur tous les paramètres de résolution COLUMN GROUP.

Remarque : si le paramètre de réplication SITE PRIORITY n'est pas placé avant les instructions de mapping applicables dans le fichier de paramètres, il ne fonctionnera pas. Ce paramètre doit être placé avant les instructions de mapping applicables.

La résolution de priorité est indiquée dans le fichier de paramètres de réplication entre la source et la cible pour la résolution des conflits.

SITE PRIORITY est activé pour une base de données ou une base de données pluggable dans le fichier de paramètres de réplication avec le paramètre ACDR SITE_PRIORITY {source_db_name}{OVERWRITE | IGNORE }, qui est indiqué pour activer la résolution SITE PRIORITY pour une table.

Si l'option OVERWRITE est indiquée, la table source est prioritaire et les conflits sont résolus par OVERWRITE. Inversement, si l'option IGNORE est indiquée, la table cible est prioritaire et les modifications apportées à la table source sont ignorées en cas de conflit.

La résolution SITE PRIORITY peut être désactivée par le champ ADDITIONAL_OPTIONS dans la procédure ADD_AUTO_CDR() du package DBMS_GOLDENGATE_ADM et par ALTER_AUTO_CDR() en définissant IGNORE_SITE_PRIORITY.

Chaque relation source-cible Replicat peut être configurée différemment. Par conséquent, la convergence dépend de la configuration utilisateur.

Supprimer le CDR d'horodatage Toujours gagner

DELETE ALWAYS WINS est activé via le champ ADDITIONAL_OPTIONS dans les procédures DBMS_GOLDENGATE_ADM ADD_AUTO_CDR() et ALTER_AUTO_CDR(). Il s'agit à nouveau d'une méthode de résolution des conflits de suppression, qui n'utilise pas la dernière résolution d'horodatage. Par conséquent, la gestion des versions est nécessaire. L'activation de DELETE ALWAYS WINS active automatiquement la gestion des versions, ce qui ajoute une nouvelle colonne masquée KEYVER$$ (numéro de version) de type horodatage. Une nouvelle valeur d'indicateur est également ajoutée à acdrflags_kqldtvc pour indiquer l'utilisation de DELETE ALWAYS WINS. Ce champ est également ajouté à la table DELETE TOMBSTONE. Les mêmes problèmes de gestion des versions existent que la résolution EARLIEST TIMESTAMP.

Exemple :

Version de clé kv et horodatage ts

Base de données 1 : insert tab1 key1 kv1 ts1

Base de données 2 : delete tab1 key1 kv1 ts1

Insertion dans la table DELETE TOMBSTONE key1 kv1 ts1

Base de données 1 : insert tab1 key1 kv2 ts2

Sans utiliser la version de clé, l'insertion serait ignorée, la suppression gagne toujours. Comme la version de clé est utilisée, vous savez que kv2 n'est pas la version de la ligne qui a été supprimée et que l'insertion réussit.

SUPPRIMER la table TOMBSTONE

La table DELETE TOMBSTONE est un marqueur pour un enregistrement supprimé afin de le distinguer d'un enregistrement qui n'a jamais existé. Une table DELETE TOMBSTONE contient au minimum les colonnes de clé et l'horodatage de l'opération. Ces informations sont requises pour supprimer la convergence car certaines mises à jour et insertions entrantes peuvent être retardées à partir d'un autre site et le LCR entrant doit être filtré par rapport à l'horodatage de l'opération de pierre tombale pour déterminer s'il doit être appliqué.

Suivi des mises à jour de clé primaire dans Delete Tombstone

La prise en charge complète des mises à jour de clé primaire (PK) nécessite la gestion des conflits sur les lignes représentées par l'image avant de la clé et sur la ligne représentée par l'image après de la clé. Une mise à jour de clé primaire est une suppression et une insertion autonomes. Par conséquent, les conflits de mise à jour de clé primaire doivent être pris en charge en tant que suppression pour les conflits avec l'image avant de la clé et les insertions avec l'image après de la clé (et de la ligne).

La prise en charge de la mise à jour PK en tant que suppression de la ligne représentée par l'image avant de la clé signifie qu'elle doit être insérée dans la table de suppression de la pierre tombale en tant que suppression. Un déclencheur interne de mise à jour est ajouté pour être inséré dans la table de pierre tombale lorsque la clé primaire est mise à jour (en fait, la clé d'identification de ligne, soit la clé primaire si elle existe, soit le Royaume-Uni choisi avec au moins une colonne non NULL). Comme une mise à jour de clé primaire peut entraîner deux conflits, jusqu'à deux résolutions sont tentées au niveau de la ligne, la suppression de la ligne avec la clé primaire d'origine et l'insertion de la ligne avec la nouvelle clé primaire.

Exemple : utilisation de la dernière résolution d'horodatage

Base de données 1 : mise à jour vers tab1 key1 at ts1

Database 2 : mise à jour vers tab1 key1 set key1 to key2 ts2

Database 3 : mise à jour vers tab1 key2 ts3

Dans ce scénario, il apparaît qu'au niveau ligne, la ligne tab1 avec key1 doit être supprimée et que la mise à jour de la base de données 3 doit être la modification finale de la clé de ligne tab1.

  1. Si, à la place, la base de données 2 se trouve à l'adresse ts3 et la base de données 3 à l'adresse ts3, la mise à jour de clé primaire à la base de données 2 est la modification finale de la ligne tab1 key2.

Maintenant, considérez un cas où la base de données 1 était à ts3, la base de données 2 à ts2 et la base de données 3 à ts1, puis la mise à jour vers la ligne key1 tab1 sur la base de données 1 devrait réussir et la mise à jour de clé primaire à partir de la base de données 2 sur la ligne tab1 key2 devrait réussir. A ce stade, il semble que la résolution complète est que la suppression à l'image avant et l'insertion à l'image après doivent être résolues séparément. Cela implique qu'ils ne sont pas dépendants l'un de l'autre et qu'une perte pour l'un n'est pas une perte pour les deux.

Configuration de la détection et de la résolution de conflits delta

La procédure ADD_AUTO_CDR_DELTA_RES du package DBMS_GOLDENGATE_ADM configure la détection et la résolution des conflits delta.

Avec la résolution des conflits delta, vous indiquez une colonne pour laquelle les conflits sont détectés et résolus. Le conflit est détecté si la valeur de la colonne dans le LCR de ligne ne correspond pas à la valeur correspondante dans la table. Le conflit est résolu en ajoutant la différence entre les nouvelles et les anciennes valeurs du LCR de ligne à la valeur de la table.

Vous pouvez configurer un administrateur Oracle GoldenGate à l'aide de la procédure GRANT_ADMIN_PRIVILEGE du package DBMS_GOLDENGATE_ADM.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure ADD_AUTO_CDR et indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents.

  3. Exécutez la procédure ADD_AUTO_CDR_DELTA_RES et indiquez la colonne sur laquelle la détection et la résolution des conflits delta sont effectuées.

  4. Répétez les étapes précédentes dans chaque instance Oracle AI Database qui réplique la table.

Exemple 9-23 Configuration de la détection et de la résolution delta des conflits pour une table

Cet exemple configure la détection et la résolution des conflits delta pour la colonne order_total de la table oe.orders.

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
    SCHEMA_NAME => 'OE',
    TABLE_NAME  => 'ORDERS');
END;
/

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_DELTA_RES(
    SCHEMA_NAME => 'OE',
    TABLE_NAME  => 'ORDERS',
    COLUMN_NAME => 'ORDER_TOTAL');
END;
/

Configurer la détection et la résolution des conflits de l'horodatage le plus récent

La procédure ADD_AUTO_CDR du package DBMS_GOLDENGATE_ADM configure la détection et la résolution des conflits d'horodatage les plus récents. La procédure ADD_AUTO_CDR_COLUMN_GROUP ajoute des groupes de colonnes facultatifs.

Pour Oracle AI Database 26ai et versions ultérieures, des méthodes supplémentaires existent pour gérer et tenir à jour les tables configurées ACDR. Vous pouvez conserver les colonnes liées à AUTO-CDR sous-jacentes en tant que colonnes UNUSED ou les supprimer immédiatement après l'appel de la procédure REMOVE_AUTO_CDR.

Si vous appliquez la procédure ADD_AUTO_CDR à une table, ses colonnes internes sont marquées comme non utilisées par défaut si AUTO_CDR est enlevé. Après l'appel de REMOVE_AUTO_CDR, les colonnes inutilisées peuvent être supprimées manuellement ultérieurement ou être immédiatement enlevées à l'aide de certains paramètres supplémentaires. Pour plus de détails, reportez-vous à Suppression de la détection et de la résolution des conflits d'une table.

Pour en savoir plus, reportez-vous à ADD_AUTO_CDR Procedure dans le Référence des types et packages PL/SQL Oracle AI Database.

Avec la détection et la résolution des conflits d'horodatage les plus récents, un conflit est détecté lorsque la colonne d'horodatage du LCR de ligne ne correspond pas à l'horodatage de la ligne de table correspondante. Le LCR de ligne est appliqué si son horodatage est postérieur. Sinon, le LCR de ligne est supprimé et la ligne du tableau n'est pas modifiée. Lorsque vous exécutez la procédure ADD_AUTO_CDR, elle ajoute une colonne d'horodatage invisible pour chaque ligne de la table indiquée et configure la détection et la résolution des conflits d'horodatage. Lorsque vous utilisez la procédure ADD_AUTO_CDR_COLUMN_GROUP pour ajouter des groupes de colonnes, elle ajoute un horodatage pour le groupe de colonnes et configure la détection et la résolution des conflits d'horodatage pour le groupe de colonnes.

Vous pouvez configurer un administrateur Oracle GoldenGate à l'aide de la procédure GRANT_ADMIN_PRIVILEGE du package DBMS_GOLDENGATE_ADM.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure ADD_AUTO_CDR et indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents.

  3. Exécutez la procédure ADD_AUTO_CDR_COLUMN_GROUP et indiquez des groupes de colonnes dans la table.

  4. Répétez les étapes précédentes dans chaque instance Oracle AI Database qui réplique la table.

Exemple 9-24 Configuration de la détection et de la résolution des conflits de l'horodatage le plus récent pour une table

Cet exemple configure la détection et la résolution des conflits d'horodatage les plus récents pour la table hr.employees.

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
    SCHEMA_NAME => 'HR',
    TABLE_NAME  => 'EMPLOYEES');
END;
/

Exemple 9-25 Configuration de groupes de colonnes

Cet exemple configure les groupes de colonnes suivants pour la résolution des conflits d'horodatage sur la table HR.EMPLOYEES :

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_COLUMN_GROUP(
    SCHEMA_NAME       => 'HR',
    TABLE_NAME        => 'EMPLOYEES',
    COLUMN_LIST       => 'JOB_ID, DEPARTMENT_ID, MANAGER_ID',
    COLUMN_GROUP_NAME => 'JOB_IDENTIFIER_CG');
END;
/

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_COLUMN_GROUP(
    SCHEMA_NAME       => 'HR',
    TABLE_NAME        => 'EMPLOYEES',
    COLUMN_LIST       => 'SALARY, COMMISSION_PCT',
    COLUMN_GROUP_NAME => 'COMPENSATION_CG');
END;
/

Configuration de la détection et de la résolution de conflits delta

La procédure ADD_AUTO_CDR_DELTA_RES du package DBMS_GOLDENGATE_ADM configure la détection et la résolution des conflits delta.

Avec la résolution des conflits delta, vous indiquez une colonne pour laquelle les conflits sont détectés et résolus. Le conflit est détecté si la valeur de la colonne dans le LCR de ligne ne correspond pas à la valeur correspondante dans la table. Le conflit est résolu en ajoutant la différence entre les nouvelles et les anciennes valeurs du LCR de ligne à la valeur de la table.

Vous pouvez configurer un administrateur Oracle GoldenGate à l'aide de la procédure GRANT_ADMIN_PRIVILEGE du package DBMS_GOLDENGATE_ADM.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure ADD_AUTO_CDR et indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents.

  3. Exécutez la procédure ADD_AUTO_CDR_DELTA_RES et indiquez la colonne sur laquelle la détection et la résolution des conflits delta sont effectuées.

  4. Répétez les étapes précédentes dans chaque instance Oracle AI Database qui réplique la table.

Exemple 9-26 Configuration de la détection et de la résolution delta des conflits pour une table

Cet exemple configure la détection et la résolution des conflits delta pour la colonne order_total de la table oe.orders.

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
    SCHEMA_NAME => 'OE',
    TABLE_NAME  => 'ORDERS');
END;
/

BEGIN
  DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_DELTA_RES(
    SCHEMA_NAME => 'OE',
    TABLE_NAME  => 'ORDERS',
    COLUMN_NAME => 'ORDER_TOTAL');
END;
/

Gestion de la détection et de la résolution automatiques de conflits

Vous pouvez gérer la détection et la résolution automatiques des conflits Oracle GoldenGate dans Oracle AI Database avec le package DBMS_GOLDENGATE_ADM.

Modification de la détection et de la résolution de conflits pour une table

La procédure ALTER_AUTO_CDR du package DBMS_GOLDENGATE_ADM modifie la détection et la résolution des conflits pour une table.

La détection et la résolution automatiques des conflits Oracle GoldenGate doivent être configurées pour la table :

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure ALTER_AUTO_CDR et indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents.

  3. Répétez toutes les étapes précédentes dans chaque base de données Oracle AI Database qui réplique la table.

Exemple 9-27 Modification de la détection et de la résolution de conflits pour une table

Cet exemple modifie la détection et la résolution des conflits pour la table HR.EMPLOYEES afin d'indiquer que les conflits de suppression sont suivis dans une table de pierre tombale.

BEGIN
  DBMS_GOLDENGATE_ADM.ALTER_AUTO_CDR(
    SCHEMA_NAME       => 'HR',
    TABLE_NAME        => 'EMPLOYEES',
    TOMBSTONE_DELETES => TRUE);
END;
/

Modification d'un groupe de colonnes

La procédure ALTER_AUTO_CDR_COLUMN_GROUP modifie un groupe de colonnes.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure ALTER_AUTO_CDR_COLUMN_GROUP et indiquez des groupes de colonnes dans la table.

  3. Répétez toutes les étapes précédentes dans chaque base de données Oracle AI Database qui réplique la table.

Exemple 9-28 Modification d'un groupe de colonnes

Cet exemple enlève la colonne MANAGER_ID du groupe de colonnes JOB_IDENTIFIER_CG pour la table HR.EMPLOYEES.

BEGIN
  DBMS_GOLDENGATE_ADM.ALTER_AUTO_CDR_COLUMN_GROUP(
    SCHEMA_NAME        => 'HR',
    TABLE_NAME         => 'EMPLOYEES',
    COLUMN_GROUP_NAME  => 'JOB_IDENTIFIER_CG',
    REMOVE_COLUMN_LIST => 'MANAGER_ID');
END;
/

Remarque : s'il existe plusieurs colonnes, utilisez une liste séparée par des virgules.

Purge des lignes de pierre tombale

La procédure PURGE_TOMBSTONES supprime les lignes de pierre tombale qui ont été enregistrées avant une date et une heure spécifiées. Cette procédure supprime les lignes de pierre tombale de toutes les tables configurées pour la résolution des conflits dans la base de données.

Il peut être nécessaire de purger périodiquement les rangées de pierre tombale pour éviter que la pierre tombale ne devienne trop grande au fil du temps.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure PURGE_TOMBSTONES et indiquez la date et l'heure.

Exemple 9-29 Purge des lignes de pierre tombale

Cet exemple purge toutes les lignes de pierre tombale enregistrées avant 3h00 le 1er décembre 2015 à l'heure normale de l'Est. L'horodatage doit être saisi au format TIMESTAMP WITH TIME ZONE.

EXEC DBMS_GOLDENGATE_ADM.PURGE_TOMBSTONES('2015-12-01 15:00:00.000000 EST');

Redéfinition en ligne sur les tables ACDR

Oracle AI Database permet d'atténuer les interactions entre les applications lors de la réorganisation de tables ou de colonnes à l'aide du package DBMS_REDEFINITION. Le package DBMS_REDEFINITION peut être utilisé pour effectuer les tâches suivantes :

DBMS_REDFINITION.START_REDEF_TABLE gère automatiquement la colonne d'horodatage masqué dans la table temporaire.

Pour plus d'informations sur le package DBMS_REDFINITION, reportez-vous à DBMS_REDEFINITION dans le manuel Référence des types et packages PL/SQL Oracle AI Database.

Suppression de la détection et de la résolution de conflits d'une table

Avec Oracle AI Database et les versions ultérieures, la suppression complète d'ACDR (Automatic Conflict Detection and Resolution) de la table a un impact moindre sur la table car les colonnes liées à AUTO_CDR sont marquées comme UNUSED si AUTO_CDR est enlevé.

Après l'appel de la procédure REMOVE_AUTO_CDR, les colonnes non utilisées peuvent être supprimées manuellement dans une fenêtre de maintenance. Cela est utile pour les tables volumineuses où l'opération ALTER TABLE ... DROP COLUMN nécessite beaucoup de ressources.

Pour enlever immédiatement toutes les colonnes internes AUTO_CDR lors de l'appel de la procédure REMOVE_AUTO_CDR, vous devez d'abord marquer la table à l'aide du paramètre additional_options REMOVE_HIDDEN_COLUMNS pour la procédure ADD_AUTO_CDR ou ALTER_AUTO_CDR.

Utilisez la procédure REMOVE_AUTO_CDR du package DBMS_GOLDENGATE_ADM pour baliser une table en tant que UNUSED, ce qui réduit le blocage. Vous pouvez choisir de supprimer une colonne ou de la conserver ultérieurement.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure REMOVE_AUTO_CDR et indiquez la table.

  3. Répétez toutes les étapes précédentes dans chaque instance Oracle AI Database qui réplique la table.

Exemple 9-30 Suppression de la détection et de la résolution de conflits pour une table

Cet exemple supprime la détection et la résolution des conflits pour la table HR.EMPLOYEES.

BEGIN
  DBMS_GOLDENGATE_ADM.REMOVE_AUTO_CDR(
    SCHEMA_NAME => 'HR',
    TABLE_NAME  => 'EMPLOYEES');
END;
/

Vous pouvez choisir de supprimer des colonnes en utilisant l'indicateur ADD_AUTO_CDR.REMOVE_HIDDEN_COLUMNS en tant que paramètre additional_flags dans la procédure ADD_AUTO_CDR.

Voici un exemple que vous pouvez utiliser pour afficher les colonnes masquées d'une table.

La requête suivante utilise le package DBA_UNUSED_COL_TABS pour déterminer si des colonnes non utilisées figurent dans la table EMPLOYEES.

SELECT OWNER, TABLE_NAME, COUNT
  FROM DBA_UNUSED_COL_TABS
  WHERE OWNER = 'HR'
  AND TABLE_NAME = 'EMPLOYEES'
  ORDER BY OWNER, TABLE_NAME;

La sortie s'affiche comme suit :

OWNER        TABLE_NAME    COUNT
--------    ------------ ----------
HR            EMPLOYEES      1

La requête suivante répertorie les colonnes masquées qui ont été balisées par le système lors de la suppression de l'ACDR pour le groupe de colonnes dans la table EMPLOYEES.

SELECT OWNER, TABLE_NAME, COLUMN_ID, COLUMN_NAME, DATA_TYPE, HIDDEN_COLUMN
  FROM DBA_TAB_COLS
  WHERE OWNER = 'HR'
  AND TABLE_NAME = 'EMPLOYEES'
  AND HIDDEN_COLUMN = 'YES' AND USER_GENERATED= 'NO'
  ORDER BY OWNER, TABLE_NAME, COLUMN_ID;

La sortie s'affiche comme suit :

OWNER        TABLE_NAME    COLUMN_ID  COLUMN_NAME      DATA_TYPE     HIDDEN_COLUMN
------------ ------------ ---------- -------------    ------------ ---------------
HR           EMPLOYEES    SYS_C00014_22092220:30:52$   TIMESTAMP(6)       YES

Suppression d'un groupe de colonnes

Avec Oracle AI Database 26ai et versions ultérieures, la suppression de la détection et de la résolution automatiques des conflits (ACDR) des groupes de colonnes a un impact moindre sur la table car les colonnes associées à l'ACDR sont marquées comme UNUSED. Vous pouvez également choisir de supprimer une colonne ou de la conserver ultérieurement.

Utilisez la procédure REMOVE_AUTO_CDR_COLUMN_GROUP du package DBMS_GOLDENGATE_ADM pour baliser une table, ce qui réduit le blocage. Reportez-vous à l'exemple de la section Removing Conflict Detection and Resolution From a Table.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure REMOVE_AUTO_CDR_COLUMN_GROUP et indiquez le nom du groupe de colonnes.

  3. Répétez toutes les étapes précédentes dans chaque base de données Oracle AI Database qui réplique la table.

Exemple 9-31 Suppression d'un groupe de colonnes

Cet exemple enlève le groupe de colonnes COMPENSATION_CG de la table HR.EMPLOYEES.

BEGIN
  DBMS_GOLDENGATE_ADM.REMOVE_AUTO_CDR_COLUMN_GROUP(
    SCHEMA_NAME       => 'HR',
    TABLE_NAME        => 'EMPLOYEES',
    COLUMN_GROUP_NAME => 'COMPENSATION_CG');
END;

Suppression de la détection et de la résolution de conflits delta

La procédure REMOVE_AUTO_CDR_DELTA_RES du package DBMS_GOLDENGATE_ADM supprime la détection et la résolution des conflits delta pour une colonne.

La détection et la résolution des conflits delta doivent être configurées pour la colonne indiquée.

  1. Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.

  2. Exécutez la procédure REMOVE_AUTO_CDR_DELTA_RES et indiquez la colonne.

  3. Répétez toutes les étapes précédentes dans chaque base de données Oracle AI Database qui réplique la table.

Exemple 9-32 Suppression de la détection et de la résolution de conflits Delta pour une table

Cet exemple supprime la détection et la résolution des conflits delta pour la colonne ORDER_TOTAL dans la table OE.ORDERS.

BEGIN
  DBMS_GOLDENGATE_ADM.REMOVE_AUTO_CDR_DELTA_RES(
    SCHEMA_NAME => 'OE',
    TABLE_NAME  => 'ORDERS',
    COLUMN_NAME => 'ORDER_TOTAL');
END;

Surveillance de la détection et de la résolution automatiques de conflits

Vous pouvez surveiller la détection et la résolution automatiques des conflits Oracle GoldenGate dans une base de données Oracle AI Database en interrogeant les vues du dictionnaire de données.

Affichage d'informations sur les tables configurées pour les conflits

La vue ALL_GG_AUTO_CDR_TABLES affiche des informations sur les tables configurées pour la détection et la résolution automatiques des conflits Oracle GoldenGate.

  1. Connexion à la base de données.

  2. Interrogez la vue ALL_GG_AUTO_CDR_TABLES.

Exemple 9-33 Affichage des informations sur les tables configurées pour la détection et la résolution des conflits

Cette requête affiche les informations suivantes sur les tables configurées pour la détection et la résolution des conflits :

COLUMN TABLE_OWNER FORMAT A15
COLUMN TABLE_NAME FORMAT A15
COLUMN TOMBSTONE_TABLE FORMAT A15
COLUMN ROW_RESOLUTION_COLUMN FORMAT A25

SELECT TABLE_OWNER,
       TABLE_NAME,
       TOMBSTONE_TABLE,
       ROW_RESOLUTION_COLUMN
  FROM ALL_GG_AUTO_CDR_TABLES
  ORDER BY TABLE_OWNER, TABLE_NAME;

Le résultat obtenu est similaire à ce qui suit :

TABLE_OWNER     TABLE_NAME      TOMBSTONE_TABLE ROW_RESOLUTION_COLUMN
--------------- --------------- --------------- -------------------------
HR              EMPLOYEES       DT$_EMPLOYEES   CDRTS$ROW
OE              ORDERS          DT$_ORDERS      CDRTS$ROW

Affichage d'informations sur les colonnes de résolution de conflits

La vue ALL_GG_AUTO_CDR_COLUMNS affiche des informations sur les colonnes configurées pour la détection et la résolution automatiques des conflits Oracle GoldenGate.

Les colonnes peuvent être configurées pour la détection et la résolution automatiques des conflits de lignes ou de colonnes. Les colonnes peuvent être configurées pour la résolution du conflit d'horodatage le plus récent dans un groupe de colonnes. En outre, une colonne peut être configurée pour la résolution de conflits delta.

  1. Connectez-vous à la base de données en tant qu'administrateur Oracle GoldenGate.

  2. Interrogez la vue ALL_GG_AUTO_CDR_COLUMNS.

Exemple 9-34 Affichage d'informations sur les groupes de colonnes

Cette requête affiche les informations suivantes sur les tables configurées pour la détection et la résolution des conflits :

COLUMN TABLE_OWNER FORMAT A10
COLUMN TABLE_NAME FORMAT A10
COLUMN COLUMN_GROUP_NAME FORMAT A17
COLUMN COLUMN_NAME FORMAT A15
COLUMN RESOLUTION_COLUMN FORMAT A23

SELECT TABLE_OWNER,
       TABLE_NAME,
       COLUMN_GROUP_NAME,
       COLUMN_NAME,
       RESOLUTION_COLUMN
  FROM ALL_GG_AUTO_CDR_COLUMNS
  ORDER BY TABLE_OWNER, TABLE_NAME;

Le résultat obtenu est similaire à ce qui suit :

TABLE_OWNE TABLE_NAME COLUMN_GROUP_NAME COLUMN_NAME     RESOLUTION_COLUMN
---------- ---------- ----------------- --------------- -----------------------
HR         EMPLOYEES  COMPENSATION_CG   COMMISSION_PCT  CDRTS$COMPENSATION_CG
HR         EMPLOYEES  COMPENSATION_CG   SALARY          CDRTS$COMPENSATION_CG
HR         EMPLOYEES  JOB_IDENTIFIER_CG MANAGER_ID      CDRTS$JOB_IDENTIFIER_CG
HR         EMPLOYEES  JOB_IDENTIFIER_CG JOB_ID          CDRTS$JOB_IDENTIFIER_CG
HR         EMPLOYEES  JOB_IDENTIFIER_CG DEPARTMENT_ID   CDRTS$JOB_IDENTIFIER_CG
HR         EMPLOYEES  IMPLICIT_COLUMNS$ PHONE_NUMBER    CDRTS$ROW
HR         EMPLOYEES  IMPLICIT_COLUMNS$ LAST_NAME       CDRTS$ROW
HR         EMPLOYEES  IMPLICIT_COLUMNS$ HIRE_DATE       CDRTS$ROW
HR         EMPLOYEES  IMPLICIT_COLUMNS$ FIRST_NAME      CDRTS$ROW
HR         EMPLOYEES  IMPLICIT_COLUMNS$ EMAIL           CDRTS$ROW
HR         EMPLOYEES  IMPLICIT_COLUMNS$ EMPLOYEE_ID     CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ ORDER_MODE      CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ ORDER_ID        CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ ORDER_DATE      CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ CUSTOMER_ID     CDRTS$ROW
OE         ORDERS     DELTA$            ORDER_TOTAL
OE         ORDERS     IMPLICIT_COLUMNS$ PROMOTION_ID    CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ ORDER_STATUS    CDRTS$ROW
OE         ORDERS     IMPLICIT_COLUMNS$ SALES_REP_ID    CDRTS$ROW

Dans cet exemple, les colonnes dont le nom de groupe de colonnes est IMPLICIT_COLUMNS$ sont configurées pour la détection et la résolution des conflits de lignes, mais ne font pas partie d'un groupe de colonnes. Les colonnes avec DELTA$ pour le nom du groupe de colonnes sont configurées pour la détection et la résolution des conflits delta, et ces colonnes n'ont pas de colonne de résolution.

Affichage des informations sur les groupes de colonnes

La vue ALL_GG_AUTO_CDR_COLUMN_GROUPS affiche des informations sur les groupes de colonnes configurés pour la détection et la résolution automatiques des conflits Oracle GoldenGate.

Vous pouvez configurer la détection et la résolution automatiques des conflits Oracle GoldenGate à l'aide de la procédure ADD_AUTO_CDR du package DBMS_GOLDENGATE_ADM. Vous pouvez configurer des groupes de colonnes à l'aide de la procédure ADD_AUTO_CDR_COLUMN_GROUP du package DBMS_GOLDENGATE_ADM.

  1. Connectez-vous à la base de données en tant qu'administrateur Oracle GoldenGate.

  2. Interrogez la vue ALL_GG_AUTO_CDR_COLUMN_GROUPS.

Exemple 9-35 Affichage d'informations sur les groupes de colonnes

Cette requête affiche les informations suivantes sur les tables configurées pour la détection et la résolution des conflits :

COLUMN TABLE_OWNER FORMAT A15
COLUMN TABLE_NAME FORMAT A15
COLUMN COLUMN_GROUP_NAME FORMAT A20
COLUMN RESOLUTION_COLUMN FORMAT A25

SELECT TABLE_OWNER,
       TABLE_NAME,
       COLUMN_GROUP_NAME,
       RESOLUTION_COLUMN
  FROM ALL_GG_AUTO_CDR_COLUMN_GROUPS
  ORDER BY TABLE_OWNER, TABLE_NAME;

Vous pouvez obtenir une sortie similaire à la suivante :

TABLE_OWNER     TABLE_NAME      COLUMN_GROUP_NAME    RESOLUTION_COLUMN
--------------- --------------- -------------------- -------------------------
HR              EMPLOYEES       COMPENSATION_CG      CDRTS$COMPENSATION_CG
HR              EMPLOYEES       JOB_IDENTIFIER_CG    CDRTS$JOB_IDENTIFIER_CG