ADD EXTRACT

Valide pour les bases de données Db2, HP NonStop, MySQL, Oracle, PostgreSQL, SQL Server, Sybase ASE et Yugabyte prises en charge.

Utilisez ADD EXTRACT pour créer un processus de capture de base de données source, appelé extraction. L'extraction peut être créée en tant qu'extraction des données de modification, auquel cas les transactions en cours sont capturées à partir du journal de base de données ou par un autre moyen selon le fournisseur de base de données, ou en tant qu'extraction du chargement initial, auquel cas les enregistrements présents dans les tables de base de données sont capturés.

Il est recommandé de ne créer qu'une extraction de données de modification ou de chargement initial par base de données source. Toutefois, dans de rares cas, l'utilisation de plusieurs extractions peut améliorer le débit de capture.

Oracle GoldenGate peut prendre en charge un grand nombre de processus d'extraction et de réplication simultanés par déploiement, en fonction des ressources disponibles avec le système d'exploitation. Toutefois, il est recommandé de surveiller les ressources système lorsque des processus d'extraction ou de réplication sont ajoutés, et de limiter le nombre total de processus par déploiement à 300.

Remarque :

Si vous créez une extraction portant le même nom qu'une ancienne extraction, assurez-vous que l'ancienne extraction a été complètement enlevée et supprimée. Vous pouvez utiliser l'option DELETE EXTRACT pour enlever l'extraction et tous ses composants.
La taille de cette commande ne peut pas dépasser 500 octets pour l'ensemble des mots-clés et des entrées, y compris les textes saisis dans l'option DESC.
Pour DB2 for i, la commande établit un point de départ global pour tous les journaux. Cette première étape est requise. Une fois la commande ADD EXTRACT émise, vous pouvez éventuellement positionner n'importe quel journal au niveau d'un numéro de séquence d'écriture de journal spécifique en utilisant la commande ALTER EXTRACT avec une option de journal appropriée.
Pour les bases de données Oracle et PostgreSQL, établissez une connexion à la base de données source à l'aide de DBLOGIN USERIDALIAS, puis exécutez la commande REGISTER EXTRACT avant d'ajouter l'extraction. Pour plus de détails, reportez-vous à la commande REGISTER EXTRACT.
Pour SQL Server, établissez une connexion à la base de données source avec DBLOGIN USERIDALIAS, avant d'ajouter l'extraction. Cette opération est nécessaire pour que le service d'administration lie les informations d'identification au processus d'extraction.

Syntaxe

ADD EXTRACT extract-name
|             { SOURCEISTABLE |
|              [ INTEGRATED ] TRANLOG
|               {, BEGIN     [ NOW | yyyy-mm-ddThh:mm.ssZ | LSN value | EOL | EOF | EXTRBA archive-offset-number |  SCN  scn }
|               [, DESC        description    ]
|               [, CRITICAL    [ YES | NO ]     ]
|               [, ENCRYPTIONPROFILE     encryption-profile-name]
|               [, GTIDSET gtidset
|               [, PROFILE
|                 [ AUTOSTART   [ YES | NO ]
|                       [ DELAY     delay-number   ] ]
|                 [ AUTORESTART [ YES | NO ]
|                       [ RETRIES          retries-number ]
|                       [ WAITSECONDS      wait-number    ]
|                       [ RESETSECONDS     reset-number   ]
|                       [ DISABLEONFAILURE [ YES | NO ] ] ] ]
|               [ LOGNUM lognum]
|               [ LOGPOS logpos]

extract_name

Nom d'une extraction. Il peut contenir jusqu'à huit caractères. Reportez-vous à Choix de noms pour les processus et les fichiers.

SOURCEISTABLE

Crée une tâche d'extraction qui extrait des enregistrements complets des tables spécifiées pour un chargement initial à l'aide d'Oracle GoldenGate. Lors de l'utilisation de SOURCEISTABLE, n'indiquez aucune option de service.

Les paramètres de tâche doivent être spécifiés dans le fichier de paramètres. Voir Add Initial Load Extract Using the Admin Client dans la documentation des microservices Oracle GoldenGate.

TRANLOG [bsds_name]

Utilisez cette option pour toutes les bases de données. TRANLOG exige l'option BEGIN.

(Db2 sur z/OS) Vous pouvez vous servir de l'option bsds_name pour Db2 sur un système z/OS afin d'indiquer le nom d'ensemble de données bootstrap du journal des transactions. Toutefois, il n'est ni requis, ni utilisé. Vous n'avez pas besoin de modifier les paramètres TRANLOG existants.

(Oracle) L'extraction lit directement les fichiers de journalisation Oracle. Reportez-vous à INTEGRATED TRANLOG pour découvrir une autre configuration.

INTEGRATED TRANLOG

Valide pour Oracle.

Ajoute l'extraction en mode de capture intégré. Dans ce mode, l'extraction s'intègre au serveur de log mining de base de données, qui lui transmet les enregistrements de modification logiques directement. Avant de recourir à INTEGRATED TRANLOG, utilisez la commande REGISTER EXTRACT.

BEGIN {NOW yyyy-mm-ddthh:mm.ssZ}

Indique dans la source de données un horodatage à partir duquel commencer le processus.

Remarque : vous devez enregistrer l'extraction avant de positionner l'extraction à un horodatage spécifique.

NOW

NOW indique le moment où la commande ADD EXTRACT est émise. Lorsque l'extraction démarre, elle tente d'effectuer la position au niveau d'une frontière de transaction à cette heure spécifique ou ultérieure. Le positionnement d'une extraction par NOW n'est pas aussi précis que les autres méthodes, telles que le positionnement par LSN, SCN ou LRI, et nécessite que le serveur de base de données et le serveur Oracle GoldenGate soient définis sur les mêmes heures et fuseaux horaires.

Pour DB2 LUW, seuls les enregistrements de validation et d'arrêt de transaction contiennent des horodatages. La position de départ d'extraction ne peut donc être calculée que par rapport à ces horodatages. Il s'agit d'une limite de l'API utilisée par Oracle GoldenGate. Le positionnement en fonction de l'horodatage n'est pas précis et peut de plus prendre un certain temps. Il est recommandé d'utiliser les options LRI ou EOL dès que cela peut être possible.
yyyy-mm-ddthh:mm.ssZ

Date et heure (horodatage) au format indiqué. Par exemple, 2017-07-14T14:54:45Z.
yyyy-mm-ddT[ hh:mi:[ss[.cccccc]]]Z

Date et heure (horodatage) au format indiqué. Dans le cas d'une extraction Oracle et pour PostgreSQL, la valeur d'horodatage doit être supérieure à l'horodatage de l'inscription de l'extraction auprès de la base de données.

Le positionnement en fonction de l'horodatage dans PostgreSQL comprend les scénarios suivants :
- Scénario 1
  
  Si track_commit_timestamp est défini suroff, la sortie suivante sera affichée lorsque le processus d'extraction démarre, peu importe la méthode de positionnement employée :
```
2020-04-29T02:15:54Z
```
- Scénario 2
  
  Si track_commit_timestamp est activé avant l'inscription de l'extraction, l'horodatage correct sera affiché une fois les enregistrements propagés dans la base de données source, comme indiqué dans l'exemple suivant :
```
2020-04-29 02:19:07 INFO OGG-01515 Positioning to begin time Apr 29,2020 2:18:38 AM.
```
- Scénario 3
  
  Si track_commit_timestamp est activé après l'inscription de l'extraction, il est possible que les anciens enregistrements soient disponibles dans le journal pour lequel l'horodatage de validation n'est pas créé avec l'élément transaction ID associé. Dans ce cas, si l'extraction n'obtient pas l'horodatage, elle utilisera l'horodatage par défaut indiqué dans le scénario 1. Le résultat obtenu est semblable au résultat suivant :
```
020-04-29 01:55:07 INFO OGG-01517 Position of first record processed LSN: 0/221D028, Jan 1, 1970 12:00:00 PM.
```
- Un horodatage passé ne peut pas être indiqué si l'emplacement de réplication a été déplacé.

EXTRBA archive-offset_number

Valide pour DB2 z/OS.

Indique l'adresse d'octet relative dans un journal de transaction à partir de laquelle démarrer la capture des données.

Le format requis est le suivant :0Xnnn, où nnn est un nombre hexadécimal de 1 à 20 chiffres (le premier caractère est le chiffre zéro, le deuxième peut être la lettre majuscule ou minuscule x).

EOL

Valide pour DB2 for i, DB2 LUW, MySQL, PostgreSQL et SQL Server.

Configure le traitement de sorte qu'il démarre à la fin des fichiers journaux (ou journaux) dans lesquels l'enregistrement suivant sera écrit. Les éventuelles transactions actives ne sont pas capturées.

Pour Db2 LUW, cette option configure l'exécution de sorte qu'elle démarre à la valeur LRI active dans les fichiers journaux. La valeur LRI active correspond à la position à la fin des fichiers journaux dans lesquels l'enregistrement suivant sera écrit. Les éventuelles transactions actives ne sont pas capturées.

Pour PostgreSQL, la commande DBLOGIN est requise pour la position en fonction de la valeurEOL.

Pour MySQL, cette option détecte la position correspondant à la fin du fichier et démarre la lecture des transactions à partir de ce point. La position EOL n'est pas parfaitement exacte si des données sont continuellement écrites dans le journal binaire.

EOF

Valide pour MySQL, DB2 z/OS, DB2 LUW, SQL Server, PostgreSQL, Oracle GoldenGate for DAA.

LSN value

Valide pour DB2 z/OS, PostgreSQL et SQL Server.

Indique la transaction LSN à compter de laquelle démarrer la capture des données. L'alias de cette option est EXTLSN. Le positionnement à un numéro de séquence de journal est précis.

Pour Db2 z/OS, la valeur LSN peut être une série de chiffres hexadécimaux ou une série de chiffres décimaux. S'il est au format hexadécimal, le préfixe 0X ou 0x doit être suivi de 1 à 20 chiffres hexadécimaux (0-9, a-g ou A-G). Si la valeur est au format décimal, elle ne contient aucun préfixe, et comporte entre 1 et 25 chiffres décimaux (0-9).

Pour PostgreSQL, la valeur LSN peut être hi ou lo. Définissez la valeur sur hi pour le point d'entrée du fichier journal. Lo correspond à la position dans le fichier journal. la position LSN doit se situer entre la position du redémarrage d'emplacement de réplication et l'emplacement en cours de journal à écriture anticipée. Si la position indiquée existe dans la plage mentionnée, l'extraction génère une erreur.

Pour SQL Server, LSN indique la transaction LSN à laquelle démarrer la capture des données. L'alias de cette option est EXTLSN.

La valeur de LSN indiquée doit exister en tant que valeur de tran_begin_lsn valide dans la table système cdc.lsn_time_mapping, sinon l'extraction tentera d'effectuer le positionnement après la valeur LSN fournie.

Les spécifications LSN valides pour SQL Server sont les suivantes :

Chaîne hexadécimale séparée par des signes deux points (8:8:4) complétée par des zéros à gauche et ayant pour préfixe 0X. Exemple : 0X00000d7e:0000036b:0001
Chaîne hexadécimale séparée par des signes deux points ayant pour préfixe 0X sans zéros à gauche. Exemple : 0Xd7e:36b:1

Pour connaître la valeur LSN minimale disponible, effectuez la requête suivante :

SELECT min([tran_begin_lsn]) FROM [cdc].[lsn_time_mapping] with (nolock) where tran_id <> 0x00

Les exemples suivants illustrent l'utilisation de la valeur LSN pour Db2 z/OS :

Exemple 1 :

ADD EXTRACT extn TRANLOG, LSN 0xDEE40E4F27A3245400

Exemple 2 :

ADD EXTRACT extn TRANLOG, LSN 22216433159121980904448

L'exemple suivant illustre la valeur LSN pour SQL Server :

ADD EXTRACT extn TRANLOG, LSN 0X00000d7e:0000036b:0001

LRI value

Valide pour DB2 LUW. Indique une position de départ dans les journaux de transactions lors du démarrage de l'extraction.

Vous pouvez utiliser l'option LRI pour les systèmes Db2 LUW afin d'indiquer le LRI au niveau duquel l'extraction peut commencer de capturer des enregistrements de journal des transactions. Vous pouvez vous servir du db2logsForRfwd pour obtenir le LRI. Cet utilitaire fournit les plages LRI figurant dans les journaux Db2.

Même si l'extraction se positionne sur un LRI donné, ce LRI n'est pas forcément le premier traitement traité par l'extraction. L'extraction ignore de nombreux types d'enregistrement présents dans les fichiers journaux, par exemple les enregistrements de journal internes DB2. L'extraction indique le LRI de départ réel dans le fichier de rapport d'extraction.

LOGNUM lognum

Valide pour MySQL.

Il s'agit du numéro de fichier journal. ADD EXTRACT échoue si la valeur LOGNUM contient des zéros précédant la valeur. Par exemple, ADD EXTRACT ext1, TRANLOG, LOGNUM 000001, LOGPOS 0 échouera. Au lieu de cela, définissez LOGNUM sur 1 pour que cet exemple aboutisse.

LOGPOS logpos

Il s'agit d'une valeur de position d'événement dans le fichier journal qui identifie un enregistrement de transaction spécifique. Les valeurs de position d'événement sont stockées dans la section d'en-tête d'un enregistrement de journal. pour vous positionner au début d'un fichier binlog, définissez LOGPOS sur 0.

SEQNO sequence_number

Valide pour DB2 for i. Démarre la capture au niveau de (ou juste après) un numéro de séquence système, à savoir un nombre décimal de 20 chiffres au maximum.

SCN value

Valide pour Oracle.

Démarre l'extraction au niveau de la transaction dans le fichier de journalisation correspondant au numéro de modification système (SCN) Oracle indiqué. Pour une extraction en mode intégré, la valeur du numéro SCN doit être supérieure au numéro SCN de l'inscription de l'extraction auprès de la base de données. Pour plus d'informations, reportez-vous à REGISTER EXTRACT.

PARAMS file_name

Indique le nom de chemin complet d'un fichier des paramètres d'extraction dans un emplacement autre que celui par défaut (dirprm) au sein du répertoire Oracle GoldenGate.

REPORT file_name

Indique le nom de chemin complet d'un fichier d'état Extract dans un emplacement autre que l'emplacement dirrpt par défaut du répertoire Oracle GoldenGate.

DESC ‘description’

Indique la description du groupe. Exemple : 'Extracts account_tab on Serv1'. Placez la description entre apostrophes.

ENCRYPTIONPROFILE

Indique le nom du profil de cryptage Oracle GoldenGate associé au client spécifique.

GTIDSET gtidset

Valide pour MySQL.

Indique le positionnement initial de l'extraction en utilisant le type de position en tant qu'ensemble de GTID pour la capture basée sur le GTID (MySQL). Les sources MySQL prises en charge pour l'ensemble de GTID sont MySQL Server 8.0 et les versions supérieures. La taille d'ensemble de GTID maximale prise en charge est de 64 ko.

Syntaxe :

ADD EXTRACT extract_name, TRANLOG, GTIDSET gtidset

CRITICAL

Indique si le processus est essentiel pour le déploiement.

PROFILE

Nom du profil de démarrage automatique.

AUTOSTART

Indique si le processus géré doit être démarré automatiquement lors du démarrage du service d'administration. La valeur par défaut est YES.

DELAY

Temps d'attente (en secondes) avant de démarrer le processus.

AUTORESTART

Détermine le mode de redémarrage du processus en cas d'interruption.

RETRIES

Nombre maximal de tentatives de redémarrage de la tâche avant d'annuler les nouvelles tentatives. Cette option est facultative.

WAITSECONDS

Durée (en secondes) au cours de laquelle le nombre de tentatives est compté.

RESETSECONDS

Réinitialise la durée au cours de laquelle le nombre de tentatives est compté.

DISABLEONFAILURE

Si la valeur TRUE est définie, la tâche est désactivée lorsque le nombre de tentatives est épuisé.

SOCKSPROXY {host_name IP_address}[:port] [PROXYCSALIAS credential_store_alias [PROXYCSDOMAIN credential_store_domain]

Utilisez cette commande pour une extraction d'alias. Indique l'adresse IP ou le nom d'hôte DNS du serveur proxy. Vous pouvez employer l'un ou l'autre pour définir l'hôte. Toutefois, vous devez utiliser l'adresse IP si le serveur DNS est inaccessible. Si vous utilisez une adresse IP, servez-vous d'une adresse mise en correspondance IPv6 ou IPv4, selon la pile du système de destination. Vous devez indiquer l'alias de banque de PROXYCSALIAS. De plus, vous pouvez indiquer le port à utiliser et le domaine de la banque d'informations d'identification.

Exemples

L'exemple suivant crée un groupe d'extraction nommé exte qui capture les modifications de base de donnée des journaux des transactions. L'extraction démarre par les enregistrements générés au moment de la création et de la mise en route du groupe d'extraction avec ADD EXTRACT.

ADD EXTRACT extn, TRANLOG, BEGIN NOW

Dans l'exemple suivant, le nom d'un groupe d'extraction (extw) est créé en vue de l'extraction des modifications de base de donnée dans les journaux des transactions, par le positionnement de l'extraction à un horodatage spécifique :

ADD EXTRACT extn, TRANLOG, BEGIN NOW

REGISTER EXTRACT extn DATABASE

ALTER EXTRACT extn BEGIN 2020-08-02T06:05:30.000Z

L'exemple suivant crée un groupe d'extraction intégrée.

ADD EXTRACT extn, INTEGRATED TRANLOG, BEGIN NOW

L'exemple suivant crée une extraction de chargement initial nommée extei.

ADD EXTRACT extn, SOURCEISTABLE

Les exemples suivants incluent toutes les combinaisons de formats d'ensemble de GTID valides.

Exemple 1 :

ADD EXTRACT exte, TRANLOG, GTIDSET "E11FA47-71CA-11E1-9E33-C80AA9429562:4"

Exemple 2 :

ADD EXTRACT exts, TRANLOG, GTIDSET "3E11FA47-71CA-11E1-9E33-C80AA9429562:1-10"

Exemple 3 :

ADD EXTRACT extn, TRANLOG, GTIDSET "3E11FA47-71CA-11E1-9E33-C80AA9429562:1-3:11:47-49"

Exemple 4 :

ADD EXTRACT extw, TRANLOG, GTIDSET "2174B383-5441-11E8-B90A-C80AA9429562:1-3,24DA167-0C0C-11E8-8442-00059A3C7B00:1-19"

Remarque : comme indiqué dans l'exemple 4, lorsque le jeu GTID contient plusieurs uuids, pour former une demande d'API REST, ce jeu GTID est divisé en plusieurs jeux GTID à l'aide d'un séparateur de virgules.

Les exemples suivants créent et positionnent l'extraction au niveau d'un numéro de modification système (SCN) Oracle spécifique du fichier de journalisation.

ADD EXTRACT extn TRANLOG SCN 123456

ADD EXTRACT extn INTEGRATED TRANLOG SCN 123456

L'exemple suivant crée une extraction sur un système DB2 LUW.

ADD EXTRACT extn, TRANLOG LRI 8066.322711

L'exemple suivant crée une extraction dotée de l'option autostart à l'aide du client d'administration.

ADD EXTRACT extn, TRANLOG , BEGIN NOW , AUTOSTART yes