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

Découvrez les objets et opérations Oracle pris en charge par Oracle GoldenGate pour la capture et la réplication des opérations LDD.

Objets et opérations pris en charge dans Oracle DDL

La prise en charge de la capture LDD est intégrée au serveur de journalisation de la base de données. Vous devez définir la compatibilité des paramètres de base de données sur 11.2.0.4.0 ou une version ultérieure. Le processus Extract prend en charge les instructions LDD qui incluent le cryptage de colonne basé sur un mot de passe, par exemple :

• CREATE TABLE t1 (a number, b varchar2(32) ENCRYPT IDENTIFIED BY my_password);

• ALTER TABLE t1 ADD COLUMN c varchar2(64) ENCRYPT IDENTIFIED BY my_password;

Les instructions supplémentaires suivantes s'appliquent à Extract en ce qui concerne la prise en charge des instructions LDD.

• Toutes les configurations de topologie Oracle GoldenGate sont prises en charge pour la réplication LDD Oracle.

• La réplication active-active (directionnelle) d'Oracle DDL est prise en charge entre deux (et seulement deux) bases de données qui contiennent des métadonnées identiques.

• Oracle GoldenGate prend en charge le langage DDL sur les objets suivants :

  • clusters

  • annuaires

  • fonctions

  • index

  • emballages

  • procédure

  • tables

  • tablespaces

  • rôles

  • séquences

  • synonymes

  • déclencheurs

  • types

  • vues

  • vues matérialisées

  • utilisateurs

  • colonnes invisibles

• La réplication de base de données Oracle Edition-Based Redefinition (EBR) d'Oracle DDL est prise en charge pour l'extraction pour les objets Oracle AI Database suivants :

  • fonctions

  • bibliothèque

  • paquets (spécification et corps)

  • procédure

  • synonymes

  • types (spécification et corps)

  • vues

• A partir de la version 21c d'Oracle GoldenGate, les instructions LDD dont la taille est supérieure à 4 Mo bénéficieront de la prise en charge de la réplication.

• Les domaines SQL sont pris en charge à partir d'Oracle GoldenGate 23ai.

• Oracle GoldenGate est capable de gérer des tables avec 4000 colonnes si la taille de ligne est inférieure à 4 Mo.

• Oracle GoldenGate prend en charge les opérations LDD de tables temporaires globales (GTT) qui doivent être visibles par le processus Extract afin qu'elles puissent être répliquées. Vous devez définir le paramètre DDLOPTIONS pour activer cette opération car elle n'est pas définie par défaut.

• Oracle GoldenGate prend en charge le dictionnaire pour une utilisation avec NOUSERID et TRANLOGOPTIONS GETCTASDML. Cela signifie que le processus Extract reçoit les métadonnées d'objet du dictionnaire LogMiner sans interroger les objets du dictionnaire. Oracle GoldenGate utilise automatiquement le dictionnaire lorsque le paramètre de compatibilité de la base de données source est supérieur ou égal à 11.2.0.4.

  Lorsque vous utilisez le format de dictionnaire et de trace dans la version 12.2.x d'Oracle GoldenGate, le processus Extract requiert que le patch Logminer soit appliqué à la base de données d'exploration si la version d'Oracle Database est antérieure à 12.1.0.2.

• Oracle GoldenGate prend en charge la réplication des colonnes invisibles dans le processus Extract. La version 12.2 du format de trace est requise. Le processus de réplication doit indiquer le paramètre MAPINVISIBLECOLUMNS ou mettre explicitement en correspondance avec des colonnes invisibles dans la clause COLMAP du paramètre MAP.

  Si SOURCEDEFS ou TARGETDEFS est utilisé, le format de métadonnées d'un fichier de définition pour les tables Oracle doit être compatible avec le format de trace. Le format de métadonnées 12.2 est compatible avec le format de trace 12.2 et le format de métadonnées antérieur à 12.2 est compatible avec le format de trace antérieur à 12.2. Pour indiquer le format de métadonnées d'un fichier de définition, utilisez l'option FORMAT RELEASE du paramètre DEFSFILE lorsque le fichier de définition est généré dans DEFGEN.

• Les instructions LDD pour créer un contexte d'espace de noms (CREATE CONTEXT) sont capturées par le processus Extract et appliquées par le processus Replicat.

• L'extraction en mode pompe prend en charge les options LDD suivantes :

  • DDL INCLUDE ALL

  • DDL EXCLUDE ALL

  • DDL EXCLUDE OBJNAME

  L'option SOURCECATALOG et l'option ALLCATALOG de DDL EXCLUDE sont également prises en charge.

  Si aucun paramètre LDD n'est indiqué, toutes les instructions LDD sont écrites dans la trace. Si DDL EXCLUDE OBJNAME est indiqué et que le propriétaire de l'objet ne correspond à aucune règle d'exclusion, il est écrit dans la trace.

• A partir de la base de données Oracle 21c, le script LDD suivant est disponible pour prendre en charge le blocage des modifications LMD/LDD qui ne sont pas répliquées par Oracle GoldenGate :

  ALTER DATABASE [ENABLE | DISABLE] goldengate blocking mode;

  Lorsque le mode de blocage d'Oracle GoldenGate est activé, les instructions LMD qui utilisent support_mode NONE dans des tables et exécutent des instructions PL/SQL Oracle non prises en charge échouent avec l'erreur suivante :

  ORA-26981: "operation was unsupported during Oracle GoldenGate blocking mode"

  Pour la base de données Oracle 21c, les fonctionnalités suivantes entraînent l'existence de support_mode NONE dans une table dans Oracle GoldenGate :

  • BFILE en tant qu'attribut de colonne ADT ou de table saisie

  • Table sans scalaire

  • Table OLAP AW$

  • Table de files d'attente distribuées

  • Table des clusters de hachages triés

  • Contrainte de clé primaire sur l'attribut ADT dans la table relationnelle

  • Contrainte de clé primaire/clé unique sur la longueur raw/varchar (plus de 4000 octets)

  • Colonne V$DATABASE, Goldengate_Blocking_Mode peut être interrogé pour déterminer le statut du mode de blocage actuel.

• Pour le mode de capture automatique DDL :

  • Elle n'est pertinente que pour DDL INCLUDE MAPPED car le processus Extract capture des instructions LDD basées sur les paramètres TABLE et TABLEEXCLUDE.

  • Seuls les instructions LDD relatives aux tables peuvent être capturées automatiquement.

  • Instructions LDD pour activer la capture automatique au niveau table :

    CREATE/ALTER TABLE ... ENABLE LOGICAL REPLICATION ALLKEYS;

  ou

    <pre class="copy"><code>CREATE/ALTER TABLE ... ENABLE LOGICAL REPLICATION ALLOW NOVALIDATE KEYS;</code></pre>
  

  Reportez-vous à Capture de la journalisation supplémentaire pour Oracle GoldenGate dans le guide Utilitaires Oracle AI Database.

• Les opérations suivantes sont prises en charge pour les instructions LDD liées aux partitions et les opérations de maintenance des partitions

  • Supprimer la partition :

  Si une partition est recréée avec le même nom, elle obtient un nouveau numéro d'objet. Les caches internes sont effacés pour réduire la consommation d'espace lorsqu'un script LDD de suppression de partition est traité.

  • Tronquer la partition :

  Le nom de partition et le numéro d'objet restent identiques. La version de l'objet de table de base reste la même.

  • Renommer la partition :

  Le numéro de l'objet de partition reste le même mais obtient un nouveau nom. La version d'objet de la table de base est dépassée. Dans le cache des noms de mémoire, le script DDL s'affiche et le code DML suivant est réutilisé. Le cache, qui stocke si un numéro d'objet de partition donné est intéressant ou non, devra également être réévalué car un nouveau nom de partition peut passer de filtré à non filtré ou vice versa.

  • Partition Exchange :

  Echanger des données dans une partition avec celles d'une table ou inversement. Le n° obj de la partition échangée ne change pas. Dataobj# change mais n'est pas utilisé par le processus Extract. La partition elle-même appartient toujours à la même table.

  • Fusionner la partition :

  Fusionne une ou plusieurs partitions dans une nouvelle partition. Le script LDD crée la nouvelle partition et supprime les partitions à partir desquelles elle a été fusionnée. Dans les caches de mémoire doivent être effacés pour économiser de l'espace et l'utilisateur doit s'assurer que les règles de filtrage appropriées pour la nouvelle partition créée.

  • Partition fractionnée :

  La partition fractionnée conserve son nom et son numéro d'objet d'origine, et une nouvelle partition est créée pour les données fractionnées. L'utilisateur doit s'assurer que les règles de filtre de partition sont correctes pour la partition nouvellement créée.

  • Partition coalescente :

  Réduit le nombre de partitions dans une table partitionnée par hachage. La partition fusionnée spécifique est sélectionnée par la base de données et supprimée après redistribution de son contenu. Les partitions restantes conservent le même nom et le même numéro d'objet. Les caches internes doivent être effacés pour réduire la consommation d'espace.

  • Modifier la partition :

  Modifie les attributs par défaut et réels des partitions, en plus de l'ajout ou de la suppression de valeurs pour les partitions de liste. Toutes les modifications laissent le nom et le numéro d'objet des partitions intacts.

  • Déplacer la partition :

  Les données de partition sont déplacées vers un nouveau tablespace. Le nom et le numéro de la partition restent identiques.

  • Table de récif :

  dbms_redefinition peut être utilisé pour partitionner une table via l'utilisation d'une table temporaire. Les partitions sont créées sur la table temporaire et, après l'opération finish_redef, les noms de swap des tables. Les partitions créées dans la table temporaire conservent leur nom et leur numéro d'objet lorsque les tables sont échangées. Le cache de filtre d'extraction doit être réévalué sur finish_redef car les partitions appartiennent désormais à la table de base. L'utilisateur doit s'assurer que les règles de filtrage sont correctes.

  • Partition de récif :

  Lors de la redéfinition d'une table, les partitions suivent la table d'origine vers la table temporaire. Par exemple, considérons le cas où la table d'origine comporte des partitions, qui résident dans le tablespace USER, et où la table temporaire est créée sans partitions et où la table réside dans le tablespace NEW. Dans ce cas, après l'opération finish_redef, lorsque les tables sont échangées, la partition réside toujours dans le tablespace USER. La partition Redef permet de déplacer une partition vers le tablespace NEW de la table temporaire. La partition conserve son nom et son numéro d'objet.

  • Noms de partition générés par le système :

  Lorsque des partitions sont créées automatiquement pour des partitions de hachage et des opérations telles que la partition fractionnée, le nom de la partition est au format SYS_P sequence value. De même, les sous-partitions sont de la forme SYS_SUBP sequence value. Il est recommandé de renommer la partition avant d'excepter les instructions LMD pour qu'elles soient conformes aux règles de filtrage.

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

Voici la liste des opérations et des objets non pris en charge dans Oracle DDL.

Objets exclus

Les noms ou préfixes de nom suivants sont considérés comme réservés par Oracle et doivent être exclus de la configuration LDD Oracle GoldenGate. Oracle GoldenGate ignore les objets qui contiennent ces noms.

Schémas exclus :

"ANONYMOUS", // HTTP access to XDB
"APPQOSSYS", // QOS system user
"AUDSYS", // audit super user
"BI", // Business Intelligence
"CTXSYS", // Text
"DBSNMP", // SNMP agent for OEM
"DIP", // Directory Integration Platform
"DMSYS", // Data Mining
"DVF", // Database Vault
"DVSYS", // Database Vault
"EXDSYS", // External ODCI System User
"EXFSYS", // Expression Filter
"GSMADMIN_INTERNAL", // Global Service Manager
"GSMCATUSER", // Global Service Manager
"GSMUSER", // Global Service Manager
"LBACSYS", // Label Security
"MDSYS", // Spatial
"MGMT_VIEW", // OEM Database Control
"MDDATA",
"MTSSYS", // MS Transaction Server
"ODM", // Data Mining
"ODM_MTR", // Data Mining Repository
"OJVMSYS", // Java Policy SRO Schema
"OLAPSYS", // OLAP catalogs
"ORACLE_OCM", // Oracle Configuration Manager User
"ORDDATA", // Intermedia
"ORDPLUGINS", // Intermedia
"ORDSYS", // Intermedia
"OUTLN", // Outlines (Plan Stability)
"SI_INFORMTN_SCHEMA", // SQL/MM Still Image
"SPATIAL_CSW_ADMIN", // Spatial Catalog Services for Web
"SPATIAL_CSW_ADMIN_USR",
"SPATIAL_WFS_ADMIN", // Spatial Web Feature Service
"SPATIAL_WFS_ADMIN_USR",
"SYS",
"SYSBACKUP",
"SYSDG",
"SYSKM",
"SYSMAN", // Adminstrator OEM
"SYSTEM",
"TSMSYS", // Transparent Session Migration
"WKPROXY", // Ultrasearch
"WKSYS", // Ultrasearch
"WK_TEST",
"WMSYS", // Workspace Manager
"XDB", // XML DB
"XS$NULL",
"XTISYS", // Time Index

Schémas spéciaux :

"AURORA$JIS$UTILITY$", // JSERV
"AURORA$ORB$UNAUTHENTICATED", // JSERV
"DSSYS", // Dynamic Services Secured Web Service
"OSE$HTTP$ADMIN", // JSERV
"PERFSTAT", // STATSPACK
"REPADMIN",
"TRACESVR" // Trace server for OEM

Tables exclues (le caractère générique * indique tout schéma ou tout caractère) :

"*.AQ$*", // advanced queues
"*.DR$*$*", // oracle text
"*.M*_*$$", // Spatial index
"*.MLOG$*", // materialized views
"*.OGGQT$*",
"*.OGG$*", // AQ OGG queue table
"*.ET$*", // Data Pump external tables
"*.RUPD$*", // materialized views
"*.SYS_C*", // constraints
"*.MDR*_*$", // Spatial Sequence and Table
"*.SYS_IMPORT_TABLE*",
"*.SYS_EXPORT_TABLE*",
"*.CMP*$*", // space management, rdbms >= 12.1
"*.DBMS_TABCOMP_TEMP_*", // space management, rdbms < 12.1
"*.MDXT_*$*" // Spatial extended statistics tables

Autre DDL non pris en charge

Oracle GoldenGate ne prend pas en charge les éléments suivants :

• LDD sur les tables imbriquées.

• LDD sur les colonnes d'identité.

• ALTER DATABASE et ALTER SYSTEM (ils ne sont pas considérés comme LDD) A l'aide du dictionnaire, vous pouvez répliquer ALTER DATABASE DEFAULT EDITION et ALTER PLUGGABLE DATABASE DEFAULT EDITION. Toutes les autres commandes ALTER [PLUGABLE] DATABASE sont ignorées.

• LDD sur une base de données de secours.

• LDD de lien de base de données.

• LDD qui crée des tables avec la clause FLASHBACK ARCHIVE et LDD qui crée, modifie ou supprime la Flashback Data Archive elle-même. Les instructions LMD sur les tables avec FLASHBACK ARCHIVE sont prises en charge.

• Certains DDL génèrent des noms d'objet générés par le système. Les noms des objets générés par le système peuvent ne pas toujours être identiques entre deux bases de données différentes. Par conséquent, les opérations LDD sur les objets portant des noms générés par le système ne doivent être effectuées que si le nom est exactement le même sur la cible.