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 :
-
EARLIEST_TIMESTAMP_RESOLUTIONdéfinitTOMBSTONE KEY VERSIONINGautomatiquement -
DELETE_ALWAYS_WINSdéfinitTOMBSTONE KEY VERSIONINGautomatiquement. -
IGNORE_SITE_PRIORITY
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 :
-
Oracle AI Database crée et gère automatiquement des colonnes d'horodatage invisibles.
-
Les insertions, mises à jour et suppressions utilisent la table de journalisation de suppression de pierre tombale pour déterminer si une ligne a été supprimée.
-
Des conflits de colonne LOB peuvent être détectés.
-
Oracle AI Database configure automatiquement la journalisation supplémentaire sur les colonnes requises.
Conseil :
Pour plus d'informations sur la journalisation supplémentaire, reportez-vous également aux utilitaires Oracle AI Database.
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 :
-
Une journalisation supplémentaire est requise pour garantir que chaque LCR de ligne dispose des informations requises pour détecter et résoudre un conflit. La journalisation supplémentaire place des informations supplémentaires dans le fichier de journalisation pour les colonnes d'une table lorsqu'une opération LMD est effectuée sur la table. Lorsque vous configurez une table pour la détection et la résolution des conflits Oracle GoldenGate, la journalisation supplémentaire est configurée automatiquement pour toutes les colonnes de la table. Les informations supplémentaires du fichier de journalisation sont placées dans un LCR lorsqu'une modification de table est répliquée.
L'extraction doit être utilisée pour la capture. Le processus Replicat intégré ou le processus Replicat parallèle en mode intégré doit être utilisé côté application.
LOGALLSUPCOLSdoit rester la valeur par défaut. -
Un champ masqué
KEYVER$$de type horodatage est éventuellement ajouté à la tableDELETE TOMBSTONE. Ce champ est obligatoire pour les résolutionsEARLIEST TIMESTAMP,DELETE ALWAYS WINSetSITE PRIORITY. Il existe également dans la table de base. L'existence du champ dans la table de base doit être indiquée dans les métadonnées du fichier trace en tant qu'indicateur ou jeton.Les mises à jour de clé primaire sont également prises en charge dans la table
DELETE TOMBSTONE. Une entrée est insérée dans la tableDELETE TOMBSTONEpour la ligne de la valeur de clé d'origine (avant l'image). La logique de l'extraction, qui met en correspondance INSERTS dans la tableDELETE TOMBSTONEet DELETES, doit également être mise en correspondance avec les mises à jour de clé primaire, ou avec la clé unique (UK) avec au moins un champ non NULL, s'il n'y a pas de clé primaire. -
SITE PRIORITYdoit être pris en charge par le processus Replicat avant que les paramètres ne soient implémentés et que le paramètre ne soit transmis au processus Replicat. -
La fonction CDR automatique ne fonctionne pas avec les autres exceptions de niveau
MAPet configurations de traitement des erreurs, telles queREPERRORetMAPEXCEPTION. Vous pouvez utiliser la fonction CDR automatique ouREPERROR/MAPEXCEPTION, mais pas les deux sur la même table. Pour en savoir plus, reportez-vous àTABLE \| MAPet àREPERROR.
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

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 :
-
Un groupe de colonnes inclut la colonne
Office. La colonne d'horodatage invisible pour ce groupe de colonnes estTS1. -
Un autre groupe de colonnes inclut les colonnes
TitleetSalary. La colonne d'horodatage invisible pour ce groupe de colonnes estTS2.
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 :
-
Dans la base de données A, la valeur de
Officeest passée de1080à1030. -
Dans la base de données B, la valeur de
Titleest passée deMTS1àMTS2.
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 :
-
Si l'horodatage du groupe de colonnes de l'objet LOB est postérieur au groupe de colonnes de l'objet LOB correspondant dans la ligne, la mise à jour de l'objet LOB par morceaux est appliquée.
-
Si l'horodatage du groupe de colonnes de l'objet LOB est antérieur au groupe de colonnes de l'objet LOB correspondant dans la ligne, l'objet LOB dans la ligne de la table est conservé.
-
Si la ligne n'existe pas dans la table, une erreur est générée.
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 :
-
ADD_AUTO_CDR() -
ADD_AUTO_CDR_COLUMN_GROUP() -
REMOVE_AUTO_CDR() -
REMOVE_AUTO_CDR_COLUMN_GROUP() -
ALTER_AUTO_CDR() -
ALTER_AUTO_CDR_COLUMN_GROUP()
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 :
|
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 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 |
DELETE |
Un conflit est détecté dans chacun des cas suivants :
|
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 : 
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.
-
Dans la base de données A, la valeur de la colonne
Officeest mise à jour de 1080 à 1103 et la valeur RowTS passe de @TS10 à @TS20. Une flèche indique que cette modification est répliquée dans la base de données B. -
Dans la base de données B, la valeur de la colonne
Titlepasse de MTS1 à MTS2 et la valeur RowTS passe de @TS10 à @TS22. -
Pour résoudre ce conflit, le dernier horodatage qui existe dans la base de données B est gagnant. Cela signifie que les modifications apportées à la base de données A ne sont pas appliquées. Les valeurs finales appliquées à la base de données A et à la base de données B sont Scott, @TS22, 1080, MTS2, 100.
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

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 :
-
Dans la base de données A, la valeur de
Balanceest passée de1000à1750. La valeur a donc été augmentée de 750. -
Dans la base de données B, la valeur de
Balanceest passée de1000à950. La valeur a donc été diminuée de 50. -
Pour résoudre le conflit au niveau de la base de données A, la valeur de la différence entre les nouvelles et les anciennes valeurs de la ligne LCR par rapport à la valeur de la table. La différence entre les nouvelles et les anciennes valeurs dans le LCR est (1000+750-50=1700). La valeur actuelle de la table est augmentée de 700, de sorte que la valeur après résolution des conflits est 1700.
-
Pour résoudre le conflit au niveau de la base de données B, la valeur de la différence entre les nouvelles et les anciennes valeurs de la ligne LCR par rapport à la valeur de la table. La différence entre les nouvelles et les anciennes valeurs dans le LCR est de 750 (1000 - 50 + 750) = 1700. Par conséquent, la valeur actuelle dans le tableau (950) est augmentée de 750 de sorte que la valeur après résolution de conflit est 1700.
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.
- Si, à la place, la base de données 2 se trouve à l'adresse
ts3et la base de données 3 à l'adressets3, la mise à jour de clé primaire à la base de données 2 est la modification finale de la lignetab1key2.
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
ADD_AUTO_CDRet indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents. -
Exécutez la procédure
ADD_AUTO_CDR_DELTA_RESet indiquez la colonne sur laquelle la détection et la résolution des conflits delta sont effectuées. -
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
ADD_AUTO_CDRet indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents. -
Exécutez la procédure
ADD_AUTO_CDR_COLUMN_GROUPet indiquez des groupes de colonnes dans la table. -
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 :
-
Le groupe de colonnes
JOB_IDENTIFIER_CGinclut les colonnesJOB_ID,DEPARTMENT_IDetMANAGER_ID. -
Le groupe de colonnes
COMPENSATION_CGinclut les colonnesSALARYetCOMMISSION_PCT.
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
ADD_AUTO_CDRet indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents. -
Exécutez la procédure
ADD_AUTO_CDR_DELTA_RESet indiquez la colonne sur laquelle la détection et la résolution des conflits delta sont effectuées. -
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 :
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
ALTER_AUTO_CDRet indiquez la table à configurer pour la détection et la résolution des conflits d'horodatage les plus récents. -
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
ALTER_AUTO_CDR_COLUMN_GROUPet indiquez des groupes de colonnes dans la table. -
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
PURGE_TOMBSTONESet 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 :
-
Supprimez les colonnes inutilisées.
-
Réorganisation, conception de tablespace et partitionnement.
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
REMOVE_AUTO_CDRet indiquez la table. -
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
REMOVE_AUTO_CDR_COLUMN_GROUPet indiquez le nom du groupe de colonnes. -
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.
-
Connectez-vous à la base de données du serveur entrant en tant qu'administrateur Oracle GoldenGate.
-
Exécutez la procédure
REMOVE_AUTO_CDR_DELTA_RESet indiquez la colonne. -
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.
-
Connexion à la base de données.
-
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 :
-
Propriétaire de la table pour chaque table.
-
Nom de la table pour chaque table.
-
Table de pierre tombale utilisée pour stocker les lignes supprimées pour les conflits de mise à jour-suppression, si une table de pierre tombale est configurée pour la table.
-
Colonne d'horodatage masquée utilisée pour la résolution des conflits pour chaque table.
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.
-
Connectez-vous à la base de données en tant qu'administrateur Oracle GoldenGate.
-
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 :
-
Propriétaire de la table pour chaque table.
-
Nom de la table pour chaque table.
-
Si la colonne se trouve dans un groupe de colonnes, nom du groupe de colonnes.
-
Nom de la colonne.
-
Si la colonne est configurée pour la résolution du conflit d'horodatage le plus récent, nom de la colonne d'horodatage masquée pour la colonne.
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.
-
Connectez-vous à la base de données en tant qu'administrateur Oracle GoldenGate.
-
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 :
-
Propriétaire de la table.
-
Nom de la table.
-
Nom du groupe de colonnes.
-
Colonne d'horodatage masquée utilisée pour la résolution des conflits pour chaque groupe de colonnes.
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