RÉERREUR

Durée de validité

Réplication

Description

Utilisez le paramètre REPERROR pour contrôler la façon dont le processus Replicat répond aux erreurs. La réponse par défaut du processus Replicat à toute erreur est l'abandon.

Vous pouvez utiliser une instruction REPERROR pour gérer la plupart des erreurs de manière par défaut, tout en utilisant une ou plusieurs autres instructions REPERROR pour gérer des erreurs spécifiques différemment. Par exemple, vous pouvez ignorer les erreurs d'enregistrement en double, mais abandonner le traitement dans tous les autres cas.

Vous pouvez utiliser REPERROR globalement (à la racine du fichier de paramètres) pour affecter toutes les instructions MAP qui le suivent, ou vous pouvez l'utiliser dans une instruction MAP pour affecter les tables indiquées dans cette instruction. L'utilisation de REPERROR dans une instruction MAP vous permet de gérer les erreurs d'une manière particulière pour chaque thread d'une réplication coordonnée.

Utilisation du traitement des erreurs au niveau de l'enregistrement

Toutes les options REPERROR, à l'exception de TRANSDISCARD et TRANSEXCEPTION, appliquent une action de traitement des erreurs en réponse à une opération SQL individuelle sur un enregistrement individuel. D'autres enregistrements sans erreur dans la même transaction sont traités comme configuré dans les instructions MAP et d'autres paramètres du fichier de paramètres, le cas échéant.

Utilisation de la gestion des erreurs au niveau transaction

Les options TRANSDISCARD, TRANSEXCEPTION et ABEND appliquent une action de traitement des erreurs à l'ensemble d'une transaction. L'erreur de déclenchement peut se produire sur un enregistrement individuel dans la transaction ou sur l'opération de validation. (Aucun enregistrement particulier n'est associé aux erreurs de validation.) Ces options peuvent être utilisées pour :

TRANSDISCARD et TRANSEXCEPTION s'excluent mutuellement.

Effet des autres paramètres sur les options au niveau de la transaction

TRANSDISCARD et TRANSEXCEPTION respectent les limites de la transaction source. Toutefois, la présence de BATCHSQL, GROUPTRANSOPS ou MAXTRANSOPS dans le fichier de paramètres peut affecter la logique de traitement des erreurs ou le résultat, car ils modifient les limites de transaction.

Effet de BATCHSQL et GROUPTRANSOPS

BATCHSQL ou GROUPTRANSOPS (valeur par défaut) regroupent les opérations SQL de différentes transactions en transactions plus volumineuses afin d'améliorer les performances, tout en maintenant l'ordre transactionnel. Lorsque ces paramètres sont en vigueur et qu'une erreur se produit, le processus Replicat tente d'abord de les résoudre en entrant un autre mode de traitement (reportez-vous à la documentation de ces paramètres). Si l'erreur persiste, TRANSDISCARD ou TRANSEXCEPTION entre en vigueur et le processus Replicat reprend le mode de traitement source comme suit :

  1. Il annule la transaction groupée ou groupée.

  2. Il réexécute la transaction incriminée une opération SQL à la fois, en utilisant les mêmes limites de transaction que la transaction source.

  3. Il effectue la logique de rejet (TRANSDISCARD) ou la mise en correspondance des exceptions (TRANSEXCEPTION). (Voir ces descriptions d'options pour plus de détails.)

  4. Il reprend le mode BATCHSQL ou GROUPTRANSOPS une fois le traitement des erreurs TRANSDISCARD terminé.

Effet de MAXTRANSOPS

L'intégrité du traitement des erreurs au niveau de la transaction TRANSDISCARD et TRANSEXCEPTION peut être affectée négativement par la définition du paramètre MAXTRANSOPS. MAXTRANSOPS permet au processus Replicat de fractionner des transactions source répliquées très volumineuses en transactions plus petites lorsqu'il les applique sur la cible.

Grâce à la logique TRANSDISCARD et TRANSEXCEPTION, le processus Replicat rétablit le premier enregistrement après la dernière validation réussie. Cela peut être ou non le début réel de la transaction. Cela dépend du fait que la transaction a été fractionnée et qu'une partie de celle-ci figure dans les transactions précédemment validées. Dans ce cas, le processus Replicat ne peut pas appliquer l'action TRANSDISCARD ou TRANSEXCEPTION à l'ensemble de la transaction telle qu'elle a été émise sur la source, mais uniquement à la partie qui a été annulée à partir de la cible.

Si vous utilisez MAXTRANSOPS, assurez-vous qu'elle est définie sur une valeur supérieure à la transaction la plus volumineuse qui devrait être gérée par TRANSDISCARD et TRANSEXCEPTION. Cela garantit que les transactions ne sont pas divisées en plus petites sur la cible.

Effet des options de niveau transaction sur les statistiques

La sortie des commandes d'information, telles que STATS REPLICAT, affiche le nombre total d'enregistrements dans la transaction qui a été traitée par la logique TRANSDISCARD ou TRANSEXCEPTION. Ce nombre peut refléter les éléments suivants :

Le processus Replicat abandonne les erreurs causées par le traitement de suppression (TRANSDISCARD) ou le mapping des exceptions (TRANSEXCEPTION).

Obtention d'informations supplémentaires sur le traitement des erreurs

Pour plus d'informations sur la configuration de la gestion des erreurs pour Extract et Replicat, reportez-vous à Gestion des erreurs dans la documentation des microservices Oracle GoldenGate.

Pour plus d'informations sur le paramètre MAP, reportez-vous à "TABLE | MAP".

Valeur par défaut

TRANSABORT pour les interblocages ; ABEND pour tous les autres

Syntaxe

REPERROR {
(
{DEFAULT | DEFAULT2 | <SQL_error> | <user_defined_error>},
{ABEND |
DISCARD |
EXCEPTION |
IGNORE |
RETRYOP [MAXRETRIES <n>] |
TRANSABORT [, MAXRETRIES] [, DELAYSECS <n> | DELAYCSECS <n>] |
TRANSDISCARD |
TRANSEXCEPTION
}
{PROCEDURE,[ABEND|IGNORE|DISCARD]}) |
RESET }

Options de spécification d'erreur

DEFAULT

Définit une réponse globale à toutes les erreurs à l'exception de celles pour lesquelles des instructions REPERROR explicites sont indiquées.

DEFAULT2

Fournit une action de sauvegarde par défaut lorsque la réponse pour DEFAULT est définie sur EXCEPTION. Utilisez DEFAULT2 lorsqu'aucune instruction MAP d'exception n'est indiquée pour une instruction MAP pour laquelle des erreurs sont anticipées.

<SQL_error>

Numéro d'erreur SQL. Il peut s'agir d'une erreur au niveau de l'enregistrement ou d'une erreur au niveau de la validation si vous utilisez TRANSDISCARD et TRANSEXCEPTION.

<user_defined_error>

Erreur définie par l'utilisateur qui est indiquée avec l'option RAISEERROR d'une clause FILTER dans une instruction MAP.

Options de réponse aux erreurs

ABEND

Annule la transaction et met fin au traitement anormalement. ABEND est la valeur par défaut.

DISCARD

Consigne l'opération incriminée dans le fichier de rebut, mais poursuit le traitement de la transaction et des transactions suivantes.

EXCEPTION

Gère l'opération à l'origine de l'erreur comme une exception, mais traite normalement les opérations sans erreur dans la transaction. Utilisez cette option conjointement avec une instruction MAP d'exceptions ou pour utiliser l'option MAPEXCEPTION de MAP. Par exemple, vous pouvez mettre en correspondance des colonnes d'instructions de mise à jour ayant échoué dans une table "Mises à jour manquantes". Dans le fichier de paramètres, indiquez l'instruction MAP des exceptions après l'instruction MAP pour laquelle l'erreur est anticipée.

EXCEPTION applique la gestion des exceptions uniquement à une opération SQL individuelle sur un enregistrement individuel. Pour appliquer la gestion des exceptions à l'ensemble de la transaction, utilisez l'option TRANSEXCEPTION.

Remarque : Lorsque la fonction Détection et résolution des conflits (CDR) est active, elle traite automatiquement toutes les opérations qui génèrent des erreurs en tant qu'exceptions si une instruction MAP d'exceptions existe pour la table concernée. Dans ce cas, REPERROR avec EXCEPTION n'est pas nécessaire car AUTOCDR n'est pas compatible avec REPERROR. Par conséquent, REPERROR sera ignoré pour les tables pour lesquelles AUTOCDR est activé. Utilisez REPERROR avec d'autres options pour gérer les conflits que la fonction CDR ne peut pas résoudre ou pour les conflits que vous ne souhaitez pas que la fonction CDR gère.

IGNORE

Ne tient pas compte de l'erreur.

RETRYOP [MAXRETRIES <n>]

Retente l'opération à l'origine du problème. Utilisez l'option MAXRETRIES pour contrôler le nombre de nouvelles tentatives. Par exemple, si une table n'a pas d'extents, RETRYOP avec MAXRETRIES vous donne le temps d'ajouter des extents afin que la transaction n'échoue pas. Abandon de la réplication après le nombre spécifié de MAXRETRIES.

TRANSABORT [, MAXRETRIES <n>] [, DELAYSECS <n> | DELAYCSECS <n>]

Abandonne la transaction et effectue un repositionnement en début de transaction. Cette séquence se poursuit jusqu'à ce que les enregistrements soient traités avec succès ou jusqu'à ce que MAXRETRIES expire. Si MAXRETRIES n'est pas défini, l'action TRANSABORT effectue une boucle continue.

Utilisez l'une des options DELAY pour retarder la nouvelle tentative. DELAYSECS <n> définit le délai en secondes et la valeur par défaut est de 60 secondes. DELAYCSECS <n> définit le délai en centisecondes.

L'option TRANSABORT est utile pour gérer les délais d'expiration et les interblocages sur les bases de données qui prennent en charge ces conditions.

TRANSDISCARD

Ignore la transaction source entière si une opération au sein de cette transaction, y compris l'opération de validation, entraîne une erreur de réplication répertoriée dans la spécification d'erreur REPERROR. Le processus Replicat abandonne la transaction et, si l'erreur s'est produite sur un enregistrement, écrit cet enregistrement dans le fichier de rebut. Le processus Replicat réexécute ensuite la transaction et écrit tous les enregistrements dans le fichier de rebut, y compris l'enregistrement de validation. Le processus Replicat abandonne les erreurs causées par le traitement de suppression.

Si l'enregistrement supprimé a déjà été mis en correspondance avec un enregistrement cible, le processus Replicat l'écrit dans le fichier de rebut au format cible ; sinon, il sera écrit au format source. La transaction elle-même réexécutée est toujours écrite au format source.

TRANSDISCARD prend en charge les erreurs de niveau enregistrement ainsi que les erreurs de validation.

Des informations supplémentaires sont disponibles au début de ce sujet.

TRANSEXCEPTION

Si une erreur spécifiée avec REPERROR se produit sur un enregistrement d'une transaction, effectue la mise en correspondance des exceptions pour chaque enregistrement de la transaction en fonction de sa spécification de mise en correspondance des exceptions correspondante, telle que définie par une clause MAPEXCEPTION ou EXCEPTIONSONLY dans une instruction MAP d'exceptions. Si un enregistrement n'a pas de spécification de mappage d'exceptions correspondante, ou si une erreur s'est produite lors de l'écriture dans la table des exceptions, le processus Replicat s'interrompt avec un message d'erreur.

Lorsqu'une erreur est détectée et que TRANSEXCEPTION est utilisé, le processus de réplication abandonne la transaction et, si l'erreur s'est produite sur un enregistrement, écrit cet enregistrement dans le fichier de rebut. Le processus Replicat réexécute la transaction et examine les enregistrements source pour trouver les spécifications de mise en correspondance des exceptions, puis les exécute.

TRANSEXCEPTION prend en charge les erreurs de niveau enregistrement ainsi que les erreurs de validation. Pour gérer les erreurs au niveau de l'enregistrement (pour les opérations SQL individuelles), sans affecter les opérations sans erreur dans la même transaction, utilisez l'option EXCEPTION dans une instruction MAP.

PROCEDURE,[ABEND IGNORE DISCARD]

Utilisez PROCEDURE pour configurer le comportement de la réplication lorsqu'une erreur de réplication procédurale se produit. Par défaut, le processus Replicat ABEND lorsqu'une erreur de réplication procédurale se produit.

L'option IGNORE ignore l'appel qui a échoué. L'option DISCARD transfère les erreurs ignorées dans la file d'attente des erreurs d'application dans la base de données cible. Ces erreurs peuvent être réexécutées ou supprimées ultérieurement.

RESET

Utilisez une instruction REPERROR RESET pour enlever les règles de traitement des erreurs indiquées dans les paramètres REPERROR précédents et appliquer la gestion des erreurs par défaut à toutes les instructions MAP qui suivent.

Exemples d'utilisation de REPERROR globalement

Ces exemples montrent REPERROR tel qu'il est utilisé à la racine du fichier de paramètres pour définir des règles globales de traitement des erreurs. Vous pouvez remplacer une ou plusieurs de ces règles pour une ou plusieurs tables en utilisant REPERROR dans une instruction MAP. Reportez-vous à la section "Exemples d'utilisation de REPERROR globalement et dans une instruction MAP".

Exemple 1

L'exemple suivant montre comment arrêter le traitement de la plupart des erreurs, mais ignorer les erreurs d'enregistrement en double.

REPERROR (DEFAULT, ABEND)
REPERROR (-1, IGNORE)

Exemple 2

L'exemple suivant appelle une instruction MAP d'exception créée pour gérer les erreurs dans la table de comptes. Les erreurs sur la table product entraînent une fin anormale du processus Replicat car aucune instruction MAP d'exception n'a été définie.

REPERROR (DEFAULT, EXCEPTION)
REPERROR (DEFAULT2, ABEND)
MAP sales.product, TARGET sales.product;
MAP sales.account, TARGET sales.account;
INSERTALLRECORDS
MAP sales.account, TARGET sales.account_exception,
EXCEPTIONSONLY,
COLMAP (account_no = account_no,
optype = @GETENV ('lasterr', 'optype'),
dberr = @GETENV ('lasterr', 'dberrnum'),
dberrmsg = @GETENV ('lasterr', 'dberrmsg'));

Exemple 3

Les règles d'erreur suivantes s'appliquent à la première instruction MAP, puis restaurent la valeur par défaut de ABEND vers la seconde.

REPERROR (-1, IGNORE)
MAP sales.product, TARGET sales.product;
REPERROR RESET
MAP sales.account, TARGET sales.account;

Exemple 4

La commande suivante supprime l'enregistrement incriminé, puis réexécute l'intégralité de la transaction si une opération sur un enregistrement qu'elle contient génère une erreur 1403. D'autres types d'erreur entraînent un abandon du processus Replicat.

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSDISCARD

Exemple 5

Les éléments suivants annulent l'enregistrement incriminé, puis réexécutent l'ensemble de la transaction pour rechercher une spécification de mappage des exceptions qui écrit dans la table des exceptions nommée tgtexception. D'autres erreurs entraînent l'abandon de l'enregistrement incriminé par le processus Replicat (le cas échéant), puis l'abandon.

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSEXCEPTION
MAP src, TARGET tgt, &
MAPEXCEPTION (TARGET tgtexception, INSERTALLRECORDS, COLMAP (...) );

Exemples d'utilisation de REPERROR globalement et dans une instruction MAP

Les exemples suivants montrent différentes façons dont REPERROR peut être utilisé dans une instruction MAP conjointement avec une instruction REPERROR globale.

Exemple 1

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error1>, <response2>);
MAP <src2>, TARGET <tgt2>, REPERROR (<error2>, <response3>);

Dans l'exemple précédent, lorsque error1 se produit pour la première instruction MAP, l'action doit être response2, et non response1, car un remplacement a été indiqué. Toutefois, si une valeur error1 se produit pour la deuxième instruction MAP, la réponse doit être response1, la réponse globale. La réponse pour error2 serait response3, qui est propre à MAP.

Exemple 2

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error2>, <response2>),
REPERROR (<error3>, <response3>);

Dans l'exemple précédent, lors de la réplication de src1 vers src2, toutes les erreurs et actions (1-3) doivent s'appliquer, car toutes les instructions REPERROR traitent des erreurs différentes (il n'y a pas de remplacements propres à MAP).

Exemple 3

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error1>, <response2>);
MAP <src2>, TARGET <tgt2>, REPERROR (<error2>, <response3>);
REPERROR (<error1> , <response4>)
MAP <src2>, TARGET <tgt2>, REPERROR (<error3>, <response3>);

Dans l'exemple précédent, si error1 se produit pour la première instruction MAP, l'action doit être response2. Pour la deuxième, il s'agirait de response1 (réponse globale) et pour la troisième, de response4 (en raison de la deuxième instruction REPERROR). Une instruction REPERROR globale s'applique à toutes les instructions MAP qui la suivent dans le fichier de paramètres jusqu'à ce qu'une autre instruction REPERROR démarre de nouvelles règles.

Exemple 4

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSDISCARD.
MAP src, TARGET tgt, REPERROR(600 TRANSDISCARD);

Dans l'exemple précédent, si l'erreur 600 est détectée lors de l'application de la table source src à la table cible tgt, la transaction entière est écrite dans le fichier de rebut. La rencontre de l'erreur 1403 entraîne également la même action en fonction de la spécification globale REPERROR. Sur les autres erreurs, le processus supprime simplement l'enregistrement incriminé, puis abandonne.