Propagando Alterações de Evolução da Tabela da Origem para o Destino

O Oracle GoldenGate replica as alterações da tabela, incluindo os eventos de tabela ausentes. Quando AUTOSCHEMA está ativado, o evento de tabela ausente é detectado durante o mapeamento da tabela, mais especificamente, durante o processamento do Registro de Definição de Tabela (TDR) do arquivo de trilha.

As etapas a seguir explicam esse workflow:

  1. O processo Replicat tenta resolver os metadados da tabela de destino. Se a resolução de metadados falhar com o erro object not found, isso indicará que a tabela de destino não existe no banco de dados de destino.

  2. Se a funcionalidade AUTOSCHEMA estiver ativada, a instrução CREATE TABLE, para a tabela de destino ausente, será gerada com base nos metadados de origem no registro TDR.

    1. O modelo de mapeamento de tipo de dados padrão, com base no tipo de banco de dados de destino, é usado ao selecionar tipos de dados adequados para as colunas da tabela de destino.

    2. A instrução CREATE TABLE é gerada com base na sintaxe SQL do banco de dados de destino, considerando as preferências do usuário, se especificadas. Você pode especificar as seguintes preferências:

      1. Nome da tabela de destino conforme especificado na cláusula TARGET do conjunto de estatísticas MAP correspondente no arquivo de parâmetros de replicação.

      2. Por padrão, os nomes das colunas da tabela de destino são iguais aos das colunas da tabela de origem; no entanto, você pode selecionar nomes diferentes usando COLMAP.

      3. Você pode selecionar nomes de tipos de dados personalizados (disponíveis no banco de dados de destino) para nomes de tipos de dados de origem específicos (ou colunas de origem) usando TYPEMAP. Adequado nos casos em que os tipos de dados suportados (e seus limites) podem diferir entre os bancos de dados de origem e de destino.

  3. A criação de novas tabelas usando as instruções CREATE TABLE geradas é tratada automaticamente pelo processo de replicação, desde que a operação atenda aos critérios de filtragem configurados (como regras INCLUDE/EXCLUDE). Se ocorrer um problema temporário, o sistema tentará aplicar a alteração várias vezes, dependendo das configurações de repetição configuradas. Se a alteração ainda não puder ser aplicada após essas novas tentativas, a replicação será interrompida e um erro será reportado.

Propagando a Evolução da Coluna nas Tabelas de Destino

A coluna ausente no evento da tabela de destino foi detectada durante o mapeamento da tabela. Mais especificamente, ao processar o registro de definição de tabela (TDR).

  1. O processo Replicat tenta resolver os metadados da tabela de destino. Nesse caso, como a tabela de destino existe, a resolução de metadados não falha, mas uma estrutura de definição de tabela de destino válida é retornada.

  2. Se o AUTOSCHEMA estiver ativado, os metadados na definição da tabela de destino serão comparados com os metadados da tabela de origem no registro TDR de entrada. Isso serve para detectar quaisquer colunas adicionais nos metadados da tabela de origem no registro de TDR que não estejam disponíveis na definição da tabela de destino, que foram recuperadas na etapa anterior.

    1. O modelo de mapeamento de tipo de dados padrão de acordo com o tipo de banco de dados de destino é usado ao escolher os tipos de dados mais adequados para as novas colunas da tabela de destino.

    2. A instrução ALTER TABLE ADD COLUMN é gerada com base na sintaxe SQL do banco de dados de destino.

      Você pode escolher nomes de tipos de dados personalizados (disponíveis no banco de dados de destino) para nomes de tipos de dados de origem específicos (ou colunas de origem). Adequado nos casos em que os tipos de dados suportados (e seus limites) podem diferir entre os bancos de dados de origem e de destino.

  3. Se houver essas colunas adicionais identificadas, a instrução ALTER TABLE ADD COLUMN, para a tabela de destino existente, será gerada com base nos metadados de origem no registro de TDR (mais especificamente as colunas adicionais no registro de TDR).

A execução do ALTER TABLE DDL gerado é executada pela infraestrutura de replicação DDL existente somente quando o DDL correspondente passa nos critérios de filetring DDL (critérios DDL INCLUDE/EXCLUDE com opções OBJTYPE/OPTYPE/OBJNAME). Como a infraestrutura de replicação de DDL também é usada para AUTOSCHEMA, a lógica de repetição em códigos de erro não fatais também é usada. A lógica de repetição também tem um número configurável de repetições e um atraso entre repetições. Se a execução de DDL gerada falhar mesmo após as novas tentativas, o processo Replicat será encerrado.