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á. # AWS Validação de dados do DMS **Topics** + [ ## Estatísticas da tarefa de replicação ](#CHAP_Validating.TaskStatistics) + [ ## Estatísticas de tarefas de replicação com a Amazon CloudWatch ](#CHAP_Validating.TaskStatistics.CloudWatch) + [ ## Revalidar tabelas durante uma tarefa ](#CHAP_Validating.Revalidating) + [ ## Utilizar o editor JSON para modificar regras de validação ](#CHAP_Validating.JSONEditor) + [ ## Tarefas somente de validação ](#CHAP_Validating.ValidationOnly) + [ ## Solução de problemas ](#CHAP_Validating.Troubleshooting) + [ ## Desempenho da validação do Redshift ](#CHAP_Validating.Redshift) + [ ## Validação de dados aprimorada para AWS Database Migration Service ](#CHAP_Validating_Enhanced) + [ ## Limitações ](#CHAP_Validating.Limitations) + [ # Validação de dados de destino do Amazon S3 ](CHAP_Validating_S3.md) + [ # AWS DMS ressincronização de dados ](CHAP_Validating.DataResync.md) AWS DMS fornece suporte para validação de dados para garantir que seus dados foram migrados com precisão da origem para o destino. Se ativada, a validação começa imediatamente após a execução da carga máxima de uma tabela. A validação compara as alterações incrementais de uma tarefa ativada para a CDC à medida que ocorrem. Durante a validação de dados, AWS DMS compara cada linha na origem com a linha correspondente no destino, verifica se as linhas contêm os mesmos dados e relata qualquer incompatibilidade. Para fazer isso, AWS DMS emite consultas apropriadas para recuperar os dados. Observe que essas consultas consomem recursos adicionais na origem e no destino, bem como em outros recursos de rede. Para uma tarefa exclusiva de apenas CDC com a validação ativada, todos os dados preexistentes em uma tabela são validados antes de iniciar a validação de novos dados. A validação de dados funciona com os seguintes bancos de dados de origem, sempre que os AWS DMS suporte como endpoints de origem: + Oracle + Banco de dados compatível com o PostgreSQL (PostgreSQL, Aurora PostgreSQL ou Aurora Sem Servidor para PostgreSQL) + Banco de dados compatível com o MySQL (MySQL, MariaDB, Aurora MySQL ou Aurora Sem Servidor para MySQL) + Microsoft SQL Server + IBM Db2 LUW A validação de dados funciona com os seguintes bancos de dados de destino, sempre que os AWS DMS suporte como endpoints de destino: + Oracle + Banco de dados compatível com o PostgreSQL (PostgreSQL, Aurora PostgreSQL ou Aurora Sem Servidor para PostgreSQL) + Banco de dados compatível com o MySQL (MySQL, MariaDB, Aurora MySQL ou Aurora Sem Servidor para MySQL) + Microsoft SQL Server + IBM Db2 LUW + banco de dados de origem + Amazon S3. Para obter informações sobre como validar os dados de destino do Amazon S3, consulte [Validação de dados de destino do Amazon S3](CHAP_Validating_S3.md). Para obter mais informações sobre os endpoints com suporte, consulte [Trabalhando com endpoints AWS do DMS](CHAP_Endpoints.md). A validação de dados requer tempo adicional, além da quantidade necessária para a migração em si. O tempo extra necessário depende do volume de dados que foi migrado. Para ter mais informações sobre essas configurações, consulte [Configurações da tarefa de validação de dados](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Para obter um exemplo das configurações da tarefa `ValidationSettings` em um arquivo JSON, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## Estatísticas da tarefa de replicação Quando a validação de dados está ativada, AWS DMS fornece as seguintes estatísticas no nível da tabela: + **ValidationState**—O estado de validação da tabela. O parâmetro pode ter os valores a seguir: + **Não ativado**: a validação não é ativada para a tabela na tarefa de migração. + **Registros pendentes**: alguns registros na tabela estão aguardando validação. + **Registros incompatíveis**: alguns registros na tabela não correspondem entre a origem e o destino. Uma incompatibilidade pode ocorrer por vários motivos. Para obter mais informações, consulte a tabela `awsdms_control.awsdms_validation_failures_v1` no endpoint de destino. + **Registros suspensos**: não foi possível validar alguns registros na tabela. + **Nenhuma chave primária**: não foi possível validar a tabela, pois ela não tinha uma chave primária. + **Erro de tabela**: não foi possível validar a tabela, porque ela estava em estado de erro, e alguns dados não foram migrados. + **Validadas**: todas as linhas na tabela estão validadas. Se a tabela for atualizada, o status poderá não ser mais Validado. + **Erro**: não é possível validar a tabela devido a um erro inesperado. + **Validação pendente**: a tabela está aguardando validação. + **Preparando a tabela**: preparando a tabela ativada na tarefa de migração para validação. + **Revalidação pendente**: todas as linhas na tabela estão pendentes de validação após a atualização da tabela. + **ValidationPending**— O número de registros que foram migrados para o destino, mas que ainda não foram validados. + **ValidationSuspended**—O número de registros que não AWS DMS podem ser comparados. Por exemplo, se um registro na origem está sendo atualizado constantemente, não é AWS DMS possível comparar a origem e o destino. + **ValidationFailed**—O número de registros que não passaram pela fase de validação de dados. Para obter um exemplo das configurações da tarefa `ValidationSettings` em um arquivo JSON, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). Você pode visualizar as informações de validação de dados usando o console AWS CLI, o ou a AWS DMS API. + No console, é possível optar por validar uma tarefa ao criá-la ou modificá-la. Para visualizar o relatório de validação de dados utilizando o console, escolha a página **Tarefas** e escolha a guia **Estatísticas da tabela**, na seção de detalhes. + Utilizando a CLI, defina o parâmetro `EnableValidation` como `true` ao criar ou modificar uma tarefa para começar a validação de dados. O exemplo a seguir cria uma tarefa e permite a validação de dados. ``` create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}' ``` Use o comando `describe-table-statistics` para receber o relatório de validação de dados no formato JSON. O comando a seguir mostra o relatório de validação de dados. ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` O relatório seria semelhante ao seguinte. ``` { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } } ``` + Usando a AWS DMS API, crie uma tarefa usando a **CreateReplicationTask**ação e defina o `EnableValidation` parâmetro como **verdadeiro** para validar os dados migrados pela tarefa. Use a **DescribeTableStatistics**ação para receber o relatório de validação de dados no formato JSON. ## Estatísticas de tarefas de replicação com a Amazon CloudWatch Quando a Amazon CloudWatch está habilitada, AWS DMS fornece as seguintes estatísticas de tarefas de replicação: + **ValidationSucceededRecordCount**— Número de linhas AWS DMS validadas, por minuto. + **ValidationAttemptedRecordCount**— Número de linhas em que houve tentativa de validação, por minuto. + **ValidationFailedOverallCount**— Número de linhas em que a validação falhou. + **ValidationSuspendedOverallCount**— Número de linhas em que a validação foi suspensa. + **ValidationPendingOverallCount**— Número de linhas em que a validação ainda está pendente. + **ValidationBulkQuerySourceLatency**— AWS DMS pode fazer a validação de dados em massa, especialmente em determinados cenários durante uma carga completa ou uma replicação contínua quando há muitas alterações. Essa métrica indica a latência necessária para ler um conjunto de dados em massa no endpoint de origem. + **ValidationBulkQueryTargetLatency**— AWS DMS pode fazer a validação de dados em massa, especialmente em determinados cenários durante uma carga completa ou uma replicação contínua quando há muitas alterações. Essa métrica indica a latência necessária para ler um conjunto de dados em massa no endpoint de destino. + **ValidationItemQuerySourceLatency**— Durante a replicação contínua, a validação de dados pode identificar as mudanças em andamento e validar essas alterações. Essa métrica indica a latência de leitura das alterações a partir da origem. A validação pode executar mais consultas do que o necessário, com base no número de alterações, se houver erros durante a validação. + **ValidationItemQueryTargetLatency**— Durante a replicação contínua, a validação de dados pode identificar as alterações em andamento e validar as alterações linha por linha. Essa métrica fornece a latência de leitura das alterações a partir do destino. A validação pode executar mais consultas do que o necessário, com base no número de alterações, se houver erros durante a validação. Para coletar informações de validação de dados das estatísticas CloudWatch ativadas, selecione **Ativar CloudWatch registros** ao criar ou modificar uma tarefa usando o console. Para visualizar as informações sobre a validação de dados e garantir que os dados foram migrados de forma precisa da origem para o destino, faça o seguinte. 1. Escolha a tarefa pai na lista na página **Tarefas de migração de banco de dados**. 1. Escolha a guia de **CloudWatch métricas**. 1. Selecione **Validação** no menu suspenso. ## Revalidar tabelas durante uma tarefa Enquanto uma tarefa está em execução, você pode solicitar AWS DMS a validação de dados. ### Console de gerenciamento da AWS 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Se você estiver conectado como usuário AWS Identity and Access Management (IAM), verifique se você tem as permissões apropriadas para acessar AWS DMS. As permissões necessárias, consulte[Permissões do IAM necessárias para usar AWS DMS](security-iam.md#CHAP_Security.IAMPermissions). 1. No painel de navegação, selecione **Tasks**. 1. Escolha a tarefa em execução cuja tabela você deseja revalidar. 1. Escolha a guia **Table Statistics** (Estatísticas da tabela). 1. Escolha a tabela que deseja revalidar (é possível escolher até 10 tabelas por vez). Se a tarefa não estiver mais em execução, não será possível revalidar a(s) tabela(s). 1. Selecione **Revalidate (Revalidar)**. ## Utilizar o editor JSON para modificar regras de validação Para adicionar uma regra de validação a uma tarefa usando o editor JSON do AWS DMS console, faça o seguinte: 1. Selecione **Tarefas de migração de banco de dados**. 1. Selecione a tarefa na lista de tarefas de migração. 1. Se a tarefa estiver em execução, selecione **Interromper** no menu suspenso **Ações**. 1. Depois que a tarefa for interrompida, para modificá-la, selecione **Modificar** no menu suspenso **Ações**. 1. Na seção **Mapeamentos de tabela**, selecione o **editor JSON** e adicione sua regra de validação aos mapeamentos de tabela. Por exemplo, é possível adicionar a regra de validação a seguir para executar um perfil de substituição na origem. Nesse caso, se a regra de validação encontrar um byte nulo, ela o validará como um espaço. ``` { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" } ``` **nota** `override-validation-function` não terá efeito se a coluna fizer parte da chave primária. ## Tarefas somente de validação É possível criar tarefas somente de validação para visualizar e validar os dados sem executar nenhuma migração ou replicação de dados. Para criar uma tarefa somente de validação, defina as configurações `EnableValidation` e `ValidationOnly` como `true`. Ao ativar `ValidationOnly`, requisitos adicionais se aplicam. Para obter mais informações, consulte [Configurações da tarefa de validação de dados](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Para um tipo de migração de carga máxima somente, uma tarefa somente de validação é concluída muito mais rapidamente do que a CDC equivalente quando muitas falhas são relatadas. Mas as alterações no endpoint de origem ou de destino são relatadas como falhas no modo de carga máxima, uma possível desvantagem. Uma tarefa somente de validação da CDC atrasa a validação com base na latência média e repete as falhas várias vezes antes de relatá-las. Se a maioria das comparações de dados resultar em falhas, uma tarefa somente de validação do modo CDC será muito lenta, uma desvantagem potencial. Uma tarefa somente de validação deve ser configurada na mesma direção da tarefa de replicação, especialmente para a CDC. Isso ocorre porque uma tarefa somente de validação de CDC detecta quais linhas foram alteradas e precisam ser revalidadas com base no log de alterações na origem. Se o destino for especificado como a origem, ele só saberá sobre as alterações enviadas ao destino pelo DMS e não terá a garantia de detectar erros de replicação. ### Validação somente de carga máxima A partir da AWS DMS versão 3.4.6 e superior, uma tarefa somente de validação de carga completa compara rapidamente todas as linhas das tabelas de origem e destino em uma única passagem, relata imediatamente quaisquer falhas e, em seguida, é encerrada. A validação nunca é suspensa devido a falhas nesse modo, ela é otimizada para velocidade. Mas as alterações no endpoint de origem ou de destino são relatadas como falhas. **nota** A partir da AWS DMS versão 3.4.6 e superior, esse comportamento de validação também se aplica à tarefa de migração de carga total com a validação ativada. ### Validação somente de CDC Uma tarefa somente de validação de CDC valida todas as linhas existentes entre as tabelas de origem e de destino em um novo início. Além disso, uma tarefa somente de validação de CDC é executada continuamente, revalida as alterações de replicação em andamento, limita o número de falhas relatadas em cada passagem e repete as linhas incompatíveis antes de declará-las como falhas. Ela é otimizada para evitar falsos positivos. A validação de uma tabela (ou de toda a tarefa) será suspensa se os limites de ` FailureMaxCount` ou de `TableFailureMaxCount` forem violados. Isso também se aplica a uma tarefa de migração de CDC ou de carga máxima\$1CDC com a validação ativada. E uma tarefa de CDC com validação ativada atrasa a revalidação de cada linha alterada com base na latência média de origem e de destino. Mas *tarefa de somente validação* de CDC não migra dados e não tem latência. Ela define `ValidationQueryCdcDelaySeconds` como 180 por padrão. É possível aumentar a quantidade para considerar ambientes de alta latência e ajudar a evitar falsos positivos. ### Casos de uso de somente de validação Os casos de uso para a divisão da parte de validação de dados de uma tarefa de migração ou replicação em uma *tarefa somente de validação* separada incluem, mas não estão limitados, ao seguinte: + *Controle exatamente quando a validação ocorre*: as consultas de validação adicionam uma carga extra aos endpoints de origem e de destino. Portanto, migrar ou replicar dados em uma primeira tarefa e validar os resultados em outra tarefa pode ser benéfico. + *Reduza a carga na instância de replicação*: a divisão da validação de dados para execução em sua própria instância pode ser vantajosa. + *Obtenha rapidamente quantas linhas não correspondem em um determinado momento*: por exemplo, imediatamente antes ou durante uma transição para a produção da janela de manutenção para um endpoint de destino, é possível criar uma tarefa de somente validação de carga máxima para obter uma resposta à sua pergunta. + *Quando falhas de validação são esperadas para uma tarefa de migração com um componente da CDC*: por exemplo, ao migrar o Oracle para o `varchar2` PostgreSQL`jsonb`, a validação da CDC continua repetindo essas linhas com falha e limita o número de falhas relatadas a cada vez. Porém, é possível criar uma tarefa somente de validação de carga máxima e obter uma resposta mais rápida. + *Você desenvolveu um reparo de dados script/utility que lê a tabela de falhas de validação* — (Veja também,[Solução de problemas](#CHAP_Validating.Troubleshooting)). Uma tarefa somente de validação de carga máxima relata rapidamente as falhas nas quais o script de reparo de dados deve atuar. Para obter um exemplo das configurações da tarefa `ValidationSettings` em um arquivo JSON, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)). ## Solução de problemas Durante a validação, AWS DMS cria uma nova tabela no endpoint de destino:`awsdms_control.awsdms_validation_failures_v1`. Se algum registro entrar no *ValidationFailed*estado *ValidationSuspended*ou, AWS DMS grava as informações de diagnóstico em`awsdms_control.awsdms_validation_failures_v1`. É possível consultar essa tabela para ajudar a solucionar erros de validação. Para obter informações sobre como alterar o esquema padrão em que a tabela é criada no destino, consulte [Configurações da tarefa da tabela de controle](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md). Veja a seguir uma descrição da tabela `awsdms_control.awsdms_validation_failures_v1`: | Nome da coluna | Tipo de dados | Description | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS identificador de tarefa. | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | Schema (proprietário) da tabela. | | `TABLE_NAME` | VARCHAR(128) NOT NULL | O nome da tabela. | | FAILURE\$1TIME | DATETIME(3) NOT NULL | Hora em que a falha ocorreu. | | KEY\$1TYPE | VARCHAR(128) NOT NULL | Reservado para uso futuro (o valor é sempre 'Linha') | | KEY | TEXT NOT NULL | Esta é a chave primária para o tipo de registro de linha. | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | Severidade do erro de validação. Pode ser `RECORD_DIFF`, `MISSING_SOURCE`, `MISSING_TARGET` ou `TABLE_WARNING`. | | DETAILS | VARCHAR(8000) NOT NULL | Cadeia de caracteres formatada em JSON de todos os valores da source/target coluna que não coincidem com a chave fornecida. | A consulta a seguir é um exemplo de um destino do MySQL que mostra todas as falhas de uma tarefa ao consultar a tabela `awsdms_control.awsdms_validation_failures_v1`. Observe que o nome do esquema e a sintaxe da consulta variam entre as versões do mecanismo de destino. O nome da tarefa deve ser seu ID de recurso externo. O ID de recurso externo da tarefa é o último valor em seu ARN. Por exemplo, para uma tarefa com um valor ARN de arn:aws:dms:us-west- 2:5599:task: RYSI, o ID do recurso externo da tarefa seria RYSI. VFPFKH4 FJR3 FTYKK2 VFPFKH4 FJR3 FTYKK2 ``` select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],] ``` É possível examinar o campo `DETAILS` para determinar quais colunas não correspondem. Como você tem a chave primária do registro que falhou, poderá consultar os endpoints de origem e de destino para ver qual parte do registro não corresponde. ### Tabela de controle `awsdms_validation_failures_v2` Durante a validação, na AWS DMS versão 3.6.1 e superior, o DMS cria uma nova tabela no endpoint de destino do PostgreSQL:. `awsdms_validation_failures_v2` Essa tabela consiste em falhas em todas as tarefas do DMS que têm a validação de dados habilitada. Quando a tabela `awsdms_validation_failures_v2` é criada, você não deve descartar ou truncar a tabela, pois isso pode causar erros em qualquer tarefa com validação e ressincronização habilitadas. A tabela `awsdms_validation_failures_v2` tem um recurso de chave primária de incremento automático. Essa tabela consiste em novas colunas para permitir o uso do recurso de ressincronização de dados. Eles são: `RESYNC_RESULT` **Valores**: `SUCCESS` ou `FAILURE`. **`RESYNC_TIME`** Carimbo de data/hora com precisão de milissegundos. O valor padrão é `NULL` se não houver tentativa de ressincronização de dados para essa falha. **`RESYNC_ACTION`** **Valores**: `UPSERT` ou `DELETE`. `RESYNC_ID` Coluna de chave primária com incremento automático habilitado. Na tabela `awsdms_validation_failures_v2`, um índice é adicionado às colunas `TASK_NAME`, `TABLE_OWNER`, `TABLE_NAME`, `FAILURE_TYPE` e `FAILURE_TIME` para ler com eficiência as falhas de qualquer tabela específica no banco de dados de destino. Confira abaixo um exemplo de instrução create para criar uma tabela `awsdms_validation_failures_v2`: ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Desempenho da validação do Redshift O Amazon Redshift difere dos bancos de dados relacionais em vários sentidos, como armazenamento colunar, MPP, compactação de dados e outros fatores. Essas diferenças conferem ao Redshift um perfil de desempenho distinto em relação aos bancos de dados relacionais. Durante a fase de replicação de carga máxima, a validação usa consultas de intervalo e o tamanho dos dados é controlado pela configuração `PartitionSize`. Essas consultas baseadas em intervalos selecionam todos os registros da tabela de origem. Na replicação contínua, as consultas alternam entre buscas de registros individuais e baseadas em intervalos. O tipo de consulta é determinado dinamicamente com base em vários fatores, como os seguintes: + Volume de consultas + Tipos de consulta DML na tabela de origem + Latência de tarefa + Número total de registros + Configurações de validação, como `PartitionSize` Você pode ver uma carga adicional no cluster do Amazon Redshift devido a consultas de validação. Como os fatores acima variam entre os casos de uso, você deve analisar o desempenho da consulta de validação e ajustar o cluster e a tabela adequadamente. Algumas opções para mitigar problemas de desempenho incluem o seguinte: + Reduza as configurações `ThreadCount` e `PartitionSize` para ajudar a diminuir a workload durante a validação da carga máxima. Observe que isso retardará a validação de dados. + Embora o Redshift não imponha chaves primárias, AWS DMS depende das chaves primárias para identificar de forma exclusiva os registros no destino para validação de dados. Se possível, defina a chave primária para espelhar a chave de classificação de forma que as consultas de validação de carga máxima sejam executadas mais rapidamente. ## Validação de dados aprimorada para AWS Database Migration Service AWS Database Migration Service aprimorou o desempenho de validação de dados para migrações de bancos de dados, permitindo que os clientes validem grandes conjuntos de dados com tempos de processamento significativamente mais rápidos. Essa validação aprimorada de dados já está disponível na versão 3.5.4 do mecanismo de replicação para tarefas de migração de carga máxima e carga com CDC. No momento, esse aprimoramento atende a caminhos de migração de Oracle para PostgreSQL, SQL Server para PostgreSQL, Oracle para Oracle e SQL Server para SQL Server, com caminhos de migração adicionais planejados para futuras versões. ### Pré-requisitos + *Oracle:* conceda a permissão `EXECUTE` em `SYS.DBMS_CRYPTO` para a conta de usuário que acessa o endpoint do Oracle: ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + Instale a extensão `pgcrypto` no banco de dados PostgreSQL: Para instâncias autogerenciadas do PostgreSQL, você precisa instalar as bibliotecas do módulo `contrib` e criar a extensão: + Instale as bibliotecas do módulo `contrib`. Por exemplo, em uma instância do Amazon EC2 com Amazon Linux e PostgreSQL 15: ``` sudo dnf install postgresql15-contrib ``` + Crie a extensão `pgcrypto`: ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Para instâncias do Amazon RDS for PostgreSQL, configure o modo SSL para o endpoint: AWS DMS + Por padrão, o Amazon RDS força uma conexão SSL. Ao criar um AWS DMS endpoint para uma instância do Amazon RDS for PostgreSQL, use a opção “Modo SSL” = “obrigatório”. + Se você quiser usar a opção “Modo SSL” = “nenhum”, defina o parâmetro `rds.force_ssl` como 0 no em “Grupo de parâmetros do RDS”. + Para o PostgreSQL 12 e 13, crie o agregado `BIT_XOR`: ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### Limitações de validação de dados aprimorada Esse recurso aprimorado de validação de dados tem as seguintes limitações: + Requisitos de endpoint de banco de dados: esse aprimoramento está habilitado somente para endpoints de banco de dados que atendam aos seguintes critérios: + Use AWS Secrets Manager para armazenar credenciais. + Para o Microsoft SQL Server, a autenticação Kerberos também é permitida. + Versões de banco de dados compatíveis: + PostgreSQL 12 e posterior + Oracle 12.1 e posterior + Em versões do Microsoft SQL Server anteriores a 2019, não é possível usar a validação dos tipos de dados NCHAR e NVARCHAR. ## Limitações + A validação de dados requer que a tabela tenha uma chave primária ou índice exclusivo. + As colunas de chave primária não podem ser do tipo `CLOB`, `BLOB`, `BINARY` ou `BYTE`. + Para colunas de chave primária do tipo `VARCHAR` ou `CHAR`, o comprimento deve ser inferior a 1024. Você deve especificar o tamanho no tipo de dados. Não é possível usar tipos de dados ilimitados como chave primária para validação de dados. + Uma chave do Oracle criada com a cláusula `NOVALIDATE` *não* é considerada uma chave primária ou um índice exclusivo. + Para uma tabela do Oracle sem uma chave primária e somente com uma chave exclusiva, as colunas com a restrição exclusiva também devem ter uma restrição `NOT NULL`. + A validação de PK/UK valores NULL não é suportada. + Se o agrupamento da coluna de chave primária na instância PostgreSQL de destino não for definido como "C", a ordem de classificação da chave primária será diferente da ordem de classificação em Oracle. Se a ordem de classificação for diferente entre PostgreSQL e Oracle, a validação de dados não poderá validar os registros. + A validação de dados gera consultas adicionais em relação a bancos de dados de origem e destino. Os dois bancos de dados devem ter recursos suficientes para lidar com essa carga adicional. Isso se aplica principalmente aos destinos do Redshift. Para obter mais informações, consulte [Desempenho da validação do Redshift](#CHAP_Validating.Redshift) a seguir. + A validação de dados não é compatível ao consolidar vários bancos de dados em um banco de dados. + Para um endpoint Oracle de origem ou destino, AWS DMS usa`DBMS_CRYPTO`. Se você usar a validação de dado no endpoint Oracle, deverá conceder a permissão de execução em `dbms_crypto` para a conta de usuário usada para acessar esse endpoint. Para isso, execute a seguinte instrução: ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + Se o banco de dados de destino for modificado fora da AWS DMS validação, as discrepâncias podem não ser relatadas com precisão. Esse resultado pode ocorrer se um de seus aplicativos gravar dados na tabela de destino enquanto AWS DMS estiver realizando a validação nessa mesma tabela. + Se uma ou mais linhas estiverem sendo modificadas continuamente durante a validação, não será AWS DMS possível validar essas linhas. + Se AWS DMS detectar mais de 10.000 registros com falha ou suspensos, a validação será interrompida. Antes de continuar, solucione os problemas subjacentes com os dados. + AWS DMS não oferece suporte à validação de dados de visualizações. + AWS DMS não oferece suporte à validação de dados quando as configurações da tarefa de substituição de caracteres são usadas. + AWS DMS não suporta a validação do tipo Oracle LONG. + AWS DMS não suporta a validação do tipo Oracle Spatial durante a migração heterogênea. + A validação de dados ignora as colunas nas tabelas para as quais existem transformações de mascaramento de dados no mapeamento de tabelas. + A validação de dados ignora uma tabela inteira se houver uma regra de transformação de mascaramento de dados para sua PK/UK coluna. O estado de validação será exibido como “Nenhuma chave primária” para essas tabelas. + A validação de dados não funciona com o Amazon Aurora PostgreSQL Limitless. Ao tentar validar tabelas em um banco de dados ilimitado, o estado de validação exibe “Sem chave primária” para essas tabelas. Para obter as limitações ao utilizar a validação de destino do S3, consulte [Limitações da utilização da validação de destino do S3.](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations). # Validação de dados de destino do Amazon S3 AWS DMS suporta a validação de dados replicados em destinos do Amazon S3. Como AWS DMS armazena dados replicados como arquivos simples no Amazon S3, usamos consultas do Amazon [`CREATE TABLE AS SELECT`Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) (CTAS) para validar os dados. As consultas de dados armazenados no Amazon S3 exigem uso intensivo de comutação. Assim, AWS DMS executa a validação nos dados do Amazon S3 durante a captura de dados de alteração (CDC) somente uma vez por dia, à meia-noite (00:00) UTC. Cada validação diária AWS DMS executada é chamada de *validação de intervalo*. Durante uma validação de intervalo, AWS DMS valida todos os registros de alteração que foram migrados para o bucket de destino do Amazon S3 nas últimas 24 horas. Para obter mais informações sobre as limitações de validação de intervalo, consulte [Limitações da utilização da validação de destino do S3.](#CHAP_Validating_S3_limitations). A validação de destino do Amazon S3 utiliza o Amazon Athena, portanto, custos adicionais são aplicados. Para obter mais informações, consulte [Preços do Amazon Athena](https://aws.amazon.com/athena/pricing/). **nota** A validação de destino do S3 requer a AWS DMS versão 3.5.0 ou posterior. **Topics** + [Pré-requisitos](#CHAP_Validating_S3_prerequisites) + [Permissões](#CHAP_Validating_S3_permissions) + [Limitações](#CHAP_Validating_S3_limitations) + [Tarefas somente de validação](#CHAP_Validating_S3_only) ## Pré-requisitos da validação do S3 de destino Antes de utilizar a validação de destino do S3, verifique as seguintes configurações e permissões: + Defina o valor de `DataFormat` das [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) do endpoint como `parquet`. Para obter mais informações, consulte [Configurações de parquet para S3](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet). + Verifique se o perfil atribuído à conta do usuário utilizada para criar a tarefa de migração tem o conjunto de permissões correto. Consulte [Permissões](#CHAP_Validating_S3_permissions) a seguir. Para tarefas que utilizam a replicação contínua (CDC), verifique as seguintes configurações: + Ative o registro em log suplementar para ter registros completos nos dados da CDC. Para obter informações sobre como ativar o registro em log complementar, consulte [Adição automática de registro em log complementar a um endpoint de origem Oracle](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging) na seção [Compatibilidade com a solução de problemas e diagnósticoSolução de problemas de latência](CHAP_Troubleshooting.md) deste guia. + Defina o parâmetro `TimestampColumnName` para o endpoint de destino. Não há limitações no nome da coluna de timestamp. Para obter mais informações, consulte [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html). + Configure o particionamento de pastas baseadas em data do destino. Para obter mais informações, consulte [Utilizar o particionamento de pastas com base em data](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning). ## Permissões para utilizar a validação de destino do S3 Para configurar o acesso para utilizar a validação do destino do S3, verifique se o perfil atribuído à conta de usuário utilizada para criar a tarefa de migração tem o seguinte conjunto de permissões. Substitua os valores de amostra por seus próprios valores. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## Limitações da utilização da validação de destino do S3. Visualize as seguintes limitações adicionais que se aplicam à utilização da validação de destino do S3. Para obter as limitações que se aplicam a todas as validações, consulte [Limitações](CHAP_Validating.md#CHAP_Validating.Limitations). + O valor de `DatePartitionSequence` precisa de um componente Day. A validação de destino do S3 não é compatível com o formato `YYYYMM`. + Quando a validação do intervalo está em execução durante a CDC, é possível ver erros de validação falsos na tabela `awsdms_validation_failures_v1`. Esses erros ocorrem porque AWS DMS migra as alterações que chegaram durante a validação do intervalo para a pasta de partições do dia seguinte. Normalmente, essas alterações são gravadas na pasta de partições do dia atual. Esses erros falsos são uma limitação da validação da replicação de um banco de dados de origem dinâmico para um destino estático, como o Amazon S3. Para investigar esses erros falsos, verifique os registros perto do final da janela de validação (0h UTC), que é quando esses erros normalmente aparecem. Para minimizar o número de erros falsos, verifique se o valor de `CDCLatencySource` da tarefa é baixo. Para obter informações sobre como monitorar a latência, consulte [Métricas de tarefas de replicação](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task). + As tarefas no estado `failed` ou `stopped` não validam as alterações do dia anterior. Para minimizar os erros de validação causados por falhas inesperadas, crie tarefas separadas somente de validação com os mesmos mapeamentos de tabela e endpoints de origem e de destino. Para obter mais informações sobre as tarefas de somente validação, consulte [Utilizar tarefas de somente validação com a validação do S3 de destino](#CHAP_Validating_S3_only). + A coluna **Status de validação** nas estatísticas da tabela reflete o estado da validação do intervalo mais recente. Como resultado, uma tabela com incompatibilidades pode ser mostrada como validada após a validação do intervalo do dia seguinte. Verifique `s3_validation_failures folder` no bucket do Amazon S3 de destino para obter as incompatibilidades que ocorreram há mais de um dia. + A validação do S3 usa o recurso de tabela com buckets do Amazon Athena. Isso permite que a validação do S3 faça uma cópia com buckets dos dados da tabela de destino. Isso significa que a cópia dos dados da tabela é dividida em subconjuntos que correspondem ao particionamento interno da validação do DMS. As tabelas com buckets do Athena têm um limite de 100.000 buckets. Todas as tabelas que a validação do S3 tentar validar que excedam esse limite falharão na validação. O número de buckets que a validação do S3 tenta criar é igual ao seguinte: ``` (#records in the table) / (validation partition size setting) ``` Para contornar essa limitação, aumente a configuração do tamanho do particionamento da validação para que o número de buckets criados pela validação do S3 seja inferior a 100.000. Para ter mais informações sobre o armazenamento em bucket, consulte [Usar particionamento e bucketing](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html) no *Guia do usuário do Amazon Athena*. + O nome da tabela não deve conter caracteres especiais, exceto sublinhado. A validação do S3 usa o Amazon Athena, que não permite caracteres especiais (exceto sublinhado) nos nomes de tabela. Para ter mais informações, consulte o tópico [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) no *Guia do usuário do Amazon Athena*. + Quando o recurso de validação de AWS DMS dados é usado com um alvo do Amazon S3 gerenciado pela AWS Lake Formation, o processo de validação falha. Isso pode provocar problemas de consistência de dados. ## Utilizar tarefas de somente validação com a validação do S3 de destino Uma *tarefa somente de validação* executa a validação nos dados que devem ser migrados sem executar a migração. As tarefas somente de validação continuam sendo executadas, mesmo que a tarefa de migração seja interrompida, o que garante que AWS DMS ela não perca a janela de validação do intervalo de 00:00 UTC. A utilização de tarefas de somente validação com os endpoints de destino do Amazon S3 apresenta as seguintes limitações: + A validação de tarefas de carga máxima do Amazon S3 com a configuração somente validação habilitada é compatível, mas opera de forma diferente das tarefas de carga máxima e somente de validação de outros endpoints. Para o S3 como destino, uma tarefa desse tipo valida somente com base nos dados de carga máxima no destino do S3 e não validará em relação a nenhum dado migrado como parte de uma migração de CDC. Utilize esse recurso somente para validar os dados criados por uma tarefa somente de carga máxima. A utilização desse modo para validar os dados em um destino que tenha uma tarefa de CDC ativa em execução não produzirá uma validação eficaz. + As tarefas somente de validação validam somente as alterações desde a última janela de validação do intervalo (0h UTC). As tarefas de somente validação não validam dados de carga máxima ou de dados de CDC de dias anteriores. # AWS DMS ressincronização de dados AWS Database Migration Service (AWS DMS) A ressincronização de dados corrige automaticamente as inconsistências de dados identificadas por meio da validação de dados entre seus bancos de dados de origem e de destino. Esse recurso funciona como parte das tarefas existentes de migração do DMS, garantindo que as atualizações adequadas ocorram com base nas configurações de tarefa, configurações de conexão, mapeamentos de tabelas e transformações. O recurso de ressincronização de dados lê as falhas de validação de uma tabela de controle no banco de dados de destino e executa as operações de correção apropriadas. Quando uma incompatibilidade é detectada, os dados atuais são recuperados da origem usando a chave primária armazenada no registro de falhas e aplicados ao destino, respeitando todas as transformações configuradas. Para obter mais informações, consulte [Tabela de controle `awsdms_validation_failures_v2`](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table). O comportamento varia de acordo com o tipo de migração. Para full-load-only tarefas, a ressincronização de dados é executada uma vez após a conclusão do carregamento inicial e da validação. Quanto às tarefas com captura de dados de alteração (CDC), a ressincronização de dados opera de acordo com uma programação configurada, pausando temporariamente a replicação e a validação enquanto as correções são aplicadas. Durante as operações de ressincronização de CDC: + A replicação e a validação são pausadas temporariamente. + A ressincronização de dados processa as falhas de validação existentes. + A replicação e validação normais são retomadas. + O processo se repete com base na programação configurada. A ressincronização de dados rastreia automaticamente o status de cada operação de correção e fornece métricas detalhadas por meio de estatísticas de tabela. **Pré-requisitos:** O recurso de ressincronização de dados precisa que os seguintes pré-requisitos sejam atendidos: + Você deve ter a versão 3.6.1 ou posterior do AWS DMS motor. + Você deve definir as configurações de cronograma e duração para tarefas que tenham replicação contínua. Tarefas somente de carga máxima não exigem essas configurações. ## Limitações Esse recurso tem as seguintes limitações: + A ressincronização de dados pode ser usada somente no Oracle e SQL Server como banco de dados de origem. + A ressincronização de dados pode ser usada no PostgreSQL e Amazon Aurora para PostgreSQL como banco de dados de destino. + Todas as tabelas no banco de dados de origem e destino devem ter chaves primárias. A validação não aceita tabelas sem uma chave primária ou uma chave exclusiva. Todas as tabelas que não têm uma chave primária ou exclusiva válida são suspensas da validação e nenhuma falha de validação é relatada. + Ao executar Full-load-only tarefas, a validação de dados deve ser ativada. + A ressincronização de dados não pode ser habilitada para a tarefas somente de validação, pois elas não replicam nenhum dado. Você pode habilitar a ressincronização na tarefa de replicação principal fornecendo o `taskID` da tarefa somente de validação. Para ter mais informações, consulte [Tarefas somente de validação](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly). + Se a tarefa somente de validação tiver uma configuração de parâmetros `ControlSchema` definida nas respectivas configurações de tarefa, a tarefa de replicação também deverá ter a mesma configuração de parâmetros para que a ressincronização de dados encontre as falhas de validação corretas. + Você deve definir as configurações de cronograma e duração para tarefas de CDC. + Durante a janela de ressincronização, a ressincronização de dados pode ter um impacto na latência de replicação no DMS. [Para obter mais informações sobre a solução de problemas de validação AWS DMS durante a ressincronização de dados, consulte a seção [AWS DMS Solução](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) de problemas em Validação de dados.](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) ## Programação e cronograma Para tarefas com CDC, você deve configurar quando e por quanto tempo a ressincronização de dados deve operar. Isso ajuda a evitar o impacto em suas operações normais de replicação. Você deve especificar: + Um cronograma usando o formato cron para definir quando as operações de ressincronização podem ocorrer. + Uma duração máxima para garantir que as operações de ressincronização não se estendam até os períodos de pico de uso. Convém programar as operações de ressincronização fora do horário de pico ou para um período em que haja pouca ou nenhuma alteração no banco de dados de origem. **nota** O tempo programado inclui aguardar que a aplicação de fluxo do destino fique vazia, pois a ressincronização de dados e a replicação normal não podem ser executadas simultaneamente. ## Casos de uso O recurso de ressincronização de dados permite que os usuários reconciliem inconsistências de dados entre os sistemas de origem e de destino. Ele identifica registros incompatíveis e os sincroniza para manter a consistência de dados em ambientes distribuídos. Os seguintes casos de uso demonstram cenários comuns em que o recurso de ressincronização de dados resolve os desafios de consistência de dados: **Cenário 1: tarefa de carga máxima (executar a ressincronização usando a mesma tarefa do DMS)** Em sua atual tarefa de migração de carga máxima do DMS, você pode fazer o seguinte: + Habilite a validação: `Validation with data migration = true`. + Habilite a ressincronização: `Data resync = true`. **Cenário 2: tarefa de carga máxima e CDC e somente de CDC (executar a ressincronização usando a mesma tarefa do DMS)** Em sua atual tarefa de migração de CDC do DMS, você pode fazer o seguinte: + Habilite a validação: `Validation with data migration = true`. + Habilite a ressincronização: `Data resync = true`. + Especifique o cronograma de ressincronização: `"ResyncSchedule": "0 0,2,4,6 * * *"`. + Especifique o tempo de ressincronização: `MaxResyncTime": 60`. **Cenário 3: tarefa de carga máxima e CDC ou somente de CDC para replicação e ressincronização, associada a uma tarefa somente de validação** Para realizar uma operação somente de validação em outra tarefa do DMS ao utilizar a ressincronização, você pode fazer o seguinte: + Crie uma tarefa somente de validação de CDC do DMS. **nota** Você deve anotar e especificar o ID dessa tarefa durante a ressincronização de dados. + Em sua tarefa principal de CDC, desabilite a validação: `Data validation = false`. + Habilite a ressincronização: `Data resync = true`. + Especifique o cronograma de ressincronização: `"ResyncSchedule": "0 0,2,4,6 * * *"`. + Especifique o tempo de ressincronização: `MaxResyncTime": 60`. + Especifique o ID da tarefa somente de validação de CDC do DMS. Somente o ID da tarefa de validação é anexado ao final do ARN. Exemplo de ARN (`arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`) e exemplo de ID de tarefa somente de validação (`6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`). ## Práticas recomendadas Você pode aproveitar o recurso de ressincronização de dados AWS Database Migration Service para melhorar a durabilidade de suas tarefas de replicação e obter consistência. Algumas das práticas recomendadas para usar o recurso de ressincronização de dados são: + Como parte da ressincronização de dados, para corrigir os registros que apresentam divergências, eles devem ser procurados na origem e aplicados no banco de dados de destino. Se o banco de dados de origem for atualizado durante a janela de ressincronização, a ressincronização lerá o valor do registro mais recente e o aplicará no destino. Isso pode fazer com que os eventos de aplicação de CDC falhem e introduzam inconsistências temporárias no banco de dados de destino. Para evitar isso, programe a janela de ressincronização fora do horário comercial ou períodos em que as alterações no banco de dados de origem sejam zero ou mínimas. + Configure a janela de ressincronização durante períodos de atividade mínima do banco de dados de origem e dentro do limite aceitável de latência pretendido. Os pequenos intervalos de ressincronização podem causar acúmulo de incompatibilidades de validação não processadas, enquanto janelas grandes podem aumentar a latência de replicação quando ocorrem muitas falhas de validação. Monitore as falhas de validação e as taxas de ressincronização para determinar as janelas de ressincronização ideais durante os períodos de inatividade da origem. Alguns exemplos para configurar as janelas de ressincronização são: + Configuração de várias janelas curtas: ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + Configuração de janela única diária: ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + Monitore a latência da replicação no DMS durante as janelas de ressincronização e ajuste o cronograma adequadamente para mitigar grandes picos. + Você pode analisar os resultados da ressincronização por meio da estatística da tabela ou consultando a tabela `awsdms_validation_failures_v2` no banco de dados de destino. Para obter mais informações, consulte [Monitoramento de tarefas de replicação usando a Amazon CloudWatch](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch). + Quando a tarefa estiver em uma fase de replicação contínua, evite iniciar uma recarga para tabelas individuais durante a janela de ressincronização. + Práticas recomendadas para uma tarefa de replicação de CDC: + Todas as tabelas em seu banco de dados concluem o processo de carregamento. + As incompatibilidades são identificadas no processo de validação em andamento. + De acordo com a janela programada de ressincronização, a tarefa de replicação é pausada por um breve período. + A ressincronização de dados corrige os problemas identificados durante o processo de validação. + O processo de replicação é retomado e repetido de acordo com o cronograma. ## Configuração e exemplos de ressincronização de dados **Configuração das definições de ressincronização de dados**: É possível configurar a ressincronização para sua tarefa de replicação no DMS. Confira abaixo um exemplo de configuração de definições de ressincronização de dados em uma tarefa: ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **Exemplos de padrões comuns de programação de ressincronização**: + `0 0 * * *`: execute uma vez por dia à meia-noite. + `0 0,12 * * *`: execute duas vezes por dia à meia-noite e ao meio-dia. + `0 0,2,4,6, * * *`: executa a cada duas horas, entre meia-noite e 6h. + `0 1 * * 1`: execute todas as semanas às segundas-feiras à 1h. **nota** Especificar um número para cada dia, começando de 0 a 6. Para ter mais informações, consulte [Regras de expressão cron](#CHAP_DataResync.cron). **Monitorar as operações de ressincronização**: É possível monitorar a operação de ressincronização por meio das estatísticas da tabela. Abaixo é apresentado um exemplo de saída: ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` Para configurar o recurso de ressincronização de dados em AWS DMS, você pode revisar vários parâmetros de ressincronização e suas respectivas configurações. Para obter mais informações, consulte [Configurações de ressincronização de dados](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md). Para saber mais sobre as configurações de registro em log de ressincronização de dados, consulte [Configurações de registro de tarefa](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md). ## Validação e solução de problemas **Validação**: Quando a validação de dados está ativada, AWS DMS cria uma tabela de falhas de validação em seu banco de dados de destino com a seguinte estrutura: ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL ); ``` Você pode escrever uma consulta nessa tabela para entender as incompatibilidades de dados encontradas e como elas são resolvidas. Quando a validação está ativada, AWS DMS cria uma tabela de falhas de validação no banco de dados de destino. Se encontrar algum problema, você pode consultar a tabela `awsdms_control.awsdms_validation_failures_v2` para entender as incompatibilidades de dados encontradas e como elas são resolvidas. Para ter mais informações, consulte a seção [Solucionar problemas](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) em [Validação de dados do AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html). **Fluxo de trabalho comum**: Durante a validação na ressincronização de dados, o fluxo de trabalho padrão é o seguinte: **Tarefas somente de carga máxima**: 1. Todas as tabelas em seu banco de dados concluem o processo de carregamento. 1. As incompatibilidades são identificadas no processo de validação em andamento. 1. A ressincronização de dados corrige os problemas identificados durante o processo de validação. 1. O processo de validação valida a retificação. 1. A tarefa de migração é concluída com êxito. **Tarefas de CDC**: 1. Todas as tabelas em seu banco de dados concluem o processo de carregamento. 1. As incompatibilidades são identificadas no processo de validação em andamento. 1. De acordo com a janela programada de ressincronização, a tarefa de replicação é pausada por um breve período. 1. A ressincronização de dados corrige os problemas identificados durante o processo de validação. 1. O processo de replicação é retomado e repetido de acordo com o cronograma. Qualquer modificação feita na tarefa, como interromper a tarefa de replicação durante a operação de ressincronização ou recarregar e revalidar tabelas, pode afetar o comportamento e o resultado da tarefa. Algumas das mudanças de comportamento conhecidas são as seguintes: **Quando você interrompe a tarefa de replicação enquanto a operação de ressincronização está em andamento**: + A operação de ressincronização não é retomada automaticamente. Você deve iniciá-la novamente. + As futuras operações de ressincronização ocorrerão de acordo com o cronograma configurado. + Todas as correções incompletas são tentadas na próxima janela de programada de ressincronização. **Quando você recarrega uma tabela no banco de dados**: + A operação de ressincronização ignora qualquer tabela que esteja sendo recarregada. + As falhas de validação anteriores de uma tabela que foi recarregada são ignoradas. + A nova validação começa após a conclusão da ação de recarregamento. **Quando você recarrega revalida uma tabela no banco de dados**: + Todas as estatísticas da operação de ressincronização são redefinidas. + As falhas de validação anteriores de uma tabela que foi revalidada são ignoradas. **nota** Ao atualizar ou mover uma tarefa para a versão 3.6.1 e posterior do DMS, qualquer falha na tabela `awsdms_control.awsdms_validation_failures_v1` não é ressincronizada. Somente falhas na tabela `awsdms_validation_failures_v2` são ressincronizadas. Para ressincronizar falhas na tabela `awsdms_control.awsdms_validation_failures_v2`, você deve recarregar a tarefa, recarregar uma ou mais tabelas na tarefa ou revalidar uma ou mais tabelas. Para obter mais informações, consulte os seguintes links: Para recarregar uma tarefa, consulte a [Referência da API `StartReplicationTask`](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html). Para recarregar uma ou mais tabelas em uma tarefa, consulte [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) na documentação *Referência de comandos da AWS CLI*. Para revalidar uma ou mais tabelas, consulte a opção `validate-only` na seção [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) na documentação *Referência de comandos da AWS CLI*. . ## Regras de expressão cron Para configurar as operações de ressincronização de dados durante uma tarefa de replicação, AWS DMS você pode usar regras de expressões cron. Essas regras permitem personalizar as janelas de tempo de ressincronização e programá-las de acordo com suas necessidades comerciais. Você pode usar vários parâmetros, como minutos, horas, dias, meses e dias da semana. As regras de expressão cron para cada parâmetro são: **Minutos**: + Intervalo de minutos de 0 a 59. + Você pode usar (`-`), `or`/`and` para especificar o intervalo. Máximo de dez itens separados por vírgula (`,`). + **Exemplos:** + `2-5` é igual a `2,3,5,5`. + `1-2,3-4,5,7-10` é um intervalo válido. + `1,2,3,4,5,6,7,8,9,10` é um intervalo válido. + `1,2,3,4,5,6,7,8,9,10,11` não é um intervalo válido. A operação de ressincronização pula após o décimo item do intervalo. + Você pode usar (`*`). Exemplo: `*` é igual a `0-59`. + Você pode usar (`/`) somente com (`-`) ou (`*`). **Exemplos:** + `2-7/2` é igual a `2,4,6`. + `*/15` é igual a `0,15,30,45`. **Horas**: O mesmo que “**Minutos**”, mas o intervalo válido é de `0` a `23`. **Dias**: + O mesmo que “**Minutos**”, mas o intervalo válido é de `1` a `31`. + É possível usar `L` na configuração de ressincronização. Ele é interpretado como último dia do mês. Você não deve usá-lo com outra sintaxe. **Meses**: O mesmo que “**Minutos**”, mas o intervalo válido é de `1` a `12`. **Dias da semana**: + O mesmo que “**Minutos**”, mas o intervalo válido é de `0` a `6`. + Não é possível adicionar um valor de string para o nome da semana.