Limites

Tenez compte des limites suivantes si vous prévoyez d'utiliser la fonctionnalité d'évolution automatique des schémas :

• Le processus Replicat prend en charge le schéma automatique uniquement en mode classique et en mode coordonné (le mode parallèle n'est pas pris en charge).

• Le schéma automatique n'est pas pris en charge pour la réplication bidirectionnelle.

• Le schéma automatique n'est pas applicable à la table utilisée dans la clause MAPEXCEPTION. Les utilisateurs doivent créer explicitement la table des exceptions correspondante avant de démarrer la réplication.

• Le schéma automatique ne prend pas en charge le paramètre COLMATCH.

• Le schéma automatique ne propage pas les colonnes invisibles/masquées source de la source vers la cible.

• Le schéma automatique ne respecte pas le paramètre DDLSUBST.

• Automatic Schema ne propage pas tous les index ou contraintes présents sur la table source vers la table cible correspondante.

• Le schéma automatique n'honore aucun jeu de caractères et/ou classement au niveau de la colonne source. Le jeu de caractères ou le classement de niveau colonne correspondant n'est pas associé aux colonnes cible.

  • Automatic Schema n'associe aucun jeu de caractères de niveau table aux tables cible.

  • Automatic Schema n'associe aucun jeu de caractères ou classement de niveau colonne aux colonnes cible.

    Lorsque vous utilisez le schéma automatique, assurez-vous de vérifier les jeux de caractères utilisés sur la source et les jeux de caractères disponibles sur les systèmes cible. Ne supposez pas que les jeux de caractères source sont nécessairement disponibles sur le système cible. Cela est particulièrement vrai si les bases de données n'utilisent pas toutes une forme d'Unicode. A l'heure actuelle, lors de l'utilisation d'Automatic Schema, la meilleure compatibilité avec les jeux de caractères de la base de données source est assurée par le fait que toute base de données cible utilise UTF-8 ou UTF-16 pour ses colonnes de caractères. Ceci est particulièrement visible lorsque les bases de données IBM Db2 sont la source. Pour Db2 pour z/OS et Db2 pour i, les données source sont souvent une forme d'EBCDIC et si la cible est une autre famille de bases de données, il est peu probable que ces jeux de caractères soient directement représentables sur la cible. Une préoccupation similaire peut également être faite pour les jeux de caractères ASCII, car toutes les bases de données ne les prennent pas tous en charge.

  IMPORTANT : l'utilisation d'Unicode pour la base de données cible peut nécessiter une extension de la longueur des champs de caractères pour garantir que la taille appropriée est disponible lors du mappage à partir d'une source qui n'est pas Unicode lui-même. Si la base de données cible utilise plus d'octets pour représenter un caractère que le nombre d'octets utilisés par la base de données source, les utilisateurs doivent utiliser AUTOSCHEMAOPTIONS TYPEMAP pour toutes ces colonnes et utiliser un type de données cible plus large et compatible pour éviter toute troncation de données possible.

• Le schéma automatique ne prend pas en charge les colonnes source de type AUTO-INCREMENT et ne crée pas/modifie les colonnes cible correspondantes avec les mêmes propriétés d'incrémentation automatique.

• Il est possible que le schéma automatique ne crée pas correctement la clé primaire/unique sur la table cible lorsque la table MySQL source contient uniquement une clé unique et aucune clé primaire. Base de données MySQL qui ne fournit pas les informations clés correctes.

REMARQUE : Il ne s'agit pas d'une limitation imposée par le schéma automatique, mais de la source MySQL.

• Si la base de données source est Oracle Database 19c, il est possible que le schéma automatique ne puisse pas déterminer correctement la capacité d'annulation des colonnes cible.

REMARQUE : Il ne s'agit pas d'une limitation de schéma automatique, mais c'est le fichier Oracle Database 19c source qui ne fournit pas les informations clés correctes. Les colonnes de type char et varchar2 source Oracle sont toujours évaluées à l'aide de la sémantique des octets, même si le DDL source utilise la sémantique char.

• Si aucune clé primaire n'est définie pour la table source Oracle, mais qu'elle ne contient qu'une clé unique contenant l'une des colonnes virtuelles, les colonnes avec valeur NULL, les types de données définis par l'utilisateur, les colonnes varchar longues étendues ou les colonnes d'index basées sur une fonction, en tant que colonne(s) de clé valide(s), Automatic Schema ne crée pas de colonne(s) de ce type en tant que clé primaire/unique sur la table cible.

• Si la source est une base de données PostgreSQL et que la table source comporte des colonnes LOB dans la clé, les utilisateurs doivent indiquer DBOPTIONS MAXLOBKEYLEN <value> dans leur fichier de paramètres d'extraction. Sinon, par défaut (sans AUTOSCHEMAOPTIONS TYPEMAP), le schéma automatique crée les colonnes correspondantes avec une longueur nulle sur la cible.

• Pour le type PostgreSQL Array source, le schéma automatique crée le type CLOB ou son équivalent pour la colonne cible correspondante. AUTOSCHEMAOPTIONS TYPEMAP doit être indiqué pour sélectionner le type de cible approprié, en fonction du nom de colonne PostgreSQL Array source.

• Par défaut, pour les colonnes CLOB source Oracle avec un jeu de caractères de base de données à plusieurs octets, NCLOB ou un type de cible équivalent est choisi pour la colonne cible. Pour remplacer, TYPEMAP doit être utilisé.

• Pour Db2 pour z/OS, la réplication des données UTF-16 nécessite une base de données EBCDIC ou Unicode. Les autres codages sur deux octets ne sont pas explicitement pris en charge.

• Pour les bases de données IBM Db2 (anciennement Db2 pour LUW) qui répliquent des données UTF-16, une base de données Unicode est requise. Les autres codages sur deux octets ne sont pas explicitement pris en charge.

• Pour les colonnes de type ENUM source, le schéma automatique applique le type de cible char sur MySQL. Si nécessaire, utilisez TYPEMAP pour utiliser VARCHAR à la place.

• AUTOSCHEMAOPTIONS TYPEMAP doit être spécifié en fonction du nom de la colonne source, et non du nom du type de données source, pour les colonnes numériques/décimales source avec une précision inférieure à 8.

• AUTOSCHEMAOPTIONS TYPEMAP doit être indiqué en fonction du nom de la colonne source et non en fonction du nom du type de données source pour les colonnes source de type :
  • Colonnes de type char/varchar avec une longueur > 4000.
  • TEMPS (p)
  • TEMPS (p) SANS ZONE DE TEMPS
  • TEMPS(p) AVEC ZONE DE TEMPS
  • TIMESTAMP(p)
  • TIMESTAMP(p) SANS ZONE DE TEMPS
  • TIMESTAMP(p) AVEC ZONE TEMPS
  • Toutes les variantes INTERVAL
  • Colonnes de type de vecteur SQL Server source

• Automatic Schema ne prend pas en charge l'utilisation de la clause COLMAP avec des noms de colonne contenant des guillemets doubles. Le nom de colonne cible utilisé dans un mapping de colonne spécifique de la clause COLMAP, qui est mis en correspondance avec un nom de colonne source, ne peut pas être identique à un autre nom de colonne de la table source.

• Quelques messages d'erreur de schéma automatique peuvent apparaître en ASCII lorsque l'environnement local du système où GoldenGate est en cours d'exécution est un jeu de caractères multioctets, tel que chinois ou japonais (par exemple, zh_CN.UTF-8).

• Sur la cible SQL Server, pour tout type datetime/timestamp source sans fraction de seconde, vous devez indiquer AUTOSCHEMAOPTIONS TYPEMAP pour le type de source (ou le nom de colonne) correspondant avec datetime2(0) comme type de cible de remplacement indiqué.

• Sur la cible Db2 z/OS, le schéma automatique ne prend pas en charge la suppression de plusieurs colonnes à l'aide d'une seule valeur ALTER TABLE DDL. Vous pouvez réexécuter le script LDD en échec qui est signalé dans l'erreur OGG (à partir du fichier de rapport Replicat) et redémarrer le processus Replicat.

• Sur la cible SQLServer, le schéma automatique ne détecte pas/exécute correctement la modification de colonne de VARCHAR(n) à TEXT ou VARCHAR(max).

• AUTOSCHEMAOPTIONS TYPEMAP ne fonctionne pas pour les spécifications de type de cible :
  • NUMÉRO (p,s)
  • NUMÉRIQUE(p,s)
  • DÉCIMAL(p,s)
  • TIMESTAMP(p) avec fuseau horaire
  • TIME(p) avec fuseau horaire : la solution consiste à utiliser TIME(p) comme spécification de nom de type de cible au lieu de TIME(p) sans fuseau horaire car les deux sont sémantiquement équivalents.
  • TIMESTAMP(p) sans fuseau horaire Comme solution de contournement, vous pouvez utiliser TIMESTAMP(p) comme spécification de nom de type de cible au lieu de TIMESTAMP(p) sans fuseau horaire car les deux sont sémantiquement équivalents.
  • Varbinary(max)
  • Varchar(max) : la solution consiste à utiliser CLOB comme spécification de nom de type de cible au lieu de varchar(max)
  • Nvarchar(max) : la solution consiste à utiliser NCLOB comme spécification de nom de type de cible au lieu de nvarchar(max)

• Sur la cible SQLServer, la spécification de la dimension Vector dans la spécification de type est obligatoire. La spécification du type de base (comme float16 ou float32) est facultative.

• Pour les colonnes source SQLServer de type DATETIME, le schéma automatique ne peut pas faire la distinction entre DATETIME et DATETIME2(3). Par conséquent, lorsque vous utilisez une clause TYPEMAP explicite, vous devez configurer une valeur TYPEMAP basée sur le nom de colonne source au lieu d'une correspondance de type basée sur le nom de type source.

• Pour les colonnes NCHAR cible DB2AS400, le schéma automatique ne détecte pas correctement les modifications de type de colonne requises.

• Si une base de données Oracle GoldenGate Delivery sur PostgreSQL (ou compatible PostgreSQL) est configurée pour utiliser le pilote ODBC natif PostgreSQL, le schéma automatique ne détecte pas correctement les cas de modification de colonne de table.

• Pour IBM Db2 pour i, il est possible qu'un travail semble "bloqué" et ne progresse pas. Par exemple, cela est plus probable sur la réplication lorsque le schéma automatique est utilisé si l'opération demandée peut entraîner un problème de troncation des données. Selon la façon dont le système IBM i est configuré, le travail de réplication peut être placé dans un état d'attente de message (MSGW) où le système attend qu'un utilisateur fournisse l'action que le travail doit entreprendre pour résoudre le problème spécifique. Actuellement, il n'y a aucun moyen pour GoldenGate d'y remédier directement, et vous devez le gérer du côté IBM i.

• Pour les types de colonne Snowflake source TIMESTAMP_NTZ(p), TIMESTAMP_LTZ(p) ou TIMESTAMP_TZ(p), le schéma automatique les met en correspondance avec les colonnes d'horodatage correspondantes, mais avec une précision de date/heure de 0. Pour éviter la troncature des données de la fraction de seconde, vous devez utiliser AUTOSCHEMAOPTIONS TYPEMAP pour sélectionner le type requis sur la cible.

• Le schéma automatique ne différencie pas les types de colonne JSON et JSONB source PostgreSQL. Vous devez utiliser AUTOSCHEMAOPTIONS TYPEMAP en fonction du nom de colonne source au lieu du type de colonne pour les types JSONB source PostgreSQL.

• Le schéma automatique ne fait pas de distinction entre les types de colonne numérique non limitée source PostgreSQL (numérique sans précision et échelle) et numérique source PostgreSQL (1000, 100). Vous devez utiliser AUTOSCHEMAOPTIONS TYPEMAP en fonction du nom de la colonne source au lieu du type de colonne pour les colonnes de type numérique source (1000,100) PostgreSQL.

• Pour les types de colonne source Snowflake ARRAY, GEOGRAPHY et GEOMETRY, le schéma automatique est mis en correspondance avec le type JSON (si pris en charge) ou CLOB sur la cible. Pour sélectionner un autre type sur la cible, les utilisateurs doivent utiliser AUTOSCHEMAOPTIONS TYPEMAP.

• Le(s) message(s) informatif(s) contenant la partie AUTOSCHEMAOPTIONS TYPEMAP des spécifications basées sur le nom de colonne source ne s'affiche pas correctement.