Operações Suportadas com a Evolução Automática do Esquema

A Evolução Automática do Esquema é suportada em destinos Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, DB2400, Teradata e TimesTen da Oracle.

A Evolução Automática do Esquema é suportada em origens Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, Db2 zOS, DB2400, Sybase, Teradata, Oracle TimesTen e Snowflake.

As seguintes operações são suportadas:

A resposta de Evolução Automática do Esquema padrão pode ser substituída usando AUTOSCHEMAOPTIONS. As seguintes opções são suportadas:
- TYPEMAP: Use esta opção para substituir o mapeamento de tipo de dados padrão
- IGNORE_DATA_TRUNCATION: Se o mapeamento de tipo de dados padrão prever qualquer possível truncamento de dados, o Replicat será encerrado com erro apropriado por padrão. Para ignorar esses erros de truncamento de dados e permitir que o Replicat continue sem terminar em ordem, você pode especificar AUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATION no arquivo de parâmetros do Replicat.
- IGNORE_MODIFY_KEY_COLUMN: Por padrão, a Evolução Automática do Esquema não permite modificar a(s) coluna(s) de chave primária e o processo Replicat é encerrado em tais casos com um erro apropriado. Você pode especificar AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMN para ignorar qualquer modificação nas colunas de chave.
- ALLOW_MODIFY_KEY_COLUMN: Por padrão, a Evolução Automática do Esquema não permite modificar a(s) coluna(s) de chave primária e o processo Replicat é encerrado em tais casos. Você pode especificar AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMN para permitir qualquer modificação nas colunas de chave.
- MODIFY_COLUMN_NULLABILITY_ONLY: Você poderá especificar AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLY se eles estiverem interessados apenas na modificação da nulidade da coluna e não na modificação do tipo.

A Evolução Automática do Esquema suporta as seguintes operações com base nas alterações de esquema, detectadas nos registros de metadados nos arquivos de trilha para manter o esquema das tabelas de origem e de destino sincronizadas:

Criando a tabela ausente no banco de dados de destino
Alterando a tabela de destino executando as colunas ADD/MODIFY/DROP

Com base em todos os metadados da coluna de origem, por padrão, o tipo de dados mais adequado é escolhido para a coluna de destino correspondente.

OBSERVAÇÃO: analise os mapeamentos de tipo de dados padrão aplicáveis para o banco de dados de origem específico para o cenário de replicação do banco de dados de destino no Mapeamento de Tipo de Dados antes de implementar a Evolução Automática do Esquema.

Os tipos de dados de destino podem não ser exatamente iguais ao tipo de dados de origem em todos os casos. Sempre que possível, a escolha do tipo de dados de destino é feita de modo que o tipo de destino seja sempre compatível e grande o suficiente (com o mesmo tamanho da coluna de origem ou mais amplo) para poder acomodar os dados da coluna de origem correspondente. Em alguns casos em que não há um tipo apropriado disponível para o tipo de dados da coluna de origem correspondente no banco de dados de destino (como os tipos disponíveis no banco de dados de destino podem causar truncamento de dados), um erro é retornado ao usuário com uma recomendação apropriada.

Criando a Tabela Ausente

O AutoSchema suporta os seguintes casos de uso:

Crie a tabela ausente no destino ao aplicar os dados de trilha gerados pelo Extract CDC.
Crie a tabela ausente no destino ao aplicar os dados de trilha gerados pelo Extract de carga inicial.
Ao aplicar a trilha gerada somente pelo Extract initialLoad, você pode optar por eliminar a tabela de destino existente e criar outro Extract especificando OPTYPE RECREATE como parte dos critérios de inclusão DDL AUTOSCHEMA.
Se todas as colunas de chave de origem correspondentes dos metadados da trilha não puderem ser anuladas, o Esquema Automático criará a tabela de destino com uma cláusula PRIMARY KEY com todas as colunas correspondentes.
Se qualquer uma das colunas de chave de origem correspondentes, dos metadados da trilha, puder ser anulada, o Esquema Automático criará a tabela de destino com uma cláusula UNIQUE KEY com todas as colunas correspondentes.

Alterando a Tabela Existente

Se alguma coluna for adicionada/eliminada/modificada na origem, as DDLs ALTER TABLE correspondentes serão geradas e executadas nas tabelas de destino mapeadas correspondentes. O Esquema Automático suporta modificações relacionadas apenas ao tipo (incluindo nome do tipo de dados, tamanho, precisão, escala conforme aplicável) e à restrição de anulação. No entanto, não honra nenhuma modificação em nenhum outro atributo de coluna. Se forem detectadas alterações de esquema relacionadas a tipo/anulação nas colunas de origem, elas serão propagadas nas colunas de destino.

Uma ou várias alterações de esquema na tabela de origem podem resultar em uma ou várias ALTER TABLE DDLs nas tabelas de destino mapeadas, conforme suportado no banco de dados de destino específico. O número de DDLs no destino depende da sintaxe suportada em um banco de dados de destino específico, como nos seguintes casos:

Poucos bancos de dados não permitem adicionar/eliminar/modificar várias colunas em um único ALTER TABLE DDL.
Poucos bancos de dados não permitem a modificação de tipo e anulação de coluna(s) em uma única instrução ALTER TABLE DDL.

Nesses casos, o número necessário de instruções ALTER TABLE DDL é executado na tabela de destino, com base nos requisitos do banco de dados de destino.

É possível que o Esquema Automático possa afetar o banco de dados de destino, exigindo mais ações. Por exemplo, se um ALTER TABLE MODIFY COLUMN puder resultar em algum truncamento de dados, diferentes bancos de dados poderão tratar isso de maneiras diferentes. Um banco de dados pode detectar alguns dados existentes que podem ser truncados pela operação e fazer com que o Replicat seja interrompido, o que geralmente acontece entre o Oracle e o MySQL, quando o MySQL está em execução com o modo restrito ativado. No entanto, se MySQL estiver configurado no modo não restrito, a tração poderá ocorrer sem aviso.

Para IBM i, dependendo de como o sistema está configurado, o Replicat pode parecer travar. Para algumas ações no Db2 (anteriormente Db2 LUW) e no Db2 z/OS, determinadas ações podem exigir reorganização da tabela. Em Db2 z/OS, uma coluna de eliminação não será reconhecida até que uma reorganização seja executada, e para Db2 a tabela pode acabar em um estado de reorganização pendente e parar de permitir mais operações contra ela.

OBSERVAÇÃO: se necessário, você pode adicionar seletivamente OPTYPE ADDCOLUMN, OPTYPE DROPCOLUMN e OPTYPE MODIFYCOLUMN aos critérios de inclusão/exclusão DDL AUTOSCHEMA.