Paramètres et conditions du journal des transactions

Oracle GoldenGate s'appuie sur les fichiers de journalisation pour capturer les données nécessaires à la réplication des transactions source. Les fichiers de journalisation Oracle sur le système source doivent être configurés correctement avant de démarrer le traitement Oracle GoldenGate.

Cette section aborde les niveaux de journalisation suivants qui s'appliquent à Oracle GoldenGate. Le niveau de journalisation que vous utilisez dépend des fonctionnalités Oracle GoldenGate que vous utilisez.

Remarque : le volume de journalisation est augmenté à la suite de la journalisation requise. Vous pouvez attendre que vous soyez prêt à démarrer le traitement Oracle GoldenGate pour activer la journalisation.

Ce tableau présente les cas d'utilisation d'Oracle GoldenGate pour les différentes propriétés de journalisation.

option de journalisation	Nom de commande	Résultat	Cas d'emploi
Mode de journalisation imposé	`ALTER DATABASE FORCE LOGGING`;	Force la journalisation de toutes les transactions et chargements.	Fortement recommandé pour tous les cas d'utilisation d'Oracle GoldenGate. `FORCE LOGGING` remplace tous les paramètres `NOLOGGING` de niveau table.
Journalisation supplémentaire minimale au niveau de la base de données Reportez-vous à Activation de la journalisation de réplication de base de données de sous-ensemble.	`ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;`	Permet une journalisation supplémentaire minimale pour ajouter des informations de chaînage de lignes au fichier de journalisation.	Requis pour tous les cas d'utilisation d'Oracle GoldenGate
Journalisation supplémentaire de niveau schéma	`[ADD SCHEMATRANDATA](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-5DA7C3DC-5D87-4A8B-AD23-6EF587A5CF41)`	Active la journalisation supplémentaire inconditionnelle de la clé primaire et la journalisation supplémentaire conditionnelle de la ou des clés uniques et étrangères de toutes les tables d'un schéma. Toutes ces clés ensemble sont appelées colonnes de planification. Ce paramètre garantit également que tout objet créé dans ce schéma aura la journalisation supplémentaire appropriée.	Active la journalisation pour toutes les tables actuelles et futures du schéma. Si les colonnes de clé primaire, de clé unique et de clé étrangère ne sont pas identiques au niveau de la source et de la cible, utilisez `ALLCOLS`.
Journalisation supplémentaire de niveau schéma avec journalisation inconditionnelle pour toutes les colonnes prises en charge. (Reportez-vous à Activation de la journalisation supplémentaire de niveau schéma pour les types de colonne non pris en charge.)	`ADD SCHEMATRANDATA` avec l'option `ALLCOLS`	Active la journalisation supplémentaire inconditionnelle de toutes les colonnes d'une table, pour toutes les tables d'un schéma. Ce paramètre garantit également que tout objet créé dans ce schéma aura la journalisation supplémentaire appropriée.	Utilisé pour les configurations bidirectionnelles et actives-actives où toutes les valeurs de colonne sont vérifiées, pas seulement les colonnes modifiées, lors de la tentative de mise à jour ou de suppression. Cela nécessite plus de ressources, mais permet le plus haut niveau de validation des données en temps réel et donc de détection des conflits. Cette méthode doit également être utilisée si elle va utiliser le paramètre `HANDLECOLLISIONS` pour les chargements initiaux.
Journalisation supplémentaire au niveau du schéma, paramètre minimal	`ADD SCHEMATRANDATA` avec l'option `NOSCHEDULINGCOLS`	Active la journalisation supplémentaire inconditionnelle de la clé primaire et de tous les index uniques valides de toutes les tables d'un schéma. Ce paramètre garantit également que tout objet créé dans ce schéma aura la journalisation supplémentaire appropriée.	A utiliser uniquement pour le processus Replicat non intégré. Il s'agit de la journalisation minimum requise au niveau du schéma.
Journalisation supplémentaire au niveau de la table avec prise en charge intégrée du processus Replicat Reportez-vous à Activation de la journalisation supplémentaire de niveau table.	`ADD TRANDATA`	Active la journalisation supplémentaire inconditionnelle de la clé primaire et la journalisation supplémentaire conditionnelle de la ou des clés uniques et étrangères d'une table. Toutes ces clés ensemble sont appelées colonnes de planification.	Requis pour tous les cas d'utilisation d'Oracle GoldenGate, sauf si la journalisation supplémentaire au niveau du schéma est utilisée. Si les colonnes de clé primaire, de clé unique et de clé étrangère ne sont pas identiques au niveau de la source et de la cible, utilisez `ALLCOLS`.
Journalisation supplémentaire de niveau table avec journalisation inconditionnelle pour toutes les colonnes prises en charge. (Reportez-vous à Activation de la journalisation supplémentaire de niveau table pour les types de colonne non pris en charge.)	`ADD TRANDATA` avec l'option `ALLCOLS`	Active la journalisation supplémentaire inconditionnelle de toutes les colonnes de la table.	Utilisé pour les configurations bidirectionnelles et actives-actives où toutes les valeurs de colonne sont vérifiées, pas seulement les colonnes modifiées, lors de la tentative de mise à jour ou de suppression. Cela nécessite plus de ressources, mais permet le plus haut niveau de validation des données en temps réel et donc de détection des conflits. Elle peut également être utilisée lorsque les clés primaires, uniques et étrangères source et cible ne sont pas identiques ou sont en constante évolution entre la source et la cible.
Journalisation supplémentaire au niveau de la table, paramètre minimal	`ADD TRANDATA` avec l'option `NOSCHEDULINGCOLS`	Active la journalisation supplémentaire inconditionnelle de la clé primaire et de tous les index uniques valides d'une table.	Utilisé pour le processus Replicat non intégré et le processus Replicat non parallèle. Il s'agit de la journalisation minimale requise au niveau de la table.
Journalisation supplémentaire de niveau table pour les vues de dualité relationnelle JSON et les tables de collecte JSON.	`ADD TRANDATA` avec `Duality View name` et `Collection Table name`	Active la journalisation supplémentaire pour les vues de dualité et les tables de collecte spécifiées.	Pour obtenir des instructions, reportez-vous à Activation de la journalisation supplémentaire pour les vues de dualité relationnelle JSON et les tables de collecte JSON. Pour en savoir plus, reportez-vous à Détails de la prise en charge des vues de dualité relationnelle JSON et des tables de collecte JSON.

Activer la journalisation de réplication de base de données de sous-ensemble

Oracle recommande vivement de placer la base de données source Oracle en mode de journalisation forcée. Le mode de journalisation forcée force la journalisation de l'ensemble des transactions et des chargements, remplaçant tout paramètre utilisateur ou de stockage contraire. Ainsi, aucune donnée source dans la configuration Extract n'est manquée.

Il existe un mode de journalisation supplémentaire de base de données granulaire détaillé appelé Réplication de base de données sous-ensemble disponible dans LogMiner, qui est le mode recommandé de base pour tous les clients Oracle GoldenGate et XStream. Il remplace le mode de journalisation supplémentaire minimum précédemment utilisé.

La journalisation de réplication de base de données de sous-ensemble est actuellement activée dans CDB$ROOT (et toutes les bases de données pluggables utilisateur en héritent).

Remarque : la journalisation des clés primaires (PK) et des index uniques (UI) au niveau de la base de données n'est déconseillée que si vous répliquez un sous-ensemble de tables. Vous pouvez l'utiliser avec Live Standby ou si Oracle GoldenGate va répliquer toutes les tables, par exemple pour réduire le temps d'inactivité d'une migration ou d'une mise à niveau.

Effectuez les étapes suivantes pour vérifier et activer, si nécessaire, la journalisation de réplication de base de données de sous-ensemble et la journalisation forcée.

Connectez-vous à SQL*Plus en tant qu'utilisateur disposant du privilège ALTER SYSTEM.
Exécutez la commande suivante pour déterminer si la base de données est en mode de journalisation supplémentaire et en mode de journalisation forcée. Si le résultat est YES pour les deux requêtes, la base de données répond aux exigences d'Oracle GoldenGate.
```
SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;
```

Si le résultat est NO pour l'une des propriétés ou les deux, procédez comme suit pour les activer si nécessaire :

ALTER PLUGGABLE DATABASE *pdbname* ADD SUPPLEMENTAL LOG DATA SUBSET DATABASE REPLICATION;
ALTER DATABASE FORCE LOGGING;

Exécutez la commande suivante pour vérifier que ces propriétés sont désormais activées.
```
SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;
```
La sortie de la requête doit être YES pour les deux propriétés.
Changez les fichiers journaux.
```
ALTER SYSTEM SWITCH LOGFILE;
```

Activer la journalisation supplémentaire de niveau Schéma

Oracle GoldenGate prend en charge la journalisation supplémentaire au niveau du schéma. La journalisation au niveau schéma est requise pour les bases de données source et cible Oracle lors de l'utilisation de la fonctionnalité de réplication LDD d'Oracle GoldenGate, ou sur la base de données source si le langage LDD peut être exécuté (ou exécuté) sur les tables répliquées. Dans tous les autres cas d'utilisation, il est facultatif, mais vous devez utiliser la journalisation au niveau de la table à la place (reportez-vous à Activation de la journalisation supplémentaire au niveau de la table).

Par défaut, la journalisation de niveau schéma active automatiquement la journalisation supplémentaire inconditionnelle de la clé primaire et la journalisation supplémentaire conditionnelle de la ou des clés uniques et de la ou des clés étrangères de toutes les tables d'un schéma. Les options vous permettent de modifier la journalisation selon vos besoins.

Remarque : Oracle recommande vivement d'utiliser la journalisation au niveau schéma plutôt que la journalisation au niveau table, car elle garantit que toutes les nouvelles tables ajoutées à un schéma sont capturées si elles satisfont aux spécifications de caractères génériques. Cette méthode est également recommandée car les modifications apportées aux colonnes de clé sont automatiquement répercutées dans les données de journal supplémentaires. Par exemple, si une clé change, il n'est pas nécessaire d'émettre ADD TRANDATA.

Effectuez les étapes suivantes sur le système source pour activer la journalisation supplémentaire au niveau schéma.

Démarrez la ligne de commande sur le système source.
Exécutez la commande DBLOGIN avec l'alias d'un utilisateur de la banque d'informations d'identification qui dispose des privilèges nécessaires pour activer la journalisation supplémentaire au niveau du schéma.
```
DBLOGIN USERIDALIAS *alias*
```
Pour plus d'informations sur USERIDALIAS et sur les options supplémentaires, reportez-vous à USERIDALIAS dans Référence des paramètres et des fonctions pour Oracle GoldenGate.
Lorsque vous utilisez ADD SCHEMATRANDATA ou ADD TRANDATA sur une base de données colocative, vous pouvez vous connecter directement à la base de données pluggable et exécuter la commande. Si vous êtes connecté au niveau racine (à l'aide d'un utilisateur C##), vous devez également inclure la base de données pluggable. Exécutez la commande ADD SCHEMATRANDATA pour chaque schéma pour lequel vous voulez capturer les modifications de données avec Oracle GoldenGate.
```
ADD SCHEMATRANDATA pdb.schema [ALLCOLS | NOSCHEDULINGCOLS]
```
Où :
- Sans options, le schéma ADD SCHEMATRANDATA active la journalisation supplémentaire inconditionnelle sur le système source de la clé primaire et la journalisation supplémentaire conditionnelle de toutes les clés uniques et de toutes les clés étrangères de toutes les tables actuelles et futures du schéma donné. La journalisation non conditionnelle force les valeurs de clé primaire vers le journal, que la clé ait été modifiée ou non lors de l'opération en cours. La journalisation conditionnelle journalise toutes les valeurs de colonne d'une clé étrangère ou unique si au moins l'une d'elles a été modifiée lors de l'opération en cours. La valeur par défaut est facultative pour la prise en charge de la réplication non intégrée, mais elle est requise pour la prise en charge de la réplication intégrée car la clé primaire, les clés uniques et les clés étrangères doivent toutes être disponibles pour le serveur entrant afin de calculer les dépendances.
- ALLCOLS peut être utilisé pour activer la journalisation supplémentaire inconditionnelle de toutes les colonnes d'une table et s'applique à toutes les tables actuelles et futures du schéma donné. Permet de prendre en charge le processus Replicat intégré lorsque les tables source et cible ont des colonnes de planification différentes. (Les colonnes de planification sont la clé primaire, la clé unique et la clé étrangère.)
- NOSCHEDULINGCOLS consigne uniquement les valeurs de la clé primaire et tous les index uniques valides pour les tables existantes du schéma et les nouvelles tables ajoutées ultérieurement. Il s'agit du niveau minimal requis de journalisation au niveau schéma. Il n'est valide que pour le processus Replicat en mode non intégré.
Dans l'exemple suivant, la commande active la journalisation supplémentaire par défaut pour le schéma hr.
```
ADD SCHEMATRANDATA pdbeast.hr ALLCOLS
```
Dans l'exemple suivant, la commande active la journalisation supplémentaire uniquement pour la clé primaire et les index uniques valides pour le schéma HR.
```
ADD SCHEMATRANDATA pdbeast.hr NOSCHEDULINGCOLS
```

Activer la journalisation supplémentaire de niveau tableau

Activez la journalisation supplémentaire au niveau de la table sur le système source dans les cas suivants :

Pour activer le niveau de journalisation requis lorsque vous n'utilisez pas la journalisation de niveau schéma (reportez-vous à Activation de la journalisation supplémentaire de niveau schéma). La journalisation au niveau du schéma ou de la table doit être utilisée. Par défaut, la journalisation au niveau table active automatiquement la journalisation supplémentaire inconditionnelle de la clé primaire et la journalisation supplémentaire conditionnelle de la ou des clés uniques et de la ou des clés étrangères d'une table. Les options vous permettent de modifier la journalisation selon vos besoins.
Pour empêcher la journalisation de la clé primaire pour une table donnée.
Consigner des valeurs de colonne non clé au niveau de la table pour prendre en charge des fonctionnalités Oracle GoldenGate spécifiques, telles que la logique de filtrage et de détection et de résolution des conflits.
Si les colonnes de clé changent sur une table qui ne dispose que d'une journalisation supplémentaire de niveau table, vous devez exécuter ADD TRANDATA sur la table avant d'autoriser toute activité LMD sur la table.
Afin d'activer la journalisation supplémentaire pour les vues de dualité relationnelle JSON (DV JSON) et les tables de collecte JSON, vous devez suivre les instructions fournies dans Activer la journalisation supplémentaire pour les vues de dualité relationnelle JSON et les tables de collecte JSON.

Effectuez les étapes suivantes sur le système source pour activer la journalisation supplémentaire au niveau de la table ou utilisez les fonctionnalités facultatives de la commande.

Exécutez la ligne de commande sur le système source.
Exécutez la commande DBLOGIN à l'aide de l'alias d'un utilisateur de la banque d'informations d'identification qui dispose des privilèges nécessaires pour activer la journalisation supplémentaire au niveau de la table.
```
DBLOGIN USERIDALIAS *alias*
```
Pour plus d'informations sur DBLOGIN et les options supplémentaires, reportez-vous à USERIDALIAS dans Référence des paramètres et des fonctions pour Oracle GoldenGate.
Exécutez la commande ADD TRANDATA.
```
ADD TRANDATA [*PDB*.]*schema.**table* [, COLS (*columns)*] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]
```
Où :
- PDB est le nom du conteneur racine ou de la base de données pluggable si la table se trouve dans une base de données Conteneur colocative.
- schema est le schéma source qui contient la table.
- table est le nom du tableau. Pour obtenir des instructions sur la spécification de noms d'objet, reportez-vous à Spécification de noms d'objet dans l'entrée Oracle GoldenGate.
- ADD TRANDATA sans les autres options active automatiquement la journalisation supplémentaire inconditionnelle de la clé primaire et la journalisation supplémentaire conditionnelle de la ou des clés uniques et étrangères de la table. La journalisation non conditionnelle force les valeurs de clé primaire vers le journal, que la clé ait été modifiée ou non lors de l'opération en cours. La journalisation conditionnelle journalise toutes les valeurs de colonne d'une clé étrangère ou unique si au moins l'une d'elles a été modifiée lors de l'opération en cours. La valeur par défaut est facultative pour la prise en charge de la réplication non intégrée (voir également NOSCHEDULINGCOLS), mais elle est requise pour la prise en charge de la réplication intégrée car la clé primaire, les clés uniques et les clés étrangères doivent toutes être disponibles pour le serveur entrant afin de calculer les dépendances.
- ALLCOLS active la journalisation supplémentaire inconditionnelle de toutes les colonnes de la table. Permet de prendre en charge le processus Replicat intégré lorsque les tables source et cible ont des colonnes de planification différentes. (Les colonnes de planification sont la clé primaire, la clé unique et la clé étrangère.)
- NOSCHEDULINGCOLS est valide pour le processus Replicat en mode non intégré uniquement. Elle émet une commande ALTER TABLE avec une clause ADD SUPPLEMENTAL LOG DATA ALWAYS appropriée pour le type de contrainte unique défini pour la table ou pour toutes les colonnes en l'absence de contrainte unique. Cette commande répond aux exigences de base d'Oracle GoldenGate en matière de journalisation au niveau de la table lorsque la journalisation au niveau du schéma n'est pas utilisée. Pour savoir comment Oracle GoldenGate sélectionne une clé ou un index, reportez-vous à Assurer l'unicité des lignes dans la table source et cible.
- COLS columns consigne les colonnes non-clé requises pour une clause KEYCOLS ou pour le filtrage et la manipulation. Les parenthèses sont requises. Ces colonnes seront journalisées en plus de la clé primaire, sauf si l'option NOKEY est également présente.
- NOKEY empêche la journalisation de la clé primaire ou de la clé unique. Nécessite une clause KEYCOLS dans les paramètres TABLE et MAP et une clause COLS dans la commande ADD TRANDATA pour journaliser les autres colonnes KEYCOLS.
Si vous utilisez ADD TRANDATA avec l'option COLS, créez un index unique pour les colonnes sur la cible afin d'optimiser l'extraction de ligne. Si vous consignez ces colonnes en tant que clé de substitution pour une clause KEYCOLS, notez que vous ajoutez la clause KEYCOLS aux instructions TABLE et MAP lorsque vous configurez les processus Oracle GoldenGate.

Activer la journalisation supplémentaire pour les vues de dualité relationnelle JSON et les tables de collecte JSON

Avant de répliquer des vues de dualité relationnelle JSON et des tables de collecte JSON, vous devez configurer la journalisation supplémentaire dans Oracle GoldenGate. Par défaut, la journalisation supplémentaire n'est pas activée pour les vues de dualité relationnelle JSON et les tables de collecte JSON. Vous pouvez utiliser les instructions suivantes lors de l'activation de la journalisation supplémentaire pour les vues de dualité et les tables de collecte :

Activer la réplication logique : l'activation de la réplication logique (à l'aide de ADD TRANDATA) est obligatoire pour capturer les modifications apportées aux vues de dualité et aux tables de collecte. Ce processus active la journalisation supplémentaire nécessaire pour suivre les modifications au niveau du document JSON.

Pour plus d'informations, reportez-vous à ADD TRANDATA.

Côté Oracle AI Database, une clause a été ajoutée dans le fichier CREATE/ALTER DDL pour les vues de dualité relationnelle JSON et les tables de collecte JSON. Cette clause active la journalisation supplémentaire au niveau de la vue. Cette journalisation s'ajoute à toute journalisation existante dans les tables de base.

Pour plus de détails, reportez-vous à la section logical_replication_clause dans les commandes CREATE TABLE/CREATE JSON RELATIONAL DUALITY VIEW et ALTER TABLE/ALTER JSON RELATIONAL DUALITY VIEWS dans Référence de langage SQL Oracle AI Database.
Modifications LMD pour les vues de dualité JSON et les tables de collecte JSON : pour les opérations INSERT et UPDATE, le document JSON complet et l'attribut de clé _id sont journalisés de manière supplémentaire. Pour les opérations DELETE, seul l'attribut de clé _id est journalisé.
Journalisation de validation de transaction pour les vues de dualité relationnelle JSON : la journalisation supplémentaire pour les vues de dualité a lieu au moment de la validation. Seules les modifications réseau sont consignées.

Par exemple, si vous INSERT un enregistrement et UPDATE cet enregistrement deux fois dans une transaction contenant une vue de dualité JSON, il n'y aura qu'une seule modification logique contenant une valeur INSERT avec l'enregistrement mis à jour.
Réplication de vues de dualité JSON vers des vues de dualité JSON à l'aide de tables sous-jacentes : les modifications de réplication au niveau de la table relationnelle sous-jacente des vues de dualité sont généralement efficaces. Une vue de dualité située au-dessus de la table relationnelle sous-jacente reflète automatiquement ces modifications en tant que vue. Dans ce cas, aucune journalisation supplémentaire supplémentaire sur les vues de dualité n'est nécessaire.

Pour connaître les étapes de configuration de la journalisation supplémentaire au niveau table, reportez-vous à Activation de la journalisation supplémentaire au niveau table.

Enlever la journalisation supplémentaire de niveau table

Si une table n'est plus nécessaire pour être capturée par Oracle GoldenGate et que le paramètre TABLE de la table a été enlevé du fichier de paramètres d'extraction, ou si TABLEEXCLUDE est utilisé pour exclure la table d'une instruction générique, la journalisation supplémentaire peut être enlevée de la table.

Remarque : si l'extraction résout une table pour laquelle la journalisation supplémentaire n'est pas activée, elle est abandonnée en fonction du type d'opération LMD.

L'utilisation de DELETE TRANDATA pour enlever la journalisation supplémentaire définit le niveau d'identité de réplication de la table sur NOTHING. La journalisation supplémentaire peut être désactivée à l'aide de l'interface Web Microservices Architecture à partir de la page Administration Service, Configuration, sous les informations d'identification créées pour une base de données source, ou peut être émise avec la commande DELETE TRANDATA.

La syntaxe suivante permet d'émettre DELETE TRANDATA.

DBLOGIN USERIDALIAS alias_name
DELETE TRANDATA schema.tablename

Pour vérifier le niveau de journalisation supplémentaire :

INFO TRANDATA schema.tablename