Mapper et transformer des données
Découvrez les tâches, les fonctions, les commandes et les processus utilisés pour intégrer des données entre les tables source et cible.
Paramètres qui contrôlent le mapping et l'intégration des données
Toutes les opérations de sélection, de mise en correspondance et de manipulation des données effectuées par Oracle GoldenGate sont effectuées à l'aide d'une ou de plusieurs options des paramètres TABLE et MAP.
-
Utilisez
TABLEdans le fichier de paramètres d'extraction. -
Utilisez
MAPdans le fichier de paramètres de réplication.
TABLE et MAP indiquent les objets de base de données affectés par les autres paramètres dans le fichier de paramètres. Pour obtenir des instructions sur la spécification de noms d'objet dans ces paramètres, reportez-vous à Spécification de noms d'objet dans l'entrée Oracle GoldenGate.
Mise en correspondance entre bases de données différentes
La mise en correspondance et la conversion entre des tables ayant des structures de données différentes nécessitent soit un fichier de définitions source, soit un fichier de définitions cible, ou dans certains cas les deux. La mise en correspondance entre des bases de données différentes est contrôlée par les traces auto-descriptives, et la mise en correspondance est effectuée par nom de colonne, quel que soit le type de données de la colonne source ou cible.
Si vous ne voulez pas de mise en correspondance automatique basée sur les traces auto-décrites ou si vous voulez une compatibilité ascendante, vous pouvez utiliser SOURCEDEFS ou TARGETDEFS.
Mappage et conversion sur les systèmes NonStop
Si vous mappez ou convertissez des données d'un système Windows ou UNIX vers une cible d'abonnement NonStop, le mappage ou la conversion doit être effectué sur le système source Windows ou UNIX. La réplication pour NonStop ne peut pas convertir les types de données et les noms de table SQL en trois ou deux parties en les noms de fichier en trois parties utilisés pour la plate-forme Enscribe. Le processus Extract peut formater les données de trace avec les noms Enscribe et les types de données cible.
Mappage et conversion sur les systèmes Windows et UNIX
Lorsqu'Oracle GoldenGate fonctionne uniquement sur les systèmes Windows et UNIX, le mappage et la conversion des colonnes peuvent être effectués dans le processus Extract ou Replicat. Pour éviter la surcharge supplémentaire de ce traitement sur le processus d'extraction, vous pouvez configurer le mapping et la conversion à effectuer sur le processus Replicat ou sur un système intermédiaire.
Dans le cas où il existe plusieurs sources et une cible, il peut être plus efficace d'effectuer le mapping et la conversion sur la source.
Considérations relatives à la globalisation lors de la mise en correspondance de données
Lors de la planification de la mise en correspondance et de la conversion des données entre bases de données et plates-formes, prenez en compte ce qui est pris en charge ou non par Oracle GoldenGate en termes de mondialisation.
Conversion entre jeux de caractères
Oracle GoldenGate convertit les jeux de caractères source et cible s'ils sont différents, de sorte que les noms d'objet et les données de colonne soient comparés, mis en correspondance et manipulés correctement d'une base de données à une autre. Pour une liste des jeux de caractères pris en charge, reportez-vous à Jeux de caractères pris en charge.
Pour garantir une représentation exacte des caractères d'une base de données à une autre, les conditions suivantes doivent être remplies :
-
Le jeu de caractères de la base de données cible doit être un surensemble ou un équivalent du jeu de caractères de la base de données source. Equivalent signifie différent de, mais ayant le même ensemble de caractères. Par exemple, Shift-JIS et EUC-JP techniquement ne sont pas complètement égaux, mais ont les mêmes caractères dans la plupart des cas.
-
Si vos applications client utilisent des jeux de caractères différents, le jeu de caractères de la base de données doit également être un sur-ensemble ou un équivalent des jeux de caractères des applications client.
-
Dans de nombreuses bases de données, y compris Oracle, il est possible de forcer un caractère dans une base de données qui ne fait pas partie du jeu de caractères. Oracle GoldenGate considère cette valeur comme non valide et peut ne pas mapper correctement ce caractère lors de la réplication des données. Pour ce type de situation, vous pouvez utiliser le paramètre
REPLACEBADCHARcomme décrit dans la référence des paramètres et des fonctions pour Oracle GoldenGate.
Dans cette configuration, chaque caractère est représenté lors de la conversion d'un jeu de caractères client ou source vers le jeu de caractères de la base de données locale.
Un processus Replicat peut prendre en charge la conversion d'un jeu de caractères source en un jeu de caractères cible.
Nom des objets de base de données
Oracle GoldenGate traite les noms de catalogue, de schéma, de table et de colonne dans leur langue native, tels que déterminés par le codage de jeu de caractères des bases de données source et cible. Cette prise en charge préserve les noms mono-octets et multioctets, les symboles, les caractères d'accentuation et la sensibilité à la casse, les paramètres régionaux étant pris en compte, le cas échéant, à tous les niveaux de la hiérarchie de la base de données.
Données de colonne
Oracle GoldenGate prend en charge la conversion de données de colonne entre des jeux de caractères lorsque les données sont contenues dans les types de colonne suivants :
-
Colonnes de type caractère :
CHAR/VARCHAR/CLOBàCHAR/VARCHAR/CLOBd'un autre jeu de caractères, etCHAR/VARCHAR/CLOBà et depuisNCHAR/NVARCHAR/NCLOB. -
Colonnes contenant des nombres basés sur des chaînes et des données de date/heure. Les conversions de ces colonnes sont effectuées entre les données z/OS EBCDIC et les données non z/OS ASCII. La conversion n'est pas effectuée entre les versions ASCII et ASCII de ces données, ni entre les versions EBCDIC et EBCDIC, car les données sont compatibles dans ces cas.
Remarque : Oracle GoldenGate prend en charge les données d'horodatage de
0001-01-03 00:00:00à9999-12-31 23:59:59. Si un horodatage est converti de GMT en heure locale, ces limites s'appliquent également à l'horodatage résultant. La valeur de mois zéro, de jour zéro ou de date zéro n'est pas prise en charge. Par exemple, les valeurs telles que 0000-00-00 00:00:00, ou toute valeur de date incluant un champ de mois ou de jour zéro n'est pas prise en charge.
La conversion de jeu de caractères pour les données de colonne est limitée à une mise en correspondance directe d'une colonne source et d'une colonne cible dans les clauses COLMAP ou USEDEFAULTS du paramètre Replicat MAP. Un mappage direct est un mappage nom-nom sans l'utilisation d'une procédure stockée ou d'une fonction de conversion de colonne. Le processus Replicat effectue la conversion des jeux de caractères. Aucune conversion n'est effectuée par l'extraction.
Préservation des paramètres régionaux
Oracle GoldenGate prend en compte les paramètres régionaux de la base de données lors de la comparaison des noms d'objet sans distinction majuscules/minuscules. Pour obtenir la liste des environnements linguistiques pris en charge, reportez-vous à la section Supported Locales.
Prise en charge des séquences d'échappement
Oracle GoldenGate prend en charge l'utilisation d'une séquence d'échappement pour représenter une colonne de chaîne, un texte littéral ou un nom d'objet dans le fichier de paramètres. Vous pouvez utiliser une séquence d'échappement si le système d'exploitation ne prend pas en charge le caractère requis, tel qu'un caractère de contrôle, ou à toute autre fin nécessitant un caractère qui ne peut pas être utilisé dans un fichier de paramètres.
Une séquence d'échappement peut être utilisée n'importe où dans le fichier de paramètres, mais elle est particulièrement utile dans les éléments suivants d'une instruction TABLE ou MAP :
-
Nom d'objet
-
Clause
WHERE -
Clause
COLMAPpermettant d'affecter un caractère Unicode à une colonne Unicode ou d'affecter un caractère codé en natif à une colonne. -
Fonctions de conversion de colonne Oracle GoldenGate dans une clause
COLMAP.
Oracle GoldenGate prend en charge les types de séquence d'échappement suivants :
-
\uFFFFSéquence d'échappement Unicode. Tout point de codeUNICODEpeut être utilisé à l'exception des paires de substitution. -
\377Séquence d'échappement octale -
\xFFSéquence d'échappement hexadécimale
Les règles suivantes s'appliquent :
-
S'il est utilisé pour la mise en correspondance d'un nom d'objet dans
TABLEouMAP, aucune restriction ne s'applique. Par exemple, la spécificationTABLEsuivante est valide :TABLE schema."\u3000ABC"; -
S'il est utilisé avec une fonction de mapping de colonne, n'importe quel point de code peut être utilisé, mais uniquement pour une colonne
NCHAR/NVARCHAR. Pour une colonneCHAR/VARCHAR, le point de code est limité à l'équivalent de 7 bits ASCII. -
Les types de données source et cible doivent être identiques (par exemple,
NCHARàNCHAR). -
Commencez chaque séquence d'échappement par un solidus inverse (point de code
U+005C), suivi du point de code alphanumérique. (Un solidus est plus communément appelé symbole de barre oblique inverse.) Utilisez la séquence d'échappement, au lieu du caractère réel, dans votre chaîne d'entrée dans l'instruction de paramètre ou la fonction de conversion de colonne.Remarque : pour spécifier une barre oblique inverse réelle dans le fichier de paramètres, spécifiez une barre oblique inverse double. Par exemple, la barre oblique inverse suivante est trouvée dans
COL1: @STRFIND (COL1, '\' ).
Pour utiliser la séquence d'échappement \uFFFF Unicode
-
La séquence d'échappement Unicode
\uFFFFdoit commencer par uneuminuscule, suivie de exactement quatre chiffres hexadécimaux. -
Les plages prises en charge sont les suivantes :
-
0à9(U+0030àU+0039) -
AàF(U+0041àU+0046) -
aàf(U+0061àU+0066)
-
\u20ac est la séquence d'échappement Unicode pour le signe Euro.
Remarque : pour une prise en charge fiable des plates-formes croisées, utilisez la séquence d'échappement Unicode. Les séquences d'échappement octales et hexadécimales ne sont pas standardisées sur différents systèmes d'exploitation.
Pour utiliser la séquence d'échappement octal \377
-
Doit contenir exactement trois chiffres octaux.
-
Plages prises en charge :
-
La plage du premier chiffre est comprise entre
0et3(U+0030etU+0033). -
La plage des deuxième et troisième chiffres est comprise entre
0et7(U+0030etU+0037).
\200est la séquence d'échappement octale pour le signe de devise Euro sur Microsoft Windows. -
Pour utiliser l'ordre d'échappement \xFF hexadécimal
-
Doit commencer par un
xminuscule suivi de exactement deux chiffres hexadécimaux. -
Plages prises en charge :
-
0à9(U+0030àU+0039) -
AàF(U+0041àU+0046) -
aàf(U+0061àU+0066)
-
\x80 est la séquence d'échappement hexadécimale du signe de devise Euro sur la page de code Microsoft Windows 1252 Latin1.
Mise en correspondance de colonnes à l'aide de TABLE et MAP
Oracle GoldenGate permet la mise en correspondance de colonnes au niveau de la table et au niveau global. Le mapping de colonne par défaut est également fourni en l'absence de règles de mapping de colonne explicites.
Cette section contient les instructions suivantes pour le mappage des colonnes :
Cas annexe et caractères spéciaux dans les noms de colonne
Par défaut, Oracle GoldenGate suit les règles SQL-92 pour la spécification des noms de colonne et des littéraux. Dans les fichiers de paramètres Oracle GoldenGate, les fonctions de conversion, les exits utilisateur et les commandes, les noms de colonne sensibles à la casse doivent être placés entre guillemets doubles si la base de données exige des guillemets doubles pour appliquer la distinction majuscules/minuscules. Pour les autres bases de données sensibles à la casse qui ne nécessitent pas de guillemets, les noms de colonne sensibles à la casse doivent être indiqués car ils sont stockés dans la base de données. Les littéraux doivent être placés entre apostrophes. Pour plus d'informations, reportez-vous à Différence entre les noms de colonne sensibles à la casse et les littéraux.
Configurer le mapping de colonnes au niveau table avec COLMAP
Si vous utilisez des traces auto-descriptives, toutes les colonnes de l'objet source sont mises en correspondance avec le même nom de colonne sur l'objet cible. Vous devez uniquement gérer les noms de colonne qui sont différents entre la source et la cible ou si vous devez transformer une colonne.
Toutefois, si vous n'utilisez pas de traces auto-descriptives, le mappage par défaut est effectué par ordre de colonne et non par nom de colonne. Ainsi, la colonne 1 de la source sera mise en correspondance avec la colonne 1 de la cible, la colonne 2 avec la colonne 2, etc.
Utilisez l'option COLMAP des paramètres MAP et TABLE pour :
-
mettre en correspondance des colonnes source individuelles avec des colonnes cible portant des noms différents.
-
spécifier un mappage de colonne par défaut lorsqu'un mappage de colonne explicite n'est pas nécessaire.
-
Fournissez des instructions pour sélectionner, mettre en correspondance, traduire et déplacer des données d'une colonne source vers une colonne cible.
Utiliser USEDEFAULTS pour activer le mappage de colonnes par défaut
Vous pouvez utiliser l'option USEDEFAULTS de COLMAP pour indiquer une mise en correspondance automatique des colonnes par défaut pour toutes les colonnes source et cible correspondantes portant des noms identiques. USEDEFAULTS permet de gagner du temps en éliminant la nécessité de mapper explicitement chaque colonne cible.
La mise en correspondance par défaut amène Oracle GoldenGate à mettre en correspondance ces colonnes et, si nécessaire, à traduire les types de données en fonction du fichier de définitions de données. N'indiquez pas de mapping par défaut pour les colonnes déjà mises en correspondance avec une instruction de mapping explicite.
L'exemple suivant de mapping de colonne illustre l'utilisation de mapping de colonne par défaut et explicite pour une table source ACCTBL et une table cible ACCTTAB. La plupart des colonnes sont identiques dans les deux tables, à l'exception des différences suivantes :
-
La table source a une colonne
CUST_NAME, tandis que la table cible a une colonneNAME. -
Une colonne
PHONE_NOà dix chiffres dans la table source correspond à des colonnesAREA_CODE,PHONE_PREFIXetPHONE_NUMBERdistinctes dans la table cible. -
Les colonnes
YY, MMséparées etDDde la table source correspondent à une seule colonneTRANSACTION_DATEde la table cible.
Pour résoudre ces différences, USEDEFAULTS est utilisé pour mapper automatiquement les colonnes similaires, tandis que les fonctions de mapping et de conversion explicites sont utilisées pour des colonnes différentes.
L'exemple suivant illustre le mapping de colonne à l'aide de l'option COLMAP des paramètres MAP et TABLE. Il décrit le mapping de la table source ACCTBL avec la table cible ACCTTAB.
MAP SALES.ACCTBL, TARGET SALES.ACCTTAB,
COLMAP ( USEDEFAULTS,
NAME = CUST_NAME,
TRANSACTION_DATE = @DATE ('YYYY-MM-DD', 'YY',YEAR, 'MM', MONTH, 'DD', DAY),
AREA_CODE = @STREXT (PHONE_NO, 1, 3),
PHONE_PREFIX = @STREXT (PHONE_NO, 4, 6),
PHONE_NUMBER = @STREXT (PHONE_NO, 7, 10)
)
;
Tableau 3 - Exemple de mappage de colonne
| Instruction Parameter | Description |
|---|---|
COLMAP |
Démarre l'instruction COLMAP. |
USEDEFAULTS, |
Met en correspondance les colonnes source telles quelles lorsque les noms de colonne cible sont identiques. |
NAME = CUST_NAME, |
Met en correspondance la colonne source CUST_NAME avec la colonne cible NAME. |
TRANSACTION_DATE = @DATE ('YYYY-MM-DD', 'YY', YEAR, 'MM', MONTH, 'DD', DAY), |
Convertit la date de transaction des colonnes de date source en colonne cible TRANSACTION_DATE à l'aide de la fonction de conversion de colonne @DATE. |
AREA_CODE = @STREXT (PHONE_NO, 1, 3), PHONE_PREFIX = @STREXT (PHONE_NO, 4, 6), PHONE_NUMBER = @STREXT (PHONE_NO, 7, 10)) ; |
Convertit la colonne source PHONE_NO en colonnes cible distinctes de AREA_CODE, PHONE_PREFIX et PHONE_NUMBER à l'aide de la fonction de conversion de colonne @STREXT. |
Pour plus d'informations sur les règles suivies par Oracle GoldenGate pour le mapping de colonne par défaut, reportez-vous à Présentation du mapping de colonne par défaut.
Spécification des colonnes à mettre en correspondance dans la clause COLMAP
La syntaxe COLMAP est la suivante :
COLMAP ([USEDEFAULTS, ] target_column = source_expression)
Dans cette syntaxe, target_column est le nom de la colonne cible et source_expression. Voici quelques exemples de source_expressions :
-
Nom d'une colonne source, tel que
ORD_DATE. -
Constante numérique, telle que
123. -
Constante de chaîne placée entre apostrophes, telle que
'ABCD'. -
Expression utilisant une fonction de conversion de colonne Oracle GoldenGate. Dans une instruction
COLMAP, vous pouvez utiliser n'importe quelle fonction de conversion de colonne Oracle GoldenGate pour transformer les données des colonnes mises en correspondance, par exemple :@STREXT (COL1, 1, 3) -
Voici un exemple d'utilisation de
BEFORE column_name:BEFORE ORD_DATE -
Voici un exemple d'utilisation de
AFTER column_name:AFTER ORD_DATE. Il s'agit de l'option par défaut si un nom de colonne est répertorié.
Si le mapping de colonne implique des colonnes sensibles à la casse de différents types de base de données, indiquez chaque colonne telle qu'elle est stockée dans la base de données.
-
Si la base de données requiert des guillemets doubles pour appliquer la distinction majuscules/minuscules, indiquez le nom de la colonne entre guillemets doubles.
-
Si la base de données distingue les majuscules des minuscules sans nécessiter de guillemets, indiquez le nom de colonne tel qu'il est stocké dans la base de données.
L'exemple suivant illustre un mapping entre une colonne cible dans Oracle AI Database et une colonne source dans une base de données SQL Server sensible à la casse.
COLMAP ("ColA" = ColA)
Pour plus d'informations sur la spécification de noms dans Oracle GoldenGate, reportez-vous à Spécification de noms d'objet dans l'entrée Oracle GoldenGate.
Reportez-vous à Considérations relatives à la globalisation lors de la mise en correspondance de données pour plus d'informations sur la globalisation lors de la mise en correspondance de colonnes source et cible dans des bases de données ayant des jeux de caractères et des paramètres régionaux différents.
Evitez d'utiliser COLMAP pour mettre en correspondance une valeur avec une colonne de clé (ce qui entraîne la mise à jour de l'opération en tant que clé primaire). La clause WHERE utilisée par Oracle GoldenGate pour localiser la ligne cible n'utilisera pas l'image avant correcte de la colonne de clé. Au lieu de cela, il utilisera l'image after. Cela entraînera des erreurs si vous utilisez des fonctions basées sur cette colonne de clé, telles qu'une instruction SQLEXEC.
Limites de mapping de colonne
Voici les limites de mise en correspondance des colonnes :
-
Les colonnes
LOBne peuvent pas être utilisées dans les colonnesFILTER,WHEREou en tant quesource_expressiondans une instructionCOLMAP. Les colonnesLOBsontBLOB,CLOB,NCLOB,XMLType, les types de données définis par l'utilisateur, les tables imbriquées,VARRAYset d'autres types de données spéciaux. -
Si la colonne source contient plus de 4000 octets, elle ne peut pas être utilisée dans les routines de transformation, car la valeur est stockée dans la trace en tant qu'enregistrement
LOB. Par exemple,VARCHAR2(4000 CHAR) dans Oracle et le jeu de caractères japonais est stocké sous forme de 3 octets pour chaque caractère. Cela signifie que la colonne peut comporter 12000 octets et qu'Oracle GoldenGate stocke cette valeur en tant que champLOB. -
La taille de l'instruction SQL complète qu'Oracle GoldenGate exécuterait dépasserait 4 Mo. Par exemple, si vous disposez d'une table contenant des milliers de colonnes
VARCHAR2(4000)et que vous voulez placer 4000 octets dans chacune d'elles, l'instruction SQL totale qu'Oracle GoldenGate va exécuter risque de dépasser la taille maximale de 4 Mo.
Configuration du mappage global de colonnes avec COLMATCH
Utilisez le paramètre COLMATCH pour créer des règles globales pour la mise en correspondance de colonnes. Avec COLMATCH, vous pouvez effectuer une mise en correspondance entre des tables de structure similaire qui ont des noms de colonne différents pour les mêmes ensembles de données. COLMATCH offre un moyen plus pratique de mettre en correspondance des colonnes de ce type que l'utilisation de la mise en correspondance au niveau de la table avec une clause COLMAP dans des instructions TABLE ou MAP individuelles.
La sensibilité à la casse est prise en charge comme suit :
-
Pour MySQL, SQL Server, si la base de données est sensible à la casse,
COLMATCHrecherche une correspondance exacte entre la casse et le nom, qu'un nom soit indiqué entre guillemets ou non. -
Pour les bases de données Oracle AI Database et Db2, où les noms peuvent être sensibles à la casse ou non sensibles à la casse dans la même base de données et où des guillemets sont requis pour afficher la distinction entre les majuscules et les minuscules,
COLMATCHrequiert une correspondance exacte entre les majuscules et les minuscules lorsqu'un nom est entre guillemets dans la base de données.
Syntaxe
COLMATCH
{NAMES target_column = source_column |
PREFIX prefix |
SUFFIX suffix |
RESET}
| Argument | Description |
|---|---|
NAMES target_column = source_column |
Correspond en fonction des noms de colonne. Placez les guillemets autour du nom de colonne s'il respecte la casse et que la base de données requiert des guillemets pour appliquer la distinction entre les majuscules et les minuscules. Pour ces types de base de données, un nom de colonne non entre guillemets est traité comme non sensible à la casse par Oracle GoldenGate. Pour les bases de données qui prennent en charge la distinction entre majuscules et minuscules sans mettre de guillemets, indiquez le nom de colonne tel qu'il est stocké dans la base de données. Si COLMATCH se trouve entre des colonnes de différents types de base de données, assurez-vous que les noms reflètent la représentation de casse appropriée pour chacune d'elles. Par exemple, la commande suivante indique un nom de colonne cible sensible à la casse "aBc" dans une base de données Oracle AI Database et un nom de colonne source sensible à la casse aBc dans une base de données SQL Server sensible à la casse : COLMATCH NAMES "aBc" = aBc. |
PREFIX prefix / SUFFIX suffix |
Ignore le préfixe ou le suffixe de nom indiqué. Placez les guillemets autour du préfixe ou du suffixe si la base de données requiert des guillemets pour appliquer la distinction majuscules/minuscules, par exemple "P_". Pour ces types de base de données, un préfixe ou un suffixe non entre guillemets est traité comme ne respectant pas la casse. Pour les bases de données qui prennent en charge la distinction entre majuscules et minuscules sans guillemets, indiquez le préfixe ou le suffixe tel qu'il est stocké dans la base de données. Par exemple, "P_" indique un préfixe P majuscule. L'exemple suivant indique un préfixe non sensible à la casse à ignorer : COLMATCH PREFIX p_. Le nom de colonne cible P_ABC est mis en correspondance avec le nom de colonne source ABC et le nom de colonne cible P_abc est mis en correspondance avec le nom de colonne source abc. L'exemple suivant indique un suffixe sensible à la casse à ignorer : SUFFIX "_k". Le nom de colonne cible ABC_k est mis en correspondance avec le nom de colonne source ABC et le nom de colonne cible "abc_k" est mis en correspondance avec le nom de colonne source abc. |
RESET |
Désactive les règles COLMATCH précédemment définies pour les instructions TABLE ou MAP suivantes. |
L'exemple suivant illustre quand utiliser COLMATCH. Les tables source et cible sont identiques, sauf que la base de données de table et de colonne names.The légèrement différentes ne tient pas compte de la casse.
| Table ACCT | Table ORD |
|---|---|
CUST_CODE CUST_NAME CUST_ADDR PHONE S_REP S_REPCODE |
CUST_CODE CUST_NAME ORDER_ID ORDER_AMT S_REP S_REPCODE |
| Table ACCOUNT | Table ORDER |
|---|---|
CUSTOMER_CODE CUSTOMER_NAME CUSTOMER_ADDRESS PHONE REP REPCODE |
CUSTOMER_CODE CUSTOMER_NAME ORDER_ID ORDER_AMT REP REPCODE |
Pour mettre en correspondance les colonnes source avec les colonnes cible de cet exemple, ainsi que pour gérer les mises en correspondance ultérieures pour d'autres tables, la syntaxe est la suivante :
COLMATCH NAMES CUSTOMER_CODE = CUST_CODE
COLMATCH NAMES CUSTOMER_NAME = CUST_NAME
COLMATCH NAMES CUSTOMER_ADDRESS = CUST_ADDR
COLMATCH PREFIX S_
MAP SALES.ACCT, TARGET SALES.ACCOUNT, COLMAP (USEDEFAULTS);
MAP SALE.ORD, TARGET SALES.ORDER, COLMAP (USEDEFAULTS);
COLMATCH RESET
MAP SALES.REG, TARGET SALE.REG;
MAP SALES.PRICE, TARGET SALES.PRICE;
En fonction des règles de l'exemple, les événements suivants se produisent :
-
Les données sont mises en correspondance à partir des colonnes
CUST_CODEdes tables sourceACCTetORDavec les colonnesCUSTOMER_CODEdes tables cibleACCOUNTetORDER. -
Le préfixe
S_sera ignoré. -
Les colonnes portant le même nom, telles que les colonnes
PHONEetORDER_AMT, sont automatiquement mises en correspondance à l'aide deUSEDEFAULTSsans règles explicites. Pour plus d'informations, voir Comprendre le mapping de colonne par défaut. -
Le mapping de colonne global précédent est désactivé pour les tables
REGetPRICE. Les colonnes source et cible de ces tables sont automatiquement mises en correspondance car tous les noms sont identiques.
Comprendre le mappage des colonnes par défaut
Pour les traces d'auto-description, si aucun mapping de colonne explicite n'existe, à l'aide de COLMATCH ou de COLMAP, Oracle GoldenGate met en correspondance les colonnes source et cible par défaut conformément aux règles suivantes.
Cela ne s'applique pas si vous utilisez SOURCEDEFS ou TARGETDEFS.
-
Si une colonne source dont le nom et la casse correspondent exactement à ceux de la colonne cible est trouvée, les deux colonnes sont mises en correspondance.
-
Si aucune correspondance de casse n'est trouvée, le mappage du nom de restauration est utilisé. Le mapping de secours effectue un mapping de table cible sans distinction majuscules/minuscules pour rechercher une correspondance de nom. La correspondance de nom de colonne Inexact est appliquée à l'aide de noms en majuscules. Ce comportement est contrôlé par le paramètre
GLOBALSNAMEMATCHIGNORECASE. Vous pouvez désactiver la mise en correspondance du nom de restauration avec le paramètreNAMEMATCHEXACTou le conserver activé, mais avec un message d'avertissement, à l'aide du paramètreNAMEMATCHNOWARNING. -
Les colonnes cible qui ne correspondent à aucune colonne source prennent les valeurs par défaut déterminées par la base de données.
Si le mappage par défaut ne peut pas être effectué, la colonne cible est définie par défaut sur l'une des valeurs indiquées dans le tableau suivant.
| Type de colonne | Valeur |
|---|---|
| Numérique | Zéro (0) |
Caractère ou VARCHAR |
Espaces |
| Date ou date/heure | Date et heures actuelles |
Colonnes pouvant prendre une valeur NULL |
NULL |
Conversions de type de données
Découvrez comment Oracle GoldenGate met en correspondance les types de données.
Colonnes numériques
Les colonnes numériques sont converties pour correspondre au type et à l'échelle de la colonne cible. Si l'échelle de la colonne cible est inférieure à celle de la source, le nombre est tronqué à droite. Si l'échelle de la colonne cible est supérieure à celle de la source, le nombre est complété par des zéros sur la droite.
Pour plus d'informations, vous pouvez indiquer une valeur de substitution pour les données numériques non valides rencontrées lors de la mise en correspondance de colonnes numériques à l'aide du paramètre REPLACEBADNUM.
Colonnes de type caractère
Les colonnes de type caractère peuvent accepter des types de données basés sur des caractères tels que VARCHAR, des valeurs numériques sous forme de chaîne, des dates et heures sous forme de chaîne et des littéraux de type chaîne. Si l'échelle de la colonne cible est inférieure à celle de la source, la colonne est tronquée à droite. Si l'échelle de la colonne cible est supérieure à celle de la source, la colonne est complétée par des espaces à droite.
Les littéraux doivent être placés entre apostrophes.
Vous pouvez contrôler la réponse du processus Oracle GoldenGate lorsqu'il n'existe aucun point de code valide pour le jeu de caractères source ou cible lors de la mise en correspondance de colonnes de caractères en utilisant le paramètre REPLACEBADCHAR pour plus d'informations.
Colonnes de date/heure
Les colonnes Datetime (DATE, TIME et TIMESTAMP) peuvent accepter des colonnes datetime et alphanumériques, ainsi que des littéraux de type chaîne. Les littéraux doivent être placés entre apostrophes. Pour mettre en correspondance une colonne de caractères avec une colonne de date/heure, assurez-vous qu'elle est conforme au format SQL externe Oracle GoldenGate de YYYY-MM-DD HH:MI:SS.FFFFFF.
Oracle GoldenGate prend en charge les données d'horodatage de 0001-01-03 00:00:00 à 9999-12-31 23:59:59. Si un horodatage est converti de GMT en heure locale, ces limites s'appliquent également à l'horodatage résultant. Selon le fuseau horaire, la conversion peut ajouter ou soustraire des heures, ce qui peut entraîner un dépassement de la limite inférieure ou supérieure prise en charge.
La précision requise varie selon le type de données et la plate-forme cible. Si l'échelle de la colonne cible est inférieure à celle de la source, les données sont tronquées à droite. Si l'échelle de la colonne cible est supérieure à celle de la source, la colonne est étendue sur la droite avec les valeurs de la date et de l'heure actuelles.
Sélectionner et filtrer les lignes
Le filtrage ne peut être effectué que sur les colonnes disponibles pour Oracle GoldenGate. Dans le processus d'extraction TRANLOG, Oracle GoldenGate a accès à toutes les colonnes présentes dans les fichiers de journalisation et dans la base de données. Si les colonnes ne figurent pas dans les fichiers de journalisation, elles doivent être explicitement extraites (à l'aide de FETCHCOLS) pour pouvoir les filtrer. Dans la pompe Extract et dans le processus Replicat, les colonnes doivent être disponibles dans le fichier trace. Pour cette raison, toute colonne à utiliser dans une clause FILTER ou WHERE doit être journalisée explicitement à l'aide de ADD TRANDATA COLS et vous devez conserver la valeur par défaut LOGALLSUPCOLS.
Pour filtrer ou sélectionner des lignes pour l'extraction ou la réplication, utilisez les clauses FILTER et WHERE des paramètres TABLE et MAP.
La clause FILTER offre plus de fonctionnalités que la clause WHERE car vous pouvez utiliser n'importe quelle fonction de conversion de colonne Oracle GoldenGate, tandis que la clause WHERE accepte les opérateurs WHERE de base.
Sélectionner des lignes avec une clause FILTER
Utilisez une clause FILTER pour sélectionner des lignes en fonction d'une valeur numérique à l'aide d'opérateurs de base ou d'une ou plusieurs fonctions de conversion de colonne Oracle GoldenGate.
Remarque : pour filtrer une colonne en fonction d'une chaîne, utilisez l'une des fonctions de chaîne Oracle GoldenGate ou utilisez une clause WHERE.
La syntaxe de FILTER dans une instruction TABLE est la suivante :
TABLE source_table
, FILTER (
[, ON INSERT | ON UPDATE| ON DELETE]
[, IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE]
, filter_clause);
La syntaxe de FILTER dans une instruction MAP est la suivante et inclut une option de traitement des erreurs.
MAP source_table, TARGET target_table,
, FILTER (
[, ON INSERT | ON UPDATE| ON DELETE]
[, IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE]
[, RAISEERROR error_number]
, filter_clause);
Les éléments de clause FILTER valides sont les suivants :
-
Fonction de conversion de colonne Oracle GoldenGate. Ces fonctions sont intégrées à Oracle GoldenGate afin que vous puissiez effectuer des tests, manipuler des données, extraire des valeurs, etc. Pour plus d'informations sur les fonctions de conversion Oracle GoldenGate, reportez-vous à Test et transformation de données.
-
Nombres
-
Colonnes contenant des nombres
-
Fonctions renvoyant des nombres
-
Opérateurs arithmétiques:
-
+(plus) -
-(moins) -
*(multiplier) -
/(diviser) -
%(remainder)
-
-
Opérateurs de comparaison :
-
>(supérieur à) -
>=(supérieur ou égal à) -
<(moins de) -
<=(inférieur ou égal à) -
=(égal à) -
<>(différent) -
Les résultats dérivés des comparaisons peuvent être nuls (indiquant
FALSE) ou non nuls (indiquantTRUE).
-
-
Parenthèses (pour regrouper les résultats dans l'expression)
-
Opérateurs de conjonction :
AND,OR
Utilisez les options FILTER suivantes pour indiquer les opérations SQL concernées par une clause de filtre. Chacune de ces options peut être combinée.
ON INSERT | ON UPDATE | ON DELETE IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE
Utilisez l'option RAISEERROR de FILTER dans le paramètre MAP pour générer une erreur définie par l'utilisateur en cas d'échec du filtre. Cette option est utile lorsque vous devez déclencher un événement en réponse à l'échec.
Utilisez la fonction @RANGE dans une clause FILTER pour répartir la charge globale de traitement entre plusieurs instructions MAP ou TABLE.
Voici un exemple :
REPERROR (9999, EXCEPTION)
MAP OWNER.SRCTAB, TARGET OWNER.TARGTAB,
SQLEXEC (ID CHECK, ON UPDATE, QUERY ' SELECT COUNT FROM TARGTAB WHERE PKCOL = :P1 ', PARAMS (P1 = PKCOL)),
FILTER (BALANCE > 15000),
FILTER (ON UPDATE, @BEFORE (COUNT) = CHECK.COUNT)
;
MAP OWNER.SRCTAB, TARGET OWNER.TARGEXC,
EXCEPTIONSONLY,
COLMAP ( USEDEFAULTS,
ERRTYPE = 'UPDATE FILTER FAILED'
)
;
Tableau 4 : Utilisation de plusieurs instructions FILTER
| Fichier de paramètres | Description |
|---|---|
REPERROR (9999, EXCEPTION) |
Génère une exception pour l'erreur indiquée. |
MAP OWNER.SRCTAB, TARGET OWNER.TARGTAB, |
Démarre l'instruction MAP. |
SQLEXEC (ID CHECK, ON UPDATE, QUERY ' SELECT COUNT FROM TARGTAB ' 'WHERE PKCOL = :P1 ', PARAMS (P1 = PKCOL)), |
Exécute une requête pour extraire la valeur actuelle de la colonne COUNT chaque fois qu'une mise à jour est détectée. L'option BEFOREFILTER permet également d'exécuter la requête ou la procédure stockée avant de traiter la clause FILTER. Ainsi, les valeurs de la partie SQLEXEC peuvent être utilisées dans FILTER lors de l'exécution. |
FILTER (BALANCE > 15000), |
Utilise une clause FILTER pour sélectionner les lignes où le solde est supérieur à 15000. |
FILTER (ON UPDATE, @BEFORE (COUNT) = CHECK.COUNT) |
Utilise une autre clause FILTER pour garantir que la valeur de la colonne COUNT source avant une mise à jour correspond à la valeur de la colonne cible avant d'appliquer la mise à jour cible. |
; |
Le point-virgule termine l'instruction MAP. |
MAP OWNER.SRCTAB, TARGET OWNER.TARGEXC, EXCEPTIONSONLY, COLMAP (USEDEFAULTS, ERRTYPE = 'UPDATE FILTER FAILED'); |
Désigne une instruction MAP d'exception. La clause REPERROR pour l'erreur 9999 garantit que la mise en correspondance des exceptions avec TARGEXC sera exécutée. |
Exemple 9-5 Appel de la fonction @COMPUTE
L'exemple suivant appelle la fonction @COMPUTE pour extraire les enregistrements dans lesquels le prix multiplié par le montant dépasse 10 000.
MAP SALES.TCUSTORD, TARGET SALES.TORD,
FILTER (@COMPUTE (PRODUCT_PRICE * PRODUCT_AMOUNT) > 10000);
Exemple 9-6 Appel de la fonction @STREQ
La fonction suivante utilise la fonction @STREQ pour extraire les enregistrements dont la valeur d'une colonne de caractères est 'JOE'.
TABLE ACCT.TCUSTORD, FILTER (@STREQ ("Name", 'joe') > 0);
Exemple 9-7 Sélection d'enregistrements
Les enregistrements suivants sélectionnent les enregistrements dans lesquels la colonne AMOUNT est supérieure à 50 et exécutent le filtre sur les opérations UPDATE et DELETE.
TABLE ACT.TCUSTORD, FILTER (ON UPDATE, ON DELETE, AMOUNT > 50);
Exemple 9-8 Utilisation de la fonction @RANGE
(Fichier de paramètres du groupe Replicat 1)
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1, 2, ID));
(Fichier de paramètres du groupe Replicat 2)
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (2, 2, ID));
Vous pouvez combiner plusieurs clauses FILTER dans une instruction MAP ou TABLE, comme indiqué dans le Table 9-4, qui affiche une partie d'un fichier de paramètres de réplication. Oracle GoldenGate exécute les filtres dans l'ordre indiqué, jusqu'à ce que l'un échoue ou jusqu'à ce que tous soient transmis. Si un filtre échoue, tous échouent.
Sélectionner des lignes avec une clause WHERE
Utilisez l'un des éléments du tableau 9-5 dans une clause WHERE pour sélectionner ou exclure des lignes (ou les deux) en fonction d'une instruction conditionnelle. Chaque clause WHERE doit être placée entre parenthèses. Les littéraux doivent être placés entre apostrophes.
Tableau 5 Opérateurs WHERE autorisés
| Elément | Exemples |
|---|---|
| Noms de colonne | PRODUCT_AMT |
| Valeurs numériques | -123, 5500.123 |
| Chaînes littérales | 'AUTO', 'Ca' |
| Tests de colonne intégrés | @NULL, @PRESENT, @ABSENT (la colonne est NULL, présente ou absente dans la ligne). Ces tests sont intégrés à Oracle GoldenGate. Reportez-vous à Remarques concernant la sélection de lignes avec FILTER et WHERE. |
| opérateurs de comparaison | =, <>, >, <, >=, <= |
| Opérateurs conjonctifs | AND, OR |
| Parenthèses de regroupement | Utilisez les parenthèses ouvrantes et fermantes ( ) pour le regroupement logique de plusieurs éléments. |
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.
Les opérateurs arithmétiques et les types de données à virgule flottante ne sont pas pris en charge par WHERE. Pour utiliser des conditions de sélection plus complexes, utilisez une clause FILTER ou une routine d'exit utilisateur.
La syntaxe de WHERE est identique dans les instructions TABLE et MAP :
TABLE table, WHERE (clause);
MAP source_table, TARGET target_table, WHERE (clause);
Remarques concernant la sélection de lignes avec FILTER et WHERE
Les suggestions suivantes peuvent vous aider à créer une clause de sélection réussie. Remarque : les exemples de cette section supposent une base de données non sensible à la casse.
Garantir la disponibilité des données pour les filtres
Si la base de données consigne uniquement les valeurs des colonnes modifiées dans le journal des transactions, des erreurs peuvent survenir si l'une des colonnes non modifiées est référencée par des critères de sélection. Oracle GoldenGate ignore ces opérations de ligne, les renvoie dans le fichier de rebut et émet un avertissement.
Pour éviter les erreurs de colonne manquante, créez les conditions de sélection comme suit :
-
Utilisez uniquement des colonnes de clé primaire comme critères de sélection, si possible.
-
Rendez disponibles les valeurs de colonne requises en activant la journalisation supplémentaire pour ces colonnes. Vous pouvez également utiliser l'option
FETCHCOLSouFETCHCOLSEXCEPTdu paramètreTABLE. Ces options sont valides pour toutes les bases de données prises en charge. Ils interrogent la base de données pour extraire les valeurs si elles ne sont pas présentes dans le journal. Pour extraire les valeurs avant l'exécution de la clauseFILTERouWHERE, incluez l'optionFETCHBEFOREFILTERdans l'instructionTABLEavant la clauseFILTERouWHERE. Exemple :
TABLE DEMO.PEOPLE, FETCHBEFOREFILTER, FETCHCOLS (age), FILTER (age > 50);
- Testez d'abord la présence d'une colonne, puis la valeur de la colonne. Pour tester la présence d'une colonne, utilisez la syntaxe suivante.
column_name {= | <>} {@PRESENT | @ABSENT}
L'exemple suivant renvoie tous les enregistrements lorsque la colonne amount est supérieure à 10 000 et n'entraîne pas la suppression d'un enregistrement lorsque amount est absent.
WHERE (amount = @PRESENT AND amount > 10000)
Comparer des valeurs de colonne
Pour vous assurer que les éléments utilisés dans une comparaison correspondent, comparez les types de colonne appropriés :
-
Colonnes de type caractère vers des chaînes littérales.
-
Colonnes numériques avec des valeurs numériques, qui peuvent inclure un signe et un point décimal.
-
Colonnes de date et d'heure en chaînes littérales, selon le format dans lequel la colonne est extraite par l'application.
Test des valeurs NULL
Pour évaluer les colonnes pour les valeurs NULL, utilisez la syntaxe suivante.
column {= | <>} @NULL
La commande suivante renvoie TRUE si la valeur de colonne est NULL, ce qui réplique la ligne. Elle renvoie FALSE pour tous les autres cas (y compris une colonne manquante dans l'enregistrement).
WHERE (amount = @NULL)
La commande suivante renvoie TRUE uniquement si la colonne est présente dans l'enregistrement et non NULL.
WHERE (amount = @PRESENT AND amount <> @NULL)
Remarque : si une valeur dans la trace contient plus de 4000 octets, la fonction @NULL renvoie TRUE.
Extraire les valeurs avant et après
Pour les opérations de mise à jour et de suppression, il peut être utile d'extraire les valeurs BEFORE des colonnes source (les valeurs avant la mise à jour). Pour les insertions, toutes les valeurs de colonne sont considérées comme des images AFTER.
Ces valeurs sont stockées dans la trace et peuvent être utilisées dans des filtres et des mappings de colonnes. Ainsi, vous pouvez effectuer les opérations suivantes :
-
Extraire l'image "avant" d'une ligne dans le cadre d'une spécification de mise en correspondance de colonnes dans une instruction
MAPd'exceptions, et mettre en correspondance ces valeurs avec une table d'exceptions à utiliser dans le test ou le dépannage de routines de résolution de conflits. -
Effectuer des calculs delta. Par exemple, si une table comporte une colonne
Balance, vous pouvez calculer le résultat net d'une transaction particulière en soustrayant le solde d'origine du nouveau solde, comme dans l'exemple suivant :MAP "owner"."src", TARGET "owner"."targ", COLMAP (PK1 = PK1, delta = balance - @BEFORE (balance));Remarque : l'exemple précédent indique une base de données sensible à la casse, telle qu'Oracle. Les noms de table sont entre guillemets pour refléter la distinction majuscules/minuscules.
Pour référencer la valeur Avant
-
Utilisez la fonction de conversion de colonne
@BEFOREavec le nom de la colonne pour laquelle vous voulez une valeur avant, comme suit :@BEFORE (column_name) -
Utilisez le paramètre
GETUPDATEBEFORESdans le fichier de paramètres d'extraction pour capturer les images avant de l'enregistrement de transaction, ou utilisez-le dans le fichier de paramètres de réplication pour utiliser l'image avant dans un mapping ou un filtre de colonne. Si vous utilisez la fonctionnalité de résolution et de détection des conflits, vous pouvez utiliser l'optionGETBEFORECOLSdeTABLE. Pour utiliser ces paramètres, toutes les colonnes doivent être présentes dans le journal des transactions. Si la base de données consigne uniquement les valeurs des colonnes qui ont été modifiées, l'utilisation de la fonction@BEFOREpeut entraîner une condition "colonne manquante" et le mapping de colonnes est exécuté comme si la colonne ne figurait pas dans l'enregistrement. Reportez-vous à Assurance de la disponibilité des données pour les filtres pour vous assurer que les valeurs de colonne sont disponibles.Oracle GoldenGate fournit également la fonction
@AFTERà extraire après les valeurs lorsque cela est nécessaire pour le filtrage, pour une utilisation dans des fonctions de conversion ou à d'autres fins. Reportez-vous à@BEFOREet à@AFTERdans le guide Référence des paramètres et des fonctions pour Oracle GoldenGate.
Sélection des colonnes
Pour contrôler les colonnes d'une table source extraites par Oracle GoldenGate, utilisez les options COLS et COLSEXCEPT du paramètre TABLE. Utilisez COLS pour sélectionner des colonnes à extraire et COLSEXCEPT pour sélectionner toutes les colonnes à l'exception de celles désignées par COLSEXCEPT.
La restriction des colonnes extraites peut être utile lorsqu'une table cible ne contient pas les mêmes colonnes que la table source ou lorsque les colonnes contiennent des informations confidentielles, telles qu'un numéro d'identification personnel ou d'autres informations commerciales propriétaires.
Sélectionner et convertir des opérations SQL
Par défaut, Oracle GoldenGate capture et applique les opérations INSERT, UPDATE et DELETE. Vous pouvez utiliser les paramètres suivants dans le fichier de paramètres Extract ou Replicat pour contrôler les types d'opération traités, tels que les insertions ou uniquement les insertions et les mises à jour.
GETINSERTS | IGNOREINSERTS
GETUPDATES | IGNOREUPDATES
GETDELETES | IGNOREDELETES
Vous pouvez convertir un type d'opération SQL en un autre en utilisant les paramètres suivants dans le fichier de paramètres Replicat :
-
Utilisez
INSERTUPDATESpour convertir les opérations de mise à jour source en insertions dans la table cible. Cela est utile pour gérer l'historique des transactions sur cette table. L'enregistrement du journal des transactions doit contenir toutes les valeurs de colonne de la table, et pas seulement les valeurs modifiées. Certaines bases de données ne consignent pas les valeurs de ligne complète dans leur journal de transactions, mais uniquement les valeurs modifiées. -
Utilisez
INSERTDELETESpour convertir toutes les opérations de suppression source en insertions dans la table cible. Cela permet de conserver un historique de tous les enregistrements qui se trouvaient dans la base de données source. -
Utilisez
UPDATEDELETESpour convertir les suppressions source en mises à jour sur la cible.
Utilisation de l'historique des transactions
Oracle GoldenGate vous permet de conserver un historique des modifications apportées à un enregistrement cible et de mettre en correspondance les informations sur l'opération à l'origine de chaque modification. Cet historique peut être utile pour créer un système de reporting basé sur les transactions qui contient un enregistrement distinct pour chaque opération effectuée sur une table, au lieu de ne contenir que la version la plus récente de chaque enregistrement.
Par exemple, les séries d'opérations suivantes effectuées sur une table cible nommée CUSTOMER ne laisseraient aucune trace de l'ID de Dave. La dernière opération supprime l'enregistrement, il n'y a donc aucun moyen de connaître l'historique du compte de Dave ou son solde final.
Tableau 6 Historique des opérations de la table CUSTOMER
| Séquence | Opération | ID | BALANCE |
|---|---|---|---|
1 |
Insert |
Dave |
1000 |
2 |
Update |
Dave |
900 |
3 |
Update |
Dave |
1250 |
4 |
Delete |
Dave |
1250 |
La conservation de cet historique en tant que série d'enregistrements peut s'avérer utile à bien des égards. Par exemple, vous pouvez générer l'effet net des transactions.
Pour implémenter le reporting des transactions
-
Pour préparer le processus Extract à capturer les valeurs avant, utilisez le paramètre
GETUPDATEBEFORESdans le fichier de paramètres Extract. Une valeur avant (ou une image avant) est la valeur existante d'une colonne avant qu'une mise à jour ne soit effectuée. Les images "avant" permettent à Oracle GoldenGate de créer l'enregistrement de transaction. -
Pour préparer le processus Replicat à publier toutes les opérations sous forme d'insertions, utilisez le paramètre
INSERTALLRECORDSdans le fichier de paramètres du processus Replicat. Chaque opération d'une table devient un nouvel enregistrement dans cette table. -
Pour mettre en correspondance l'historique des transactions, utilisez les valeurs renvoyées de l'option
GGHEADERde la fonction de conversion de colonne@GETENV. Incluez la fonction de conversion comme expression source dans une instructionCOLMAPdans le paramètreTABLEouMAP.
A l'aide de l'exemple de série de transactions présenté dans le tableau 9-6, les configurations de paramètres suivantes peuvent être créées pour générer une vue plus orientée transaction des clients, plutôt que le dernier état de la base de données.
| Processus | Instructions de paramètre |
|---|---|
| Extraction | GETUPDATEBEFORES TABLE ACCOUNT.CUSTOMER; |
| Réplication | INSERTALLRECORDS MAP SALES.CUSTOMER, TARGET SALES.CUSTHIST, COLMAP (TS = @GETENV ('GGHEADER', 'COMMITTIMESTAMP'), BEFORE_AFTER = @GETENV ('GGHEADER', 'BEFOREAFTERINDICATOR'), OP_TYPE = @GETENV ('GGHEADER', 'OPTYPE'), ID = ID, BALANCE = BALANCE); |
Remarque : il ne s'agit pas d'un fichier de paramètres complet pour un processus Oracle GoldenGate. Notez également que ces exemples représentent une base de données non sensible à la casse.
Cette configuration permet d'effectuer des requêtes telles que les suivantes, qui renvoie la somme nette de chaque transaction ainsi que l'heure de la transaction et l'ID client.
SELECT AFTER.ID, AFTER.TS, AFTER.BALANCE - BEFORE.BALANCE
FROM CUSTHIST AFTER, CUSTHIST BEFORE
WHERE AFTER.ID = BEFORE.ID AND AFTER.TS = BEFORE.TS AND
AFTER.BEFORE_AFTER = 'A' AND BEFORE.BEFORE_AFTER = 'B';