Operaciones soportadas con evolución automática de esquemas

La evolución automática del esquema está soportada en los destinos Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, DB2400, Teradata y Oracle TimesTen.

La evolución automática del esquema está soportada en los orígenes Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, Db2 zOS, DB2400, Sybase, Teradata, Oracle TimesTen y Snowflake.

Se admiten las siguientes operaciones:

La respuesta Automatic Schema Evolution por defecto se puede sustituir mediante AUTOSCHEMAOPTIONS. Las siguientes opciones están soportadas:
- TYPEMAP: utilice esta opción para sustituir la asignación de tipo de dato por defecto
- IGNORE_DATA_TRUNCATION: si la asignación de tipo de dato por defecto prevé cualquier posible truncamiento de datos, Replicat finaliza de forma anormal con el error adecuado por defecto. Para ignorar estos errores de truncamiento de datos y permitir que Replicat continúe sin terminar de forma anormal, puede especificar AUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATION en el archivo de parámetros de Replicat.
- IGNORE_MODIFY_KEY_COLUMN: por defecto, la evolución automática del esquema no permite modificar las columnas de clave primaria y Replicat termina de forma anormal en estos casos con un error adecuado. Puede especificar AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMN para omitir cualquier modificación en las columnas de clave.
- ALLOW_MODIFY_KEY_COLUMN: por defecto, la evolución automática del esquema no permite modificar las columnas de clave primaria y Replicat termina de forma anormal en estos casos. Puede especificar AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMN para permitir cualquier modificación en las columnas de clave.
- MODIFY_COLUMN_NULLABILITY_ONLY: puede especificar AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLY si solo están interesados en la modificación de la nulidad de la columna y no en la modificación del tipo.

La evolución automática del esquema soporta las siguientes operaciones en función de los cambios del esquema, detectados en los registros de metadatos de los archivos de pista para mantener sincronizado el esquema de las tablas de origen y destino:

Creación de la tabla que falta en la base de datos destino
Modificación de la tabla de destino mediante la realización de columnas ADD/MODIFY/DROP

Según los metadatos de cada columna de origen, por defecto se selecciona el tipo de dato más adecuado para la columna de destino correspondiente.

NOTA: Revise las asignaciones de tipo de datos predeterminadas aplicables para el escenario de replicación de base de datos de origen a base de datos de destino de Asignación de tipo de datos antes de implantar la evolución automática del esquema.

Es posible que los tipos de dato de destino no sean exactamente iguales que el tipo de dato de origen en todos los casos. Siempre que sea posible, la elección del tipo de dato de destino se realiza de modo que el tipo de destino sea siempre compatible y lo suficientemente grande (con el mismo tamaño que la columna de origen o más amplio) para poder acomodar los datos de la columna de origen correspondiente. En algunos casos en los que no hay un tipo adecuado disponible para el tipo de dato de columna de origen correspondiente en la base de datos de destino (como los tipos disponibles en la base de datos de destino pueden provocar el truncamiento de datos), se devuelve un error al usuario con una recomendación adecuada.

Creación de la tabla que falta

AutoSchema soporta los siguientes casos de uso:

Cree la tabla que falta en el destino al aplicar los datos de pista generados por la extracción de CDC.
Cree la tabla que falta en el destino al aplicar los datos de pista generados por la extracción de carga inicial.
Al aplicar la pista generada solo por el Extract initialLoad, puede seleccionar borrar la tabla de destino existente y crear otro Extract especificando OPTYPE RECREATE como parte de los criterios de inclusión DDL AUTOSCHEMA.
Si todas las columnas de clave de origen correspondientes de los metadatos de pista no son nulas, el esquema automático crea la tabla de destino con una cláusula PRIMARY KEY con todas las columnas correspondientes.
Si alguna de las columnas de clave de origen correspondientes, a partir de los metadatos de pista, es nula, el esquema automático crea la tabla de destino con una cláusula UNIQUE KEY con todas las columnas correspondientes.

Modificación de la Tabla Existente

Si se agrega, borra o modifica alguna columna en el origen, las DDL ALTER TABLE correspondientes se generan y ejecutan en las tablas de destino asignadas correspondientes. El esquema automático admite modificaciones relacionadas solo con el tipo (incluido el nombre del tipo de datos, la longitud, la precisión, la escala según corresponda) y la restricción de nulidad. Sin embargo, no cumple ninguna modificación en ningún otro atributo de columna. Si se detecta algún cambio de esquema relacionado con el tipo/nulabilidad en las columnas de origen, se propagan a las columnas de destino.

Uno o varios cambios de esquema en la tabla de origen pueden dar lugar a una o varias DDL ALTER TABLE en las tablas de destino asignadas, tal como están soportadas en la base de datos de destino específica. El número de DDL del destino depende de la sintaxis soportada en una base de datos de destino específica, como en los siguientes casos:

Pocas bases de datos no permiten agregar/soltar/modificar varias columnas en un solo ALTER TABLE DDL.
Pocas bases de datos no permiten modificar tanto el tipo como la nulabilidad de las columnas en una sola sentencia ALTER TABLE DDL.

En estos casos, el número necesario de sentencias ALTER TABLE DDL se ejecuta en la tabla de destino, según los requisitos de la base de datos de destino.

Es posible que el esquema automático afecte a la base de datos de destino que necesita más acciones. Por ejemplo, si un ALTER TABLE MODIFY COLUMN puede dar lugar a algún truncamiento de datos, diferentes bases de datos pueden manejar esto de diferentes maneras. Una base de datos puede detectar que la operación puede truncar algunos datos existentes y hacer que el Replicat se pare, lo que suele ocurrir entre Oracle y MySQL, cuando MySQL se está ejecutando con el modo estricto activado. Sin embargo, si MySQL está configurado en modo no estricto, es posible que se produzca una tracción sin advertencia.

Para IBM i, según la configuración del sistema, puede parecer que el Replicat se bloquea. Para algunas acciones en Db2 (anteriormente Db2 LUW) y Db2 z/OS, es posible que determinadas acciones requieran una reorganización de la tabla. En Db2 z/OS, no se reconocerá una columna de borrado hasta que se realice una reorganización y, para Db2, la tabla podría terminar en un estado pendiente de reorganización y dejar de permitir más operaciones en ella.

NOTA: si es necesario, puede agregar de forma selectiva OPTYPE ADDCOLUMN, OPTYPE DROPCOLUMN y OPTYPE MODIFYCOLUMN a los criterios de inclusión/exclusión DDL AUTOSCHEMA.