

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

# Configurações de tarefa de metadados de destino
<a name="CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata"></a>

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 ser deixada vazia para os endpoints de MySQL-type destino. 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 são AWS DMS transferidos em linha durante uma carga completa. A transferência de LOBs pequenos é mais eficiente do que procurá-los em uma tabela de origem. Durante uma carga completa, AWS DMS verifica todos os LOBs e executa uma transferência em linha para os LOBs menores que. `InlineLobMaxSize` AWS DMS transfere todos os LOBs maiores do que a entrada`InlineLobMaxSize`. `FullLobMode` O valor padrão de `InlineLobMaxSize` é 0, e o intervalo é de 1 a 102400 kilobytes (100 MB). Defina um valor para `InlineLobMaxSize` somente se você souber que a maioria dos LOBs é menor 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 um AWS DMS task](CHAP_Tasks.LOBSupport.md). Também é possível controlar o gerenciamento de LOBs para 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` é definido como verdadeiro e AWS DMS encontra um erro de dados de uma tabela com a política padrão de tratamento de erros, a AWS DMS tarefa muda do modo batch para o modo um por um para o resto das tabelas. 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 AWS Tarefas do serviço de migração de banco](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 segmentos 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 Amazon OpenSearch 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. Atualmente, essa configuração só é válida quando o DynamoDB, Kinesis, Apache Kafka or é 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 de CDC para enviar registros de dados para um endpoint de destino do Amazon DocumentDB, Kinesis, Amazon MSK ou Amazon OpenSearch Redshift. O padrão é zero (0).

  Essa configuração só se aplica CDC-only a. 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 Amazon Redshift durante um OpenSearch carregamento de 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.