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 DMS não cria CloudWatch registrosOcorrem problemas com a conexão com a Amazon RDSOcorrem problemas de redeCDCestá preso após a carga totalErros 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 problemasAs tarefas falham quando uma chave primária é criada em uma LOB colunaRegistros 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 My SQLSolução de problemas com o Postgre SQLSolução de problemas com o Microsoft SQL ServerSolução de problemas com o Amazon RedshiftSolução de problemas com o Amazon Aurora My SQL Solução de problemas com SAP ASESolucionando 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, você encontrará tópicos sobre solução de problemas com o AWS Database Migration Service (AWS DMS). Esses tópicos podem ajudá-lo a resolver problemas comuns usando bancos de dados de endpoints selecionados AWS DMS e ambos.

Se você abriu um caso de AWS Support, seu engenheiro de suporte pode identificar um possível problema com uma das configurações do seu 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 Trabalhando com scripts de suporte de diagnóstico em 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, 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 para uma tarefa de migração ser executada lentamente é que há recursos inadequados alocados para a instância de AWS DMS replicação. Para garantir que sua instância tenha recursos suficientes para as tarefas que você está executando nela, verifique o uso, a memóriaCPU, os arquivos de troca e. IOPS Por exemplo, várias tarefas com o Amazon Redshift como endpoint têm uso intensivo de E/S. Você pode aumentar sua instância IOPS de replicação ou dividir suas tarefas em várias instâncias de replicação para uma migração mais eficiente.

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 seu destino for uma RDS instância de banco de dados Amazon, certifique-se de que o Multi-AZ não esteja habilitado 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 seu destino, use provisionadoIOPS.

  • Se seus dados de migração contiveremLOBs, verifique se a tarefa está otimizada para LOB migração. Para obter mais informações sobre como otimizar paraLOBs, consulteConfiguraçõ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 estatísticas de linhas estimadas, não é AWS DMS possível fornecer nenhum tipo de estimativa percentual completa. 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 obter 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

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 com eficiência os dados da fonte. 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 DMS nã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 IAM console em https://console.aws.amazon.com/iam/.

  2. Escolha a guia Perfis. Selecione Criar função.

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

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

  5. Selecione Next: Permissions (Próximo: permissões).

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

  7. Escolha Próximo: etiquetas.

  8. Selecione Next: Review (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 função.

Ocorrem problemas com a conexão com a Amazon RDS

Pode haver vários motivos pelos quais você não pode se conectar a uma RDS instância de banco de dados da Amazon que você definiu 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 RDS console da Amazon para a instância é o mesmo que o identificador do endpoint que você usou para criar o AWS DMS endpoint.

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

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

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

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 de rede mais comum envolve o grupo VPC de segurança usado pela instância de AWS DMS replicação. 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:

  • Instância de replicação e endpoints de origem e destino na mesma VPC — O grupo de segurança usado pelos endpoints deve permitir a entrada na porta do banco de dados a partir 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 do VPC usado pela instância de replicação (usando um gateway da Internet) — O grupo de VPC segurança deve incluir regras de roteamento que enviem tráfego que não é 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 do VPC usado pela instância de replicação (usando um NAT gateway) — Você pode configurar um gateway de conversão de endereço de rede (NAT) usando um único endereço IP elástico vinculado a uma única interface de rede elástica. Esse NAT gateway recebe um NAT identificador (nat-#####).

    Em alguns casos, VPC inclui uma rota padrão para esse NAT gateway em vez do gateway de internet. Nesses casos, a instância de replicação parece entrar em contato com o endpoint do banco de dados usando o endereço IP público do NAT gateway. Aqui, a entrada no endpoint do banco de dados fora do VPC precisa permitir a entrada do NAT endereço 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.

CDCestá preso após a carga total

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 a não AWS DMS 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, AWS DMS faz uma varredura completa da 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 a opção Modo de preparação da tabela de destino estiver definida como Não fazer nada, AWS DMS não fará nenhuma preparação na tabela de destino, incluindo a limpeza dos 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 usada 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, geralmente descobrimos que o problema envolve recursos insuficientes alocados para a instância de AWS DMS replicação.

Para garantir que sua instância de replicação tenha recursos suficientes para realizar a migração, verifique o uso, a memóriaCPU, os arquivos de troca e. IOPS Para obter mais informações sobre monitoramento, consulte AWS Database Migration Service métricas.

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

AWS DMS reinicia o carregamento da tabela desde o início, quando não termina o carregamento inicial de uma tabela. Quando uma tarefa é reiniciada, 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.

As tarefas falham quando uma chave primária é criada em uma LOB coluna

No LIMITED LOB modo FULL LOB ou, AWS DMS não oferece suporte à replicação de chaves primárias que são tipos de LOB dados.

DMSmigra inicialmente uma linha com uma LOB coluna como nula e depois atualiza a LOB coluna. Portanto, quando a chave primária é criada em uma LOB coluna, a inserção inicial falha, pois 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 LOB coluna.

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

Executar uma carga e uma CDC tarefa completas pode criar registros duplicados em tabelas de destino que não têm uma chave primária ou um índice exclusivo. Para evitar a duplicação de registros nas tabelas de destino durante a carga total e CDC as tarefas, certifique-se de que as tabelas de destino tenham uma chave primária ou um índice exclusivo.

Os endpoints de origem ficam no intervalo IP reservado

Se um banco de dados de AWS DMS origem usar um endereço IP dentro do intervalo de 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. Encontre uma EC2 instância da Amazon que não esteja no intervalo reservado e 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
&

Use o endereço IP da EC2 instância Amazon e a porta do banco de dados fornecida anteriormente para o AWS DMS endpoint. Certifique-se de que o endpoint tenha o grupo de segurança que permite acessar AWS DMS a porta do banco de dados. Observe que o proxy precisa estar em execução durante a execução da DMS tarefa. 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ê pode aprender sobre a solução de problemas específicos do uso 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

Migrando LOBs do Oracle 12c

AWS DMS pode 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 suporta LOB colunas. Para capturar alterações nas LOB colunas no Oracle 12c, use o Binary Reader.

Alternando entre Oracle LogMiner e Binary Reader

AWS DMS pode 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. Use uma ferramenta de desenvolvedor da Oracle, como SQL -Plus, para conceder o seguinte privilégio adicional à conta de AWS DMS usuário usada para se conectar ao endpoint Oracle.

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

Erro: o Oracle CDC interrompeu 122301. O contador CDC máximo de tentativas do Oracle foi excedido.

Esse erro ocorre quando os registros de arquivamento Oracle necessários são removidos do seu servidor antes AWS DMS que você possa usá-los para capturar alterações. Aumente as políticas de retenção de logs no servidor de banco de dados. Para um RDS banco de dados da Amazon, execute o procedimento a seguir para aumentar a retenção de logs. Por exemplo, o código a seguir aumenta a retenção de registros em uma RDS instância de banco de dados da Amazon 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, AWS DMS tem 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. Selecione 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.

LOBas mudanças não estão sendo capturadas

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

  • 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: Valor muito grande para a coluna column-name

O erro "ORA-12899: valor muito grande para a coluna column-name“geralmente é causado por alguns problemas.

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

Em outra dessas questões, as configurações de suporte ao idioma nacional (NLS) diferem entre os dois bancos de dados. Uma causa comum desse erro é quando o parâmetro NLS _ LENGTH _ do banco de dados de origem é definido como CHAR e o SEMANTICS parâmetro NLS _ LENGTH _ SEMANTICS do banco de dados de destino está definido comoBYTE.

NUMBERtipo de dados sendo mal interpretado

O tipo de NUMBER dados Oracle é convertido em vários tipos de AWS DMS dados, dependendo da precisão e da escala deNUMBER. Essas conversões estão documentadas aqui Tipos de dados de origem do Oracle. A forma como o NUMBER tipo é convertido também pode ser afetada pelo uso das configurações de endpoint para o endpoint 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 realizar uma carga completa, 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 tarefaTransactionConsistencyTimeout=600, 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 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 obter 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 sua fonte Oracle não tem nenhum registro de arquivamento gerado ou V$ ARCHIVED _ LOG está vazio. É possível resolver o erro trocando os logs manualmente.

Para um RDS banco de dados da Amazon, execute o procedimento a seguir para alternar 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 de registros de refazer ou arquivar, use a imagem de máquina de AWS DMS diagnóstico da Amazon (AMI).

Você pode usar o AWS DMS diagnóstico AMI para fazer o seguinte:

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

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

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

  • Use Single-thread para avaliar o desempenho de leitura em. ASMFile

  • Use vários threads para avaliar o desempenho de leitura em. 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 EC2 instância AWS DMS de diagnóstico AMI da Amazon e conecte-se a ela.

    Para obter mais informações, consulte Trabalhando com o AWS DMS diagnóstico AMI.

  2. Execute o comando awsreplperf.

    $ awsreplperf

    O comando exibe as opções do AWS DMS Oracle Read Performance Utility.

    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 seus arquivos de redo log tiverem até 2 GB, tente aumentar LOG _ BUFFER para 200 MB para ajudar a melhorar o desempenho.

  • Analise as AWS DMS melhores práticas para garantir que sua instância, tarefa e endpoints de DMS replicação estejam configurados de forma ideal.

Solução de problemas com o My SQL

A seguir, você pode aprender sobre a solução de problemas específicos do uso AWS DMS com Meus SQL bancos de dados.

CDCfalha na tarefa para o endpoint da RDS instância de banco de dados da Amazon porque o registro binário foi desativado

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

Conexões com uma instância de destino Minha SQL instância são desconectadas durante uma tarefa

Se você tem uma tarefa LOBs que está sendo desconectada de um SQL destino Meu, você pode ver os seguintes tipos de erros no registro 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 SQL destino Meu, faça o seguinte:

  • Verifique se o max_allowed_packet conjunto de variáveis do banco de dados é grande o suficiente para conter o maiorLOB.

  • 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 de Minhas variáveis de SQL sistema, consulte Variáveis de sistema do servidor na SQLdocumentação Minha.

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

Para adicionar confirmação automática a um endpoint compatível com My SQL de destino

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

  2. Selecione Endpoints.

  3. Escolha o endpoint SQL de destino compatível com My ao qual você deseja adicionar a confirmação automática.

  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.

Desativar chaves estrangeiras em um endpoint SQL compatível com My de destino

Você pode desativar as verificações de chave estrangeira no My SQL adicionando o seguinte aos Atributos de conexão extras na seção Avançado do endpoint MySQL, Amazon Aurora My SQL -Compatible Edition ou MariaDB de destino.

Para desativar chaves estrangeiras em um endpoint SQL compatível com My de destino

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

  2. Selecione Endpoints.

  3. Escolha o endpoint de destino MySQL, Aurora My SQL ou MariaDB em que você 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 mais comum que causa esse problema é quando os caracteres do endpoint de origem são codificados por um conjunto de caracteres que AWS DMS não é compatível.

Entradas de log de "eventos inválidos"

As entradas de “evento incorreto” nos registros de migração geralmente indicam que uma operação de linguagem de definição de dados (DDL) não suportada foi tentada no endpoint do banco de dados de origem. DDLOperações não suportadas causam um evento que a instância de replicação não pode ignorar, portanto, um evento incorreto é registrado.

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 DDL operação não suportada.

Altere a captura de dados com o My SQL 5.5

AWS DMS change data capture (CDC) para bancos de dados SQL compatíveis com Amazon RDS My requer registro binário completo baseado em linhas de imagens, o que não é suportado na SQL versão 5.5 ou inferior do My. Para usar AWS DMS CDC, você deve atualizar sua instância de RDS banco de dados Amazon para a SQL versão My 5.6.

Aumento da retenção de registros binários para instâncias de RDS banco de dados da Amazon

AWS DMS requer a retenção de arquivos de log binários para a captura de dados de alterações. Para aumentar a retenção de logs em uma instância de RDS banco de dados Amazon, use 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 AWS DMS atualiza o valor da coluna Meu SQL banco de dados para o valor existente, uma mensagem de zero rows affected é retornada de MySQL. Esse comportamento é diferente de outros mecanismos de banco de dados, como Oracle e 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 AWS DMS a criação de tabelas e chaves primárias no banco de dados de destino. Nesses casos, DMS atualmente não usa os mesmos nomes para as chaves primárias que foram usadas no banco de dados de origem. Em vez disso, DMS cria o nome da chave primária com base no nome da tabela. Quando o nome da tabela é longo, o identificador gerado automaticamente criado pode ser maior do que os limites permitidos para 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: Codepage 1252 para UTF8 [120112] uma conversão de dados de campo falhou

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

  
[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 solução alternativa, você pode usar o atributo CharsetMapping extra de conexão com seu SQL endpoint de origem para especificar o mapeamento do conjunto de caracteres. Talvez seja necessário reiniciar a tarefa de AWS DMS migração desde o início se você adicionar essa configuração de endpoint.

Por exemplo, a configuração de endpoint a seguir pode ser usada para um endpoint My SQL source em que o conjunto de caracteres de origem é Utf8 oulatin1. 65001 é o identificador da página de UTF8 código. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

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

AWS DMS não suporta 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. Em seguida, crie uma única tarefa para carga total ou duas tarefas separadas para carga total eCDC, conforme descrito a seguir: CDC

Crie uma única tarefa com suporte para carga total e CDC

Este procedimento descreve como migrar chaves estrangeiras e índices usando uma única tarefa para carga total e. CDC

Crie uma carga e uma CDC tarefa completas

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

  2. Adicione o seguinte ECA ao AWS DMS endpoint de destino:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Crie a AWS DMS tarefa com TargetTablePrepMode definido comoDO_NOTHING.

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

  5. Inicie a tarefa. AWS DMS interrompe a tarefa automaticamente depois que ela conclui o carregamento completo e aplica todas as alterações em cache.

  6. Remova o SET FOREIGN_KEY_CHECKS ECA que você adicionou anteriormente.

  7. Retome a tarefa. A tarefa entra na CDC fase e aplica as mudanças contínuas do banco de dados de origem para o de destino.

Crie a carga completa e CDC as tarefas separadamente

Esses procedimentos descrevem como migrar chaves e índices estrangeiros usando tarefas separadas para carga total e. 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 seguinte ECA ao AWS DMS endpoint de destino:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

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

  4. Inicie a tarefa. AWS DMS interrompe a tarefa automaticamente depois que ela conclui o carregamento completo 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 carregamento total ou o nome e a posição do arquivo de log binário para iniciar a CDC única tarefa. UTC Consulte os registros para obter o registro de data e hora a UTC partir do horário inicial de início do carregamento total.

Crie uma CDC tarefa somente

  1. Remova o SET FOREIGN_KEY_CHECKS ECA que você definiu anteriormente.

  2. Crie a tarefa CDC somente com a posição inicial definida para a hora de início da carga total 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 CDC -only e monitore os registros em busca de erros.

nota

Essa solução alternativa se aplica somente a uma SQL migração My SQL to My. 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 Postgre SQL

A seguir, você pode aprender sobre a solução de problemas específicos do uso AWS DMS com SQL bancos de dados Postgre.

JSONtipos de dados sendo truncados

AWS DMS trata o tipo JSON de dados no Postgre SQL como uma coluna de tipo de LOB dados. Isso significa que a limitação de LOB tamanho quando você usa o LOB modo limitado se aplica aos JSON dados.

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

As informações de registro a seguir mostram JSON que foi truncado devido à configuração do LOB modo 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 SQL fonte do Postgre, AWS DMS cria a tabela de destino com os mesmos tipos de dados para todas as colunas, exceto as 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 NativeError: 7 Mensagem:ERROR: nenhum esquema foi selecionado para criar em”.

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

As exclusões e atualizações em uma tabela não estão sendo replicadas usando CDC

As operações de exclusão e atualização durante a captura de dados de alteração (CDC) são ignoradas se a tabela de origem não tiver uma chave primária. AWS DMS suporta captura de dados de alteração (CDC) para SQL tabelas Postgre com chaves primárias.

Se uma tabela não tiver uma chave primária, os registros write-ahead (WAL) não incluirão uma imagem anterior da linha do banco de dados. Nesse caso, não é AWS DMS possível atualizar 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 usar change data capture (CDC), TRUNCATE as operações não são suportadas pelo AWS DMS.

Impedindo que o Postgre SQL capture DDL

Você pode impedir que um endpoint de SQL destino do Postgre capture DDL instruções adicionando a seguinte instrução de configuração do Endpoint.


"CaptureDDLs": "N"

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

Você pode controlar em qual esquema os objetos do 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 Oracle ausentes após a migração para o Postgre SQL

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

O Oracle usa como padrão nomes de tabelas em maiúsculas e o Postgre SQL usa como padrão nomes de tabelas em minúsculas. Ao realizar uma migração do Oracle para o PostgreSQL, sugerimos que você forneça determinadas regras de transformação na seção de mapeamento de tabelas da sua 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 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 obter 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

  • SQLServidor Microsoft

  • Meu SQL

  • Postger SQL

  • IBMDb2 LUW

  • SAPServidor corporativo adaptável () ASE

Solução de problemas com o Microsoft SQL Server

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

A replicação contínua falha após o failover SQL do servidor RDS para o secundário

Se uma instância SQL do servidor de origem fizer o failover para a secundária, a replicação AWS DMS contínua continuará tentando se conectar e continuará a replicar quando a fonte estiver on-line novamente. No entanto, RDS para MAZ instâncias de SQL servidor, sob certas circunstâncias, o proprietário do banco de dados secundário pode ser definido comoNT AUTHORITY\SYSTEM. Depois de um failover, isso faz com que a DMS tarefa falhe com o seguinte erro:

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

Para corrigir isso, siga as etapas em Alterar o db_owner para a conta rdsa do seu banco de dados e, em seguida, retome sua tarefa. DMS

Erros ao capturar alterações no banco de dados SQL do servidor

Erros durante a captura de dados de alteração (CDC) geralmente 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 usar o SQL Server como fonte em. Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS

Colunas de identidade ausentes

AWS DMS não oferece suporte a colunas de identidade quando você cria um esquema de destino. Você deve adicioná-las após a conclusão do carregamento inicial.

Erro: SQL o servidor não suporta publicações

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


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

AWS DMS atualmente não oferece suporte ao SQL Server Express como origem ou destino.

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

AWS DMS exige que um banco de dados SQL do servidor de origem esteja no modelo de recuperação de dados BULK LOGGED '' ou '' para capturar alterações de forma consistente. FULL O modelo SIMPLE '' não é suportado.

O modelo SIMPLE de recuperação registra as informações mínimas necessárias para permitir que os usuários recuperem seu banco 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 AWS DMS não oferece suporte ao modelo SIMPLE de recuperação de dados. Para obter informações sobre outros pré-requisitos necessários para usar o SQL Server como fonte, 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 é suspensa quando não AWS DMS pode ser CDC executada adequadamente 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 CDC em tabelas SQL do servidor, AWS DMS analisa os tlogs do SQL servidor. Em cada registro tlog, AWS DMS analisa valores hexadecimais contendo dados de colunas que foram inseridas, atualizadas ou excluídas durante uma alteração.

Para analisar o registro hexadecimal, AWS DMS lê os metadados da tabela nas tabelas do sistema do servidor. SQL 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".

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, AWS DMS pode suspender 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ê pode aprender sobre a solução de problemas específicos para uso AWS DMS com bancos de dados do Amazon Redshift.

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

Você não pode carregar em um cluster do Amazon Redshift em uma AWS região diferente da sua instância de AWS DMS replicação. DMSexige que sua instância de replicação e seu cluster do Amazon Redshift estejam na mesma região.

Erro: Relation "awsdms_apply_exceptions" already exists

O erro “A relação 'awsdms_apply_exceptions' já existe” geralmente ocorre quando um endpoint do Redshift é especificado como um endpoint do Postgre. SQL 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.

Visualizando tabelas em clusters com nomes como dms.awsdms_changes000000000 XXXX

AWS DMS cria tabelas temporárias quando os dados estão sendo carregados de arquivos armazenados no Amazon S3. O nome dessas tabelas temporárias tem o prefixo dms.awsdms_changes. Essas tabelas são necessárias para que AWS DMS possam armazenar dados quando 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 usar AWS DMS com o Amazon Redshift, a conta de usuário que você usa 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 Amazon Aurora My SQL

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

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

Se você estiver usando o Amazon Aurora My SQL como destino, poderá ver um erro como o seguinte nos registros. Esse tipo de erro geralmente indica que você tem ANSI _ QUOTES como parte do MODE parâmetro SQL _. Ter ANSI _ QUOTES como parte do MODE parâmetro SQL _ faz com que aspas duplas sejam tratadas como aspas e pode criar problemas ao executar uma tarefa.

Para corrigir esse erro, remova ANSI _ QUOTES do MODE parâmetro SQL _.


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 SAP ASE

A seguir, você pode aprender sobre a solução de problemas específicos do uso AWS DMS com SAP ASE bancos de dados.

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

Ao usar SAP ASE como fonte tabelas configuradas com um índice exclusivo composto que permite NULL valores, os LOB valores podem não migrar 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 DMS de replicação.

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

Solucionando problemas com o IBM Db2

A seguir, você pode aprender sobre a solução de problemas específicos do uso AWS DMS com bancos de dados IBM Db2.

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

Para a replicação contínua (CDC), se você planeja iniciar a replicação a partir de um timestamp específico, defina o atributo de conexão com o timestamp StartFromContext necessário. Para obter mais informações, consulte Configurações do endpoint ao usar o LUW Db2. 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.