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.
# Spécification des paramètres des tâches pour les tâches du AWS Database Migration Service
Chaque tâche possède des paramètres que vous pouvez configurer selon les besoins de votre migration de base de données. Vous créez ces paramètres dans un fichier JSON ou, avec certains paramètres, vous pouvez les définir à l'aide de la AWS DMS console. 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.Example).
Il existe plusieurs types principaux de paramètres de tâche, comme présenté ci-dessous.
**Topics**
+ [
## Exemple de paramètres de tâche
](#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)
+ [
# Paramètres de métadonnées des tâches cibles
](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md)
+ [
# Paramètres de tâche de chargement complet
](CHAP_Tasks.CustomizingTasks.TaskSettings.FullLoad.md)
+ [
# Paramètres de tâche de voyage dans le temps
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.md)
+ [
# Paramètres de la tâche de journalisation
](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)
+ [
# Paramètres de tâche de la table de contrôle
](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md)
+ [
# Paramètres de tâche de mémoire tampon de flux
](CHAP_Tasks.CustomizingTasks.TaskSettings.StreamBuffer.md)
+ [
# Paramètres de réglage du traitement des modifications
](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md)
+ [
# Paramètres de la tâche de validation des données
](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)
+ [
# Paramètres de resynchronisation des données
](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md)
+ [
# Paramètres de tâche pour la gestion du DDL de traitement des modifications
](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md)
+ [
# Paramètres de tâche de substitution de caractères
](CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.md)
+ [
# Paramètres de tâche de l’image antérieure
](CHAP_Tasks.CustomizingTasks.TaskSettings.BeforeImage.md)
+ [
# Paramètres de traitement des erreurs pour une tâche
](CHAP_Tasks.CustomizingTasks.TaskSettings.ErrorHandling.md)
+ [
# Paramètres de tâche d'enregistrement
](CHAP_Tasks.CustomizingTasks.TaskSettings.Saving.md)
| Paramètres de tâche | Documentation utile |
| --- | --- |
| **Création d’un rapport d’évaluation de tâche** Vous pouvez créer un rapport d'évaluation de tâche qui présente tous les types de données non pris en charge qui peuvent entraîner des problèmes lors de la migration. Vous pouvez exécuter ce rapport sur votre tâche avant l'exécution de la tâche afin de découvrir les problèmes potentiels. | [Activation et utilisation des évaluations de prémigration pour une tâche](CHAP_Tasks.AssessmentReport.md) |
| **Création d’une tâche** Lorsque vous créez une tâche, vous spécifiez la source, la cible et l'instance de réplication, ainsi que les paramètres de migration. | [Création d’une tâche](CHAP_Tasks.Creating.md) |
| **Création d’une tâche de réplication continue** Vous pouvez configurer une tâche afin de fournir une réplication continue entre la source et la cible. | [Création de tâches pour une réplication continue à l'aide de AWS DMS](CHAP_Task.CDC.md) |
| **Application des paramètres de tâche** Chaque tâche possède des paramètres que vous pouvez configurer selon les besoins de votre migration de base de données. Vous créez ces paramètres dans un fichier JSON ou, avec certains paramètres, vous pouvez les définir à l'aide de la AWS DMS console. | [Spécification des paramètres des tâches pour les tâches du AWS Database Migration Service](#CHAP_Tasks.CustomizingTasks.TaskSettings) |
| **Validation des données** Utilisez la validation des données pour AWS DMS comparer les données de votre magasin de données cible avec celles de votre magasin de données source. | [AWS Validation des données DMS](CHAP_Validating.md) |
| **Modification d’une tâche** Lorsqu'une tâche est arrêtée, vous pouvez modifier les paramètres de la tâche. | [Modification d’une tâche](CHAP_Tasks.Modifying.md) |
| **Rechargement de tables pendant une tâche** Vous pouvez recharger une table pendant une tâche si une erreur se produit pendant la tâche. | [Rechargement de tables pendant une tâche](CHAP_Tasks.ReloadTables.md) |
| **Utilisation d’un mappage de tables** Le mappage de table utilise différents types de règles afin de spécifier les paramètres de tâche pour la source de données, le schéma source, les données et toutes les transformations qui doivent se produire pendant la tâche. | Règles de sélection [Règles et actions de sélection](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md) Règles de transformation [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md) |
| **Application de filtres** Vous pouvez utiliser des filtres de source pour limiter le nombre et le type d'enregistrements transférés de votre source vers votre cible. Par exemple, vous pouvez spécifier que seuls les employés avec un emplacement de siège sont déplacés vers la base de données cible. Vous appliquez des filtres sur une colonne de données. | [Utilisation de filtres de source](CHAP_Tasks.CustomizingTasks.Filters.md) |
| Surveillance d’une tâche Il existe plusieurs façons d'obtenir des informations sur les performances d'une tâche et sur les tables utilisées par la tâche. | [Surveillance des AWS tâches DMS](CHAP_Monitoring.md) |
| Gestion des journaux de tâches Vous pouvez consulter et supprimer les journaux des tâches à l'aide de l' AWS DMS API ou AWS CLI. | [Affichage et gestion des journaux AWS de tâches DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) |
## Exemple de paramètres de tâche
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer une tâche de réplication. Si vous utilisez le AWS CLI, vous définissez les paramètres des tâches en créant un fichier JSON, puis en spécifiant l'URI file ://du fichier JSON comme [ ReplicationTaskSettings](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html#DMS-CreateReplicationTask-request-ReplicationTaskSettings)paramètre de l'[CreateReplicationTask](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html)opération.
L'exemple suivant montre comment utiliser le AWS CLI pour appeler l'`CreateReplicationTask`opération :
```
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
```
L’exemple précédent utilise un fichier de mappage de table appelé `tablemappings.json`. Pour obtenir des exemples de mappage de table, consultez [Utilisation du mappage de table pour spécifier des paramètres de tâche](CHAP_Tasks.CustomizingTasks.TableMapping.md).
Un fichier JSON de paramètres de tâche peut se présenter comme suit :
```
{
"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
}
}
```
# Paramètres de métadonnées des tâches cibles
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.
# Paramètres de tâche de chargement complet
Les paramètres de chargement complet 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).
+ Pour indiquer comment gérer le chargement de la cible au démarrage du chargement complet, spécifiez l'une des valeurs suivantes pour l'option `TargetTablePrepMode` :
+ `DO_NOTHING` : les données et les métadonnées de la table cible existante ne sont pas concernées.
+ `DROP_AND_CREATE` : la table existante est supprimée et une nouvelle table est créée à la place.
+ `TRUNCATE_BEFORE_LOAD` : les données sont tronquées sans impact sur les métadonnées de la table.
+ Pour retarder la création d’une clé primaire ou d’un index unique jusqu’à la fin d’un chargement complet, définissez l’option `CreatePkAfterFullLoad` sur `true`.
+ Pour les tâches de chargement complet et CDC, vous pouvez définir les options suivantes pour `Stop task after full load completes` :
+ `StopTaskCachedChangesApplied` : définissez cette option sur `true` pour arrêter une tâche après la fin d’un chargement complet et pour appliquer les modifications mises en cache.
+ `StopTaskCachedChangesNotApplied` : définissez cette option sur `true` pour arrêter une tâche avant l’application des modifications mises en cache.
+ Pour indiquer le nombre maximal de tables à charger en parallèle, définissez l'option `MaxFullLoadSubTasks`. La valeur par défaut est 8 ; la valeur maximale 49.
+ Définissez l’option `ParallelLoadThreads` pour indiquer le nombre de threads simultanés que DMS utilisera pendant un processus de chargement complet pour transférer des enregistrements de données vers un point de terminaison cible. La valeur par défaut est zéro (0).
**Important**
`MaxFullLoadSubTasks` contrôle le nombre de tables ou de segments de table à charger en parallèle. `ParallelLoadThreads` contrôle le nombre de threads utilisés par une tâche de migration pour exécuter les chargements en parallèle. *Ces paramètres sont multiplicatifs*. Ainsi, le nombre total de threads utilisés lors d’une tâche de chargement complet correspond approximativement au résultat de la valeur de `ParallelLoadThreads ` multipliée par la valeur de `MaxFullLoadSubTasks` (`ParallelLoadThreads` **\$1** `MaxFullLoadSubtasks)`).
Si vous créez des tâches avec un grand nombre de sous-tâches de chargement complet et un grand nombre de threads de chargement parallèle, votre tâche peut consommer trop de mémoire et échouer.
+ Vous pouvez définir le nombre de secondes qui attendent AWS DMS la clôture des transactions avant de commencer une opération de chargement complet. Pour ce faire, si les transactions sont ouvertes lorsque la tâche démarre, définissez l'option `TransactionConsistencyTimeout`. La valeur par défaut est 600 (10 minutes). AWS DMS commence le chargement complet une fois que le délai d'expiration est atteint, même si des transactions sont ouvertes. Une full-load-only tâche n'attend pas 10 minutes mais démarre immédiatement.
+ Pour indiquer le nombre maximal d’enregistrements qui peuvent être transférés ensemble, définissez l’option `CommitRate`. La valeur par défaut est 10 000 et la valeur maximale est 50 000.
# Paramètres de tâche de voyage dans le temps
Pour enregistrer et déboguer les tâches de réplication, vous pouvez utiliser AWS DMS Time Travel. Dans cette approche, vous utilisez Amazon S3 pour stocker les journaux et les chiffrer à l’aide de vos clés de chiffrement. Ce n’est qu’en accédant à votre compartiment S3 de voyage dans le temps que vous pouvez récupérer vos journaux S3 à l’aide de filtres de date et d’heure, puis afficher, télécharger et masquer les journaux selon vos besoins. Ce faisant, vous pouvez « voyager dans le temps » en toute sécurité pour examiner les activités de base de données. Time Travel fonctionne indépendamment de la CloudWatch journalisation. Pour plus d'informations sur la CloudWatch journalisation, consultez[Paramètres de la tâche de journalisation](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md).
Vous pouvez utiliser Time Travel dans toutes les AWS régions avec des points de terminaison sources AWS DMS compatibles avec Oracle, Microsoft SQL Server et PostgreSQL, et des points de terminaison cibles PostgreSQL et MySQL AWS DMS pris en charge. Vous pouvez activer le voyage dans le temps uniquement pour les tâches de chargement complet et de capture des données de modification (CDC) et pour les tâches de CDC uniquement. Pour activer le voyage dans le temps ou pour modifier des paramètres de voyage dans le temps existants, assurez-vous que votre tâche de réplication est arrêtée.
Les paramètres de voyage dans le temps incluent les propriétés `TTSettings` suivantes :
+ `EnableTT` : si cette option est définie sur `true`, la journalisation de voyage dans le temps est activée pour la tâche. La valeur par défaut est `false`.
Type : booléen
Obligatoire : non
+ `EncryptionMode` : type de chiffrement côté serveur actuellement utilisé sur votre compartiment S3 pour stocker vos données et vos journaux. Vous pouvez spécifier `"SSE_S3"` (par défaut) ou `"SSE_KMS"`.
Vous pouvez redéfinir `EncryptionMode` de `"SSE_KMS"` à `"SSE_S3"`, mais pas l’inverse.
Type : chaîne
Obligatoire : non
+ `ServerSideEncryptionKmsKeyId`— Si vous le spécifiez `"SSE_KMS"` pour`EncryptionMode`, fournissez l'ID de votre AWS KMS clé gérée personnalisée. Assurez-vous que la clé que vous utilisez est associée à une politique qui active les autorisations utilisateur Gestion des identités et des accès AWS (IAM) et autorise l'utilisation de la clé.
Seule votre propre clé KMS symétrique gérée personnalisée est prise en charge avec l’option `"SSE_KMS"`.
Type : Chaîne
Obligatoire uniquement si vous définissez `EncryptionMode` sur `"SSE_KMS"`
+ `ServiceAccessRoleArn` : Amazon Resource Name (ARN) utilisé par le service pour accéder au rôle IAM. Définissez le nom du rôle sur `dms-tt-s3-access-role`. Il s'agit d'un paramètre obligatoire qui permet d' AWS DMS écrire et de lire des objets à partir d'un compartiment S3.
Type : Chaîne
Obligatoire si le voyage dans le temps est activé
Voici un exemple de politique pour ce rôle.
------
#### [ 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"
]
}
]
}
```
------
Voici un exemple de politique d’approbation pour ce rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"dms.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
+ `BucketName` : nom du compartiment S3 dans lequel stocker les journaux de voyage dans le temps. Assurez-vous de créer ce compartiment S3 avant d’activer les journaux de voyage dans le temps.
Type : Chaîne
Obligatoire si le voyage dans le temps est activé
+ `BucketFolder` : paramètre facultatif pour définir le nom d’un dossier dans le compartiment S3. Si vous spécifiez ce paramètre, DMS crée les journaux de voyage dans le temps dans le chemin `"/BucketName/BucketFolder/taskARN/YYYY/MM/DD/hh"`. Si vous ne spécifiez pas ce paramètre, AWS DMS crée le chemin par défaut sous la forme`"/BucketName/dms-time-travel-logs/taskARN/YYYY/MM/DD/hh`.
Type : chaîne
Obligatoire : non
+ `EnableDeletingFromS3OnTaskDelete`— Lorsque cette option est définie sur`true`, AWS DMS supprime les journaux de voyage dans le temps de S3 si la tâche est supprimée. La valeur par défaut est `false`.
Type : chaîne
Obligatoire : non
+ `EnableRawData` : lorsque cette option est définie sur `true`, les données brutes DML pour les journaux de voyage dans le temps apparaissent sous la colonne `raw_data` des journaux de voyage dans le temps. Pour obtenir des détails, consultez [Utilisation des journaux de voyage dans le temps](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md). La valeur par défaut est `false`. Lorsque cette option est définie sur `false`, seul le type de DML est capturé.
Type : chaîne
Obligatoire : non
+ `RawDataFormat`— Dans AWS DMS les versions 3.5.0 et supérieures, quand `EnableRawData` est défini sur. `true` Cette propriété spécifie un format pour les données brutes du DML dans un journal de voyage dans le temps. Elle peut se présenter comme suit :
+ `"TEXT"` : noms de colonnes et valeurs lisibles et analysés pour les événements DML capturés pendant la CDC sous forme de champs `Raw`.
+ `"HEX"` : valeur hexadécimale d’origine pour les noms de colonnes et les valeurs capturés pour les événements DML pendant la CDC.
Cette propriété s’applique aux sources de base de données Oracle et Microsoft SQL Server.
Type : chaîne
Obligatoire : non
+ `OperationsToLog` : spécifie le type d’opérations DML pour journaliser les journaux de voyage dans le temps. Vous pouvez spécifier l'une des options suivantes :
+ `"INSERT"`
+ `"UPDATE"`
+ `"DELETE"`
+ `"COMMIT"`
+ `"ROLLBACK"`
+ `"ALL"`
La valeur par défaut est `"ALL"`.
Type : chaîne
Obligatoire : non
+ `MaxRecordSize` : spécifie la taille maximale des enregistrements de journalisation de voyage dans le temps consignés pour chaque ligne. Utilisez cette propriété pour contrôler la croissance des journaux de voyage dans le temps pour les tables particulièrement chargées. La valeur par défaut est de 64 Ko.
Type : Integer
Obligatoire : non
Pour plus d’informations sur l’activation et l’utilisation des journaux de voyage dans le temps, consultez les rubriques suivantes.
**Topics**
+ [
# Activation des journaux de voyage dans le temps pour une tâche
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.TaskEnabling.md)
+ [
# Utilisation des journaux de voyage dans le temps
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md)
+ [
# À quelle fréquence les journaux de voyage AWS DMS dans le temps sont-ils téléchargés sur S3
](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md)
# Activation des journaux de voyage dans le temps pour une tâche
Vous pouvez activer Time Travel pour une AWS DMS tâche à l'aide des paramètres de tâche décrits précédemment. Assurez-vous que votre tâche de réplication est arrêtée avant d’activer le voyage dans le temps.
**Pour activer le voyage dans le temps à l'aide du AWS CLI**
1. Créez un fichier JSON de configuration de tâche DMS et ajoutez la section `TTSettings` suivante. 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).
```
.
.
.
},
"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. Dans une action de tâche appropriée, spécifiez ce fichier JSON à l’aide de l’option `--replication-task-settings`. Par exemple, le fragment de code CLI suivant spécifie ce fichier de paramètres de voyage dans le temps comme faisant partie 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
.
.
.
```
Ici, le nom de ce fichier de paramètres de voyage dans le temps est `task-settings-tt-enabled.json`.
De même, vous pouvez spécifier ce fichier comme faisant partie de l’action `modify-replication-task`.
Notez le traitement spécial des journaux de voyage dans le temps pour les actions de tâche suivantes :
+ `start-replication-task` : lorsque vous exécutez une tâche de réplication, si un compartiment S3 utilisé pour le voyage dans le temps n’est pas accessible, la tâche est marquée comme `FAILED`.
+ `stop-replication-task`— Lorsque la tâche s'arrête, AWS DMS envoie immédiatement tous les journaux de voyage dans le temps actuellement disponibles pour l'instance de réplication vers le compartiment S3 utilisé pour Time Travel.
Pendant l’exécution d’une tâche de réplication, vous pouvez modifier la valeur `EncryptionMode` de `"SSE_KMS"` à `"SSE_S3"`, mais pas l’inverse.
Si la taille des journaux de voyage dans le temps pour une tâche continue dépasse 1 Go, DMS transfère les journaux vers S3 dans un délai de cinq minutes après avoir atteint cette taille. Après l’exécution d’une tâche, si le compartiment S3 ou la clé KMS devient inaccessible, DMS arrête de transférer les journaux vers ce compartiment. Si vous constatez que vos journaux ne sont pas transférés vers votre compartiment S3, vérifiez votre S3 et vos AWS KMS autorisations. Pour plus de détails sur la fréquence à laquelle DMS transfère ces journaux vers S3, consultez [À quelle fréquence les journaux de voyage AWS DMS dans le temps sont-ils téléchargés sur S3](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md).
Pour activer le voyage dans le temps pour une tâche existante à partir de la console, utilisez l’option de l’éditeur JSON sous **Paramètres de tâche** pour ajouter une section `TTSettings`.
# Utilisation des journaux de voyage dans le temps
Les *fichiers journaux de voyage dans le temps* sont des fichiers CSV (valeurs séparées par des virgules) comportant les champs suivants.
```
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
```
Une fois que vos journaux de voyage dans le temps sont disponibles dans S3, vous pouvez y accéder directement et les interroger à l’aide d’outils tels qu’Amazon Athena. Vous pouvez également télécharger les journaux comme n’importe quel fichier à partir de S3.
L’exemple suivant illustre un journal de voyage dans le temps dans lequel les transactions d’une table appelée `mytable` sont journalisées. Les fins de ligne du journal suivant ont été ajoutées pour plus de lisibilité.
```
"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'"
```
# À quelle fréquence les journaux de voyage AWS DMS dans le temps sont-ils téléchargés sur S3
Pour minimiser l'utilisation du stockage par votre instance de réplication, AWS DMS déchargez régulièrement les journaux Time Travel de cette instance.
Les journaux de voyage dans le temps sont transférés vers votre compartiment Amazon S3 dans les cas suivants :
+ Si la taille actuelle des journaux dépasse 1 Go, AWS DMS télécharge les journaux vers S3 dans les cinq minutes. Ainsi, AWS DMS vous pouvez effectuer jusqu'à 12 appels par heure à S3 et AWS KMS pour chaque tâche en cours d'exécution.
+ AWS DMS télécharge les journaux sur S3 toutes les heures, quelle que soit leur taille.
+ Lorsqu'une tâche est arrêtée, télécharge AWS DMS immédiatement les journaux de voyage dans le temps vers S3.
# Paramètres de la tâche de journalisation
La journalisation utilise Amazon CloudWatch pour enregistrer les informations pendant le processus de migration. Les paramètres de tâche de journalisation vous permettent de spécifier les activités de composant qui sont consignées et la quantité d'informations écrites dans le journal. Les paramètres de tâche de journalisation sont écrits dans un fichier JSON. 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).
Vous pouvez activer la CloudWatch journalisation de différentes manières. Vous pouvez sélectionner l'`EnableLogging`option AWS Management Console lorsque vous créez une tâche de migration. Vous pouvez également définir l'`EnableLogging`option sur `true` lors de la création d'une tâche à l'aide de l' AWS DMS API. Vous pouvez également spécifier `"EnableLogging": true` dans le code JSON de la section de journalisation des paramètres de la tâche.
Lorsque vous définissez sur`true`, `EnableLogging` AWS DMS assignez le nom du CloudWatch groupe et le nom du flux comme suit. Vous ne pouvez pas définir ces valeurs directement.
+ **CloudWatchLogGroup**: `dms-tasks-`
+ **CloudWatchLogStream**: `dms-task-`
`` est l’identifiant de l’instance de réplication. `` est la valeur de la section `` de l’ARN de tâche. Pour plus d'informations sur le mode AWS DMS de génération des ressources ARNs, consultez[Création d'un nom de ressource Amazon (ARN) pour AWS DMS](CHAP_Introduction.AWS.ARN.md).
CloudWatch s'intègre à Gestion des identités et des accès AWS (IAM), et vous pouvez spécifier CloudWatch les actions qu'un utilisateur de votre AWS compte peut effectuer. Pour plus d'informations sur l'utilisation d'IAM dans CloudWatch, consultez [Gestion des identités et des accès pour Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) et [Journalisation des appels d' CloudWatch API Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html) dans le *guide de l' CloudWatch utilisateur Amazon*.
Pour supprimer les journaux d'une tâche, vous pouvez définir `DeleteTaskLogs` sur true dans le code JSON de la section de journalisation des paramètres de la tâche.
Vous pouvez spécifier la journalisation pour les types d’événements suivants :
+ `FILE_FACTORY` : la fabrique de fichiers gère les fichiers utilisés pour l’application et le chargement par lots, et gère les points de terminaison Amazon S3.
+ `METADATA_MANAGER` : le gestionnaire de métadonnées gère les métadonnées sources et cibles, le partitionnement et l’état des tables pendant la réplication.
+ `SORTER` : `SORTER` reçoit les événements entrants du processus `SOURCE_CAPTURE`. Les événements sont regroupés dans des transactions et transmis au composant de service `TARGET_APPLY`. Si le processus `SOURCE_CAPTURE` produit des événements plus rapidement que le composant `TARGET_APPLY` ne peut les consommer, le composant `SORTER` met en cache les événements en attente sur le disque ou dans un fichier d’échange. Les événements mis en cache sont une cause fréquente de manque d’espace de stockage dans les instances de réplication.
Le composant de service `SORTER` gère les événements mis en cache, collecte les statistiques de CDC et signale le temps de latence des tâches.
+ `SOURCE_CAPTURE` : les données de réplication continue (CDC) sont capturées à partir de la base de données ou du service source et sont transmises au composant de service SORTER.
+ `SOURCE_UNLOAD` : les données sont déchargées de la base de données ou du service source pendant le chargement complet.
+ `TABLES_MANAGER` : le gestionnaire de tables suit les tables capturées, gère l’ordre de migration des tables et collecte les statistiques des tables.
+ `TARGET_APPLY` : les données et les instructions DDL sont appliquées à la base de données cible.
+ `TARGET_LOAD` : les données sont chargées dans la base de données cible.
+ `TASK_MANAGER` : le gestionnaire de tâches gère les tâches en cours et les décompose en sous-tâches pour le traitement parallèle des données.
+ `TRANSFORMATION` : événements de transformation liés au mappage de table. Pour de plus amples informations, veuillez consulter [Utilisation du mappage de table pour spécifier des paramètres de tâche](CHAP_Tasks.CustomizingTasks.TableMapping.md).
+ `VALIDATOR/ VALIDATOR_EXT` : le composant de service `VALIDATOR` vérifie que les données ont été migrées correctement de la source vers la cible. Pour de plus amples informations, veuillez consulter [Validation des données](CHAP_Validating.md).
+ `DATA_RESYNC`— Composant commun de la fonctionnalité de resynchronisation des données qui gère le flux de resynchronisation des données. Pour de plus amples informations, veuillez consulter [AWS DMS resynchronisation des données](CHAP_Validating.DataResync.md).
+ `RESYNC_UNLOAD`— Les données sont déchargées de la base de données ou du service source pendant le processus de resynchronisation.
+ `RESYNC_APPLY`— Les instructions DML (Data Manipulation Language) sont appliquées à la base de données cible lors de la resynchronisation.
Les composants de journalisation suivants génèrent un grand nombre de journaux lorsque le niveau de gravité des journaux `LOGGER_SEVERITY_DETAILED_DEBUG` est utilisé :
+ `COMMON`
+ `ADDONS`
+ `DATA_STRUCTURE`
+ `COMMUNICATION`
+ `FILE_TRANSFER`
+ `FILE_FACTORY`
Les niveaux de journalisation autres que `DEFAULT` sont rarement nécessaires pour ces composants lors du dépannage. Nous ne recommandons pas de modifier le niveau de journalisation `DEFAULT` pour ces composants, sauf demande spécifique du AWS Support.
Après avoir spécifié l'une des actions précédentes, vous pouvez spécifier la quantité d'informations consignées, comme indiqué dans la liste suivante.
Les niveaux de gravité sont dans l'ordre du plus bas au plus haut niveau d'information. Les niveaux supérieurs englobent toujours les informations des niveaux inférieurs.
+ LOGGER\$1SEVERITY\$1ERROR : les messages d’erreur sont écrits dans le journal.
+ LOGGER\$1SEVERITY\$1WARNING : les avertissements et les messages d’erreur sont écrits dans le journal.
+ LOGGER\$1SEVERITY\$1INFO : les messages d’information, les avertissements et les messages d’erreur sont écrits dans le journal.
+ LOGGER\$1SEVERITY\$1DEFAULT : les messages d’information, les avertissements et les messages d’erreur sont écrits dans le journal.
+ LOGGER\$1SEVERITY\$1DEBUG : les messages de débogage, les messages d'information, les avertissements et les messages d'erreur sont écrits dans le journal.
+ LOGGER\$1SEVERITY\$1DETAILED\$1DEBUG : toutes les informations sont écrites dans le journal.
L'exemple JSON suivant montre les paramètres de tâche pour consigner toutes les actions et tous les niveaux de gravité.
```
…
"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
},
…
```
# Paramètres de tâche de la table de contrôle
Les tables de contrôle fournissent des informations sur une AWS DMS tâche. Elles fournissent également des statistiques utiles que vous pouvez utiliser pour planifier et gérer à la fois la tâche de migration actuelle et les tâches futures. Vous pouvez appliquer ces paramètres de tâche dans un fichier JSON ou en choisissant **Paramètres avancés** sur la page **Créer une tâche** de la AWS DMS console. La table Application des exceptions (`dmslogs.awsdms_apply_exceptions`) est toujours créée sur les cibles de base de données. 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).
AWS DMS crée des tables de contrôle uniquement pendant les tâches Full Load \$1 CDC ou CDC uniquement, et non pendant les tâches Full Load Only.
Pour les tâches de chargement complet \$1 CDC (Migrer les données existantes et répliquer les modifications continues) et les tâches de CDC uniquement (Répliquer les modifications de données uniquement), vous pouvez également créer des tables supplémentaires, notamment les suivantes :
+ **Statut de réplication (dmslogs.awsdms\$1status)** : cette table fournit des détails sur la tâche en cours. Il s'agit notamment de son statut, de la quantité de mémoire utilisée par la tâche et du nombre de modifications pas encore appliquées à la cible. Ce tableau indique également la position dans la base de données source où la lecture AWS DMS est en cours. Elle indique également si la tâche est en phase de chargement complet ou de capture des données de modification (CDC).
+ **Tables suspendues (dmslogs.awsdms\$1suspended\$1tables)** : cette table fournit une liste des tables suspendues, ainsi que la raison pour laquelle elles ont été suspendues.
+ **Historique de réplication (dmslogs.awsdms\$1history)** : cette table fournit des informations sur l’historique de réplication. Ces informations sont le nombre et le volume d'enregistrements traités pendant la tâche, la latence à la fin d'une tâche de CDC et d'autres statistiques.
La table Application des exceptions (`dmslogs.awsdms_apply_exceptions`) contient les paramètres suivants :
| Colonne | Type | Description |
| --- | --- | --- |
| TASK\$1NAME | nvchar | ID de ressource de la AWS DMS tâche. L’ID de ressource se trouve dans l’ARN de la tâche. |
| TABLE\$1OWNER | nvchar | Propriétaire de la table. |
| TABLE\$1NAME | nvchar | Nom de la table. |
| ERROR\$1TIME | timestamp | Heure à laquelle l'exception (erreur) s'est produite. |
| STATEMENT | nvchar | Déclaration en cours d'exécution lorsque l'erreur s'est produite. |
| ERROR | nvchar | Nom et description de l'erreur. |
La table Statut de réplication (`dmslogs.awsdms_status`) contient le statut actuel de la tâche et de la base de données cible. Ses paramètres sont les suivants :
| Colonne | Type | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | Nom de la machine sur laquelle s'exécute la tâche de réplication. |
| TASK\$1NAME | nvchar | ID de ressource de la AWS DMS tâche. L’ID de ressource se trouve dans l’ARN de la tâche. |
| TASK\$1STATUS | varchar | L'une des valeurs suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) Le statut de la tâche est défini sur FULL LOAD tant qu'au moins une table est en chargement complet. Une fois que toutes les tables ont été chargées, le statut de la tâche devient CHANGE PROCESSING si CDC est activé. La tâche est définie sur NON EXÉCUTABLE avant que vous ne démarriez la tâche ou une fois celle-ci terminée. |
| STATUS\$1TIME | timestamp | Horodatage du statut de la tâche. |
| PENDING\$1CHANGES | int | Nombre d’enregistrements de modification qui ont été validés dans la base de données source et mis en cache dans la mémoire et le disque de votre instance de réplication. |
| DISK\$1SWAP\$1SIZE | int | Quantité d'espace disque utilisé par des transactions anciennes ou déchargées. |
| TASK\$1MEMORY | int | Mémoire actuelle utilisée, en Mo. |
| SOURCE\$1CURRENT \$1POSITION | varchar | Position dans la base de données source à partir de laquelle la lecture AWS DMS est en cours. |
| SOURCE\$1CURRENT \$1TIMESTAMP | timestamp | L'horodatage de la base de données source en AWS DMS cours de lecture. |
| SOURCE\$1TAIL \$1POSITION | varchar | Position de la transaction de départ la plus ancienne non validée. Cette valeur est la position la plus récente à laquelle vous pouvez revenir sans perdre de modification. |
| SOURCE\$1TAIL \$1TIMESTAMP | timestamp | Horodatage de la transaction de départ la plus ancienne non validée. Cette valeur est l'horodatage le plus récent auquel vous pouvez revenir sans perdre de modification. |
| SOURCE\$1TIMESTAMP \$1APPLIED | timestamp | Horodatage de la dernière validation de transaction. Dans un processus d'application en bloc, cette valeur est l'horodatage de la validation de la dernière transaction du lot. |
La table suspendue (`dmslogs.awsdms_suspended_tables`) contient les paramètres suivants.
| Colonne | Type | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | Nom de la machine sur laquelle s'exécute la tâche de réplication. |
| TASK\$1NAME | nvchar | Le nom de la AWS DMS tâche |
| TABLE\$1OWNER | nvchar | Propriétaire de la table. |
| TABLE\$1NAME | nvchar | Nom de la table. |
| SUSPEND\$1REASON | nvchar | Motif de la suspension. |
| SUSPEND\$1TIMESTAMP | timestamp | Heure à laquelle la suspension a eu lieu. |
La table Historique de réplication (`dmslogs.awsdms_history`) contient les paramètres suivants :
| Colonne | Type | Description |
| --- | --- | --- |
| SERVER\$1NAME | nvchar | Nom de la machine sur laquelle s'exécute la tâche de réplication. |
| TASK\$1NAME | nvchar | ID de ressource de la AWS DMS tâche. L’ID de ressource se trouve dans l’ARN de la tâche. |
| TIMESLOT\$1TYPE | varchar | L'une des valeurs suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) Si la tâche exécute à la fois les processus de chargement complet et de capture de données modifiées, deux enregistrements d'historique sont consignés dans l'intervalle. |
| TIMESLOT | timestamp | Horodatage de fin de l'intervalle. |
| TIMESLOT\$1DURATION | int | Durée de l'intervalle, en minutes. |
| TIMESLOT\$1LATENCY | int | Latence cible à la fin de l'intervalle, en secondes. Cette valeur s'applique uniquement aux créneaux horaires CDC. |
| RECORDS | int | Nombre d'enregistrements traités pendant l'intervalle. |
| TIMESLOT\$1VOLUME | int | Volume de données traitées, en Mo. |
La table Échec de validation (`awsdms_validation_failures_v1`) contient tous les échecs de validation des données pour une tâche. Pour plus d’informations, consultez [Résolution des problèmes liés à la validation des données](CHAP_Validating.md#CHAP_Validating.Troubleshooting).
Les paramètres de table de contrôle supplémentaires sont les suivants :
+ `HistoryTimeslotInMinutes` : utilisez cette option pour indiquer la longueur de chaque intervalle dans la table Historique de réplication. La valeur par défaut est de 5 minutes.
+ `ControlSchema`— Utilisez cette option pour indiquer le nom du schéma de base de données pour les tables de contrôle de la AWS DMS cible. Si vous ne saisissez aucune information pour cette option, les tables sont copiées à l'emplacement par défaut de la base de données comme suit :
+ PostgreSQL, Public
+ Oracle, schéma cible
+ Microsoft SQL Server, dbo dans la base de données cible
+ MySQL, awsdms\$1control
+ MariaDB, awsdms\$1control
+ Amazon Redshift, Public
+ DynamoDB, créé en tant que tables individuelles dans la base de données
+ IBM Db2 LUW, awsdms\$1control
# Paramètres de tâche de mémoire tampon de flux
Vous pouvez définir les paramètres de la mémoire tampon du flux à l'aide de AWS CLI, notamment les éléments 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).
+ `StreamBufferCount` : utilisez cette option pour spécifier le nombre de mémoires tampons de flux de données pour la tâche de migration. Le nombre de mémoires tampon de flux par défaut est 3. L'augmentation de la valeur de ce paramètre pourrait accélérer le processus d'extraction de données. Cependant, cette augmentation des performances dépend fortement de l'environnement de migration, notamment du système source et de la classe d'instance du serveur de réplication. La valeur par défaut est suffisante pour la plupart des cas.
+ `StreamBufferSizeInMB` : utilisez cette option pour indiquer la taille maximale de chaque mémoire tampon de flux de données. La taille par défaut est de 8 Mo. Il se peut que vous deviez augmenter la valeur de cette option lorsque vous travaillez avec des fichiers très volumineux LOBs. Vous devrez peut-être aussi augmenter la valeur si vous recevez un message dans les fichiers-journaux indiquant que la taille de la mémoire tampon de flux est insuffisante. Afin de déterminer la taille de cette option, vous pouvez utiliser l'équation suivante : ` [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` : utilisez cette option pour définir la taille de la mémoire tampon du flux de contrôle. La valeur est exprimée en mégaoctets et peut être comprise entre 1 et 8. La valeur par défaut est 5. Vous devrez peut-être l'augmenter lorsque vous utiliserez un très grand nombre de tables, par exemple des dizaines de milliers de tables.
# Paramètres de réglage du traitement des modifications
Les paramètres suivants déterminent le mode de AWS DMS gestion des modifications apportées aux tables cibles lors de la capture des données de modification (CDC). Plusieurs de ces paramètres dépendent de la valeur du paramètre de métadonnées cibles `BatchApplyEnabled`. Pour plus d'informations sur le paramètre `BatchApplyEnabled`, consultez [Paramètres de métadonnées des tâches cibles](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md). 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).
Les paramètres de réglage du traitement des modifications sont les suivants :
Les paramètres ci-dessous s'appliquent uniquement lorsque le paramètre de métadonnées cibles `BatchApplyEnabled` est défini sur `true`.
+ `BatchApplyPreserveTransaction` : si cette option est définie 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. La valeur par défaut est `true`. Ce paramètre s'applique uniquement aux points de terminaison cible Oracle.
Si elle est définie sur `false`, il peut exister des écarts temporaires dans l'intégrité transactionnelle afin d'améliorer les performances. Il n'existe aucune garantie que toutes les modifications effectuées dans une transaction à partir de la source soient appliquées à la cible en un seul lot.
Par défaut, AWS DMS les processus changent en mode transactionnel, ce qui préserve l'intégrité des transactions. Si vous pouvez vous permettre des écarts temporaires dans l'intégrité transactionnelle, vous pouvez utiliser l'option d'application par lots optimisée à la place. Cette option regroupe efficacement les transactions et les applique par lots pour plus d'efficacité. L’utilisation de l’option d’application optimisée par lots enfreint presque toujours les contraintes d’intégrité référentielle. Nous vous recommandons donc de désactiver ces contraintes pendant le processus de migration et de les réactiver dans le cadre du processus de basculement.
+ `BatchApplyTimeoutMin`— Définit le temps d' AWS DMS attente minimal en secondes entre chaque application de modifications par lots. La valeur par défaut est 1.
+ `BatchApplyTimeoutMax`— Définit la durée maximale en secondes qui s' AWS DMS écoule entre chaque application de modifications par lots avant l'expiration du délai. La valeur par défaut est 30.
+ `BatchApplyMemoryLimit` : définit la quantité de mémoire maximale (en Mo) à utiliser pour le prétraitement en **mode d’application par lots optimisée**. La valeur par défaut est 500.
+ `BatchSplitSize` : définit le nombre maximal de modifications appliquées dans un même lot. La valeur par défaut est 0, ce qui signifie qu'aucune limite n'est appliquée.
Les paramètres ci-dessous s'appliquent uniquement lorsque le paramètre de métadonnées cibles `BatchApplyEnabled` est défini sur `false`.
+ `MinTransactionSize` : définit le nombre minimal de modifications à inclure dans chaque transaction. La valeur par défaut est 1 000.
+ `CommitTimeout`— Définit le délai maximum en secondes AWS DMS pour collecter les transactions par lots avant de déclarer un délai d'expiration. La valeur par défaut est 1.
Pour la réplication bidirectionnelle, le paramètre suivant s’applique uniquement lorsque le paramètre de métadonnées cibles `BatchApplyEnabled` est défini sur `false`.
+ `LoopbackPreventionSettings` : ces paramètres permettent d’empêcher les boucles pour chaque tâche de réplication en cours dans n’importe quelle paire de tâches impliquées dans la réplication bidirectionnelle. La *Prévention de boucles* empêche l'application de modifications identiques dans les deux sens de la réplication bidirectionnelle, ce qui peut corrompre les données. Pour plus d’informations sur la réplication bidirectionnelle, consultez [Effectuer une réplication bidirectionnelle](CHAP_Task.CDC.md#CHAP_Task.CDC.Bidirectional).
AWS DMS tente de conserver les données de transaction en mémoire jusqu'à ce que la transaction soit entièrement validée dans la source, la cible ou les deux. Toutefois, les transactions dont la taille dépasse la mémoire allouée ou qui ne sont pas validées dans le délai imparti sont écrites sur le disque.
Les paramètres suivants s'appliquent au réglage du traitement des modifications quel que soit ce mode de traitement.
+ `MemoryLimitTotal` : définit la taille maximale (en Mo) que la totalité des transactions peut occuper en mémoire avant leur écriture sur le disque. La valeur par défaut est 1024.
+ `MemoryKeepTime` : définit la durée maximale, en secondes, pendant laquelle chaque transaction peut rester en mémoire avant son écriture sur le disque. La durée est calculée à partir du moment où la capture de la transaction AWS DMS a commencé. La valeur par défaut est 60.
+ `StatementCacheSize` : définit le nombre maximal d’instructions préparées à stocker sur le serveur en vue d’une exécution ultérieure lors de l’application des modifications à la cible. La valeur par défaut est 50 et la valeur maximale est 200.
+ `RecoveryTimeout`— Lorsque vous reprenez une tâche en mode CDC, RecoveryTimeout contrôle le temps (en minutes) pendant lequel la tâche attendra avant d'atteindre le point de contrôle de reprise. Si le point de contrôle n'est pas atteint dans le délai défini, la tâche échouera. Le comportement par défaut consiste à attendre indéfiniment l'événement du point de contrôle.
Exemple de la façon dont les paramètres de tâche qui gèrent le réglage du traitement des modifications apparaissent dans un fichier JSON de paramètres de tâche :
```
"ChangeProcessingTuning": {
"BatchApplyPreserveTransaction": true,
"BatchApplyTimeoutMin": 1,
"BatchApplyTimeoutMax": 30,
"BatchApplyMemoryLimit": 500,
"BatchSplitSize": 0,
"MinTransactionSize": 1000,
"CommitTimeout": 1,
"MemoryLimitTotal": 1024,
"MemoryKeepTime": 60,
"StatementCacheSize": 50
"RecoveryTimeout": -1
}
```
Pour contrôler la fréquence des écritures sur une cible Amazon S3 lors d’une tâche de réplication de données, vous pouvez configurer les attributs de connexion supplémentaires `cdcMaxBatchInterval` et `cdcMinFileSize`. Cela peut améliorer les performances lors de l’analyse des données sans aucune surcharge supplémentaire. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation d'Amazon S3 comme cible pour AWS DMS](CHAP_Target.S3.md#CHAP_Target.S3.Configuring).
# Paramètres de la tâche de validation des données
Vous pouvez vérifier que vos données ont été migrées avec précision de la source vers la cible. Si vous activez la validation d'une tâche, AWS DMS commence à comparer les données source et cible immédiatement après le chargement complet d'une table. Pour plus d'informations sur la validation des données d'une tâche, ses exigences, la portée de la prise en charge de sa base de données et les métriques qu'elle fournit, consultez [AWS Validation des données DMS](CHAP_Validating.md). 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).
Les paramètres de validation des données et leurs valeurs incluent les éléments suivants :
+ `EnableValidation` : active la validation des données lorsque la valeur est true. Dans le cas contraire, la validation est désactivée pour la tâche. La valeur par défaut est false.
+ `ValidationMode`— contrôle la manière dont AWS DMS les données de la table cible sont validées par rapport à la table source. À partir de la version 3.5.4 du moteur de réplication, DMS définit automatiquement cette valeur `GROUP_LEVEL` pour les chemins de migration pris en charge, offrant ainsi des performances de validation améliorées et un traitement nettement plus rapide pour les ensembles de données volumineux. Cette amélioration s'applique aux migrations pour les chemins de migration répertoriés dans la [AWS DMS resynchronisation des données](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.DataResync.html#CHAP_DataResync.limitations). Pour tous les autres chemins de migration, le mode de validation est défini par défaut sur`ROW_LEVEL`.
**Note**
Quel que soit le paramètre, AWS DMS valide toutes les lignes configurées via la validation de table.
+ `FailureMaxCount` : spécifie le nombre maximal d’enregistrements dont la validation peut échouer avant que celle-ci soit suspendue pour la tâche. La valeur par défaut est 10,000. Si vous souhaitez que la validation se poursuive quel que soit le nombre d'enregistrements pour lesquels elle échoue, choisissez une valeur plus élevée que le nombre d'enregistrements dans la source.
+ `HandleCollationDiff`— Lorsque cette option est définie sur`true`, la validation prend en compte les différences de classement des colonnes entre les bases de données source et cible. Sinon, les différences de classement des colonnes sont ignorées pour la validation. Les classements de colonnes peuvent imposer l’ordre des lignes, ce qui est important pour la validation des données. Définir `HandleCollationDiff` sur true permet de résoudre automatiquement ces différences de classement et évite les faux positifs dans la validation des données. La valeur par défaut est `false`.
+ `RecordFailureDelayInMinutes` : spécifie le délai en minutes avant que les détails d’un échec de validation ne soient fournis.
Si la latence CDC globale de la tâche DMS est supérieure à la valeur de `RecordFailureDelayInMinutesthen` celle-ci prend la priorité, par exemple, si elle `RecordFailureDelayInMinutes` est de 5, et si la latence CDC est de 7 minutes, le DMS attend 7 minutes pour signaler les détails de l'échec de validation.
+ `RecordFailureDelayLimitInMinutes`— Spécifie le délai avant de signaler les détails d'un échec de validation. AWS DMS utilise la latence des tâches pour reconnaître le délai réel avant que les modifications soient apportées à la cible afin d'éviter les faux positifs. Ce paramètre remplace le délai réel et la valeur de latence CDC de la tâche DMS et vous permet de définir un délai plus long avant de signaler des métriques de validation. La valeur par défaut est 0.
+ `RecordSuspendDelayInMinutes` : spécifie le délai en minutes avant que la validation des tables ne soit suspendue en raison du seuil d’erreur défini dans `FailureMaxCount`.
+ `SkipLobColumns`— Lorsque cette option est définie sur`true`, AWS DMS ignore la validation des données pour toutes les colonnes LOB de la partie de la table consacrée à la validation des tâches. La valeur par défaut est `false`.
+ `TableFailureMaxCount` : spécifie le nombre maximal de lignes dans une table dont la validation peut échouer avant que la validation soit suspendue pour la table. La valeur par défaut est 1,000.
+ `ThreadCount`— Spécifie le nombre de threads d'exécution AWS DMS utilisés lors de la validation. Chaque thread sélectionne les not-yet-validated données de la source et de la cible pour les comparer et les valider. La valeur par défaut est 5. Si vous définissez `ThreadCount` un nombre plus élevé, vous AWS DMS pouvez terminer la validation plus rapidement. Toutefois, AWS DMS exécute ensuite plusieurs requêtes simultanées, consommant plus de ressources sur la source et la cible.
+ `ValidationOnly` : lorsque cette option est définie sur `true`, la tâche effectue la validation des données sans aucune migration ou réplication des données. La valeur par défaut est `false`. Vous ne pouvez pas modifier le paramètre `ValidationOnly` une fois la tâche créée.
Vous devez **TargetTablePrepMode**définir sur `DO_NOTHING` (valeur par défaut pour une tâche de validation uniquement) et définir le **type de migration** sur l'une des valeurs suivantes :
+ Chargement complet : définissez le **type de migration** des tâches pour **migrer les données existantes** dans la AWS DMS console. Ou, dans l' AWS DMS API, définissez le type de migration sur FULL-LOAD.
+ CDC : définissez le **Type de migration** de la tâche sur **Répliquer les modifications de données uniquement** dans la console AWS DMS . Ou, dans l' AWS DMS API, définissez le type de migration sur CDC.
Quel que soit le type de migration choisi, les données ne sont pas réellement migrées ou répliquées lors d’une tâche de validation uniquement.
Pour de plus amples informations, veuillez consulter [Tâches de validation uniquement](CHAP_Validating.md#CHAP_Validating.ValidationOnly).
**Important**
Le paramètre `ValidationOnly` est immuable. Il ne peut pas être modifié pour une tâche une fois celle-ci créée.
+ `ValidationPartialLobSize` : indique si vous souhaitez effectuer une validation partielle pour les colonnes LOB au lieu de valider toutes les données stockées dans la colonne. Cela peut vous être utile lorsque vous ne migrez qu’une partie des données LOB et non l’ensemble du jeu de données LOB. La valeur est exprimée en Ko. La valeur par défaut est 0, ce qui signifie qu’ AWS DMS valide toutes les données de colonne LOB. Par exemple, `"ValidationPartialLobSize": 32` cela AWS DMS ne valide que les 32 premiers Ko des données de colonne à la fois dans la source et dans la cible.
+ `PartitionSize` : spécifie la taille du lot d’enregistrements à lire à des fins de comparaison entre la source et la cible. La valeur par défaut est 10 000.
+ `ValidationQueryCdcDelaySeconds` : durée pendant laquelle la première requête de validation est retardée à la fois sur la source et sur la cible pour chaque mise à jour de CDC. Cela peut contribuer à réduire la contention des ressources lorsque la latence de migration est élevée. Une tâche de validation uniquement définit automatiquement cette option sur 180 secondes. La valeur par défaut est 0.
Par exemple, le code JSON suivant active la validation des données avec deux fois le nombre de threads par défaut. Elle tient également compte des différences d'ordre d'enregistrement générées par les différences de classement des colonnes dans les points de terminaison PostgreSQL. De plus, elle fournit un délai de rapport de validation pour tenir compte du temps supplémentaire nécessaire pour traiter les défaillances de validation.
```
"ValidationSettings": {
"EnableValidation": true,
"ThreadCount": 10,
"HandleCollationDiff": true,
"RecordFailureDelayLimitInMinutes": 30
}
```
**Note**
Pour un point de terminaison Oracle, AWS DMS utilise DBMS\$1CRYPTO pour valider. BLOBs Si votre point de terminaison Oracle l'utilise BLOBs, accordez l'`execute`autorisation pour DBMS\$1CRYPTO au compte utilisateur qui accède au point de terminaison Oracle. Pour ce faire, exécutez l’instruction suivante.
```
grant execute on sys.dbms_crypto to dms_endpoint_user;
```
# Paramètres de resynchronisation des données
La fonction de resynchronisation des données vous permet de resynchroniser la base de données cible avec votre base de données source en fonction du rapport de validation des données. Pour plus d'informations, consultez la section [Validation AWS DMS des données](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html).
Vous pouvez ajouter des paramètres supplémentaires `ResyncSettings` dans le `ReplicationTaskSettings` point de terminaison qui configure le processus de resynchronisation. Pour plus d'informations, consultez l'[exemple de paramètres de tâche](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) dans la section [Spécification des paramètres de tâche pour les AWS Database Migration Service tâches](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html).
**Note**
`ResyncSchedule`et des `MaxResyncTime` paramètres sont requis si le processus de resynchronisation est activé et que la tâche comporte un composant CDC. Ils ne sont pas valides pour les tâches à chargement complet uniquement.
Les paramètres et valeurs des paramètres de resynchronisation des données sont les suivants :
`EnableResync`
Active la fonction de resynchronisation des données lorsqu'elle est définie sur. `true` Par défaut, la resynchronisation des données est désactivée.
**Type de données : booléen**
**Obligatoire** : non
**Par défaut** : `false`
**Validation** : ne doit pas être nulle si `ResyncSettings` le paramètre est présent dans`TaskSettings`.
`ResyncSchedule`
Période pendant laquelle la fonctionnalité de resynchronisation des données doit être effective. Doit être présent au format Cron. Pour de plus amples informations, veuillez consulter [Règles d'expression Cron](CHAP_Validating.DataResync.md#CHAP_DataResync.cron).
**Type de données** : chaîne
**Obligatoire** : non
**Validation** :
+ Doit être présent au format d'expression Cron.
+ La valeur ne doit pas être nulle pour les tâches dont le CDC est `EnableResync` défini sur`true`.
+ Impossible de définir des tâches sans composant CDC.
`MaxResyncTime`
Durée maximale en minutes pour que la fonction de resynchronisation des données soit active.
**Type de données** : entier
**Obligatoire** : non
**Validation** :
+ Ne doit pas être nul pour les tâches avec CDC.
+ Non requis pour les tâches sans CDC.
+ Valeur minimale : `5 minutes` valeur maximale : `14400 minutes` (10 jours).
`Validation onlyTaskID`
ID unique de la tâche de validation. L'ID de tâche de validation uniquement est ajouté à la fin d'un ARN. Par exemple :
+ ARN de la tâche de validation uniquement : `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`
+ ID de tâche de validation uniquement : `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`
**Type de données** : chaîne
**Obligatoire** : non
**Validation** : la valeur ne doit pas être nulle pour les tâches pour lesquelles la fonctionnalité de resynchronisation des données est activée et la validation désactivée.
Exemple :
```
"ResyncSettings": {
"EnableResync": true,
"ResyncSchedule": "30 9 ? * MON-FRI",
"MaxResyncTime": 400,
"ValidationTaskId": "JXPP94804DJOEWIJD9348R3049"
},
```
# Paramètres de tâche pour la gestion du DDL de traitement des modifications
Les paramètres suivants déterminent le mode de gestion AWS DMS des modifications du langage de définition des données (DDL) pour les tables cibles lors de la capture des données de modification (CDC). 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).
Les paramètres de tâche pour gérer la DDL de traitement des modifications sont les suivants :
+ `HandleSourceTableDropped –` Définissez cette option sur `true` pour supprimer la table cible lorsque la table source est supprimée
+ `HandleSourceTableTruncated` : définissez cette option sur `true` pour tronquer la table cible lorsque la table source est tronquée.
+ `HandleSourceTableAltered` : définissez cette option sur `true` pour modifier la table cible lorsque la table source est modifiée.
Voici un exemple de la façon dont les paramètres de tâche qui gèrent DDL de traitement des modifications apparaissent dans un fichier JSON de paramètre de tâche :
```
"ChangeProcessingDdlHandlingPolicy": {
"HandleSourceTableDropped": true,
"HandleSourceTableTruncated": true,
"HandleSourceTableAltered": true
},
```
**Note**
Pour en savoir plus sur les instructions DDL prises en charge pour un point de terminaison spécifique, consultez la rubrique décrivant ce point de terminaison.
# Paramètres de tâche de substitution de caractères
Vous pouvez spécifier que votre tâche de réplication effectue des substitutions de caractères dans la base de données cible pour toutes les colonnes de la base de données source avec le type de `WSTRING` données AWS DMS `STRING` or. 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).
Vous pouvez configurer la substitution de caractères pour toute tâche avec des points de terminaison provenant des bases de données source et cible suivantes :
+ Bases de données source :
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ MariaDB
+ PostgreSQL
+ SAP Adaptive Server Enterprise (ASE)
+ IBM Db2 LUW
+ Bases de données cible :
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ MariaDB
+ PostgreSQL
+ SAP Adaptive Server Enterprise (ASE)
+ Amazon Redshift
Vous pouvez spécifier des substitutions de caractères à l'aide du paramètre `CharacterSetSettings` dans vos paramètres de tâche. Ces substitutions de caractères se produisent pour les caractères spécifiés à l'aide de la valeur du point de code Unicode en notation hexadécimale. Vous pouvez implémenter les substitutions en deux phases, dans l'ordre suivant, si les deux sont spécifiées :
1. **Remplacement de caractères individuel** : AWS DMS permet de remplacer les valeurs des caractères sélectionnés sur la source par des valeurs de remplacement spécifiées des caractères correspondants sur la cible. Utilisez le tableau `CharacterReplacements` dans `CharacterSetSettings` pour sélectionner tous les caractères source ayant les points de code Unicode que vous spécifiez. Utilisez également ce tableau pour spécifier les points de code de remplacement pour les caractères correspondants dans la cible.
Pour sélectionner tous les caractères de la source qui ont un point de code donné, définissez une instance de `SourceCharacterCodePoint` dans le tableau `CharacterReplacements` sur ce point de code. Spécifiez ensuite le point de code de remplacement pour tous les caractères cibles équivalents en définissant l'instance correspondante de `TargetCharacterCodePoint` dans ce tableau. Pour supprimer les caractères cibles au lieu de les remplacer, définissez les instances appropriées de `TargetCharacterCodePoint` sur zéro (0). Vous pouvez remplacer ou supprimer autant de valeurs différentes de caractères cibles que vous le souhaitez en spécifiant des paires supplémentaires de paramètres `TargetCharacterCodePoint` et `SourceCharacterCodePoint` dans le tableau `CharacterReplacements`. Si vous spécifiez la même valeur pour plusieurs instances de `SourceCharacterCodePoint`, la valeur du dernier paramètre correspondant de `TargetCharacterCodePoint` s'applique à la cible.
Par exemple, supposons que vous spécifiiez les valeurs suivantes pour `CharacterReplacements`.
```
"CharacterSetSettings": {
"CharacterReplacements": [ {
"SourceCharacterCodePoint": 62,
"TargetCharacterCodePoint": 61
}, {
"SourceCharacterCodePoint": 42,
"TargetCharacterCodePoint": 41
}
]
}
```
Dans cet exemple, AWS DMS remplace tous les caractères ayant la valeur hexadécimale du point de code source 62 sur la cible par des caractères ayant la valeur du point de code 61. AWS DMS Remplace également tous les caractères dont le point de code source est 42 sur la cible par des caractères dont le point de code source est 41. En d'autres termes, AWS DMS remplace toutes les instances de la lettre `'b'` dans la cible par la lettre `'a'`. De même, AWS DMS remplace toutes les instances de la lettre `'B'` sur la cible par la lettre`'A'`.
1. **Validation et remplacement du jeu de caractères** : une fois le remplacement de chaque caractère effectué, AWS DMS vous pouvez vous assurer que tous les caractères cibles possèdent des points de code Unicode valides dans le jeu de caractères unique que vous spécifiez. Vous utilisez `CharacterSetSupport` dans `CharacterSetSettings` pour configurer cette vérification et cette modification de caractères cibles. Pour spécifier le jeu de caractères de vérification, définissez `CharacterSet` dans `CharacterSetSupport` sur la valeur de chaîne du jeu de caractères lui-même. (Les valeurs possibles pour `CharacterSet` sont indiquées ci-après.) Vous pouvez AWS DMS modifier les caractères cibles non valides de l'une des manières suivantes :
+ Spécifiez un point de code Unicode de remplacement unique pour tous les caractères cibles non valides, quel que soit leur point de code actuel. Pour configurer ce point de code de remplacement, définissez `ReplaceWithCharacterCodePoint` dans `CharacterSetSupport` sur la valeur spécifiée.
+ Configurez la suppression de tous les caractères cibles non valides en définissant `ReplaceWithCharacterCodePoint` sur zéro (0).
Par exemple, supposons que vous spécifiiez les valeurs suivantes pour `CharacterSetSupport`.
```
"CharacterSetSettings": {
"CharacterSetSupport": {
"CharacterSet": "UTF16_PlatformEndian",
"ReplaceWithCharacterCodePoint": 0
}
}
```
Dans cet exemple, AWS DMS supprime tous les caractères trouvés sur la cible qui ne sont pas valides dans le jeu de `"UTF16_PlatformEndian"` caractères. Par conséquent, tous les caractères spécifiés avec la valeur hexadécimale `2FB6` sont supprimés. Cette valeur n'est pas valide car il s'agit d'un point de code Unicode à 4 octets et UTF16 les jeux de caractères n'acceptent que les caractères comportant des points de code à 2 octets.
**Note**
La tâche de réplication effectue toutes les substitutions de caractères spécifiées avant de commencer les transformations globales ou au niveau de la table que vous avez spécifiées via le mappage de table. Pour plus d'informations sur le mappage de table, consultez la page [Utilisation du mappage de table pour spécifier des paramètres de tâche](CHAP_Tasks.CustomizingTasks.TableMapping.md).
La substitution de caractères ne prend pas en charge les types de données LOB. Cela s’applique à tous les types de données que DMS considère comme un type de données LOB. Par exemple, le type de données `Extended` dans Oracle est considéré comme des données LOB. Pour plus d’informations sur les types de données source, consultez [Types de données sources pour Oracle](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes) ci-après.
Les valeurs prises AWS DMS en charge par `CharacterSet` apparaissent dans le tableau suivant.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html)
# Paramètres de tâche de l’image antérieure
Lorsque vous écrivez des mises à jour de CDC sur une cible de diffusion de données comme Kinesis ou Apache Kafka, vous pouvez afficher les valeurs d’origine d’une ligne de base de données source avant de les modifier par une mise à jour. Pour ce faire, AWS DMS remplit une *image antérieure* des événements de mise à jour en fonction des données fournies par le moteur de base de données source. 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).
Pour ce faire, utilisez le paramètre `BeforeImageSettings` qui ajoute un nouvel attribut JSON à chaque opération de mise à jour avec des valeurs collectées dans le système de base de données source.
Assurez-vous d’appliquer `BeforeImageSettings` uniquement aux tâches de chargement complet \$1 CDC ou aux tâches de CDC uniquement. Les tâches de chargement complet \$1 CDC migrent les données existantes et répliquent les modifications continues. Les tâches de CDC uniquement répliquent les modifications de données uniquement.
N’appliquez pas les `BeforeImageSettings` aux tâches à pleine charge uniquement.
Les options admises pour `BeforeImageSettings` sont les suivantes :
+ `EnableBeforeImage` : lorsque cette option est définie sur `true`, active la génération d’image antérieure. La valeur par défaut est `false`.
+ `FieldName` : affecte un nom au nouvel attribut JSON. Quand `EnableBeforeImage` est `true`, `FieldName` est obligatoire et ne peut pas être vide.
+ `ColumnFilter` : spécifie une colonne à ajouter en utilisant la génération d’image antérieure. Pour ajouter uniquement des colonnes faisant partie des clés primaires de la table, utilisez la valeur par défaut, `pk-only`. Pour ajouter une colonne ayant une valeur d'image antérieure, utilisez `all`. Notez que l’image antérieure ne prend pas en charge les types de données LOB (objets binaires de grande taille) tels que CLOB et BLOB.
L’exemple suivant illustre l’utilisation de `BeforeImageSettings`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
Pour en savoir plus sur les paramètres d’image antérieure pour Kinesis, y compris sur les paramètres supplémentaires de mappage de table, consultez [Utilisation d’une image antérieure pour afficher les valeurs d’origine des lignes CDC pour un flux de données Kinesis en tant que cible](CHAP_Target.Kinesis.md#CHAP_Target.Kinesis.BeforeImage).
Pour plus d'informations sur les paramètres d'image antérieure pour Kafka, y compris les paramètres supplémentaires de mappage de table, consultez [Utilisation d'une image antérieure pour afficher les valeurs originales des lignes de la CDC pour Apache Kafka comme cible](CHAP_Target.Kafka.md#CHAP_Target.Kafka.BeforeImage).
# Paramètres de traitement des erreurs pour une tâche
Vous pouvez définir le comportement de gestion des erreurs de votre tâche de réplication en utilisant les paramètres 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).
+ `DataErrorPolicy`— Détermine l'action AWS entreprise par DMS en cas d'erreur liée au traitement des données au niveau de l'enregistrement. Certains exemples d'erreurs liées au traitement de données comprennent les erreurs de conversion, les erreurs dans la transformation et les données incorrectes. La valeur par défaut est `LOG_ERROR`.
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées. Le compteur d'erreurs pour la propriété `DataErrorEscalationCount` est incrémenté. Par conséquent, si vous définissez une limite pour les erreurs pour une table, cette erreur est prise en compte dans cette limite.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `DataTruncationErrorPolicy` : détermine l’action exécutée par AWS DMS lorsque les données sont tronquées. La valeur par défaut est `LOG_ERROR`.
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées. Le compteur d'erreurs pour la propriété `DataErrorEscalationCount` est incrémenté. Par conséquent, si vous définissez une limite pour les erreurs pour une table, cette erreur est prise en compte dans cette limite.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `DataErrorEscalationPolicy` : détermine l’action exécutée par AWS DMS lorsque le nombre maximal d’erreurs (défini dans le paramètre `DataErrorEscalationCount`) est atteint. La valeur par défaut est `SUSPEND_TABLE`.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `DataErrorEscalationCount` : définit le nombre maximal d’erreurs qui peuvent avoir lieu sur les données pour un enregistrement spécifique. Lorsque ce nombre est atteint, les données de la table qui contient l'enregistrement d'erreur sont traitées conformément à la stratégie définie dans `DataErrorEscalationPolicy`. La valeur par défaut est 0.
+ `EventErrorPolicy`— Détermine l'action entreprise par AWS DMS lorsqu'une erreur se produit lors de l'envoi d'un événement lié à une tâche. Les valeurs possibles sont les suivantes :
+ `IGNORE` : la tâche continue et toutes les données associées à cet événement sont ignorées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `TableErrorPolicy` : détermine l’action exécutée par AWS DMS lorsqu’une erreur se produit pendant le traitement des données ou des métadonnées d’une table spécifique. Cette erreur s'applique uniquement aux données générales de la table. Il ne s'agit pas d'une erreur liée à un enregistrement spécifique. La valeur par défaut est `SUSPEND_TABLE`.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `TableErrorEscalationPolicy` : détermine l’action exécutée par AWS DMS lorsque le nombre maximal d’erreurs (défini à l’aide du paramètre `TableErrorEscalationCount`) est atteint. Le paramètre par défaut et le seul paramètre utilisateur est `STOP_TASK`, avec lequel la tâche est arrêtée et une intervention manuelle est requise.
+ `TableErrorEscalationCount` : nombre maximal d’erreurs qui peuvent avoir lieu sur les données ou les métadonnées générales pour une table spécifique. Lorsque ce nombre est atteint, les données de la table sont traitées conformément à la stratégie définie dans `TableErrorEscalationPolicy`. La valeur par défaut est 0.
+ `RecoverableErrorCount` : nombre maximal de tentatives effectuées pour redémarrer une tâche lorsqu’une erreur d’environnement se produit. Une fois que le système a tenté de redémarrer la tâche le nombre de fois indiqué, la tâche est arrêtée et une intervention manuelle est requise. La valeur par défaut est -1.
Lorsque vous définissez cette valeur sur -1, le nombre de tentatives effectuées par DMS varie en fonction du type d'erreur renvoyé, comme suit :
+ **État en cours d'exécution, erreur récupérable : si une erreur** réparable, telle qu'une perte de connexion ou un échec de l'application de la cible, se produit, DMS réessaie la tâche neuf fois.
+ **État de départ, erreur récupérable** : DMS réessaie la tâche six fois.
+ **État en cours d'exécution, erreur fatale gérée par DMS** : DMS réessaie la tâche six fois.
+ **État en cours d'exécution, erreur fatale non gérée par DMS** : DMS ne réessaie pas la tâche.
+ **Autre que ci-dessus** : AWS DMS réessaie la tâche indéfiniment.
Définissez cette valeur sur 0 pour ne jamais essayer de redémarrer une tâche.
Nous vous recommandons de définir `RecoverableErrorCount` et sur `RecoverableErrorInterval` des valeurs telles qu'il y ait suffisamment de tentatives à intervalles suffisants pour que votre tâche DMS soit correctement rétablie. En cas d'erreur fatale, DMS arrête de faire des tentatives de redémarrage dans la plupart des scénarios.
+ `RecoverableErrorInterval`— Le nombre de secondes pendant lesquelles le AWS DMS attend entre deux tentatives de redémarrage d'une tâche. La valeur par défaut est 5.
+ `RecoverableErrorThrottling` : lorsque cette option est activée, l’intervalle entre les tentatives de redémarrage d’une tâche est augmenté en série en fonction de la valeur de `RecoverableErrorInterval`. Par exemple, si `RecoverableErrorInterval` est défini sur 5 secondes, la prochaine tentative aura lieu après 10 secondes, puis 20, puis 40 secondes et ainsi de suite. La valeur par défaut est `true`.
+ `RecoverableErrorThrottlingMax`— Le nombre maximal de secondes pendant lesquelles le AWS DMS attend entre deux tentatives de redémarrage d'une tâche s'il `RecoverableErrorThrottling` est activé. La valeur par défaut est 1800.
+ `RecoverableErrorStopRetryAfterThrottlingMax`— La valeur par défaut est définie sur`true`, et DMS arrête de reprendre la tâche une fois que le nombre maximum de secondes d' AWS DMS attente entre les tentatives de restauration est atteint, par. `RecoverableErrorStopRetryAfterThrottlingMax` Lorsqu'il est défini sur`false`, DMS continue de reprendre la tâche une fois que le nombre maximum de secondes d' AWS DMS attente entre les tentatives de restauration est atteint, jusqu'à ce qu'il soit `RecoverableErrorStopRetryAfterThrottlingMax` atteint. `RecoverableErrorCount`
+ `ApplyErrorDeletePolicy` : détermine l’action exécutée par AWS DMS quand un conflit lié à une opération DELETE a lieu. La valeur par défaut est `IGNORE_RECORD`. Les valeurs possibles sont les suivantes :
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées. Le compteur d'erreurs pour la propriété `ApplyErrorEscalationCount` est incrémenté. Par conséquent, si vous définissez une limite pour les erreurs pour une table, cette erreur est prise en compte dans cette limite.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `ApplyErrorInsertPolicy` : détermine l’action exécutée par AWS DMS quand un conflit lié à une opération INSERT a lieu. La valeur par défaut est `LOG_ERROR`. Les valeurs possibles sont les suivantes :
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées. Le compteur d'erreurs pour la propriété `ApplyErrorEscalationCount` est incrémenté. Par conséquent, si vous définissez une limite pour les erreurs pour une table, cette erreur est prise en compte dans cette limite.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `INSERT_RECORD` : s’il existe un enregistrement cible avec la même clé primaire que l’enregistrement source inséré, l’enregistrement cible est mis à jour.
**Note**
**En mode Transactional Apply** : dans ce processus, le système tente d'abord d'insérer l'enregistrement. Si l'insertion échoue en raison d'un conflit de clé primaire, elle supprime l'enregistrement existant, puis insère le nouveau.
**En mode Batch Apply** : le processus supprime tous les enregistrements existants dans le lot cible avant d'insérer l'ensemble complet des nouveaux enregistrements, garantissant ainsi un remplacement correct des données.
Ce processus empêche la duplication des données, mais entraîne un certain coût de performance par rapport à la politique par défaut. L'impact exact sur les performances dépend des caractéristiques spécifiques de votre charge de travail.
+ `ApplyErrorUpdatePolicy` : détermine l’action exécutée par AWS DMS quand un conflit de données manquantes lié à une opération UPDATE a lieu. La valeur par défaut est `LOG_ERROR`. Les valeurs possibles sont les suivantes :
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées. Le compteur d'erreurs pour la propriété `ApplyErrorEscalationCount` est incrémenté. Par conséquent, si vous définissez une limite pour les erreurs pour une table, cette erreur est prise en compte dans cette limite.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `UPDATE_RECORD`— Si l'enregistrement cible est manquant, l'enregistrement cible manquant est inséré dans la table cible. AWS DMS désactive complètement le support des colonnes LOB pour la tâche. La sélection de cette option nécessite qu'une journalisation supplémentaire complète soit activée pour toutes les colonnes de la table source quand Oracle est la base de données source.
**Note**
**En mode Transactional Apply** : dans ce processus, le système tente d'abord de mettre à jour l'enregistrement. Si la mise à jour échoue en raison d'un enregistrement manquant sur la cible, elle exécute une suppression pour l'enregistrement défaillant, puis insère le nouveau. Ce processus nécessite une journalisation supplémentaire complète pour les bases de données source Oracle et DMS désactive le support des colonnes LOB pour cette tâche.
**En mode Batch Apply** : le processus supprime tous les enregistrements existants dans le lot cible avant d'insérer l'ensemble complet des nouveaux enregistrements, garantissant ainsi un remplacement correct des données.
+ `ApplyErrorEscalationPolicy`— Détermine l'action AWS entreprise par DMS lorsque le nombre maximum d'erreurs (défini à l'aide du `ApplyErrorEscalationCount` paramètre) est atteint. La valeur par défaut est LOG\$1ERROR :
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
+ `STOP_TASK` : la tâche s’arrête et une intervention manuelle est requise.
+ `ApplyErrorEscalationCount` : cette option définit le nombre maximal de conflits APPLY qui peuvent se produire pour une table spécifique pendant une opération de traitement des modifications. Lorsque ce nombre est atteint, les données de la table sont traitées conformément à la stratégie définie dans le paramètre `ApplyErrorEscalationPolicy`. La valeur par défaut est 0.
+ `ApplyErrorFailOnTruncationDdl` : définissez cette option sur `true` pour faire échouer la tâche lorsqu’une troncation est effectuée sur l’une des tables suivies pendant la CDC. La valeur par défaut est `false`.
Cette approche ne fonctionne pas avec PostgreSQL version 11.x ou antérieures, ou tout autre point de terminaison source qui ne réplique pas la troncation de table DDL.
+ `FailOnNoTablesCaptured` : définissez cette option sur `true` pour faire échouer une tâche lorsque les mappages de table définis pour une tâche ne trouvent pas de tables au lancement de la tâche. La valeur par défaut est `true`.
+ `FailOnTransactionConsistencyBreached` : cette option s’applique aux tâches qui utilisent Oracle en tant que source avec la CDC. La valeur par défaut est false. Définissez le paramètre sur `true` pour qu'une tâche échoue lorsqu'une transaction est ouverte plus longtemps que le délai d'expiration spécifié et puisse être supprimée.
Lorsqu'une tâche CDC démarre avec Oracle, attendez AWS DMS pendant une durée limitée que la transaction ouverte la plus ancienne soit clôturée avant de démarrer CDC. Si la transaction ouverte la plus ancienne ne se ferme pas avant que le délai ne soit atteint, le CDC AWS DMS démarre dans la plupart des cas, en ignorant cette transaction. Si cette option est définie sur `true`, la tâche échoue.
+ `FullLoadIgnoreConflicts`— Définissez cette option `true` pour AWS DMS ignorer les erreurs « zéro ligne affectée » et « doublons » lors de l'application d'événements mis en cache. Si ce paramètre est défini AWS DMS sur`false`, signale toutes les erreurs au lieu de les ignorer. La valeur par défaut est `true`.
+ `DataMaskingErrorPolicy`— Détermine les mesures à AWS DMS prendre lorsque le masquage des données échoue en raison d'un type de données incompatible ou pour toute autre raison. Les options disponibles sont les suivantes :
+ `STOP_TASK`(Par défaut) — La tâche s'arrête et une intervention manuelle est requise.
+ `IGNORE_RECORD` : la tâche continue et les données de cet enregistrement sont ignorées.
+ `LOG_ERROR` : la tâche continue et l’erreur est écrite dans le journal de la tâche. Les données démasquées seront chargées dans la table cible.
+ `SUSPEND_TABLE` : la tâche continue, mais les données de la table avec l’enregistrement d’erreur basculent à l’état d’erreur et les données ne sont pas répliquées.
**Note**
Les erreurs de chargement des tables dans Redshift en tant que cible sont signalées dans. `STL_LOAD_ERRORS` Pour plus d’informations, consultez [STL\$1LOAD\$1ERRORS](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html) dans le *Guide du développeur de base de données Amazon Redshift*.
**Note**
Les modifications de paramètres liées aux erreurs récupérables ne prennent effet qu'après l'arrêt et la reprise de la tâche DMS. Les modifications ne s'appliquent pas à l'exécution en cours.
# Paramètres de tâche d'enregistrement
Vous pouvez enregistrer les paramètres de tâche en tant que fichier JSON, au cas où vous souhaiteriez réutiliser les paramètres pour une autre tâche. Vous trouverez les paramètres de tâche à copier dans un fichier JSON dans la section **Détails de présentation** d’une tâche.
**Note**
Lorsque vous réutilisez les paramètres de tâche pour d’autres tâches, supprimez tous les attributs `CloudWatchLogGroup` et `CloudWatchLogStream`. Sinon, l'erreur suivante s'affiche : MESSAGE D'ERREUR SYSTÈME : Paramètres des tâches CloudWatchLogGroup ou CloudWatchLogStream impossible à définir lors de la création.
Par exemple, le fichier JSON suivant contient les paramètres enregistrés pour une tâche.
```
{
"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
}
```