Solução de problemas de tarefas de migração no AWS Database Migration Service - AWS Database Migration Service
As tarefas de migração são executadas lentamenteA barra de status da tarefa não se moveA tarefa foi concluída, mas nada foi migradoChaves estrangeiras e índices secundários ausentesAWS DMSnão cria CloudWatch registrosOcorrem problemas com a conexão com o Amazon RDSOcorrem problemas de redeA CDC fica paralisada após carga máximaErros de violação de chave primária ocorrem ao reiniciar uma tarefaFalha na carga inicial de um esquemaFalha em tarefas com erro desconhecidoTarefa recomeça o carregamento de tabelas desde o inícioO número de tabelas por tarefa causa problemasFalha nas tarefas quando a chave primária é criada na coluna LOBRegistros duplicados ocorrem na tabela de destino sem chave primáriaOs endpoints de origem ficam no intervalo IP reservadoOs timestamps são distorcidos em consultas do Amazon AthenaSolução de problemas com o OracleSolução de problemas com o MySQLSolução de problemas com o PostgreSQLSolução de problemas com o Microsoft SQL ServerSolução de problemas com o Amazon RedshiftSolução de problemas com o MySQL do Amazon Aurora Solução de problemas com o SAP ASESolução de problemas com o IBM Db2

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas de tarefas de migração no AWS Database Migration Service

A seguir é possível encontrar tópicos sobre solução de problemas com o AWS Database Migration Service (AWS DMS). Esses tópicos podem ajudar a solucionar problemas comuns utilizando o AWS DMS e os bancos de dados de endpoints selecionados.

Se você abriu um caso de AWS Support, o engenheiro de suporte poderá identificar um possível problema com uma das configurações do banco de dados de endpoint. O engenheiro também poderá pedir que você execute um script de apoio para retornar informações de diagnóstico sobre o banco de dados. Para obter detalhes sobre como baixar, executar e fazer upload das informações de diagnóstico desse tipo de script de apoio, consulte Como trabalhar com scripts de suporte a diagnóstico no AWS DMS.

Para fins de solução de problemas, AWS DMS coleta arquivos de rastreamento e despejo na instância de replicação. Você pode fornecer esses arquivos ao AWS Support caso ocorra um problema que exija solução de problemas. Por padrão, o DMS limpa arquivos de rastreamento e despejo com mais de trinta dias. Para desativar a coleta de arquivos de rastreamento e despejo, abra um caso com o AWS Support.

Tópicos

As tarefas de migração são executadas lentamente

Diversos problemas podem fazer com que uma tarefa de migração seja executada lentamente ou fazer com que tarefas subsequentes sejam executadas mais lentamente que a tarefa inicial.

O motivo mais comum da lentidão da execução de uma tarefa de migração é que há recursos inadequados alocados à instância de replicação do AWS DMSDMS. Para verificar se a instância tem recursos suficientes para as tarefas que você está executando nela, confira o uso de CPU, de memória, de troca de arquivos e de IOPS. Por exemplo, várias tarefas com o Amazon Redshift como endpoint têm uso intensivo de E/S. É possível aumentar a IOPS da instância de replicação ou separar as tarefas em várias instâncias de replicação para obter uma migração mais eficaz.

Para obter mais informações sobre como determinar o tamanho da instância de replicação, consulte Seleção do melhor tamanho para uma instância de replicação.

É possível aumentar a velocidade de um carregamento de migração inicial fazendo o seguinte:

  • Se o destino for uma instância de banco de dados Amazon RDS, verifique se multi-AZ não está ativado para a instância de banco de dados de destino.

  • Desligue todos os backups automáticos ou os registros em log no banco de dados de destino durante a carga e religue-os assim que a migração for concluída.

  • Se o recurso estiver disponível no destino, utilize IOPS provisionadas.

  • Se os dados de migração contiverem LOBs, verifique se a tarefa está otimizada para a migração de LOB. Para obter mais informações sobre a otimização de LOBs, consulte Configurações de tarefa de metadados de destino.

A barra de status da tarefa não se move

A barra de status de tarefa fornece uma estimativa do andamento da tarefa. A qualidade dessa estimativa depende da qualidade das estatísticas de tabela do banco de dados de origem: quanto melhores as estatísticas de tabela, mais precisa a estimativa.

Para uma tarefa com apenas uma tabela que não tem nenhuma estatística de linhas estimada, o AWS DMS não pode fornecer nenhum tipo de estimativa de porcentagem de conclusão. Nesse caso, utilize o estado da tarefa e a indicação das linhas carregadas para confirmar se a tarefa realmente está sendo executada e progredindo.

A tarefa foi concluída, mas nada foi migrado

Faça o seguinte se nada tiver sido migrado após a conclusão da tarefa.

  • Verifique se o usuário que criou o endpoint tem acesso de leitura à tabela que você pretende migrar.

  • Verifique se o objeto que você deseja migrar é uma tabela. Se for uma visualização, atualize os mapeamentos da tabela e especifique o localizador de objetos como “visualização” ou “tudo”. Para ter mais informações, consulte Especificar a seleção de tabelas e as regras de transformação no console.

Chaves estrangeiras e índices secundários ausentes

O AWS DMS cria tabelas, chaves primárias e, em alguns casos, índices exclusivos, mas não cria nenhum outro objeto que não seja necessário para migrar os dados da origem de forma eficiente. Por exemplo, ele não cria índices secundários, restrições de chave não primária ou padrões de dados.

Para migrar objetos secundários do seu banco de dados, utilize as ferramentas nativas dele se estiver migrando para o mesmo mecanismo de banco de dados que o seu banco de dados de origem. Utilize o AWS Schema Conversion Tool (AWS SCT) se estiver migrando para um mecanismo de banco de dados diferente do usado pelo banco de dados de origem para migrar objetos secundários.

AWS DMSnão cria CloudWatch registros

Se sua tarefa de replicação não criar CloudWatch registros, verifique se sua conta tem a dms-cloudwatch-logs-role função. Se esse perfil não estiver presente, faça o seguinte para criá-lo:

  1. Faça login no AWS Management Console e abra o console do IAM em https://console.aws.amazon.com/iam/.

  2. Escolha a guia Perfis. Selecione Criar perfil.

  3. Na seção Selecionar tipo de entidade confiável, escolha AWS service (Serviço da AWS).

  4. Na seção Escolher um caso de uso, escolha DMS.

  5. Escolha Próximo: permissões.

  6. Entre AmazonDMSCloudWatchLogsRole no campo de pesquisa e marque a caixa ao lado do CloudWatchLogsRoleAmazonDMS. Isso concede AWS DMS permissões de acesso CloudWatch.

  7. Escolha Próximo: etiquetas.

  8. Escolha Próximo: revisar.

  9. Insira dms-cloudwatch-logs-role em Nome do perfil. Esse nome não diferencia maiúsculas de minúsculas.

  10. Selecione Criar perfil.

Ocorrem problemas com a conexão com o Amazon RDS

Pode haver vários motivos porque você não pode se conectar a uma instância de banco de dados Amazon RDS definida como origem ou destino. Seguem alguns itens a serem verificados:

  • Verifique se a combinação do nome do usuário e da senha está correta.

  • Verifique se o valor do endpoint mostrado no console do Amazon RDS para a instância é o mesmo do identificador do endpoint que você utilizou para criar o endpoint do AWS DMS.

  • Verifique se o valor da porta mostrado no console do Amazon RDS para a instância é o mesmo da porta atribuída ao endpoint do AWS DMS.

  • Verifique se o grupo de segurança atribuído à instância de banco de dados Amazon RDS permite conexões da instância de replicação do AWS DMS.

  • Se a instância de replicação do AWS DMS e a instância de banco de dados Amazon RDS não estiverem na mesma nuvem privada virtual (VPC), verifique se a instância de banco de dados é publicamente acessível.

Mensagem de erro: string de conexão de thread incorreta: valor de thread incorreto 0

Esse erro costuma ocorrer quando você está testando a conexão a um endpoint. Esse erro indica que há um erro na string de conexão. Um exemplo é um espaço após o endereço IP do host. Outro é um caractere inválido copiado na string de conexão.

Ocorrem problemas de rede

O problema mais comum de rede envolve o grupo de segurança da VPC usado pela instância de replicação do AWS DMS. Por padrão, esse security group tem regras que permitem a saída para 0.0.0.0/0 em todas as portas. Em muitos casos, você modifica esse grupo de segurança ou utiliza o seu próprio grupo de segurança. Nesse caso, no mínimo, verifique se você fornece saída aos endpoints de origem e de destino nas respectivas portas de banco de dados.

Outros problemas relacionados à configuração podem incluir o seguinte:

  • A instância de replicação e os endpoints de origem e de destino na mesma VPC: o grupo de segurança utilizado pelos endpoints deve permitir a entrada na porta do banco de dados da instância de replicação. Verifique se o grupo de segurança utilizado pela instância de replicação tem entrada para os endpoints. Ou crie uma regra no grupo de segurança utilizado pelos endpoints que permita acesso ao endereço IP privado da instância de replicação.

  • O endpoint de origem está fora da VPC utilizada pela instância de replicação (utilizando um gateway da Internet): o grupo de segurança da VPC deve incluir regras de roteamento que enviam o tráfego não destinado à VPC para o gateway da Internet. Nessa configuração, a conexão ao endpoint parecerá vir do endereço IP público na instância de replicação.

  • O endpoint de origem está fora da VPC utilizada pela instância de replicação (utilizando um gateway NAT): é possível configurar um gateway de conversão de endereços de rede (NAT) utilizando um único endereço IP elástico associado a uma única interface de rede elástica. Esse gateway NAT recebe um identificador NAT (nat-#####).

    Em alguns casos, a VPC inclui uma rota padrão para esse gateway NAT em vez do gateway da Internet. Nesses casos, a instância de replicação parece entrar em contato com o endpoint do banco de dados utilizando o endereço IP público do gateway NAT. Aqui, a entrada no endpoint do banco de dados fora da VPC precisa permitir a entrada do endereço NAT em vez do endereço IP público da instância de replicação.

Para obter informações sobre como utilizar seu próprio servidor de nomes on-premises, consulte Utilização do seu próprio servidor de nomes on-premises.

A CDC fica paralisada após carga máxima

As alterações de replicação lenta ou paralisada podem ocorrer após uma migração de carga máxima, quando várias configurações do AWS DMS entram em conflito entre si.

Por exemplo, suponha que o parâmetro do Modo de preparação da tabela de destino esteja definido como Não fazer nada ou Truncar. Nesse caso, você instruiu o AWS DMS a não fazer nenhuma configuração nas tabelas de destino, incluindo a criação de índices primários e exclusivos. Se você não criou chaves primárias ou exclusivas nas tabelas de destino, o AWS DMS fará uma varredura completa de tabela para cada atualização. Essa abordagem pode afetar significativamente o desempenho.

Erros de violação de chave primária ocorrem ao reiniciar uma tarefa

Esse erro pode ocorrer quando os dados permanecem no banco de dados de destino de uma tarefa de migração anterior. Se o parâmetro Modo de preparação de tabela de destino estiver definido como Não fazer nada, o AWS DMS não fará nenhuma preparação na tabela de destino, incluindo a limpeza de dados inseridos de uma tarefa anterior.

Para reiniciar a tarefa e evitar esses erros, remova as linhas inseridas nas tabelas de destino da execução anterior da tarefa.

Falha na carga inicial de um esquema

Em alguns casos, a carga inicial dos esquemas pode falhar com o erro Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

Nesses casos, a conta de usuário utilizada pelo AWS DMS para se conectar ao endpoint de origem não tem as permissões necessárias.

Falha em tarefas com erro desconhecido

A causa de tipos de erro desconhecidos pode ser variada. No entanto, frequentemente descobrimos que o problema envolve recursos insuficientes alocados para a instância de replicação do AWS DMS.

Para garantir que a instância de replicação tenha recursos suficientes para executar a migração, verifique o uso de CPU, de memória, de troca de arquivos e de IOPS das instâncias. Para obter mais informações sobre monitoramento, consulte Métricas do AWS Database Migration Service.

Tarefa recomeça o carregamento de tabelas desde o início

O AWS DMS reinicia a carga da tabela desde o início quando ainda não concluiu a carga inicial de uma tabela. Quando uma tarefa é reiniciada, o AWS DMS recarrega as tabelas desde o início, quando o carregamento inicial não foi concluído.

O número de tabelas por tarefa causa problemas

Não há limite definido para o número de tabelas por tarefa de replicação. No entanto, é recomendável limitar o número de tabelas em uma tarefa a menos de 60.000, como regra geral. A utilização de recursos pode representar um gargalo quando uma única tarefa utiliza mais de 60.000 tabelas.

Falha nas tarefas quando a chave primária é criada na coluna LOB

No modo FULL LOB ou LIMITED LOB, o AWS DMS não é compatível com replicação de chaves primárias que são tipos de dados LOB.

Inicialmente, o DMS migra uma linha com uma coluna LOB como nula e, posteriormente, atualiza a coluna LOB. Portanto, quando a chave primária é criada em uma coluna LOB, a inserção inicial falha, uma vez que a chave primária não pode ser nula. Como solução alternativa, adicione outra coluna como chave primária e remova a chave primária da coluna LOB.

Registros duplicados ocorrem na tabela de destino sem chave primária

A execução de uma tarefa de carga máxima e CDC pode criar registros duplicados em tabelas de destino sem uma chave primária ou um índice exclusivo. Para evitar a duplicação de registros nas tabelas de destino durante tarefas de carga máxima e CDC, verifique se as tabelas de destino têm uma chave primária ou um índice exclusivo.

Os endpoints de origem ficam no intervalo IP reservado

Se um banco de dados de origem do AWS DMS utilizar um endereço IP dentro do intervalo IP reservado de 192.168.0.0/24, o teste de conexão do endpoint de origem falhará. As etapas a seguir fornecem uma possível solução alternativa:

  1. Localize uma instância do Amazon EC2 que não esteja no intervalo reservado que possa se comunicar com o banco de dados de origem em 192.168.0.0/24.

  2. Instale um proxy socat e execute-o. Por exemplo:

    yum install socat
                
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&

Utilize o endereço IP da instância do Amazon EC2 e a porta do banco de dados fornecida anteriormente para o endpoint do AWS DMS. Verifique se o endpoint tem o grupo de segurança que permite que o AWS DMS acesse a porta do banco de dados. Observe que o proxy precisa estar em execução durante a execução da tarefa do DMS. Dependendo do caso de uso, talvez seja necessário automatizar a configuração do proxy.

Os timestamps são distorcidos em consultas do Amazon Athena

Se os carimbos de data/hora estiverem distorcidos nas consultas do Athena, use a ação ou AWS Management Console a para definir o valor ModifyEndpointdo seu endpoint do Amazon parquetTimestampInMillisecond S3 como. true Para obter mais informações, consulte S3Settings.

Solução de problemas com o Oracle

A seguir, você aprenderá sobre solução de problemas específicos para utilização do AWS DMS com bancos de dados Oracle.

Extrair de dados de exibições

É possível extrair dados uma vez de uma visualização, mas não pode utilizá-la para replicação contínua. Para poder extrair dados de visualizações, adicione o código a seguir à seção Configurações de Endpoint da página de endpoint de origem do Oracle. Ao extrair dados de uma visualização, a visualização aparece como uma tabela no esquema de destino.

"ExposeViews": true

Migração de LOBs do Oracle 12c

AWS DMSpode usar dois métodos para capturar alterações em um banco de dados Oracle, Binary Reader e Oracle LogMiner. Por padrão, AWS DMS usa o Oracle LogMiner para capturar alterações. No entanto, no Oracle 12c, o Oracle LogMiner não oferece suporte a colunas LOB. Para capturar alterações em colunas de LOB no Oracle 12c, utilize o Binary Reader.

Alternando entre Oracle LogMiner e Binary Reader

AWS DMSpode usar dois métodos para capturar alterações em um banco de dados Oracle de origem, Binary Reader e Oracle LogMiner. O Oracle LogMiner é o padrão. Para alternar e usar o Binary Reader para capturar alterações, faça o seguinte:

Como usar o Binary Reader para capturar alterações

  1. Faça login no AWS Management Console e abra o AWS DMS console em https://console.aws.amazon.com/dms/v2/.

  2. Escolha Endpoints.

  3. Escolha o endpoint de origem do Oracle em que deseja utilizar o Binary Reader.

  4. Escolha Modificar.

  5. Escolha Avançado e adicione o código a seguir a Atributos de conexão adicionais.

    
useLogminerReader=N

  6. Utilize uma ferramenta de desenvolvedor do Oracle, como SQL-Plus, para conceder o seguinte privilégio adicional à conta de usuário do AWS DMS utilizada para conectar-se ao endpoint do Oracle.

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

Erro: Oracle CDC stopped 122301 Oracle CDC maximum retry counter exceeded.

Esse erro ocorre quando os logs de arquivo do Oracle necessários foram removidos do servidor antes de o AWS DMS usá-los para capturar alterações. Aumente as políticas de retenção de logs no servidor de banco de dados. Para um banco de dados Amazon RDS, execute o seguinte procedimento para aumentar a retenção de logs. Por exemplo, o seguinte código aumenta a retenção de logs em uma instância de banco de dados Amazon RDS para 24 horas.


exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Adição automática de registro em log complementar a um endpoint de origem Oracle

Por padrão, o AWS DMS fica com o registro suplementar desativado. Para ativar automaticamente o registro suplementar de um endpoint de origem do Oracle, faça o seguinte:

Como adicionar o registro complementar a um endpoint de origem do Oracle

  1. Faça login no AWS Management Console e abra o AWS DMS console em https://console.aws.amazon.com/dms/v2/.

  2. Escolha Endpoints.

  3. Selecione o endpoint de origem do Oracle ao qual deseja adicionar o log complementar.

  4. Escolha Modificar.

  5. Selecione Avançado e adicione o seguinte código à caixa de texto Atributos de conexão extra:

    
addSupplementalLogging=Y

  6. Escolha Modificar.

Alterações de LOB não estão sendo capturadas

No momento, uma tabela deve ter uma chave primária para o AWS DMS capturar alterações de LOB. Se uma tabela que contém LOBs não tem uma chave primária, há várias ações que você pode realizar para capturar alterações de LOB:

  • Adicione uma chave primária à tabela. Isso pode ser tão simples quanto adicionar uma coluna de ID e preenchê-la com uma sequência utilizando um trigger.

  • Crie uma visão materializada da tabela que inclua um ID gerado pelo sistema como a chave primária e migre a visão materializada em vez da tabela.

  • Crie uma espera lógica, adicione uma chave primária à tabela e migre a partir da espera lógica.

Erro: ORA-12899: value too large for column column-name

O erro “ORA-12899: valor muito grande para o nome da coluna” geralmente é causado por dois problemas.

Em um desses problemas, há uma incompatibilidade nos conjuntos de caracteres utilizados pelos bancos de dados de origem e de destino.

Em outro desses problemas, as configurações com compatibilidade ao idioma nacional (NLS) diferem entre os dois bancos de dados. Uma causa comum desse erro é quando o parâmetro NLS_LENGTH_SEMANTICS do banco de dados de origem é definido como CHAR e o parâmetro NLS_LENGTH_SEMANTICS do banco de dados de destino é definido como BYTE.

Tipo de dados NUMBER sendo mal interpretado

O tipo de dados NUMBER do Oracle é convertido em vários tipos de dados do AWS DMS, dependendo da precisão e da escala de NUMBER. Essas conversões estão documentadas aqui Tipos de dados de origem do Oracle. A forma como o tipo NUMBER é convertido também pode ser afetada pela utilização de configurações do endpoint do Oracle de origem. Essas configurações de endpoint são documentadas emConfigurações de endpoint ao usar o Oracle como fonte para AWS DMS.

Registros ausentes durante a carga máxima

Ao executar uma carga máxima, o AWS DMS procura transações abertas no nível do banco de dados e espera que a transação seja confirmada. Por exemplo, com base na configuração da tarefa TransactionConsistencyTimeout=600, o AWS DMS espera por 10 minutos mesmo que a transação aberta esteja em uma tabela não incluída no mapeamento da tabela. Mas se a transação aberta estiver em uma tabela incluída no mapeamento da tabela e a transação não for confirmada a tempo, haverá registros ausentes na tabela de destino.

É possível modificar a configuração da tarefa TransactionConsistencyTimeout e aumentar o tempo de espera quando você sabe que as transações abertas levarão mais tempo para serem confirmadas.

Além disso, observe que o valor padrão da configuração da tarefa FailOnTransactionConsistencyBreached é false. Isso significa que o AWS DMS continua aplicando outras transações, mas as transações abertas são perdidas. Se você quiser que a tarefa falhe quando as transações abertas não forem fechadas a tempo, poderá definir FailOnTransactionConsistencyBreached como true.

Erro de tabela

Table Error aparecerá nas estatísticas da tabela durante a replicação se uma cláusula WHERE não fizer referência a uma coluna de chave primária e o registro em log suplementar não for usado para todas as colunas.

Para corrigir esse problema, ative o registro em log suplementar de todas as colunas da tabela referenciada. Para ter mais informações, consulte Configuração de registro em log suplementar.

Erro: não é possível recuperar IDs de destino de Redo Log arquivados do Oracle

Esse erro ocorre quando a origem Oracle não tem nenhum log de arquivamento gerado ou quando V$ARCHIVED_LOG está vazio. É possível resolver o erro trocando os logs manualmente.

Para um banco de dados Amazon RDS, execute o procedimento a seguir para trocar os arquivos de log. O procedimento switch_logfile não tem parâmetros.

exec rdsadmin.rdsadmin_util.switch_logfile;

Para um banco de dados de origem Oracle autogerenciado, utilize o comando a seguir para forçar uma troca de log.

ALTER SYSTEM SWITCH LOGFILE ;

Avaliação do desempenho de leitura de redo logs ou de arquivamento do Oracle

Se você tiver problemas de desempenho com a origem do Oracle, poderá avaliar o desempenho de leitura dos redo logs ou do arquivamento do Oracle para encontrar maneiras de melhorar o desempenho. Para testar o desempenho de leitura dos redo logs ou de arquivamento, utilize a imagem de máquina da Amazon (AMI) de diagnóstico do AWS DMS.

É possível utilizar a AMI de diagnóstico do AWS DMS para fazer o seguinte:

  • Utilizar o método bFile para avaliar o desempenho do arquivo de redo log.

  • Use o LogMiner método para avaliar o desempenho do arquivo de redo log.

  • Utilizar o método PL/SQL (dbms_lob.read) para avaliar o desempenho do arquivo de redo log.

  • Utilizar Single-thread para avaliar o desempenho de leitura no ASMFile.

  • Utilizar Single-threads para avaliar o desempenho de leitura no ASMFile.

  • Utilize o perfil Direct OS Readfile() Windows ou Pread64 Linux para avaliar o arquivo de redo log.

É possível tomar medidas corretivas com base nos resultados.

Para testar o desempenho de leitura em um arquivo de redo log ou de arquivamento do Oracle

  1. Crie uma instância de diagnóstico da AMI do Amazon EC2 do AWS DMS e conecte-se a ela.

    Para obter mais informações, consulte Como trabalhar com a AMI de diagnóstico do AWS DMS.

  2. Execute o comando awsreplperf.

    $ awsreplperf

    O comando exibe as opções do AWS DMS do utilitário de desempenho de leitura do Oracle.

    0.	Quit
1.	Read using Bfile
2.	Read using LogMiner
3.	Read file PL/SQL (dms_lob.read)
4.	Read ASMFile Single Thread
5.	Read ASMFile Multi Thread
6.	Readfile() function

  3. Selecione uma opção na lista.

  4. Insira as seguintes informações de conexão do banco de dados e do log de arquivamento.

    Oracle user name [system]:
Oracle password:

Oracle connection name [orcllx]:
Connection format hostname:port/instance

Oracle event trace? [N]: 
Default N = No or Y = Yes

Path to redo or archive log file []:

  5. Examine a saída exibida para obter informações relevantes sobre o desempenho de leitura. Por exemplo, o seguinte mostra a saída que pode resultar da seleção da opção número 2, Ler usando LogMiner.

    Saída do utilitário de desempenho de leitura

  6. Para sair do utilitário, insira 0 (zero).

Próximas etapas

  • Quando os resultados mostrarem que a velocidade de leitura está abaixo de um limite aceitável, execute o Script apoio de diagnóstico do Oracle no endpoint, revise as seções Tempo de espera, Perfil de carga e Perfil de E/S. Ajuste qualquer configuração anormal que possa melhorar o desempenho de leitura. Por exemplo, se os arquivos de redo log tiverem até 2 GB, tente aumentar LOG_BUFFER para 200 MB para ajudar a melhorar o desempenho.

  • Analise as Práticas recomendadas do AWS DMS para garantir que a instância, a tarefa e os endpoints de replicação do DMS estejam configurados de forma ideal.

Solução de problemas com o MySQL

A seguir, você aprenderá sobre a solução de problemas específicos para utilização do AWS DMS com bancos de dados MySQL.

Falha na tarefa de CDC para o endpoint da instância de banco de dados Amazon RDS porque o registro em log binário está desativado

Esse problema ocorre com instâncias do banco de dados Amazon RDS porque os backups automáticos estão desabilitados. Para habilitar backups automáticos, configure o período de retenção de backup para um valor diferente de zero.

Conexões a uma instância de destino MySQL são desconectadas durante uma tarefa

Se você tiver uma tarefa com LOBs que está sendo desconectada de um destino MySQL, poderá ver o seguinte tipo de erros no log de tarefas. 

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.
 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

Nesse caso, poderá ser necessário ajustar algumas das configurações da tarefa.

Para resolver o problema em que uma tarefa está sendo desconectada de um destino MySQL, faça o seguinte:

  • Confirme se a sua variável de banco de dados max_allowed_packet está definida como grande o suficiente para reter o maior LOB.

  • Verifique se você tem as seguintes variáveis definidas para ter um valor de tempo limite grande. Sugerimos que você utilize um valor de, pelo menos, 5 minutos para cada uma dessas variáveis.

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

Para obter informações sobre a configuração das variáveis de sistema do MySQL, consulte Variáveis do sistema do servidor na Documentação do MySQL.

Adicionar confirmação automática a um endpoint compatível com MySQL

Como adicionar autocommit a um endpoint de destino compatível com MySQL

  1. Faça login no AWS Management Console e abra o AWS DMS console em https://console.aws.amazon.com/dms/v2/.

  2. Escolha Endpoints.

  3. Escolha o endpoint de destino compatível com MySQL ao qual você deseja adicionar autocommit.

  4. Escolha Modificar.

  5. Selecione Avançado e adicione o seguinte código à caixa de texto Atributos de conexão extra:

    
Initstmt= SET AUTOCOMMIT=1

  6. Escolha Modificar.

Desabilitar chaves externas em um endpoint de destino compatível com MySQL

É possível desativar as verificações de chaves estrangeiras no MySQL adicionando o seguinte a Atributos de conexão adicionais, na seção Avançado do endpoint de destino MySQL, da edição compatível com MySQL do Amazon Aurora ou do MariaDB.

Como desabilitar chaves externas em um endpoint de destino compatível com MySQL

  1. Faça login no AWS Management Console e abra o AWS DMS console em https://console.aws.amazon.com/dms/v2/.

  2. Escolha Endpoints.

  3. Escolha o endpoint de destino MySQL, Aurora MySQL ou MariaDB em que deseja desativar as chaves estrangeiras.

  4. Escolha Modificar.

  5. Selecione Avançado e adicione o seguinte código à caixa de texto Atributos de conexão extra:

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. Escolha Modificar.

Caracteres substituídos por interrogações

A situação que mais causa esse problema é quando os caracteres do endpoint de origem foram codificados por um conjunto de caracteres não compatíveis com o AWS DMS.

Entradas de log de "eventos inválidos"

As entradas "Eventos inválidos" nos logs de migração costumam indicar que houve tentativa de uma operação de linguagem de definição de dados (DDL) incompatível no endpoint do banco de dados de origem. Operações DDL incompatíveis provocam um evento que a instância de replicação não pode ignorar, portanto, um evento inválido é registrado em log.

Para corrigir esse problema, reinicie a tarefa desde o início. Isso recarrega as tabelas e começa a capturar as alterações em um ponto após a emissão da operação DDL incompatível.

Captura de dados de alteração com MySQL 5.5

A captura de dados de alteração (CDC) do AWS DMS de bancos de dados do Amazon RDS compatível com MySQL exige registro em log binário baseado em linhas de imagem completa, o que não é compatível com o MySQL versão 5.5 ou inferior. Para usar o CDC do AWS DMS, você deve atualizar a sua instância de banco de dados Amazon RDS para MySQL versão 5.6.

Aumentar a retenção de log binário para instâncias de banco de dados Amazon RDS

O AWS DMS exige a retenção de arquivos de log binário para a captura de dados de alteração. Para aumentar a retenção de logs em uma instância de banco de dados Amazon RDS, utilize o procedimento a seguir. O exemplo a seguir aumenta a retenção de log binário para 24 horas. 


call mysql.rds_set_configuration('binlog retention hours', 24);

Mensagem de log: Algumas alterações do banco de dados de origem não tiverem impacto ao serem aplicadas ao banco de dados de destino.

Quando o AWS DMS atualiza um valor da coluna do banco de dados MySQL para o valor existente, uma mensagem de zero rows affected é gerada pelo MySQL. Esse comportamento é diferente de outros mecanismos de banco de dados, como o Oracle e o SQL Server. Esses mecanismos atualizam uma linha, mesmo quando o valor de substituição é igual ao atual.

Erro: Identifier too long

O erro a seguir ocorre quando um identificador é muito longo:


TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

Em alguns casos, você configura o AWS DMS para criar as tabelas e as chaves primárias no banco de dados de destino. Nesses casos, atualmente o DMS não utiliza os mesmos nomes para as chaves primárias que foram utilizadas no banco de dados de origem. Em vez disso, o DMS cria o nome da chave primária baseado no nome da tabela. Quando o nome da tabela é longo, o identificador gerado automaticamente pode ser mais longo que os limites permitidos para o MySQL.

Para solucionar esse problema, a abordagem atual é primeiro pré-criar as tabelas e as chaves primárias no banco de dados de destino. Utilize uma tarefa com a configuração de tarefa Modo de preparação da tabela de destino definido como Não fazer nada ou Truncar para preencher as tabelas de destino.

Erro: conjunto de caracteres incompatível causa falha na conversão de dados de campos

O erro a seguir ocorre quando um conjunto de caracteres não suportado causa a falha de uma conversão de dados de campo:


"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)

Verifique os parâmetros do banco de dados relativos a conexões. O comando a seguir pode ser utilizado para definir esses parâmetros:


SHOW VARIABLES LIKE '%char%';

Erro: página de código 1252 para UTF8 [120112] Uma conversão de dados de campo falhou

O erro a seguir pode ocorrer durante uma migração se você tiver caracteres que não sejam da página de código 1252 no banco de dados MySQL de origem.

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)

Como alternativa, você pode usar o atributo de conexão extra CharsetMapping com o endpoint MySQL de origem para especificar o mapeamento de conjuntos de caracteres. Talvez seja necessário reiniciar a tarefa de migração do AWS DMS desde o início se você adicionar essa configuração de endpoint.

Por exemplo, a configuração de endpoint a seguir pode ser utilizada para um endpoint do MySQL de origem em que o conjunto de caracteres de origem é Utf8 ou latin1. 65001 é o identificador da página de código UTF8. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

Índices, chaves estrangeiras ou atualizações ou exclusões em cascata não migrados

O AWS DMS não é compatível com a migração de objetos secundários, como índices e chaves estrangeiras. Para replicar as alterações feitas em tabelas secundárias em uma operação de atualização ou de exclusão em cascata, você precisa ter a restrição de chave estrangeira acionadora ativa na tabela de destino. Para contornar essa limitação, crie a chave estrangeira manualmente na tabela de destino. Crie uma única tarefa para carga máxima e CDC, ou duas tarefas separadas para carga máxima e CDC, conforme descrito a seguir:

Criar uma única tarefa compatível com carga máxima e CDC

Este procedimento descreve como migrar chaves estrangeiras e índices utilizando uma única tarefa de carga máxima e CDC.

Criar uma tarefa de carga máxima e CDC

  1. Crie manualmente as tabelas com chaves estrangeiras e índices no destino para que correspondam às tabelas de origem.

  2. Adicione o ECA a seguir ao endpoint de destino do AWS DMS:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Crie a tarefa do AWS DMS com TargetTablePrepMode definido como DO_NOTHING.

  4. Defina a configuração Stop task after full load completes como StopTaskCachedChangesApplied.

  5. Inicie a tarefa. O AWS DMS interrompe a tarefa automaticamente depois que ela conclui a carga máxima e aplica todas as alterações em cache.

  6. Remova o ECA do SET FOREIGN_KEY_CHECKS adicionado anteriormente.

  7. Retome a tarefa. A tarefa entra na fase de CDC e aplica as alterações em andamento no banco de dados de origem para o de destino.

Crie tarefas de carga máxima e de CDC separadamente

Este procedimento descreve como migrar chaves estrangeiras e índices utilizando tarefas separadas de carga máxima e de CDC.

Criar uma tarefa de carga máxima

  1. Crie manualmente as tabelas com chaves estrangeiras e índices no destino para que correspondam às tabelas de origem.

  2. Adicione o ECA a seguir ao endpoint de destino do AWS DMS:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Crie a tarefa do AWS DMS com o parâmetro TargetTablePrepMode definido como DO_NOTHING e EnableValidation definido como FALSE.

  4. Inicie a tarefa. O AWS DMS interrompe a tarefa automaticamente depois que ela conclui a carga máxima e aplica todas as alterações em cache.

  5. Depois que a tarefa for concluída, anote a hora de início da tarefa de carga máxima em UTC ou o nome e a posição do arquivo de log binário, para iniciar somente a tarefa de CDC. Consulte os logs para obter o timestamp em UTC do horário de início da carga máxima.

Criar uma tarefa somente de CDC

  1. Remova o ECA do SET FOREIGN_KEY_CHECKS definido anteriormente.

  2. Crie a tarefa somente de CDC com a posição de início definida como a hora de início da carga máxima indicada na etapa anterior. Como alternativa, é possível utilizar a posição do log binário registrada na etapa anterior. Defina a configuração TargetTablePrepMode como DO_NOTHING. Para ativar a validação de dados, defina a configuração do EnableValidation como TRUE se necessário.

  3. Inicie a tarefa somente de CDC e monitore os logs para verificar erros.

nota

Essa solução alternativa só se aplica a uma migração de MySQL para MySQL. Não é possível utilizar esse método com o recurso de aplicação em lotes, porque a aplicação em lotes exige que as tabelas de destino não tenham chaves estrangeiras ativas.

Solução de problemas com o PostgreSQL

A seguir, você aprenderá sobre a solução de problemas específicos para utilização do AWS DMS com bancos de dados PostgreSQL.

Tipos de dados JSON que estão sendo truncados

O AWS DMS trata os tipos de dados JSON no PostgreSQL como uma coluna de tipos de dados LOB. Isso significa que a limitação de tamanho de LOB ao utilizar o modo LOB limitado se aplica a dados JSON.

Por exemplo, suponha que o modo LOB limitado esteja definido como 4.096 KB. Nesse caso, qualquer dado JSON maior que 4.096 KB é truncado no limite de 4.096 KB e falha no teste de validação no PostgreSQL.

Por exemplo, as seguintes informações de log mostram o JSON que foi truncado devido à configuração do modo LOB limitado e à falha na validação.

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

Colunas de tipo de dados definido pelo usuário não estão sendo migradas corretamente

Ao replicar de uma origem do PostgreSQL, o AWS DMS cria a tabela de destino com os mesmos tipos de dados para todas as colunas, além das colunas com tipos de dados definidos pelo usuário. Nesses casos, o tipo de dados é criado como "variante de caractere" no destino.

Erro: No schema has been selected to create in

Em alguns casos, você pode ver o erro “SQL_ERROR SqlState: 3F000:7 Message NativeError: ERROR: no schema has selected to create in”.

Esse erro pode ocorrer quando o mapeamento da tabela JSON contém um valor curinga para o esquema, mas o banco de dados de origem não é compatível com esse valor.

Exclusões e atualizações em uma tabela não estão sendo replicadas utilizando a CDC

As operações de exclusão e de atualização durante a captura de dados de alteração (CDC) serão ignoradas se a tabela de origem não tiver uma chave primária. O AWS DMS é compatível com a captura de dados de alteração (CDC) para tabelas do PostgreSQL com chaves primárias.

Se uma tabela não tiver uma chave primária, os logs de gravação antecipada (WAL) não incluirão uma imagem anterior da linha do banco de dados. Nesse caso, o AWS DMS não atualiza a tabela. Para operações de exclusão a serem replicadas, crie uma chave primária na tabela de origem.

Instruções de truncamento não estão sendo propagadas

Ao utilizar a captura de dados de alteração (CDC), as operações TRUNCATE não são compatíveis com o AWS DMS.

Impedir que o PostgreSQL capture DDL

É possível impedir que um endpoint de destino do PostgreSQL capture instruções DDL adicionando a seguinte instrução de Configuração de endpoint.


"CaptureDDLs": "N"

Selecionar o esquema em que os objetos de banco de dados para a captura DDL são criados

É possível controlar o schema onde os objetos de banco de dados relacionados à captura DDL são criados. Adicione a seguinte instrução de Configuração de endpoint. O parâmetro de Configuração de endpoint está disponível na guia do endpoint de origem.


"DdlArtifactsSchema: "xyzddlschema"

Tabelas do Oracle ausentes após a migração para o PostgreSQL

Nesse caso, as tabelas e dados geralmente ainda estão acessíveis.

O Oracle padroniza os nomes de tabelas com letras maiúsculas, enquanto o PostgreSQL as padroniza com minúsculas. Ao executar uma migração do Oracle para o PostgreSQL, sugerimos fornecer certas regras de transformação na seção de mapeamento de tabela da tarefa. Essas são as regras de transformação para converter maiúsculas e minúsculas dos nomes de tabelas.

Se você migrou as tabelas sem utilizar as regras de transformação para converter maiúsculas e minúsculas dos nomes das tabelas, será necessário inserir os nomes de tabelas entre aspas ao se referir a elas.

ReplicationSlotDiskUsage aumenta e restart_lsn para de avançar durante transações longas, como cargas de trabalho de ETL

Quando a replicação lógica está ativada, o número máximo de alterações mantidas na memória por transação é de 4 MB. Depois disso, as alterações são transferidas para o disco. Como resultado, o ReplicationSlotDiskUsage aumenta, e o restart_lsn não avança até que a transação seja concluída/abortada e a reversão seja concluída. Como é uma transação longa, ela pode demorar muito tempo para reverter.

Portanto, evite transações de longa execução quando a replicação lógica estiver ativada. Em vez disso, tente dividir a transação em várias transações menores.

Tarefa utilizando visualização como uma origem não tem nenhuma linha copiada

Para migrar uma visualização, defina table-type como all ou view. Para ter mais informações, consulte Especificar a seleção de tabelas e as regras de transformação no console.

As origens compatíveis com visualizações incluem o seguinte.

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise (ASE)

Solução de problemas com o Microsoft SQL Server

A seguir, você aprenderá sobre a solução de problemas específicos para utilizar o AWS DMS com bancos de dados Microsoft SQL Server.

Erros ao capturar alterações de banco de dados SQL Server

Os erros durante a captura de dados de alteração (CDC) podem indicar que um dos pré-requisitos não foi atendido. Por exemplo, o pré-requisito que mais passa despercebido é o backup completo do banco de dados. O log de tarefas indica essa omissão com o seguinte erro:


SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)

Revise os pré-requisitos listados para a utilização do SQL Server como origem em Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS.

Colunas de identidade ausentes

O AWS DMS não é compatível com colunas de identidade quando você cria um esquema de destino. Você deve adicioná-las após a conclusão do carregamento inicial.

Erro: o SQL Server não é compatível com publicações

O erro a seguir é gerado quando você utiliza o SQL Server Express como endpoint de origem:


RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.

No momento, o AWS DMS não é compatível com o SQL Server Express como origem ou destino.

As alterações não são exibidas no destino

O AWS DMS requer que um banco de dados SQL Server de origem esteja no modelo de recuperação de dados "FULL" ou "BULK LOGGED" para capturar as alterações de maneira consistente. O modelo 'SIMPLE' não é compatível.

O modelo de recuperação SIMPLE registra o mínimo de informações necessárias para permitir que os usuários recuperem seus bancos de dados. Todas as entradas de log inativas são truncadas automaticamente quando um ponto de verificação ocorre.

Todas as operações ainda são registradas em log. No entanto, assim que ocorre um ponto de verificação, o log é automaticamente truncado. Esse truncamento significa que o log fica disponível para reutilização e as entradas mais antigas do log podem ser substituídas. Quando as entradas do log são substituídas, as alterações não podem ser capturadas. Esse problema é o motivo pelo qual o AWS DMS não é compatível com o modelo de recuperação de dados SIMPLE. Para obter informações sobre outros pré-requisitos necessários para utilizar o SQL Server como origem, consulte Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS.

Tabela não uniforme mapeada entre partições

Durante a captura de dados de alteração (CDC), a migração de uma tabela com uma estrutura especializada será suspensa quando o AWS DMS não puder executar corretamente a CDC na tabela. Mensagens como estas são emitidas:


[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

Ao executar a CDC em tabelas do SQL Server, o AWS DMS analisa os tlogs do SQL Server. Em cada registro do tlog, o AWS DMS analisa os valores hexadecimais contendo dados das colunas que foram inseridas, atualizadas ou excluídas durante uma alteração.

Para analisar o registo hexadecimal, o AWS DMS lê os metadados da tabela das tabelas do sistema do SQL Server. Essas tabelas do sistema identificam o que são as colunas da tabela especialmente estruturadas e revelam algumas de suas propriedades internas, como "xoffset" e "posição de bit nulo".

O AWS DMS espera que os metadados sejam os mesmos para todas as partições brutas da tabela. Mas, em alguns casos, tabelas especialmente estruturadas não têm os mesmos metadados em todas as partições. Nesses casos, o AWS DMS pode suspender a CDC nessa tabela para evitar a análise incorreta das alterações e o fornecimento de dados incorretos ao destino. As soluções alternativas incluem o seguinte:

  • Se a tabela tiver um índice clusterizado, execute uma recompilação do índice.

  • Se a tabela não tiver um índice clusterizado, adicione um índice clusterizado à tabela (você poderá descartá-lo mais tarde se quiser).

Solução de problemas com o Amazon Redshift

A seguir, você aprenderá sobre a solução de problemas específicos ao utilizar o AWS DMS com bancos de dados do Amazon Redshift.

Carga em um cluster do Amazon Redshift em uma região da AWS diferente

Não é possível carregar em um cluster do Amazon Redshift em uma região da AWS diferente da instância de replicação do AWS DMS. O DMS exige que a instância de replicação e o cluster do Amazon Redshift estejam na mesma região.

Erro: Relation "awsdms_apply_exceptions" already exists

O erro "Relation 'awsdms_apply_exceptions' already exists" costuma ocorrer quando um endpoint do Redshift é especificado como endpoint do PostgreSQL. Por corrigir esse problema, modifique o endpoint e altere Target engine para "redshift".

Erros com tabelas cujos nomes começam com "awsdms_changes"

Mensagens de erro de tabelas com nomes que começam com "awsdms_changes" podem ocorrer quando duas tarefas que estão tentando carregar dados no mesmo cluster do Amazon Redshift são executadas simultaneamente. Devido à forma como tabelas temporárias são nomeadas, tarefas simultâneas podem entrar em conflito ao atualizar a mesma tabela.

Ver tabelas em cluster com nomes como dms.awsdms_changes000000000XXXX

O AWS DMS cria tabelas temporárias quando os dados estão sendo carregados de arquivos armazenados no S3. O nome dessas tabelas temporárias tem o prefixo dms.awsdms_changes. Elas são necessárias para o AWS DMS armazenar dados quando eles são carregados pela primeira vez e antes de serem colocados na tabela de destino final.

Permissões necessárias para trabalhar com o Amazon Redshift

Para utilizar o AWS DMS com o Amazon Redshift, a conta de usuário utilizada para acessar o Amazon Redshift deve ter as seguintes permissões:

  • CRUD (escolher, inserir, atualizar, excluir)

  • Carga em massa

  • Criar, alterar, descartar (se necessário pela definição da tarefa)

Para ver todos os pré-requisitos necessários para usar o Amazon Redshift como destino, consulte Utilizar um banco de dados Amazon Redshift como destino do AWS Database Migration Service.

Solução de problemas com o MySQL do Amazon Aurora

A seguir, você poderá aprender sobre a solução de problemas específicos para utilizar o AWS DMS com os bancos de dados do MySQL do Amazon Aurora.

Erro: campos CHARACTER SET UTF8 terminados por ',' inseridos em '"' linhas terminadas em '\n'

Se você estiver utilizando o MySQL do Amazon Aurora como destino, poderá ver um erro como o seguinte nos logs. Esse tipo de erro geralmente indica que você tem ANSI_QUOTES como parte do parâmetro SQL_MODE. Ter ANSI_QUOTES como parte do parâmetro SQL_MODE faz com que aspas duplas sejam tratadas como aspas simples, o que pode criar problemas ao executar uma tarefa.

Por corrigir esse erro, remova ANSI_QUOTES do parâmetro SQL_MODE.


2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

Solução de problemas com o SAP ASE

A seguir, você poderá aprender sobre a solução de problemas específicos para utilizar o AWS DMS com bancos de dados SAP ASE.

Erro: as colunas LOB têm valores NULL quando a origem tem um índice exclusivo composto com valores NULL

Ao usar o SAP ASE como origem com tabelas configuradas com um índice exclusivo composto que permite valores NULL, os valores LOB podem não serem migrados durante a replicação contínua. Esse comportamento geralmente é o resultado de ANSI_NULL definido como 1 por padrão no cliente da instância de replicação do DMS.

Para garantir que os campos LOB migrem corretamente, inclua a Configuração de endpoint 'AnsiNull=0' no endpoint de origem do AWS DMS da tarefa.

Solução de problemas com o IBM Db2

A seguir, você poderá aprender sobre a solução de problemas específicos para utilizar o AWS DMS com bancos de dados IBM Db2.

Erro: a retomada a partir do timestamp não é uma tarefa compatível

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 do StartFromContext com o timestamp requerido. Para obter mais informações, consulte Configurações de endpoint ao utilizar o Db2 LUW. A configuração StartFromContext com o timestamp necessário evita o seguinte problema:

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.