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

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á.

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á.

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, o DMS limpa os arquivos de rastreamento e despejo com mais de 30 dias. Para desativar a coleta de arquivos de rastreamento e despejo, abra um caso com o AWS Support.

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 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:

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.

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:

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:

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:

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 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 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 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.

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

No modo FULL LOB ou LIMITED LOB, AWS DMS não oferece suporte à 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 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:

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 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ê 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 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 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:

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

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 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, AWS DMS tem o registro suplementar desativado. Para ativar automaticamente o registro suplementar de um endpoint de origem do Oracle, faça o seguinte:

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

Atualmente, uma tabela deve ter uma chave primária AWS DMS para capturar as alterações de LOB. 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 as alterações de LOB:

Erro: ORA-12899: Valor muito grande para a coluna column-name

O erro “ORA-12899: valor muito grande para colunacolumn-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 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 Oracle NUMBER é convertido em vários tipos de AWS DMS dados, 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 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 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.

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

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

Solução de problemas com o MySQL

A seguir, você pode aprender sobre a solução de problemas específicos do uso 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ê tem uma tarefa LOBs que está sendo desconectada de um destino do MySQL, 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 destino MySQL, faça o seguinte:

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

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.

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 "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

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

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

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 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 AWS DMS atualiza o valor de uma coluna do banco de dados MySQL para seu valor existente, uma mensagem de zero rows affected é retornada do 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 AWS DMS a criação de tabelas e 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: 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ê 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 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 de origem do MySQL em que o conjunto de caracteres de origem Utf8 é latin1 ou. 65001 é UTF8 o identificador da página de 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. 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.

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.

Solução de problemas com o PostgreSQL

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

Tipos de dados JSON que estão sendo truncados

AWS DMS trata o tipo de dados JSON no PostgreSQL como uma coluna de tipo 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 fonte do PostgreSQL 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:7 Mensagem NativeError: ERRO: nenhum esquema foi selecionado para criar em”.

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 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 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, 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 a captura de dados de alteração (CDC), as operações TRUNCATE não são suportadas pelo. 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 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.

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 do Microsoft SQL Server.

Replicação contínua falha após o failover do RDS para SQL Server para a origem secundária

Se uma instância do SQL Server 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 online novamente. No entanto, para instâncias MAZ do RDS para SQL Server, em determinadas circunstâncias, o proprietário do banco de dados secundário pode ser definido como NT AUTHORITY\SYSTEM. Depois de um failover, isso fará com que a tarefa do DMS apresente 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 retome sua tarefa do DMS.

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

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: 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.                
            

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 Server de origem esteja no modelo de recuperação de dados “FULL” ou “BULK LOGGED” para capturar alterações de forma 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 AWS DMS não oferece suporte ao 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 é suspensa quando não é AWS DMS possível executar adequadamente o 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 o CDC em tabelas do SQL Server, AWS DMS analisa os tlogs do SQL Server. 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 das tabelas do sistema 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".

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 o 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:

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. 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

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:

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

Erro: UTF8 campos CHARACTER SET terminados por ',' delimitados por '"' linhas terminadas por '\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ê pode aprender sobre a solução de problemas específicos do uso 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 'AnsiNull=0' do Endpoint no endpoint de AWS DMS origem da tarefa.

Solução de 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 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.