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á.
# Especificando configurações de tarefas para tarefas do AWS Database Migration Service
Cada tarefa tem configurações que podem ser definidas de acordo com as necessidades da migração do banco de dados. Você cria essas configurações em um arquivo JSON ou, com algumas configurações, pode especificar as configurações usando o AWS DMS console. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
Há vários tipos principais de configurações de tarefa, conforme listado a seguir.
**Topics**
+ [
## Exemplo de configurações de tarefas
](#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)
+ [
# Configurações de tarefa de metadados de destino
](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md)
+ [
# Configurações de tarefa de carregamento completo
](CHAP_Tasks.CustomizingTasks.TaskSettings.FullLoad.md)
+ [
# Configurações de tarefa do Time Travel
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.md)
+ [
# Configurações de registro de tarefa
](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)
+ [
# Configurações de tarefa de tabela de controle
](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md)
+ [
# Configurações de tarefas de buffer de stream
](CHAP_Tasks.CustomizingTasks.TaskSettings.StreamBuffer.md)
+ [
# Configurações de ajuste de processamento de alterações
](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md)
+ [
# Configurações da tarefa de validação de dados
](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)
+ [
# Configurações de ressincronização de dados
](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md)
+ [
# Configurações de tarefa para processamento de DDL de processamento de alterações
](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md)
+ [
# Configurações da tarefa de substituição de caracteres
](CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.md)
+ [
# Configurações de tarefa de imagem anterior
](CHAP_Tasks.CustomizingTasks.TaskSettings.BeforeImage.md)
+ [
# Configurações de tarefa de tratamento de erros
](CHAP_Tasks.CustomizingTasks.TaskSettings.ErrorHandling.md)
+ [
# Salvar configurações de tarefa
](CHAP_Tasks.CustomizingTasks.TaskSettings.Saving.md)
| Configurações de tarefa | Documentação relevante |
| --- | --- |
| **Criar um relatório de avaliação de tarefa** É possível criar um relatório de avaliação de tarefa que mostre os tipos de dados incompatíveis, que podem causar problemas durante a migração. É possível executar esse relatório na tarefa antes de executá-la, para descobrir possíveis problemas. | [Ativar e trabalhar com avaliações de pré-migração de uma tarefa](CHAP_Tasks.AssessmentReport.md) |
| **Criar uma tarefa** Quando você cria uma tarefa, especifica a origem, o destino e a instância de replicação, juntamente com todas as configurações de migração. | [Criar uma tarefa](CHAP_Tasks.Creating.md) |
| **Criar uma tarefa de replicação contínua** Você pode configurar uma tarefa para fornecer replicação contínua entre a origem e o destino. | [Criação de tarefas para replicação contínua usando AWS DMS](CHAP_Task.CDC.md) |
| **Aplicar as configurações de tarefas** Cada tarefa tem configurações que podem ser definidas de acordo com as necessidades da migração do banco de dados. Você cria essas configurações em um arquivo JSON ou, com algumas configurações, pode especificar as configurações usando o AWS DMS console. | [Especificando configurações de tarefas para tarefas do AWS Database Migration Service](#CHAP_Tasks.CustomizingTasks.TaskSettings) |
| **Validação de dados** Use a validação de dados para AWS DMS comparar os dados do seu armazenamento de dados de destino com os dados do seu armazenamento de dados de origem. | [AWS Validação de dados do DMS](CHAP_Validating.md) |
| **Modificar uma tarefa** Quando uma tarefa é interrompida, é possível modificar as configurações dela. | [Modificar uma tarefa](CHAP_Tasks.Modifying.md) |
| **Recarregar tabelas durante uma tarefa** Você poderá recarregar uma tabela durante uma tarefa se ocorrer um erro durante sua execução. | [Recarregar tabelas durante uma tarefa](CHAP_Tasks.ReloadTables.md) |
| **Utilizar mapeamento de tabela** O mapeamento de tabela utiliza vários tipos de regras para especificar as configurações da fonte de dados, do esquema de origem, dos dados e de quaisquer transformações que devem ocorrer durante a tarefa. | Regras de seleção [Regras de seleção e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md) Regras de transformação [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md) |
| **Aplicar filtros** É possível usar filtros de origem para limitar o número e o tipo de registros transferidos da origem ao destino. Por exemplo, você pode especificar que somente os funcionários localizados na sede serão movidos para o banco de dados de destino. Os filtros são aplicados a uma coluna de dados. | [Usar filtros de origem](CHAP_Tasks.CustomizingTasks.Filters.md) |
| Monitorar uma tarefa Há várias maneiras de obter informações sobre o desempenho de uma tarefa e das tabelas usadas por ela. | [Monitorando AWS tarefas do DMS](CHAP_Monitoring.md) |
| Gerenciar logs de tarefas Você pode visualizar e excluir registros de tarefas usando a AWS DMS API ou AWS CLI. | [Visualizando e gerenciando registros AWS de tarefas do DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) |
## Exemplo de configurações de tarefas
Você pode usar o Console de gerenciamento da AWS ou o AWS CLI para criar uma tarefa de replicação. Se você usar o AWS CLI, defina as configurações da tarefa criando um arquivo JSON e especificando o URI file://do arquivo JSON como [ ReplicationTaskSettings](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html#DMS-CreateReplicationTask-request-ReplicationTaskSettings)parâmetro da operação. [CreateReplicationTask](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html)
O exemplo a seguir mostra como usar o AWS CLI para chamar a `CreateReplicationTask` operação:
```
aws dms create-replication-task \
--replication-task-identifier MyTask \
--source-endpoint-arn arn:aws:dms:us-west-2:123456789012:endpoint:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \
--target-endpoint-arn arn:aws:dms:us-west-2:123456789012:endpoint:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \
--replication-instance-arn arn:aws:dms:us-west-2:123456789012:rep:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \
--migration-type cdc \
--table-mappings file://tablemappings.json \
--replication-task-settings file://settings.json
```
O exemplo anterior utiliza um arquivo de mapeamento de tabela chamado`tablemappings.json`. Para ver exemplos de mapeamento de tabela, consulte [Utilizar o mapeamento de tabela para especificar as configurações da tarefa](CHAP_Tasks.CustomizingTasks.TableMapping.md).
Um arquivo JSON de configurações de tarefas pode ter a seguinte aparência:
```
{
"TargetMetadata": {
"TargetSchema": "",
"SupportLobs": true,
"FullLobMode": false,
"LobChunkSize": 64,
"LimitedSizeLobMode": true,
"LobMaxSize": 32,
"InlineLobMaxSize": 0,
"LoadMaxFileSize": 0,
"ParallelLoadThreads": 0,
"ParallelLoadBufferSize":0,
"ParallelLoadQueuesPerThread": 1,
"ParallelApplyThreads": 0,
"ParallelApplyBufferSize": 100,
"ParallelApplyQueuesPerThread": 1,
"BatchApplyEnabled": false,
"TaskRecoveryTableEnabled": false
},
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
"StopTaskCachedChangesApplied": false,
"StopTaskCachedChangesNotApplied": false,
"MaxFullLoadSubTasks": 8,
"TransactionConsistencyTimeout": 600,
"CommitRate": 10000
},
"TTSettings" : {
"EnableTT" : true,
"TTS3Settings": {
"EncryptionMode": "SSE_KMS",
"ServerSideEncryptionKmsKeyId": "arn:aws:kms:us-west-2:112233445566:key/myKMSKey",
"ServiceAccessRoleArn": "arn:aws:iam::112233445566:role/dms-tt-s3-access-role",
"BucketName": "myttbucket",
"BucketFolder": "myttfolder",
"EnableDeletingFromS3OnTaskDelete": false
},
"TTRecordSettings": {
"EnableRawData" : true,
"OperationsToLog": "DELETE,UPDATE",
"MaxRecordSize": 64
}
},
"Logging": {
"EnableLogging": false
},
"ControlTablesSettings": {
"ControlSchema":"",
"HistoryTimeslotInMinutes":5,
"HistoryTableEnabled": false,
"SuspendedTablesTableEnabled": false,
"StatusTableEnabled": false
},
"StreamBufferSettings": {
"StreamBufferCount": 3,
"StreamBufferSizeInMB": 8
},
"ChangeProcessingTuning": {
"BatchApplyPreserveTransaction": true,
"BatchApplyTimeoutMin": 1,
"BatchApplyTimeoutMax": 30,
"BatchApplyMemoryLimit": 500,
"BatchSplitSize": 0,
"MinTransactionSize": 1000,
"CommitTimeout": 1,
"MemoryLimitTotal": 1024,
"MemoryKeepTime": 60,
"StatementCacheSize": 50
},
"ChangeProcessingDdlHandlingPolicy": {
"HandleSourceTableDropped": true,
"HandleSourceTableTruncated": true,
"HandleSourceTableAltered": true
},
"LoopbackPreventionSettings": {
"EnableLoopbackPrevention": true,
"SourceSchema": "LOOP-DATA",
"TargetSchema": "loop-data"
},
"CharacterSetSettings": {
"CharacterReplacements": [ {
"SourceCharacterCodePoint": 35,
"TargetCharacterCodePoint": 52
}, {
"SourceCharacterCodePoint": 37,
"TargetCharacterCodePoint": 103
}
],
"CharacterSetSupport": {
"CharacterSet": "UTF16_PlatformEndian",
"ReplaceWithCharacterCodePoint": 0
}
},
"BeforeImageSettings": {
"EnableBeforeImage": false,
"FieldName": "",
"ColumnFilter": "pk-only"
},
"ErrorBehavior": {
"DataErrorPolicy": "LOG_ERROR",
"DataTruncationErrorPolicy":"LOG_ERROR",
"DataMaskingErrorPolicy": "STOP_TASK",
"DataErrorEscalationPolicy":"SUSPEND_TABLE",
"DataErrorEscalationCount": 50,
"TableErrorPolicy":"SUSPEND_TABLE",
"TableErrorEscalationPolicy":"STOP_TASK",
"TableErrorEscalationCount": 50,
"RecoverableErrorCount": 0,
"RecoverableErrorInterval": 5,
"RecoverableErrorThrottling": true,
"RecoverableErrorThrottlingMax": 1800,
"ApplyErrorDeletePolicy":"IGNORE_RECORD",
"ApplyErrorInsertPolicy":"LOG_ERROR",
"ApplyErrorUpdatePolicy":"LOG_ERROR",
"ApplyErrorEscalationPolicy":"LOG_ERROR",
"ApplyErrorEscalationCount": 0,
"FullLoadIgnoreConflicts": true
},
"ValidationSettings": {
"EnableValidation": false,
"ValidationMode": "ROW_LEVEL",
"ThreadCount": 5,
"PartitionSize": 10000,
"FailureMaxCount": 1000,
"RecordFailureDelayInMinutes": 5,
"RecordSuspendDelayInMinutes": 30,
"MaxKeyColumnSize": 8096,
"TableFailureMaxCount": 10000,
"ValidationOnly": false,
"HandleCollationDiff": false,
"RecordFailureDelayLimitInMinutes": 1,
"SkipLobColumns": false,
"ValidationPartialLobSize": 0,
"ValidationQueryCdcDelaySeconds": 0
}
}
```
# Configurações de tarefa de metadados de destino
As configurações de metadados de destino incluem: Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
+ `TargetSchema`: o nome do esquema da tabela de destino. Se essa opção de metadados estiver vazia, o esquema da tabela de origem será utilizado. O AWS DMS adicionará automaticamente o prefixo do proprietário do banco de dados de destino a todas as tabelas se não houver esquema de origem definido. Essa opção deve ficar vazia para endpoints de destino do tipo MySQL. A renomeação de um esquema no mapeamento de dados tem precedência sobre essa configuração.
+ Configurações de LOB — Configurações que determinam como objetos grandes (LOBs) são gerenciados. Se você definir `SupportLobs=true`, defina um dos seguintes como `true`:
+ `FullLobMode`: se você definir esta opção como `true`, insira um valor para a opção `LobChunkSize`. Insira o tamanho, em kilobytes, dos blocos de LOB a serem utilizados durante a replicação dos dados para o destino. A opção `FullLobMode` funciona melhor para tamanhos de LOB muito grandes, mas costuma deixar o carregamento mais lento. O valor recomendado para `LobChunkSize` é 64 kilobytes. Aumentar o valor de `LobChunkSize` acima de 64 kilobytes pode causar falhas na tarefa.
+ `InlineLobMaxSize`— Esse valor determina quais LOBs AWS DMS transferências em linha durante uma carga completa. Transferir pequenos LOBs é mais eficiente do que pesquisá-los em uma tabela de origem. Durante uma carga completa, AWS DMS verifica tudo LOBs e executa uma transferência em linha para aqueles LOBs que são menores que`InlineLobMaxSize`. AWS DMS transferências todas LOBs maiores do que a `InlineLobMaxSize` entrada`FullLobMode`. O valor padrão de `InlineLobMaxSize` é 0, e o intervalo é de 1 a 102400 kilobytes (100 MB). Defina um valor `InlineLobMaxSize` somente se você souber que a LOBs maioria deles é menor do que o valor especificado em`InlineLobMaxSize`.
+ `LimitedSizeLobMode`: se você definir esta opção como `true`, insira um valor para a opção `LobMaxSize`. Insira o tamanho máximo, em kilobytes, de um LOB individual. O valor máximo recomendado para `LobMaxSize` é 102.400 kilobytes (100 MB).
Para obter mais informações sobre os critérios para utilização dessas configurações de LOB de tarefa, consulte [Configurando o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md). Você também pode controlar o gerenciamento LOBs de tabelas individuais. Para obter mais informações, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
+ `BatchApplyEnabled`: determina se cada transação é aplicada individualmente ou se as alterações são confirmadas em lotes. O valor padrão é `false`.
Quando `BatchApplyEnabled` está definido como `true`, o DMS exige uma chave primária (PK) ou uma chave exclusiva (UK) na(s) tabela(s) de **origem**. Sem uma PK ou UK nas tabelas de origem, somente as inserções em lote são aplicadas, mas não atualizações e exclusões em lote.
Quando `BatchApplyEnabled` está definido como `true`, o AWS DMS gerará uma mensagem de erro se uma tabela de **destino** tiver uma restrição exclusiva e uma chave primária. Tabelas de destino com uma restrição exclusiva e uma chave primária não são compatíveis quando `BatchApplyEnabled` está definida como `true`.
Quando `BatchApplyEnabled` é definida como verdadeira e AWS DMS encontra um erro de dados em uma tabela com a política padrão de tratamento de erros, a AWS DMS tarefa muda do modo em lote para o modo do resto das tabelas. one-by-one Para alterar esse comportamento, é possível definir a ação `"SUSPEND_TABLE"` nas seguintes políticas na propriedade de grupo `"ErrorBehavior"` grupo do arquivo JSON de configurações da tarefa:
+ `DataErrorPolicy`
+ `ApplyErrorDeletePolicy`
+ `ApplyErrorInsertPolicy`
+ `ApplyErrorUpdatePolicy`
Para obter mais informações sobre essa propriedade de grupo `"ErrorBehavior"`, consulte o exemplo de arquivo JSON de configurações de tarefas em [Especificando configurações de tarefas para tarefas do AWS Database Migration Service](CHAP_Tasks.CustomizingTasks.TaskSettings.md). Depois de definir essas políticas como`"SUSPEND_TABLE"`, a AWS DMS tarefa suspende os erros de dados em todas as tabelas que os geram e continua no modo em lote para todas as tabelas.
É possível utilizar o parâmetro `BatchApplyEnabled` com o parâmetro `BatchApplyPreserveTransaction`. Se `BatchApplyEnabled` estiver definido como `true`, o parâmetro `BatchApplyPreserveTransaction` determinará a integridade transacional.
Se `BatchApplyPreserveTransaction` estiver definido como `true`, a integridade transacional será preservada e será garantido que um lote contenha todas as alterações dentro de uma transação da origem.
Se `BatchApplyPreserveTransaction` estiver definido como `false`, poderá haver lapsos temporários na integridade transacional para melhorar o desempenho.
O parâmetro `BatchApplyPreserveTransaction` se aplica somente aos endpoints de destino Oracle e só será relevante quando o parâmetro `BatchApplyEnabled` estiver definido como `true`.
Quando colunas de LOB estiverem incluídas na replicação, é possível utilizar `BatchApplyEnabled` somente no modo LOB limitado.
Para obter mais informações sobre como utilizar essas configurações para uma carga de captura de dados de alteração (CDC), consulte [Configurações de ajuste de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ `MaxFullLoadSubTasks`: indica o número máximo de tabelas a serem carregadas em paralelo. O padrão é 8; o valor máximo é 49.
+ `ParallelLoadThreads`— Especifica o número de threads AWS DMS usados para carregar cada tabela no banco de dados de destino. Esse parâmetro tem valores máximos para destinos não RDBMS. O valor máximo para um destino do DynamoDB é 200. O valor máximo para uma meta do Amazon Kinesis Data Streams, Apache Kafka ou OpenSearch Amazon Service é 32. É possível pedir um aumento desse limite máximo. `ParallelLoadThreads`aplica-se às tarefas de carga máxima. Para obter informações sobre as configurações para o carregamento paralelo de tabelas individuais, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
Essa configuração se aplica aos seguintes tipos de mecanismo de endpoint:
+ DynamoDB
+ Amazon Kinesis Data Streams
+ Amazon MSK
+ OpenSearch Serviço Amazon
+ banco de dados de origem
AWS DMS suporta `ParallelLoadThreads` o MySQL como um atributo de conexão extra. `ParallelLoadThreads`não se aplica ao MySQL como uma configuração de tarefa.
+ `ParallelLoadBufferSize` especifica o número máximo de registros a serem armazenados em buffer que os threads de carga paralela utilizam para carregar dados no destino. O valor padrão é 50. Valor máximo de 1.000. No momento, essa configuração só é válida quando DynamoDB, Kinesis, Apache Kafka ou é o destino. OpenSearch Utilize esse parâmetro com `ParallelLoadThreads`. `ParallelLoadBufferSize` é válido somente quando há mais de um thread. Para obter informações sobre as configurações para o carregamento paralelo de tabelas individuais, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
+ `ParallelLoadQueuesPerThread`: especifica o número de filas que cada thread simultâneo acessa para extrair registros de dados das filas e gerar uma carga em lote para o destino. O padrão é um. Essa configuração é válida somente quando o Kinesis ou o Apache Kafka é o destino.
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos que são AWS DMS usados durante um carregamento do CDC para enviar registros de dados para um endpoint de destino do Amazon DocumentDB, Kinesis, Amazon MSK ou Amazon Redshift. OpenSearch O padrão é zero (0).
Essa configuração só se aplica à CDC. Esta configuração não se aplica à carga máxima.
Essa configuração se aplica aos seguintes tipos de mecanismo de endpoint:
+ Amazon DocumentDB (compatível com MongoDB)
+ Amazon Kinesis Data Streams
+ Amazon Managed Streaming for Apache Kafka
+ OpenSearch Serviço Amazon
+ banco de dados de origem
+ `ParallelApplyBufferSize`— Especifica o número máximo de registros a serem armazenados em cada fila de buffer para que threads simultâneos sejam enviados para um endpoint de destino do Amazon DocumentDB, Kinesis, Amazon MSK ou OpenSearch Amazon Redshift durante um carregamento do CDC. O valor padrão é 100. O valor máximo é 1000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`— Especifica o número de filas que cada thread acessa para retirar registros de dados das filas e gerar uma carga em lote para um Amazon DocumentDB, Kinesis, Amazon MSK ou endpoint durante o CDC. OpenSearch O valor padrão é 1.
# Configurações de tarefa de carregamento completo
As configurações de carga máxima incluem o seguinte: Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
+ Para indicar como tratar a carga no destino em um startup de carga máxima, especifique um dos seguintes valores para a opção `TargetTablePrepMode`:
+ `DO_NOTHING`: os dados e metadados da tabela de destino existente não são afetados.
+ `DROP_AND_CREATE`: a tabela existente é descartada, e uma nova tabela é criada em seu lugar.
+ `TRUNCATE_BEFORE_LOAD`: os dados são truncados sem afetar os metadados da tabela.
+ Para atrasar a criação de uma chave primária ou de um índice único até a conclusão da carga máxima, defina a opção `CreatePkAfterFullLoad` como `true`.
+ Para tarefas com carga máxima e CEC ativado, defina as seguintes opções para `Stop task after full load completes`:
+ `StopTaskCachedChangesApplied`: defina esta opção como `true` para interromper uma tarefa após a conclusão de uma carga máxima ser concluída e as alterações em cache serem aplicadas.
+ `StopTaskCachedChangesNotApplied`: defina esta opção como `true` para interromper uma tarefa antes que as alterações em cache sejam aplicadas.
+ Para indicar o número máximo de tabelas a serem carregadas em paralelo, defina a opção `MaxFullLoadSubTasks`. O padrão é 8; o valor máximo é 49.
+ Defina a opção `ParallelLoadThreads` para indicar quantos threads simultâneos o DMS utiliza durante um processo de carga máxima para enviar registros de dados para um endpoint de destino. O valor padrão é zero (0).
**Importante**
`MaxFullLoadSubTasks` controla o número de tabelas ou segmentos de tabela a serem carregados em paralelo. `ParallelLoadThreads` controla o número de threads utilizados por uma tarefa de migração para executar as cargas em paralelo. *Essas configurações são multiplicativas.* Dessa forma, o número total de threads utilizados durante uma tarefa de carga máxima é aproximadamente o resultado do valor de `ParallelLoadThreads ` multiplicado pelo valor de `MaxFullLoadSubTasks` (`ParallelLoadThreads`**\$1**`MaxFullLoadSubtasks)`.
Se você criar tarefas com um grande número de subtarefas de carga máxima e um grande número de threads de carga paralela, a tarefa poderá consumir muita memória e falhar.
+ Você pode definir o número de segundos que AWS DMS aguarda o fechamento das transações antes de iniciar uma operação de carga total. Para fazer isso, se as transações estiverem abertas quando a tarefa começar, defina a opção `TransactionConsistencyTimeout`. O valor padrão é 600 (10 minutos). AWS DMS inicia a carga total após o valor do tempo limite ser atingido, mesmo se houver transações abertas. Uma full-load-only tarefa não espera por 10 minutos, mas começa imediatamente.
+ Para indicar o número máximo de eventos que podem ser transferidos em conjunto, defina a opção `CommitRate`. O valor padrão é 10000 e o valor máximo é 50000.
# Configurações de tarefa do Time Travel
Para registrar e depurar tarefas de replicação, você pode usar o AWS DMS Time Travel. Nessa abordagem, você utiliza o Amazon S3 para armazenar logs e criptografá-los utilizando as chaves de criptografia. Somente com acesso ao bucket do S3 do Time Travel, é possível recuperar os logs do S3 utilizando filtros de data e hora e visualizar, baixar e ofuscar os logs conforme necessário. Ao fazer isso, é possível “viajar no tempo” com segurança para investigar as atividades do banco de dados. O Time Travel funciona independentemente do CloudWatch registro. Para obter mais informações sobre CloudWatch registro em log, consulte[Configurações de registro de tarefa](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md).
Você pode usar o Time Travel em todas as AWS regiões com AWS DMS endpoints de origem Oracle, Microsoft SQL Server e PostgreSQL compatíveis e endpoints de destino PostgreSQL e MySQL AWS DMS compatíveis. É possível ativar o Time Travel somente para tarefas de carga máxima e captura de dados alterados (CDC) e para tarefas somente CDC. Para ativar o Time Travel ou modificar qualquer configuração existente do Time Travel, interrompa a tarefa de replicação.
As configurações do Time Travel incluem as seguintes propriedades `TTSettings`:
+ `EnableTT`: se esta opção estiver definida como`true`, o Time Travel será ativado para a tarefa. O valor padrão é `false`.
Tipo: booliano
Obrigatório: não
+ `EncryptionMode`: o tipo de criptografia do lado do servidor que está sendo utilizada no bucket do S3 para armazenar os dados e logs. É possível especificar `"SSE_S3"` (o padrão) ou `"SSE_KMS"`.
É possível alterar `EncryptionMode` de `"SSE_KMS"` para`"SSE_S3"`, mas não o contrário.
Tipo: string
Obrigatório: não
+ `ServerSideEncryptionKmsKeyId`— Se você especificar `"SSE_KMS"` para`EncryptionMode`, forneça o ID da sua AWS KMS chave gerenciada personalizada. Certifique-se de que a chave que você usa tenha uma política anexada que ative as permissões de usuário AWS Identity and Access Management (IAM) e permita o uso da chave.
Somente a sua própria chave do KMS simétrica gerenciada e personalizada é compatível com a opção `"SSE_KMS"`.
Tipo: string
Obrigatório: somente se `EncryptionMode` for definido como `"SSE_KMS"`
+ `ServiceAccessRoleArn`: o nome do recurso da Amazon (ARN) utilizado pelo serviço para acessar o perfil do IAM. Defina o nome do usuário como `dms-tt-s3-access-role`. Essa é uma configuração obrigatória que permite AWS DMS gravar e ler objetos de um bucket do S3.
Tipo: string
Obrigatório: se o Time Travel estiver ativado
Veja a seguir um exemplo de política para esse perfil.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"kms:GenerateDataKey",
"kms:Decrypt",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::S3bucketName*",
"arn:aws:kms:us-east-1:112233445566:key/1234a1a1-1m2m-1z2z-d1d2-12dmstt1234"
]
}
]
}
```
------
Veja a seguir um exemplo de política de confiança para esse perfil.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"dms.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
+ `BucketName`: o nome do bucket do S3 para armazenar logs de Time Travel. Crie esse bucket do S3 antes de ativar os logs do Time Travel.
Tipo: string
Obrigatório: se o Time Travel estiver ativado
+ `BucketFolder`: um parâmetro opcional para definir um nome de pasta no bucket do S3. Se você especificar esse parâmetro, o DMS criará os logs do Time Travel no caminho `"/BucketName/BucketFolder/taskARN/YYYY/MM/DD/hh"`. Se você não especificar esse parâmetro, AWS DMS cria o caminho padrão como`"/BucketName/dms-time-travel-logs/taskARN/YYYY/MM/DD/hh`.
Tipo: string
Obrigatório: não
+ `EnableDeletingFromS3OnTaskDelete`— Quando essa opção está definida como`true`, AWS DMS exclui os registros de viagem no tempo do S3 se a tarefa for excluída. O valor padrão é `false`.
Tipo: string
Obrigatório: não
+ `EnableRawData`: quando esta opção está definida como `true`, os dados brutos da linguagem de manipulação de dados (DML) dos logs do Time Travel aparecem sob a coluna `raw_data` dos logs do Time Travel. Para obter detalhes, consulte [Utilizar os logs do Time Travel](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md). O valor padrão é `false`. Quando esta opção é definida como `false`, somente o tipo de DML é capturado.
Tipo: string
Obrigatório: não
+ `RawDataFormat`— Nas AWS DMS versões 3.5.0 e superiores, quando `EnableRawData` está definido como. `true` Essa propriedade especifica um formato para os dados brutos da DML em um log do Time Travel e pode ser apresentada como:
+ `"TEXT"`: nomes e valores de colunas analisados e legíveis para eventos da DML capturados durante a CDC como campos `Raw`.
+ `"HEX"`: o hexadecimal original para nomes de colunas e valores capturados para eventos da DML durante a CDC.
Essa propriedade se aplica às origens de bancos de dados Oracle e Microsoft SQL Server.
Tipo: string
Obrigatório: não
+ `OperationsToLog`: especifica o tipo de operação da DML a ser registrado em log nos logs do Time Travel. É possível especificar um dos seguintes:
+ `"INSERT"`
+ `"UPDATE"`
+ `"DELETE"`
+ `"COMMIT"`
+ `"ROLLBACK"`
+ `"ALL"`
O padrão é `"ALL"`.
Tipo: string
Obrigatório: não
+ `MaxRecordSize`: especifica o tamanho máximo dos registros de log do Time Travel que são registrados em log para cada linha. Utilize essa propriedade para controlar o crescimento dos logs do Time Travel em tabelas especialmente ocupadas. O padrão é 64 KB.
Tipo: inteiro
Obrigatório: não
Para obter mais informações sobre como ativar e utilizar os logs do Time Travel, consulte os tópicos a seguir.
**Topics**
+ [
# Ativar os logs do Time Travel para uma tarefa
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.TaskEnabling.md)
+ [
# Utilizar os logs do Time Travel
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md)
+ [
# Com que frequência AWS DMS carrega registros de viagem no tempo para o S3
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md)
# Ativar os logs do Time Travel para uma tarefa
Você pode ativar a Viagem no Tempo para uma AWS DMS tarefa usando as configurações de tarefa descritas anteriormente. Verifique se a tarefa de replicação é interrompida antes de ativar o Time Travel.
**Para ativar a Viagem no Tempo usando o AWS CLI**
1. Crie um arquivo JSON de configuração de tarefas do DMS e adicione uma seção `TTSettings` como a seguinte. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
```
.
.
.
},
"TTSettings" : {
"EnableTT" : true,
"TTS3Settings": {
"EncryptionMode": "SSE_KMS",
"ServerSideEncryptionKmsKeyId": "arn:aws:kms:us-west-2:112233445566:key/myKMSKey",
"ServiceAccessRoleArn": "arn:aws:iam::112233445566:role/dms-tt-s3-access-role",
"BucketName": "myttbucket",
"BucketFolder": "myttfolder",
"EnableDeletingFromS3OnTaskDelete": false
},
"TTRecordSettings": {
"EnableRawData" : true,
"OperationsToLog": "DELETE,UPDATE",
"MaxRecordSize": 64
},
.
.
.
```
1. Em uma ação de tarefa apropriada, especifique esse arquivo JSON utilizando a opção `--replication-task-settings`. Por exemplo, o fragmento de código da CLI a seguir especifica esse arquivo de configurações de Time Travel como parte de `create-replication-task`.
```
aws dms create-replication-task
--target-endpoint-arn arn:aws:dms:us-east-1:112233445566:endpoint:ELS5O7YTYV452CAZR2EYBNQGILFHQIFVPWFRQAY \
--source-endpoint-arn arn:aws:dms:us-east-1:112233445566:endpoint:HNX2BWIIN5ZYFF7F6UFFZVWTDFFSMTNOV2FTXZA \
--replication-instance-arn arn:aws:dms:us-east-1:112233445566:rep:ERLHG2UA52EEJJKFYNYWRPCG6T7EPUAB5AWBUJQ \
--migration-type full-load-and-cdc --table-mappings 'file:///FilePath/mappings.json' \
--replication-task-settings 'file:///FilePath/task-settings-tt-enabled.json' \
--replication-task-identifier test-task
.
.
.
```
Aqui, o nome desse arquivo de configurações do Time Travel é `task-settings-tt-enabled.json`.
De forma semelhante, é possível especificar esse arquivo como parte da ação `modify-replication-task`.
Observe o tratamento especial dos logs do Time Travel para as seguintes ações de tarefas:
+ `start-replication-task`: ao executar uma tarefa de replicação, se um bucket do S3 utilizado pelo Time Travel não estiver acessível, a tarefa será marcada como `FAILED`.
+ `stop-replication-task`— Quando a tarefa é interrompida, envia AWS DMS imediatamente todos os registros de viagem no tempo que estão atualmente disponíveis para a instância de replicação para o bucket do S3 usado para viagem no tempo.
Enquanto uma tarefa de replicação é executada, é possível alterar o valor de `EncryptionMode` de `"SSE_KMS"` para `"SSE_S3"`, mas não o contrário.
Se o tamanho dos logs do Time Travel de uma tarefa em andamento exceder 1 GB, o DMS enviará os logs para o S3 em cinco minutos após atingir esse tamanho. Depois que uma tarefa estiver em execução, se o bucket do S3 ou a chave do KMS ficarem inacessíveis, o DMS deixará de enviar logs para esse bucket. Se você achar que seus registros não estão sendo enviados para o bucket do S3, verifique o S3 e AWS KMS as permissões. Para obter mais detalhes sobre a frequência com que o DMS envia esses logs para o S3, consulte [Com que frequência AWS DMS carrega registros de viagem no tempo para o S3](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md).
Para ativar o Time Travel para uma tarefa existente no console, utilize a opção do editor JSON em **Configurações de tarefa** para adicionar uma seção `TTSettings`.
# Utilizar os logs do Time Travel
Os *Arquivos de log do Time Travel* são arquivos de valores separados por vírgulas (CSV) com os campos a seguir.
```
log_timestamp
component
dms_source_code_location
transaction_id
event_id
event_timestamp
lsn/scn
primary_key
record_type
event_type
schema_name
table_name
statement
action
result
raw_data
```
Depois que os logs do Time Travel estiverem disponíveis no S3, é possível acessá-los e consultá-los diretamente com ferramentas, como o Amazon Athena. Ou é possível baixar os logs da mesma forma utilizada com qualquer arquivo do S3.
O exemplo a seguir mostra um log do Time Travel em que as transações de uma tabela chamada `mytable` são registradas em log. As terminações de linha do log a seguir foram adicionadas para facilitar a leitura.
```
"log_timestamp ","tt_record_type","dms_source_code_location ","transaction_id",
"event_id","event_timestamp","scn_lsn","primary_key","record_type","event_type",
"schema_name","table_name","statement","action","result","raw_data"
"2021-09-23T01:03:00:778230","SOURCE_CAPTURE","postgres_endpoint_wal_engine.c:00819",
"609284109","565612992","2021-09-23 01:03:00.765321+00","00000E9C/D53AB518","","DML",
"UPDATE (3)","dmstest","mytable","","Migrate","","table dmstest.mytable:
UPDATE: id[bigint]:2244937 phone_number[character varying]:'phone-number-482'
age[integer]:82 gender[character]:'f' isactive[character]:'true '
date_of_travel[timestamp without time zone]:'2021-09-23 01:03:00.76593'
description[text]:'TEST DATA TEST DATA TEST DATA TEST DATA'"
```
# Com que frequência AWS DMS carrega registros de viagem no tempo para o S3
Para minimizar o uso do armazenamento de sua instância de replicação, AWS DMS descarregue periodicamente os registros de viagem no tempo dela.
Os logs do Time Travel são enviados para o bucket do Amazon S3 nos seguintes casos:
+ Se o tamanho atual dos registros exceder 1 GB, AWS DMS faça o upload dos registros para o S3 em cinco minutos. Assim, AWS DMS pode fazer até 12 chamadas por hora para o S3 e AWS KMS para cada tarefa em execução.
+ AWS DMS carrega os registros para o S3 a cada hora, independentemente do tamanho dos registros.
+ Quando uma tarefa é interrompida, carrega AWS DMS imediatamente os registros de viagem no tempo para o S3.
# Configurações de registro de tarefa
O Logging usa CloudWatch a Amazon para registrar informações durante o processo de migração. Usando as configurações de tarefa de registro em log, é possível especificar quais atividades de componentes serão registradas em log e qual quantidade de informações será gravada no log. As configurações da tarefa de registro em log são gravadas em um arquivo JSON. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
Você pode ativar o CloudWatch login de várias maneiras. Você pode selecionar a `EnableLogging` opção Console de gerenciamento da AWS ao criar uma tarefa de migração. Ou você pode definir a `EnableLogging` opção para `true` ao criar uma tarefa usando a AWS DMS API. Também é possível especificar `"EnableLogging": true` no JSON da seção de registro em log de configurações de tarefas.
Quando você define como`true`, `EnableLogging` AWS DMS atribui o nome do CloudWatch grupo e o nome do stream da seguinte forma. Não é possível definir esses valores diretamente.
+ **CloudWatchLogGroup**: `dms-tasks-`
+ **CloudWatchLogStream**: `dms-task-`
`` é o identificador da instância de replicação. `` é o valor da seção `` do ARN da tarefa. Para obter informações sobre como AWS DMS gera recursos ARNs, consulte[Construindo um nome de recurso da Amazon (ARN) para AWS DMS](CHAP_Introduction.AWS.ARN.md).
CloudWatch se integra com AWS Identity and Access Management (IAM), e você pode especificar quais CloudWatch ações um usuário em sua AWS conta pode realizar. Para obter mais informações sobre como trabalhar com o IAM em CloudWatch, consulte [Gerenciamento de identidade e acesso para a Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) e [Registro de chamadas de CloudWatch API](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html) da *Amazon no Guia CloudWatch do usuário da Amazon.*
Para excluir os logs de tarefas, é possível definir `DeleteTaskLogs` como verdadeiro no JSON da seção de registro em log das configurações de tarefas.
É possível especificar o registro em log dos seguintes tipos de eventos:
+ `FILE_FACTORY`: a fábrica de arquivos gerencia os arquivos utilizados para aplicação e carga em lote e gerencia os endpoints do Amazon S3.
+ `METADATA_MANAGER`: o gerenciador de metadados gerencia os metadados de origem e de destino, o particionamento e o estado da tabela durante a replicação.
+ `SORTER`: o `SORTER` recebe eventos recebidos do processo `SOURCE_CAPTURE`. Os eventos são agrupados em transações e passados para o componente de serviço `TARGET_APPLY`. Se o processo `SOURCE_CAPTURE` produzir eventos mais rapidamente do que o componente `TARGET_APPLY` pode consumir, o componente `SORTER` armazenará em cache os eventos acumulados no disco ou em um arquivo de troca. Os eventos armazenados em cache são uma causa comum de falta de armazenamento em instâncias de replicação.
O componente de serviço `SORTER` gerencia os eventos armazenados em cache, reúne estatísticas da CDC e relata a latência da tarefa.
+ `SOURCE_CAPTURE`: os dados da replicação contínua (CDC) são capturados no banco de dados ou serviço de origem e passados para o componente de serviço SORTER.
+ `SOURCE_UNLOAD`: os dados são descarregados no banco de dados ou serviço de origem durante a carga máxima.
+ `TABLES_MANAGER`: o gerenciador de tabelas rastreia as tabelas capturadas, gerencia a ordem da migração da tabela e coleta as estatísticas das tabelas.
+ `TARGET_APPLY`: os dados e as instruções da linguagem de definição de dados (DDL) são aplicados no banco de dados de destino.
+ `TARGET_LOAD`: os dados são carregados no banco de dados de destino.
+ `TASK_MANAGER`: o gerenciador de tarefas gerencia as tarefas em execução e divide as tarefas em subtarefas para processamento paralelo de dados.
+ `TRANSFORMATION`: eventos de transformação de mapeamento de tabela. Para obter mais informações, consulte [Utilizar o mapeamento de tabela para especificar as configurações da tarefa](CHAP_Tasks.CustomizingTasks.TableMapping.md).
+ `VALIDATOR/ VALIDATOR_EXT`: o componente de serviço `VALIDATOR` verifica se os dados foram migrados com precisão da origem para o destino. Para obter mais informações, consulte [Validação de dados](CHAP_Validating.md).
+ `DATA_RESYNC`: componente comum do recurso de ressincronização de dados que gerencia o fluxo de ressincronização de dados. Para obter mais informações, consulte [AWS DMS ressincronização de dados](CHAP_Validating.DataResync.md).
+ `RESYNC_UNLOAD`: os dados são descarregados no banco de dados ou serviço de origem durante o processo de ressincronização.
+ `RESYNC_APPLY`: as instruções da linguagem de manipulação de dados (DML) são aplicadas no banco de dados de destino durante a ressincronização.
Os seguintes componentes de registro em log geram uma grande quantidade de logs ao utilizar o nível de gravidade do log `LOGGER_SEVERITY_DETAILED_DEBUG`:
+ `COMMON`
+ `ADDONS`
+ `DATA_STRUCTURE`
+ `COMMUNICATION`
+ `FILE_TRANSFER`
+ `FILE_FACTORY`
Níveis de log diferentes `DEFAULT` são raramente necessários para esses componentes durante a solução de problemas. Não recomendamos alterar o nível de registro desses componentes, `DEFAULT` a menos que seja especificamente solicitado pelo AWS Support.
Depois de especificar um dos itens anteriores, é possível especificar a quantidade de informações registradas em log, conforme mostrado na lista a seguir.
Os níveis de severidade estão na ordem do menor para o maior nível de informações. Os níveis mais altos sempre incluem informações dos níveis mais baixos.
+ LOGGER\$1SEVERITY\$1ERROR: as mensagens de erro são gravadas no log.
+ LOGGER\$1SEVERITY\$1WARNING: avisos e mensagens de erro são gravados no log.
+ LOGGER\$1SEVERITY\$1INFO: mensagens informativas, avisos e mensagens de erro são gravados no log.
+ LOGGER\$1SEVERITY\$1DEFAULT: mensagens informativas, avisos e mensagens de erro são gravados no log.
+ LOGGER\$1SEVERITY\$1DEBUG: mensagens de depuração, mensagens informativas, mensagens de erro e avisos são gravadas no log.
+ LOGGER\$1SEVERITY\$1DETAILED\$1DEBUG: todas as informações são gravadas no log.
O exemplo de JSON a seguir mostra as configurações de tarefa para registrar em log todas as ações e os níveis de gravidade.
```
…
"Logging": {
"EnableLogging": true,
"LogComponents": [
{
"Id": "FILE_FACTORY",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "METADATA_MANAGER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "SORTER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "SOURCE_CAPTURE",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "SOURCE_UNLOAD",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "TABLES_MANAGER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "TARGET_APPLY",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},{
"Id": "TARGET_LOAD",
"Severity": "LOGGER_SEVERITY_INFO"
},{
"Id": "TASK_MANAGER",
"Severity": "LOGGER_SEVERITY_DEBUG"
},{
"Id": "TRANSFORMATION",
"Severity": "LOGGER_SEVERITY_DEBUG"
},{
"Id": "VALIDATOR",
"Severity": "LOGGER_SEVERITY_DEFAULT"
}
],
"CloudWatchLogGroup": null,
"CloudWatchLogStream": null
},
…
```
# Configurações de tarefa de tabela de controle
As tabelas de controle fornecem informações sobre uma AWS DMS tarefa. Elas também fornecem estatísticas úteis que é possível utilizar para planejar e gerenciar a tarefa de migração atual e as tarefas futuras. Você pode aplicar essas configurações de tarefa em um arquivo JSON ou escolhendo **Configurações avançadas** na página **Criar tarefa** no AWS DMS console. A tabela Aplicar exceções (`dmslogs.awsdms_apply_exceptions`) é sempre criada nos destinos de bancos de dados. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
AWS DMS cria tabelas de controle somente durante tarefas de carga total \$1 CDC ou somente CDC, e não durante tarefas somente de carga total.
Para tarefas de carga máxima e CDC (migrar dados existentes e replicar alterações em andamento) e de somente CDC (somente replicar alterações de dados), também é possível criar tabelas adicionais, incluindo as seguintes:
+ **Status da replicação (dmslogs.awsdms\$1status)**: esta tabela fornece detalhes sobre a tarefa atual. Isso inclui o status da tarefa, a quantidade de memória consumida pela tarefa e o número de alterações que ainda não foram aplicadas ao destino. Essa tabela também fornece a posição no banco de dados de origem em que AWS DMS está sendo lida atualmente. Ela também indica se a tarefa está na fase de carga máxima ou de captura de dados de alteração (CDC).
+ **Tabelas suspensas (dmslogs.awsdms\$1suspended\$1tables)**: esta tabela fornece uma lista de tabelas suspensas e o motivo por que foram suspensas.
+ **Histórico de replicação (dmslogs.awsdms\$1history)** esta tabela fornece informações sobre o histórico de replicação. Essas informações incluem o número e o volume de registros processados durante a tarefa, a latência no final de uma tarefa de CDC e outras estatísticas.
A tabela Aplicar exceções (`dmslogs.awsdms_apply_exceptions`) contém os seguintes parâmetros:
| Coluna | Tipo | Description |
| --- | --- | --- |
| TASK\$1NAME | nvchar | O ID do recurso da AWS DMS tarefa. O ID do recurso pode ser encontrado no ARN da tarefa. |
| TABLE\$1OWNER | nvchar | O proprietário da tabela. |
| TABLE\$1NAME | nvchar | O nome da tabela. |
| ERROR\$1TIME | timestamp | A hora em que a exceção (erro) ocorreu. |
| STATEMENT | nvchar | A declaração que estava sendo executada quando o erro ocorreu. |
| ERRO | nvchar | O nome e a descrição do erro. |
A tabela Replication Status (Status de replicação) `dmslogs.awsdms_status` contém o status atual da tarefa e do banco de dados de destino. Ela possui as seguintes configurações.
| Coluna | Tipo | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | O nome da máquina onde a tarefa de replicação está sendo executada. |
| TASK\$1NAME | nvchar | O ID do recurso da AWS DMS tarefa. O ID do recurso pode ser encontrado no ARN da tarefa. |
| TASK\$1STATUS | varchar | Um dos seguintes valores: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) O status da tarefa é definido como FULL LOAD desde que haja pelo menos uma tabela em carga máxima. Após todas as tabelas serem carregadas, o status da tarefa será alterado para CHANGE PROCESSING se CDC estiver ativado. A tarefa é definida como NÃO EXECUTANDO antes de você iniciá-la ou após sua conclusão. |
| STATUS\$1TIME | timestamp | O timestamp do status da tarefa. |
| PENDING\$1CHANGES | int | O número de registros de alteração que foram confirmados no banco de dados de origem e armazenados em cache na memória e no disco da instância de replicação. |
| DISK\$1SWAP\$1SIZE | int | A quantidade de espaço em disco usada por transações antigas ou descarregadas. |
| TASK\$1MEMORY | int | Memória atual utilizada em MB. |
| SOURCE\$1CURRENT \$1POSITION | varchar | A posição no banco de dados de origem que AWS DMS está sendo lida atualmente. |
| SOURCE\$1CURRENT \$1TIMESTAMP | timestamp | O carimbo de data/hora no banco de dados de origem que AWS DMS está sendo lido no momento. |
| SOURCE\$1TAIL \$1POSITION | varchar | A posição da transação de início mais antiga que ainda não está confirmada. Esse valor é a posição mais recente para a qual é possível reverter sem perder alterações. |
| SOURCE\$1TAIL \$1TIMESTAMP | timestamp | O timestamp da transação de início mais antiga que ainda não está confirmada. Esse valor é o timestamp mais recente para o qual é possível reverter sem perder alterações. |
| SOURCE\$1TIMESTAMP \$1APPLIED | timestamp | O timestamp da última confirmação de transação. Em um processo de aplicação em lote, esse valor é o timestamp da confirmação da última transação no lote. |
A tabela suspensa (`dmslogs.awsdms_suspended_tables`) contém os seguintes parâmetros.
| Coluna | Tipo | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | O nome da máquina onde a tarefa de replicação está sendo executada. |
| TASK\$1NAME | nvchar | O nome da AWS DMS tarefa |
| TABLE\$1OWNER | nvchar | O proprietário da tabela. |
| TABLE\$1NAME | nvchar | O nome da tabela. |
| SUSPEND\$1REASON | nvchar | Motivo da suspensão. |
| SUSPEND\$1TIMESTAMP | timestamp | A hora em que ocorreu a suspensão. |
A tabela Replication History (Histórico de replicação) (`dmslogs.awsdms_history`) contém os seguintes parâmetros:
| Coluna | Tipo | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | O nome da máquina onde a tarefa de replicação está sendo executada. |
| TASK\$1NAME | nvchar | O ID do recurso da AWS DMS tarefa. O ID do recurso pode ser encontrado no ARN da tarefa. |
| TIMESLOT\$1TYPE | varchar | Um dos seguintes valores: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) Se a tarefa estiver executando tanto carga máxima quanto CDC, dois registros de histórico serão gravados no slot de tempo. |
| TIMESLOT | timestamp | O timestamp de término no slot de tempo. |
| TIMESLOT\$1DURATION | int | A duração do slot de tempo, em minutos. |
| TIMESLOT\$1LATENCY | int | A latência de destino no final do slot de tempo, em segundos. Este valor só se aplica a intervalos de tempo CDC. |
| RECORDS | int | O número de registros processados durante o slot de tempo. |
| TIMESLOT\$1VOLUME | int | O volume de dados processados em MB. |
A tabela Falha de validação (`awsdms_validation_failures_v1`) contém todas as falhas de validação de dados de uma tarefa. Para obter mais informações sobre a validação de dados, consulte [Solução de problemas da validação de dados](CHAP_Validating.md#CHAP_Validating.Troubleshooting).
Veja a seguir as configurações adicionais de tabela de controle:
+ `HistoryTimeslotInMinutes`: utilize esta opção para indicar o tamanho de cada slot de tempo na tabela Histórico de replicação. O padrão é 5 minutos.
+ `ControlSchema`— Use essa opção para indicar o nome do esquema do banco de dados para as tabelas de controle do AWS DMS destino. Se você não inserir nenhuma informação nessa opção, as tabelas serão copiadas para o local padrão no banco de dados conforme listado a seguir:
+ PostgreSQL, público
+ Oracle, o esquema de destino
+ Microsoft SQL Server, dbo no banco de dados de destino
+ MySQL, awsdms\$1control
+ MariaDB, awsdms\$1control
+ Amazon Redshift, público
+ DynamoDB, criado como tabelas individuais no banco de dados
+ IBM Db2 LUW, awsdms\$1control
# Configurações de tarefas de buffer de stream
Você pode definir as configurações do buffer de transmissão usando o AWS CLI, incluindo o seguinte. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
+ `StreamBufferCount`: utilize esta opção para especificar o número de buffers de fluxo de dados da tarefa de migração. O número de buffer de fluxo padrão é 3. Aumentar o valor dessa configuração pode aumentar a velocidade de extração de dados. Contudo, esse aumento de desempenho depende altamente do ambiente de migração, incluindo o sistema de origem e a classe da instância do servidor de replicação. O padrão é suficiente na maioria de situações.
+ `StreamBufferSizeInMB`: utilize esta opção para indicar o tamanho máximo de cada buffer de fluxo de dados. O tamanho padrão é 8 MB. Talvez seja necessário aumentar o valor dessa opção ao trabalhar com muito grande LOBs. Também pode ser preciso aumentar o valor se você receber uma mensagem nos arquivos de log que o tamanho do buffer de fluxo é insuficiente. Ao calcular o tamanho dessa opção, é possível utilizar a seguinte equação:` [Max LOB size (or LOB chunk size)]*[number of LOB columns]*[number of stream buffers]*[number of tables loading in parallel per task(MaxFullLoadSubTasks)]*3`
+ `CtrlStreamBufferSizeInMB`: utilize esta opção para definir o tamanho do buffer de fluxo de controle. O valor é em megabytes e pode ser de 1 a 8. O valor padrão é 5. Pode ser necessário aumentá-lo ao trabalhar com um número muito grande de tabelas, como dezenas de milhares de tabelas.
# Configurações de ajuste de processamento de alterações
As configurações a seguir determinam como AWS DMS manipula as alterações nas tabelas de destino durante a captura de dados de alterações (CDC). Várias dessas configurações dependem do valor do parâmetro de metadados de destino `BatchApplyEnabled`. Para obter mais informações sobre o parâmetro `BatchApplyEnabled`, consulte [Configurações de tarefa de metadados de destino](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md). Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
Veja a seguir as configurações de ajuste do processamento de alterações:
As seguintes configurações aplicam-se somente quando o parâmetro de metadados de destino `BatchApplyEnabled` está definido como `true`.
+ `BatchApplyPreserveTransaction`: se estiver definido como `true`, a integridade transacional será preservada e será garantido que um lote contenha todas as alterações dentro de uma transação da origem. O valor padrão é `true`. Essa configuração se aplica apenas a endpoints de destino da Oracle.
Se definido como `false`, pode haver lapsos temporários na integridade para melhorar o desempenho. Não há garantia de que todas as alterações em uma transação da origem sejam aplicadas ao destino em um único lote.
Por padrão, AWS DMS os processos mudam em um modo transacional, que preserva a integridade transacional. Se houver condições para lapsos temporários em integridade transacional, você poderá usar a opção batch optimized apply. Essa opção agrupa transações de maneira eficaz e as aplica em lotes para fins de eficiência. A utilização da opção de aplicação otimizada em lote quase sempre viola as restrições de integridade referencial. Portanto, é recomendável desativar essas restrições durante o processo de migração e ativá-las novamente como parte do processo de substituição.
+ `BatchApplyTimeoutMin`— Define o tempo mínimo em segundos de AWS DMS espera entre cada aplicação de alterações em lote. O valor padrão é 1.
+ `BatchApplyTimeoutMax`— Define o tempo máximo em segundos que AWS DMS espera entre cada aplicação de alterações em lote antes de atingir o tempo limite. O valor padrão é 30.
+ `BatchApplyMemoryLimit`: define a quantidade máxima de memória em MB a ser utilizada para pré-processamento no **Modo de aplicação otimizada para lotes**. O valor padrão é 500.
+ `BatchSplitSize`: define o número máximo de alterações aplicadas em um único lote. O valor padrão é 0, o que significa que não há limite aplicado.
As seguintes configurações aplicam-se somente quando o parâmetro de metadados de destino `BatchApplyEnabled` está definido como `false`.
+ `MinTransactionSize`: define o número mínimo de alterações a serem incluídas em cada transação. O valor padrão é 1000.
+ `CommitTimeout`— Define o tempo máximo em segundos AWS DMS para coletar transações em lotes antes de declarar um tempo limite. O valor padrão é 1.
Para a replicação bidirecional, aplicam-se as seguintes configurações somente quando o parâmetro de metadados de destino `BatchApplyEnabled` está definido como `false`.
+ `LoopbackPreventionSettings`: essas configurações fornecem prevenção de loopback para cada tarefa de replicação contínua em qualquer par de tarefas envolvidas na replicação bidirecional. A *Prevenção de loopback* impede que alterações idênticas sejam aplicadas nas duas direções da replicação bidirecional, o que pode corromper os dados. Para obter mais informações sobre a replicação bidirecional, consulte [Executar replicação bidirecional](CHAP_Task.CDC.md#CHAP_Task.CDC.Bidirectional).
AWS DMS tenta manter os dados da transação na memória até que a transação seja totalmente confirmada com a origem, o destino ou ambos. Contudo, as transações maiores que a memória alocada ou não confirmadas dentro do limite de tempo especificado são gravadas no disco.
As seguintes configurações aplicam-se ao ajuste de processamento de alterações, independentemente do modo de processamento de alterações.
+ `MemoryLimitTotal`: define o tamanho máximo em MB que todas as transações podem ocupar na memória antes de serem gravadas no disco. O valor padrão é 1024.
+ `MemoryKeepTime`: define o tempo máximo em segundos que cada transação pode permanecer na memória antes de ser gravada no disco. A duração é calculada a partir do momento em que AWS DMS começou a capturar a transação. O valor padrão é 60.
+ `StatementCacheSize`: define o número máximo de declarações preparadas a serem armazenadas no servidor para execução posterior ao aplicar alterações ao destino. O valor padrão é 50 e o valor máximo é 200.
+ `RecoveryTimeout`— Ao retomar uma tarefa no modo CDC, RecoveryTimeout controla quanto tempo (em minutos) a tarefa aguardará para chegar ao ponto de verificação de retomada. Se o ponto de verificação não for encontrado dentro do prazo configurado, a tarefa falhará. O comportamento padrão é esperar indefinidamente pelo evento do ponto de verificação.
Exemplo de como as configurações de tarefas que lidam com o ajuste de processamento de alterações aparecem em um arquivo JSON de configuração de tarefas:
```
"ChangeProcessingTuning": {
"BatchApplyPreserveTransaction": true,
"BatchApplyTimeoutMin": 1,
"BatchApplyTimeoutMax": 30,
"BatchApplyMemoryLimit": 500,
"BatchSplitSize": 0,
"MinTransactionSize": 1000,
"CommitTimeout": 1,
"MemoryLimitTotal": 1024,
"MemoryKeepTime": 60,
"StatementCacheSize": 50
"RecoveryTimeout": -1
}
```
Para controlar a frequência de gravações em um destino do Amazon S3 durante uma tarefa de replicação de dados, é possível configurar os atributos de conexão adicionais `cdcMaxBatchInterval` e `cdcMinFileSize`. Isso pode resultar em melhor desempenho ao analisar os dados sem operações adicionais de sobrecarga. Para obter mais informações, consulte [Configurações de endpoint ao usar o Amazon S3 como destino para AWS DMS](CHAP_Target.S3.md#CHAP_Target.S3.Configuring).
# Configurações da tarefa de validação de dados
É possível verificar se os dados foram migrados com precisão da origem para o destino. Se você habilitar a validação de uma tarefa, AWS DMS começará a comparar os dados de origem e de destino imediatamente após a execução de uma carga completa para uma tabela. Para obter mais informações sobre a validação de dados de tarefa, seus requisitos, o escopo do suporte a seu banco de dados e as métricas relatadas por ela, consulte [AWS Validação de dados do DMS](CHAP_Validating.md). Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
As configurações de validação dos dados e seus valores incluem o seguinte:
+ `EnableValidation`: ativa a validação de dados quando definida como verdadeira. Caso contrário, a validação será desabilitada para a tarefa. O valor padrão é falso.
+ `ValidationMode`— controla como AWS DMS valida os dados na tabela de destino em relação à tabela de origem. A partir da versão 3.5.4 do mecanismo de replicação, o DMS define isso automaticamente como `GROUP_LEVEL` para os caminhos de migração compatíveis, oferecendo desempenho de validação aprimorado e processamento significativamente mais rápido para grandes conjuntos de dados. Esse aprimoramento se aplica aos caminhos de migração listados na [ressincronização de dados do AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.DataResync.html#CHAP_DataResync.limitations). Para todos os outros caminhos de migração, o modo de validação usa `ROW_LEVEL` como padrão.
**nota**
Independentemente da configuração, AWS DMS valida todas as linhas configuradas por meio da validação da tabela.
+ `FailureMaxCount`: especifica o número máximo de registros que podem falhar na validação antes que a validação seja suspensa para a tarefa. O valor padrão é 10.000. Para que a validação continue, independentemente do número de registros que fizeram com que a validação falhasse, defina essa configuração como um valor superior ao número de registros na origem.
+ `HandleCollationDiff`: quando esta opção está definida como `true`, a validação considera as diferenças de agrupamento de colunas entre os bancos de dados de origem e de destino. Caso contrário, qualquer diferença no agrupamento de colunas será ignorada para validação. Os agrupamentos de colunas podem ditar a ordem das linhas, o que é importante para a validação dos dados. Configurar `HandleCollationDiff` como true resolve essas diferenças de agrupamento automaticamente e impede falsos positivos na validação dos dados. O valor padrão é `false`.
+ `RecordFailureDelayInMinutes`: especifica o atraso, em minutos, antes de relatar qualquer detalhe da falha da validação.
Se a latência geral de CDC da tarefa do DMS for maior do que o valor `RecordFailureDelayInMinutesthen`, ela terá precedência; por exemplo, se `RecordFailureDelayInMinutes` for 5 e a latência de CDC for 7 minutos, o DMS aguardará 7 minutos para relatar os detalhes da falha de validação.
+ `RecordFailureDelayLimitInMinutes`— Especifica o atraso antes de relatar os detalhes de qualquer falha de validação. AWS DMS usa a latência da tarefa para reconhecer o atraso real das alterações que chegam ao alvo, a fim de evitar falsos positivos. Essa configuração substitui o valor de atraso real e o valor de latência de CDC da tarefa do DMS e permite que você defina um atraso maior antes de relatar qualquer métrica de validação. O valor padrão é 0.
+ `RecordSuspendDelayInMinutes`: especifica o tempo de atraso, em minutos, antes que as tabelas sejam suspensas da validação devido ao limite de erro definido em `FailureMaxCount`.
+ `SkipLobColumns`— Quando essa opção é definida como`true`, AWS DMS ignora a validação de dados para todas as colunas LOB na parte da tabela da validação da tarefa. O valor padrão é `false`.
+ `TableFailureMaxCount`: especifica o número máximo de linhas em uma tabela em que uma validação pode falhar antes que a validação seja suspensa para a tabela. O valor padrão é 1,000.
+ `ThreadCount`— Especifica o número de threads de execução AWS DMS usados durante a validação. Cada thread seleciona not-yet-validated dados da origem e do destino para comparar e validar. O valor padrão é 5. Se você `ThreadCount` definir um número maior, AWS DMS poderá concluir a validação mais rapidamente. No entanto, o AWS DMS executa mais consultas simultâneas que consomem mais recursos na origem e no destino.
+ `ValidationOnly`: quando esta opção está definida como `true`, a tarefa executa a validação dos dados sem executar nenhuma migração ou replicação de dados. O valor padrão é `false`. Não é possível modificar a configuração de `ValidationOnly` após a tarefa ser criada.
Você deve definir como **TargetTablePrepMode**`DO_NOTHING`(o padrão para uma tarefa somente de validação) e definir o **Tipo de migração** como um dos seguintes:
+ Carga total — Defina o **tipo de migração** da tarefa para **migrar dados existentes** no AWS DMS console. Ou, na AWS DMS API, defina o tipo de migração como FULL-LOAD.
+ CDC: defina o **Tipo de migração** da tarefa para **Replicar somente alterações de dados** no console do AWS DMS . Ou, na AWS DMS API, defina o tipo de migração como CDC.
Independentemente do tipo de migração escolhido, os dados não são realmente migrados ou replicados durante uma tarefa somente de validação.
Para obter mais informações, consulte [Tarefas somente de validação](CHAP_Validating.md#CHAP_Validating.ValidationOnly).
**Importante**
A configuração de `ValidationOnly` é imutável. Ela não pode ser modificada para uma tarefa após a criação dessa tarefa.
+ `ValidationPartialLobSize`: especifica se você deseja fazer uma validação parcial das colunas LOB em vez de validar todos os dados armazenados na coluna. Isso é algo que pode ser útil ao migrar apenas parte dos dados de LOB e não todo o conjunto de dados de LOB. O valor está em unidades de KB. O valor padrão é 0, o que significa que o AWS DMS valida todos os dados da coluna LOB. Por exemplo, `"ValidationPartialLobSize": 32` significa que valida AWS DMS somente os primeiros 32 KB dos dados da coluna na origem e no destino.
+ `PartitionSize`: especifica o tamanho do lote de registros a serem lidos para comparação da origem e do destino. O padrão é 10.000.
+ `ValidationQueryCdcDelaySeconds`: a quantidade de tempo em que a primeira consulta de validação é atrasada na origem e no destino de cada atualização da CDC. Isso pode ajudar a reduzir a contenção de recursos quando a latência da migração é alta. Uma tarefa somente de validação define automaticamente essa opção como 180 segundos. O padrão é 0.
Por exemplo, o JSON a seguir permite a validação de dados com duas vezes o número padrão de threads. Ele também considera as diferenças na ordem dos registros provocadas pelas diferenças no agrupamento de colunas nos endpoints do PostgreSQL. Além disso, ele fornece um atraso nos relatórios de validação para considerar tempo adicional para processar todas as falhas de validação.
```
"ValidationSettings": {
"EnableValidation": true,
"ThreadCount": 10,
"HandleCollationDiff": true,
"RecordFailureDelayLimitInMinutes": 30
}
```
**nota**
Para um endpoint Oracle, AWS DMS usa DBMS\$1CRYPTO para validar. BLOBs Se seu endpoint Oracle usa BLOBs, conceda a `execute` permissão para DBMS\$1CRYPTO à conta de usuário que acessa o endpoint Oracle. Faça isso executando a seguinte instrução.
```
grant execute on sys.dbms_crypto to dms_endpoint_user;
```
# Configurações de ressincronização de dados
O recurso de ressincronização de dados permite que você ressincronize o banco de dados de destino com seu banco de dados de origem com base no relatório de validação de dados. Para ter mais informações, consulte [Validação de dados do AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html).
Você pode adicionar parâmetros adicionais para `ResyncSettings` no endpoint `ReplicationTaskSettings` que configura o processo de ressincronização. Para ter mais informações, consulte [Exemplo de configuração de tarefa](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) em [Especificar configurações de tarefa para tarefas do AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html).
**nota**
Os parâmetros `ResyncSchedule` e `MaxResyncTime` serão necessários se o processo de ressincronização estiver habilitado e a tarefa tiver um componente de CDC. Eles não são válidos somente para tarefas de carga máxima.
As configurações e os valores dos parâmetros de ressincronização de dados são os seguintes:
`EnableResync`
Habilita o recurso de ressincronização de dados quando definido como `true`. Por padrão, a ressincronização de dados está desabilitada.
**Tipo de dados**: booliano
**Obrigatório**: não
**Padrão**: `false`
**Validação**: não deve ser nula se o parâmetro `ResyncSettings` estiver presente em `TaskSettings`.
`ResyncSchedule`
Janela de tempo para a entrada em vigor do recurso de ressincronização de dados. Deve estar presente no formato cron. Para obter mais informações, consulte [Regras de expressão cron](CHAP_Validating.DataResync.md#CHAP_DataResync.cron).
**Tipos de dados**: string
**Obrigatório**: não
**Validação**:
+ Deve estar presente no formato expressão cron.
+ Não deve ser nulo para tarefas com CDC que tenha `EnableResync` definido como `true`:
+ Não pode ser configurado para tarefas sem o componente de CDC.
`MaxResyncTime`
Limite máximo de tempo em minutos para que o recurso de ressincronização de dados entre em vigor.
**Tipo de dados**: inteiro
**Obrigatório**: não
**Validação**:
+ Não deve ser nulo para tarefas com CDC.
+ Não é necessário para tarefas sem CDC.
+ Valor mínimo: `5 minutes`; valor máximo: `14400 minutes` (dez dias).
`Validation onlyTaskID`
O ID exclusivo da tarefa de validação. O ID da tarefa somente de validação é anexado ao final de um ARN. Por exemplo:
+ ARN da tarefa somente de validação: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`
+ ID da tarefa somente de validação: `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`
**Tipos de dados**: string
**Obrigatório**: não
**Validação**: não deve ser nula para tarefas com o recurso de ressincronização de dados habilitado e a validação desabilitada.
Exemplo:
```
"ResyncSettings": {
"EnableResync": true,
"ResyncSchedule": "30 9 ? * MON-FRI",
"MaxResyncTime": 400,
"ValidationTaskId": "JXPP94804DJOEWIJD9348R3049"
},
```
# Configurações de tarefa para processamento de DDL de processamento de alterações
As configurações a seguir determinam como AWS DMS manipula as alterações da linguagem de definição de dados (DDL) nas tabelas de destino durante a captura de dados de alteração (CDC). Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
As configurações de tarefas para lidar com DDL de processamento de alterações incluem:
+ `HandleSourceTableDropped –` defina esta opção como `true` para abandonar a tabela de destino quando a tabela de origem for abandonada.
+ `HandleSourceTableTruncated`: defina esta opção como `true` para truncar a tabela de destino quando a tabela de origem for truncada.
+ `HandleSourceTableAltered`: defina esta opção como `true` para alterar a tabela de destino quando a tabela de origem for alterada.
Veja a seguir um exemplo de como as configurações de tarefas que manipulam o DDL de processamento de alterações aparecem em um arquivo JSON de configuração de tarefas:
```
"ChangeProcessingDdlHandlingPolicy": {
"HandleSourceTableDropped": true,
"HandleSourceTableTruncated": true,
"HandleSourceTableAltered": true
},
```
**nota**
Para obter informações sobre quais instruções DDL são compatíveis com um endpoint específico, consulte o tópico que descreve esse endpoint.
# Configurações da tarefa de substituição de caracteres
Você pode especificar que sua tarefa de replicação realize substituições de caracteres no banco de dados de destino para todas as colunas do banco de dados de origem com o tipo de `WSTRING` dados AWS DMS `STRING` ou. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
É possível configurar a substituição de caracteres para qualquer tarefa com endpoints dos seguintes bancos de dados de origem e de destino:
+ Bancos de dados de origem:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ MariaDB
+ PostgreSQL
+ SAP Adaptive Server Enterprise (ASE)
+ IBM Db2 LUW
+ Bancos de dados de destino:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ MariaDB
+ PostgreSQL
+ SAP Adaptive Server Enterprise (ASE)
+ banco de dados de origem
É possível especificar substituições de caracteres utilizando o parâmetro `CharacterSetSettings` nas configurações da tarefa. Essas substituições de caracteres ocorrem para caracteres especificados utilizando o valor de ponto de código Unicode em notação hexadecimal. É possível implementar as substituições em duas fases, na seguinte ordem, se ambas forem especificadas:
1. **Substituição individual de caracteres** — AWS DMS pode substituir os valores dos caracteres selecionados na fonte por valores de substituição especificados dos caracteres correspondentes no destino. Utilize a matriz `CharacterReplacements` no `CharacterSetSettings` para selecionar todos os caracteres de origem com os pontos de código Unicode que você especificar. Utilize essa matriz também para especificar os pontos de código de substituição para os caracteres correspondentes no destino.
Para selecionar todos os caracteres na origem que têm um determinado ponto de código, defina uma instância de `SourceCharacterCodePoint` na matriz `CharacterReplacements` para esse ponto de código. Depois, especifique o ponto de código de substituição para todos os caracteres de destino equivalentes definindo a instância correspondente de `TargetCharacterCodePoint` nessa matriz. Para excluir caracteres de destino em vez de substituí-los, defina as instâncias apropriadas de `TargetCharacterCodePoint` como zero (0). É possível substituir ou excluir quantos valores diferentes de caracteres de destino desejar especificando pares adicionais de configurações `SourceCharacterCodePoint` e `TargetCharacterCodePoint` na matriz `CharacterReplacements`. Se você especificar o mesmo valor para várias instâncias de `SourceCharacterCodePoint`, o valor da última configuração correspondente de `TargetCharacterCodePoint` se aplicará ao destino.
Por exemplo, suponha que você especifique os seguintes valores para `CharacterReplacements`.
```
"CharacterSetSettings": {
"CharacterReplacements": [ {
"SourceCharacterCodePoint": 62,
"TargetCharacterCodePoint": 61
}, {
"SourceCharacterCodePoint": 42,
"TargetCharacterCodePoint": 41
}
]
}
```
Neste exemplo, AWS DMS substitui todos os caracteres com o valor hexadecimal 62 do ponto do código-fonte no destino por caracteres com o valor 61 do ponto de código. Além disso, AWS DMS substitui todos os caracteres com o ponto 42 do código-fonte no destino por caracteres com o valor 41 do ponto de código. Em outras palavras, o AWS DMS substitui todas as instâncias da letra `'b'` no destino pela letra `'a'`. Da mesma forma, AWS DMS substitui todas as instâncias da letra `'B'` no alvo pela letra`'A'`.
1. **Validação e substituição do conjunto** de caracteres — Após a conclusão de qualquer substituição individual de caracteres, AWS DMS pode garantir que todos os caracteres de destino tenham pontos de código Unicode válidos no único conjunto de caracteres que você especificar. Utilize o `CharacterSetSupport` em `CharacterSetSettings` para configurar essa verificação e modificação de caracteres de destino. Para especificar o conjunto de caracteres de verificação, defina `CharacterSet` em `CharacterSetSupport` como o valor de string do conjunto de caracteres. (Os valores possíveis de `CharacterSet` se seguem.) Você pode AWS DMS modificar os caracteres de destino inválidos de uma das seguintes formas:
+ Especifique um único ponto de código Unicode de substituição para todos os caracteres de destino inválidos, independentemente do ponto de código atual. Para configurar esse ponto de código de substituição, defina `ReplaceWithCharacterCodePoint` em `CharacterSetSupport` como o valor especificado.
+ Configure a exclusão de todos os caracteres de destino inválidos definindo `ReplaceWithCharacterCodePoint` como zero (0).
Por exemplo, suponha que você especifique os seguintes valores para `CharacterSetSupport`.
```
"CharacterSetSettings": {
"CharacterSetSupport": {
"CharacterSet": "UTF16_PlatformEndian",
"ReplaceWithCharacterCodePoint": 0
}
}
```
Neste exemplo, AWS DMS exclui todos os caracteres encontrados no destino que são inválidos no conjunto de `"UTF16_PlatformEndian"` caracteres. Portanto, todos os caracteres especificados com o valor hexadecimal `2FB6` são excluídos. Esse valor é inválido porque é um ponto de código Unicode de 4 bytes e UTF16 os conjuntos de caracteres aceitam somente caracteres com pontos de código de 2 bytes.
**nota**
A tarefa de replicação conclui todas as substituições de caracteres especificadas antes de iniciar qualquer transformação global ou de tabela especificada por meio do mapeamento de tabela. Para obter mais informações sobre o mapeamento de tabela, consulte [Utilizar o mapeamento de tabela para especificar as configurações da tarefa](CHAP_Tasks.CustomizingTasks.TableMapping.md).
A substituição de caracteres não é compatível com tipos de dados LOB. Isso inclui qualquer tipo de dados que o DMS considere um tipo de dados LOB. Por exemplo, o tipo de dados `Extended` no Oracle é considerado LOB. Para obter mais informações sobre tags, consulte [Tipos de dados de origem do Oracle](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes):
Os valores que AWS DMS oferecem suporte para `CharacterSet` aparecem na tabela a seguir.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html)
# Configurações de tarefa de imagem anterior
Ao gravar atualizações de CDC em um destino de streaming de dados, como o Kinesis ou o Apache Kafka, é possível exibir os valores originais de uma linha do banco de dados de origem antes da alteração por uma atualização. Para tornar isso possível, AWS DMS preenche uma *imagem anterior* dos eventos de atualização com base nos dados fornecidos pelo mecanismo do banco de dados de origem. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
Para isso, utilize o parâmetro `BeforeImageSettings` que adiciona um novo atributo JSON a cada operação de atualização com valores coletados do sistema do banco de dados de origem.
Aplique `BeforeImageSettings` somente às tarefas de carga máxima mais CDC ou às tarefas de CDC somente. As tarefas de carga máxima mais CDC migram os dados existentes e replicam as alterações em andamento. As tarefas somente de CDC replicam somente as alterações de dados.
Não aplique `BeforeImageSettings` a tarefas que são somente de carga total.
As opções possíveis para `BeforeImageSettings` são as seguintes:
+ `EnableBeforeImage`: ativa a geração de imagem anterior quando definido como `true`. O padrão é `false`.
+ `FieldName`: atribui um nome ao novo atributo JSON. Quando `EnableBeforeImage` for `true`, `FieldName` será necessário e não poderá estar vazio.
+ `ColumnFilter`: especifica uma coluna a ser adicionada utilizando a geração de imagem anterior. Para adicionar somente colunas que fazem parte das chaves primárias da tabela, use o valor padrão, `pk-only`. Para adicionar qualquer coluna que tenha um valor de imagem anterior, use `all`. Observe que a imagem anterior não é compatível com tipos de dados de objetos binários grandes (LOB), como CLOB e BLOB.
O exemplo a seguir mostra a utilização de `BeforeImageSettings`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
Para obter informações sobre as configurações de imagem anterior para o Kinesis, incluindo configurações adicionais de mapeamento de tabela, consulte [Utilizar uma imagem anterior para visualizar valores originais de linhas da CDC para um fluxo de dados do Kinesis como destino](CHAP_Target.Kinesis.md#CHAP_Target.Kinesis.BeforeImage).
Para obter informações sobre as configurações de imagem anterior para o Kafka, incluindo configurações adicionais de mapeamento de tabela, consulte [Utilizar uma imagem anterior para visualizar os valores originais de linhas da CDC para o Apache Kafka como destino](CHAP_Target.Kafka.md#CHAP_Target.Kafka.BeforeImage).
# Configurações de tarefa de tratamento de erros
É possível definir o comportamento do tratamento de erros da tarefa de replicação ao utilizar as seguintes configurações. Para obter informações sobre como utilizar um arquivo de configuração de tarefas para definir as configurações de tarefas, consulte [Exemplo de configurações de tarefas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
+ `DataErrorPolicy`— Determina a ação que o AWS DMS executa quando há um erro relacionado ao processamento de dados no nível do registro. Erros de conversão, erros de transformação e dados ruins são alguns exemplos de erros de processamento de dados. O padrão é `LOG_ERROR`.
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados. O contador de erros para a propriedade `DataErrorEscalationCount` foi incrementado. Portanto, se você definir um limite de erros para uma tabela, este erro será contado para esse limite.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `DataTruncationErrorPolicy`: determina a ação que o AWS DMS realiza quando os dados estão truncados. O padrão é `LOG_ERROR`.
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados. O contador de erros para a propriedade `DataErrorEscalationCount` foi incrementado. Portanto, se você definir um limite de erros para uma tabela, este erro será contado para esse limite.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `DataErrorEscalationPolicy`: determina a ação que o AWS DMS realiza quando o número máximo de erros (definido no parâmetro `DataErrorEscalationCount`) é atingido. O padrão é `SUSPEND_TABLE`.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `DataErrorEscalationCount`: define o número máximo de erros que podem ocorrer nos dados de um registro específico. Quando esse número é atingido, os dados da tabela que contém o registro de erro são tratados de acordo com a política definida em `DataErrorEscalationPolicy`. O padrão é 0.
+ `EventErrorPolicy`— Determina a ação que o AWS DMS executa quando ocorre um erro ao enviar um evento relacionado à tarefa. Os valores possíveis são
+ `IGNORE`: a tarefa continua e todos os dados associados a esse evento são ignorados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `TableErrorPolicy`: determina a ação que o AWS DMS realiza quando um erro ocorre durante o processamento de dados ou de metadados de uma tabela específica. Esse erro só se aplica a dados gerais da tabela e é relacionado a um registro específico. O padrão é `SUSPEND_TABLE`.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `TableErrorEscalationPolicy`: determina a ação que o AWS DMS realiza quando o número máximo de erros (definido utilizando o parâmetro `TableErrorEscalationCount`). A configuração de usuário padrão, e única, é `STOP_TASK`, onde a tarefa é interrompida e é necessária intervenção manual.
+ `TableErrorEscalationCount`: o número máximo de erros que podem ocorrer devido a dados ou metadados gerais de uma tabela específica. Quando esse número é atingido, os dados da tabela são manipulados de acordo com a política definida em `TableErrorEscalationPolicy`. O padrão é 0.
+ `RecoverableErrorCount`: o número máximo de tentativas feitas para reiniciar uma tarefa quando um erro ambiental ocorre. Após o sistema tentar reiniciar a tarefa o número designado de vezes, ela será interrompida e será necessária intervenção manual. O valor padrão é -1.
Quando você define esse valor como -1, o número de novas tentativas que o DMS faz varia com base no tipo de erro retornado da seguinte forma:
+ **Estado de execução, erro recuperável**: se ocorrer um erro recuperável, como uma conexão perdida ou uma falha na aplicação de destino, o DMS repetirá a tarefa nove vezes.
+ **Estado inicial, erro recuperável**: o DMS repetirá a tarefa seis vezes.
+ **Estado de execução, erro fatal tratado pelo DMS**: o DMS repetirá a tarefa seis vezes.
+ **Estado de execução, erro fatal não tratado pelo DMS**: o DMS não repetirá a tarefa.
+ **Além do acima**: AWS DMS repete a tarefa indefinidamente.
Defina esse valor como 0 para nunca tentar reiniciar uma tarefa.
Recomendamos que você defina os valores de `RecoverableErrorCount` e `RecoverableErrorInterval` para que haja repetições suficientes em intervalos suficientes para que sua tarefa do DMS se recupere adequadamente. Se ocorrer um erro fatal, o DMS interrompe as tentativas de reinicialização na maioria dos cenários.
+ `RecoverableErrorInterval`— O número de segundos que o AWS DMS espera entre as tentativas de reiniciar uma tarefa. O padrão é 5.
+ `RecoverableErrorThrottling`: quando ativado, o intervalo entre as tentativas de reiniciar uma tarefa é aumentado em uma série com base no valor de `RecoverableErrorInterval`. Por exemplo, se `RecoverableErrorInterval` estiver definido como 5 segundos, a próxima tentativa ocorrerá após 10 segundos, depois 20, depois 40 segundos e assim por diante. O padrão é `true`.
+ `RecoverableErrorThrottlingMax`— O número máximo de segundos que o AWS DMS espera entre as tentativas de reiniciar uma tarefa, se `RecoverableErrorThrottling` estiver ativado. O padrão é 1800.
+ `RecoverableErrorStopRetryAfterThrottlingMax`— O valor padrão é definido como`true`, e o DMS para de retomar a tarefa após atingir o número máximo de segundos de AWS DMS espera entre as tentativas de recuperação, por. `RecoverableErrorStopRetryAfterThrottlingMax` Quando definido como`false`, o DMS continua retomando a tarefa após atingir o número máximo de segundos de AWS DMS espera entre as tentativas de recuperação, por `RecoverableErrorStopRetryAfterThrottlingMax` até `RecoverableErrorCount` ser atingido.
+ `ApplyErrorDeletePolicy`: determina a ação que o AWS DMS realiza quando há um conflito com uma operação DELETE. O padrão é `IGNORE_RECORD`. Os valores possíveis são os seguintes:
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados. O contador de erros para a propriedade `ApplyErrorEscalationCount` foi incrementado. Portanto, se você definir um limite de erros para uma tabela, este erro será contado para esse limite.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `ApplyErrorInsertPolicy`: determina a ação que o AWS DMS realiza quando há um conflito com uma operação INSERT. O padrão é `LOG_ERROR`. Os valores possíveis são os seguintes:
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados. O contador de erros para a propriedade `ApplyErrorEscalationCount` foi incrementado. Portanto, se você definir um limite de erros para uma tabela, este erro será contado para esse limite.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `INSERT_RECORD`: se houver um registro de destino existente com a mesma chave primária que o registro de origem inserido, o registro de destino será atualizado.
**nota**
**No modo de aplicação transacional**: nesse processo, o sistema primeiro tenta inserir o registro. Se a inserção falhar devido a um conflito de chave primária, ele exclui o registro existente e insere o novo.
**No modo de aplicação em lote**: o processo remove todos os registros existentes no lote de destino antes de inserir o conjunto completo de novos registros, garantindo uma substituição ordenada dos dados.
Esse processo evita a duplicação de dados, mas gera algum custo de desempenho em comparação com a política padrão. O impacto exato no desempenho depende das características específicas de sua carga de trabalho.
+ `ApplyErrorUpdatePolicy`: determina a ação que o AWS DMS realiza quando há um conflito de dados ausentes com uma operação UPDATE. O padrão é `LOG_ERROR`. Os valores possíveis são os seguintes:
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados. O contador de erros para a propriedade `ApplyErrorEscalationCount` foi incrementado. Portanto, se você definir um limite de erros para uma tabela, este erro será contado para esse limite.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `UPDATE_RECORD`— Se o registro de destino estiver ausente, o registro de destino ausente será inserido na tabela de destino. AWS DMS desativa completamente o suporte da coluna LOB para a tarefa. Selecionar essa opção requer que o registro em log suplementar total seja ativado para todas as colunas da tabela de origem quando o Oracle é o banco de dados de origem.
**nota**
**No modo de aplicação transacional**: nesse processo, o sistema primeiro tenta atualizar o registro. Se a atualização falhar devido à falta de um registro no destino, ele executará uma exclusão do registro com falha e inserirá o novo. Esse processo requer um registro em log suplementar completo para bancos de dados Oracle de origem, e o DMS desabilita a compatibilidade com a coluna de LOB para essa tarefa.
**No modo de aplicação em lote**: o processo remove todos os registros existentes no lote de destino antes de inserir o conjunto completo de novos registros, garantindo uma substituição ordenada dos dados.
+ `ApplyErrorEscalationPolicy`— Determina qual ação o AWS DMS executa quando o número máximo de erros (definido usando o `ApplyErrorEscalationCount` parâmetro) é atingido. O padrão é LOG\$1ERROR:
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
+ `STOP_TASK`: a tarefa é interrompida, e intervenção manual é requerida.
+ `ApplyErrorEscalationCount`: esta opção define o número máximo de conflitos de APPLY que pode ocorrer para uma tabela específica durante uma operação de processo de alteração. Quando esse número é atingido, os dados da tabela são manipulados de acordo com a política definida no parâmetro `ApplyErrorEscalationPolicy`. O padrão é 0.
+ `ApplyErrorFailOnTruncationDdl`: defina esta opção como `true` para fazer com que a tarefa falhe quando um truncamento for executado em uma das tabelas rastreadas durante a CDC. O padrão é `false`.
Essa abordagem não funciona com o PostgreSQL versão 11.x ou inferior, ou qualquer outro endpoint de origem que não replica o truncamento da tabela de DDL.
+ `FailOnNoTablesCaptured`: defina esta opção como `true` para que uma tarefa falhe quando os mapeamentos de tabelas definidos para uma tarefa não encontrarem tabelas quando a tarefa for iniciada. O padrão é `true`.
+ `FailOnTransactionConsistencyBreached`: esta opção se aplica a tarefas que utilizam o Oracle como uma origem com CDC. O padrão é falso. Defina como `true` para fazer com que uma tarefa falhe quando uma transação permanecer aberta por um tempo maior do que o limite especificado e puder ser descartada.
Quando uma tarefa do CDC começa com o Oracle, AWS DMS aguarda por um tempo limitado até que a transação aberta mais antiga seja fechada antes de iniciar o CDC. Se a transação aberta mais antiga não fechar até que o tempo limite seja atingido, na maioria dos casos AWS DMS iniciará o CDC, ignorando essa transação. Se essa opção for definida como `true`, a tarefa falhará.
+ `FullLoadIgnoreConflicts`— Defina essa opção `true` para AWS DMS ignorar os erros de “zero linhas afetadas” e “duplicatas” ao aplicar eventos em cache. Se definido como`false`, AWS DMS relata todos os erros em vez de ignorá-los. O padrão é `true`.
+ `DataMaskingErrorPolicy`— determina a ação tomada AWS DMS quando o mascaramento de dados falha devido a um tipo de dados incompatível ou por qualquer outro motivo. As seguintes opções estão disponíveis:
+ `STOP_TASK` (padrão): a tarefa é interrompida, exigindo intervenção manual.
+ `IGNORE_RECORD`: a tarefa continua, e os dados daquele registro são ignorados.
+ `LOG_ERROR`: a tarefa continua, e o erro é gravado no log de tarefas. Os dados não mascarados serão carregados na tabela de destino.
+ `SUSPEND_TABLE`: a tarefa continua, mas os dados da tabela com o registro do erro são movidos para um estado de erro e os dados não são replicados.
**nota**
Os erros de carregamento da tabela no Redshift como destino são relatados em. `STL_LOAD_ERRORS` Para obter mais informações, consulte [STL\$1LOAD\$1ERRORS](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
**nota**
As alterações de parâmetros relacionadas a erros recuperáveis só entram em vigor depois que você interrompe e retoma a tarefa do DMS. As alterações não se aplicam à execução atual.
# Salvar configurações de tarefa
É possível salvar as configurações de tarefa como um arquivo JSON caso você queira reutilizá-las em outra tarefa. É possível encontrar as configurações de tarefas para copiar para um arquivo JSON na seção **Detalhes da visão geral** de uma tarefa.
**nota**
Ao reutilizar as configurações de tarefas para outras tarefas, remova todos os atributos `CloudWatchLogGroup` e `CloudWatchLogStream`. Caso contrário, o seguinte erro será fornecido: MENSAGEM DE ERRO DO SISTEMA:Configurações da tarefa CloudWatchLogGroup ou CloudWatchLogStream não podem ser definidas na criação.
Por exemplo, o seguinte arquivo JSON contém as configurações salvas de uma tarefa.
```
{
"TargetMetadata": {
"TargetSchema": "",
"SupportLobs": true,
"FullLobMode": false,
"LobChunkSize": 0,
"LimitedSizeLobMode": true,
"LobMaxSize": 32,
"InlineLobMaxSize": 0,
"LoadMaxFileSize": 0,
"ParallelLoadThreads": 0,
"ParallelLoadBufferSize": 0,
"BatchApplyEnabled": false,
"TaskRecoveryTableEnabled": false,
"ParallelLoadQueuesPerThread": 0,
"ParallelApplyThreads": 0,
"ParallelApplyBufferSize": 0,
"ParallelApplyQueuesPerThread": 0
},
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
"StopTaskCachedChangesApplied": false,
"StopTaskCachedChangesNotApplied": false,
"MaxFullLoadSubTasks": 8,
"TransactionConsistencyTimeout": 600,
"CommitRate": 10000
},
"Logging": {
"EnableLogging": true,
"LogComponents": [
{
"Id": "TRANSFORMATION",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "SOURCE_UNLOAD",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "IO",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "TARGET_LOAD",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "PERFORMANCE",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "SOURCE_CAPTURE",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "SORTER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "REST_SERVER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "VALIDATOR_EXT",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "TARGET_APPLY",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "TASK_MANAGER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "TABLES_MANAGER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "METADATA_MANAGER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "FILE_FACTORY",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "COMMON",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "ADDONS",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "DATA_STRUCTURE",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "COMMUNICATION",
"Severity": "LOGGER_SEVERITY_DEFAULT"
},
{
"Id": "FILE_TRANSFER",
"Severity": "LOGGER_SEVERITY_DEFAULT"
}
]
},
"ControlTablesSettings": {
"ControlSchema": "",
"HistoryTimeslotInMinutes": 5,
"HistoryTableEnabled": false,
"SuspendedTablesTableEnabled": false,
"StatusTableEnabled": false,
"FullLoadExceptionTableEnabled": false
},
"StreamBufferSettings": {
"StreamBufferCount": 3,
"StreamBufferSizeInMB": 8,
"CtrlStreamBufferSizeInMB": 5
},
"ChangeProcessingDdlHandlingPolicy": {
"HandleSourceTableDropped": true,
"HandleSourceTableTruncated": true,
"HandleSourceTableAltered": true
},
"ErrorBehavior": {
"DataErrorPolicy": "LOG_ERROR",
"DataTruncationErrorPolicy": "LOG_ERROR",
"DataErrorEscalationPolicy": "SUSPEND_TABLE",
"DataErrorEscalationCount": 0,
"TableErrorPolicy": "SUSPEND_TABLE",
"TableErrorEscalationPolicy": "STOP_TASK",
"TableErrorEscalationCount": 0,
"RecoverableErrorCount": -1,
"RecoverableErrorInterval": 5,
"RecoverableErrorThrottling": true,
"RecoverableErrorThrottlingMax": 1800,
"RecoverableErrorStopRetryAfterThrottlingMax": true,
"ApplyErrorDeletePolicy": "IGNORE_RECORD",
"ApplyErrorInsertPolicy": "LOG_ERROR",
"ApplyErrorUpdatePolicy": "LOG_ERROR",
"ApplyErrorEscalationPolicy": "LOG_ERROR",
"ApplyErrorEscalationCount": 0,
"ApplyErrorFailOnTruncationDdl": false,
"FullLoadIgnoreConflicts": true,
"FailOnTransactionConsistencyBreached": false,
"FailOnNoTablesCaptured": true
},
"ChangeProcessingTuning": {
"BatchApplyPreserveTransaction": true,
"BatchApplyTimeoutMin": 1,
"BatchApplyTimeoutMax": 30,
"BatchApplyMemoryLimit": 500,
"BatchSplitSize": 0,
"MinTransactionSize": 1000,
"CommitTimeout": 1,
"MemoryLimitTotal": 1024,
"MemoryKeepTime": 60,
"StatementCacheSize": 50
},
"PostProcessingRules": null,
"CharacterSetSettings": null,
"LoopbackPreventionSettings": null,
"BeforeImageSettings": null,
"FailTaskWhenCleanTaskResourceFailed": false
}
```