Problemas de verificação de dados - Data Transmission Service: Central de Documentação do Alibaba Cloud

P: Quais são as causas de inconsistência de dados em uma tarefa de verificação de dados?
As causas mais comuns são:
1. A tarefa de migração ou sincronização de dados apresenta latência.
2. O banco de dados source executa uma operação ADD COLUMN com um valor padrão enquanto a tarefa apresenta latência.
3. O banco de dados de destino recebe gravações de dados de fontes diferentes do DTS.
4. O banco de dados source de uma tarefa com o recurso de mesclagem de várias tabelas ativado executa uma operação DDL.
5. A tarefa de migração ou sincronização de dados utiliza o recurso de mapeamento de nome de banco de dados, tabela ou coluna.
P: Por que uma tarefa de verificação de esquema detecta uma diferença em isRelHasoids?

Bancos de dados PostgreSQL anteriores à versão 12 aceitam a criação de tabelas com WITH OIDS para adicionar uma coluna de identificador de objeto (OID) globalmente exclusivo. Se o source de uma tarefa de verificação de esquema especificar WITH OIDS ao criar tabelas e o destino for uma versão posterior do PostgreSQL que não aceita WITH OIDS, a tarefa relata uma diferença em isRelHasoids.
P: Uma diferença em isRelHasoids relatada por uma tarefa de verificação de esquema requer atenção?

Não.
P: O DTS sincroniza ou migra a coluna de identificador de objeto (OID)?

A coluna de identificador de objeto (OID) é gerada automaticamente quando WITH OIDS é especificado. O DTS não sincroniza nem migra esses dados, independentemente de o destino aceitar ou não essa coluna.
P: Como verificar se uma tabela possui uma coluna de identificador de objeto (OID)?
Nota
Substitua <table_name> nos comandos pelo nome da tabela que você deseja consultar.
- Comando SQL: SELECT relname AS table_name, relhasoids AS has_oids FROM pg_class WHERE relname = '<table_name>' AND relkind = 'r';
- Comando do cliente: \d+ <table_name>
P: Como solucionar inconsistências de dados relatadas em um relatório de verificação completa de dados?

Siga estas etapas para solucionar o problema:
1. Revise o relatório de verificação para identificar os valores de source e de destino para cada coluna e confirme quais colunas e valores estão inconsistentes.
2. Com base no relatório de verificação, faça login manualmente nos bancos de dados source e de destino e compare os valores divergentes para determinar se são esperados.
3. Confirme que nenhum dado foi gravado no source ou no destino durante a verificação. Caso não seja possível garantir isso, recomendamos pausar as gravações no banco de dados source durante horários de menor movimento e, em seguida, reiniciar a verificação.
4. Se as diferenças persistirem, ative temporariamente o SQL Explorer (pagamento conforme o uso) no source e no destino, e use os logs de auditoria para verificar se as colunas foram modificadas.
5. Diferenças em alguns atributos (como SECURITY_TYPE) são comportamentos esperados e podem ser ignoradas.
6. Uma verificação completa de dados bem-sucedida confirma a consistência dos dados após modificações não padronizadas no backend.
7. Inconsistências na verificação completa de dados geralmente não estão relacionadas a diferenças de esquema. Para uma verificação adicional, execute manualmente count(*) para comparar a contagem de linhas entre os bancos de dados source e de destino.
P: Por que o DTS mostra o progresso da tarefa como incompleto (por exemplo, 41%) mesmo após a conclusão da transmissão de dados?

A porcentagem de progresso da tarefa do DTS abrange duas etapas: transmissão de dados (migração completa de dados) e verificação de dados. Após a conclusão da migração completa de dados, o progresso restante reflete a verificação de dados em andamento. A verificação de dados é uma verificação de consistência independente executada após o término da transmissão completa de dados. A tarefa geral é considerada concluída somente quando o progresso da verificação atinge 100%.

Para confirmar os dados imediatamente após o término da transmissão, conecte-se manualmente ao banco de dados de destino e verifique os dados sem esperar a conclusão da verificação.
P: Causas e soluções para consultas SQL lentas durante a etapa de verificação completa de dados

Causa: Durante a etapa de verificação completa de dados, o DTS lê tabelas grandes em shards pela chave primária ID. Quando o volume de dados é grande, as consultas de shard demoram mais e podem causar consultas SQL lentas no banco de dados source.

Solução:
1. Primeiro, verifique se a tarefa de verificação completa de dados foi interrompida. Em caso afirmativo, nenhuma consulta desse tipo deve ser gerada.
2. Se a tarefa de verificação ainda estiver em execução e afetar seus negócios, execute a verificação completa de dados durante horários de menor movimento, ou suspenda a tarefa de verificação e reinicie-a nesses horários.