Détails de la prise en charge des objets et des opérations dans Oracle DML

Voici la liste des objets et des opérations Oracle qu'Oracle GoldenGate prend en charge pour la capture et la réplication des opérations LMD.

Base de donnée Conteneur colocative

Oracle GoldenGate capture et distribue à partir d'une base de données Conteneur colocative. Reportez-vous à Configuration d'une base de données Conteneur colocative.

Oracle GoldenGate ne prend pas en charge la réplication de bout en bout du conteneur d'applications racine-enfant

Tables, vues et vues matérialisées

Les opérations LMD suivantes sont prises en charge pour les tables standard, les tables organisées en index, les tables clusterisées et les vues matérialisées :

• INSERT

• UPDATE

• DELETE

• Opérations de contrôle des transactions associées

A partir d'Oracle GoldenGate 23ai, les fonctionnalités suivantes sont disponibles pour les tables :

• Colonne 4K dans les tables dont la taille de ligne est inférieure à 4 Mo

• Blockchain et tables non mutables

  Pour plus d'informations, reportez-vous à Limites de prise en charge de la chaîne de blocs et des tables immuables.

Conseil :

Vous pouvez utiliser la vue DBA_GOLDENGATE_SUPPORT_MODE du dictionnaire de données pour afficher des informations sur le niveau de prise en charge des processus de capture Oracle GoldenGate pour les tables de la base de données. La valeur PLSQL de DBA_GOLDENGATE_SUPPORT_MODE indique que la table est prise en charge nativement, mais nécessite une journalisation supplémentaire procédurale. Pour plus d'informations, reportez-vous au site DBA_GOLDENGATE_SUPPORT_MODE. Si vous devez afficher toutes les tables qui n'ont pas d'index unique principal et aucun index unique non NULL, vous pouvez utiliser DBA_GOLDENGATE_NOT_UNIQUE. Pour plus d'informations, reportez-vous à DBA_GOLDENGATE_NOT_UNIQUE.

Limites de la prise en charge des tables standard

Ces limitations s'appliquent à l'extraction.

• Oracle GoldenGate prend en charge les tables qui contiennent un nombre illimité de lignes.

• La longueur d'une ligne peut atteindre 4 Mo. Si Oracle GoldenGate est configuré pour inclure à la fois l'image avant et après d'une colonne dans sa portée de traitement, la longueur maximale de 4 Mo s'applique à la longueur totale de l'image avant complète plus la longueur de l'image après. Par exemple, si des opérations UPDATE sont effectuées sur des colonnes qui sont utilisées comme identificateur de ligne, les images avant et après sont traitées et ne peuvent pas dépasser 4 Mo au total. Les images Avant et Après sont également requises pour les colonnes qui ne sont pas des identificateurs de ligne mais qui sont utilisées comme colonnes de comparaison dans la détection et la résolution des conflits (CDR). Les colonnes de type caractère qui autorisent plus de 4 ko de données (par exemple, CLOB) ne contiennent que les 4 premiers ko de données stockées dans la ligne et contribuent à la longueur de ligne maximale de 4 Mo. Colonnes binaires qui permettent plus de 4 ko de données, telles que BLOB, les 8 premiers ko de données sont stockés dans la ligne et contribuent à la longueur de ligne maximale de 4 Mo.

• Oracle GoldenGate prend en charge le nombre maximal de colonnes par table prises en charge par la base de données.

• Oracle GoldenGate prend en charge la taille de colonne maximale prise en charge par la base de données.

• Oracle GoldenGate prend en charge les tables qui ne contiennent qu'une seule colonne, sauf lorsque la colonne contient l'un des types de données suivants :

  • LOB

  • LONG

  • LONG VARCHAR

  • Nested table

  • Type défini/util. (UDT)

  • VARRAY

  • XMLType

• Définissez DBOPTIONS ALLOWUNUSEDCOLUMN avant de procéder à la réplication à partir et vers des tables contenant des colonnes non utilisées.

• Oracle GoldenGate prend en charge les tables avec les attributs de partitionnement suivants :

  • Partitionnement de plage

  • Partitionnement par hachage - Partitionnement par intervalle

  • Partitionnement composite

  • Partitionnement basé sur une colonne virtuelle

  • Partitionnement par référence

  • Partitionnement par liste

• Oracle GoldenGate prend en charge les tables avec des colonnes virtuelles, mais ne capture pas de données de modification pour ces colonnes ni ne leur applique de données de modification : la base de données n'écrit pas de colonnes virtuelles dans le journal des transactions et Oracle AI Database n'autorise pas les opérations LMD sur les colonnes virtuelles. Pour la même raison, les données de chargement initial ne peuvent pas être appliquées à une colonne virtuelle. Vous pouvez mettre en correspondance les données des colonnes virtuelles avec les colonnes cible non virtuelles.

• Oracle GoldenGate ne prendra pas en compte l'unicité/l'index avec des colonnes virtuelles.

• Oracle GoldenGate prend en charge la réplication vers et depuis Oracle Exadata. Pour prendre en charge la compression en colonnes hybride Exadata, la compatibilité de la base de données source doit être définie sur 11.2.0.0.0 ou une version ultérieure.

• Oracle GoldenGate prend en charge le cryptage transparent des données (TDE).

• Oracle GoldenGate prend en charge les instructions TRUNCATE dans le cadre de la prise en charge de la réplication LDD ou en tant que fonctionnalité autonome indépendante de la prise en charge LDD.

• Oracle GoldenGate prend en charge la capture de la charge directe INSERT, à l'exception de l'insertion de chemin direct SQL*Loader pour les données binaires XML et les données relationnelles d'objet XML. La journalisation supplémentaire doit être activée et la base de données doit être en mode fichier de journalisation archivé. Les méthodes de chargement direct suivantes sont prises en charge.

  • Conseil /*+ APPEND */

  • Conseil /*+ PARALLEL */

  • SQLLDR avec DIRECT=TRUE

• Oracle GoldenGate prend entièrement en charge la capture à partir d'objets compressés pour l'extraction.

• Oracle GoldenGate prend en charge les transactions distribuées XA et PDML.

• Oracle GoldenGate prend en charge les opérations LMD sur les tables avec l'option FLASHBACK ARCHIVE activée. Toutefois, Oracle GoldenGate ne prend pas en charge les instructions LDD qui créent des tables avec la clause FLASHBACK ARCHIVE ou les instructions LDD qui créent, modifient ou suppriment l'archive Flashback Data Archive elle-même.

Limites de prise en charge des vues

Ces limitations s'appliquent à l'extraction.

• Oracle GoldenGate prend en charge la capture à partir d'une vue lorsque le processus Extract est en mode de chargement initial (capturation directe à partir de la vue source, et non à partir du fichier de journalisation).

• Oracle GoldenGate ne capture pas les données de modification à partir d'une vue, mais il prend en charge la capture à partir des tables sous-jacentes d'une vue.

Limites de la prise en charge des vues matérialisées

Les vues matérialisées sont prises en charge par le processus Extract avec les limitations suivantes.

• Les vues matérialisées créées WITH ROWID ne sont pas prises en charge.

• Le journal de vues matérialisées peut être créé WITH ROWID.

• La table source doit avoir une clé primaire.

• Les tronçons de vues matérialisées ne sont pas pris en charge. Vous pouvez utiliser une instruction DELETE FROM.

• Les instructions LMD (mais pas LDD) issues d'une actualisation complète d'une vue matérialisée sont prises en charge. Si la prise en charge des instructions LDD est requise pour cette fonctionnalité, ouvrez un dossier de support Oracle GoldenGate.

• Pour la réplication, la commande Create MV doit inclure la clause FOR UPDATE.

• Les vues matérialisées peuvent être répliquées ou les tables de base sous-jacentes, mais pas les deux.

Limites de la prise en charge de la blockchain et des tables immuables

A partir d'Oracle AI Database 26ai, les tables immuables et blockchain sont prises en charge. Voici les opérations prises en charge pour la fonctionnalité :

Prise en charge de la réplication unidirectionnelle

• Les versions de table de chaîne de blocs v1 (introduites dans Oracle Database 19.10) et v2 (introduites dans Oracle AI Database 26ai), ainsi que les versions de table non mutables v1 (introduites dans Oracle Database 19.11) et v2 (introduites dans Oracle AI Database 26ai) sont prises en charge pour toutes les répliques, à l'exception de la réplication coordonnée.

• Interopérabilité entre types et versions :

  • Prise en charge de la réplication de la blockchain et des tables immuables de n'importe quelle version à la source vers les tables conventionnelles à la cible.

  • Aucune prise en charge de la réplication des tables conventionnelles à la source vers une blockchain et des tables immuables de n'importe quelle version sur la cible.

• La réplication LMD, LDD et procédurale doit être activée. Pour la réplication de procédure, la table Blockchain doit être ajoutée.

• Les opérations de suppression des lignes expirées ne sont pas répliquées. L'expiration est gérée séparément par chaque système de base de données.

Prise en charge de la réplication bidirectionnelle (active-active)

• Prise en charge de la version v2 uniquement.

• Prise en charge de la réplication parallèle en mode intégré et de la réplication intégrée uniquement.

• ACDR doit être configuré. L'ACDR pour la blockchain et les tables immuables contient les méthodes de résolution suivantes :

  • Dernier horodatage

  • Horodatage au plus tôt Remarque : aucune autre méthode de résolution (telle que la résolution de groupe de colonnes ou delta) n'est prise en charge. Il n'y a pas de support pour CDR manuel.

• Une chaîne de blocs ou une table non mutable peut avoir au maximum une clé primaire ou une contrainte unique et ne peut pas avoir d'index uniques.

  • La clé primaire ou la contrainte de clé unique sur la blockchain ou les tables non mutables pour ACDR utilise des index non uniques.

  • ACDR gère uniquement les conflits INSERT-INSERT car la blockchain et les tables non mutables sont des tables INSERT uniquement. L'ACDR ajoute deux colonnes masquées pour l'horodatage (CDRTS$ROW) et la visibilité (ORABCTAB_INVISIBLE$).

  Ces colonnes masquées fonctionnent comme suit :

  L'ACDR résout un conflit et conserve les deux copies de la ligne. Elle marquera une instruction INSERT en conflit qui aurait normalement été supprimée ou écrasée comme logiquement non valide en définissant la colonne masquée ORABCTAB_INVISIBLE$ sur 1. Par conséquent, il peut y avoir plusieurs lignes avec la même valeur de clé, mais au plus 1 ligne pour chaque clé sera valide et aura ORABCTAB_INVISIBLE$ défini sur 0.

Capture automatique DML

Oracle GoldenGate prend en charge les opérations LMD suivantes avec le mode de capture automatique :

• Le paramètre TABLEEXCLUSION est pris en charge.

• Le paramètre TABLE est pris en charge.

• Le processus Extract écrit dans le fichier trace les enregistrements LMD de table fournis par la base de données pour la capture automatique.

Partitionnement du système

Le partitionnement système est une fonctionnalité d'Oracle AI Database qui permet de créer une table avec des partitions nommées. La base de données ne gère pas une table partitionnée par système. Chaque instruction LMD doit indiquer la partition dans laquelle la ligne doit résider. Le processus Extract et tous les modes de réplication prennent en charge le partitionnement du système. Chaque en-tête d'enregistrement de fichier trace appartenant à une table partitionnée par système inclut le nom de la partition. A partir de la version 21c d'Oracle GoldenGate, un enregistrement de nom de partition (PNR) est généré pour les tables partitionnées par système, s'il est inclus dans le paramètre PARTITION.

Reportez-vous à PARTITION \| PARTITIONEXCLUDE dans la référence des paramètres et des fonctions pour Oracle GoldenGate.

Séquences et colonnes d'identité

• Les colonnes d'identité sont prises en charge à partir de la base de données Oracle 18c et nécessitent l'extraction, la réplication parallèle en mode intégré ou la réplication intégrée.

  Remarque : la réplication des séquences générées par le système pour les colonnes d'identité n'est pas prise en charge.

• Oracle GoldenGate prend en charge la réplication des valeurs de séquence et des colonnes d'identité dans une configuration de haute disponibilité unidirectionnelle et active-passive.

• Oracle GoldenGate garantit que les valeurs de séquence cible seront toujours supérieures à celles de la source (ou égales à celles-ci, si le cache est égal à zéro).

Limites de prise en charge des séquences

Ces limitations s'appliquent à l'extraction.

• Oracle GoldenGate ne prend pas en charge la réplication des valeurs de séquence dans une configuration bidirectionnelle active-active.

• La taille du cache et l'intervalle d'incrémentation des séquences source et cible doivent être identiques. Le cache peut avoir n'importe quelle taille, y compris 0 (NOCACHE).

• La séquence peut être définie sur Cycle ou non, mais les bases de données source et cible doivent être définies de la même manière.

• Les tables avec des colonnes de séquence par défaut sont exclues de la réplication pour l'extraction.

Objets et opérations non pris en charge dans Oracle DML

Les opérations ou objets Oracle supplémentaires suivants ne sont pas pris en charge par le processus Extract :

• REF est pris en charge de manière native pour assurer la compatibilité avec Oracle Database 12.2 et versions ultérieures, mais pas avec REFs basé sur la clé primaire (PKREFs)

• Valeurs de séquence dans une configuration bidirectionnelle active-active

• Réexécution de base de données

• Tables créées en tant que EXTERNAL