TABLE | MAP

Durée de validité

TABLE est valide pour le processus d'extraction. Vous pouvez utiliser TABLE avec le processus de réplication uniquement avec le paramètre EVENTACTIONS. MAP est valide pour l'extraction dans certains cas et pour la réplication. Pour plus d'informations, reportez-vous à MAP pour l'extraction.

Description

Les paramètres TABLE et MAP contrôlent la sélection, le mapping et la manipulation des objets qui doivent être affectés par un processus Oracle GoldenGate. Ces paramètres fonctionnent comme suit :

TABLE et MAP sont valides pour les configurations de chargement initial et pour les processus en ligne configurés pour prendre en charge la réplication des modifications transactionnelles.

Vous pouvez traiter les objets suivants avec TABLE et MAP :

Pour indiquer une séquence pour la capture par le processus Extract, utilisez le paramètre SEQUENCE.

Remarque : Oracle GoldenGate prend en charge la réplication des valeurs de données réelles des vues matérialisées Oracle.

Vous pouvez utiliser une ou plusieurs instructions TABLE ou MAP dans un fichier de paramètres, avec ou sans caractères génériques, pour indiquer tous les objets à traiter.

Vous pouvez exclure des objets d'une instruction TABLE ou MAP avec des caractères génériques avec les paramètres suivants :

Valeur par défaut

Aucun

Syntaxe de TABLE

Pour les tables, vous pouvez utiliser toutes les options TABLE. Pour les objets non table, utilisez TABLE uniquement pour indiquer un objet à capturer.

TABLE <source_table>[, TARGET <target_table>]
[, ATTRCHARSET (<charset>)]
[, CHARSET <character_set>]
[, COLCHARSET <character_set>]
[, COLMAP (<column_mapping>)]
[, {COLS | COLSEXCEPT} (<column_list>)]
[, {DEF | TARGETDEF} <template>]
[, EVENTACTIONS <action>]
[, EXITPARAM '<parameter>']
[, {FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)]
[, {FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)]
[, FETCHBEFOREFILTER]
[, FILTER (<filter_clause>)]
[, GETBEFORECOLS (<column_specification>)]
[, KEYCOLS (<columns>)]
[, SQLEXEC (<SQL_specification>)]
[, SQLPREDICATE 'WHERE <where_clause>']
[, TOKENS (<token_definition>)]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Syntaxe pour MAP

MAP <source_table>, TARGET <target_table>
[, MOD_COMPARE_COLS( <tgt_col> = <source> )]
[, COLMAP (<column_mapping>)]
[, COMPARECOLS (<column_specification>)]
[, COORDINATED]
[, {DEF | TARGETDEF} <template>]
[, EXCEPTIONSONLY]
[, EXITPARAM '<parameter>']
[, EVENTACTIONS (<action>)]
[, FILTER (<filter_clause>)]
[, HANDLECOLLISIONS | NOHANDLECOLLISIONS]
[, INSERTALLRECORDS]
[, INSERTAPPEND | NOINSERTAPPEND]
[, KEYCOLS (<columns>)]
[, MAPALLCOLUMNS | NOMAPALLCOLUMNS]
[, MAPEXCEPTION (<exceptions_mapping>)]
[, MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS]
[, REPERROR (<error>, <response>)]
[, RESOLVECONFLICT (<conflict_resolution_specification>)]
[, SQLEXEC (<SQL_specification>)]
[, THREAD (<thread_ID>)]
[, THREADRANGE (<thread_range>[, <column_list>])]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Options TABLE et MAP

Le tableau suivant récapitule les options disponibles pour les paramètres TABLE et MAP. Notez que toutes les options ne sont pas valides pour les deux paramètres.

Tableau 11 : Récapitulatif des composants de syntaxe TABLE et MAP

Composant Description Durée de validité
MAP MOD_COMPARE_COL( tgt_col = source [,...] ) Il s'agit d'un paramètre de réplication uniquement. Affecte la valeur source indiquée à l'image avant de la colonne cible en tant que valeur de clé, et la valeur est utilisée pour la clause WHERE. MAP
TABLE <source_table>[, TARGET <target>] Indique l'objet source dans une instruction TABLE pour l'extraction et une mise en correspondance facultative avec un objet cible. A utiliser dans le fichier de paramètres Extract. TABLE
MAP source_table, TARGET target_table Spécifie le mapping d'objet source-cible pour le processus Replicat. A utiliser dans le fichier de paramètres Replicat. MAP
ATTRCHARSET (charset) spécifie les informations du jeu de caractères source au niveau de l'attribut UDT. TABLE
COLCHARSET character_set Spécifie tout jeu de caractères pris en charge. TABLE
COLMAP (column_mapping) Mappe les enregistrements entre différentes colonnes source et cible. TABLE et MAP
{COLS \| COLSEXCEPT} (column_list) Sélectionne ou exclut les colonnes à traiter. TABLE
COMPARECOLS (column_specification) Indique les colonnes à utiliser pour la détection et la résolution des conflits. TABLE et MAP
COORDINATED Force le traitement d'une transaction en tant que transaction barrière. MAP
{DEF | TARGETDEF} template Spécifie un modèle de définition de source ou de cible. TABLE et MAP
EXCEPTIONSONLY Indique que l'instruction MAP est une instruction MAP d'exception. MAP
EVENTACTIONS (action) Déclenche une action basée sur un enregistrement qui satisfait à une règle de filtre spécifiée. TABLE et MAP
EXITPARAM 'parameter' Transmet un paramètre sous la forme d'une chaîne littérale à un user exit. TABLE et MAP
FETCHBEFOREFILTER Indique l'action FETCHCOLS ou FETCHCOLSEXCEPT à exécuter avant l'exécution d'un filtre. TABLE
{FETCHCOLS | FETCHCOLSEXCEPT} (column_list) Permet d'extraire des valeurs de colonne de la base de données source lorsque les valeurs ne figurent pas dans l'enregistrement de transaction. TABLE
{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (column_list) Force l'extraction des valeurs de colonne à partir de la base de données lorsque les colonnes sont présentes dans le journal des transactions. TABLE
FILTER (filter_clause) Sélectionne les enregistrements en fonction d'une valeur numérique. FILTER offre plus de flexibilité que WHERE. TABLE, MAP
GETBEFORECOLS (column_specification) Force les images des colonnes avant d'être capturées et écrites dans la trace. TABLE
HANDLECOLLISIONS \| NOHANDLECOLLISIONS Rapproche les résultats des modifications apportées à la table cible par un processus de chargement initial de ceux appliqués par un groupe de synchronisation des modifications. MAP
INSERTALLRECORDS Applique toutes les modifications de ligne sous forme d'insertions. MAP
INSERTAPPEND \| NOINSERTAPPEND Contrôle si le processus Replicat utilise ou non un conseil Oracle APPEND pour les instructions INSERT. MAP
KEYCOLS (columns) Désigne les colonnes qui identifient les lignes de manière unique. TABLE et MAP
MAPALLCOLUMNS | NOMAPALLCOLUMNS Contrôle si le processus Replicat obtient ou non des colonnes non clé. S/O
MAPEXCEPTION (exceptions_mapping) Indique que l'instruction MAP contient la gestion des exceptions pour les tables avec caractères génériques. MAP
MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS Détermine si le processus Replicat inclut ou non des colonnes invisibles dans les tables cible Oracle pour le mapping de colonnes par défaut. Pour les colonnes invisibles dans les tables cible Oracle qui utilisent une mise en correspondance de colonnes explicite, elles sont toujours mises en correspondance. Par conséquent, cette option n'est pas requise. MAP
REPERROR (error, response) Contrôle la façon dont le processus Replicat répond aux erreurs lors de l'exécution de l'instruction MAP. MAP
RESOLVECONFLICT (conflict_resolution_specification) Spécifie les règles de résolution des conflits. MAP
SQLEXEC (SQL_specification) Exécute les procédures stockées et les requêtes. TABLE et MAP
SQLPREDICATE 'WHERE where_clause' Active une clause WHERE pour sélectionner des lignes pour un chargement initial. TABLE
THREAD (thread_ID) Valide pour la réplication en mode coordonné. Indique que l'instruction MAP sera traitée par le thread de réplication indiqué. MAP
THREADRANGE (thread_range, column_list) Valide pour la réplication en mode coordonné. Indique que l'instruction MAP sera traitée par la plage indiquée de threads de réplication. MAP
TOKENS (token_definition) Définit les jetons utilisateur. TABLE
TRIMSPACES \| NOTRIMSPACES Détermine si les espaces de fin sont tronqués ou non lors de la mise en correspondance de colonnes CHAR avec des colonnes VARCHAR. TABLE et MAP
TRIMVARSPACES \| NOTRIMVARSPACES Détermine si les espaces de fin sont tronqués ou non lors de la mise en correspondance de VARCHAR avec des colonnes CHAR ou VARCHAR. TABLE et MAP
WHERE (clause) Sélectionne les enregistrements en fonction des opérateurs conditionnels. TABLE et MAP
; (Semicolon) met fin à l'instruction TABLE ou MAP et est requis. TABLE et MAP
PARTITIONOBJID Disponible pour l'extraction intégrée. Cette option permet de spécifier les ID objet des partitions à capturer pour les tables partitionnées. TABLE et MAP

MAP MOD_COMPARE_COL( tgt_col = source [,…] )

tgt_col doit être le nom de la colonne de table cible et la colonne de clé doit être appliquée correctement. source peut être une colonne de table source, une valeur constante (nombre ou chaîne), une fonction de mapping de colonne ou des résultats SQLEXEC. Par exemple, source col1 est mis en correspondance avec target col 1. source col1 avant que la valeur d'image ne soit égale à 1, ce qui est une valeur fictive car elle est masquée par le DBA pour des raisons de sécurité. Le processus Replicat peut interroger la valeur d'image réelle avant target col1 par SQLEXEC. A l'aide de MOD_COMPARE_COLS(), le processus de réplication remplace la valeur source col1 fictive par le résultat SQLEXEC, de sorte que le fonctionnement de UPDATE ou DELETE fonctionne correctement.

TABLE <source_table>[, TARGET <target>]

TABLE est valide dans un fichier de paramètres d'extraction.

Utilisez TABLE pour indiquer un objet source pour lequel le processus d'extraction doit capturer des données. Indiquez le nom qualifié complet en deux ou en trois parties de l'objet, tel que <schema.table> ou <catalog.schema.table>. Vous pouvez utiliser un caractère générique pour indiquer plusieurs objets avec une instruction TABLE. Pour indiquer correctement les noms d'objet et les caractères génériques, reportez-vous à Utilisation de caractères génériques dans les noms d'objet de base de données et à Utilisation de caractères génériques dans les arguments de commande dans la documentation des microservices Oracle GoldenGate.

Utilisez l'option TARGET uniquement lorsque le processus d'extraction doit faire référence à un fichier de définitions cible (indiqué avec le paramètre TARGETDEFS) pour effectuer des conversions ou lorsque l'option COLMAP est utilisée pour mettre en correspondance des colonnes. Sinon, il peut être omis dans un paramètre TABLE. Le mappage des colonnes avec COLMAP et le travail de conversion sont généralement effectués sur le système cible afin de minimiser l'impact des activités de réplication sur le système source, mais peuvent être effectués sur le système source si nécessaire. Par exemple, le mappage et la conversion de colonnes peuvent être effectués sur le système source dans une configuration où il existe plusieurs sources et une cible. Dans ce scénario, il peut être plus facile de gérer un fichier de définitions cible plutôt que de gérer un fichier de définitions pour chaque base de données source, en particulier si des modifications fréquentes de l'application nécessitent la génération de nouveaux fichiers de définitions.

L'utilisation de TARGET dans un paramètre TABLE identifie les métadonnées des données extraites en fonction de la structure cible, plutôt que de celle de la source, afin de refléter la structure de l'enregistrement qui est reflétée dans le fichier de définitions ou la correspondance de colonnes. N'utilisez pas de noms en trois parties si TARGET indique des tables dans une base de données Conteneur Oracle cible. Le processus Replicat ne peut se connecter qu'à un seul conteneur ou catalogue. Par conséquent, il est supposé que la partie conteneur ou catalogue du nom est identique à celle dans laquelle le processus Replicat se connecte (comme indiqué avec USERIDALIAS, en fonction de la base de données).

Si aucune autre option de syntaxe TABLE n'est requise pour traiter les données source indiquées, vous pouvez utiliser une instruction TABLE simple, en veillant à l'arrêter par un point-virgule.

 TABLE sales.customers;

L'exemple suivant illustre l'utilisation d'un caractère générique pour spécifier plusieurs tables :

 TABLE sales.*;

Les instructions TABLE précédentes indiquent au processus Extract de capturer toutes les données de colonne prises en charge pour les objets indiqués et de les écrire dans la trace sans effectuer de filtrage, de conversion ou d'autres manipulations.

MAP <source_table>, TARGET <target_table>

MAP est valide dans un fichier de paramètres de réplication. Vous pouvez également utiliser MAP dans un fichier de paramètres d'extraction pour modifier le nom des transactions stockées par Oracle GoldenGate pour la table. Voir

Utilisez MAP pour indiquer un objet source et TARGET pour indiquer l'objet cible auquel le processus de réplication applique les données source répliquées. Ensemble, les clauses MAP et TARGET constituent un mapping.

L'exemple suivant illustre l'utilisation d'un caractère générique pour spécifier plusieurs tables. La clause TARGET n'inclut pas le préfixe tab avant le caractère générique. Cette spécification ne serait pas valide, car le caractère générique serait résolu en tant que sales.tabtab1, sales.tabtab2, etc.

 MAP sales.tab*, TARGET sales.*;

Si aucun filtrage, mapping ou autre travail n'est requis pour les objets, vous pouvez utiliser des instructions MAP simples comme suit, en veillant à mettre fin à chacune d'entre elles par un point-virgule.

MAP sales.customers, TARGET sales.customers;
MAP fin.*, TARGET fin.*;

ATTRCHARSET <(charset)>

ATTRCHARSET est valide pour TABLE.

Utilisez la clause ATTRCHARSET pour indiquer les informations du jeu de caractères source au niveau de l'attribut UDT. Il remplace le jeu de caractères défini dans le fichier trace ou indiqué par les paramètres SOURCECHARSET, CHARSET ou COLCHARSET.

Les valeurs valides sont les noms de jeu de caractères et les noms d'attribut UDT valides. Les noms d'attribut avec caractères génériques sont pris en charge. Exemple :

TABLE SCHEMA.T*,
  ATTRCHARSET(WE8DEC, col*.attr1, col1.attr*.attr3);

COLCHARSET <character_set>

COLCHARSET est valide pour TABLE.

Utilisez la clause COLCHARSET pour indiquer tout jeu de caractères pris en charge. Pour plus d'informations, reportez-vous à COLCHARSET.

COLMAP <(column_mapping)>

COLMAP est valide pour TABLE et MAP.

Utilisez COLMAP pour :

COLMAP fournit des instructions pour sélectionner, traduire et déplacer des données de colonne d'une colonne source vers une colonne cible. Remarque : pour créer des règles globales pour la mise en correspondance de colonnes entre toutes les tables dans les instructions MAP suivantes, utilisez le paramètre COLMATCH.

Obtention d'informations supplémentaires sur la configuration du mappage de colonnes

Pour utiliser COLMAP, les instructions de configuration associées doivent être prises en compte, par exemple si les structures de colonne source et cible sont identiques ou différentes et si les paramètres de mise en correspondance de colonne globale peuvent être suffisants.

Syntaxe

COLMAP (
[USEDEFAULTS, ]
<target_column> = <source_expression> [BINARYINPUT]
[, ...]
)

USEDEFAULTS

Met automatiquement en correspondance les colonnes source et cible portant le même nom si elles n'ont pas été spécifiées dans un mapping de colonne explicite. Les types de données sont convertis automatiquement, selon les besoins, en fonction du fichier de définitions de données local. USEDEFAULTS élimine la nécessité d'un mapping de colonne explicite si ces colonnes portent le même nom et que les données ne nécessitent aucun filtrage ou conversion.

Indiquez USEDEFAULTS avant les mappings de colonne explicites dans la clause COLMAP.

<target_column = source_expression>

Définit un mapping de colonne source-cible explicite.

<target_column>

Indique le nom de la colonne cible. Pour connaître les caractères pris en charge dans les noms de colonne, reportez-vous à Jeux de caractères pris en charge.

<source_expression>

Il peut s'agir de l'un des éléments suivants :

BINARYINPUT

Utilisez BINARYINPUT lorsque la colonne cible est définie en tant que type de données binaires, tel que RAW ou BLOB, mais que l'entrée source contient des zéros binaires au milieu des données. L'entrée source est gérée en tant qu'entrée binaire et le remplacement des valeurs de données est supprimé.

Exemple 1

MAP ggs.tran, TARGET ggs.tran2, COLMAP (loc2 = loc, type2 = type);

Exemple 2

TABLE ggs.tran, COLMAP (SECTION = @STRCAT('\u00a7', SECTION ));

{COLS | COLSEXCEPT} (<column_list>)

COLS et COLSEXCEPT sont valides pour TABLE.

Utilisez COLS et COLSEXCEPT pour contrôler les colonnes pour lesquelles les données sont capturées.

Pour utiliser COLS, les éléments suivants sont requis :

Sans clé primaire, clé unique ou clause KEYCOLS dans l'instruction TABLE, Oracle GoldenGate utilise toutes les colonnes de la table, ce qui rend COLS inutile.

Remarque : N'utilisez pas cette option pour les tables qui sont traitées en mode de transmission par un groupe Extract Data Pump.

Syntaxe

{COLS | COLSEXCEPT} (<column> [, ...])

<column>

Nom d'une colonne. Pour indiquer plusieurs éléments <columns>, créez une liste délimitée par des virgules, par exemple :

COLS (name, city, state, phone)

Remarque : si la base de données consigne uniquement les valeurs des colonnes qui ont été modifiées lors d'une opération de mise à jour, il se peut qu'une colonne indiquée pour la capture avec COLS ne soit pas disponible. Pour rendre ces colonnes disponibles, utilisez l'option FETCHCOLS dans l'instruction TABLE ou activez la journalisation supplémentaire pour la colonne.

Exemple

Dans cet exemple, COLS <clause> capture uniquement <columns> 1 et 3, tandis que COLSEXCEPT <clause> capture tous les éléments <columns> à l'exception de <columns> 1 et 3.

TABLE hq.acct, COLS (col1, col3);
TABLE hq.sales, COLSEXCEPT (col1, col3);

COMPARECOLS (<column_specification>)

COMPARECOLS est valide pour MAP.

Utilisez COMPARECOLS pour indiquer les colonnes que le processus de réplication utilise pour détecter et résoudre les conflits de mise à jour ou de suppression lorsqu'il est configuré avec l'option RESOLVECONFLICT de MAP dans une configuration multimaître. Un conflit est une non-concordance entre l'image "avant" d'un enregistrement dans la trace (trail) et les données appropriées dans la table cible.

Pour utiliser COMPARECOLS, l'image "avant" doit être disponible dans l'enregistrement de trace au moyen du paramètre GETBEFORECOLS dans l'instruction TABLE d'extraction. Les colonnes indiquées doivent exister dans la base de données cible et faire partie de la configuration du processus Replicat (conformément à la spécification TARGET avec ou sans clause COLMAP).

Seuls les types de données scalaires sont pris en charge par COMPARECOLS en tant que colonnes de comparaison. Un type de données scalaire peut être utilisé dans une clause WHERE, possède une valeur atomique unique et aucun composant interne. Les types de données scalaires pris en charge par Oracle GoldenGate incluent les objets LOB suivants, mais pas ceux-ci.

Les types de données non scalaires sont par exemple les données spatiales, les types de données définis par l'utilisateur, les objets LOB (LOB), XML, les types de données de référence et RAW. Une ligne prise en compte pour CDR peut inclure des données non scalaires tant que le conflit ne se trouve pas dans les données non scalaires elles-mêmes.

Pour spécifier des routines de résolution de conflit, utilisez l'option RESOLVECONFLICT de MAP. COMPARECOLS et RESOLVECONFLICT peuvent se trouver dans n'importe quel ordre dans l'instruction MAP.

Pour plus d'informations sur la configuration de la fonction CDR

Pour plus d'informations sur la configuration de la détection et de la résolution des conflits, reportez-vous à Détection et résolution automatiques de conflits ou à Détection et résolution manuelles de conflits.

Syntaxe

COMPARECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Indique si l'image "avant" des colonnes indiquées doit être comparée pour les mises à jour ou les suppressions. Vous pouvez utiliser ON UPDATE uniquement, ON DELETE uniquement ou les deux. Si vous utilisez les deux, indiquez-les dans la même clause COMPARECOLS. Reportez-vous à l'exemple pour savoir comment utiliser les deux.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...])}

Indique les colonnes pour lesquelles une image "avant" est capturée.

ALL

Effectue une comparaison à l'aide de toutes les colonnes de la table cible. Une erreur est générée si aucune image avant correspondante n'est disponible dans la trace. L'utilisation de ALL impose la charge de traitement la plus élevée pour Replicat, mais permet d'effectuer des comparaisons de détection de conflit à l'aide de toutes les colonnes pour une précision maximale.

KEY

Compare uniquement les colonnes de clé primaire. Il s'agit de l'option la plus rapide, mais elle ne permet pas la détection de conflit la plus précise, car les clés peuvent correspondre mais les colonnes sans clé peuvent être différentes.

KEYINCLUDING

Compare les colonnes de clé primaire et les colonnes indiquées. Il s'agit d'un compromis raisonnable entre la vitesse et la précision de détection.

ALLEXCLUDING

Compare toutes les colonnes à l'exception des colonnes indiquées. Pour les tables comportant de nombreuses colonnes, ALLEXCLUDING peut être plus efficace que KEYINCLUDING. N'excluez pas les colonnes de clé.

Exemple 1

Dans l'exemple suivant, les colonnes de clé plus les colonnes name, address et salary sont comparées pour les conflits.

MAP src, TARGET tgt
COMPARECOLS (
ON UPDATE KEYINCLUDING (name, address, salary),
ON DELETE KEYINCLUDING (name, address, salary));

Exemple 2

Dans l'exemple suivant, la colonne comment est ignorée et toutes les autres colonnes sont comparées pour les conflits.

MAP src, TARGET tgt
COMPARECOLS (ON UPDATE ALLEXCLUDING (comment))

COORDONNÉ

COORDINATED est valide pour MAP. Cette option est valide lorsque le processus Replicat est en mode coordonné.

Utilisez l'option COORDINATED pour forcer le traitement des transactions effectuées sur les objets de la même instruction MAP en tant que transactions barrière. Tous les threads de toutes les instructions MAP sont synchronisés au même emplacement de trace. La position synchronisée est le début de la transaction qui contient un enregistrement qui satisfait à une valeur MAP contenant le mot-clé COORDINATED. La transaction est ensuite appliquée atomiquement par un seul thread, qui est soit le thread avec le thread le plus bas ID parmi les threads en cours d'exécution, soit un thread dédié avec ID sur 0 si USEDEDICATEDCOORDINATIONTHREAD est spécifié dans le fichier de paramètres.

Les clauses THREAD et THREADRANGE spécifiées conjointement avec COORDINATED sont ignorées car l'enregistrement ne sera pas appliqué par les threads désignés. Le mot-clé COORDINATED entraîne la suspension temporaire du parallélisme afin que les tables cible soient dans un état cohérent avant que la transaction coordonnée de force ne soit appliquée. Après ce point, l'exécution parallèle recommence.

Par défaut, la réplication coordonne les transactions dans lesquelles la clé primaire est mise à jour, les transactions qui exécutent DDL et certaines actions EVENTACTIONS. COORDINATED prévoit une coordination explicite.

Pour plus d'informations, reportez-vous à A propos de la réplication coordonnée.

Syntaxe

COORDINATED

Exemple

L'exemple suivant illustre l'utilisation de l'option COORDINATED. Dans cet exemple, les règles métier exigent que les tables cible soient dans un état cohérent avant que le processus Replicat exécute les transactions qui incluent des opérations SQLEXEC sur les objets indiqués dans l'instruction MAP. Dans ce cas, le parallélisme doit être converti temporairement en traitement SQL série.

Compte tenu de l'instruction MAP suivante, si un autre thread insère dans t2 un enregistrement avec une valeur de 100 pour col_val avant que l'insertion dans t1 ne soit effectuée par le thread 1, SQLEXEC supprime la ligne. Si d'autres threads traitent toujours l'enregistrement dont la valeur est 100, SQLEXEC échoue. Les résultats de cette instruction MAP ne sont donc pas prévisibles.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1);

Inversement, lorsque COORDINATED est utilisé, tous les threads se synchronisent à un point commun, y compris celui qui traite l'enregistrement col_val=100, éliminant ainsi l'ambiguïté des résultats.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1), COORDINATED;

{DEF| TARGETDEF}<template>

DEF et TARGETDEF sont valides pour TABLE et MAP.

Utilisez DEF et TARGETDEF pour indiquer le nom d'un modèle de définitions créé par l'utilitaire DEFGEN.

Un modèle est basé sur les définitions d'une table spécifique. Elle permet d'ajouter de nouvelles tables qui ont les mêmes définitions que la table d'origine à la configuration Oracle GoldenGate sans exécuter DEFGEN pour elles, et sans avoir à arrêter et démarrer le processus Oracle GoldenGate. Les définitions du modèle sont utilisées pour les codes express de définitions.

Syntaxe

{DEF | TARGETDEF} <template>

<template>

Nom de l'un des modèles de définition suivants généré par l'utilitaire DEFGEN :

Les définitions contenues dans le modèle doivent être identiques aux définitions de la ou des tables spécifiées dans la même instruction TABLE ou MAP.

La distinction majuscules/minuscules entre les noms de modèle est observée lorsque le nom est indiqué de la même manière qu'il est stocké dans la base de données. Assurez-vous que le nom du modèle est indiqué de la même manière dans la clause DEF ou TARGETDEF de cette instruction TABLE ou MAP et dans le fichier de paramètres DEFGEN qui a créé le modèle.

Exemple 1

Cet exemple montre un nom de modèle non sensible à la casse.

MAP acct.cust*, TARGET acct.cust*, DEF custdef;

Exemple 2

Cet exemple montre un nom de modèle sensible à la casse lorsque la base de données requiert des guillemets pour appliquer la distinction majuscules/minuscules.

  TABLE acct.cust*, DEF "CustDef";

Exemple 3

Cet exemple illustre un cas où DEF et TARGETDEF sont utilisés.

  MAP acct.cust*, TARGET acc.cust*, DEF custdef, TARGETDEF tcustdef;

EXCEPTIONS UNIQUEMENT

EXCEPTIONSONLY est valide pour MAP.

Utilisez EXCEPTIONSONLY dans une instruction MAP d'exception destinée à la gestion des erreurs. L'instruction MAP des exceptions doit suivre l'instruction MAP pour laquelle des erreurs sont anticipées. L'instruction MAP des exceptions s'exécute uniquement si une erreur se produit pour le dernier enregistrement traité dans l'instruction MAP standard précédente.

Pour utiliser EXCEPTIONSONLY, utilisez une instruction REPERROR avec l'option EXCEPTION dans l'instruction MAP standard ou à la racine du fichier de paramètres. Pour plus d'informations, reportez-vous à REPERROR. Remarque : si vous utilisez la fonctionnalité CDR (Conflict Detection and Resolution) d'Oracle GoldenGate, il n'est pas nécessaire d'utiliser une valeur REPERROR avec EXCEPTION. Le référentiel CDR envoie automatiquement toutes les opérations qui génèrent des erreurs à l'instruction MAP des exceptions.

L'instruction MAP des exceptions doit indiquer la même table source que dans l'instruction MAP standard, mais la table cible dans l'instruction MAP des exceptions doit être une table d'exceptions.

Remarque : reportez-vous à "MAPEXCEPTION (exceptions_mapping)" pour prendre en charge les noms d'objet avec caractères génériques.

Syntaxe

EXCEPTIONSONLY

EVENTACTIONS (<action>)

EVENTACTIONS est valide pour TABLE et MAP. Certaines options s'appliquent uniquement à l'un ou l'autre paramètre et sont indiquées comme telles dans les descriptions.

Utilisez EVENTACTIONS pour que le processus effectue une action définie en fonction d'un enregistrement de la trace, appelé enregistrement d'événement, qui répond aux critères d'une règle de filtre spécifique. Vous pouvez utiliser ce système, appelé système de marqueurs d'événements (ou infrastructure de marqueurs d'événements), pour personnaliser le traitement en fonction des événements de base de données. Par exemple, vous pouvez suspendre un processus pour effectuer une transformation ou générer des statistiques. La fonctionnalité de marqueur d'événement est prise en charge pour la réplication des modifications de données, mais pas pour les chargements initiaux.

Pour déclencher des actions qui ne nécessitent pas l'application de données aux tables cible, vous pouvez utiliser le paramètre TABLE de réplication avec des options de filtrage qui prennent en charge EVENTACTIONS. Pour plus d'informations, reportez-vous à TABLE pour le processus Replicat.

Vous devrez peut-être combiner deux actions ou plus pour atteindre vos objectifs. Lorsque plusieurs actions sont combinées, l'instruction EVENTACTIONS entière est analysée en premier, puis les options indiquées sont exécutées par ordre de priorité. La liste suivante indique l'ordre de priorité. Les actions répertoriées avant Process the record se produisent avant que l'enregistrement ne soit écrit dans la trace ou appliqué à la cible (selon le processus). Les actions répertoriées après Process the record sont exécutées une fois l'enregistrement traité.

Pour empêcher le traitement normal de l'enregistrement d'événement lui-même, utilisez l'option IGNORE ou DISCARD. Etant donné que IGNORE et DISCARD sont évalués avant l'enregistrement lui-même, ils empêchent le traitement de l'enregistrement. Sans ces options, EVENTACTIONS pour le processus Extract écrit l'enregistrement dans la trace, et EVENTACTIONS pour le processus Replicat applique cette opération à la base de données cible.

Vous devez tenir compte de la possibilité qu'une transaction puisse contenir au moins deux enregistrements qui déclenchent une action d'événement. Dans ce cas, il peut y avoir plusieurs exécutions de certaines spécifications EVENTACTIONS. Par exemple, le fait de rencontrer deux enregistrements admissibles qui déclenchent deux actions ROLLOVER successives entraînera le basculement du processus Extract sur la trace deux fois, laissant l'un des deux fichiers vide de données de transaction.

Vous devez également tenir compte du fait que lorsque le paramètre GETUPDATEBEFORES est activé, deux enregistrements sont générés pour les opérations UPDATE : un enregistrement qui contient l'image "avant" et un enregistrement qui contient l'image "après". Une action d'événement est déclenchée pour chacun de ces enregistrements lorsque l'opération est considérée comme un enregistrement d'événement. Vous pouvez utiliser le jeton BEFOREAFTERINDICATOR de la fonction de conversion de colonne GGHEADER comme filtre dans une clause FILTER pour qualifier les enregistrements de sorte que l'action d'événement ne se déclenche qu'une seule fois, soit sur l'enregistrement avant, soit sur l'enregistrement après, mais pas sur les deux.

L'exemple suivant filtre l'indicateur BEFORE. EVENTACTION émet la commande shell ECHO pour générer la chaîne 'Déclenchée sur BEFORE' dans le journal des événements lorsqu'un enregistrement BEFORE est rencontré.

TABLE qasource.test, &
FILTER(@STRFIND('BEFORE', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
EVENTACTIONS ( shell ('echo --== Triggered on BEFORE ==-- '), LOG);

Le résultat de l'événement <action> est le suivant :

013-03-06 17:59:31  INFO    OGG-05301  Shell command output: '--== Triggered
on AFTER ==--'

L'exemple suivant fait la même chose, mais pour l'indicateur AFTER.

 TABLE qasource.test, &
 FILTER(@STRFIND('AFTER', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
 EVENTACTIONS ( shell ('echo --== Triggered on AFTER ==-- '), LOG);

Syntaxe

EVENTACTIONS (
[STOP | SUSPEND | ABORT | FORCESTOP]
[IGNORE [RECORD | TRANSACTION [INCLUDEVENT]]
[DISCARD]
[LOG [INFO | WARNING]]
[REPORT]
[ROLLOVER]
[SHELL '<command>' | SHELL ('<command>', VAR <variable> = {<column_name> | <expression>}
  [, ...]) ]
[TRACE[2] <file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]]
[CHECKPOINT [BEFORE | AFTER | BOTH]]
[, ...]
)

STOP

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Arrêtez progressivement le processus lorsque l'enregistrement d'événement spécifié est détecté. Le processus attend que d'autres opérations de la transaction d'événement soient terminées avant de s'arrêter. Si la transaction est une transaction groupée ou en batch de réplication, le groupe de transactions en cours est appliqué avant l'arrêt progressif du processus. Le traitement redémarre à l'enregistrement suivant après l'enregistrement d'événement, à condition que cet enregistrement indique également la fin d'une transaction.

Le traitement consigne un message s'il ne peut pas s'arrêter immédiatement car une transaction est toujours ouverte. Toutefois, si l'enregistrement d'événement est détecté dans une transaction ouverte à longue durée d'exécution, aucun message d'avertissement ne vous avertit de l'état non validé de la transaction. Par conséquent, le processus peut rester en cours d'exécution pendant une longue période malgré l'événement STOP.

STOP peut être combiné avec d'autres options EVENTACTIONS, à l'exception de ABORT et FORCESTOP.

SUSPEND

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Suspend le processus de sorte qu'il conserve le contexte actif de l'exécution en cours et puisse toujours répondre aux commandes SEND émises dans le client Admin. Lorsqu'un processus est suspendu, la commande INFO l'affiche en tant que RUNNING et le champ RBA affiche la dernière position du point de reprise.

Pour reprendre le traitement, exécutez la commande SEND avec l'option RESUME.

Pour utiliser l'option CHECKPOINT BEFORE conjointement avec SUSPEND, l'enregistrement d'événement doit être le début d'une transaction pour que SUSPEND ait lieu. Ainsi, si le processus est arrêté alors qu'il est à l'état suspendu, l'enregistrement d'événement avec l'action SUSPEND est le premier enregistrement à retraiter au redémarrage. Si CHECKPOINT BERORE et SUSPEND sont indiqués, mais que l'enregistrement d'événement n'est pas le début d'une transaction, le processus se termine avant que SUSPEND ne puisse avoir lieu.

Pour utiliser l'option CHECKPOINT AFTER conjointement avec SUSPEND, vous devez exécuter la commande RESUME pour que le point de reprise puisse avoir lieu et que l'enregistrement d'événement soit un enregistrement COMMIT. Si le processus se termine alors qu'il est dans l'état SUSPEND, le processus retraite la transaction à partir de la dernière position de point de reprise au redémarrage.

SUSPEND ne peut pas être combiné avec ABORT mais peut être combiné avec toutes les autres options.

ABORT

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Force le processus à se fermer immédiatement lorsque l'enregistrement d'événement spécifié est détecté, qu'il y ait ou non des transactions en cours. L'enregistrement d'événement n'est pas traité. Une erreur fatale est écrite dans le journal et l'enregistrement d'événement est écrit dans le fichier de rebut si DISCARD est également spécifié. Le processus subira une récupération au démarrage.

ABORT peut être combiné uniquement avec CHECKPOINT BEFORE, DISCARD, SHELL et REPORT.

FORCESTOP

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Force le processus à s'arrêter progressivement lorsque l'enregistrement d'événement spécifié est détecté, mais uniquement si l'enregistrement d'événement est la dernière opération de la transaction ou le seul enregistrement de la transaction. L'enregistrement est écrit normalement.

Si l'enregistrement d'événement est détecté dans une transaction ouverte à longue durée d'exécution, le processus écrit un message d'avertissement dans le journal et se ferme immédiatement, comme dans ABORT. Dans ce cas, une récupération peut être nécessaire au démarrage. Si l'action FORCESTOP est déclenchée au milieu d'une transaction longue, le processus se ferme sans message d'avertissement.

FORCESTOP peut être combiné avec d'autres options EVENTACTIONS à l'exception de ABORT, STOP, CHECKPOINT AFTER et CHECKPOINT BOTH. Si elle est utilisée avec ROLLOVER, la reconduction ne se produit que si le processus s'arrête progressivement.

IGNORE [RECORD TRANSACTION [INCLUDEVENT]]

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Ignore tout ou partie de la transaction, en fonction de l'action sélectionnée.

IGNORE peut être combiné avec toutes les autres options EVENTACTIONS à l'exception de ABORT et DISCARD.

Une action IGNORE est traitée une fois toutes les opérations de qualification, de filtrage, de mise en correspondance et de sortie utilisateur traitées. L'enregistrement ou la transaction est ignoré dans la phase de sortie finale et empêche l'écriture de l'enregistrement ou de la transaction sur la cible de sortie (trail dans le cas de l'extraction ou de la base de données dans le cas de la réplication). Par conséquent, dans certaines expressions, par exemple celles qui incluent des opérations SQLEXEC, SQLEXEC est exécuté avant le traitement de IGNORE. Cela signifie que, bien que l'enregistrement ne soit pas écrit dans la trace ou la base de données cible, tous les effets du traitement de l'enregistrement via la qualification, le filtrage, le mappage et la sortie utilisateur se produiront.

Cette action n'est pas valide pour les enregistrements DDL. Les opérations DDL étant autonomes, ignorer un enregistrement équivaut à ignorer l'intégralité de la transaction.

DISCARD

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne le processus à :

Le traitement reprend avec l'enregistrement suivant dans la trace.

DISCARD peut être combiné avec toutes les autres options EVENTACTIONS à l'exception de IGNORE.

LOG [INFO WARNING]

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne le processus à consigner l'événement lorsque l'enregistrement d'événement spécifié est rencontré. Le message est écrit dans le fichier de rapport, dans le journal des erreurs Oracle GoldenGate et dans le journal des événements système.

Utilisez les options suivantes pour indiquer la gravité du message :

LOG peut être combiné avec toutes les autres options EVENTACTIONS à l'exception de ABORT. Si vous utilisez ABORT, LOG n'est pas nécessaire car ABORT consigne une erreur fatale avant la fermeture du processus.

REPORT

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Permet au traitement de générer un fichier d'état lorsque l'enregistrement d'événement indiqué est détecté. Cela revient à utiliser la commande SEND avec l'option REPORT dans GGSCI.

Le message REPORT survient après le traitement de l'enregistrement d'événement (sauf si DISCARD, IGNORE ou ABORT sont utilisés), de sorte que les données du rapport incluent l'enregistrement d'événement.

REPORT peut être combiné avec toutes les autres options EVENTACTIONS.

ROLLOVER

Valide dans TABLE pour l'extraction.

Le processus Extract transfère la trace vers un nouveau fichier lorsque l'enregistrement d'événement indiqué est détecté. L'action ROLLOVER se produit avant que le processus Extract n'écrive l'enregistrement d'événement dans le fichier trace, ce qui fait de l'enregistrement le premier dans le nouveau fichier, sauf si DISCARD, IGNORE ou ABORT sont également utilisés.

ROLLOVER peut être combiné avec toutes les autres options EVENTACTIONS à l'exception de ABORT. ROLLOVER ne peut pas être combiné avec ABORT car ROLLOVER n'entraîne pas l'écriture d'un point de reprise par le processus et ROLLOVER se produit avant ABORT.

Sans point de reprise (checkpoint) ROLLOVER, ABORT entraîne le passage de l'extraction à son point de reprise précédent au redémarrage, qui se trouverait dans le fichier trace précédent. En fait, cela annule le report.

SHELL '<command>'

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne le processus à exécuter la commande shell spécifiée lorsque l'enregistrement d'événement est rencontré. SHELL '<command'> exécute une commande shell de base. La chaîne de commande est prise à sa valeur littérale et envoyée au système de cette manière. La commande est sensible à la casse. Placez la chaîne de commande entre apostrophes, par exemple :

 EVENTACTIONS (SHELL 'echo hello world! > output.txt')

Si la commande shell réussit, le processus écrit un message d'information dans le fichier de rapport et dans le journal des événements. Le succès est basé sur le statut de sortie de la commande conformément au langage shell UNIX. Dans cette langue, zéro indique le succès.

Si l'appel système échoue, le processus s'interrompt avec une erreur fatale. Dans le langage shell UNIX, une valeur différente de zéro équivaut à une défaillance. Le message d'erreur concerne uniquement l'exécution de la commande SHELL elle-même, et non le statut de sortie d'une commande subordonnée. Par exemple, SHELL peut exécuter un script avec succès, mais les commandes de ce script peuvent échouer.

SHELL peut être combiné avec toutes les autres options EVENTACTIONS.

SHELL ('<command>', VAR <variable> = {<column_name> | <expression>} [, ...])

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne le processus à exécuter la commande shell spécifiée lorsque l'enregistrement d'événement est rencontré et prend en charge la transmission des paramètres. La commande et les paramètres sont sensible à la casse.

Lorsque SHELL est utilisé avec des arguments, l'intégralité de <command> et des chaînes d'argument doivent être placées entre parenthèses, par exemple :

 EVENTACTIONS (SHELL
 ('Current timestamp: $1  SQLEXEC result is $2 ',VAR $1 = @GETENV('JULIANTIMESTAMP'),
 VAR $2 = mytest.description));

L'entrée est la suivante :

<command>

Il s'agit de la commande qui est transmise littéralement au système.

VAR

Mot-clé requis qui démarre l'entrée du paramètre.

<variable>

Nom défini par l'utilisateur de la variable de réserve dans laquelle la valeur de la variable d'exécution sera remplacée. Les variables supplémentaires qui ne sont pas utilisées dans la commande sont ignorées. Tous les littéraux de la commande SHELL qui correspondent à un nom de variable VAR sont remplacés par la valeur VAR remplacée. Cela peut avoir des conséquences inattendues. Testez votre code avant de le mettre en production.

<column_name>

Il peut s'agir de l'image avant ou après (en cours) d'une valeur de colonne.

<expression>

peut être la suivante, selon que les données de colonne ou DDL sont gérées.

<TRACE[2]file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne l'écriture des informations de trace de processus dans un fichier trace lorsque l'enregistrement d'événement spécifié est détecté. TRACE fournit des informations de traitement détaillées. TRACE2 identifie les segments de code sur lesquels le processus passe le plus de temps.

Par défaut (sans options), la fonction de trace DML standard sans ligne directrice sur les limites de transaction est activée jusqu'à ce que le processus se termine.

TRACE peut être combiné avec toutes les autres options EVENTACTIONS à l'exception de ABORT.

Pour désactiver la fonction de trace dans le fichier trace spécifié, exécutez la commande processcommand GGSCI SEND avec l'option TRACE OFF <file_name>.

CHECKPOINT [BEFORE AFTER BOTH]

Valide dans TABLE pour l'extraction et dans MAP pour le processus Replicat.

Entraîne le processus à écrire un point de reprise lorsque l'enregistrement d'événement spécifié est rencontré. Les actions de point de reprise fournissent un contexte autour du traitement défini dans les instructions TABLE ou MAP. Ce contexte a un point de début et un point de fin, fournissant ainsi des points de synchronisation pour la mise en correspondance des fonctions exécutées avec SQLEXEC et les user exits.

BEFORE

BEFORE pour un processus Extract écrit un point de reprise avant que le processus Extract n'écrive l'enregistrement d'événement dans la trace. BEFORE pour un processus Replicat écrit un point de reprise avant que le processus Replicat applique l'opération SQL contenue dans l'enregistrement à la cible.

BEFORE exige que l'enregistrement d'événement soit le premier enregistrement d'une transaction. S'il ne s'agit pas du premier enregistrement, le processus est abandonné. Utilisez BEFORE pour vous assurer que toutes les transactions antérieures à celle qui commence par l'enregistrement d'événement sont validées.

Lorsque vous utilisez EVENTACTIONS pour un enregistrement DDL, notez que chaque enregistrement DDL étant autonome, l'enregistrement DDL est garanti comme étant le début d'une transaction. Par conséquent, l'action d'événement CHECKPOINT BEFORE est impliquée pour un enregistrement DDL.

CHECKPOINT BEFORE peut être combiné avec toutes les options EVENTACTIONS.

AFTER

AFTER pour le processus Extract écrit un point de reprise après que le processus Extract a écrit l'enregistrement d'événement dans la trace (trail). AFTER pour le processus Replicat écrit un point de reprise une fois que le processus Replicat a appliqué l'opération SQL contenue dans l'enregistrement à la cible.

AFTER marque la demande de point de reprise comme un conseil, ce qui signifie que le processus n'émettra un point de reprise qu'à la prochaine occasion pratique. Par exemple, dans le cas où l'enregistrement d'événement est une transaction à plusieurs enregistrements, le point de reprise aura lieu à la prochaine limite de transaction, conformément au modèle d'intégrité des données Oracle GoldenGate.

Lorsque vous utilisez EVENTACTIONS pour un enregistrement DDL, notez que chaque enregistrement DDL étant autonome, l'enregistrement DDL est garanti comme étant la fin (limite) d'une transaction. Par conséquent, l'action d'événement CHECKPOINT AFTER est impliquée pour un enregistrement DDL.

CHECKPOINT AFTER peut être combiné avec toutes les options EVENTACTIONS sauf ABORT.

BOTH

BOTH combine BEFORE et AFTER. Le processus Extract ou Replicat écrit un point de reprise avant et après le traitement de l'enregistrement d'événement.

CHECKPOINT BOTH peut être combiné avec toutes les options EVENTACTIONS sauf ABORT.

CHECKPOINT peut être abrégé en CP.

Exemple 1

L'exemple suivant montre comment configurer un processus pour ignorer certains enregistrements. Lorsque le processus d'extraction traite un enregistrement de trace ayant name = abc, il ignore l'enregistrement.

TABLE fin.cust, &
WHERE (name = 'abc'), &
EVENTACTIONS (ignore);

Exemple 2

En fonction des règles de compatibilité et de priorité des options EVENTACTIONS, DISCARD est plus prioritaire que ABORT. Dans cet exemple, l'enregistrement d'événement est écrit dans le fichier de rebut avant l'abandon du processus.

MAP fin.cust, TARGET fin.cust2, &
WHERE (name = 'abc'), &
EVENTACTIONS (DISCARD, ABORT);

Exemple 3

L'exemple suivant exécute une action SHELL. Elle obtient le résultat d'une requête SQLEXEC et l'associe à l'horodatage en cours.

TABLE src.tab &
SQLEXEC (id mytest, query 'select description from lookup &
where pop = :mycol2', params (mycol2 = col2) ), &
EVENTACTIONS (SHELL ('Current timestamp: $1  SQLEXEC result is $2 ', &
VAR $1 = @GETENV('JULIANTIMESTAMP'), VAR $2 = mytest.description));

Le shell <command> résultant de cet exemple peut être similaire à ce qui suit :

'Current timestamp: 212156002704718000  SQLEXEC result is test passed'

Exemple 4

L'exemple suivant montre comment des résultats non valides peuvent se produire si un nom d'espace réservé entre en conflit avec le texte littéral dans la chaîne de commande. Dans cet exemple, un espace réservé nommé $1 est associé à une valeur de colonne et la commande SHELL fait écho à une chaîne littérale qui inclut $1.

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $1 is $1', VAR $1 = COL1));

Il s'agit du résultat inattendu, en supposant que la valeur <column> est gift wrap :

'Extra charge for gift wrap is gift wrap'

La modification de l'espace réservé <variable> en $col génère le résultat correct :

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $col is $1', VAR $col = COL1));
'Extra charge for gift wrap is $1'

Ce qui suit présente un potentiel similaire pour des résultats inattendus :

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('Timestamp: $1  Price is $13 > out.txt ', &
VAR $1 = @GETENV('JULIANTIMESTAMP')));

La sortie redirigée <file> peut contenir une valeur <string> comme celle-ci (remarquez que le deuxième horodatage contient la valeur ajoutée 3) :

'Timestamp: 212156002704718000 Price is 2121560027047180003'

Le résultat escompté est le suivant :

'Timestamp: 212156002704718000 Price is $13'

Exemple 5

Ces exemples montrent différentes façons de configurer la fonction de trace.

MAP tab1, TARGET tab1 EVENTACTIONS (TRACE ./dirrpt/trace
1.txt);
MAP tab2, TARGET tab2 EVENTACTIONS (TRACE ./dirrpt/trace2.txt TRANSACTION);

Exemple 6

L'exemple suivant montre comment EVENTACTIONS avec SUSPEND peut être utilisé.

EXITPARAM '<parameter>'

EXITPARAM est valide pour TABLE et MAP.

Utilisez EXITPARAM pour transmettre un paramètre à la fonction EXIT_PARAMS d'une routine d'exit utilisateur chaque fois qu'un enregistrement de l'instruction TABLE ou MAP est rencontré.

Syntaxe

EXITPARAM '<parameter string>'

<'parameter string'>

Paramètre qui est une chaîne littérale. Placez le paramètre entre apostrophes. Vous pouvez spécifier jusqu'à 100 caractères pour la chaîne de paramètre.

EXTRAIREAVANTFILTRE

FETCHBEFOREFILTER est valide pour TABLE.

Utilisez FETCHBEFOREFILTER pour extraire les colonnes indiquées avec FETCHCOLS ou FETCHCOLSEXCEPT avant l'exécution d'une opération FILTER. L'extraction avant le filtre garantit que les valeurs requises pour le filtre sont disponibles. Sans FETCHBEFOREFILTER, les extractions indiquées avec FETCHCOLS ou FETCHCOLSEXCEPT ne sont pas effectuées tant que les filtres n'ont pas été exécutés. Indiquez FETCHBEFOREFILTER avant FILTER dans le fichier de paramètres.

N'utilisez pas cette option pour les tables en cours de traitement en mode de transmission par un groupe Extract Data Pump.

Syntaxe

FETCHBEFOREFILTER

Exemple

TABLE hr.salary, FETCHCOLS (<sal_level>),
FETCHBEFOREFILTER,
FILTER (sal_level >= 8)
;

{FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)

FETCHCOLS et FETCHCOLSEXCEPT sont valides pour TABLE. Ces options ne sont valides que pour l'extraction principale.

Utilisez FETCHCOLS et FETCHCOLSEXCEPT pour extraire des valeurs de colonne de la base de données lorsque les valeurs ne sont pas présentes dans l'enregistrement de journal de transactions. Utilisez cette option si la base de données consigne uniquement les valeurs des colonnes qui ont été modifiées lors d'une opération de mise à jour, mais que vous devez vous assurer que d'autres valeurs de colonne requises pour les opérations FILTER sont disponibles.

FETCHCOLS et FETCHCOLSEXCEPT sont valides pour toutes les bases de données prises en charge par Oracle GoldenGate.

Pour une base de données Oracle AI Database, Oracle GoldenGate extrait les valeurs du tablespace d'annulation via le mécanisme Flashback Query d'Oracle. L'interrogation fournit une image cohérente en lecture des colonnes à une heure ou un SCN spécifique. Pour plus d'informations sur la façon dont Oracle GoldenGate utilise Flashback Query.

Au lieu d'utiliser FETCHCOLS ou FETCHCOLSEXCEPT, il peut être plus efficace d'activer la journalisation supplémentaire pour les colonnes souhaitées.

Pour contrôler l'extraction et activer une réponse lorsqu'une colonne indiquée pour l'extraction est introuvable, utilisez le paramètre FETCHOPTIONS. Pour inclure les résultats d'extraction dans les affichages statistiques générés par la commande STATS EXTRACT, utilisez le paramètre STATOPTIONS.

Si des valeurs pour les colonnes indiquées avec FETCHCOLS ou FETCHCOLSEXCEPT sont présentes dans le journal des transactions, aucune extraction de base de données n'est effectuée. Cela réduit la surcharge de la base de données.

Syntaxe

{FETCHCOLS | FETCHCOLSEXCEPT} (<column> [, ...])

<column>

Il peut s'agir de l'une des valeurs suivantes :

Exemple

Dans cet exemple, la clause FETCHCOLS extrait uniquement les colonnes 1 et 3, tandis que la clause FETCHCOLSEXCEPT extrait toutes les colonnes sauf les colonnes 1 et 3.

TABLE hq.acct, FETCHCOLS (col1, col3);
TABLE hq.sales, FETCHCOLSEXCEPT (col1, col3);

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)

FETCHMODCOLS et FETCHMODCOLSEXCEPT sont valides pour TABLE. Ces options ne sont valides que pour l'extraction principale.

Utilisez FETCHMODCOLS et FETCHMODCOLSEXCEPT pour forcer l'extraction des valeurs de colonne à partir de la base de données, même si les colonnes sont présentes dans le journal de transactions. Selon le type de base de données, un enregistrement de journal peut contenir toutes les colonnes d'une table ou uniquement les colonnes qui ont été modifiées dans l'opération de transaction donnée.

FETCHMODCOLS et FETCHMODCOLSEXCEPT sont valides pour toutes les bases de données prises en charge par Oracle GoldenGate.

Respectez les consignes d'utilisation suivantes :

Syntaxe

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column> [, ...])

(<column> [, ...])

Il peut s'agir de l'une des valeurs suivantes :

Exemple

Dans cet exemple, la clause FETCHMODCOLS extrait uniquement les colonnes 1 et 3, tandis que la clause FETCHMODCOLSEXCEPT extrait toutes les colonnes sauf les colonnes 1 et 3.

TABLE hq.acct, FETCHMODCOLS (col1, col3);
TABLE hq.sales, FETCHMODCOLSEXCEPT (col1, col3);

FILTER (<filter_clause>)

FILTER est valide pour TABLE et MAP.

Utilisez FILTER pour sélectionner ou exclure des enregistrements en fonction d'une valeur numérique. Une expression de filtre peut utiliser des opérateurs conditionnels, des fonctions de conversion de colonne Oracle GoldenGate ou les deux. Remarque : Pour filtrer en fonction d'une chaîne, utilisez l'une des fonctions de chaîne Oracle GoldenGate. Pour plus d'informations sur ces fonctions, reportez-vous à la section "Fonctions de mapping de table et de colonne". Vous pouvez également utiliser l'option WHERE. Reportez-vous à "WHERE (clause)".

Séparez tous les composants FILTER par des virgules. Une clause FILTER peut inclure les éléments suivants :

Placez les littéraux entre apostrophes. Indiquez les noms de colonne sensibles à la casse au fur et à mesure qu'ils sont stockés dans la base de données, et placez-les entre guillemets si la base de données requiert des guillemets pour appliquer la distinction majuscules/minuscules (par exemple, Oracle).

Oracle GoldenGate prend en charge FILTER pour les colonnes qui ont un jeu de caractères sur plusieurs octets.

Syntaxe

FILTER (
[, ON INSERT | ON UPDATE| ON DELETE]
[, IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE]
, <filter_clause>
[, RAISEERROR <error_number>]
)

<filter_clause>

Sélectionne les enregistrements en fonction d'un élément <expression>, par exemple :

FILTER ((PRODUCT_PRICE*PRODUCT_AMOUNT) > 10000))

Vous pouvez utiliser les fonctions de conversion de colonne d'Oracle GoldenGate dans un filtre <clause>, comme dans :

FILTER (@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

Placez les littéraux entre apostrophes. Indiquez les noms de colonne sensibles à la casse au fur et à mesure qu'ils sont stockés dans la base de données, et placez-les entre guillemets si la base de données requiert des guillemets pour appliquer la distinction majuscules/minuscules (par exemple, Oracle).

Oracle GoldenGate ne prend pas en charge FILTER pour les colonnes qui ont un jeu de caractères multioctets ou un jeu de caractères incompatible avec le jeu de caractères du système d'exploitation local.

La taille maximale de la clause de filtre est de 5 000 octets.

ON INSERT ON UPDATE ON DELETE

Limite le filtrage des enregistrements aux opérations spécifiées. Séparer les opérations par des virgules, par exemple :

FILTER (ON UPDATE, ON DELETE,
@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

L'exemple précédent exécute le filtre pour les opérations UPDATE et DELETE, mais pas pour les opérations INSERT.

IGNORE INSERT IGNORE UPDATE IGNORE DELETE

N'applique pas le filtre pour les opérations spécifiées. Séparer les opérations par des virgules, par exemple :

FILTER (IGNORE INSERT, @COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

L'exemple précédent exécute le filtre sur les opérations UPDATE et DELETE, mais ignore les opérations INSERT.

RAISEERROR <error>

Génère un numéro d'erreur défini par l'utilisateur en cas d'échec du filtre. Peut être utilisé comme entrée pour le paramètre REPERROR afin d'appeler le traitement des erreurs. Assurez-vous que la valeur de <error> est en dehors de la plage de numéros d'erreur utilisée par la base de données ou par Oracle GoldenGate. Par exemple : RAISEERROR 21000.

GETBEFORECOLS (<column_specification>)

GETBEFORECOLS est valide pour TABLE.

Utilisez GETBEFORECOLS pour indiquer les colonnes pour lesquelles l'image avant doit être capturée et écrite dans la trace lors d'une opération de mise à jour ou de suppression. Utilisez GETBEFORECOLS lors de l'utilisation de la fonctionnalité de détection et de résolution des conflits (CDR) d'Oracle GoldenGate dans une configuration bidirectionnelle ou multimaître. Utilisez-le également lorsque vous utilisez des fonctions de conversion ou d'autres fonctions de traitement qui nécessitent l'image "avant" d'un enregistrement.

Pour les mises à jour, l'image "avant" des colonnes indiquées est incluse dans la trace, qu'une colonne donnée soit modifiée ou non. Outre les colonnes indiquées dans la clause GETBEFORECOLS, une base de données Oracle AI Database consigne également l'image "avant" des autres colonnes modifiées. Pour les autres bases de données prises en charge, vous pouvez utiliser le paramètre GETUPDATEBEFORES pour forcer l'inclusion des valeurs "avant" des autres colonnes modifiées.

Remarque : GETUPDATEBEFORES remplace GETBEFORECOLS si les deux sont utilisés dans le même fichier de paramètres.

Pour utiliser ce paramètre, la journalisation supplémentaire doit être activée pour toute base de données qui ne consigne pas avant les valeurs par défaut.

GETBEFORECOLS remplace COMPRESSUPDATES et COMPRESSDELETES s'ils sont utilisés dans le même fichier de paramètres.

Ce paramètre est valide pour toutes les bases de données à l'exception de Db2 z/OS. Pour Db2 z/OS sur toutes les plates-formes prises en charge par Oracle GoldenGate, utilisez le paramètre GETUPDATEBEFORES au lieu de GETBEFORECOLS.

Syntaxe

GETBEFORECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...])  | KEYANDMOD | | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Indique si l'image "avant" des colonnes indiquées doit être capturée pour les mises à jour ou les suppressions. Vous pouvez utiliser ON UPDATE uniquement, ON DELETE uniquement ou les deux. Si vous utilisez les deux, indiquez-les dans la même clause GETBEFORECOLS. Reportez-vous à l'exemple pour savoir comment utiliser les deux.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | KEYANDMOD | ALLEXCLUDING (<col>[,...])}

Indique les colonnes pour lesquelles une image "avant" est capturée.

ALL

Capture une image avant de toutes les colonnes de type de données prises en charge dans la table cible, y compris la clé primaire. Toutes les colonnes non prises en charge sont ignorées et consignées dans le fichier de paramètres Extract ou Replicat en tant que message d'information. Cela impose la charge de traitement la plus élevée pour l'extraction, mais permet d'effectuer des comparaisons de détection de conflit à l'aide de toutes les colonnes pour une précision maximale.

KEY

Capturez l'image avant uniquement pour la clé primaire. Il s'agit de l'option la plus rapide, mais elle ne permet pas la détection de conflit la plus précise, car les clés peuvent correspondre mais les colonnes sans clé peuvent être différentes. KEY est l'option par défaut.

KEYINCLUDING

Capturez l'image avant de la clé primaire ainsi que la ou les colonnes indiquées. Il s'agit d'un compromis raisonnable entre la vitesse et la précision de détection.

KEYANDMOD

Utilisez cette option comme extension de l'option de clé pour le processus Extract et le processus Replicat. Pour les instructions LMD de mise à jour sur la source, le processus Extract consigne la clé et les colonnes modifiées. La réplication sur la cible utilisera les colonnes KEY et MODIFIED lors de la détection de conflit dans une clause WHERE. Avec les bases de données Oracle AI, la colonne modifiée est toujours utilisée par défaut pour la détection des conflits et ce paramètre la rend explicite.

ALLEXCLUDING

Capturez l'image "avant" de toutes les colonnes à l'exception des colonnes indiquées. Pour les tables comportant de nombreuses colonnes, ALLEXCLUDING peut être plus efficace que KEYINCLUDING. N'excluez pas les colonnes de clé.

Exemple

Dans l'exemple suivant, les images "avant" pour les colonnes de clé plus name, address et salary sont toujours écrites dans le fichier trace lors des opérations de mise à jour et de suppression.

TABLE src,
GETBEFORECOLS (
ON UPDATE KEYINCLUDING (name, address,  salary),
ON DELETE KEYINCLUDING (name, address, salary));

HANDLECOLLISIONS | NOHANDLECOLLISIONS

HANDLECOLLISIONS et NOHANDLECOLLISIONS sont valides pour MAP.

Utilisez HANDLECOLLISIONS et NOHANDLECOLLISIONS pour déterminer si Oracle GoldenGate rapproche les résultats d'un chargement initial des modifications transactionnelles répliquées apportées aux mêmes tables. Lorsque Oracle GoldenGate applique les modifications répliquées une fois le chargement terminé, HANDLECOLLISIONS entraîne le remplacement des enregistrements en double dans les tables cible par le processus Replicat et fournit un autre traitement des erreurs pour les enregistrements manquants.

HANDLECOLLISIONS et NOHANDLECOLLISIONS peuvent être utilisés globalement pour toutes les instructions MAP du fichier de paramètres ou en tant que commutateur ON/OFF pour les groupes de tables spécifiés avec des instructions MAP, et peuvent être utilisés dans une instruction MAP. Lorsqu'elles sont utilisées dans une instruction MAP, elles remplacent les spécifications globales.

Reportez-vous à "HANDLECOLLISIONS | NOHANDLECOLLISIONS" pour connaître la syntaxe et l'utilisation.

INSÉRER DES ENREGISTREMENTS

INSERTALLRECORDS est valide pour MAP.

Utilisez le paramètre INSERTALLRECORDS pour convertir toutes les opérations mises en correspondance en opérations INSERT sur la cible. INSERTALLRECORDS peut être utilisé au niveau racine du fichier de paramètres, dans une instruction MAP et dans une clause MAPEXCEPTION d'une instruction MAP.

Reportez-vous à "INSERTALLRECORDS" pour connaître la syntaxe et l'utilisation.

INSERTAPPEND | NOINSERTAPPEND

INSERTAPPEND est valide pour MAP.

Utilisez les paramètres INSERTAPPEND et NOINSERTAPPEND pour déterminer si le processus de réplication utilise ou non un conseil APPEND lorsqu'il applique des opérations INSERT aux tables cible Oracle. Ces paramètres ne sont valides que pour les bases de données Oracle.

Reportez-vous à "INSERTAPPEND | NOINSERTAPPEND" pour connaître la syntaxe et l'utilisation.

KEYCOLS (<columns>)

KEYCOLS est valide pour TABLE et MAP.

Utilisez KEYCOLS pour définir des colonnes de la table cible comme uniques. L'utilisation principale de KEYCOLS consiste à définir une clé primaire de substitution lorsqu'une clé primaire ou un index unique approprié n'est pas disponible pour la table. Vous pouvez également utiliser KEYCOLS pour indiquer des colonnes supplémentaires à utiliser dans l'identificateur de ligne utilisé par le processus Replicat. Sans la disponibilité d'une clé ou d'une clause KEYCOLS, le processus Replicat utilise toutes les colonnes de la table pour créer sa clause WHERE, en effectuant essentiellement un balayage complet de table (full table scan).

Les colonnes d'une clé affichée par KEYCOLS doivent identifier une ligne de manière unique et doivent correspondre aux colonnes utilisées en tant que clé dans la table source. La table source doit contenir au moins autant de colonnes de clé ou d'index que la clé KEYCOLS indiquée pour la table cible. Sinon, en cas de mise à jour des colonnes de clé ou d'index source, le processus Replicat ne disposera pas des images "avant" pour les colonnes KEYCOL cible supplémentaires.

Lorsque vous définissez une clé de substitution avec KEYCOLS, respectez les instructions suivantes :

Lorsque vous utilisez KEYCOLS, assurez-vous que les colonnes indiquées sont configurées pour la journalisation afin qu'elles soient disponibles pour le processus Replicat dans les enregistrements de trace. Pour une base de données Oracle AI, vous pouvez activer la journalisation à l'aide de l'option COLS de la commande ADD TRANDATA.

Dans les tables cible, créez un index unique sur les colonnes de clé définies par KEYCOLS. Un index améliore la vitesse à laquelle Oracle GoldenGate localise les lignes cible qu'il doit traiter.

N'utilisez pas KEYCOLS pour les tables en cours de traitement en mode de transmission par un groupe d'extraction Data Pump.

Règles supplémentaires pour KEYCOLS lors de l'utilisation de la réplication parallèle ou de la réplication intégrée :

Syntaxe

KEYCOLS (<column> [, ... ])

<column>

Définit une colonne à utiliser comme clé primaire de substitution. S'il existe une clé primaire ou unique, ces colonnes doivent être incluses dans la spécification KEYCOLS. Pour spécifier plusieurs colonnes, créez une liste délimitée par des virgules comme suit :

KEYCOLS (id, name)

Les types de colonne suivants ne sont pas pris en charge dans KEYCOLS :

Exemple

KEYCOLS

MAPEXCEPTION (<exceptions_mapping>)

MAPEXCEPTIONS est valide pour MAP.

Utilisez MAPEXCEPTION dans le cadre d'une instruction MAP d'exception destinée au traitement des erreurs. MAPEXCEPTION met en correspondance les opérations en échec qui sont marquées comme exceptions par le paramètre REPERROR avec une table d'exceptions. Le processus Replicat écrit les valeurs de ces opérations ainsi que d'autres informations dans la table des exceptions.

Vous pouvez utiliser MAPEXCEPTION dans la même instruction MAP qui inclut la mise en correspondance de table source-cible et d'autres options MAP standard. Les noms de table source et cible peuvent inclure des caractères génériques.

Lorsque vous utilisez MAPEXCEPTION, utilisez une instruction REPERROR avec l'option EXCEPTION dans la même instruction MAP ou à la racine du fichier de paramètres de réplication. Reportez-vous à "EXCEPTIONSONLY" et "REPERROR".

Syntaxe

MAPEXCEPTION (TARGET <exceptions_table>, INSERTALLRECORDS [, <exception_MAP_options>])

TARGET <exceptions_table>

Nom qualifié complet de la table des exceptions. Les règles Oracle GoldenGate standard pour les noms d'objet s'appliquent au nom de la table des exceptions.

<exception_MAP_options>

Toutes les options valides du paramètre MAP que vous voulez appliquer à la gestion des exceptions.

INSERTALLRECORDS

Applique toutes les exceptions à la table des exceptions en tant qu'opérations INSERT. Ce paramètre est requis lors de l'utilisation de MAPEXCEPTION.

Exemple

Voici un exemple d'utilisation de MAPEXCEPTION pour le mapping d'exceptions. Les clauses MAP et TARGET contiennent des noms de table source et cible avec caractères génériques. Les exceptions qui se produisent lors du traitement d'une table dont le nom commence par TRX sont capturées dans la table fin.trxexceptions à l'aide du mapping indiqué.

MAP src.trx*, TARGET trg.*,
MAPEXCEPTION (TARGET fin.trxexceptions,
INSERTALLRECORDS,
COLMAP (USEDEFAULTS,
ACCT_NO = ACCT_NO,
OPTYPE = @GETENV ('LASTERR', 'OPTYPE'),
DBERR = @GETENV ('LASTERR', 'DBERRNUM'),
DBERRMSG = @GETENV ('LASTERR', 'DBERRMSG')
)
);

NOMAPALLCOLUMNS | NOMAPALLCOLUMNS

MAPALLCOLUMNS et NOMAPALLCOLUMNS sont valides pour MAP.

Utilisez MAPALLCOLUMNS pour obtenir des colonnes non mappées (sans clé). Lorsque cette option est indiquée, le processus Extract ou Replicat vérifie si toutes les colonnes source sont directement mises en correspondance avec la cible sans la fonction de mise en correspondance des colonnes. Si aucune colonne source n'est mise en correspondance, le processus Extract et/ou Replicat s'interrompt.

Reportez-vous à "MAPALLCOLUMNS| NOMAPALLCOLUMNS".

MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS

MAPINVISIBLECOLUMNS et NOMAPINVISIBLECOLUMNS sont valides pour MAP.

Utilisez MAPINVISIBLECOLUMNS et NOMAPINVISIBLECOLUMNS pour déterminer si le processus Replicat inclut ou non des colonnes invisibles dans les tables cible Oracle pour le mapping de colonnes par défaut. Pour les colonnes invisibles dans les tables cible Oracle qui utilisent une mise en correspondance de colonnes explicite, elles sont toujours mises en correspondance. Par conséquent, cette option n'est pas requise.

MAPINVISIBLECOLUMNS et NOMAPINVISIBLECOLUMNS peuvent être utilisés de deux façons différentes. Lorsqu'il est indiqué au niveau global, un paramètre reste actif pour toutes les instructions MAP suivantes, jusqu'à ce que l'autre paramètre soit indiqué. Lorsqu'elles sont utilisées dans une instruction MAP, elles remplacent les spécifications globales

Reportez-vous à "MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS" pour connaître la syntaxe et l'utilisation.

REPERROR (<error>,<response>)

REPERROR est valide pour MAP.

Utilisez REPERROR pour indiquer une erreur et une réponse qui contrôlent ensemble la façon dont le processus Replicat répond à l'erreur lors de l'exécution de l'instruction MAP. Vous pouvez utiliser REPERROR au niveau MAP pour remplacer et compléter les règles globales de traitement des erreurs définies avec le paramètre REPERROR au niveau racine du fichier de paramètres. Plusieurs instructions REPERROR peuvent être appliquées à la même instruction MAP pour permettre une gestion automatique et complète des erreurs et un traitement de réplication sans interruption.

Pour connaître la syntaxe et les descriptions, reportez-vous à la section "REPERROR".

RESOLVECONFLICT (<conflict_resolution_specification>)

RESOLVECONFLICT est valide pour MAP.

Utilisez RESOLVECONFLICT dans une configuration bidirectionnelle ou multimaître pour indiquer comment le processus Replicat gère les conflits sur les opérations effectuées sur les tables dans l'instruction MAP.

Plusieurs résolutions peuvent être indiquées pour le même type de conflit et sont exécutées dans l'ordre indiqué dans RESOLVECONFLICT. Les résolutions multiples sont limitées aux conflits INSERTROWEXISTS et UPDATEROWEXISTS uniquement.

RESOLVECONFLICT peut être utilisé plusieurs fois dans une instruction MAP pour indiquer différentes résolutions pour différents types de conflit.

Les types de données et plates-formes suivants sont pris en charge par RESOLVECONFLICT.

Syntaxe

RESOLVECONFLICT (
{INSERTROWEXISTS | UPDATEROWEXISTS | UPDATEROWMISSING |
   DELETEROWEXISTS | DELETEROWMISSING}
( {DEFAULT | <resolution_name>},
  {USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |
     DISCARD | OVERWRITE | IGNORE}
 )
[, COLS (<column>[,...])]
)
INSERTROWEXISTS UPDATEROWEXISTS UPDATEROWMISSING
DELETEROWEXISTS DELETEROWMISSING  

Type de conflit géré par cette résolution.

INSERTROWEXISTS

Une ligne insérée viole une contrainte d'unicité sur la cible.

UPDATEROWEXISTS

Une ligne mise à jour existe sur la cible, mais une ou plusieurs colonnes ont une image avant dans la trace différente de la valeur en cours dans la base de données.

UPDATEROWMISSING

Aucune ligne mise à jour n'existe dans la cible.

DELETEROWEXISTS

Une ligne supprimée existe dans la cible, mais une ou plusieurs colonnes ont une image avant dans la trace qui est différente de la valeur en cours dans la base de données.

DELETEROWMISSING

Aucune ligne supprimée n'existe dans la cible.

DEFAULT | <resolution_name>

DEFAULT

Groupe de colonnes par défaut. La résolution associée au groupe de colonnes DEFAULT est utilisée pour toutes les colonnes qui ne font pas partie d'un groupe de colonnes nommé explicitement. Vous devez définir un groupe de colonnes DEFAULT.

<resolution_name>

Nom d'un groupe de colonnes spécifique lié à un type de résolution spécifique. Indiquez un nom identifiant le type de résolution. Les valeurs valides sont des caractères alphanumériques. Evitez les espaces et les caractères spéciaux, mais les traits de soulignement sont autorisés, par exemple :

delta_res_method

Utilisez une résolution nommée ou DEFAULT, mais pas les deux.

USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |    
DISCARD OVERWRITE IGNORE

Logique du gestionnaire de conflits utilisée pour résoudre le conflit. Les résolutions valides sont :

USEMAX

Si la valeur de <resolution_column> dans l'enregistrement de trace est supérieure à la valeur de la colonne dans la base de données, l'action appropriée est exécutée.

USEMAXEQ

Si la valeur de <resolution_column> dans l'enregistrement de trace est supérieure ou égale à la valeur de la colonne dans la base de données, l'action appropriée est exécutée.

USEMIN

Si la valeur de <resolution_column> dans l'enregistrement de trace est inférieure à la valeur de <column> dans la base de données, le paramètre <action> approprié est exécuté :

USEMINEQ

Si la valeur de <resolution_column> dans l'enregistrement de trace est inférieure ou égale à la valeur de <column> dans la base de données, le paramètre <action> approprié est exécuté :

<resolution_column>

Nom d'une colonne NOT NULL qui sert de colonne de résolution. Cette colonne doit faire partie du groupe de colonnes associé à cette résolution. La valeur de la colonne de résolution par rapport à la valeur actuelle dans la base de données cible détermine la manière dont une résolution doit être appliquée. L'image après de la colonne de résolution est utilisée pour la comparaison, si elle est disponible ; sinon, la valeur de l'image avant est utilisée. Utilisez une colonne qui peut être comparée via du code SQL simple :

Pour utiliser une résolution d'horodatage le plus récent, utilisez une colonne d'horodatage comme <resolution_column> et définissez la colonne d'horodatage sur l'heure actuelle lorsqu'une ligne est insérée ou mise à jour. Si possible, définissez la colonne de résolution avec le type de données SYSTIMESTAMP, qui prend en charge les fractions de seconde. Lorsque des comparaisons sont effectuées avec une granularité inférieure à la seconde, il n'est pas nécessaire de recourir à des gestionnaires de conflit qui résolvent les cas où la valeur de la colonne de résolution est identique dans la trace et la cible. Si vous veillez à ce que la valeur de la colonne d'horodatage puisse uniquement augmenter ou diminuer (en fonction de la résolution), USEMAX et USEMIN n'entraînent pas de divergence des données.

Remarque :

N'utilisez pas de colonne de clé primaire comme colonne de résolution dans une instruction USEMAX pour le conflit UPDATEROWEXISTS. Sinon, le processus Replicat s'interrompt avec une erreur semblable à la suivante :

  2013-04-04 10:18:38 ERROR OGG-01922 Missing RESOLUTION COLUMN NAME while mapping to target table "FIN"."ACCT".

USEDELTA

(conflit UPDATEROWEXISTS uniquement) Ajoutez la différence entre les valeurs avant et après de l'enregistrement de trace à la valeur en cours de la colonne dans la base de données cible. Si l'une des valeurs est NULL, une erreur est générée. Basez USEDELTA sur les colonnes qui contiennent des types de données NUMERIC. USEDELTA est utile dans une configuration à plusieurs noeuds lorsqu'une ligne est mise à jour simultanément sur plusieurs noeuds. Il propage uniquement la différence entre les valeurs de colonne et les autres noeuds, de sorte que tous les noeuds soient synchronisés.

DISCARD

(Valide pour tous les types de conflit) Conservez la valeur actuelle dans la base de données cible et écrivez les données de l'enregistrement de trace dans le fichier de rebut.

Utilisez DISCARD avec précaution, car cela peut entraîner des divergences de données.

OVERWRITE

(Valide pour tous les types de conflit à l'exception de DELETEROWMISSING) Appliquez l'enregistrement de trace comme suit :

Utilisez OVERWRITE avec précaution, car cela peut entraîner des divergences de données.

IGNORE

(Valide pour tous les types de conflit) Conservez la valeur actuelle dans la base de données cible et ignorez l'enregistrement de trace (trail) : Ne pas appliquer à la table cible ou à un fichier de rebut.

COLS (<column>[, ...])

Groupe de colonnes autre que celui par défaut. Liste des colonnes de la base de données cible (après mise en correspondance) liées à un type de résolution spécifique et exploitées par ce type. Si aucun groupe de colonnes n'est spécifié pour un conflit, toutes les colonnes sont affectées par la résolution indiquée pour le conflit donné.

Vous pouvez également indiquer un groupe de colonnes DEFAULT, qui inclut toutes les colonnes qui ne sont pas répertoriées dans un autre groupe de colonnes. Voir l'option DEFAULT.

Vous pouvez spécifier plusieurs groupes de colonnes, chacun ayant une résolution différente. Par exemple, vous pouvez utiliser OVERWRITE pour col2 et col3, et USEDELTA pour col4. Aucune colonne d'un groupe ne peut appartenir à un autre groupe. Les conflits pour les colonnes de différents groupes de colonnes sont résolus séparément en fonction de la résolution indiquée et dans l'ordre indiqué.

Les groupes de colonnes fonctionnent comme suit :

Exemples

Exemple 1

Cet exemple illustre tous les types de conflit avec USEMAX, OVERWRITE et DISCARD.

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)),
    );

Exemple 2

Cet exemple illustre UPDATEROWEXISTS avec USEDELTA et USEMAX.

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)));

Exemple 3

Cet exemple illustre UPDATEROWEXISTS avec USEDELTA, USEMAX et IGNORE.

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));

SQLEXEC (<SQL_specification>)

SQLEXEC est valide pour TABLE et MAP.

Utilisez SQLEXEC pour exécuter une requête ou une procédure stockée SQL à partir d'une instruction MAP pendant le traitement d'Oracle GoldenGate. SQLEXEC permet à Oracle GoldenGate de communiquer directement avec la base de données pour effectuer toute tâche prise en charge par la base de données. Ce travail peut faire partie du processus de synchronisation, tel que l'extraction de valeurs pour la conversion de colonne, ou être indépendant de l'extraction ou de la réplication de données, comme l'exécution d'une procédure stockée qui exécute une action dans la base de données.

Reportez-vous à "SQLEXEC" pour connaître la syntaxe et l'utilisation.

SQLPREDICATE 'WHERE <where_clause>'

SQLPREDICATE est valide pour les bases de données Oracle, Db2 LUW, Db2 sur z/OS, Db2 pour i, PostgreSQL, MySQL, SQL Server et Sybase. N'utilisez pas SQLPREDICATE pour un groupe d'extraction configuré pour synchroniser les modifications transactionnelles. Elle n'est appropriée que pour une extraction de chargement initial, car elle requiert une instruction SELECT qui sélectionne les enregistrements directement à partir des tables.

SQLPREDICATE est utilisé avec TABLE.

Utilisez SQLPREDICATE pour inclure une clause SQL WHERE conventionnelle dans l'instruction SELECT que le processus Extract utilise lors de la sélection de données dans une table en vue d'un chargement initial. SQLPREDICATE force l'ordre des enregistrements renvoyés par la sélection en fonction des valeurs de clé.

SQLPREDICATE est une méthode de sélection plus rapide pour les chargements initiaux que les options WHERE ou FILTER. Elle affecte directement l'instruction SQL et n'exige pas que le processus Extract extrait tous les enregistrements avant de les filtrer.

Pour les tables Oracle, SQLPREDICATE réduit la quantité de données stockées dans le segment d'annulation, ce qui peut réduire l'incidence des erreurs de cliché trop anciennes. Cela est utile lors du chargement de tables très volumineuses.

En utilisant une clause SQLPREDICATE, vous pouvez partitionner les lignes d'une table volumineuse entre plusieurs processus Extract parallèles. Cette configuration vous permet également de tirer parti du traitement de la charge de livraison parallèle.

SQLPREDICATE vous permet également de sélectionner des données en fonction d'un horodatage ou d'autres critères pour filtrer les lignes extraites et chargées dans la table cible. SQLPREDICATE peut être utilisé pour les clauses ORDER BY ou tout autre type de clause de sélection.

Vérifiez que la clause WHERE contient des colonnes qui font partie d'une clé ou d'un index. Sinon, le processus Extract effectue un balayage complet de table (full table scan), ce qui réduit l'efficacité de l'instruction SELECT.

Syntaxe

TABLE <source_table>, SQLPREDICATE 'WHERE <where_clause>';

WHERE

Ce mot-clé est obligatoire.

<where_clause>

Clause SQL WHERE valide qui sélectionne les enregistrements dans les tables source.

Exemple

TABLE hr.emp, SQLPREDICATE 'WHERE state = 'CO' and city = 'DENVER''

THREAD (<thread_ID>)

THREAD est valide pour MAP. Cette option est valide lorsque le processus Replicat est en mode coordonné.

Utilisez THREAD pour indiquer que tous les objets de la même instruction MAP doivent être traités par le thread de réplication indiqué. Le thread spécifié gère le filtrage, la manipulation, la distribution à la cible, la gestion des erreurs et tout autre travail configuré pour ces objets. Les caractères génériques peuvent être utilisés dans la clause TARGET lorsque THREAD est utilisé.

Toutes les tables qui ont des dépendances référentielles entre elles doivent être mappées dans le même thread. Par exemple, si les tables scott.cust et scott.ord ont une relation de clé étrangère, le mapping suivant est possible :

MAP scott.cust, TARGET scott.cust, THREAD (5);
MAP scott.ord, TARGET scott.ord, THREAD (5);

Le thread avec le thread le plus bas ID traite toujours les transactions de barrière si l'option THREAD ou THREADRANGE est omise. De plus, le travail qui n'est pas explicitement affecté à un thread est traité via ce thread. Par exemple, s'il existe des threads avec des ID allant de 1 à 10, les transactions de barrière et non affectées sont effectuées par le thread 1.

Pour traiter une instruction MAP entre plusieurs threads, reportez-vous à THREADRANGE (thread_range, column_list). THREAD et THREADRANGE sont des options qui s'excluent mutuellement. Ne les utilisez pas ensemble dans la même instruction MAP.

Syntaxe

THREAD (<thread_ID>)

<thread_ID>

Identificateur numérique du thread qui traitera cette instruction MAP. Les valeurs valides vont de 1 à la valeur indiquée avec l'option MAXTHREADS de la commande ADD REPLICAT qui a créé ce groupe. Vous pouvez utiliser la commande INFO REPLICAT pour vérifier le nombre maximal de threads autorisés pour un groupe de réplication. Lorsque vous spécifiez des ID de thread, les conditions suivantes doivent être remplies :

Si MAXTHREADS n'a pas été utilisé, le nombre maximal de threads par défaut est 25.

Exemples

Les exemples suivants montrent quelques façons d'utiliser l'option THREAD.

Exemple 1

Dans cet exemple, le thread 1 traite la table cust.

MAP scott.cust, TARGET scott.cust, THREAD (1);

Exemple 2

Dans cet exemple, le thread 1 traite toutes les tables du schéma scott.

MAP scott.*, TARGET scott.*, THREAD (1);

Exemple 3

Dans cet exemple, la table orders est partitionnée entre deux instructions MAP via l'utilisation de FILTER (filter_clause) et de la fonction @RANGE. Pour plus d'informations sur @RANGE, reportez-vous à "@RANGE".

MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (1, 2, OID)), THREAD (1);
MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (2, 2, OID)), THREAD (2);

THREADRANGE (<thread_range>,<column_list>)

THREADRANGE est valide pour MAP. Cette option est valide lorsque le processus Replicat est en mode coordonné.

Utilisez THREADRANGE pour indiquer que la charge globale de la table cible doit être partitionnée uniformément parmi une plage de threads de réplication, en fonction de la valeur d'une ou de plusieurs colonnes indiquées. Par exemple, si le partitionnement est basé sur la valeur d'une colonne nommée ID et que la valeur THREADRANGE est comprise entre 1 et 3, le thread 1 traite les lignes avec des valeurs ID comprises entre 1 et 10, le thread 2 traite les lignes avec des valeurs ID comprises entre 11 et 20, et le thread 3 traite les lignes avec des valeurs ID comprises entre 21 et 30. Le partitionnement peut ne pas être aussi absolu que dans l'exemple précédent, en fonction du calcul initial de la charge globale, mais il est coordonné de sorte que la même ligne soit toujours traitée par le même thread. Chaque thread spécifié gère le filtrage, la manipulation, la gestion des erreurs, la distribution à la cible et d'autres tâches pour sa plage de lignes.

Le partitionnement d'une table sur une plage de threads peut améliorer les performances d'application pour les tables très volumineuses ou les tables qui impliquent souvent des transactions longues ou un volume important, mais peut également être utilisé dans d'autres cas. Vous pouvez traiter plusieurs tables via la même plage de threads.

Une clause TARGET avec caractères génériques peut être utilisée lorsque THREADRANGE est utilisé si la liste de colonnes facultatives est omise. Lorsque vous utilisez une liste de colonnes, utilisez des instructions MAP explicites distinctes pour chaque table qui utilise la même plage de threads.

Pour traiter une instruction MAP avec un thread spécifique, reportez-vous à THREAD (thread_ID). THREAD et THREADRANGE sont des options qui s'excluent mutuellement. Ne les utilisez pas ensemble dans la même instruction MAP.

N'indiquez pas les tables qui ont des dépendances référentielles entre elles dans une plage de threads. Utilisez l'option THREAD et traitez toutes ces tables avec le même thread.

N'utilisez pas THREADRANGE pour partitionner les séquences. Si une coordination est requise, par exemple lorsqu'une séquence fait partie d'une opération SQLEXEC, partitionnez le travail de la séquence sur un thread avec l'option THREAD.

Le thread avec le thread le plus bas ID traite toujours les transactions de barrière si l'option THREAD ou THREADRANGE est omise. De plus, le travail qui n'est pas explicitement affecté à un thread est traité via ce thread. Par exemple, s'il existe des threads avec des ID allant de 1 à 10, les transactions de barrière et non affectées sont effectuées par le thread 1. Remarque : Les colonnes indiquées dans une liste de colonnes doivent exister dans le fichier trace. Vous pouvez le contrôler en utilisant KEYCOLS dans le processus Extract pour inclure cette colonne, ou en utilisant FETCHCOLS dans le processus Extract pour la colonne, ou en vous assurant que la colonne fait partie du groupe de journaux supplémentaire, puis en utilisant LOGALLSUPCOLS.

Syntaxe

THREADRANGE (<lowID>-<highID>, [<column>[, <column>][, ...]])

<lowID>

Identificateur de thread le plus bas de cette plage. Les valeurs valides sont comprises entre 1 et 500.

<highID>

Identificateur de thread le plus élevé de cette plage, qui doit être un nombre supérieur à <lowID>. Les valeurs valides sont <lowID>+1 à 500. Le nombre de threads dans la plage ne peut pas dépasser la valeur indiquée avec l'option MAXTHREADS de la commande ADD REPLICAT. Si MAXTHREADS n'a pas été utilisé, le nombre maximal de threads par défaut est 25.

[<column>[, <column>][, ...]]

Facultatif. Spécifie une ou plusieurs colonnes uniques sur lesquelles baser le partitionnement de ligne. Pour indiquer plusieurs colonnes, utilisez une liste délimitée par des virgules, telle que col1, col2, col3. Lorsque cette option est omise, le partitionnement entre les threads est basé par défaut sur les colonnes suivantes, dans l'ordre de préférence indiqué :

Exemple

L'exemple suivant divise les tables orders et order_lines entre les deux mêmes threads, en fonction de la valeur de la colonne OID.

MAP scott.orders, TARGET scott.orders, THREADRANGE (1-2, OID);
MAP scott.order_lines, TARGET scott.order_lines, THREADRANGE (1-2, OID);

TOKENS (<token_definition>)

TOKENS est valide pour TABLE.

Utilisez TOKENS pour définir un jeton utilisateur et l'associer à des données. Les jetons vous permettent d'extraire et de stocker des données dans la zone de jeton utilisateur d'un en-tête d'enregistrement de trace. Les données de jeton peuvent être extraites et utilisées de nombreuses façons pour personnaliser la façon dont Oracle GoldenGate fournit les données. Par exemple, vous pouvez utiliser des données de jeton dans des mappings de colonnes, des procédures stockées appelées par SQLEXEC ou des macros.

Pour utiliser les données de jeton définies dans les tables cible, utilisez la fonction de conversion de colonne @TOKEN dans la clause COLMAP d'une instruction MAP de réplication. La fonction @TOKEN met en correspondance le nom d'un jeton avec une colonne cible.

N'utilisez pas cette option pour les tables en cours de traitement en mode de transmission par un groupe Extract Data Pump.

Le jeu de caractères des données de jeton n'est pas converti. Le jeton doit figurer dans le jeu de caractères de la base de données source pour le processus Extract et dans le jeu de caractères de la base de données cible pour le processus Replicat.

Syntaxe

TOKENS (<token_name> = <token_data> [, ...])

<token_name>

Nom de votre choix pour le jeton. Il peut s'agir de n'importe quel nombre de caractères valides et ne distingue pas les majuscules des minuscules. Les noms multioctets ne sont pas pris en charge.

<token_data>

Toute chaîne de caractères valide d'un maximum de 2000 octets. Les données peuvent être un littéral placé entre guillemets simples (ou entre guillemets si NOUSEANSISQLQUOTES est utilisé) ou le résultat d'une fonction de conversion de colonne Oracle GoldenGate.

Exemple

La commande suivante crée des jetons nommés TK-OSUSER, TK-GROUP et TK-HOST, et les met en correspondance avec les données de jeton obtenues avec la fonction @GETENV.

TABLE ora.oratest, TOKENS (
TK-OSUSER = @GETENV ('GGENVIRONMENT' , 'OSUSERNAME'),
TK-GROUP = @GETENV ('GGENVIRONMENT' , 'GROUPNAME')
TK-HOST =  @GETENV ('GGENVIRONMENT' , 'HOSTNAME'));

TRIMSPACES | NOTRIMSPACES

TRIMSPACES et NOTRIMSPACES sont valides pour TABLE et MAP.

Utilisez TRIMSPACES et NOTRIMSPACES au niveau racine d'un fichier de paramètres ou dans une instruction TABLE ou MAP pour déterminer si les espaces de fin d'une colonne CHAR source sont tronqués lorsqu'ils sont appliqués à une colonne CHAR ou VARCHAR cible. La valeur par défaut est TRIMSPACES.

Reportez-vous à "TRIMSPACES | NOTRIMSPACES" pour connaître la syntaxe et l'utilisation.

TRIMVARSPACES | NOTRIMVARSPACES

TRIMVARSPACES et NOTRIMVARSPACES sont valides pour TABLE et MAP.

Utilisez TRIMVARSPACES et NOTRIMVARSPACES au niveau racine d'un fichier de paramètres ou dans une instruction TABLE ou MAP pour déterminer si les espaces de fin d'une colonne VARCHAR source sont tronqués lorsqu'ils sont appliqués à une colonne CHAR ou VARCHAR cible. La valeur par défaut est NOTRIMVARSPACES.

Reportez-vous à "TRIMVARSPACES | NOTRIMVARSPACES" pour connaître la syntaxe et l'utilisation.

WHERE (<clause>)

WHERE est valide pour TABLE et MAP.

Utilisez WHERE pour sélectionner des enregistrements en fonction d'une instruction conditionnelle. WHERE ne prend pas en charge les éléments suivants :

Placez les littéraux entre apostrophes. Indiquez les noms de colonne sensibles à la casse au fur et à mesure qu'ils sont stockés dans la base de données, et placez-les entre guillemets si la base de données requiert des guillemets pour appliquer la distinction majuscules/minuscules (par exemple, Oracle).

Obtention d'informations supplémentaires sur le filtrage des enregistrements

Syntaxe

WHERE (<clause>)

<clause>

Sélectionne les enregistrements en fonction d'une condition, par exemple :

WHERE (branch = 'NY')

Le tableau 2-12 présente les opérateurs WHERE autorisés.

Tableau 12 Opérateurs WHERE autorisés

Opérateur Exemple
Noms de colonne PRODUCT_AMT "Product_Amt"
Valeurs numériques -123, 5500.123
Chaînes littérales placées entre apostrophes 'AUTO', 'Ca'
Tests de colonne @NULL, @PRESENT, @ABSENT (la colonne est NULL, présente ou absente dans l'enregistrement). Ces tests sont intégrés à Oracle GoldenGate.
Comparison operators =, <>, >, <,>=, <= < td>
Conjunctive operators `AND`, `OR`
Grouping parentheses Use open and close parentheses for logical grouping of multiple elements.

Example

The following WHERE example returns all records when the AMOUNT column is over 10,000 and does not cause a record to be discarded when AMOUNT is absent.

WHERE (amount = @PRESENT AND amount > 10000)

PARTITIONOBJID

Valid for Integrated Extract.

PARTITIONOBJID is used to specify the object IDs of the partitions to be captured for partitioned tables, and applies to Integrated Extract. For an IO table (with or without overflow area), index segment object ID should be used for partition level filtering. In this case, PARTITIONOBJID in the MAP or TABLE statement specifies the index segment object IDs of the partitions to be extracted.

Syntax

MAP/TABLE [container.]schema.table PARTITIONOBJID ptn_object_ID [, ptn_object_ID]

The following restrictions apply:

Syntax for IO table TABLE statement:

TABLE [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]

Syntax for IO table MAP statement:

MAP [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]