Limitaciones

Tenga en cuenta las siguientes limitaciones si tiene previsto utilizar la funcionalidad de evolución automática de esquemas:

• Replicat solo soporta el esquema automático en los modos Clásico y Coordinado (no se admite el modo paralelo).

• El esquema automático no está soportado para la replicación bidireccional.

• El esquema automático no se aplica a la tabla utilizada en la cláusula MAPEXCEPTION. Los usuarios deben crear explícitamente la tabla de excepciones correspondiente antes de iniciar la replicación.

• El esquema automático no soporta el parámetro COLMATCH.

• El esquema automático no propaga las columnas invisibles/ocultas de origen del origen al destino.

• El esquema automático no cumple el parámetro DDLSUBST.

• El esquema automático no propaga todos los índices o restricciones presentes en la tabla de origen a la tabla de destino correspondiente.

• El esquema automático no cumple con ningún juego de caracteres de nivel de columna de origen ni con ninguna ordenación. El juego de caracteres o la ordenación de nivel de columna correspondiente no están asociados a las columnas de destino.

  • El esquema automático no asocia ningún juego de caracteres de nivel de tabla a las tablas de destino.

  • El esquema automático no asocia ningún juego de caracteres de nivel de columna ni ninguna ordenación con las columnas de destino.

    Al utilizar el esquema automático, asegúrese de comprobar los juegos de caracteres que se utilizan en el origen y los juegos de caracteres disponibles en los sistemas de destino. No suponga que los juegos de caracteres de origen están necesariamente disponibles en el sistema de destino. Esto es especialmente cierto si no todas las bases de datos utilizan algún tipo de Unicode. En este momento, al utilizar el esquema automático, la mejor compatibilidad con los juegos de caracteres de la base de datos origen se proporciona asegurándose de que cualquier base de datos destino utiliza UTF-8 o UTF-16 para sus columnas de caracteres. Esto se muestra más claramente cuando las bases de datos Db2 de IBM son el origen. Para Db2 para z/OS y Db2 para i, los datos de origen suelen ser una forma de EBCDIC y, si el destino es cualquier otra familia de bases de datos, es poco probable que esos juegos de caracteres se puedan representar directamente en el destino. También se puede plantear una preocupación similar para los juegos de caracteres ASCII, ya que no todas las bases de datos las admiten a todas.

  IMPORTANTE: el uso de Unicode para la base de datos de destino puede requerir una ampliación de la longitud de los campos de caracteres para garantizar que el tamaño adecuado esté disponible al asignar desde un origen que no sea Unicode en sí. Si la base de datos destino utiliza más bytes para representar un carácter que el número de bytes utilizados por la base de datos origen, los usuarios deben utilizar AUTOSCHEMAOPTIONS TYPEMAP para todas estas columnas y utilizar un tipo de dato de destino más amplio y compatible para evitar cualquier posible truncamiento de datos.

• El esquema automático no soporta las columnas de origen de tipo AUTO-INCREMENT y no crea ni modifica las columnas de destino correspondientes con las mismas propiedades de incremento automático.

• El esquema automático no puede crear la clave primaria/única correctamente en la tabla de destino cuando la tabla MySQL de origen solo contiene una clave única y ninguna clave primaria. Base de datos MySQL que no proporciona la información de clave correcta.

NOTA: Esta no es una limitación impuesta por el esquema automático, sino el origen MySQL.

• Si la base de datos origen es Oracle Database 19c, puede que el esquema automático no pueda derivar correctamente la nulidad de las columnas de destino.

NOTA: esta no es una limitación automática del esquema, pero es la instancia de Oracle Database 19c de origen la que no proporciona la información de clave correcta. Las columnas de tipo char y varchar2 de origen de Oracle siempre se evalúan mediante semántica de bytes, incluso si el DDL de origen utiliza semántica char.

• Si la tabla de origen de Oracle no tiene ninguna clave primaria definida pero solo tiene una clave única que contiene cualquiera de las columnas virtuales, las columnas nulables, los tipos de dato definidos por el usuario, las columnas varchar largas ampliadas o las columnas de índice basadas en funciones, como columnas de clave válidas, el esquema automático no crea dichas columnas como clave primaria/única en la tabla de destino.

• Si el origen es la base de datos PostgreSQL y la tabla de origen tiene columnas LOB como parte de la clave, los usuarios deben especificar DBOPTIONS MAXLOBKEYLEN <value> en su archivo de parámetros Extract. De lo contrario, por defecto (sin AUTOSCHEMAOPTIONS TYPEMAP), el esquema automático creará las columnas correspondientes con longitud cero en el destino.

• Para el tipo de origen PostgreSQL Array, el esquema automático crea el tipo CLOB o su equivalente para la columna de destino correspondiente. Se debe especificar AUTOSCHEMAOPTIONS TYPEMAP para seleccionar el tipo de destino adecuado, según el nombre de columna Array PostgreSQL de origen.

• Para las columnas CLOB de origen de Oracle con un juego de caracteres de base de datos de varios bytes, se selecciona NCLOB o un tipo de destino equivalente para la columna de destino, por defecto. Para sustituirlo, se debe utilizar TYPEMAP.

• Para Db2 para z/OS, la replicación de datos UTF-16 requiere una base de datos EBCDIC o Unicode. No se admiten explícitamente otras codificaciones de doble byte.

• Para las bases de datos IBM Db2 (anteriormente Db2 para LUW) que replican datos UTF-16, se necesita una base de datos Unicode. No se admiten explícitamente otras codificaciones de doble byte.

• Para las columnas de tipo ENUM de origen, el esquema automático aplica char como tipo de destino en MySQL. Si es necesario, utilice TYPEMAP para utilizar VARCHAR en su lugar.

• AUTOSCHEMAOPTIONS TYPEMAP se debe especificar en función del nombre de columna de origen, y no del nombre de tipo de dato de origen, para las columnas numéricas/decimales de origen con una precisión inferior a 8.

• AUTOSCHEMAOPTIONS TYPEMAP se debe especificar en función del nombre de columna de origen y no en función del nombre de tipo de dato de origen para las columnas de origen de tipos:
  • Columnas de tipo Char/Varchar con una longitud > 4000.
  • TIEMPO(p)
  • TIEMPO (p) SIN ZONA DE TIEMPO
  • TIEMPO(p) CON ZONA DE TIEMPO
  • TIMESTAMP(p)
  • TIMESTAMP(p) SIN TIEMPO ZONA
  • TIMESTAMP(p) CON ZONA DE TIEMPO
  • Todas las variantes INTERVAL
  • Columnas de tipo de vector de SQL Server de origen

• El esquema automático no soporta el uso de la cláusula COLMAP con nombres de columna que contienen comillas dobles. El nombre de columna de destino utilizado en una asignación de columna específica en la cláusula COLMAP, que se asigna a un nombre de columna de origen, no puede ser el mismo que cualquier otro nombre de columna de la tabla de origen.

• Pocos de los mensajes de error del esquema automático pueden aparecer en ASCII cuando la configuración regional del sistema en el que se ejecuta GoldenGate es un juego de caracteres multibyte, como chino o japonés (por ejemplo, zh_CN.UTF-8).

• En el destino de SQL Server, para cualquier tipo de origen datetime/timestamp sin segundos fraccionarios, debe especificar AUTOSCHEMAOPTIONS TYPEMAP para el tipo de origen correspondiente (o nombre de columna) con datetime2(0) como tipo de destino de sustitución especificado.

• En el destino z/OS Db2, el esquema automático no soporta el borrado de varias columnas mediante un único ALTER TABLE DDL. Puede volver a ejecutar el DDL con fallos que se informa en el error de OGG (desde el archivo de informe de Replicat) y reiniciar Replicat.

• En el destino SQLServer, el esquema automático no detecta/ejecuta correctamente la modificación de columna de VARCHAR(n) a TEXT o VARCHAR(max).

• AUTOSCHEMAOPTIONS TYPEMAP no funciona para las especificaciones de tipo de destino:
  • NUMBER (p,s)
  • NUMERIC(p,s)
  • DECIMAL(p,s)
  • TIMESTAMP(p) con zona horaria
  • TIME(p) con zona horaria: la solución alternativa es utilizar TIME(p) como especificación de nombre de tipo de destino en lugar de TIME(p) sin zona horaria porque ambos son semánticamente equivalentes.
  • TIMESTAMP(p) sin zona horaria Como solución alternativa, puede utilizar TIMESTAMP(p) como especificación de nombre de tipo de destino en lugar de TIMESTAMP(p) sin zona horaria porque ambos son semánticamente equivalentes.
  • Varbinary (máx.)
  • Varchar(max): La solución alternativa es utilizar CLOB como especificación de nombre de tipo de destino en lugar de varchar(max)
  • Nvarchar(max): la solución alternativa es usar NCLOB como especificación de nombre de tipo de destino en lugar de nvarchar(max)

• En el destino SQLServer, la especificación de la dimensión Vector en la especificación de tipo es obligatoria. La especificación del tipo base (como float16 o float32) es opcional.

• Para las columnas de origen SQLServer del tipo DATETIME, el esquema automático no puede distinguir entre DATETIME y DATETIME2(3). Por lo tanto, al utilizar la cláusula TYPEMAP explícita, debe configurar un TYPEMAP basado en el nombre de la columna de origen en lugar de un tipo de origen basado en el mapa de tipos.

• Para las columnas NCHAR de destino DB2AS400, el esquema automático no detecta correctamente las modificaciones de tipo de columna necesarias.

• Si alguna entrega de Oracle GoldenGate en la base de datos PostgreSQL (o compatible con PostgreSQL) está configurada para utilizar el controlador ODBC nativo PostgreSQL, el esquema automático no detecta correctamente las mayúsculas y minúsculas de la columna Modificar tabla.

• Para IBM Db2 for i, es posible que un trabajo parezca "colgarse" y no progrese. Por ejemplo, es más probable que en el replicat cuando se utiliza el esquema automático si la operación solicitada puede causar un problema de truncamiento de datos. Según la configuración del sistema IBM i, el trabajo de replicación se puede poner en un estado de espera de mensajes (MSGW) en el que el sistema espera a que un usuario proporcione la acción que debe realizar el trabajo para resolver el problema específico. Actualmente no hay forma de que GoldenGate aborde esto directamente, y debe manejarlo en el lado de IBM i.

• Para los tipos de columna Snowflake de origen de TIMESTAMP_NTZ(p), TIMESTAMP_LTZ(p) o TIMESTAMP_TZ(p), el esquema automático los asigna a las columnas de registro de hora correspondientes, pero con una precisión de fecha y hora de 0. Para evitar el truncamiento de datos de los segundos fraccionarios, debe utilizar AUTOSCHEMAOPTIONS TYPEMAP para seleccionar el tipo necesario en el destino.

• El esquema automático no diferencia los tipos de columna JSON y JSONB de origen PostgreSQL. Debe utilizar AUTOSCHEMAOPTIONS TYPEMAP basado en el nombre de columna de origen en lugar del tipo de columna para los tipos JSONB de origen PostgreSQL.

• El esquema automático no diferencia entre los tipos numéricos de origen PostgreSQL sin enlazar (numéricos sin precisión ni escala) y numéricos de origen PostgreSQL (1000, 100). Debe utilizar AUTOSCHEMAOPTIONS TYPEMAP basado en el nombre de columna de origen en lugar del tipo de columna para las columnas de tipo numérico (1000,100) de origen PostgreSQL.

• Para los tipos de columna de origen Snowflake de ARRAY, GEOGRAPHY y GEOMETRY, el esquema automático se asigna al tipo JSON (si está soportado) o al tipo CLOB en el destino. Para seleccionar un tipo diferente en el destino, los usuarios deben utilizar AUTOSCHEMAOPTIONS TYPEMAP.

• Los mensajes informativos que contienen especificaciones basadas en nombre de columna de origen, parte de AUTOSCHEMAOPTIONS TYPEMAP, no se muestran correctamente.