Utilizar o IBM Db2 para Linux, Unix e o banco de dados do Amazon RDS (Db2 LUW) como origem para o AWS DMS

Defina o banco de dados para ser recuperável, que o AWS DMS exige para captura de alterações. Um banco de dados será recuperável se um ou os dois parâmetros de configuração de banco de dados LOGARCHMETH1 e LOGARCHMETH2 estiverem definidos como ON.

Se o banco de dados for recuperável, o AWS DMS poderá acessar o ARCHIVE LOG do Db2, se necessário.

Verifique se os logs de transações do DB2 estão disponíveis, com um período de retenção suficiente para serem processados pelo AWS DMS.

O DB2 requer autorização de SYSADM ou de DBADM para extrair registros de log de transações. Conceda à conta do usuário as seguintes permissões:

Ao utilizar o IBM DB2 for LUW versão 9.7 como origem, defina o atributo de conexão adicional (ECA), CurrentLSN, da seguinte forma:

CurrentLSN=LSN em que LSN especifica um número de sequência de log (LSN) em que você deseja que a replicação seja iniciada. Ou, CurrentLSN=scan.

Ao usar o Amazon RDS para Db2 LUW como origem, garanta que os logs de arquivamento estejam disponíveis no AWS DMS. Como os bancos de dados Db2 gerenciados pela AWS purgam os logs de arquivamento assim que possível, é necessário aumentar o período em que os logs permanecem disponíveis. Por exemplo, para aumentar a retenção de log para 24 horas, execute o comando a seguir:

db2 "call rdsadmin.set_archive_log_retention( ?, 'TESTDB', '24')"

Para ter mais informações sobre os procedimentos do Amazon RDS para Db2 LUW, consulte Referência de procedimentos armazenados do Amazon RDS para Db2 no Guia do usuário do Amazon Relational Database Service.

Quando uma tabela com várias partições é truncada, o número de eventos de DDL mostrado no console do AWS DMS é igual ao número de partições. Isso ocorre porque o Db2 LUW registra um DDL separado para cada partição.

As ações de DDL a seguir não são compatíveis em tabelas particionadas:

O AWS DMS não é compatível com uma migração de replicação contínua de uma instância em espera de recuperação de desastres de alta disponibilidade (HADR) do DB2. O modo de espera é inacessível.

O tipo de dados DECFLOAT não é compatível. Consequentemente, alterações nas colunas DECFLOAT são ignoradas durante a replicação contínua.

A instrução RENAME COLUMN não é compatível.

Ao realizar atualizações nas tabelas de Multi-Dimensional Clustering (MDC - Clusterização multi-dimensional), cada atualização é mostrada no console do AWS DMS como INSERT + DELETE.

Quando a configuração da tarefa Incluir colunas LOB na replicação não está ativada, qualquer tabela que tenha com colunas LOB é suspensa durante a replicação contínua.

Nas versões 10.5 e superior do Db2 LUW, as colunas de strings de comprimento variável com dados armazenados fora da linha são ignoradas. Essa limitação se aplica somente a tabelas criadas com tamanho de linha estendido para colunas com tipos de dados, como VARCHAR e VARGRAPHIC. Para contornar essa limitação, mova a tabela para um espaço de tabela com um tamanho de página maior. Para obter mais informações, consulte O que posso fazer se eu quiser alterar o tamanho da página dos espaços de tabela do DB2.

Para a replicação contínua, o DMS não é compatível com a migração de dados carregados em nível da página pelo utilitário DB2 LOAD. Em vez disso, utilize o utilitário IMPORT que utiliza inserções SQL. Para obter mais informações, consulte diferenças entre os utilitários de importação e de carregamento.

Enquanto uma tarefa de replicação está em execução, o DMS captura DDLs CREATE TABLE somente se as tabelas tiverem sido criadas com o atributo DATA CAPTURE CHANGE.

O DMS apresenta as seguintes limitações ao usar o Db2 Database Partition Feature (DPF):

Para replicação contínua (CDC), se você planejar iniciar a replicação a partir de um timestamp específico, defina o atributo de conexão StartFromContext com o timestamp requerido.

Atualmente, o DMS não é compatível com o Db2 pureScale Feature, uma extensão do DB2 LUW que é possível utilizar para escalar a solução de banco de dados.