Limitações

Considere as seguintes limitações se estiver planejando usar a funcionalidade Evolução Automática do Esquema:

• O Replicat suporta Esquema Automático somente no modo Clássico e Coordenado (o modo Paralelo não é suportado).

• O Esquema Automático não é suportado para replicação bidirecional.

• O Esquema Automático não é aplicável à tabela usada na cláusula MAPEXCEPTION. Os usuários devem criar explicitamente a tabela de exceções correspondente antes de iniciar a replicação.

• O Esquema Automático não suporta o parâmetro COLMATCH.

• O Esquema Automático não propaga colunas de origem invisíveis/ocultas da origem para o destino.

• O Esquema Automático não honra o parâmetro DDLSUBST.

• O Esquema Automático não propaga todos os índices ou restrições presentes na tabela de origem para a tabela de destino correspondente.

• O Esquema Automático não honra nenhum conjunto de caracteres no nível da coluna de origem e/ou agrupamento. O conjunto ou agrupamento de caracteres no nível da coluna correspondente não está associado às colunas de destino.

  • O Esquema Automático não associa nenhum conjunto de caracteres no nível da tabela às tabelas de destino.

  • O Esquema Automático não associa nenhum conjunto de caracteres no nível da coluna ou agrupamento às colunas de destino.

    Ao usar o Esquema Automático, verifique os conjuntos de caracteres usados na origem e os conjuntos de caracteres disponíveis no(s) sistema(s) de destino. Não suponha que os conjuntos de caracteres de origem estejam necessariamente disponíveis no sistema de destino. Isto é especialmente verdadeiro se os bancos de dados não estão todos usando alguma forma de Unicode. Neste momento, ao usar o Esquema Automático, a melhor compatibilidade com conjuntos de caracteres do banco de dados de origem é fornecida, garantindo que qualquer banco de dados de destino esteja usando UTF-8 ou UTF-16 para suas colunas de caracteres. Isso é mostrado mais distintamente quando os bancos de dados IBM Db2 são a origem. Para Db2 para z/OS e Db2 para i, OS dados de origem geralmente são de alguma forma de EBCDIC e, se o destino for qualquer outra família de bancos de dados, é improvável que esses conjuntos de caracteres sejam representáveis diretamente no destino. Uma preocupação semelhante também pode ser feita para conjuntos de caracteres ASCII, uma vez que nem todos os bancos de dados suportam todos eles universalmente.

  IMPORTANTE: O uso do Unicode para o banco de dados de destino pode exigir uma expansão do tamanho dos campos de caracteres para garantir que o tamanho adequado esteja disponível durante o mapeamento de uma origem que não seja o próprio Unicode. Se o banco de dados de destino usar mais número de bytes para representar um caractere do que o número de bytes usados pelo banco de dados de origem, os usuários deverão usar AUTOSCHEMAOPTIONS TYPEMAP para todas essas colunas e usar um tipo de dados de destino mais amplo e compatível para evitar qualquer possível truncamento de dados.

• O Esquema Automático não suporta as colunas de origem do tipo AUTO-INCREMENT e não cria/altera as colunas de destino correspondentes com as mesmas propriedades de incremento automático.

• O Esquema Automático pode não criar a chave primária/exclusiva corretamente na tabela de destino quando a tabela MySQL de origem contiver apenas chave exclusiva e nenhuma chave primária. Banco de dados MySQL que não fornece as informações de chave corretas.

OBSERVAÇÃO: essa não é uma limitação imposta pelo Esquema Automático, mas pela origem MySQL.

• Se o banco de dados de origem for o Oracle Database 19c, talvez o Esquema Automático não consiga derivar a nulidade das colunas de destino corretamente.

OBSERVAÇÃO: essa não é uma limitação de Esquema Automático, mas é o Oracle Database 19c de origem que não fornece as informações de chave corretas. As colunas do tipo char e varchar2 de origem Oracle são sempre avaliadas usando semântica de byte, mesmo que a DDL de origem use semântica char.

• Se a tabela de origem Oracle não tiver uma chave primária definida, mas tiver apenas uma chave exclusiva contendo qualquer uma das colunas virtuais, colunas anuláveis, tipos de dados definidos pelo usuário, colunas varchar longas estendidas ou colunas de índice baseadas em função, como coluna(s) chave(s) válida(s), o Esquema Automático não criará essa(s) coluna(s) como chave primária/única na tabela de destino.

• Se a origem for o banco de dados PostgreSQL e a tabela de origem tiver qualquer coluna LOB como parte da chave, os usuários deverão especificar DBOPTIONS MAXLOBKEYLEN <value> em seu arquivo de parâmetros de Extract. Caso contrário, por padrão (sem qualquer AUTOSCHEMAOPTIONS TYPEMAP), o Esquema Automático criará colunas correspondentes com tamanho zero no destino.

• Para o Tipo Array de origem PostgreSQL, o Esquema Automático cria o tipo CLOB ou seu equivalente para a coluna de destino correspondente. AUTOSCHEMAOPTIONS TYPEMAP deve ser especificado para selecionar o tipo de destino adequado, com base no nome da coluna PostgreSQL Array de origem.

• Para colunas de origem CLOB da Oracle com conjunto de caracteres de banco de dados de vários bytes, NCLOB ou tipo de destino equivalente é escolhido para a coluna de destino, por padrão. Para substituir, TYPEMAP deve ser usado.

• Para Db2 para z/OS, a replicação de dados UTF-16 requer um banco de dados EBCDIC ou Unicode. Outras codificações de byte duplo não são explicitamente suportadas.

• Para bancos de dados IBM Db2 (anteriormente Db2 para LUW) que replicam dados UTF-16, é necessário um banco de dados Unicode. Outras codificações de byte duplo não são explicitamente suportadas.

• Para colunas do tipo ENUM de origem, o Esquema Automático aplica char como o tipo de destino em MySQL. Use TYPEMAP, se necessário, para usar VARCHAR.

• AUTOSCHEMAOPTIONS TYPEMAP deve ser especificado com base no nome da coluna de origem e não no nome do tipo de dados de origem para colunas numéricas/decimais de origem com precisão inferior a 8.

• AUTOSCHEMAOPTIONS TYPEMAP deve ser especificado com base no nome da coluna de origem e não no nome do tipo de dados de origem para colunas de origem dos tipos:
  • Colunas do tipo Caract/Varchar com comprimento > 4000.
  • TEMPO(p)
  • TEMPO(p) SEM FUSO DE TEMPO
  • TEMPO(p) COM FUSO DE TEMPO
  • TIMESTAMP(p)
  • TIMESTAMP(p) SEM TEMPO
  • TIMESTAMP(p) WITH TIME ZONE
  • Todas as variantes INTERVAL
  • Colunas do tipo Vetor do SQL Server de Origem

• O Esquema Automático não suporta o uso da cláusula COLMAP com nomes de coluna contendo aspas duplas dentro deles. O nome da coluna de destino usado em um mapeamento de coluna específico na cláusula COLMAP, que é mapeado para um nome de coluna de origem, não pode ser igual a qualquer outro nome de coluna na tabela de origem.

• Poucas mensagens de erro do Esquema Automático podem aparecer no ASCII quando a configuração regional do sistema em que GoldenGate está em execução é um conjunto de caracteres multibyte, como chinês ou japonês (por exemplo, zh_CN.UTF-8).

• No destino do SQL Server, para qualquer tipo de origem datetime/timestamp sem segundos fracionais, você deve especificar AUTOSCHEMAOPTIONS TYPEMAP para o tipo de origem correspondente (ou nome da coluna) com datetime2(0) como o tipo de destino de substituição especificado.

• No destino z/OS Db2, o Esquema Automático não suporta a eliminação de várias colunas usando um único ALTER TABLE DDL. Você pode executar novamente o DDL com falha que foi reportado no erro do OGG (do arquivo de relatório do Replicat) e reiniciar o Replicat.

• No destino SQLServer, o Esquema Automático não detecta/executa corretamente a modificação da coluna de VARCHAR(n) para TEXT ou VARCHAR(max).

• AUTOSCHEMAOPTIONS TYPEMAP não funciona para especificações de tipo de destino:
  • NÚMERO (p,s)
  • NUMÉRICO (p,s)
  • DECIMAL(p,s)
  • TIMESTAMP(p) com fuso horário
  • TIME(p) com fuso horário: A solução alternativa é usar TIME(p) como a especificação do nome do tipo de destino em vez de TIME(p) sem fuso horário porque ambos são semanticamente equivalentes.
  • TIMESTAMP(p) sem fuso horário Como solução alternativa, você pode usar TIMESTAMP(p) como a especificação do nome do tipo de destino em vez de TIMESTAMP(p) sem fuso horário porque ambos são semanticamente equivalentes.
  • Varbinário (máx.)
  • Varchar(max): A solução alternativa é usar CLOB como especificação do nome do tipo de destino em vez de varchar(max)
  • Nvarchar(max): A solução alternativa é usar NCLOB como a especificação do nome do tipo de destino em vez de nvarchar(max)

• No destino SQLServer, a especificação da dimensão Vector na especificação do tipo é obrigatória. A especificação do tipo base (como float16 ou float32) é opcional.

• Para colunas de origem SQLServer do tipo DATETIME, o Esquema Automático não pode diferenciar DATETIME de DATETIME2(3). Portanto, ao usar a cláusula TYPEMAP explícita, você deve configurar um TYPEMAP baseado em nome de coluna de origem em vez de um mapa de tipo baseado em nome de tipo de origem.

• Para as colunas NCHAR de destino DB2AS400, o Esquema Automático não detecta corretamente as modificações necessárias no tipo de coluna.

• Se qualquer banco de dados Oracle GoldenGate Delivery no PostgreSQL (ou compatível com PostgreSQL) estiver configurado para usar o driver ODBC nativo do PostgreSQL, o Esquema Automático não detectará os casos Alterar Coluna Modificar Tabela corretamente.

• Para o IBM Db2 para i, é possível que um job apareça para "parar" e não faça nenhum progresso. Por exemplo, isso é mais provável na replicação quando o Esquema Automático é usado se a operação solicitada puder causar um problema de truncamento de dados. Dependendo de como o sistema IBM i está configurado, o job de replicação pode ser colocado em um estado de Espera de Mensagem (MSGW) em que o sistema está aguardando que um usuário forneça qual ação o job deve executar para resolver o problema específico. Atualmente, não há como GoldenGate abordar isso diretamente, e você deve lidar com isso no lado IBM i.

• Para os tipos de coluna Snowflake de origem TIMESTAMP_NTZ(p), TIMESTAMP_LTZ(p) ou TIMESTAMP_TZ(p), o Esquema Automático os mapeia para as colunas de timestamp correspondentes, mas com uma precisão de data e hora igual a 0. Para evitar o truncamento de dados dos segundos fracionais, use AUTOSCHEMAOPTIONS TYPEMAP para selecionar o tipo necessário no destino.

• O Esquema Automático não diferencia os tipos de coluna JSON e JSONB de origem PostgreSQL. Use AUTOSCHEMAOPTIONS TYPEMAP com base no nome da coluna de origem em vez do tipo de coluna para os tipos JSONB de origem PostgreSQL.

• O Esquema Automático não diferencia entre os tipos de coluna numérica ilimitada de origem PostgreSQL (numérica sem precisão e escala) e numérica de origem PostgreSQL (1000, 100). Você deve usar AUTOSCHEMAOPTIONS TYPEMAP com base no nome da coluna de origem em vez do tipo de coluna para colunas do tipo numérico (1000.100) de origem PostgreSQL.

• Para os tipos de coluna de origem do Snowflake ARRAY, GEOGRAPHY e GEOMETRY, o Esquema Automático é mapeado para o tipo JSON (se suportado) ou o tipo CLOB no destino. Para selecionar outro tipo no destino, os usuários devem usar o AUTOSCHEMAOPTIONS TYPEMAP.

• A(s) mensagem(ns) informativa(s), contendo a parte de especificações com base no nome da coluna de origem de AUTOSCHEMAOPTIONS TYPEMAP não é(são) exibida(s) corretamente.