

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Paramètres de métadonnées des tâches cibles
<a name="CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata"></a>

Les paramètres de métadonnées cibles sont les suivants. Pour en savoir plus sur l’utilisation d’un fichier de configuration de tâche pour définir les paramètres d’une tâche, consultez [Exemple de paramètres de tâche](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example).
+ `TargetSchema` : nom du schéma de la table cible. Si cette option de métadonnées est vide, le schéma de la table source est utilisé. AWS DMS ajoute automatiquement le préfixe du propriétaire de la base de données cible à toutes les tables si aucun schéma source n'est défini. Cette option doit être vide pour les points de terminaison cibles MySQL-type. Le changement de nom d’un schéma dans le mappage de données est prioritaire sur ce paramètre.
+ Paramètres LOB : paramètres qui déterminent le mode de gestion des objets de grande taille (LOBs). Si vous définissez `SupportLobs=true`, vous devez définir les éléments suivants à la valeur `true` : 
  + `FullLobMode` : si vous définissez cette option sur `true`, vous devez entrer une valeur pour l’option `LobChunkSize`. Entrez la taille, en kilo-octets, des blocs du LOB à utiliser lors de la réplication des données à la cible. L'option `FullLobMode` est la mieux adaptée pour les très grandes tailles de LOB, mais elle a tendance à ralentir le chargement. La valeur recommandée pour `LobChunkSize` est de 64 kilo-octets. L’augmentation de la valeur de `LobChunkSize` au-delà de 64 kilo-octets peut entraîner l’échec des tâches.
  + `InlineLobMaxSize`— Cette valeur détermine les LOBs AWS DMS transferts en ligne lors d'un chargement complet. LOBs Il est plus efficace de transférer de petits fichiers que de les rechercher dans une table source. Lors d'un chargement complet, AWS DMS vérifie tout LOBs et effectue un transfert en ligne pour LOBs les valeurs inférieures à`InlineLobMaxSize`. AWS DMS les transferts sont tous LOBs supérieurs `InlineLobMaxSize` à l'entrée`FullLobMode`. La valeur par défaut pour `InlineLobMaxSize` est 0 et la plage est de 1 à 102 400 kilo-octets (100 Mo). Définissez une valeur pour `InlineLobMaxSize` uniquement si vous savez que la plupart d'entre LOBs elles sont inférieures à la valeur spécifiée dans`InlineLobMaxSize`.
  + `LimitedSizeLobMode` : si vous définissez cette option sur `true`, vous devez entrer une valeur pour l’option `LobMaxSize`. Saisissez la taille maximale, en kilo-octets, pour un LOB individuel. La valeur maximale pour `LobMaxSize` est de 102 400 kilo-octets (100 Mo).

  Pour plus d’informations sur les critères d’utilisation de ces paramètres LOB de tâche, consultez [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md). Vous pouvez également contrôler la gestion LOBs de quatre tables individuelles. Pour de plus amples informations, veuillez consulter [Règles des paramètres de table et de collection et opérations](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
+ `BatchApplyEnabled` : détermine si chaque transaction est appliquée individuellement ou si les modifications sont validées par lots. La valeur par défaut est `false`.

  Lorsque `BatchApplyEnabled` est défini sur `true`, DMS nécessite une clé primaire (PK) ou une clé unique (UK) sur la ou les tables **sources**. Sans PK ou UK dans les tables sources, seules les insertions par lots sont appliquées, pas les mises à jour ni les suppressions par lots.

  Lorsque `BatchApplyEnabled` est défini sur `true`, AWS DMS génère un message d’erreur si une table **cible** possède une contrainte unique et une clé primaire. Les tables cibles comportant à la fois une contrainte unique et une clé primaire ne sont pas prises en charge lorsque `BatchApplyEnabled` est défini sur `true`.

  Lorsqu'elle `BatchApplyEnabled` est définie sur true et qu'elle AWS DMS rencontre une erreur de données dans une table dotée de la politique de gestion des erreurs par défaut, la AWS DMS tâche passe du mode batch au one-by-one mode pour les autres tables. Pour modifier ce comportement, vous pouvez définir l’action `"SUSPEND_TABLE"` sur les politiques suivantes dans la propriété de groupe `"ErrorBehavior"` du fichier JSON des paramètres de tâche :
  + `DataErrorPolicy`
  + `ApplyErrorDeletePolicy`
  + `ApplyErrorInsertPolicy`
  + `ApplyErrorUpdatePolicy`

  Pour plus d’informations sur cette propriété de groupe `"ErrorBehavior"`, consultez l’exemple de fichier JSON des paramètres de tâche dans [Spécification des paramètres des tâches pour les tâches du AWS Database Migration Service](CHAP_Tasks.CustomizingTasks.TaskSettings.md). Une fois ces politiques définies sur`"SUSPEND_TABLE"`, la AWS DMS tâche suspend les erreurs de données sur toutes les tables qui les génèrent et continue en mode batch pour toutes les tables.

  Vous pouvez utiliser le paramètre `BatchApplyEnabled` avec le paramètre `BatchApplyPreserveTransaction`. Si `BatchApplyEnabled` est défini sur `true`, le paramètre `BatchApplyPreserveTransaction` détermine l'intégrité transactionnelle. 

  Si `BatchApplyPreserveTransaction` est défini sur `true`, l'intégrité transactionnelle est préservée et un lot est assuré de contenir toutes les modifications effectuées dans une transaction à partir de la source.

  Si `BatchApplyPreserveTransaction` est défini sur `false`, il peut exister des écarts temporaires dans l'intégrité transactionnelle afin d'améliorer les performances. 

  Le paramètre `BatchApplyPreserveTransaction` s'applique uniquement aux points de terminaison cible Oracle, et est approprié uniquement lorsque le paramètre `BatchApplyEnabled` est défini sur `true`.

  Lorsque les colonnes LOB sont incluses dans la réplication, vous pouvez utiliser `BatchApplyEnabled` uniquement en mode LOB limité.

  Pour plus d’informations sur l’utilisation de ces paramètres pour un chargement de capture des données de modification (CDC), consultez [Paramètres de réglage du traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ `MaxFullLoadSubTasks` : indique le nombre maximal de tables à charger en parallèle. La valeur par défaut est 8 ; la valeur maximale 49.
+ `ParallelLoadThreads`— Spécifie le nombre de threads AWS DMS utilisés pour charger chaque table dans la base de données cible. Ce paramètre possède des valeurs maximales pour les cibles autres que les SGBDR. La valeur maximale pour une cible DynamoDB est 200. La valeur maximale pour une cible Amazon Kinesis Data Streams, Apache Kafka ou OpenSearch Amazon Service est de 32. Vous pouvez demander une augmentation de cette limite maximale. `ParallelLoadThreads` s’applique aux tâches de chargement complet. Pour plus d'informations sur les paramètres qui activent le chargement parallèle des tables individuelles, consultez [Règles des paramètres de table et de collection et opérations](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).

  Ce paramètre s’applique aux types de moteurs de point de terminaison suivants :
  + DynamoDB
  + Amazon Kinesis Data Streams
  + Amazon MSK
  + Amazon OpenSearch Service
  + Amazon Redshift

  AWS DMS prend en `ParallelLoadThreads` charge MySQL en tant qu'attribut de connexion supplémentaire. `ParallelLoadThreads`ne s'applique pas à MySQL en tant que paramètre de tâche. 
+ `ParallelLoadBufferSize` : spécifie le nombre maximal d’enregistrements à stocker dans la mémoire tampon utilisée par les threads de chargement parallèles pour charger les données sur la cible. La valeur par défaut est 50. La valeur maximale est 1 000. Ce paramètre n'est actuellement valide que lorsque DynamoDB, Kinesis, Apache Kafka OpenSearch ou R est la cible. Utilisez ce paramètre avec `ParallelLoadThreads`. `ParallelLoadBufferSize` est valide uniquement dans le cas de plusieurs threads. Pour plus d'informations sur les paramètres qui activent le chargement parallèle des tables individuelles, consultez [Règles des paramètres de table et de collection et opérations](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
+ `ParallelLoadQueuesPerThread` : spécifie le nombre de files d’attente auxquelles chaque thread simultané accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour la cible. La valeur par défaut est 1. Ce paramètre n’est actuellement valide que lorsque Kinesis ou Apache Kafka est la cible.
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement par le CDC pour transférer des enregistrements de données vers un point de terminaison cible Amazon DocumentDB, Kinesis, Amazon MSK OpenSearch ou Amazon Redshift. La valeur par défaut est zéro (0).

  Ce paramètre ne s’applique qu’à la CDC uniquement. Ce paramètre ne s’applique pas au chargement complet.

  

  Ce paramètre s’applique aux types de moteurs de point de terminaison suivants :
  + Amazon DocumentDB (compatible avec MongoDB)
  + Amazon Kinesis Data Streams
  + Amazon Managed Streaming for Apache Kafka
  + Amazon OpenSearch Service
  + Amazon Redshift
+ `ParallelApplyBufferSize`— Spécifie le nombre maximum d'enregistrements à stocker dans chaque file d'attente tampon pour les threads simultanés à envoyer vers un point de terminaison cible Amazon DocumentDB, Kinesis, Amazon MSK OpenSearch ou Amazon Redshift lors d'un chargement CDC. La valeur par défaut est 100. La valeur maximale est de 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads. 
+ `ParallelApplyQueuesPerThread`— Spécifie le nombre de files d'attente auxquelles chaque thread accède pour extraire des enregistrements de données des files d'attente et générer un chargement par lots pour un Amazon DocumentDB, Kinesis, Amazon MSK ou un point de terminaison pendant le CDC. OpenSearch La valeur par défaut est 1.