Preparar Tabelas para Processamento

Você deve executar as tarefas a seguir para preparar suas tabelas para uso em um ambiente Oracle GoldenGate para Db2 LUW.

Desativando Triggers e Constraints em Cascata

Desative acionadores, restrições de exclusão em cascata e restrições de atualização em cascata nas tabelas LUW Db2 de destino. O Oracle GoldenGate replica a DML resultante de um trigger ou restrição em cascata. Se o mesmo trigger ou constraint for ativado na tabela de destino, ele se tornará redundante por causa da versão replicada, e o banco de dados retornará um erro. Considere o exemplo a seguir, no qual as tabelas de origem são emp_src e salary_src e as tabelas de destino são emp_targ e salary_targ.

Uma exclusão é emitida para emp_src.
Ela coloca uma exclusão em cascata em salary_src.
O Oracle GoldenGate envia as duas exclusões ao destino.
A exclusão pai chega primeiro e é aplicada ao emp_targ.
A exclusão pai coloca uma exclusão em cascata em salary_targ.
A exclusão em cascata de salary_src é aplicada a salary_targ.
Não é possível localizar a linha porque ela já foi excluída na etapa 5.

Garantindo a Exclusividade da Linha para Tabelas

O Oracle GoldenGate requer alguma forma de identificador de linha exclusivo nas tabelas de origem e destino para localizar as linhas de destino corretas para atualizações e exclusões replicadas.

A menos que uma cláusula KEYCOLS seja usada na instrução TABLE ou MAP, o Oracle GoldenGate seleciona um identificador de linha a ser usado na seguinte ordem de prioridade:

Chave principal
Primeira chave exclusiva alfanumérica que não contém um timestamp ou uma coluna calculada não materializada.
Se nenhum dos tipos de chave anteriores existir (mesmo que possa haver outros tipos de chaves definidos na tabela), o Oracle GoldenGate construirá uma pseudochave de todas as colunas que o banco de dados permite ser usado em uma chave exclusiva, excluindo as que não são suportadas pelo Oracle GoldenGate em uma chave ou as excluídas da configuração do Oracle GoldenGate.

Observação: Se houver outras chaves não utilizáveis em uma tabela ou se não houver chaves na tabela, o Oracle GoldenGate registrará uma mensagem apropriada no arquivo de relatório. A construção de uma chave de todas as colunas impede o desempenho do Oracle GoldenGate no sistema de origem. No destino, essa chave faz com que o Replicat use uma cláusula WHERE maior e menos eficiente.
Se uma tabela não tiver uma chave apropriada, ou se você preferir que a(s) chave(s) existente(s) não seja(m) usada(s), poderá definir uma chave substituta, se a tabela tiver colunas que sempre contenham valores exclusivos. Você define essa chave substituta incluindo uma cláusula KEYCOLS no parâmetro Extract TABLE e no parâmetro Replicat MAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar. Consulte TABLE \| MAP na Referência de Parâmetros e Funções do Oracle GoldenGate.

Usando KEYCOLS para Especificar uma Chave Personalizada

Se uma tabela não tiver um dos tipos anteriores de identificadores de linha, ou se você preferir que esses identificadores não sejam usados, poderá definir uma chave substituta se a tabela tiver colunas que sempre contenham valores exclusivos. Você define essa chave substituta incluindo uma cláusula KEYCOLS no parâmetro Extract TABLE e no parâmetro Replicat MAP. A chave especificada substituirá qualquer chave primária ou exclusiva existente que o Oracle GoldenGate localizar.

Impedindo Alterações Principais

Não adicione colunas a uma chave depois que o Oracle GoldenGate começar a extrair dados da tabela. Essa regra se aplica a uma chave primária, exclusiva, KEYCOLS ou all-column key. Db2 O LUW não fornece uma imagem anterior para colunas que são adicionadas a uma tabela. Se alguma coluna em uma chave for atualizada na origem, o Oracle GoldenGate precisará de uma imagem anterior para comparar com os valores atuais na tabela de destino quando replicar a atualização.

Mantendo Tabelas de Consulta Materializadas

Para manter a paridade entre as tabelas de consulta materializada (MQT) de origem e de destino, replique as tabelas base, mas não as MQTs. O banco de dados de destino mantém os MQTs com base nas alterações que o Replicat aplica às tabelas base.

Estas são as regras para configurar estas tabelas:

Inclua as tabelas base em suas instruções TABLE e MAP.
Não inclua MQTs nas instruções TABLE e MAP.
Curingas podem ser usados em instruções TABLE e MAP, mesmo que possam resolver nomes MQT junto com nomes de tabela regulares. O Oracle GoldenGate exclui automaticamente MQTs de listas de tabelas com curingas. No entanto, qualquer MQT explicitamente listado em uma instrução Extract TABLE por nome fará com que a Extract seja encerrada.

Criando uma Tabela Temporal

Tabela temporal é uma tabela que mantém o histórico de seus dados e o período de tempo em que seus dados são válidos. As tabelas temporais são usadas no Oracle GoldenGate para controlar todas as linhas antigas que são excluídas ou atualizadas na tabela. As tabelas temporais também são usadas para manter a validade de negócios de suas linhas e dados. Por exemplo, o Oracle GoldenGate mantém um controle do período durante o qual uma linha é válida. Há três tipos de tabelas temporais: período do sistema, período do aplicativo e bitemporal.

Converter em Tabela Temporal

Você pode converter uma tabela já existente em uma tabela temporal, o que altera a estrutura da tabela. Esta seção descreve como a estrutura das tabelas é alterada. O exemplo de tabela existente a seguir é convertido em todos os três tipos de tabelas temporais nos exemplos desta seção:

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

Exemplo 1 Convertendo uma tabela existente em tabela temporal de período do sistema

Você converte a tabela existente de amostra em uma tabela temporal de período do sistema adicionando colunas SYSTEM_PERIOD, transaction id e período SYSTEM_TIME como no seguinte:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

Em seguida, você cria uma tabela de histórico para a nova tabela temporal usando um dos dois métodos a seguir:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

A cláusula RESTRICT ON DROP não permitirá que a tabela de histórico seja eliminada ao eliminar a tabela temporal de período do sistema. Caso contrário, a tabela de histórico será eliminada implicitamente durante a eliminação de sua tabela temporal associada. Você pode criar uma tabela de histórico sem RESTRICT ON DROP. Não é possível eliminar explicitamente uma tabela de histórico.

Não use a cláusula GENERATED ALWAYS ao criar uma tabela de histórico. A chave primária da tabela temporal período do sistema também não se aplica aqui, pois pode haver muitas atualizações para uma determinada linha na tabela base, o que aciona muitas inserções na tabela de histórico para o mesmo conjunto de chaves primárias. Além disso, a estrutura de uma tabela de histórico deve ser exatamente igual à tabela temporal de período do sistema associada. A tabela de histórico deve ter o mesmo número e a mesma ordem de colunas da tabela temporal de período do sistema. As colunas da tabela de histórico não podem ser adicionadas, eliminadas ou alteradas explicitamente. Associe uma tabela temporal de período do sistema à sua tabela de histórico com a seguinte instrução:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

As colunas GENERATED ALWAYS da tabela são as que são sempre preenchidas pelo gerenciador de banco de dados para que você não tenha controle sobre essas colunas. O gerenciador de banco de dados preenche essas colunas com base na hora do sistema.

As colunas SYSTEM_PERIOD e transaction id adicionadas extra terão valores padrão para linhas já existentes como no seguinte:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

A tabela de histórico associada é preenchida com as imagens antes de iniciar a atualização da tabela temporal.

Exemplo 2 Convertendo uma tabela existente em uma tabela temporal de período do aplicativo

Você pode converter a tabela existente de amostra em tabela temporal de período do aplicativo adicionando colunas de tempo e um período BUSINESS_TIME da seguinte forma:

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Ao adicionar colunas de tempo, certifique-se de que, ao inserir valores de tempo de validade de negócios das colunas de tempo existentes, a coluna bus_start sempre tenha um valor menor que bus_end porque essas colunas especificam a validade de negócios das linhas.

A nova tabela temporal do período do aplicativo será semelhante a:

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

Exemplo 3 Convertendo uma tabela existente em tabela bitemporal

Você pode converter a tabela existente de amostra em tabela bitemporal adicionando SYSTEM_PERIOD, colunas de tempo juntamente com o período SYSTEM_TIME e BUSINESS_TIME como no seguinte:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Ao adicionar as colunas de tempo, certifique-se de que, ao inserir valores de tempo de validade de negócios de colunas de tempo já existentes, a coluna bus_start sempre tenha um valor menor que bus_end porque essas colunas especificam a validade de negócios das linhas.

Em seguida, você cria uma tabela de histórico para a nova tabela temporal usando um dos dois métodos a seguir:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

A cláusula RESTRICT ON DROP não permitirá que a tabela de histórico seja eliminada ao eliminar a tabela temporal de período do sistema. Caso contrário, a tabela de histórico será eliminada implicitamente durante a eliminação de sua tabela temporal associada. Você pode criar uma tabela de histórico sem RESTRICT ON DROP. Não é possível eliminar explicitamente uma tabela de histórico.

Não use a cláusula GENERATED ALWAYS ao criar uma tabela de histórico. A chave primária da tabela temporal período do sistema também não se aplica aqui, pois pode haver muitas atualizações para uma determinada linha na tabela base, o que aciona muitas inserções na tabela de histórico para o mesmo conjunto de chaves primárias. Além disso, a estrutura de uma tabela de histórico deve ser exatamente igual à tabela temporal de período do sistema associada. A tabela de histórico deve ter o mesmo número e a mesma ordem de colunas da tabela temporal de período do sistema. As colunas da tabela de histórico não podem ser adicionadas, eliminadas ou alteradas explicitamente. Associe uma tabela temporal de período do sistema à sua tabela de histórico com a seguinte instrução:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

As colunas SYSTEM_PERIOD e transaction id adicionadas extra terão valores padrão para linhas já existentes como no seguinte:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

A tabela de histórico associada é preenchida com as imagens antes de iniciar a atualização da tabela temporal.

O período SYSTEM_TIME extra adicionado, o id da transação e as colunas de tempo terão valores padrão para linhas já existentes, como no seguinte:

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

A tabela de histórico é preenchida com as imagens anteriores quando o usuário começa a atualizar a tabela temporal.

Exemplo 4 Replicação em Ambiente Heterogêneo.

Na configuração heterogênea em que não há tabelas temporais no lado de aplicação, você só pode replicar as tabelas de período do sistema e bitemporal, embora não as tabelas de histórico associadas. Ao executar a replicação nessa situação, você deve cuidar do valor das colunas SYSTEM_PERIOD e do id da transação. Essas colunas terão alguns valores que o banco de dados de destino pode não suportar. Você deve primeiro usar as funções de conversão de mapas para converter esses valores no formato suportado pelo banco de dados de destino e, em seguida, mapear as colunas adequadamente.

Por exemplo, MySQL tem uma faixa de DATETIME de 1000-01-01 00:00:00.000000 a 9999-12-31 23:59:59.999999. Não é possível replicar um valor de timestamp 0001-01-01-00.00.00.000000000000 para MySQL. Para replicar esses valores, você deve converter esse valor no valor 1000-01-01 00:00:00.000000 MySQL DATETIME e, em seguida, mapear as colunas. Se você tiver a seguinte linha na tabela de períodos do sistema policy_info:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Para replicar a linha em MySQL, você usaria a função colmap():

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

Replicando com Tabelas Temporais

Você pode escolher um dos seguintes métodos para replicar um período do sistema ou uma tabela temporal bitemporal da seguinte forma:

Você só pode replicar uma tabela temporal para outra tabela temporal; esse é o comportamento padrão. O Oracle GoldenGate não replicará as colunas do período SYSTEM_TIME e do id da transação porque elas são colunas geradas automaticamente no lado de aplicação. O gerenciador de banco de dados preenche as colunas na tabela temporal de destino usando a hora do relógio do sistema e com os valores padrão. Você pode preservar os valores originais dessas colunas e, em seguida, usar qualquer uma das seguintes opções:
- Adicione colunas de timestamp extra na tabela temporal de destino e mapeie as colunas adequadamente. As colunas extras são adicionadas automaticamente à tabela de histórico associada.
- Use uma tabela não temporal no lado de aplicação e mapeie as colunas adequadamente. Neste cenário, você não poderá manter a tabela de histórico.
- Em uma configuração heterogênea em que a origem é Db2 LUW e o destino é um banco de dados diferente, você pode ignorar as colunas geradas automaticamente ou usar uma função de conversão de coluna apropriada para converter o valor das colunas no formato que o banco de dados de destino suporta e mapeá-las para as colunas de destino de acordo.
Ou
Você pode replicar uma tabela temporal, com a tabela de histórico associada, para uma tabela temporal e uma tabela de histórico, respectivamente. Em seguida, especifique o parâmetro de replicação, DBOPTIONS SUPPRESSTEMPORALUPDATES. Especifique a tabela temporal e a tabela de histórico a serem capturadas no arquivo de parâmetros do Extract. O Oracle GoldenGate replica o período SYSTEM_TIME e o valor das colunas de id de transações. Certifique-se de que a instância do banco de dados tenha a permissão de execução para executar o procedimento armazenado no lado de aplicação.

O Oracle GoldenGate não pode detectar e resolver conflitos ao usar a replicação padrão, pois o período SYSTEM_TIME e as colunas transactionstart id permanecem gerados automaticamente. Essas colunas não podem ser especificadas na cláusula set e where. Se você usar o parâmetro SUPPRESSTEMPORALUPDATES, o Oracle GoldenGate suportará CDR.