Détection et résolution manuelles de conflits

Découvrez comment configurer manuellement la détection et la résolution des conflits (CDR) à l'aide de paramètres spécifiques. La détection et la résolution des conflits sont requises dans les configurations actives-actives, où Oracle GoldenGate doit maintenir la synchronisation des données entre plusieurs bases de données contenant les mêmes ensembles de données.

Présentation de la fonctionnalité CDR d'Oracle GoldenGate

La fonction CDR (Conflict Detection and Resolution) d'Oracle GoldenGate comporte deux parties : la détection des conflits et la résolution des conflits. Avant de commencer par la résolution des conflits, il est important d'enquêter et de terminer la détection des conflits.

Oracle GoldenGate Conflict Detection and Resolution (CDR) fournit des routines de base de résolution des conflits qui :

Résolvez un conflit d'unicité pour INSERT.
Résolvez un conflit "aucune donnée trouvée" pour UPDATE lorsque la ligne existe, mais l'image "avant" d'au moins une colonne est différente de la valeur en cours dans la base de données.
Résolvez un conflit "aucune donnée trouvée" pour une valeur UPDATE lorsque la ligne n'existe pas.
Résolvez un conflit "aucune donnée trouvée" pour DELETE lorsque la ligne existe, mais l'image "avant" d'une ou plusieurs colonnes est différente de la valeur en cours dans la base de données.
Résolvez un conflit "aucune donnée trouvée" pour une valeur DELETE lorsque la ligne n'existe pas.

Pour utiliser la détection et la résolution des conflits (CDR), la base de données cible doit résider sur un système Windows, Linux ou UNIX. Elle n'est pas prise en charge pour les bases de données sur la plate-forme NonStop.

CDR prend en charge les types de données scalaires tels que :

NUMERIC
BOOLEAN
DATE
TIMESTAMP
CHAR/NCHAR
VARCHAR/ NVARCHAR

Cela signifie que ces types de colonne peuvent être utilisés avec le paramètre COMPARECOLS et en tant que colonne de résolution dans les options USEMIN et USEMAX du paramètre RESOLVECONFLICT. Seules les colonnes NUMERIC peuvent être utilisées pour l'option USEDELTA de RESOLVECONFLICT. Pour USEMAX, USEMIN, seules TIMESTAMP et NUMBER sont prises en charge.

La résolution des conflits n'est pas effectuée lorsque le processus Replicat fonctionne en mode BATCHSQL. Si un conflit se produit en mode BATCHSQL, le processus de réplication revient en mode GROUPTRANSOPS, puis en mode transaction unique. La détection des conflits se produit dans les trois modes.

Configurer les fichiers de paramètres Oracle GoldenGate pour la résolution des conflits

Les paramètres suivants sont requis pour la prise en charge de la détection et de la résolution des conflits.

Utilisez l'option COMPARECOLS du paramètre MAP dans le fichier de paramètres de réplication pour indiquer les colonnes à utiliser avec les valeurs "avant" dans la clause WHERE du processus de réplication. Les valeurs "avant" sont comparées aux valeurs en cours dans la base de données cible pour détecter les conflits de mise à jour et de suppression. (Par défaut, le processus Replicat utilise uniquement la clé primaire dans la clause WHERE ; cela peut ne pas être suffisant pour la détection des conflits).
Utilisez l'option RESOLVECONFLICT du paramètre MAP pour indiquer des routines de résolution de conflit pour différentes opérations et différents types de conflit. Vous pouvez utiliser RESOLVECONFLICT plusieurs fois dans une instruction MAP pour indiquer différentes résolutions pour différents types de conflit. Toutefois, vous ne pouvez pas utiliser RESOLVECONFLICT plusieurs fois pour le même type de conflit. Utilisez des procédures de résolution de conflit identiques sur toutes les bases de données, de sorte que le même conflit produise le même résultat final. Une méthode de résolution de conflit peut ne pas fonctionner pour chaque conflit qui pourrait se produire. Vous devrez peut-être créer plusieurs routines qui peuvent être appelées dans un ordre logique de priorité afin de minimiser le risque d'échec.

Remarque : une attention supplémentaire doit être accordée lorsqu'une table comporte une clé primaire et des index uniques ou des clés uniques supplémentaires. Les routines automatisées fournies avec les paramètres COMPARECOLS et RESOLVECONFLICT nécessitent un moyen cohérent d'identifier chaque ligne de manière unique. Si une ligne n'est pas identifiée de manière cohérente, une erreur se produit lors de la résolution des conflits. Dans ce cas, les clés uniques supplémentaires doivent être désactivées ou vous pouvez utiliser la fonctionnalité SQLEXEC pour gérer l'erreur générée et résoudre le conflit.

Pour plus d'informations sur ces paramètres, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate. Pour plus d'informations sur ces paramètres, reportez-vous aux exemples commençant à la section CDR Example 1 : All Conflict Types with USEMAX, OVERWRITE, DISCARD.

Rendre les valeurs de colonne requises disponibles pour l'extraction

Pour utiliser CDR, les valeurs de colonne suivantes doivent être consignées afin que le processus Extract puisse les écrire dans la trace (trail).

Image complète avant chaque enregistrement. Certaines bases de données ne fournissent pas d'image before dans l'enregistrement de journal et doivent être configurées pour ce faire avec la journalisation supplémentaire. Pour la plupart des bases de données prises en charge, vous pouvez utiliser la commande ADD TRANDATA à cette fin.
Utilisez le paramètre LOGALLSUPCOLS pour vous assurer que les images complètes avant et après des colonnes de programmation sont écrites dans la trace. Les colonnes de planification sont des colonnes de clé primaire, d'index unique et de clé étrangère. LOGALLSUPCOLS fait en sorte que le processus Extract inclue dans la trace l'image "avant" pour les opérations UPDATE et l'image "avant" de toutes les colonnes journalisées supplémentaires pour les opérations UPDATE et DELETE.

Pour plus d'informations sur ces paramètres et commandes, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate. Reportez-vous aux exemples commençant à la section CDR Example 1 : All Conflict Types with USEMAX, OVERWRITE, DISCARD pour plus d'informations sur le fonctionnement de ces paramètres avec CDR.

Afficher les statistiques CDR

La fonction CDR fournit les méthodes suivantes pour afficher les résultats de la résolution des conflits.

Voici différentes techniques que vous pouvez utiliser pour afficher les statistiques CDR.

Fichier d'état

Le processus Replicat écrit les statistiques CDR dans le fichier de rapport :

Total CDR conflicts        7
    CDR resolutions succeeded       6
    CDR resolutions failed          1
    CDR INSERTROWEXISTS conflicts   1
    CDR UPDATEROWEXISTS conflicts   4
    CDR UPDATEROWMISSING conflicts
    CDR DELETEROWEXISTS conflicts      1
    CDR DELETEROWMISSING conflicts     1

Ligne de commande

Vous pouvez afficher les statistiques CDR à partir de la ligne de commande en utilisant la commande STATS REPLICAT avec l'option REPORTCDR :

STATS REPLICAT *group*, REPORTCDR

Fonctions de conversion de colonne

Les statistiques CDR suivantes peuvent être extraites et mises en correspondance avec une table d'exceptions ou utilisées dans d'autres paramètres Oracle GoldenGate qui acceptent les entrées des fonctions de conversion de colonne, le cas échéant.

Nombre de conflit détectés par la réplication
Nombre de résolutions résolues par le processus Replicat
Nombre de résolutions que la réplication n'a pas pu résoudre

Pour extraire ces statistiques, utilisez la fonction de conversion de colonne @GETENV avec le type d'informations STATS ou DELTASTATS. Les résultats sont basés sur la session Replicat en cours. Si le processus Replicat s'arrête et redémarre, il réinitialise les statistiques.

Vous pouvez renvoyer les statistiques suivantes pour une table ou un ensemble spécifique de tables avec caractères génériques :

@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_CONFLICTS')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_FAILED')

Vous pouvez renvoyer les statistiques suivantes pour toutes les tables dans toutes les instructions MAP du fichier de paramètres Replicat :

@GETENV ('STATS','CDR_CONFLICTS')
@GETENV ('STATS','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','CDR_RESOLUTIONS_FAILED')

Le type d'informations 'STATS' dans les exemples précédents peut être remplacé par 'DELTASTATS' pour renvoyer les nombres demandés depuis la dernière exécution de 'DELTASTATS'. Pour plus d'informations sur @GETENV, reportez-vous à @GETENV

CDR - Exemple 1 : tous les types de conflit avec USEMAX, OVERWRITE, DISCARD

Cet exemple résout tous les types de conflit à l'aide des résolutions USEMAX, OVERWRITE et DISCARD.

Table utilisée dans cet exemple

Les exemples supposent des bases de données Oracle identiques.

CREATE TABLE hr.emp_tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Dans la base de données source, toutes les colonnes sont journalisées de manière supplémentaire :

ADD TRANDATA hr.emp_src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Déclaration MAP avec spécifications de résolution des conflits

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
    RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)),
    );

Description de la déclaration MAP

L'instruction MAP est décrite ci-dessous :

Pour COMPARECOLS, utilisez l'image "avant" de toutes les colonnes de l'enregistrement de trace dans la clause WHERE de réplication pour les mises à jour et les suppressions.
Par DEFAULT, utilisez toutes les colonnes comme groupe de colonnes pour tous les types de conflit. Par conséquent, la résolution s'applique à toutes les colonnes.
Pour un conflit INSERTROWEXISTS, utilisez la résolution USEMAX : si la ligne existe lors d'une insertion, utilisez la colonne last_mod_time comme colonne de résolution pour décider quelle est la valeur la plus élevée : la valeur dans la trace ou celle de la base de données. Si la valeur de la trace est supérieure, appliquez l'enregistrement mais remplacez l'insertion par une mise à jour. Si la valeur de la base de données est supérieure, ignorez l'enregistrement.
Pour un conflit UPDATEROWEXISTS, utilisez la résolution USEMAX : si la ligne existe au cours d'une mise à jour, utilisez la colonne last_mod_time comme colonne de résolution : si la valeur de la trace est supérieure, appliquez la mise à jour.
Si vous utilisez USEMIN ou USEMAX et que les valeurs sont exactement les mêmes, RESOLVECONFLICT n'est pas déclenché et la ligne entrante est ignorée. Si vous utilisez USEMINEQ ou USEMAXEQ, et que les valeurs sont exactement les mêmes, la résolution est déclenchée.
Pour un conflit DELETEROWEXISTS, utilisez la résolution OVERWRITE : si la ligne existe au cours d'une opération de suppression, appliquez la suppression.
Pour un conflit UPDATEROWMISSING, utilisez la résolution OVERWRITE : si la ligne n'existe pas au cours d'une mise à jour, remplacez la mise à jour par une insertion et appliquez-la.
Pour un conflit DELETROWMISSING, utilisez la résolution DISCARD : si la ligne n'existe pas au cours d'une opération de suppression, ignorez l'enregistrement de trace.

Remarque : au lieu de USEMAX, vous pouvez utiliser la résolution USEMAXEQ pour appliquer une condition >=. Pour plus d'informations, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.

INSERTROWEXISTS avec la résolution USEMAX

Dans cet exemple, la résolution USEMAX est illustrée avec les images avant et après applicables pour l'enregistrement dans la trace (trail) et dans la base de données. Il montre comment résoudre une insertion lorsque la ligne existe dans la source et la cible, mais que certaines ou toutes les valeurs de ligne sont différentes.

Tableau 10 INSERTROWEXISTS Conflit avec la résolution USEMAX

Image	SQL	Commentaires
Avant l'image dans la trace	None (row was inserted on the source).	S/O
Après l'image dans la trace	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` est l'image après de la colonne de résolution. Comme il y a une image après, elle sera utilisée pour déterminer la résolution.
Image de base de données cible	name='Mary' phone='111111' address='Ralston' salary=200 balance=500 comment='aaa' last_mod_time='9/1/10 1:00'	`last_mod_time='9/1/10 1:00` est l'image en cours de la colonne de résolution dans la cible sur laquelle la valeur de la colonne de résolution dans la trace est comparée.
`INSERT` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : 1)'Mary' 2)'1234567890' 3)'Oracle Pkwy' 4)100 5)100 6)NULL 7)'9/1/10 3:00'	Cette instruction SQL renvoie un conflit d'unicité sur 'Mary'.
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit	Les variables attachées SQL : 1)'1234567890' 2)'Oracle Pkwy' 3)100 4)100 5)NULL 6)'9/1/10 3:00' 7)'Mary' 8)'9/1/10 3:00'	Etant donné que `USEMAX` est indiqué pour `INSERTROWEXISTS`, le processus Replicat convertit l'insertion en mise à jour et compare la valeur de `last_mod_time` dans l'enregistrement de trace à la valeur dans la base de données. La valeur de l'enregistrement est supérieure, de sorte que les images après pour les colonnes du fichier trace sont appliquées à la cible.

UPDATEROWEXISTS avec la résolution USEMAX

Dans cet exemple, la résolution USEMAX est illustrée avec les images avant et après applicables pour l'enregistrement dans la trace (trail) et dans la base de données. Il montre comment résoudre une mise à jour lorsque la ligne existe dans la source et la cible, mais que certaines ou toutes les valeurs de ligne sont différentes.

Tableau 11 MISE À JOUREXISTE Conflit avec la résolution USEMAX

Image	SQL	Commentaires
Avant l'image dans la trace	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` est l'image avant de la colonne de résolution.
Après l'image dans la trace	phone='222222' address='Holly' last_mod_time='9/1/10 5:00'	`last_mod_time='9/1/10 5:00` est l'image après de la colonne de résolution. Comme il y a une image après, elle sera utilisée pour déterminer la résolution.
Image de base de données cible	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment='com' last_mod_time='9/1/10 6:00'	`last_mod_time='9/1/10 6:00` est l'image en cours de la colonne de résolution dans la cible sur laquelle la valeur de la colonne de résolution dans la trace est comparée.
`UPDATE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : 1)'222222' 2)'Holly' 3)'9/1/10 5:00' 4)'Mary' 5)'1234567890' 6)'Oracle Pkwy' 7)100 8)100 9)NULL 10)'9/1/10 3:00'	Cette instruction SQL renvoie une erreur "no-data-found" car les valeurs de `balance`, `comment` et `last_mod_time` sont différentes dans la cible. Toutes les colonnes sont utilisées dans la clause `WHERE` car l'instruction `COMPARECOLS` est définie sur `ALL`.
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit	Les variables attachées SQL : 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100 6)NULL 7)'9/1/10 5:00' 8)'Mary' 9)'9/1/10 5:00'	La valeur après `last_mod_time` dans l'enregistrement de trace étant inférieure à la valeur en cours dans la base de données, la valeur de base de données est conservée. Le processus de réplication applique l'opération avec une clause `WHERE` qui contient la clé primaire plus une valeur `last_mod_time` définie sur une valeur inférieure à `9/1/10 5:00`. Aucune ligne ne correspond à ce critère. Par conséquent, l'instruction échoue avec une erreur "data not found", mais le processus de réplication ignore l'erreur car une résolution `USEMAX` devrait échouer si la condition n'est pas satisfaite.

UPDATEROWMISSING avec résolution OVERWRITE

Dans cet exemple, la résolution OVERWRITE est illustrée avec les images avant et après applicables pour l'enregistrement dans la trace (trail) et dans la base de données. Elle indique comment résoudre le cas où la ligne cible est manquante. La résolution logique, et celle utilisée, consiste à écraser la ligne dans la cible afin que les deux bases de données soient à nouveau synchronisées.

Tableau 12 Conflit de mise à jour avec la résolution OVERWRITE

Image	SQL	Commentaires
Avant l'image dans la trace	name='Jane' phone='333' address='Oracle Pkwy' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 7:00'	S/O
Après l'image dans la trace	phone='4444' address='Holly' last_mod_time='9/1/10 8:00'
Image de base de données cible	None (row for Jane is missing)
`UPDATE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : 1)'4444' 2)'Holly' 3)'9/1/10 8:00' 4)'Jane' 5)'333' 6)'Oracle Pkwy' 7)200 8)200 9)NULL 10)'9/1/10 7:00'	Cette instruction SQL renvoie une erreur no-data-found. Toutes les colonnes sont utilisées dans la clause `WHERE` car l'instruction `COMPARECOLS` est définie sur `ALL`.
`INSERT` appliqué par le processus Replicat pour résoudre le conflit	Les variables attachées SQL : 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	La mise à jour est convertie en insertion car `OVERWRITE` est la résolution. L'image après d'une colonne est utilisée si elle est disponible ; sinon, l'image avant est utilisée.

DELETEROWEXISTS avec résolution OVERWRITE

Dans cet exemple, la résolution OVERWRITE est illustrée avec les images avant et après applicables pour l'enregistrement dans la trace (trail) et dans la base de données. Elle indique comment résoudre le cas où la ligne source a été supprimée mais où la ligne cible existe. Dans ce cas, la résolution OVERWRITE applique la suppression à la cible.

Tableau 13 DELETEROWEXISTS Conflit avec la résolution OVERWRITE

Image	SQL	Commentaires
Avant l'image dans la trace	name='Mary' phone='222222' address='Holly' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 5:00'	S/O
Après l'image dans la trace	None	S/O
Image de base de données cible	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment=com last_mod_time='9/1/10 7:00'	La ligne existe sur la cible, mais les colonnes `phone`, `address`, `balance`, `comment` et `last_mod_time` sont différentes de l'image "avant" dans la trace.
`DELETE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100d 6)NULL 7)'9/1/10 5:00'	Toutes les colonnes sont utilisées dans la clause `WHERE` car l'instruction `COMPARECOLS` est définie sur `ALL`. Une erreur no-data-found se produit en raison de la différence entre les valeurs before et current.
`DELETE` appliqué par le processus Replicat pour résoudre le conflit	Les variables attachées SQL : 1)'Mary'	Etant donné que `OVERWRITE` est la résolution, `DELETE` est appliqué à l'aide de la clé primaire uniquement (pour éviter une erreur d'intégrité).

DELETEROWMISSING avec résolution DISCARD

Dans cet exemple, la résolution DISCARD est illustrée avec les images avant et après applicables pour l'enregistrement dans la trace (trail) et dans la base de données. Elle indique comment résoudre le cas où la ligne cible est manquante. Dans le cas d'une suppression sur la source, il est acceptable que la ligne cible n'existe pas (elle doit quand même être supprimée). Par conséquent, la résolution consiste à ignorer l'opération DELETE qui se trouve dans la trace.

Tableau 14 DELETEROWMSING Conflict with DISCARD Resolution

Image	SQL	Commentaires
Avant l'image dans la trace	name='Jane' phone='4444' address='Holly' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 8:00'	S/O
Après l'image dans la trace	None	S/O
Image de base de données cible	None (row missing)	S/O
`DELETE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	Cette instruction SQL renvoie une erreur no-data-found. Toutes les colonnes sont utilisées dans la clause `WHERE` car l'instruction `COMPARECOLS` est définie sur `ALL`.
SQL appliqué par le processus Replicat pour résoudre le conflit	None	Etant donné que `DISCARD` est indiqué comme résolution pour `DELETEROWMISSING`, la suppression de la trace est envoyée au fichier de rebut.

CDR Exemple 2 : UPDATEROWEXISTS avec USEDELTA et USEMAX

Cet exemple résout la condition dans laquelle une ligne cible existe sur UPDATE, mais les colonnes non clé sont différentes. Il utilise deux types de résolution différents pour gérer cette condition en fonction de la colonne concernée.

Table utilisée dans cet exemple

Les exemples supposent des bases de données Oracle identiques.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Dans la base de données source, toutes les colonnes sont journalisées de manière supplémentaire :

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Déclaration MAP

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE KEYINCLUDING (address, phone, salary, last_mod_time),
    ON DELETE KEYINCLUDING (address, phone, salary, last_mod_time)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary)),
    (DEFAULT, USEMAX (last_mod_time)));

Description de la déclaration MAP

Pour un conflit UPDATEROWEXISTS, lorsqu'une ligne cible existe sur UPDATE mais que les colonnes non clé sont différentes, utilisez deux résolutions différentes en fonction de la colonne :

Selon la résolution delta_res_method, utilisez la logique de résolution USEDELTA pour la colonne salary afin que la modification de la valeur soit ajoutée à la valeur en cours de la colonne.
Par DEFAULT, utilisez la logique de résolution USEMAX pour toutes les autres colonnes de la table (groupe de colonnes par défaut), en utilisant la colonne last_mod_time comme colonne de résolution. Cette colonne est mise à jour avec l'heure actuelle chaque fois que la ligne est modifiée. La valeur de cette colonne dans la trace est comparée à la valeur de la cible. Si la valeur de last_mod_time dans l'enregistrement de trace est supérieure à la valeur en cours de last_mod_time dans la base de données cible, les modifications apportées à name, phone, address, balance, comment et last_mod_time sont appliquées à la cible.

Pour COMPARECOLS, utilisez la clé primaire (colonne name ) plus les colonnes address, phone, salary et last_mod_time comme colonnes de comparaison pour la détection des conflits pour les opérations UPDATE et DELETE. (Les colonnes balance et comment ne sont pas comparées.)

Remarque : au lieu de USEMAX, vous pouvez utiliser la résolution USEMAXEQ pour appliquer une condition >=. Pour plus d'informations, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.

Gestion des erreurs

Pour obtenir un exemple de gestion des erreurs dans une table d'exceptions, reportez-vous à Configuration des fichiers de paramètres Oracle GoldenGate pour la gestion des erreurs.

Tableau 15 UPDATEROWEXISTS avec USEDELTA et USEMAX

Image	SQL	Commentaires
Avant l'image dans la trace	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'`	`last_mod_time='9/1/10 3:00` est l'image avant de la colonne de résolution pour la résolution `USEMAX`. `salary=100` est l'image avant de la résolution `USEDELTA`.
Après l'image dans la trace	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` est l'image après de la colonne de résolution pour `USEMAX`. Comme il y a une image après, elle sera utilisée pour déterminer la résolution.
Image de base de données cible	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` est l'image en cours de la colonne de résolution dans la cible sur laquelle la valeur de la colonne de résolution dans la trace est comparée. `salary=600` est l'image en cours de la colonne cible pour la résolution `USEDELTA`.
`UPDATE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)'9/1/10 3:00'`	Cette instruction SQL renvoie une erreur "no-data-found" car les valeurs de `salary` et `last_mod_time` sont différentes. (Les valeurs de `comment` et `balance` sont également différentes, mais ces colonnes ne sont pas comparées.)
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit pour `salary`, à l'aide de `USEDELTA`.	Les variables attachées SQL : `1)200 2)100 3)'Mary'`	Par `USEDELTA`, la différence entre l'image après `salary` (200) dans la trace et l'image avant `salary` (100) dans la trace est ajoutée à la valeur actuelle de `salary` dans la cible (600). Le résultat est 700. `600 + (200 - 100) = 700`
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit des colonnes par défaut, à l'aide de `USEMAX`.	Les variables attachées SQL : `1)'222222' 2)'Holly' 3)'new' 4)'9/1/10 5:00' 5)'Mary' 6)'9/1/10 5:00'`	Par `USEMAX`, la valeur après `last_mod_time` dans l'enregistrement de trace étant supérieure à la valeur en cours dans la base de données, la ligne est mise à jour avec les valeurs après de l'enregistrement de trace. La colonne `salary` n'est pas définie ici car elle est résolue avec `UPDATE` à partir de la résolution `USEDELTA`.

CDR Exemple 3 : UPDATEROWEXISTS avec USEDELTA, USEMAX et IGNORE

Cet exemple résout le conflit lorsqu'une ligne cible existe sur UPDATE mais que les colonnes non clé sont différentes. Il utilise trois types de résolution différents pour gérer cette condition en fonction de la colonne concernée.

Table utilisée dans cet exemple

Les exemples supposent des bases de données Oracle identiques.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Dans la base de données source, toutes les colonnes sont journalisées de manière supplémentaire :

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Déclaration MAP

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE ALLEXCLUDING (comment)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary, balance)),
    (max_res_method, USEMAX (last_mod_time), COLS (address, last_mod_time)),
    (DEFAULT, IGNORE));

Description de la déclaration MAP

Pour un conflit UPDATEROWEXISTS, lorsqu'une ligne cible existe sur UPDATE mais que les colonnes non clé sont différentes, utilisez deux résolutions différentes en fonction de la colonne :
- Selon la résolution delta_res_method, utilisez la logique de résolution USEDELTA pour les colonnes salary et balance afin que la modification de chaque valeur soit ajoutée à la valeur en cours de chaque colonne.
- Selon la résolution max_res_method, utilisez la logique de résolution USEMAX pour les colonnes address et last_mod_time. La colonne last_mod_time est la colonne de résolution. Cette colonne est mise à jour avec l'heure actuelle chaque fois que la ligne est modifiée. La valeur de cette colonne dans la trace est comparée à la valeur de la cible. Si la valeur de last_mod_time dans l'enregistrement de trace est supérieure à la valeur en cours de last_mod_time dans la base de données cible, les modifications apportées à address et last_mod_time sont appliquées à la cible ; sinon, elles sont ignorées en faveur des valeurs cible.
- Par DEFAULT, utilisez la logique de résolution IGNORE pour les colonnes restantes (phone et comment) de la table (groupe de colonnes par défaut). Les modifications apportées à ces colonnes seront toujours ignorées par la réplication.
Par COMPARECOLS, utilisez toutes les colonnes à l'exception de la colonne comment comme colonnes de comparaison pour la détection des conflits pour les opérations UPDATE. Le commentaire ne sera pas utilisé dans la clause WHERE pour les mises à jour, mais toutes les autres colonnes qui ont une image "avant" dans l'enregistrement de trace seront utilisées. Remarque : au lieu de USEMAX, vous pouvez utiliser la résolution USEMAXEQ pour appliquer une condition >=. Pour plus d'informations, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.

Gestion des erreurs

Pour obtenir un exemple de gestion des erreurs dans une table d'exceptions, reportez-vous à Configuration des fichiers de paramètres Oracle GoldenGate pour la gestion des erreurs.

Tableau 16 UPDATEROWEXISTS avec USEDELTA, USEMAX et IGNORE

Image	SQL	Commentaires
Avant l'image dans la trace	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00`	`last_mod_time='9/1/10 3:00` est l'image avant de la colonne de résolution pour la résolution `USEMAX`. `salary=100` et `balance=100` sont les images "avant" pour la résolution `USEDELTA`.
Après l'image dans la trace	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` est l'image après de la colonne de résolution pour `USEMAX`. Comme il y a une image after, elle sera utilisée pour déterminer la résolution. `salary=200` est la seule image après laquelle la résolution `USEDELTA` est disponible. Pour `balance`, l'image avant est utilisée dans le calcul.
Image de base de données cible	`name='Mary' phone='1234567890' address='Ralston' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` est l'image en cours de la colonne de résolution dans la cible sur laquelle la valeur de la colonne de résolution dans la trace est comparée pour `USEMAX`. `salary=600` et `balance=600` sont les images en cours des colonnes cible pour `USEDELTA`.
`UPDATE` initial appliqué par le processus Replicat qui détecte le conflit	Les variables attachées SQL : `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)100 11)'9/1/10 3:00'`	Cette instruction SQL renvoie une erreur "no-data-found" car les valeurs des colonnes `address`, `salary`, `balance` et `last_mod_time` sont différentes.
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit pour `salary`, à l'aide de `USEDELTA`.	Les variables attachées SQL : `1)200 2)100 3)'Mary'`	Pour `salary`, il existe une différence de 100, mais la valeur de `balance` n'a pas été modifiée. Elle n'est donc pas nécessaire dans l'instruction SQL de mise à jour. Par `USEDELTA`, la différence (delta) entre l'image après (200) et l'image avant (100) de `salary` dans la trace est ajoutée à la valeur actuelle de `salary` dans la cible (600). Le résultat est 700.
`UPDATE` appliqué par le processus Replicat pour résoudre le conflit pour `USEMAX`.	Les variables attachées SQL : `1)'Holly' 2)'9/1/10 5:00' 3)'Mary' 4)'9/1/10 5:00'`	Etant donné que la valeur après `last_mod_time` dans l'enregistrement de trace est supérieure à la valeur en cours dans la base de données, cette colonne et la colonne `address` sont mises à jour avec les valeurs après de l'enregistrement de trace. La colonne `salary` n'est pas définie ici car elle est résolue avec `UPDATE` à partir de la résolution `USEDELTA`.
`UPDATE` appliqué par le processus de réplication pour `IGNORE`.	Les variables attachées SQL : `1)'222222' 2)'new' 3)'Mary'`	`IGNORE` est indiqué pour le groupe de colonnes `DEFAULT` (`phone` et `comment`), de sorte qu'aucune instruction SQL de résolution n'est appliquée.

Configurer les fichiers de paramètres Oracle GoldenGate pour la gestion des erreurs

Le traitement CDR manuel doit être utilisé conjointement avec le traitement des erreurs pour capturer les erreurs qui ont été résolues et les erreurs que le traitement CDR n'a pas pu résoudre.

La résolution des conflits est effectuée avant les autres paramètres de traitement des erreurs suivants : HANDLECOLLSIONS, INSERTMISSINGUPDATES et REPERROR. Utilisez le paramètre REPERROR pour affecter des règles de gestion des erreurs qui ne peuvent pas être résolues par CDR ou pour les erreurs que vous ne souhaitez pas gérer via CDR. Il peut être approprié que REPERROR gère certaines erreurs et que le CDR en gère d'autres. Toutefois, si REPERROR et le CDR sont configurés pour gérer le même conflit, le CDR est prioritaire. Les paramètres INSERTMISSINGUPDATES et HANDLECOLLISIONS peuvent également être utilisés pour gérer certaines erreurs non gérées par CDR. Pour plus d'informations sur ces paramètres, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.
(Facultatif) Créez une table d'exceptions. Lorsqu'une table d'exceptions est utilisée avec une instruction MAP d'exceptions, le processus de réplication envoie toutes les opérations qui génèrent un conflit (résolu ou non) à l'instruction MAP d'exceptions à mettre en correspondance avec la table d'exceptions. Omettez une clé primaire sur cette table si le processus Replicat doit traiter les conflits UPDATE et DELETE. Sinon, des erreurs de contrainte d'intégrité peuvent survenir.

Au minimum, une table d'exceptions doit contenir les mêmes colonnes que la table cible. Ces lignes contiennent chaque image de ligne que le processus Replicat a appliquée à la cible (ou a tenté d'appliquer).

En outre, vous pouvez définir des colonnes supplémentaires pour capturer d'autres informations qui permettent de placer les données dans un contexte transactionnel. Oracle GoldenGate fournit des outils permettant de capturer ces informations via l'instruction MAP des exceptions. Ces colonnes peuvent être, mais ne sont pas limitées à, les suivantes :
- Image avant de l'enregistrement de trace. Il s'agit d'un ensemble de colonnes cible en double portant des noms tels que col1_before, col2_before, etc.
- Valeurs actuelles des colonnes cible. Il s'agit également d'un ensemble de colonnes cible en double portant des noms tels que col1_current, col2_current, etc.
- Nom de la Table cible
- Horodatage du conflit
- Type d'opération
- Numéro d'erreur de la base de données
- (Facultatif) Message d'erreur de la base de données
- Indique si le conflit a été résolu ou non
Créez une instruction MAP d'exceptions pour mettre en correspondance les données d'exceptions avec la table des exceptions. Une instruction MAP d'exception contient :
- (Obligatoire) Option INSERTALLRECORDS. Ce paramètre convertit toutes les opérations mises en correspondance en INSERT de sorte que toutes les valeurs de colonne soient mises en correspondance avec la table des exceptions.
- (Obligatoire) Option EXCEPTIONSONLY. Ce paramètre amène le processus Replicat à mapper les opérations qui génèrent une erreur, mais pas celles qui ont réussi.
- (Facultatif) Clause COLMAP. Si les noms et les définitions des colonnes de la table d'exceptions sont identiques à ceux de la table source, et que la table d'exceptions contient uniquement ces colonnes, aucune valeur COLMAP n'est nécessaire. Toutefois, si des noms ou des définitions diffèrent, ou s'il existe des colonnes supplémentaires dans la table d'exceptions que vous voulez remplir avec des données supplémentaires, utilisez une clause COLMAP pour mettre en correspondance toutes les colonnes.

Outils de mise en correspondance de données supplémentaires avec la table des exceptions

Voici quelques outils que vous pouvez utiliser dans la clause COLMAP pour remplir des colonnes supplémentaires :

Si les noms et les définitions des colonnes source sont identiques à ceux des colonnes cible de la table des exceptions, vous pouvez utiliser le mot-clé USEDEFAULTS au lieu de mettre explicitement en correspondance les noms. Sinon, vous devez mettre en correspondance ces colonnes dans la clause COLMAP, par exemple :
```
COLMAP (exceptions_col1 = col1, [...])
```
Pour mettre en correspondance l'image avant de la ligne source avec les colonnes de la table des exceptions, utilisez la fonction de conversion @BEFORE, qui capture l'image avant d'une colonne à partir de l'enregistrement de trace. Cet exemple illustre l'utilisation de @BEFORE.
```
COLMAP (USEDEFAULTS, exceptions_col1 = @BEFORE (source_col1), &
exceptions_col2 = @BEFORE (source_col2), [...])
```
Pour mettre en correspondance l'image en cours de la ligne cible avec les colonnes de la table des exceptions, utilisez une requête SQLEXEC pour capturer l'image, puis mettez en correspondance les résultats de la requête avec les colonnes de la table des exceptions à l'aide de la syntaxe 'queryID.column' dans la clause COLMAP, comme dans l'exemple suivant :
```
COLMAP (USEDEFAULTS, name_current = *queryID*.*name*, phone_current = *queryID*.*phone*, [...])
```
Pour mapper les horodatages, les erreurs de base de données et d'autres informations environnementales, utilisez les fonctions de conversion de colonne Oracle GoldenGate appropriées. Par exemple, l'horodatage en cours est mappé au moment de l'exécution.
```
res_date = @DATENOW ()
```

Reportez-vous à Exemple de mapping d'exceptions avec des colonnes supplémentaires dans la table des exceptions pour savoir comment combiner ces fonctionnalités dans une clause COLMAP dans l'instruction MAP des exceptions afin de remplir une table d'exceptions détaillée.

Reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate pour connaître l'utilisation et la syntaxe des paramètres et des fonctions de conversion de colonne présentés dans ces exemples.

Exemple de mappage des exceptions avec les colonnes source et cible uniquement

Voici un exemple de fichier de paramètres qui montre la gestion des erreurs et la mise en correspondance des exceptions simples pour les tables source et cible utilisées dans les exemples CDR qui commencent. Cet exemple mappe les colonnes source et cible, mais pas de colonnes supplémentaires. Pour les raisons suivantes, une clause COLMAP n'est pas nécessaire dans l'instruction MAP des exceptions de cet exemple :

Le nom et la définition des colonnes d'exceptions source et cible sont identiques.
La table des exceptions ne contient aucune autre colonne. Remarque : cet exemple ignore intentionnellement d'autres paramètres requis dans un fichier de paramètres de réplication, tels que le nom du processus et les informations d'identification de connexion, ainsi que tous les paramètres facultatifs pouvant être requis pour un type de base de données donné. Lorsque vous utilisez des sauts de ligne pour fractionner une instruction de paramètre en plusieurs lignes, utilisez une esperluette (&) à la fin de chaque ligne.

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD

    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)

    -- Specifies a discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE

    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)), &
);

    -- Starts the exceptions MAP statement by mapping the source table to the

    -- exceptions table.
MAP fin.src, TARGET fin.exception, &

    -- directs Replicat only to map operations that caused the error specified

    -- in REPERROR.
EXCEPTIONSONLY, &

    -- directs Replicat to convert all the exceptions to inserts into the

    -- exceptions table. This is why there cannot be a primary key constraint

    -- on the exceptions table.
INSERTALLRECORDS
;

Exemple de mappage des exceptions avec des colonnes supplémentaires dans la table des exceptions

Voici un exemple de fichier de paramètres qui montre la gestion des erreurs et la mise en correspondance des exceptions complexes pour les tables source et cible utilisées dans les exemples CDR qui commencent. Dans cet exemple, la table des exceptions comporte les mêmes lignes que la table source, mais elle comporte également des colonnes supplémentaires pour capturer les données de contexte.

Remarque : cet exemple ignore intentionnellement d'autres paramètres requis dans un fichier de paramètres de réplication, tels que le nom du processus et les informations d'identification de connexion, ainsi que tous les paramètres facultatifs pouvant être requis pour un type de base de données donné. Lorsque vous utilisez des sauts de ligne pour fractionner une instruction de paramètre en plusieurs lignes, utilisez une esperluette (&) à la fin de chaque ligne.

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD
    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)
    -- Specifies the discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE
    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time))), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD))
);
    -- Starts the exceptions MAP statement by mapping the source table to the -- exceptions table.
MAP fin.src, TARGET fin.exception, &
    -- directs Replicat only to map operations that caused the error specified
    -- in REPERROR.
EXCEPTIONSONLY, &
    -- directs Replicat to convert all the exceptions to inserts into the
    -- exceptions table. This is why there cannot be a primary key constraint
    -- on the exceptions table.
INSERTALLRECORDS &
    -- SQLEXEC query to select the values from the target record before the
    -- Replicat statement is applied. These are mapped to the *_target
    -- columns later.
SQLEXEC (id qry, query 'select name, phone, address, salary, balance, & comment, last_mod_time from fin.tgt where name = :p1', PARAMS(p1 = name )), &
    -- Start of the column mapping, specifies use default column definitions.
COLMAP ( &
    -- USEDEFAULTS maps the source columns to the target exceptions columns
    -- that receive the after image that Replicat applied or tried to apply.
    -- In this case, USEDEFAULTS can be used because the names and definitions
    -- of the source and target exceptions columns are identical; otherwise
    -- the columns must be mapped explicitly in the COLMAP clause.
USEDEFAULTS, &
    -- captures the timestamp when the resolution was performed.
res_date = @DATENOW (), &
    -- captures and maps the DML operation type.
optype = @GETENV ('LASTERR', 'OPTYPE'), &
    -- captures and maps the database error number that was returned.
dberrnum = @GETENV ('LASTERR', 'DBERRNUM'), &
    -- captures and maps the database error that was returned.
dberrmsge = @GETENV ('LASTERR', 'DBERRMSG'), &
    -- captures and maps the name of the target table
tabname = @GETENV ('GGHEADER', 'TABLENAME'), &
    -- If the names and definitions of the source columns and the target
    -- exceptions columns were not identical, the columns would need to
    -- be mapped in the COLMAP clause instead of using USEDEFAULTS, as
    -- follows:
       -- name_after = name, &
       -- phone_after = phone, &
       -- address_after = address, &
       -- salary_after = salary, &
       -- balance_after = balance, &
       -- comment_after = comment, &
       -- last_mod_time_after = last_mod_time &
    -- maps the before image of each column from the trail to a column in the
    -- exceptions table.
name_before = @BEFORE (name), &
phone_before = @BEFORE (phone), &
address_before = @BEFORE (address), &
salary_before = @BEFORE (salary), &
balance_before = @BEFORE (balance), &
comment_before = @BEFORE (comment), &
last_mod_time_before = @BEFORE (last_mod_time), &
    -- maps the results of the SQLEXEC query to rows in the exceptions table
    -- to show the current image of the row in the target.
name_current = qry.name, &
phone_current = qry.phone, &
address_current = qry.address, &
salary_current = qry.salary, &
balance_current = qry.balance, &
comment_current = qry.comment, &
last_mod_time_current = qry.last_mod_time)
;

Une fois que vous êtes certain que vos routines fonctionnent comme prévu dans toutes les situations, vous pouvez réduire la quantité de données consignées dans la table des exceptions afin de réduire la surcharge des routines de résolution.