

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.

# Sources pour la migration des données
<a name="CHAP_Source"></a>

AWS Database Migration Service (AWS DMS) peut utiliser la plupart des moteurs de données les plus populaires comme source de réplication de données. La source de base de données peut être un moteur autogéré s’exécutant sur une instance Amazon EC2 ou une base de données sur site. Il peut également s'agir d'une source de données sur un AWS service tel qu'Amazon RDS ou Amazon S3.

Pour une liste complète des sources valides, consultez [Sources pour AWS DMS](CHAP_Introduction.Sources.md#CHAP_Introduction.Sources.title).

**Topics**
+ [Utilisation d'une base de données Oracle comme source pour AWS DMS](CHAP_Source.Oracle.md)
+ [Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS](CHAP_Source.SQLServer.md)
+ [Utilisation de la base de données Microsoft Azure SQL comme source pour AWS DMS](CHAP_Source.AzureSQL.md)
+ [Utilisation de l'instance gérée Microsoft Azure SQL comme source pour AWS DMS](CHAP_Source.AzureMgd.md)
+ [Utilisation du serveur flexible Microsoft Azure Database pour PostgreSQL comme source pour AWS DMS](CHAP_Source.AzureDBPostgreSQL.md)
+ [Utilisation du serveur flexible Microsoft Azure Database pour MySQL comme source pour AWS DMS](CHAP_Source.AzureDBMySQL.md)
+ [Utilisation d'OCI MySQL Heatwave comme source pour AWS DMS](CHAP_Source.heatwave.md)
+ [Utilisation de Google Cloud pour MySQL comme source pour AWS DMS](CHAP_Source.GC.md)
+ [Utilisation de Google Cloud pour PostgreSQL comme source pour AWS DMS](CHAP_Source.GCPostgres.md)
+ [Utilisation d'une base de données PostgreSQL comme source AWS DMS](CHAP_Source.PostgreSQL.md)
+ [Utilisation d'une base de données compatible MySQL comme source pour AWS DMS](CHAP_Source.MySQL.md)
+ [Utilisation d'une base de données SAP ASE comme source pour AWS DMS](CHAP_Source.SAP.md)
+ [Utilisation de MongoDB comme source pour AWS DMS](CHAP_Source.MongoDB.md)
+ [Utilisation d'Amazon DocumentDB (compatible avec MongoDB) comme source pour AWS DMS](CHAP_Source.DocumentDB.md)
+ [Utilisation d'Amazon S3 comme source pour AWS DMS](CHAP_Source.S3.md)
+ [Utilisation d'IBM Db2 pour Linux, Unix, Windows et de la base de données Amazon RDS (Db2 LUW) comme source pour AWS DMS](CHAP_Source.DB2.md)
+ [Utilisation d'IBM Db2 pour les z/OS bases de données comme source pour AWS DMS](CHAP_Source.DB2zOS.md)

# Utilisation d'une base de données Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle"></a>

Vous pouvez migrer les données d'une ou de plusieurs bases de données Oracle à l'aide de AWS DMS. Avec une base de données Oracle en tant que source, vous pouvez migrer des données vers l’une des cibles prises en charge par AWS DMS.

AWS DMS prend en charge les éditions de base de données Oracle suivantes :
+ Oracle Enterprise Edition
+ Oracle Standard Edition
+ Édition Oracle Express
+ Édition Oracle Personal

Pour plus d'informations sur les versions des bases de données Oracle AWS DMS prises en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md).

Vous pouvez utiliser SSL (Secure Sockets Layer) pour chiffrer les connexions entre votre point de terminaison Oracle et votre instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison Oracle, consultez [Prise en charge de SSL pour un point de terminaison Oracle](#CHAP_Security.SSL.Oracle).

AWS DMS prend en charge l'utilisation du chiffrement transparent des données (TDE) Oracle pour chiffrer les données au repos dans la base de données source. Pour plus d'informations sur l'utilisation de TDE Oracle avec un point de terminaison source Oracle, consultez [Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Encryption).

AWS prend en charge l'utilisation de TLS version 1.2 et ultérieure avec les points de terminaison Oracle (et tous les autres types de points de terminaison) et recommande d'utiliser TLS version 1.3 ou ultérieure.

Procédez comme suit pour configurer une base de données Oracle en tant que point de terminaison AWS DMS source :

1. Créez un utilisateur Oracle doté des autorisations appropriées pour accéder AWS DMS à votre base de données source Oracle.

1. Créez un point de terminaison source Oracle conforme à la configuration de base de données Oracle que vous avez choisie. Pour créer une full-load-only tâche, aucune autre configuration n'est nécessaire.

1. Pour créer une tâche qui gère la capture des données de modification (une tâche uniquement CDC ou une tâche à chargement complet et une tâche CDC), choisissez Oracle LogMiner ou AWS DMS Binary Reader pour capturer les modifications de données. Le choix LogMiner de Binary Reader détermine certaines des autorisations et options de configuration ultérieures. Pour une comparaison entre Binary Reader LogMiner et Binary Reader, consultez la section suivante.

**Note**  
Pour plus d’informations sur les tâches de chargement complet, les tâches de CDC uniquement et les tâches de chargement complet et de CDC, consultez [Création d’une tâche](CHAP_Tasks.Creating.md)

Pour plus de détails sur l'utilisation des bases de données source Oracle AWS DMS, consultez les sections suivantes. 

**Topics**
+ [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC)
+ [Flux de travail pour configurer une base de données source Oracle AWS autogérée ou gérée pour AWS DMSConfiguration d’une base de données source Oracle](#CHAP_Source.Oracle.Workflows)
+ [Utilisation d'une base de données Oracle autogérée comme source pour AWS DMS](#CHAP_Source.Oracle.Self-Managed)
+ [Utilisation d'une base de données Oracle AWS gérée comme source pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed)
+ [Restrictions relatives à l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Limitations)
+ [Prise en charge de SSL pour un point de terminaison Oracle](#CHAP_Security.SSL.Oracle)
+ [Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Encryption)
+ [Méthodes de compression prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Compression)
+ [Réplication de tables imbriquées à l'aide d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.NestedTables)
+ [Stockage de REDO sur Oracle ASM lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.REDOonASM)
+ [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib)
+ [Types de données sources pour Oracle](#CHAP_Source.Oracle.DataTypes)

## Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC
<a name="CHAP_Source.Oracle.CDC"></a>

Dans AWS DMS, il existe deux méthodes pour lire les journaux de restauration lors de la capture des données de modification (CDC) pour Oracle en tant que source : Oracle LogMiner et AWS DMS Binary Reader. LogMiner est une API Oracle permettant de lire les journaux de journalisation en ligne et les fichiers de journalisation archivés. Le lecteur binaire est une AWS DMS méthode qui lit et analyse directement les fichiers de journalisation bruts. Ces méthodes présentent les fonctionnalités suivantes.


| Fonctionnalité | LogMiner | Binary Reader | 
| --- | --- | --- | 
| Facile à configurer | Oui | Non | 
| Réduction de l'impact sur le système source I/O et le processeur | Non | Oui | 
| Meilleures performances de CDC | Non | Oui | 
| Prend en charge les clusters de tables Oracle | Oui | Non | 
| Prend en charge tous les types de compressions HCC Oracle | Oui |  Partiellement Binary Reader ne prend pas en charge QUERY LOW pour les tâches avec CDC. Tous les autres types de HCC sont entièrement pris en charge.  | 
| Prise en charge des colonnes LOB dans Oracle 12c uniquement | Non (le support LOB n'est pas disponible LogMiner dans Oracle 12c.) | Oui | 
| Prend en charge les instructions UPDATE qui n’affectent que les colonnes LOB | Non | Oui | 
| Prend en charge le chiffrement transparent des données (TDE) Oracle |  Partiellement Lorsque vous utilisez Oracle LogMiner, AWS DMS le chiffrement TDE au niveau des colonnes n'est pas pris en charge pour Amazon RDS for Oracle.  |  Partiellement Binary Reader prend en charge le chiffrement TDE uniquement pour les bases de données Oracle autogérées.  | 
| Prend en charge toutes les méthodes de compression Oracle | Oui | Non | 
| Prend en charge les transactions XA | Non | Oui | 
| RAC |  Oui Non recommandé pour des raisons de performances et pour certaines limitations internes du DMS.  |  Oui Fortement recommandé  | 

**Note**  
Par défaut, AWS DMS utilise Oracle LogMiner pour (CDC).   
AWS DMS prend en charge les méthodes de chiffrement transparent des données (TDE) lorsque vous travaillez avec une base de données source Oracle. Si les informations d'identification TDE que vous spécifiez sont incorrectes, la tâche de AWS DMS migration n'échoue pas, ce qui peut avoir un impact sur la réplication continue des tables chiffrées. Pour plus d’informations sur la spécification des informations d’identification TDE, consultez [Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Encryption).

Les principaux avantages de l'utilisation de LogMiner with AWS DMS sont les suivants :
+ LogMiner prend en charge la plupart des options Oracle, telles que les options de chiffrement et de compression. Binary Reader ne prend pas en charge toutes les options Oracle, en particulier la compression et la plupart des options de chiffrement.
+ LogMiner offre une configuration plus simple, en particulier par rapport à la configuration à accès direct à Binary Reader ou lorsque les journaux de rétablissement sont gérés à l'aide d'Oracle Automatic Storage Management (ASM).
+ LogMiner prend en charge les clusters de tables destinés à être utilisés par AWS DMS. Binary Reader ne le fait pas.

Les principaux avantages de l'utilisation de Binary Reader AWS DMS sont les suivants :
+ Pour les migrations comportant un volume élevé de modifications, LogMiner cela peut avoir un impact sur le I/O processeur de l'ordinateur hébergeant la base de données source Oracle. Binary Reader a moins de chances d'avoir un impact sur le I/O processeur, car les journaux sont extraits directement au lieu d'effectuer plusieurs requêtes de base de données.
+ Pour les migrations impliquant un volume élevé de modifications, les performances du CDC sont généralement bien meilleures lorsque vous utilisez Binary Reader par rapport à Oracle LogMiner.
+ Binary Reader prend en charge le CDC pour LOBs Oracle version 12c. LogMiner ne le fait pas.

En général, utilisez Oracle LogMiner pour migrer votre base de données Oracle, sauf si vous vous trouvez dans l'une des situations suivantes :
+ Vous avez besoin d'exécuter plusieurs tâches de migration sur la base de données source Oracle.
+ Le volume de modifications ou le volume de journaux redo sur la base de données Oracle source est élevé, ou vous avez des modifications et vous utilisez également Oracle ASM.

**Note**  
Si vous passez d'Oracle LogMiner à AWS DMS Binary Reader, assurez-vous de redémarrer la tâche CDC. 

### Configuration de CDC sur une base de données source Oracle
<a name="CHAP_Source.Oracle.CDC.Configuration"></a>

Pour qu’un point de terminaison source Oracle puisse se connecter à la base de données pour une tâche de capture des données de modification (CDC), vous devrez peut-être spécifier des attributs de connexion supplémentaires. Vous devrez peut-être le faire pour une tâche de chargement complet et de CDC ou pour une tâche de CDC uniquement. Les attributs de connexion supplémentaires que vous spécifiez dépendent de la méthode que vous utilisez pour accéder aux journaux de journalisation : Oracle LogMiner ou AWS DMS Binary Reader. 

Vous spécifiez des attributs de connexion supplémentaires lorsque vous créez un point de terminaison source. Si vous avez plusieurs paramètres d'attribut de connexion, séparez-les les uns des autres par des points-virgules, sans espace supplémentaire (par exemple, `oneSetting;thenAnother`).

AWS DMS utilise LogMiner par défaut. Vous n’avez pas à spécifier d’attributs de connexion supplémentaires pour l’utiliser. 

Pour utiliser Binary Reader afin d’accéder aux journaux redo, ajoutez les attributs de connexion supplémentaires suivants.

```
useLogMinerReader=N;useBfile=Y;
```

Utilisez le format suivant pour les attributs de connexion supplémentaires afin d'accéder à un serveur qui utilise ASM avec Binary Reader.

```
useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
```

Définissez le paramètre de demande `Password` du point de terminaison source sur le mot de passe d'utilisateur Oracle et le mot de passe ASM, séparés par une virgule comme suit.

```
oracle_user_password,asm_user_password
```

Dans les versions où la source Oracle utilise ASM, vous pouvez utiliser des options hautes performances dans Binary Reader pour le traitement des transactions à grande échelle. Ces options incluent des attributs de connexion supplémentaires pour spécifier le nombre de threads parallèles (`parallelASMReadThreads`) et le nombre de tampons de lecture anticipée (`readAheadBlocks`). La définition conjointe de ces attributs peut améliorer considérablement les performances de la tâche de CDC. Les paramètres suivants fournissent de bons résultats pour la plupart des configurations ASM.

```
useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
    parallelASMReadThreads=6;readAheadBlocks=150000;
```

Pour de plus amples informations sur les valeurs prises en charge par les attributs de connexion supplémentaires, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

En outre, les performances d’une tâche de CDC avec une source Oracle qui utilise ASM dépendent d’autres paramètres que vous choisissez. Ces paramètres incluent vos attributs de connexion supplémentaires AWS DMS et les paramètres SQL pour configurer la source Oracle. Pour plus d’informations sur les attributs de connexion supplémentaires pour une source Oracle qui utilise ASM, consultez [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

Vous devez également choisir un point de départ de CDC approprié. Généralement, lorsque vous effectuez cette opération, vous souhaitez identifier le point de traitement des transactions qui capture la première transaction ouverte à partir de laquelle commencer la CDC. Dans le cas contraire, la tâche de CDC peut manquer les premières transactions ouvertes. Pour une base de données source Oracle, vous pouvez choisir un point de départ natif de CDC en fonction du numéro SCN Oracle afin d’identifier cette première transaction ouverte. Pour de plus amples informations, veuillez consulter [Exécution de la réplication à partir d'un point de départ CDC](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint).

Pour plus d’informations sur la configuration de la CDC pour une base de données Oracle autogérée en tant que source, consultez [Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges), [Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges) et [Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges).

Pour plus d'informations sur la configuration du CDC pour une base de données Oracle AWS gérée en tant que source, consultez [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC) et[Utilisation d'un Amazon RDS Oracle Standby (lire une réplique) comme source avec Binary Reader for CDC dans AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy).

## Flux de travail pour configurer une base de données source Oracle AWS autogérée ou gérée pour AWS DMS


## Configuration d’une base de données source Oracle
<a name="CHAP_Source.Oracle.Workflows"></a>

Pour configurer une instance de base de données source autogérée, suivez les étapes du flux de travail suivantes, en fonction de la manière dont vous effectuez la CDC. 


| Pour cette étape du flux de travail | Si vous utilisez le CDC LogMiner, procédez comme suit | Si vous effectuez la CDC à l’aide de Binary Reader, procédez comme suit | 
| --- | --- | --- | 
| Accordez des privilèges de compte Oracle. | Consultez [Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS](#CHAP_Source.Oracle.Self-Managed.Privileges). | Consultez [Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS](#CHAP_Source.Oracle.Self-Managed.Privileges). | 
| Préparez la base de données source pour la réplication à l’aide de la CDC. | Consultez [Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS](#CHAP_Source.Oracle.Self-Managed.Configuration). | Consultez [Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS](#CHAP_Source.Oracle.Self-Managed.Configuration). | 
| Accordez les privilèges d’utilisateur Oracle supplémentaires requis pour la CDC. | Consultez [Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges). | Consultez [Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges). | 
| Pour une instance Oracle avec ASM, accordez les privilèges de compte d’utilisateur supplémentaires requis pour accéder à ASM pour la CDC. | Aucune action supplémentaire. AWS DMS prend en charge Oracle ASM sans privilèges de compte supplémentaires. | Consultez [Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges). | 
| Si ce n'est pas déjà fait, configurez la tâche à utiliser LogMiner ou Binary Reader for CDC. | Consultez [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). | Consultez [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). | 
| Configurez Oracle Standby en tant que source pour la CDC. | AWS DMS ne prend pas en charge Oracle Standby en tant que source. | Consultez [Utilisation d'un Oracle Standby autogéré comme source avec Binary Reader for CDC dans AWS DMS](#CHAP_Source.Oracle.Self-Managed.BinaryStandby). | 

Utilisez les étapes de flux de travail suivantes pour configurer une instance de base de données source Oracle AWS gérée.


| Pour cette étape du flux de travail | Si vous utilisez le CDC LogMiner, procédez comme suit | Si vous effectuez la CDC à l’aide de Binary Reader, procédez comme suit | 
| --- | --- | --- | 
| Accordez des privilèges de compte Oracle. | Pour de plus amples informations, veuillez consulter [Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | Pour de plus amples informations, veuillez consulter [Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | 
| Préparez la base de données source pour la réplication à l’aide de la CDC. | Pour de plus amples informations, veuillez consulter [Configuration d'une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | Pour de plus amples informations, veuillez consulter [Configuration d'une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | 
| Accordez les privilèges d’utilisateur Oracle supplémentaires requis pour la CDC. | Aucun privilège de compte supplémentaire n’est requis. | Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). | 
| Si ce n'est pas déjà fait, configurez la tâche à utiliser LogMiner ou Binary Reader for CDC. | Pour de plus amples informations, veuillez consulter [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). | Pour de plus amples informations, veuillez consulter [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). | 
| Configurez Oracle Standby en tant que source pour la CDC. | AWS DMS ne prend pas en charge Oracle Standby en tant que source. | Pour de plus amples informations, veuillez consulter [Utilisation d'un Amazon RDS Oracle Standby (lire une réplique) comme source avec Binary Reader for CDC dans AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy). | 

## Utilisation d'une base de données Oracle autogérée comme source pour AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed"></a>

Une *base de données autogérée* est une base de données que vous configurez et contrôlez. Il peut s’agir d’une instance de base de données locale sur site ou d’une base de données sur Amazon EC2. Vous trouverez ci-dessous des informations sur les privilèges et les configurations dont vous avez besoin pour utiliser une base de données Oracle autogérée avec AWS DMS.

### Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.Privileges"></a>

Pour utiliser une base de données Oracle comme source dans AWS DMS, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

**Note**  
Lorsque vous accordez des privilèges, utilisez le nom réel des objets, et non leur synonyme. Par exemple, utilisez `V_$OBJECT` en intégrant le trait de soulignement, et non `V$OBJECT` sans le trait de soulignement.

```
GRANT CREATE SESSION TO dms_user;
GRANT SELECT ANY TRANSACTION TO dms_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO dms_user;
GRANT SELECT ON V_$LOG TO dms_user;
GRANT SELECT ON V_$LOGFILE TO dms_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO dms_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO dms_user;
GRANT SELECT ON V_$DATABASE TO dms_user;
GRANT SELECT ON V_$THREAD TO dms_user;
GRANT SELECT ON V_$PARAMETER TO dms_user;
GRANT SELECT ON V_$NLS_PARAMETERS TO dms_user;
GRANT SELECT ON V_$TIMEZONE_NAMES TO dms_user;
GRANT SELECT ON V_$TRANSACTION TO dms_user;
GRANT SELECT ON V_$CONTAINERS TO dms_user;                   
GRANT SELECT ON ALL_INDEXES TO dms_user;
GRANT SELECT ON ALL_OBJECTS TO dms_user;
GRANT SELECT ON ALL_TABLES TO dms_user;
GRANT SELECT ON ALL_USERS TO dms_user;
GRANT SELECT ON ALL_CATALOG TO dms_user;
GRANT SELECT ON ALL_CONSTRAINTS TO dms_user;
GRANT SELECT ON ALL_CONS_COLUMNS TO dms_user;
GRANT SELECT ON ALL_TAB_COLS TO dms_user;
GRANT SELECT ON ALL_IND_COLUMNS TO dms_user;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO dms_user;
GRANT SELECT ON ALL_LOG_GROUPS TO dms_user;
GRANT SELECT ON ALL_TAB_PARTITIONS TO dms_user;
GRANT SELECT ON SYS.DBA_REGISTRY TO dms_user;
GRANT SELECT ON SYS.OBJ$ TO dms_user;
GRANT SELECT ON DBA_TABLESPACES TO dms_user;
GRANT SELECT ON DBA_OBJECTS TO dms_user; -– Required if the Oracle version is earlier than 11.2.0.3.
GRANT SELECT ON SYS.ENC$ TO dms_user; -– Required if transparent data encryption (TDE) is enabled. For more information on using Oracle TDE with AWS DMS, see Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.
GRANT SELECT ON GV_$TRANSACTION TO dms_user; -– Required if the source database is Oracle RAC in AWS DMS versions 3.4.6 and higher.
GRANT SELECT ON V_$DATAGUARD_STATS TO dms_user; -- Required if the source database is Oracle Data Guard and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.
GRANT SELECT ON V_$DATABASE_INCARNATION TO dms_user;
```

Accordez le privilège supplémentaire suivant pour chaque table répliquée lorsque vous utilisez une liste de tables spécifique.

```
GRANT SELECT on any-replicated-table to dms_user;
```

Accordez le privilège supplémentaire suivant pour utiliser la fonction de validation.

```
GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_user;
```

Accordez le privilège supplémentaire suivant si vous utilisez un lecteur binaire au lieu de LogMiner.

```
GRANT SELECT ON SYS.DBA_DIRECTORIES TO dms_user;
```

Accordez le privilège supplémentaire suivant pour exposer les vues.

```
GRANT SELECT on ALL_VIEWS to dms_user;
```

Pour exposer les vues, vous devez également ajouter l’attribut de connexion supplémentaire `exposeViews=true` au point de terminaison source.

Accordez le privilège supplémentaire suivant lorsque vous utilisez des réplications sans serveur.

```
GRANT SELECT on dba_segments to dms_user;
GRANT SELECT on v_$tablespace to dms_user;
GRANT SELECT on dba_tab_subpartitions to dms_user;
GRANT SELECT on dba_extents to dms_user;
```

Pour en savoir plus sur les réplications sans serveur, consultez [Travailler avec AWS DMS Serverless](CHAP_Serverless.md).

Accordez les privilèges supplémentaires suivants lorsque vous utilisez des évaluations de prémigration spécifiques à Oracle.

```
GRANT SELECT on gv_$parameter  to dms_user;
GRANT SELECT on v_$instance to dms_user;
GRANT SELECT on v_$version to dms_user;
GRANT SELECT on gv_$ASM_DISKGROUP to dms_user;
GRANT SELECT on gv_$database to dms_user;
GRANT SELECT on dba_db_links to dms_user;
GRANT SELECT on gv_$log_History to dms_user;
GRANT SELECT on gv_$log to dms_user;
GRANT SELECT ON DBA_TYPES TO dms_user;
GRANT SELECT ON DBA_USERS to dms_user;
GRANT SELECT ON DBA_DIRECTORIES to dms_user;
GRANT EXECUTE ON SYS.DBMS_XMLGEN TO dms_user;
```

Pour en savoir plus sur les évaluations de prémigration spécifiques à Oracle, consultez [Évaluations Oracle](CHAP_Tasks.AssessmentReport.Oracle.md).

#### Conditions préalables à la gestion des transactions ouvertes pour Oracle Standby
<a name="CHAP_Source.Oracle.Self-Managed.Privileges.Standby"></a>

Lorsque vous utilisez AWS DMS les versions 3.4.6 ou supérieures, effectuez les étapes suivantes pour gérer les transactions ouvertes pour Oracle Standby. 

1. Créez un lien de base de données nommé `AWSDMS_DBLINK` sur la base de données principale. `DMS_USER` utilisera ce lien pour se connecter à la base de données principale. Notez que le lien de base de données est exécuté à partir de l’instance de secours pour interroger les transactions ouvertes exécutées sur la base de données principale. Consultez l'exemple suivant. 

   ```
   CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
      CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
      USING '(DESCRIPTION=
               (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
               (CONNECT_DATA=(SERVICE_NAME=SID))
             )';
   ```

1. Vérifiez que la connexion au lien de base de données avec `DMS_USER` est établie, comme indiqué dans l’exemple suivant.

   ```
   select 1 from dual@AWSDMS_DBLINK
   ```

### Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.Configuration"></a>

Préparez la base de données Oracle autogérée en tant que source pour exécuter une tâche de CDC en procédant comme suit : 
+ [Vérifier que la version de la base de données source est prise en AWS DMS charge](#CHAP_Source.Oracle.Self-Managed.Configuration.DbVersion).
+ [Vérifiez que le mode ARCHIVELOG est activé](#CHAP_Source.Oracle.Self-Managed.Configuration.ArchiveLogMode).
+ [Configurez une journalisation supplémentaire](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).

#### Vérifier que la version de la base de données source est prise en AWS DMS charge
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.DbVersion"></a>

Exécutez une requête similaire à ce qui suit pour vérifier que la version actuelle de la base de données source Oracle est prise en charge par AWS DMS.

```
SELECT name, value, description FROM v$parameter WHERE name = 'compatible';
```

Ici, `name`, `value` et `description` sont des colonnes quelque part dans la base de données qui sont interrogées en fonction de la valeur de `name`. Si cette requête s'exécute sans erreur, elle AWS DMS prend en charge la version actuelle de la base de données et vous pouvez poursuivre la migration. Si la requête génère une erreur, la version actuelle de la base de données AWS DMS n'est pas prise en charge. Pour procéder à la migration, convertissez d'abord la base de données Oracle vers une version prise en charge par AWS DMS.

#### Vérifiez que le mode ARCHIVELOG est activé
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.ArchiveLogMode"></a>

Vous pouvez exécuter Oracle en deux modes différents : le mode `ARCHIVELOG` et le mode `NOARCHIVELOG`. Pour exécuter une tâche de CDC, exécutez la base de données en mode `ARCHIVELOG`. Pour savoir si la base de données est en mode `ARCHIVELOG`, exécutez la requête suivante.

```
SQL> SELECT log_mode FROM v$database;
```

Si le mode `NOARCHIVELOG` est renvoyé, définissez la base de données sur `ARCHIVELOG` conformément aux instructions d’Oracle. 

#### Configurez une journalisation supplémentaire
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging"></a>

Pour enregistrer les modifications en cours, AWS DMS vous devez activer une journalisation supplémentaire minimale sur votre base de données source Oracle. En outre, vous devez activer la journalisation supplémentaire sur chaque table répliquée de la base de données.

Par défaut, AWS DMS ajoute une journalisation `PRIMARY KEY` supplémentaire sur toutes les tables répliquées. AWS DMS Pour autoriser l'ajout d'une journalisation `PRIMARY KEY` supplémentaire, accordez le privilège suivant pour chaque table répliquée.

```
ALTER on any-replicated-table;
```

Vous pouvez désactiver la journalisation `PRIMARY KEY` supplémentaire par défaut ajoutée à AWS DMS l'aide de l'attribut `addSupplementalLogging` de connexion supplémentaire. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

Assurez-vous d'activer la journalisation supplémentaire si votre tâche de réplication met à jour une table à l'aide d'une `WHERE` clause qui ne fait pas référence à une colonne de clé primaire.

**Pour configurer manuellement la journalisation supplémentaire**

1. Exécutez la requête suivante pour vérifier si la journalisation supplémentaire est déjà activée pour la base de données.

   ```
   SELECT supplemental_log_data_min FROM v$database;
   ```

   Si le résultat renvoyé est `YES` ou `IMPLICIT`, la journalisation supplémentaire est activée pour la base de données.

   Sinon, activez la journalisation supplémentaire pour la base de données en exécutant la commande suivante.

   ```
   ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
   ```

1. Assurez-vous que la journalisation supplémentaire requise est ajoutée pour chaque table répliquée.

   Éléments à prendre en compte :
   + Si la journalisation supplémentaire `ALL COLUMNS` est ajoutée à la table, il n’est pas nécessaire d’en ajouter une autre.
   + Si une clé primaire existe, ajoutez une journalisation supplémentaire pour la clé primaire. Vous pouvez le faire en utilisant le format pour ajouter une journalisation supplémentaire sur la clé primaire en elle-même, ou en ajoutant une journalisation supplémentaire sur les colonnes de clé primaire dans la base de données.

     ```
     ALTER TABLE Tablename ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
     ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
     ```
   + Si aucune clé primaire n'existe et que la table possède un seul index unique, toutes les colonnes de l'index unique doivent être ajoutées au journal supplémentaire.

     ```
     ALTER TABLE TableName ADD SUPPLEMENTAL LOG GROUP LogGroupName (UniqueIndexColumn1[, UniqueIndexColumn2] ...) ALWAYS;
     ```

     L'utilisation `SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS` n'ajoute pas les colonnes d'index uniques au journal.
   + S'il n'existe aucune clé primaire et que la table comporte plusieurs index uniques, AWS DMS sélectionne le premier index unique dans une liste alphabétique croissante. Vous devez ajouter une journalisation supplémentaire sur les colonnes de l’index sélectionné, comme au point précédent.

     L'utilisation `SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS` n'ajoute pas les colonnes d'index uniques au journal.
   + Si aucune clé primaire n'existe et qu'il n'y a pas d'index unique, ajoutez une journalisation supplémentaire sur toutes les colonnes.

     ```
     ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
     ```

     Dans certains cas, l'index unique et la clé primaire de la table cible sont différents de ceux de la table source. Dans ce cas, ajoutez manuellement une journalisation supplémentaire sur les colonnes de la table source qui constituent l’index unique ou la clé primaire de la table cible.

     De plus, si vous modifiez la clé primaire de la table cible, vous devez ajouter la journalisation supplémentaire dans les colonnes de l'index cible, au lieu des colonnes de la clé primaire ou de l'index unique source.

Si un filtre ou une transformation est défini pour une table, vous devrez peut-être activer la journalisation supplémentaire.

Éléments à prendre en compte :
+ Si la journalisation supplémentaire `ALL COLUMNS` est ajoutée à la table, il n’est pas nécessaire d’en ajouter une autre.
+ Si la table a un index unique ou une clé primaire, ajoutez une journalisation supplémentaire sur chaque colonne impliquée dans un filtre ou une transformation. Toutefois, ne le faites que si ces colonnes sont différentes des colonnes de la clé primaire ou de l’index unique.
+ Si une transformation inclut une seule colonne, n’ajoutez pas cette colonne à un groupe de journalisations supplémentaires. Par exemple, pour une transformation `A+B`, ajoutez une journalisation supplémentaire sur les deux colonnes `A` et `B`. Cependant, pour une transformation `substring(A,10)`, n'ajoutez pas de journalisation supplémentaire sur la colonne `A`.
+ Pour configurer une journalisation supplémentaire sur les colonnes de clé primaire ou d’index unique et sur d’autres colonnes filtrées ou transformées, vous pouvez configurer la journalisation supplémentaire `USER_LOG_GROUP`. Ajoutez cette journalisation à la fois sur les colonnes de clé primaire ou d’index unique et sur toute autre colonne spécifique filtrée ou transformée.

  Par exemple, pour répliquer une table nommée `TEST.LOGGING` avec une clé primaire `ID` et un filtre sur la colonne `NAME`, vous pouvez exécuter une commande similaire à celle qui suit pour créer la journalisation supplémentaire du groupe de journaux.

  ```
  ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;
  ```

### Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation
<a name="CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges"></a>

Pour accéder aux journaux de journalisation à l'aide d'Oracle LogMiner, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

```
GRANT EXECUTE on DBMS_LOGMNR to dms_user;
GRANT SELECT on V_$LOGMNR_LOGS to dms_user;
GRANT SELECT on V_$LOGMNR_CONTENTS to dms_user;
GRANT LOGMINING to dms_user; -– Required only if the Oracle version is 12c or higher.
```

### Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration
<a name="CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges"></a>

Pour accéder aux journaux de journalisation à l'aide du lecteur AWS DMS binaire, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

```
GRANT SELECT on v_$transportable_platform to dms_user;   -– Grant this privilege if the redo logs are stored in Oracle Automatic Storage Management (ASM) and AWS DMS accesses them from ASM.
GRANT CREATE ANY DIRECTORY to dms_user;                  -– Grant this privilege to allow AWS DMS to use Oracle BFILE read file access in certain cases. This access is required when the replication instance does not have file-level access to the redo logs and the redo logs are on non-ASM storage.
GRANT EXECUTE on DBMS_FILE_TRANSFER to dms_user;         -– Grant this privilege to copy the redo log files to a temporary folder using the CopyToTempFolder method.
GRANT EXECUTE on DBMS_FILE_GROUP to dms_user;
```

Binary Reader fonctionne avec les fonctions de fichier Oracle qui incluent des répertoires Oracle. Chaque objet répertoire Oracle inclut le nom du dossier contenant les journaux redo à traiter. Ces répertoires Oracle ne sont pas représentés au niveau du système de fichiers. Il s'agit plutôt de répertoires logiques créés au niveau de la base de données Oracle. Vous pouvez les afficher dans la vue Oracle `ALL_DIRECTORIES`.

Si vous souhaitez AWS DMS créer ces annuaires Oracle, accordez le `CREATE ANY DIRECTORY` privilège spécifié ci-dessus. AWS DMS crée les noms de répertoires avec le `DMS_` préfixe. Si vous n'accordez pas le privilège `CREATE ANY DIRECTORY`, créez manuellement les répertoires correspondants. Dans certains cas, lorsque vous créez manuellement les répertoires Oracle, l'utilisateur Oracle spécifié dans le point de terminaison source Oracle n'est pas l'utilisateur qui a créé ces répertoires. Dans ces cas, accordez également le privilège `READ on DIRECTORY`.

**Note**  
AWS DMS Le CDC ne prend pas en charge Active Dataguard Standby qui n'est pas configuré pour utiliser le service de rétablissement automatique du transport.

Dans certains cas, vous pouvez utiliser Oracle Managed Files (OMF) pour stocker les journaux. Ou le point de terminaison source se trouve dans ADG et vous ne pouvez donc pas accorder le privilège CREATE ANY DIRECTORY. Dans ces cas, créez manuellement les répertoires avec tous les emplacements de journal possibles avant de démarrer la tâche de AWS DMS réplication. Si AWS DMS le répertoire précréé attendu n'est pas trouvé, la tâche s'arrête. De plus, AWS DMS ne supprime pas les entrées qu'il a créées dans la `ALL_DIRECTORIES` vue. Supprimez-les donc manuellement.

### Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM
<a name="CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges"></a>

Pour accéder aux journaux redo dans Automatic Storage Management (ASM) à l’aide de Binary Reader, accordez les privilèges suivants à l’utilisateur Oracle spécifié dans les paramètres de connexion au point de terminaison Oracle.

```
SELECT ON v_$transportable_platform
SYSASM -– To access the ASM account with Oracle 11g Release 2 (version 11.2.0.2) and higher, grant the Oracle endpoint user the SYSASM privilege. For older supported Oracle versions, it's typically sufficient to grant the Oracle endpoint user the SYSDBA privilege.
```

Vous pouvez valider l’accès au compte ASM en ouvrant une invite de commandes et en invoquant l’une des instructions suivantes, en fonction de votre version d’Oracle spécifiée précédemment.

Si vous avez besoin du privilège `SYSDBA`, utilisez ce qui suit.

```
sqlplus asmuser/asmpassword@+asmserver as sysdba
```

Si vous avez besoin du privilège `SYSASM`, utilisez ce qui suit. 

```
sqlplus asmuser/asmpassword@+asmserver as sysasm
```

### Utilisation d'un Oracle Standby autogéré comme source avec Binary Reader for CDC dans AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.BinaryStandby"></a>

Pour configurer une instance d’Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC, commencez par prendre connaissance des prérequis suivants :
+ AWS DMS prend actuellement en charge uniquement Oracle Active Data Guard Standby.
+ Assurez-vous que la configuration d’Oracle Data Guard utilise :
  + Services de transport redo pour les transferts automatisés de données redo.
  + Services d’application pour appliquer automatiquement redo à la base de données de secours.

Pour confirmer que ces exigences sont satisfaites, exécutez la requête suivante.

```
SQL> select open_mode, database_role from v$database;
```

À partir du résultat de cette requête, vérifiez que la base de données de secours est ouverte en mode READ ONLY et que redo est appliqué automatiquement. Par exemple :

```
OPEN_MODE             DATABASE_ROLE
--------------------  ----------------
READ ONLY WITH APPLY  PHYSICAL STANDBY
```

**Pour configurer une instance d’Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC**

1. Accordez les privilèges supplémentaires requis pour accéder aux fichiers journaux de secours.

   ```
   GRANT SELECT ON v_$standby_log TO dms_user;
   ```

1. Créez un point de terminaison source pour Oracle Standby à l’aide d’ AWS Management Console ou d’ AWS CLI. Lors de la création du point de terminaison, spécifiez les attributs de connexion supplémentaires suivants.

   ```
   useLogminerReader=N;useBfile=Y;
   ```
**Note**  
Dans AWS DMS, vous pouvez utiliser des attributs de connexion supplémentaires pour spécifier si vous souhaitez migrer à partir des journaux d'archives plutôt que des journaux de rétablissement. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

1. Configurez la destination du journal archivé.

   DMS Binary Reader pour la source Oracle sans ASM utilise les répertoires Oracle pour accéder aux journaux redo archivés. Si la base de données est configurée de sorte à utiliser la zone de récupération rapide (FRA) comme destination du journal d’archivage, l’emplacement des fichiers redo d’archivage n’est pas constant. Chaque jour de génération de journaux redo archivés entraîne la création d’un nouveau répertoire dans la FRA en utilisant le format de nom de répertoire AAAA\$1MM\$1JJ. Par exemple : 

   ```
   DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD
   ```

   Lorsque DMS a besoin d’accéder à des fichiers redo archivés dans le répertoire FRA récemment créé et que la base de données principale en lecture-écriture est utilisée en tant que source, DMS crée un nouveau répertoire Oracle ou remplace un répertoire Oracle existant, comme suit. 

   ```
   CREATE OR REPLACE DIRECTORY dmsrep_taskid AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD’;
   ```

   Lorsque la base de données de secours est utilisée en tant que source, DMS ne parvient pas à créer ou à remplacer le répertoire Oracle, car la base de données est en mode lecture seule. Toutefois, vous pouvez choisir d’effectuer l’une des étapes supplémentaires suivantes : 

   1. Modifiez `log_archive_dest_id_1` de sorte à utiliser un chemin réel plutôt que la FRA dans une configuration de ce type où Oracle ne créera pas de sous-répertoires quotidiens :

      ```
      ALTER SYSTEM SET log_archive_dest_1=’LOCATION=full directory path’
      ```

      Créez ensuite un objet de répertoire Oracle à utiliser par DMS :

      ```
      CREATE OR REPLACE DIRECTORY dms_archived_logs AS ‘full directory path’;
      ```

   1. Créez une destination de journal d’archivage supplémentaire et un objet de répertoire Oracle pointant vers cette destination. Par exemple :

      ```
      ALTER SYSTEM SET log_archive_dest_3=’LOCATION=full directory path’; 
      CREATE DIRECTORY dms_archived_log AS ‘full directory path’;
      ```

      Ajoutez ensuite un attribut de connexion supplémentaire au point de terminaison source de la tâche :

      ```
      archivedLogDestId=3
      ```

   1. Précréez manuellement des objets de répertoire Oracle à utiliser par DMS.

      ```
      CREATE DIRECTORY dms_archived_log_20210301 AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/2021_03_01’;
      CREATE DIRECTORY dms_archived_log_20210302 AS ‘DB_RECOVERY_FILE_DEST>/SID>/archivelog/2021_03_02’; 
      ...
      ```

   1. Créez une tâche de planificateur Oracle qui s’exécute quotidiennement et crée le répertoire requis.

1. Configurez la destination du journal en ligne. 

   Créez un répertoire Oracle qui pointe vers le répertoire du système d'exploitation contenant des journaux de restauration de secours :

   ```
   CREATE OR REPLACE DIRECTORY STANDBY_REDO_DIR AS '<full directory path>';
   GRANT READ ON DIRECTORY STANDBY_REDO_DIR TO <dms_user>;
   ```

### Utilisation d'une base de données gérée par l'utilisateur sur Oracle Cloud Infrastructure (OCI) comme source pour le CDC dans AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.OCI"></a>

Une base de données gérée par l’utilisateur est une base de données que vous configurez et contrôlez, comme une base de données Oracle créée sur une machine virtuelle (VM), un matériel nu ou un serveur Exadata. Il peut également s’agir de bases de données que vous configurez et contrôlez et qui s’exécutent sur une infrastructure dédiée, comme Oracle Cloud Infrastructure (OCI). Les informations suivantes décrivent les privilèges et les configurations dont vous avez besoin lorsque vous utilisez une base de données Oracle gérée par l’utilisateur sur OCI en tant que source pour la capture des données de modification (CDC) dans AWS DMS.

**Pour configurer une base de données Oracle gérée par l’utilisateur et hébergée par OCI en tant que source pour la capture des données de modification**

1. Accordez les privilèges de compte d’utilisateur requis pour une base de données source Oracle gérée par l’utilisateur sur OCI. Pour plus d’informations, consultez [Privilèges de compte pour un point de terminaison source Oracle autogéré](#CHAP_Source.Oracle.Self-Managed.Privileges).

1. Accordez les privilèges de compte requis lors de l’utilisation de Binary Reader pour accéder aux journaux redo. Pour plus d’informations, consultez [Privilèges de compte requis lors de l’utilisation de Binary Reader](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges).

1. Ajoutez les privilèges de compte requis lors de l’utilisation de Binary Reader avec Oracle Automatic Storage Management (ASM). Pour plus d’informations, consultez [Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges).

1. Configurez une journalisation supplémentaire. Pour plus d’informations, consultez [Configuration d’une journalisation supplémentaire](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).

1. Configurez le chiffrement TDE. Pour plus d’informations, consultez [Méthodes de chiffrement lors de l’utilisation d’une base de données Oracle comme point de terminaison source](#CHAP_Source.Oracle.Encryption).

Les limitations suivantes s’appliquent lors de la réplication de données à partir d’une base de données source Oracle sur Oracle Cloud Infrastructure (OCI).

**Limitations**
+ DMS ne prend pas en charge l'utilisation d'Oracle LogMiner pour accéder aux journaux de journalisation.
+ DMS ne prend pas en charge la base de données autonome.

## Utilisation d'une base de données Oracle AWS gérée comme source pour AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed"></a>

Une base de données AWS gérée est une base de données qui se trouve sur un service Amazon tel qu'Amazon RDS, Amazon Aurora ou Amazon S3. Vous trouverez ci-dessous les privilèges et les configurations que vous devez configurer lorsque vous utilisez une base de données Oracle AWS gérée avec AWS DMS.

### Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.Privileges"></a>

Accordez les privilèges suivants au compte d’utilisateur Oracle spécifié dans la définition du point de terminaison source Oracle.

**Important**  
Pour toutes les valeurs de paramètre telles que `dms_user` et `any-replicated-table`, Oracle suppose que la valeur est entièrement en majuscules, sauf si vous spécifiez la valeur avec un identifiant sensible à la casse. Supposons, par exemple, que vous créez une valeur `dms_user` sans utiliser de guillemets, comme dans `CREATE USER myuser` ou `CREATE USER MYUSER`. Dans ce cas, Oracle identifie et stocke la valeur entièrement en majuscules (`MYUSER`). Si vous utilisez des guillemets, comme dans `CREATE USER "MyUser"` ou `CREATE USER 'MyUser'`, Oracle identifie et stocke la valeur sensible à la casse que vous spécifiez (`MyUser`).

```
GRANT CREATE SESSION to dms_user;
GRANT SELECT ANY TRANSACTION to dms_user;
GRANT SELECT on DBA_TABLESPACES to dms_user;
GRANT SELECT ON any-replicated-table to dms_user;
GRANT EXECUTE on rdsadmin.rdsadmin_util to dms_user;
 -- For Oracle 12c or higher:
GRANT LOGMINING to dms_user; – Required only if the Oracle version is 12c or higher.
```

De plus, accordez les autorisations `SELECT` et `EXECUTE` sur les objets `SYS` à l’aide de la procédure Amazon RDS `rdsadmin.rdsadmin_util.grant_sys_object`, comme indiqué. Pour plus d'informations, consultez la page [Attribution des privilèges SELECT ou EXECUTE aux objets SYS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html#Appendix.Oracle.CommonDBATasks.TransferPrivileges).

```
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','dms_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'dms_user', 'EXECUTE');

-- (as of Oracle versions 12.1 and higher)
exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'dms_user', 'SELECT');

-- (for Amazon RDS Active Dataguard Standby (ADG))
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'dms_user', 'SELECT'); 

-- (for transparent data encryption (TDE))

exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'dms_user', 'SELECT'); 
               
-- (for validation with LOB columns)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'dms_user', 'EXECUTE');
                    
-- (for binary reader)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','dms_user','SELECT'); 
                    
-- Required when the source database is Oracle Data guard, and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATAGUARD_STATS', 'dms_user', 'SELECT');
```

Pour plus d’informations sur l’utilisation d’Amazon RDS Active Dataguard Standby (ADG) avec AWS DMS , consultez [Utilisation d'un Amazon RDS Oracle Standby (lire une réplique) comme source avec Binary Reader for CDC dans AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy).

Pour plus d'informations sur l'utilisation d'Oracle TDE avec AWS DMS, consultez[Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Encryption).

#### Conditions préalables à la gestion des transactions ouvertes pour Oracle Standby
<a name="CHAP_Source.Oracle.Amazon-Managed.Privileges.Standby"></a>

Lorsque vous utilisez AWS DMS les versions 3.4.6 ou supérieures, effectuez les étapes suivantes pour gérer les transactions ouvertes pour Oracle Standby. 

1. Créez un lien de base de données nommé `AWSDMS_DBLINK` sur la base de données principale. `DMS_USER` utilisera ce lien pour se connecter à la base de données principale. Notez que le lien de base de données est exécuté à partir de l’instance de secours pour interroger les transactions ouvertes exécutées sur la base de données principale. Consultez l'exemple suivant. 

   ```
   CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
      CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
      USING '(DESCRIPTION=
               (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
               (CONNECT_DATA=(SERVICE_NAME=SID))
             )';
   ```

1. Vérifiez que la connexion au lien de base de données avec `DMS_USER` est établie, comme indiqué dans l’exemple suivant.

   ```
   select 1 from dual@AWSDMS_DBLINK
   ```

### Configuration d'une source Oracle AWS gérée pour AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.Configuration"></a>

Avant d'utiliser une base de données Oracle AWS gérée comme source pour AWS DMS, effectuez les tâches suivantes pour la base de données Oracle :
+ Activez les sauvegardes automatiques. Pour plus d’informations sur l’activation des sauvegardes automatiques, consultez [Activation des sauvegardes automatiques](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling) dans le *Guide de l’utilisateur Amazon RDS*.
+ Configurez la journalisation supplémentaire.
+ Configurez l'archivage. L'archivage des journaux redo de votre instance de base de données Amazon RDS for Oracle permet de récupérer les informations du journal AWS DMS à l'aide d'Oracle LogMiner ou de Binary Reader. 

**Pour configurer l'archivage**

1. Exécutez la commande `rdsadmin.rdsadmin_util.set_configuration` pour configurer l'archivage.

   Par exemple, pour conserver les journaux redo archivés pendant 24 heures, exécutez la commande suivante.

   ```
   exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
   commit;
   ```
**Note**  
La validation est obligatoire pour qu’une modification prenne effet.

1. Vérifiez que votre espace de stockage est suffisant pour les journaux redo archivés pendant la période spécifiée. Par exemple, si votre période de conservation est de 24 heures, calculez la taille totale de vos journaux redo archivés accumulés sur une heure type de traitement des transactions et multipliez ce total par 24. Comparez ce total calculé sur 24 heures avec votre espace de stockage disponible et déterminez si vous disposez de suffisamment d’espace de stockage pour traiter les transactions 24 h/24.

**Pour configurer la journalisation supplémentaire**

1. Exécutez la commande suivante pour activer la journalisation supplémentaire au niveau de la base de données.

   ```
   exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
   ```

1. Exécutez la commande suivante pour activer la journalisation supplémentaire des clés primaires.

   ```
   exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');
   ```

1. (Facultatif) Activez la journalisation supplémentaire au niveau des clés, au niveau de la table.

   Votre base de données source exige un peu plus de temps système lorsqu’une journalisation supplémentaire au niveau des clés est activée. Par conséquent, si vous ne migrez qu’un sous-ensemble de vos tables, vous souhaiterez peut-être activer la journalisation supplémentaire au niveau des clés, au niveau de la table. Pour activer la journalisation supplémentaire au niveau des clés, au niveau de la table, exécutez la commande suivante.

   ```
   alter table table_name add supplemental log data (PRIMARY KEY) columns;
   ```

### Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.CDC"></a>

Vous pouvez configurer l'accès AWS DMS à la source des journaux redo de l'instance Amazon RDS pour Oracle à l'aide de Binary Reader for CDC. 

**Note**  
Pour utiliser Oracle LogMiner, les privilèges de compte utilisateur minimaux requis sont suffisants. Pour de plus amples informations, veuillez consulter [Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges).

Pour utiliser AWS DMS Binary Reader, spécifiez des paramètres supplémentaires et des attributs de connexion supplémentaires pour le point de terminaison source Oracle, en fonction de votre AWS DMS version.

La prise en charge de Binary Reader est disponible dans les versions suivantes d’Amazon RDS for Oracle :
+ Oracle 11.2 : versions 11.2.0.4V11 et ultérieures
+ Oracle 12.1 : versions 12.1.0.2.V7 et ultérieures
+ Oracle 12.2 : toutes les versions
+ Oracle 18.0 : toutes les versions
+ Oracle 19.0 : toutes les versions

**Pour configurer CDC à l'aide d' Binary Reader**

1. Connectez-vous à la base de données source Amazon RDS for Oracle en tant qu’utilisateur principal et exécutez les procédures stockées suivantes pour créer les répertoires au niveau du serveur.

   ```
   exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
   exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
   ```

1. Accordez les privilèges suivants au compte d’utilisateur Oracle utilisé pour accéder au point de terminaison source Oracle.

   ```
   GRANT READ ON DIRECTORY ONLINELOG_DIR TO dms_user;
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO dms_user;
   ```

1. Définissez les attributs de connexion supplémentaires suivants sur le point de terminaison source Amazon RDS Oracle :
   + Pour RDS Oracle versions 11.2 et 12.1, définissez les attributs suivants.

     ```
     useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;useAlternateFolderForOnline=true;
     oraclePathPrefix=/rdsdbdata/db/{$DATABASE_NAME}_A/;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;
     ```
   + Pour RDS Oracle versions 12.2, 18.0 et 19.0, définissez les attributs suivants.

     ```
     useLogminerReader=N;useBfile=Y;
     ```

**Note**  
Assurez-vous qu’il n’y ait pas d’espace après le point-virgule (;) si vous avez plusieurs paramètres d’attribut ; par exemple, `oneSetting;thenAnother`.

Pour plus d’informations sur la configuration d’une tâche de CDC, consultez [Configuration de CDC sur une base de données source Oracle](#CHAP_Source.Oracle.CDC.Configuration).

### Utilisation d'un Amazon RDS Oracle Standby (lire une réplique) comme source avec Binary Reader for CDC dans AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.StandBy"></a>

Vérifiez les conditions préalables suivantes pour utiliser Amazon RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC dans AWS DMS :
+ Utilisez l’utilisateur principal Oracle pour configurer Binary Reader.
+ Assurez-vous qu'il ne prend AWS DMS actuellement en charge que l'utilisation d'Oracle Active Data Guard Standby.

Ensuite, procédez comme suit pour utiliser RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC.

**Pour configurer RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC**

1. Connectez-vous à l’instance principale de RDS for Oracle en tant qu’utilisateur principal.

1. Exécutez les procédures stockées suivantes, comme indiqué dans le Guide de l’utilisateur Amazon RDS, pour créer les répertoires au niveau du serveur.

   ```
   exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
   exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
   ```

1. Identifiez les répertoires créés à l’étape 2.

   ```
   SELECT directory_name, directory_path FROM all_directories
   WHERE directory_name LIKE ( 'ARCHIVELOG_DIR_%' )
           OR directory_name LIKE ( 'ONLINELOG_DIR_%' )
   ```

   Par exemple, le code précédent affiche une liste de répertoires comme ce qui suit.  
![\[Table showing directory names and their corresponding paths for archive and online logs.\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-rds-server-level-directories.png)

1. Accordez le privilège `Read` sur les répertoires précédents au compte d’utilisateur Oracle utilisé pour accéder à Oracle Standby.

   ```
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR_A TO dms_user;
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TO dms_user;
   GRANT READ ON DIRECTORY ONLINELOG_DIR_A TO dms_user;
   GRANT READ ON DIRECTORY ONLINELOG_DIR_B TO dms_user;
   ```

1. Changez de journal d’archivage sur l’instance principale. Cela garantit que les modifications apportées à `ALL_DIRECTORIES` sont également transmises à Oracle Standby.

1. Exécutez une requête `ALL_DIRECTORIES` sur Oracle Standby pour confirmer que les modifications ont été appliquées.

1. Créez un point de terminaison source pour Oracle Standby à l'aide de la console AWS DMS de gestion ou AWS Command Line Interface (AWS CLI). Lors de la création du point de terminaison, spécifiez les attributs de connexion supplémentaires suivants.

   ```
   useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2
   ```

1. Après avoir créé le point de terminaison, utilisez **Tester la connexion du point** de **terminaison sur la page Créer un point** de terminaison de la console ou utilisez la AWS CLI `test-connection` commande pour vérifier que la connectivité est établie.

## Restrictions relatives à l'utilisation d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.Limitations"></a>

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données Oracle comme source pour AWS DMS:
+ AWS DMS prend en charge les types de données Oracle Extended dans les AWS DMS versions 3.5.0 et supérieures.
+ AWS DMS ne prend pas en charge les noms d'objets longs (plus de 30 octets).
+ AWS DMS ne prend pas en charge les index basés sur les fonctions.
+ Si vous gérez la journalisation supplémentaire et que vous effectuez des transformations sur l’une des colonnes, assurez-vous que la journalisation supplémentaire est activée pour tous les champs et colonnes. Pour plus d’informations sur la configuration d’une journalisation supplémentaire, consultez les rubriques suivantes :
  + Pour une base de données source Oracle autogérée, consultez [Configurez une journalisation supplémentaire](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
  + Pour une base de données source Oracle AWS gérée, voir[Configuration d'une source Oracle AWS gérée pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration).
+ AWS DMS ne prend pas en charge la base de données racine de conteneurs à locataires multiples (CDB\$1ROOT). Il prend en charge une PDB qui utilise Binary Reader.
+ AWS DMS ne prend pas en charge les contraintes différées.
+ AWS DMS la version 3.5.3 et supérieure prend entièrement en charge le protocole sécurisé LOBs.
+ AWS DMS prend en charge la `rename table table-name to new-table-name` syntaxe de toutes les versions Oracle 11 et supérieures prises en charge. Cette syntaxe n’est pas prise en charge pour les bases de données sources Oracle version 10.
+ AWS DMS ne reproduit pas les résultats de l'instruction DDL. `ALTER TABLE ADD column data_type DEFAULT default_value` Au lieu de répliquer `default_value` vers la cible, il définit la nouvelle colonne sur `NULL`.
+ Lorsque vous utilisez AWS DMS la version 3.4.7 ou supérieure, pour répliquer les modifications résultant d'opérations de partition ou de sous-partition, procédez comme suit avant de démarrer une tâche DMS.
  + Créez manuellement la structure de table partitionnée (DDL) ; 
  + Assurez-vous que la DDL est la même sur la source Oracle et la cible Oracle ; 
  + Définissez l’attribut de connexion supplémentaire `enableHomogenousPartitionOps=true`.

  Pour plus d’informations sur `enableHomogenousPartitionOps`, consultez [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib). Notez également que sur les tâches FULL\$1CDC, DMS ne réplique pas les modifications de données capturées dans le cadre des modifications mises en cache. Dans ce cas d’utilisation, recréez la structure de table sur la cible Oracle et rechargez les tables en question.

  Avant la AWS DMS version 3.4.7 :

  DMS ne reproduit pas les modifications de données résultant d'opérations de partition ou de sous-partition (`ADD`, `DROP``EXCHANGE`, et). `TRUNCATE` Ces mises à jour peuvent provoquer les erreurs suivantes pendant la réplication :
  + Pour les opérations `ADD`, les mises à jour et les suppressions des données ajoutées peuvent déclencher un avertissement « 0 lignes affectées ».
  + Pour les opérations `DROP` et `TRUNCATE`, les nouvelles insertions peuvent générer des erreurs de « doublons ».
  + Les opérations `EXCHANGE` peuvent déclencher à la fois un avertissement « 0 lignes affectées » et des erreurs « doublons ».

  Pour répliquer les modifications résultant d'opérations de partition ou de sous-partition, rechargez les tables en question. Après l’ajout d’une nouvelle partition vide, les opérations sur la partition récemment ajoutée sont répliquées vers la cible comme d’habitude.
+ AWS DMS les versions antérieures à 3.4 ne prennent pas en charge les modifications de données sur la cible résultant de l'exécution de l'`CREATE TABLE AS`instruction sur la source. Toutefois, la nouvelle table est créée sur la cible.
+ AWS DMS ne capture pas les modifications apportées par le `DBMS_REDEFINITION` package Oracle, par exemple les métadonnées de la table et le `OBJECT_ID` champ.
+ Lorsque le mode LOB de taille limitée est activé, les BLOB/CLOB colonnes vides de la source Oracle sont répliquées sous forme de valeurs NULL. Lorsque le mode LOB complet est activé, ils sont répliqués sous forme de chaîne vide (« »).
+ Lors de la capture de modifications avec Oracle 11 LogMiner, une mise à jour sur une colonne CLOB dont la longueur de chaîne est supérieure à 1982 est perdue et la cible n'est pas mise à jour.
+ Lors de la capture des données de modification (CDC), les mises à jour par lots des colonnes numériques définies comme clé primaire AWS DMS ne sont pas prises en charge.
+ AWS DMS ne prend pas en charge certaines `UPDATE` commandes. L’exemple suivant est une commande `UPDATE` non prise en charge.

  ```
  UPDATE TEST_TABLE SET KEY=KEY+1;
  ```

  Ici, `TEST_TABLE` est le nom de la table et `KEY` est une colonne numérique définie comme une clé primaire.
+ AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONG et LONG RAW. Vous pouvez plutôt utiliser le mode LOB limité pour migrer ces types de données vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONG ou LONG RAW de plus de 64 Ko.
+ AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes XMLTYPE. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes XMLTYPE vers une cible Oracle. En mode LOB limité, DMS tronque toutes les données dont la taille est supérieure à la variable « Taille de LOB maximale » définie par l’utilisateur. La valeur maximale recommandée pour « Taille de LOB maximale » est de 100 Mo.
+ AWS DMS ne reproduit pas les tables dont les noms contiennent des apostrophes.
+ AWS DMS soutient le CDC à partir de vues matérialisées. Mais le DMS ne soutient pas le CDC d'un autre point de vue.
+ AWS DMS ne prend pas en charge le CDC pour les tables organisées par index avec un segment de débordement.
+ AWS DMS ne prend pas en charge l'`Drop Partition`opération pour les tables partitionnées par référence avec la valeur `enableHomogenousPartitionOps` définie sur. `true`
+ Lorsque vous utilisez Oracle LogMiner pour accéder aux journaux de journalisation, les limites suivantes AWS DMS s'appliquent :
  + Pour Oracle 12 uniquement, AWS DMS ne reproduit aucune modification apportée aux colonnes LOB.
  + AWS DMS ne prend pas en charge les transactions XA lors de la réplication lors de l'utilisation d'Oracle LogMiner.
  + Oracle LogMiner ne prend pas en charge les connexions à une base de données enfichable (PDB). Pour vous connecter à un PDB, accédez aux fichiers de journalisation à l'aide de Binary Reader.
  + Les opérations SHRINK SPACE ne sont pas prises en charge.
+ Lorsque vous utilisez Binary Reader, il AWS DMS présente les limites suivantes :
  + Il ne prend pas en charge les clusters de tables.
  + Il ne prend en charge que les opérations `SHRINK SPACE` au niveau de la table. Ce niveau inclut la table complète, les partitions et les sous-partitions.
  + Il ne prend pas en charge les modifications apportées aux tables organisées par index à l'aide de la compression des touches.
  + Il ne prend pas en charge la mise en œuvre de journaux de restauration en ligne sur les appareils bruts.
  + Binary Reader prend en charge le TDE uniquement pour les bases de données Oracle autogérées, car RDS for Oracle ne prend pas en charge la récupération des mots de passe de portefeuille pour les clés de chiffrement TDE.
+ AWS DMS ne prend pas en charge les connexions à une source Oracle Amazon RDS à l'aide d'un proxy Oracle Automatic Storage Management (ASM).
+ AWS DMS ne prend pas en charge les colonnes virtuelles. 
+ AWS DMS ne prend pas en charge le type de `ROWID` données ou les vues matérialisées basées sur une colonne ROWID.

  AWS DMS prend partiellement en charge Oracle Materialized Views. Pour les chargements complets, DMS peut effectuer une copie de chargement complet d’une vue matérialisée Oracle. DMS copie la vue matérialisée en tant que table de base sur le système cible et ignore les colonnes ROWID dans la vue matérialisée. Pour la réplication continue (CDC), DMS essaie de répliquer les modifications apportées aux données de la vue matérialisée, mais il est possible que les résultats ne soient pas idéaux. Plus précisément, si la vue matérialisée est complètement actualisée, DMS réplique les suppressions individuelles pour toutes les lignes, puis les insertions individuelles pour toutes les lignes. Cet exercice nécessite beaucoup de ressources et risque d’être peu performant pour les vues matérialisées comportant un grand nombre de lignes. Pour une réplication continue où les vues matérialisées sont actualisées rapidement, DMS essaie de traiter et de répliquer les modifications des données d’actualisation rapide. Dans les deux cas, DMS ignore toutes les colonnes ROWID dans la vue matérialisée.
+ AWS DMS ne charge ni ne capture de tables temporaires globales.
+ Pour les cibles S3 utilisant la réplication, activez la journalisation supplémentaire sur chaque colonne afin que les mises à jour des lignes source puissent capturer chaque valeur de colonne. Voici un exemple : `alter table yourtablename add supplemental log data (all) columns;`.
+ La mise à jour d’une ligne comportant une clé unique composite contenant `null` ne peut pas être répliquée sur la cible.
+ AWS DMS ne prend pas en charge l'utilisation de plusieurs clés de chiffrement Oracle TDE sur le même point de terminaison source. Chaque point de terminaison ne peut avoir qu’un seul attribut pour le nom de clé de chiffrement TDE « `securityDbEncryptionName` » et un seul mot de passe TDE pour cette clé.
+ Lors de la réplication depuis Amazon RDS for Oracle, le TDE n'est pris en charge qu'avec un tablespace chiffré et avec Oracle. LogMiner
+ AWS DMS ne prend pas en charge plusieurs opérations de renommage de table en succession rapide.
+ Lorsque vous utilisez Oracle 19.0 comme source, les fonctionnalités suivantes AWS DMS ne sont pas prises en charge :
  + Redirection DML dans Data Guard
  + Tables hybrides partitionnées
  + Comptes Oracle de schéma uniquement
+ AWS DMS ne prend pas en charge la migration de tables ou de vues de type `BIN$` ou`DR$`.
+ À partir d'Oracle 18.x, la capture des données de modification (CDC) AWS DMS n'est pas prise en charge à partir d'Oracle Express Edition (Oracle Database XE).
+ Lors de la migration de données à partir d’une colonne CHAR, DMS tronque les espaces de fin. 
+ AWS DMS ne prend pas en charge la réplication à partir de conteneurs d'applications.
+ AWS DMS ne prend pas en charge l'exécution de la base de données Oracle Flashback et des points de restauration, car ces opérations affectent la cohérence des fichiers Oracle Redo Log.
+ Avant la AWS DMS version 3.5.3, la `INSERT` procédure de chargement direct avec l'option d'exécution parallèle n'était pas prise en charge dans les cas suivants :
  + Tables non compressées de plus de 255 colonnes
  + Taille de ligne supérieure à 8 Ko
  + Tables HCC Exadata
  + Base de données exécutée sur la plateforme Big Endian
+ Une table source n’ayant ni clé primaire ni clé unique nécessite l’activation de la journalisation supplémentaire ALL COLUMN. Des activités de journal redo supplémentaires seront créées et la latence de la CDC DMS peut augmenter.
+ AWS DMS ne migre pas les données des colonnes invisibles de votre base de données source. Pour inclure ces colonnes dans la portée de migration, utilisez l’instruction `ALTER TABLE` pour les rendre visibles.
+ Pour toutes les versions d'Oracle, AWS DMS ne reproduit pas le résultat des `UPDATE` opérations sur les colonnes LOB `XMLTYPE` et sur les colonnes.
+ AWS DMS ne prend pas en charge la réplication à partir de tables soumises à des contraintes de validité temporelle.
+ Si la source Oracle devient indisponible pendant une tâche de chargement complet, AWS DMS il est possible que la tâche soit marquée comme terminée après plusieurs tentatives de reconnexion, même si la migration des données reste incomplète. Dans ce scénario, les tables cibles contiennent uniquement les enregistrements migrés avant la perte de connexion, ce qui peut créer des incohérences de données entre les systèmes source et cible. Pour garantir l'exhaustivité des données, vous devez soit redémarrer entièrement la tâche de chargement complet, soit recharger les tables spécifiques concernées par l'interruption de connexion.

## Prise en charge de SSL pour un point de terminaison Oracle
<a name="CHAP_Security.SSL.Oracle"></a>

AWS DMS Les points de terminaison Oracle prennent en charge le protocole SSL V3 pour les modes `none` et `verify-ca` SSL. Pour utiliser SSL avec un point de terminaison Oracle, vous devez charger le portefeuille Oracle pour le point de terminaison au lieu des fichiers de certificat .pem. 

**Topics**
+ [Utilisation d'un certificat existant pour Oracle SSL](#CHAP_Security.SSL.Oracle.Existing)
+ [Utilisation d'un certificat auto-signé pour Oracle SSL](#CHAP_Security.SSL.Oracle.SelfSigned)

### Utilisation d'un certificat existant pour Oracle SSL
<a name="CHAP_Security.SSL.Oracle.Existing"></a>

Pour utiliser une installation de client Oracle existante afin de créer le fichier de portefeuille Oracle à partir du fichier de certificat CA, procédez comme suit.

**Pour utiliser une installation de client Oracle existante pour Oracle SSL avec AWS DMS**

1. Définissez la variable système `ORACLE_HOME` sur l'emplacement de votre répertoire `dbhome_1` en exécutant la commande suivante.

   ```
   prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1                        
   ```

1. Ajouter `$ORACLE_HOME/lib` à la variable système `LD_LIBRARY_PATH`.

   ```
   prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib                        
   ```

1. Créez un répertoire pour le portefeuille Oracle dans `$ORACLE_HOME/ssl_wallet`.

   ```
   prompt>mkdir $ORACLE_HOME/ssl_wallet
   ```

1. Placez le fichier `.pem` du certificat de l'autorité de certification dans le répertoire `ssl_wallet`. Si vous utilisez Amazon RDS, vous pouvez télécharger le fichier de certificat d’autorité de certification racine `rds-ca-2015-root.pem` hébergé par Amazon RDS. Pour plus d'informations sur le téléchargement de ce fichier, consultez la section [Utilisation SSL/TLS pour chiffrer une connexion à une instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) de base de données dans le guide de l'*utilisateur Amazon RDS*.

1. Si votre certificat CA contient plusieurs fichiers PEM (comme le bundle mondial ou régional Amazon RDS), vous devez le diviser en fichiers séparés et les ajouter au portefeuille Oracle à l'aide du script bash suivant. Ce script nécessite deux entrées de paramètres : le chemin d'accès au certificat CA et le chemin d'accès au dossier du portefeuille Oracle créé précédemment.

   ```
   #!/usr/bin/env bash
   
   certnum=$(grep -c BEGIN <(cat $1))
   
   cnt=0
   temp_cert=""
   while read line
   do
   if [ -n "$temp_cert" -a "$line" == "-----BEGIN CERTIFICATE-----" ]
   then
   cnt=$(expr $cnt + 1)
   printf "\rImporting certificate # $cnt of $certnum"
   orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null
   temp_cert=""
   fi
   temp_cert+="$line"$'\n'
   done < <(cat $1)
   
   cnt=$(expr $cnt + 1)
   printf "\rImporting certificate # $cnt of $certnum"
   orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null
   echo ""
   ```

Une fois que vous avez terminé les étapes précédentes, vous pouvez importer le fichier de portefeuille avec l'appel d'API `ImportCertificate` en spécifiant le paramètre de portefeuille de certificat. Vous pouvez ensuite utiliser le certificat de portefeuille importé lorsque vous sélectionnez `verify-ca` comme mode SSL lors de la création ou de la modification de votre point de terminaison Oracle.

**Note**  
 Les portefeuilles Oracle sont des fichiers binaires. AWS DMS accepte ces fichiers tels quels. 

### Utilisation d'un certificat auto-signé pour Oracle SSL
<a name="CHAP_Security.SSL.Oracle.SelfSigned"></a>

Pour utiliser un certificat auto-signé pour Oracle SSL, procédez comme suit en supposant que le mot de passe du portefeuille Oracle est `oracle123`.

**Pour utiliser un certificat auto-signé pour Oracle SSL avec AWS DMS**

1. Créez un répertoire que vous utiliserez pour travailler avec le certificat auto-signé.

   ```
   mkdir -p /u01/app/oracle/self_signed_cert
   ```

1. Accédez au répertoire que vous avez créé à l'étape précédente.

   ```
   cd /u01/app/oracle/self_signed_cert
   ```

1. Créez une clé racine.

   ```
   openssl genrsa -out self-rootCA.key 2048
   ```

1. Auto-signez un certificat racine à l'aide de la clé racine que vous avez créée à l'étape précédente.

   ```
   openssl req -x509 -new -nodes -key self-rootCA.key 
           -sha256 -days 3650 -out self-rootCA.pem
   ```

   Utilisez les paramètres d’entrée suivants.
   + `Country Name (2 letter code) [XX]`, par exemple : `AU`
   + `State or Province Name (full name) []`, par exemple : `NSW`
   + `Locality Name (e.g., city) [Default City]`, par exemple : `Sydney`
   + `Organization Name (e.g., company) [Default Company Ltd]`, par exemple : `AmazonWebService`
   + `Organizational Unit Name (e.g., section) []`, par exemple : `DBeng`
   + `Common Name (e.g., your name or your server's hostname) []`, par exemple : `aws`
   + `Email Address []`, par exemple : abcd.efgh@amazonwebservice.com

1. Créez un répertoire de portefeuille Oracle pour la base de données Oracle.

   ```
   mkdir -p /u01/app/oracle/wallet
   ```

1. Créez un nouveau portefeuille Oracle.

   ```
   orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local
   ```

1. Ajoutez le certificat racine au portefeuille Oracle.

   ```
   orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -trusted_cert 
   -cert /u01/app/oracle/self_signed_cert/self-rootCA.pem
   ```

1. Affichez le contenu du portefeuille Oracle. La liste doit inclure le certificat racine. 

   ```
   orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
   ```

   Par exemple, ce paramètre peut s’afficher comme suit.

   ```
   Requested Certificates:
   User Certificates:
   Trusted Certificates:
   Subject:        CN=aws,OU=DBeng,O= AmazonWebService,L=Sydney,ST=NSW,C=AU
   ```

1. Générez la demande de signature de certificat (CSR) à l'aide de l'utilitaire ORAPKI.

   ```
   orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 
   -dn "CN=aws" -keysize 2048 -sign_alg sha256
   ```

1. Exécutez la commande suivante.

   ```
   openssl pkcs12 -in /u01/app/oracle/wallet/ewallet.p12 -nodes -out /u01/app/oracle/wallet/nonoracle_wallet.pem
   ```

   Ce paramètre a un résultat similaire à ce qui suit.

   ```
   Enter Import Password:
   MAC verified OK
   Warning unsupported bag type: secretBag
   ```

1. Mettez « dms » comme nom commun.

   ```
   openssl req -new -key /u01/app/oracle/wallet/nonoracle_wallet.pem -out certdms.csr
   ```

   Utilisez les paramètres d’entrée suivants.
   + `Country Name (2 letter code) [XX]`, par exemple : `AU`
   + `State or Province Name (full name) []`, par exemple : `NSW`
   + `Locality Name (e.g., city) [Default City]`, par exemple : `Sydney`
   + `Organization Name (e.g., company) [Default Company Ltd]`, par exemple : `AmazonWebService`
   + `Organizational Unit Name (e.g., section) []`, par exemple : `aws`
   + `Common Name (e.g., your name or your server's hostname) []`, par exemple : `aws`
   + `Email Address []`, par exemple : abcd.efgh@amazonwebservice.com

   Assurez-vous qu’il est différent de l’étape 4. Pour ce faire, remplacez par exemple le nom de l’unité organisationnelle par un autre nom, comme indiqué.

   Entrez les attributs supplémentaires suivants à envoyer avec votre demande de certificat.
   + `A challenge password []`, par exemple : `oracle123`
   + `An optional company name []`, par exemple : `aws`

1. Obtenez la signature de certificat.

   ```
   openssl req -noout -text -in certdms.csr | grep -i signature
   ```

   La clé de signature de ce message est `sha256WithRSAEncryption`.

1. Exécutez la commande suivante pour générer le fichier de certificat (`.crt`).

   ```
   openssl x509 -req -in certdms.csr -CA self-rootCA.pem -CAkey self-rootCA.key 
   -CAcreateserial -out certdms.crt -days 365 -sha256
   ```

   Ce paramètre a un résultat similaire à ce qui suit.

   ```
   Signature ok
   subject=/C=AU/ST=NSW/L=Sydney/O=awsweb/OU=DBeng/CN=aws
   Getting CA Private Key
   ```

1. Ajoutez le certificat au portefeuille.

   ```
   orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt
   ```

1. Consultez le portefeuille. Il doit comporter deux entrées. Consultez le code suivant.

   ```
   orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
   ```

1. Configurez le fichier `sqlnet.ora` (`$ORACLE_HOME/network/admin/sqlnet.ora`).

   ```
   WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /u01/app/oracle/wallet/)
        )
      ) 
   
   SQLNET.AUTHENTICATION_SERVICES = (NONE)
   SSL_VERSION = 1.0
   SSL_CLIENT_AUTHENTICATION = FALSE
   SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)
   ```

1. Arrêtez l'écouteur Oracle.

   ```
   lsnrctl stop
   ```

1. Ajoutez des entrées pour SSL dans le fichier `listener.ora` (`$ORACLE_HOME/network/admin/listener.ora`).

   ```
   SSL_CLIENT_AUTHENTICATION = FALSE
   WALLET_LOCATION =
     (SOURCE =
       (METHOD = FILE)
       (METHOD_DATA =
         (DIRECTORY = /u01/app/oracle/wallet/)
       )
     )
   
   SID_LIST_LISTENER =
    (SID_LIST =
     (SID_DESC =
      (GLOBAL_DBNAME = SID)
      (ORACLE_HOME = ORACLE_HOME)
      (SID_NAME = SID)
     )
    )
   
   LISTENER =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
         (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
         (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
       )
     )
   ```

1. Configurez le fichier `tnsnames.ora` (`$ORACLE_HOME/network/admin/tnsnames.ora`).

   ```
   <SID>=
   (DESCRIPTION=
           (ADDRESS_LIST = 
                   (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
           )
           (CONNECT_DATA =
                   (SERVER = DEDICATED)
                   (SERVICE_NAME = <SID>)
           )
   )
   
   <SID>_ssl=
   (DESCRIPTION=
           (ADDRESS_LIST = 
                   (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
           )
           (CONNECT_DATA =
                   (SERVER = DEDICATED)
                   (SERVICE_NAME = <SID>)
           )
   )
   ```

1. Redémarrez l'écouteur Oracle.

   ```
   lsnrctl start
   ```

1. Affichez le statut de l'écouteur Oracle.

   ```
   lsnrctl status
   ```

1. Testez la connexion SSL à la base de données à partir de localhost à l'aide de sqlplus et de l'entrée SSL tnsnames.

   ```
   sqlplus -L ORACLE_USER@SID_ssl
   ```

1. Vérifiez que la connexion a été établie à l'aide de SSL.

   ```
   SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL;
   
   SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
   --------------------------------------------------------------------------------
   tcps
   ```

1. Accédez au répertoire contenant le certificat auto-signé.

   ```
   cd /u01/app/oracle/self_signed_cert
   ```

1. Créez un nouveau portefeuille client Oracle AWS DMS à utiliser.

   ```
   orapki wallet create -wallet ./ -auto_login_only
   ```

1. Ajoutez le certificat racine auto-signé au portefeuille Oracle.

   ```
   orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only
   ```

1. Répertoriez le contenu du portefeuille Oracle AWS DMS à utiliser. La liste doit inclure le certificat racine auto-signé.

   ```
   orapki wallet display -wallet ./
   ```

   Ce paramètre a un résultat similaire à ce qui suit.

   ```
   Trusted Certificates:
   Subject:        CN=aws,OU=DBeng,O=AmazonWebService,L=Sydney,ST=NSW,C=AU
   ```

1. Téléchargez le portefeuille Oracle que vous venez de créer sur AWS DMS.

## Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.Encryption"></a>

Dans le tableau suivant, vous trouverez les méthodes de chiffrement transparent des données (TDE) prises AWS DMS en charge lors de l'utilisation d'une base de données source Oracle. 


| Méthode d'accès aux journaux de journalisation | Espace disque logique TDE | Colonne TDE | 
| --- | --- | --- | 
| Oracle LogMiner | Oui | Oui | 
| Binary Reader | Oui | Oui | 

AWS DMS prend en charge Oracle TDE lorsque vous utilisez Binary Reader, à la fois au niveau des colonnes et au niveau de l'espace disque logique. Pour utiliser le chiffrement TDE avec AWS DMS, identifiez d'abord l'emplacement du portefeuille Oracle où sont stockés la clé de chiffrement TDE et le mot de passe TDE. Identifiez ensuite la clé de chiffrement TDE et le mot de passe appropriés pour le point de terminaison source Oracle.

**Pour identifier et spécifier la clé de chiffrement et le mot de passe pour le chiffrement TDE**

1. Exécutez la requête suivante pour trouver le portefeuille de chiffrement Oracle sur l’hôte de base de données Oracle.

   ```
   SQL> SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET;
   
   WRL_PARAMETER
   --------------------------------------------------------------------------------
   /u01/oracle/product/12.2.0/dbhome_1/data/wallet/
   ```

   Dans cet exemple, l’emplacement du portefeuille est `/u01/oracle/product/12.2.0/dbhome_1/data/wallet/`.

1. Obtenez l'ID de clé principale pour une source non CDB ou CDB comme suit :

   1. Pour une source non CDB, exécutez la requête suivante pour récupérer l'ID de la clé de chiffrement principale :

      ```
      SQL>  select rownum, key_id, activation_time from v$encryption_keys;
      
      ROWNUM KEY_ID                                                 ACTIVATION_TIME
      ------ ------------------------------------------------------ ---------------
           1 AeKask0XZU+NvysflCYBEVwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA   04-SEP-24 10.20.56.605200 PM +00:00
           2 AV7WU9uhoU8rv8daE/HNnSwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA   10-AUG-21 07.52.03.966362 PM +00:00
           3 AckpoJ/f+k8xvzJ+gSuoVH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA   14-SEP-20 09.26.29.048870 PM +00:00
      ```

      Le temps d'activation est utile si vous prévoyez de démarrer le CDC à un moment donné dans le passé. Par exemple, en utilisant les résultats ci-dessus, vous pouvez démarrer le CDC à partir d'un moment donné entre le 10 août et le 21 août à 07h52 ,03 et le 14 septembre 20 à 21h26,29 en utilisant l'ID de clé principale dans ROWNUM 2. Lorsque la tâche atteint le point de terminaison généré le 14 septembre 20 à 21h26.29 ou après cette date, elle échoue. Vous devez modifier le point de terminaison source, fournir l'ID de la clé principale dans ROWNUM 3, puis reprendre la tâche.

   1. Pour la source CDB, DMS nécessite la clé de chiffrement principale CDB\$1ROOT. Connectez-vous à CDB\$1ROOT et exécutez la requête suivante :

      ```
      SQL> select rownum, key_id, activation_time from v$encryption_keys where con_id = 1;
      
      ROWNUM KEY_ID                                               ACTIVATION_TIME
      ------ ---------------------------------------------------- -----------------------------------
           1 Aa2E/Vwb5U+zv5hCncS5ErMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 29-AUG-24 12.51.19.699060 AM +00:00
      ```

1. À partir de la ligne de commande, répertoriez les entrées du portefeuille de chiffrement sur l’hôte de base de données Oracle source.

   ```
   $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -list
   Oracle Secret Store entries:
   ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ORACLE.SECURITY.DB.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY
   ORACLE.SECURITY.ID.ENCRYPTION.
   ORACLE.SECURITY.KB.ENCRYPTION.
   ORACLE.SECURITY.KM.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ```

   Recherchez l’entrée contenant l’ID de clé principale que vous avez trouvé à l’étape 2 (`AWGDC9glSk8Xv+3bVveiVSg`). Cette entrée est le nom de la clé de chiffrement TDE.

1. Consultez les détails de l’entrée que vous avez trouvés à l’étape précédente.

   ```
   $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   Oracle Secret Store Tool : Version 12.2.0.1.0
   Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.
   Enter wallet password:
   ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA = AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

   Entrez le mot de passe du portefeuille pour voir le résultat.

   Ici, la valeur à droite de `'='` est le mot de passe TDE.

1. Spécifiez le nom de la clé de chiffrement TDE pour le point de terminaison source Oracle en définissant l’attribut de connexion supplémentaire `securityDbEncryptionName`.

   ```
   securityDbEncryptionName=ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ```

1. Indiquez le mot de passe TDE associé à cette clé sur la console dans le champ **Mot de passe** de la source Oracle. Utilisez l’ordre suivant pour mettre en forme les valeurs de mot de passe séparées par des virgules, qui se terminent par la valeur du mot de passe TDE.

   ```
   Oracle_db_password,ASM_Password,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

   Spécifiez les valeurs de mot de passe dans cet ordre quelle que soit la configuration de votre base de données Oracle. Par exemple, si vous utilisez TDE, mais que la base de données Oracle n’utilise pas ASM, spécifiez les valeurs de mot de passe dans l’ordre suivant séparé par des virgules.

   ```
   Oracle_db_password,,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

Si les informations d'identification TDE que vous spécifiez sont incorrectes, la tâche de AWS DMS migration n'échoue pas. Toutefois, la tâche ne lit pas et n'applique pas non plus les modifications de réplication en cours à la base de données cible. Après avoir démarré la tâche, surveillez les **Statistiques de table** sur la page de la tâche de migration de la console pour vous assurer que les modifications sont répliquées.

Si un administrateur de base de données modifie les valeurs d’informations d’identification TDE pour la base de données Oracle pendant l’exécution de la tâche, celle-ci échoue. Le message d’erreur contient le nouveau nom de clé de chiffrement TDE. Pour spécifier de nouvelles valeurs et redémarrer la tâche, procédez comme suit.

**Important**  
Vous ne pouvez pas manipuler un portefeuille TDE créé dans un emplacement Oracle Automatic Storage Management (ASM), car les commandes au niveau du système d’exploitation telles que `cp`, `mv`, `orapki` et `mkstore` corrompent les fichiers du portefeuille stockés dans un emplacement ASM. Cette restriction est spécifique aux fichiers de portefeuille TDE stockés dans un emplacement ASM uniquement, mais pas aux fichiers de portefeuille TDE stockés dans un répertoire local du système d’exploitation.  
Pour manipuler un portefeuille TDE stocké dans ASM à l’aide de commandes au niveau du système d’exploitation, créez un magasin de clés local et fusionnez-le avec le magasin de clés ASM, comme suit :   
Créez un magasin de clés local.  

   ```
   ADMINISTER KEY MANAGEMENT create keystore file system wallet location identified by wallet password;
   ```
Fusionnez le magasin de clés ASM avec le magasin de clés local.  

   ```
   ADMINISTER KEY MANAGEMENT merge keystore ASM wallet location identified by wallet password into existing keystore file system wallet location identified by wallet password with backup;
   ```
Ensuite, pour répertorier les entrées du portefeuille de chiffrement et le mot de passe TDE, exécutez les étapes 3 et 4 sur le magasin de clés local.

## Méthodes de compression prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.Compression"></a>

Dans le tableau suivant, vous trouverez les méthodes de compression prises AWS DMS en charge lors de l'utilisation d'une base de données source Oracle. Comme le montre le tableau, la prise en charge de la compression dépend à la fois de la version de votre base de données Oracle et de la configuration de DMS pour utiliser Oracle LogMiner pour accéder aux journaux de journalisation.


| Version | Base | OLTP |  HCC (à partir d’Oracle 11g R2 ou ultérieur)  | Autres | 
| --- | --- | --- | --- | --- | 
| Oracle 10 | Non | N/A | N/A | Non | 
| Oracle 11 ou version ultérieure — Oracle LogMiner | Oui | Oui | Oui  | Oui — Toutes les méthodes de compression prises en charge par Oracle LogMiner. | 
| Oracle 11 ou version ultérieure : Binary Reader | Oui | Oui | Oui : pour plus d’informations, consultez la remarque suivante. | Oui | 

**Note**  
Lorsque le point de terminaison source Oracle est configuré pour utiliser Binary Reader, le niveau Query Low de la méthode de compression HCC est pris en charge uniquement pour les tâches à pleine charge.

## Réplication de tables imbriquées à l'aide d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.NestedTables"></a>

AWS DMS prend en charge la réplication des tables Oracle contenant des colonnes qui sont des tables imbriquées ou des types définis. Pour activer cette fonctionnalité, ajoutez le paramètre d’attribut de connexion supplémentaire suivant au point de terminaison source Oracle.

```
allowSelectNestedTables=true;
```

AWS DMS crée les tables cibles à partir des tables imbriquées Oracle en tant que tables parent et enfant normales sur la cible sans contrainte unique. Pour accéder aux données correctes sur la cible, joignez les tables parent et enfant. Pour ce faire, créez d'abord manuellement un index non unique sur la colonne `NESTED_TABLE_ID` de la table enfant cible. Vous pouvez ensuite utiliser la colonne `NESTED_TABLE_ID` dans la clause de jointure `ON` avec la colonne parent qui correspond au nom de la table enfant. En outre, la création d'un tel index améliore les performances lorsque les données de la table enfant cible sont mises à jour ou supprimées par AWS DMS. Pour obtenir un exemple, consultez [Exemple de jointure pour les tables parent et enfant sur la cible](#CHAP_Source.Oracle.NestedTables.JoinExample).

Nous vous recommandons de configurer la tâche pour qu'elle s'arrête une fois la charge complète terminée. Ensuite, créez ces index non uniques pour toutes les tables enfants répliquées sur la cible et reprenez la tâche.

Si une table imbriquée capturée est ajoutée à une table parent existante (capturée ou non capturée), elle AWS DMS est gérée correctement. Toutefois, l'index non unique de la table cible correspondante n'est pas créé. Dans ce cas, si la table enfant cible devient extrêmement volumineuse, les performances peuvent être affectées. Dans ce cas, nous vous recommandons d'arrêter la tâche, de créer l'index, puis de reprendre la tâche.

Une fois les tables imbriquées répliquées vers la cible, faites en sorte que l'administrateur de base de données exécute une jointure sur les tables parent et enfant correspondantes pour aplatir les données.

### Conditions préalables à la réplication des tables imbriquées Oracle en tant que source
<a name="CHAP_Source.Oracle.NestedTables.Prerequisites"></a>

Assurez-vous de répliquer les tables parentes pour toutes les tables imbriquées répliquées. Incluez à la fois les tables parents (les tables contenant la colonne de table imbriquée) et les tables enfants (c'est-à-dire imbriquées) dans les AWS DMS mappages de tables.

### Types de tables imbriquées Oracle pris en charge en tant que source
<a name="CHAP_Source.Oracle.NestedTables.Types"></a>

AWS DMS prend en charge les types de tables imbriquées Oracle suivants en tant que source :
+ Type de données
+ Objet défini par l'utilisateur

### Limites de la AWS DMS prise en charge des tables imbriquées Oracle en tant que source
<a name="CHAP_Source.Oracle.NestedTables.Limitations"></a>

AWS DMS présente les limites suivantes quant à sa prise en charge des tables imbriquées Oracle en tant que source :
+ AWS DMS ne prend en charge qu'un seul niveau d'imbrication de tables.
+ AWS DMS le mappage des tables ne vérifie pas que la ou les tables parent et enfant sont sélectionnées pour la réplication. Autrement dit, il est possible de sélectionner une table parent sans enfant ou une table enfant sans parent.

### Comment AWS DMS réplique-t-il les tables imbriquées Oracle en tant que source
<a name="CHAP_Source.Oracle.NestedTables.HowReplicated"></a>

AWS DMS réplique les tables parentes et imbriquées vers la cible comme suit :
+ AWS DMS crée la table parent identique à la source. Il définit ensuite la colonne imbriquée dans le parent comme `RAW(16)` et inclut une référence aux tables imbriquées du parent dans sa colonne `NESTED_TABLE_ID`.
+ AWS DMS crée la table enfant identique à la source imbriquée, mais avec une colonne supplémentaire nommée`NESTED_TABLE_ID`. Cette colonne a le même type et la même valeur que la colonne imbriquée parent correspondante et a la même signification.

### Exemple de jointure pour les tables parent et enfant sur la cible
<a name="CHAP_Source.Oracle.NestedTables.JoinExample"></a>

Pour aplatir la table parent, exécutez une jointure entre les tables parent et enfant, comme illustré dans l'exemple suivant :

1. Créez la table `Type`.

   ```
   CREATE OR REPLACE TYPE NESTED_TEST_T AS TABLE OF VARCHAR(50);
   ```

1. Créez la table parent avec une colonne de type `NESTED_TEST_T`, tel que défini précédemment.

   ```
   CREATE TABLE NESTED_PARENT_TEST (ID NUMBER(10,0) PRIMARY KEY, NAME NESTED_TEST_T) NESTED TABLE NAME STORE AS NAME_KEY;
   ```

1. Aplatissez la table `NESTED_PARENT_TEST` à l'aide d'une jointure avec la table `NAME_KEY` enfant où `CHILD.NESTED_TABLE_ID` correspond à `PARENT.NAME`.

   ```
   SELECT … FROM NESTED_PARENT_TEST PARENT, NAME_KEY CHILD WHERE CHILD.NESTED_
   TABLE_ID = PARENT.NAME;
   ```

## Stockage de REDO sur Oracle ASM lors de l'utilisation d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.REDOonASM"></a>

Pour les sources Oracle à forte génération de REDO, le stockage de REDO sur Oracle ASM peut améliorer les performances, en particulier dans une configuration RAC, car vous pouvez configurer DMS pour distribuer les lectures ASM REDO sur tous les nœuds ASM.

Pour utiliser cette configuration, utilisez l’attribut de connexion `asmServer`. Par exemple, la chaîne de connexion suivante distribue les lectures DMS REDO sur 3 nœuds ASM :

```
asmServer=(DESCRIPTION=(CONNECT_TIMEOUT=8)(ENABLE=BROKEN)(LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node1_ip_address)(PORT=asm_node1_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node2_ip_address)(PORT=asm_node2_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node3_ip_address)(PORT=asm_node3_port_number)))
(CONNECT_DATA=(SERVICE_NAME=+ASM)))
```

Lorsque vous utilisez NFS pour stocker Oracle REDO, il est important de vous assurer que les correctifs client DNFS (Direct NFS) appropriés sont appliqués, en particulier les correctifs qui corrigent le bogue Oracle 25224242. Pour plus d’informations, consultez la publication Oracle suivante concernant les correctifs liés au client Direct NFS, intitulée [Recommended Patches for Direct NFS Client](https://support.oracle.com/knowledge/Oracle Cloud/1495104_1.html). 

En outre, pour améliorer les performances de lecture NFS, nous vous recommandons d’augmenter la valeur de `rsize` et de `wsize` dans `fstab` pour le volume NFS, comme indiqué dans l’exemple suivant.

```
NAS_name_here:/ora_DATA1_archive /u09/oradata/DATA1 nfs rw,bg,hard,nointr,tcp,nfsvers=3,_netdev,
timeo=600,rsize=262144,wsize=262144
```

Ajustez également la valeur de `tcp-max-xfer-size` comme suit :

```
vserver nfs modify -vserver vserver -tcp-max-xfer-size 262144
```

## Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS
<a name="CHAP_Source.Oracle.ConnectionAttrib"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source Oracle comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--oracle-settings '{"EndpointSetting": "value", ...}'` JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec Oracle en tant que source sont indiqués dans le tableau suivant.


| Nom | Description | 
| --- | --- | 
| AccessAlternateDirectly |  Définissez cet attribut sur false pour utiliser Binary Reader afin de capturer les données de modification pour Amazon RDS for Oracle en tant que source. Cette opération indique à l'instance DMS qu'elle ne doit pas accéder aux journaux redo via un remplacement de préfixe de chemin spécifié en utilisant un accès direct aux fichiers. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valeur par défaut : true  Valeurs valides : true/false Exemple : `--oracle-settings '{"AccessAlternateDirectly": false}'`  | 
|  `AdditionalArchivedLogDestId`  |  Définissez cet attribut avec `ArchivedLogDestId` dans une configuration principale/de secours. Cet attribut est utile lors d’un basculement lorsqu’une base de données Oracle Data Guard est utilisée en tant que source. Dans ce cas, vous AWS DMS devez savoir de quelle destination obtenir les journaux de restauration des archives pour lire les modifications. En effet, après le basculement, l’instance précédemment principale est désormais une instance de secours. Bien qu'il AWS DMS supporte l'utilisation de l'`RESETLOGS`option Oracle pour ouvrir la base de données, ne l'utilisez jamais `RESETLOGS` sauf si cela est nécessaire. Pour plus d’informations sur `RESETLOGS`, consultez [RMAN Data Repair Concepts](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-data-repair-concepts.html#GUID-1805CCF7-4AF2-482D-B65A-998192F89C2B) dans le *Guide de l’utilisateur Oracle® Database Backup and Recovery*. Valeurs valides : ID de destination d’archive Exemple : `--oracle-settings '{"AdditionalArchivedLogDestId": 2}'`  | 
|  `AddSupplementalLogging`  |  Définissez cet attribut pour configurer la journalisation supplémentaire au niveau de la table pour la base de données Oracle. Cet attribut active l’une des options suivantes sur toutes les tables sélectionnées pour une tâche de migration, en fonction des métadonnées des tables : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.Oracle.html) Valeur par défaut : false  Valeurs valides : true/false  Exemple : `--oracle-settings '{"AddSupplementalLogging": false}'`  Si vous utilisez cette option, vous devez encore activer la journalisation supplémentaire au niveau de la base de données, comme indiqué précédemment.    | 
|  `AllowSelectNestedTables`  |  Définissez cet attribut sur true pour activer la réplication des tables Oracle contenant des colonnes imbriquées ou des types définis. Pour de plus amples informations, veuillez consulter [Réplication de tables imbriquées à l'aide d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.NestedTables). Valeur par défaut : false  Valeurs valides : true/false Exemple : `--oracle-settings '{"AllowSelectNestedTables": true}'`  | 
|  `ArchivedLogDestId`  |  Spécifie l'ID de la destination des journaux redo archivés. Cette valeur doit être identique à un des nombres de la colonne dest\$1id de la vue v\$1archived\$1log. Si vous travaillez avec une destination de journal redo supplémentaire, nous vous recommandons d’utiliser l’attribut `AdditionalArchivedLogDestId` pour spécifier l’ID de destination supplémentaire. Cela améliore les performances en garantissant l'accès aux journaux appropriés dès le départ.  Valeur par défaut : 1 Valeurs valides : nombre  Exemple : `--oracle-settings '{"ArchivedLogDestId": 1}'`  | 
|  `ArchivedLogsOnly`  |  Lorsque ce champ est défini sur Y, il accède AWS DMS uniquement aux journaux de journalisation archivés. Si les journaux de restauration archivés sont stockés uniquement sur Oracle ASM, le compte AWS DMS utilisateur doit disposer de privilèges ASM.  Valeur par défaut : N  Valeurs valides : Y/N  Exemple : `--oracle-settings '{"ArchivedLogsOnly": Y}'`  | 
|  `asmUsePLSQLArray` (ECA uniquement)  |  Utilisez cet attribut de connexion supplémentaire (ECA) lors de la capture des modifications de source avec BinaryReader. Ce paramètre permet à DMS de mettre en mémoire tampon 50 lectures au niveau ASM par thread de lecture unique tout en contrôlant le nombre de threads à l’aide de l’attribut `parallelASMReadThreads`. Lorsque vous définissez cet attribut, le lecteur AWS DMS binaire utilise un PL/SQL bloc anonyme pour capturer les données de restauration et les renvoyer à l'instance de réplication sous forme de grande mémoire tampon. Cela réduit le nombre d’allers retours jusqu’à la source. Cela peut améliorer de manière significative les performances de capture de source, mais cela entraîne une consommation de mémoire PGA plus élevée sur l’instance ASM. Des problèmes de stabilité peuvent survenir si la mémoire cible n’est pas suffisante. Vous pouvez utiliser la formule suivante pour estimer l’utilisation totale de la mémoire PGA sur l’instance ASM par tâche DMS : `number_of_redo_threads * parallelASMReadThreads * 7 MB` Valeur par défaut : false Valeurs valides : true/false Exemple d’ECA : `asmUsePLSQLArray=true;`  | 
|  `ConvertTimestampWithZoneToUTC`  |  Définissez cet attribut sur `true` pour convertir la valeur d’horodatage des colonnes « TIMESTAMP WITH TIME ZONE » et « TIMESTAMP WITH LOCAL TIME ZONE » au format UTC. Par défaut, la valeur de cet attribut est « false » et les données seront répliquées en utilisant le fuseau horaire de la base de données source. Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"ConvertTimestampWithZoneToUTC": true}'`  | 
|  `EnableHomogenousPartitionOps`  |  Définissez cet attribut sur `true` pour permettre la réplication des opérations DDL de partition et de sous-partition Oracle pour une migration Oracle *homogène*. Notez que cette fonctionnalité et cette amélioration ont été introduites dans la AWS DMS version 3.4.7. Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"EnableHomogenousPartitionOps": true}'`  | 
|  `EnableHomogenousTablespace`  |  Définissez cet attribut pour activer la réplication homogène d'un espace de table et créer des tables ou des index existants sous le même espace de table sur la cible. Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"EnableHomogenousTablespace": true}'`  | 
|  `EscapeCharacter`  |  Définissez cet attribut sur un caractère d’échappement. Ce caractère d’échappement vous permet de faire en sorte qu’un caractère générique unique se comporte comme un caractère normal dans les expressions de mappage de table. Pour de plus amples informations, veuillez consulter [Caractères génériques dans le mappage de table](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Wildcards.md). Valeur par défaut : Null  Valeurs valides : tout caractère autre qu’un caractère générique Exemple : `--oracle-settings '{"EscapeCharacter": "#"}'` Vous pouvez uniquement utiliser `escapeCharacter` pour les noms de table. Il n’exclut pas les caractères des noms de schéma ou de colonne.  | 
|  `ExposeViews`  |  Utilisez cet attribut pour extraire les données d’une vue une fois ; vous ne pouvez pas l’utiliser pour la réplication continue. Lorsque vous extrayez les données d’une vue, la vue est représentée sous la forme d’une table sur le schéma cible. Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"ExposeViews": true}'`  | 
|  `ExtraArchivedLogDestIds`  |  Spécifie IDs une ou plusieurs destinations pour un ou plusieurs journaux de journalisation archivés. Il s' IDs agit des valeurs de la colonne dest\$1id dans la vue v\$1archived\$1log. Utilisez ce paramètre avec l'attribut de connexion ArchivedLogDestId supplémentaire dans une primary-to-single configuration ou une primary-to-multiple-standby configuration. Ce paramètre est utile lors d'un basculement lorsque vous utilisez une base de données Oracle Data Guard comme source. Dans ce cas, il AWS DMS a besoin d'informations sur la destination à partir de laquelle obtenir les journaux de restauration des archives pour lire les modifications. AWS DMS en a besoin car après le basculement, l'instance principale précédente est une instance de secours. Valeurs valides : ID de destination d’archive Exemple : `--oracle-settings '{"ExtraArchivedLogDestIds": 1}'`  | 
|  `FailTasksOnLobTruncation`  |  Lorsque la valeur `true` est définie, cet attribut provoque l'échec d'une tâche si la taille réelle d'une colonne LOB est supérieure à la valeur `LobMaxSize` spécifiée. Si une tâche est définie sur le mode LOB limité et que cette option a pour valeur `true`, la tâche échoue au lieu de tronquer les données LOB. Valeur par défaut : false  Valeurs valides : booléen  Exemple : `--oracle-settings '{"FailTasksOnLobTruncation": true}'`  | 
|  `filterTransactionsOfUser` (ECA uniquement)  |  Utilisez cet attribut de connexion supplémentaire (ECA) pour permettre à DMS d'ignorer les transactions d'un utilisateur spécifié lors de la réplication des données d'Oracle lors de l'utilisation. LogMiner Vous pouvez transmettre des valeurs de nom d’utilisateur séparées par des virgules, mais elles doivent être entièrement en majuscules. Exemple d’ECA : `filterTransactionsOfUser=USERNAME;`  | 
|  `NumberDataTypeScale`  |  Spécifie l'échelle de nombres. Vous pouvez sélectionner une échelle jusqu’à 38, -1 pour FLOAT ou -2 pour VARCHAR. Par défaut, le type de données NUMBER est converti en précision 38, échelle 10. Valeur par défaut : 10  Valeurs valides : -2 à 38 (-2 pour VARCHAR, -1 pour FLOAT) Exemple : `--oracle-settings '{"NumberDataTypeScale": 12}'`  Sélectionnez une combinaison d’échelle de précision, -1 (FLOAT) ou -2 (VARCHAR). DMS prend en charge toutes les combinaisons d’échelle de précision prises en charge par Oracle. Si la précision est supérieure ou égale à 39, sélectionnez -2 (VARCHAR). Le NumberDataTypeScale paramètre de la base de données Oracle est utilisé uniquement pour le type de données NUMBER (sans précision ni définition d'échelle explicites). Vous devez noter qu'une perte de précision peut survenir lorsque ce paramètre est mal configuré.   | 
|  `OpenTransactionWindow`  |   Fournit le délai en minutes pour vérifier l’existence de transactions ouvertes pour une tâche de CDC uniquement. Lorsque vous définissez une valeur supérieure ou égale `OpenTransactionWindow` à 1, DMS convertit les valeurs `SCN_TO_TIMESTAMP` SCN en valeurs d'horodatage. En raison des limites de la base de données Oracle, si vous spécifiez un SCN trop ancien comme point de départ du CDC, le SCN\$1TO\$1TIMESTAMP échouera avec une `ORA-08181` erreur et vous ne pourrez pas démarrer de tâches uniquement relatives au CDC. Valeur par défaut : 0  Valeurs valides : entier compris entre 0 et 240 Exemple : `openTransactionWindow=15;`  | 
| OraclePathPrefix | Définissez cet attribut de chaîne sur la valeur requise afin d'utiliser Binary Reader pour capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette valeur spécifie la racine Oracle utilisée par défaut pour accéder aux journaux redo. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valeur par défaut : none Valeur valide :/rdsdbdata/db/ORCL\$1A/ Exemple : `--oracle-settings '{"OraclePathPrefix": "/rdsdbdata/db/ORCL_A/"}'`  | 
| ParallelASMReadThreads |  Définissez cet attribut pour modifier le nombre de threads configurés par DMS pour effectuer une capture des données de modification (CDC) à l’aide d’Oracle Automatic Storage Management (ASM). Vous pouvez spécifier un nombre entier compris entre 2 (par défaut) et 8 (maximum). Utilisez cet attribut avec l'attribut `ReadAheadBlocks`. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valeur par défaut : 2  Valeurs valides : un nombre entier compris entre 2 à 8 Exemple : `--oracle-settings '{"ParallelASMReadThreads": 6;}'`  | 
| ReadAheadBlocks |  Définissez cet attribut pour modifier le nombre de blocs de lecture anticipée configurés par DMS pour effectuer une CDC à l’aide d’Oracle Automatic Storage Management (ASM) et d’un stockage NAS non ASM. Vous pouvez spécifier une valeur entière comprise entre 1 000 (valeur par défaut) et 2 000 000 (valeur maximale). Utilisez cet attribut avec l'attribut `ParallelASMReadThreads`. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valeur par défaut : 1000  Valeurs valides : un entier compris entre 1 000 et 2 000 000 Exemple : `--oracle-settings '{"ReadAheadBlocks": 150000}'`  | 
|  `ReadTableSpaceName`  |  Lorsque la valeur `true` est définie, cet attribut prend en charge la réplication d'espace de table. Valeur par défaut : false  Valeurs valides : booléen  Exemple : `--oracle-settings '{"ReadTableSpaceName": true}'`  | 
| ReplacePathPrefix | Définissez cet attribut sur true (vrai) pour utiliser Binary Reader afin de capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Ce paramètre indique à l'instance DMS qu'elle doit remplacer la racine Oracle par défaut par le paramètre UsePathPrefix pour accéder aux journaux redo. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"ReplacePathPrefix": true}'`  | 
|  `RetryInterval`  |  Spécifie le nombre de secondes que le système attend avant de renvoyer une requête.  Valeur par défaut : 5  Valeurs valides : nombres à partir de 1  Exemple : `--oracle-settings '{"RetryInterval": 6}'`  | 
|  `SecurityDbEncryptionName`  |  Spécifie le nom d'une clé utilisée pour le chiffrement transparent des données (TDE) des colonnes et de l'espace disque logique dans la base de données source Oracle. Pour de plus amples informations sur la définition de cet attribut et de son mot de passe associé sur le point de terminaison source Oracle, veuillez consulter [Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.Encryption). Valeur par défaut : ""  Valeurs valides : string  Exemple : `--oracle-settings '{"SecurityDbEncryptionName": "ORACLE.SECURITY.DB.ENCRYPTION.Adg8m2dhkU/0v/m5QUaaNJEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}'`  | 
|  `SpatialSdo2GeoJsonFunctionName`  |  Pour les sources Oracle version 12.1 ou antérieures migrant vers des cibles PostgreSQL, utilisez cet attribut pour convertir SDO\$1GEOMETRY au format GEOJSON. Par défaut, AWS DMS appelle la fonction `SDO2GEOJSON` personnalisée qui doit être présente et accessible à l' AWS DMS utilisateur. Vous pouvez également créer votre propre fonction personnalisée qui imite le fonctionnement de `SDOGEOJSON` et définir `SpatialSdo2GeoJsonFunctionName` pour l'appeler à la place.  Valeur par défaut : SDO2 GEOJSON Valeurs valides : string  Exemple : `--oracle-settings '{"SpatialSdo2GeoJsonFunctionName": "myCustomSDO2GEOJSONFunction"}'`  | 
|  `StandbyDelayTime`  |  Utilisez cet attribut pour spécifier une durée en minutes pour le retard de synchronisation de l'instance de secours. Si la source est une base de données de secours Active Data Guard, utilisez cet attribut pour spécifier le décalage entre les bases de données principale et de secours. Dans AWS DMS, vous pouvez créer une tâche Oracle CDC qui utilise une instance de secours Active Data Guard comme source pour répliquer les modifications en cours. Cela vous permet de ne plus avoir besoin de vous connecter à une base de données active pouvant être en production. Valeur par défaut : 0  Valeurs valides : nombre  Exemple : `--oracle-settings '{"StandbyDelayTime": 1}'` **Remarque :** lorsque vous utilisez DMS 3.4.6, 3.4.7 ou ultérieur, l’utilisation de ce paramètre de connexion est facultative. Dans les dernières versions de DMS 3.4.6 et 3.4.7, `dms_user` devrait avoir l’autorisation `select` sur `V_$DATAGUARD_STATS`, ce qui permet à DMS de calculer le délai de veille.  | 
| UseAlternateFolderForOnline | Définissez cet attribut sur true (vrai) pour utiliser Binary Reader afin de capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette opération indique à l'instance DMS qu'elle doit utiliser un remplacement de préfixe spécifié pour accéder à tous les journaux redo en ligne. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valeur par défaut : false Valeurs valides : true/false Exemple : `--oracle-settings '{"UseAlternateFolderForOnline": true}'`  | 
| UseBfile |  Définissez cet attribut sur Y pour capturer les données modifiées à l'aide de l'utilitaire Binary Reader. Attribuez la valeur N à `UseLogminerReader` pour définir cet attribut sur Y. Pour utiliser Binary Reader avec Amazon RDS for Oracle en tant que source, définissez des attributs supplémentaires. Pour plus d'informations sur ce paramètre et l'utilisation d'Oracle Automatic Storage Management (ASM), consultez [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). Remarque : lorsque vous définissez cette valeur en tant qu’attribut de connexion supplémentaire (ECA), les valeurs valides sont « Y » et « N ». Lorsque vous définissez cette valeur en tant que paramètre de point de terminaison, les valeurs valides sont `true` et `false`. Valeur par défaut : N  Valeurs valides : Y/N (lors de la définition de cette valeur en tant que paramètre ECA) ; true/false (lors de la définition de cette valeur en tant que paramètre de point de terminaison). Exemple : `--oracle-settings '{"UseBfile": Y}'`  | 
|  `UseLogminerReader`  |  Définissez cet attribut sur Y pour capturer les données de modification à l'aide de l' LogMiner utilitaire (valeur par défaut). Définissez cette option sur N si vous voulez qu' AWS DMS accède aux journaux redo en tant que fichier binaire. Lorsque vous définissez cette option sur N, ajoutez également le paramètre useBfile=Y. Pour plus d’informations sur ce paramètre et sur l’utilisation d’Oracle Automatic Storage Management (ASM), consultez [Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC](#CHAP_Source.Oracle.CDC). Remarque : lorsque vous définissez cette valeur en tant qu’attribut de connexion supplémentaire (ECA), les valeurs valides sont « Y » et « N ». Lorsque vous définissez cette valeur en tant que paramètre de point de terminaison, les valeurs valides sont `true` et `false`. Valeur par défaut : Y  Valeurs valides : Y/N (lors de la définition de cette valeur en tant que paramètre ECA) ; true/false (lors de la définition de cette valeur en tant que paramètre de point de terminaison). Exemple : `--oracle-settings '{"UseLogminerReader": Y}'`  | 
| UsePathPrefix | Définissez cet attribut de chaîne sur la valeur requise afin d'utiliser Binary Reader pour capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette valeur spécifie le préfixe de chemin utilisé pour remplacer la racine Oracle utilisée par défaut pour accéder aux journaux redo. Pour de plus amples informations, veuillez consulter [Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valeur par défaut : none Valeur valide : /rdsdbdata/log/ Exemple : `--oracle-settings '{"UsePathPrefix": "/rdsdbdata/log/"}'`  | 

## Types de données sources pour Oracle
<a name="CHAP_Source.Oracle.DataTypes"></a>

Le point de terminaison Oracle pour AWS DMS prend en charge la plupart des types de données Oracle. Le tableau suivant indique les types de données source Oracle pris en charge lors de l'utilisation AWS DMS et le mappage par défaut aux types de AWS DMS données.

**Note**  
À l’exception des types de données LONG et LONG RAW, lors de la réplication d’une source Oracle vers une cible Oracle (*réplication homogène*), tous les types de données source et cibles seront identiques. Toutefois, le type de données LONG sera mappé aux objets CLOB et le type de données LONG RAW sera mappé aux objets BLOB. 

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Type de données Oracle  |  AWS DMS type de données  | 
| --- | --- | 
|  BINARY\$1FLOAT  |  REAL4  | 
|  BINARY\$1DOUBLE  |  REAL8  | 
|  BINAIRE  |  BYTES  | 
|  FLOAT (P)  |  Si la précision est inférieure ou égale à 24, utilisez REAL4. Si la précision est supérieure à 24, utilisez REAL8.  | 
|  NUMBER (P,S)  |  Lorsque l’échelle est supérieure à 0, utilisez NUMERIC. Lorsque l'échelle est 0 : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.Oracle.html) Lorsque l'échelle est inférieure à 0, utilisez REAL8. | 
|  DATE  |  DATETIME  | 
|  INTERVAL\$1YEAR TO MONTH  |  STRING (avec indication d'intervalle year\$1to\$1month)  | 
|  INTERVAL\$1DAY TO SECOND  |  STRING (avec indication d'intervalle day\$1to\$1second)  | 
|  TIMESTAMP  |  DATETIME  | 
|  TIMESTAMP WITH TIME ZONE  |  STRING (avec indication timestamp\$1with\$1timezone)  | 
|  TIMESTAMP WITH LOCAL TIME ZONE  |  STRING (avec indication timestamp\$1with\$1local\$1timezone)  | 
|  CHAR  |  CHAÎNE  | 
|  VARCHAR2  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.Oracle.html)  | 
|  NCHAR  |  WSTRING  | 
|  NVARCHAR2  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.Oracle.html)  | 
|  RAW  |  BYTES  | 
|  REAL  |  REAL8  | 
|  BLOB  |  BLOB Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données BLOB pour une tâche spécifique. AWS DMS prend en charge les types de données BLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  CLOB  |  CLOB Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données CLOB pour une tâche spécifique. Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  NCLOB  |  NCLOB Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données NCLOB pour une tâche spécifique. Pendant le CDC, AWS DMS prend en charge les types de données NCLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  LONG  |  CLOB Le type de données LONG n'est pas pris en charge en mode d'application optimisé par lots (mode TurboStream CDC). Pour utiliser ce type de données avec AWS DMS, activez l'utilisation de LOBs pour une tâche spécifique. Pendant le CDC ou le chargement complet, AWS DMS prend en charge les types de données LOB uniquement dans les tables dotées d'une clé primaire. De plus, AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONGUES. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes LONG vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONGUES de plus de 64 Ko. Pour plus d'informations sur le support LOB dans AWS DMS, voir [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md)  | 
|  LONG RAW  |  BLOB Le type de données LONG RAW n'est pas pris en charge en mode d'application optimisé par lots (mode TurboStream CDC). Pour utiliser ce type de données avec AWS DMS, activez l'utilisation de LOBs pour une tâche spécifique. Pendant le CDC ou le chargement complet, AWS DMS prend en charge les types de données LOB uniquement dans les tables dotées d'une clé primaire. De plus, AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONG RAW. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes LONG RAW vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONG RAW de plus de 64 Ko. Pour plus d'informations sur le support LOB dans AWS DMS, voir [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md)  | 
|  XMLTYPE  |  CLOB  | 
| SDO\$1GEOMETRY | BLOB (pour une migration Oracle vers Oracle)CLOB (pour une migration Oracle vers PostgreSQL) | 

Les tables Oracle utilisées comme source avec des colonnes des types de données suivants ne sont pas prises en charge et ne peuvent pas être répliquées. La réplication des colonnes avec ces types de données a pour conséquence une colonne nulle.
+ BFILE
+ ROWID
+ REF
+ UROWID
+ Types de données définis par l'utilisateur
+ ANYDATA
+ VARRAY

**Note**  
Les colonnes virtuelles ne sont pas prises en charge.

### Migration de types de données spatiales Oracle
<a name="CHAP_Source.Oracle.DataTypes.Spatial"></a>

Les *données spatiales* identifient les informations de géométrie d'un objet ou d'un emplacement dans l'espace. Dans une base de données Oracle, la description géométrique d'un objet spatial est stockée dans un objet de type SDO\$1GEOMETRY. Dans cet objet, la description géométrique est stockée dans une seule ligne dans une seule colonne d'une table définie par l'utilisateur. 

AWS DMS prend en charge la migration du type Oracle SDO\$1GEOMETRY d'une source Oracle vers une cible Oracle ou PostgreSQL.

Lorsque vous migrez des types de données spatiales Oracle à l'aide de AWS DMS, tenez compte des points suivants :
+ Lors de la migration vers une cible Oracle, assurez-vous de transférer manuellement les entrées USER\$1SDO\$1GEOM\$1METADATA qui incluent des informations de type. 
+ Lors de la migration d'un point de terminaison source Oracle vers un point de terminaison AWS DMS cible PostgreSQL, crée des colonnes cibles. Ces colonnes contiennent des informations sur la géométrie et le type de géographie par défaut avec une dimension 2D et un identificateur de référence spatiale (SRID) égal à zéro (0). Par exemple : `GEOMETRY, 2, 0`.
+ Pour les sources Oracle version 12.1 ou antérieures qui migrent vers des cibles PostgreSQL, convertissez les objets `SDO_GEOMETRY` au format `GEOJSON` à l'aide de la fonction `SDO2GEOJSON` ou de l'attribut de connexion `spatialSdo2GeoJsonFunctionName` supplémentaire. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).
+ AWS DMS prend en charge les migrations de colonnes spatiales Oracle pour le mode LOB complet uniquement. AWS DMS ne prend pas en charge les modes LOB limité ou LOB en ligne. Pour plus d’informations sur le mode LOB, consultez [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md).
+ Comme le mode Full LOB est AWS DMS uniquement compatible avec la migration des colonnes Oracle Spatial, la table des colonnes a besoin d'une clé primaire et d'une clé unique. Si la table ne possède pas de clé primaire ni de clé unique, elle est ignorée lors de la migration.

# Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS
<a name="CHAP_Source.SQLServer"></a>

Migrez les données d'une ou de plusieurs bases de données Microsoft SQL Server à l'aide de AWS DMS. Avec une base de données SQL Server comme source, vous pouvez migrer des données vers une autre base de données SQL Server ou vers l'une des autres bases de données AWS DMS prises en charge. 

Pour plus d'informations sur les versions de SQL Server prises AWS DMS en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md).

La base de données source SQL Server peut être installée sur n'importe quel ordinateur dans votre réseau. Un compte SQL Server avec les privilèges d'accès appropriés à la base de données source pour le type de tâche que vous avez choisi est également nécessaire pour une utilisation avec AWS DMS. Pour de plus amples informations, veuillez consulter [Autorisations pour les tâches SQL Server](#CHAP_Source.SQLServer.Permissions).

AWS DMS prend en charge la migration de données à partir d'instances nommées de SQL Server. Vous pouvez utiliser la notation suivante dans le nom du serveur lorsque vous créez le point de terminaison source.

```
IPAddress\InstanceName
```

Par exemple, voici un nom de serveur correct de point de terminaison source. Ici, la première partie du nom est l'adresse IP du serveur, et la seconde est le nom de l'instance de SQL Server (dans cet exemple, SQLTest).

```
10.0.0.25\SQLTest
```

Obtenez également le numéro de port sur lequel votre instance nommée de SQL Server écoute et utilisez-le pour configurer votre point de terminaison AWS DMS source. 

**Note**  
Le port 1433 est le port par défaut pour Microsoft SQL Server. Mais les ports dynamiques qui changent chaque fois que SQL Server est démarré, et les numéros de port statiques spécifiques utilisés pour se connecter à SQL Server via un pare-feu sont également souvent utilisés. Vous souhaitez donc connaître le numéro de port réel de votre instance nommée de SQL Server lorsque vous créez le point de terminaison AWS DMS source.

Vous pouvez utiliser SSL pour chiffrer les connexions entre votre point de terminaison SQL Server et l'instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison SQL Server, consultez [Utilisation du protocole SSL avec AWS Database Migration Service](CHAP_Security.SSL.md).

Vous pouvez utiliser le CDC pour effectuer une migration continue depuis une base de données SQL Server. Pour plus d'informations sur la configuration de votre base de données SQL Server source pour CDC, consultez[Capture des modifications de données pour une réplication continue à partir de SQL Server](CHAP_Source.SQLServer.CDC.md).

Pour plus de détails sur l'utilisation des bases de données source SQL Server AWS DMS, consultez les sections suivantes.

**Topics**
+ [Limitations relatives à l'utilisation de SQL Server comme source pour AWS DMS](#CHAP_Source.SQLServer.Limitations)
+ [Autorisations pour les tâches SQL Server](#CHAP_Source.SQLServer.Permissions)
+ [Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server](#CHAP_Source.SQLServer.Prerequisites)
+ [Méthodes de compression prises en charge pour SQL Server](#CHAP_Source.SQLServer.Compression)
+ [Utilisation de groupes de AlwaysOn disponibilité SQL Server autogérés](#CHAP_Source.SQLServer.AlwaysOn)
+ [Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib)
+ [Types de données sources pour SQL Server](#CHAP_Source.SQLServer.DataTypes)
+ [Capture des modifications de données pour une réplication continue à partir de SQL Server](CHAP_Source.SQLServer.CDC.md)

## Limitations relatives à l'utilisation de SQL Server comme source pour AWS DMS
<a name="CHAP_Source.SQLServer.Limitations"></a>

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données SQL Server comme source pour AWS DMS :
+ La propriété d'identité d'une colonne n'est pas migrée vers une colonne de base de données cible.
+ Le point de terminaison SQL Server ne prend pas en charge l'utilisation de tables contenant des colonnes éparses.
+ L'authentification Windows n'est pas prise en charge.
+ Les modifications apportées aux champs calculés dans un serveur SQL Server ne sont pas répliquées.
+ Les tables temporelles ne sont pas prises en charge.
+ L'échange de partition SQL Server n'est pas pris en charge.
+ Lorsque vous utilisez les utilitaires WRITETEXT et UPDATETEXT, les événements appliqués à la base de données source AWS DMS ne sont pas capturés.
+ Le modèle de langage de manipulation de données (DML) suivant n’est pas pris en charge. 

  ```
  SELECT * INTO new_table FROM existing_table
  ```
+ Lorsque vous utilisez SQL Server comme source, le chiffrement au niveau des colonnes n'est pas pris en charge.
+ AWS DMS ne prend pas en charge les audits au niveau du serveur sur SQL Server 2008 ou SQL Server 2008 R2 en tant que sources. Cela est dû à un problème connu avec SQL Server 2008 et 2008 R2. Par exemple, l'exécution de la commande suivante AWS DMS entraîne un échec.

  ```
  USE [master]
  GO 
  ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
  GO
  ```
+ Les colonnes de géométrie et de géographie ne sont pas prises en charge en mode lob complet lors de l'utilisation de SQL Server comme source. Utilisez plutôt le mode LOB limité ou définissez le paramètre de tâche `InlineLobMaxSize` pour utiliser le mode LOB en ligne.
+ Lorsque vous utilisez une base de données source Microsoft SQL Server dans une tâche de réplication, les définitions du diffuseur de publication de réplication SQL Server ne sont pas supprimées si vous supprimez la tâche. Un administrateur système Microsoft SQL Server doit supprimer ces définitions de Microsoft SQL Server.
+ La migration des données depuis les non-schema-bound vues et les données liées au schéma est prise en charge uniquement pour les tâches à chargement complet. 
+ La modification de noms de tables à l'aide de sp\$1rename n'est pas prise en charge (par exemple, `sp_rename 'Sales.SalesRegion', 'SalesReg;)`
+ La modification de noms de colonnes à l'aide de sp\$1rename n'est pas prise en charge (par exemple, `sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';`)
+ AWS DMS ne prend pas en charge le traitement des modifications pour définir ou annuler les valeurs par défaut des colonnes (en utilisant la `ALTER COLUMN SET DEFAULT` clause avec `ALTER TABLE` instructions).
+ AWS DMS ne prend pas en charge le traitement des modifications pour définir la nullité des colonnes (en utilisant la `ALTER COLUMN [SET|DROP] NOT NULL` clause avec des `ALTER TABLE` instructions).
+ Avec SQL Server 2012 et SQL Server 2014, lors de l’utilisation de la réplication DMS avec des groupes de disponibilité, la base de données de distribution ne peut pas être placée dans un groupe de disponibilité. SQL 2016 prend en charge le placement de la base de données de distribution dans un groupe de disponibilité, à l'exception des bases de données de distribution utilisées dans les topologies de fusion, bidirectionnelles ou de peer-to-peer réplication.
+ Pour les tables partitionnées, AWS DMS ne prend pas en charge les différents paramètres de compression des données pour chaque partition.
+ Lorsque vous insérez une valeur dans les types de données spatiales SQL Server (GEOGRAPHY et GEOMETRY), vous pouvez ignorer la propriété SRID (Spatial Reference System Identifier) ou spécifier un nombre différent. Lors de la réplication de tables contenant des types de données spatiales, AWS DMS remplace le SRID par le SRID par défaut (0 pour GEOMETRY et 4326 pour GEOGRAPHY).
+ Si votre base de données n'est pas configurée pour MS-REPLICATION ou MS-CDC, vous pouvez toujours capturer des tables dépourvues de clé primaire, mais seuls les événements INSERT/DELETE DML sont capturés. Les événements UPDATE et TRUNCATE TABLE sont ignorés.
+ Les index Columnstore ne sont pas pris en charge.
+ Les tables optimisées pour la mémoire (utilisant OLTP en mémoire) ne sont pas prises en charge.
+ Lors de la réplication d’une table avec une clé primaire composée de plusieurs colonnes, la mise à jour des colonnes de clé primaire pendant le chargement complet n’est pas prise en charge.
+ La durabilité retardée n'est pas prise en charge.
+ Le paramètre de point de terminaison `readBackupOnly=true` (attribut de connexion supplémentaire) ne fonctionne pas sur les instances source RDS for SQL Server en raison de la manière dont RDS effectue les sauvegardes.
+ `EXCLUSIVE_AUTOMATIC_TRUNCATION` ne fonctionne pas sur les instances source Amazon RDS SQL Server, car les utilisateurs de RDS ne sont pas autorisés à exécuter la procédure stockée SQL Server `sp_repldone`.
+ AWS DMS ne capture pas les commandes de troncation.
+ AWS DMS ne prend pas en charge la réplication à partir de bases de données lorsque la restauration accélérée des bases de données (ADR) est activée.
+ AWS DMS ne prend pas en charge la capture d'instructions en langage de définition de données (DDL) et en langage de manipulation de données (DML) au cours d'une seule transaction.
+ AWS DMS ne prend pas en charge la réplication des packages d'applications au niveau des données (DACPAC).
+ Les instructions UPDATE qui impliquent des clés primaires ou des index uniques et qui mettent à jour plusieurs lignes de données peuvent provoquer des conflits lorsque vous appliquez les modifications à la base de données cible. Cela peut se produire, par exemple, lorsque la base de données cible applique des mises à jour sous forme d’instructions INSERT et DELETE au lieu d’une seule instruction UPDATE. Avec le mode d’application optimisé par lots, la table peut être ignorée. Avec le mode d’application transactionnel, l’opération UPDATE peut entraîner des violations de contrainte. Pour éviter ce problème, rechargez la table correspondante. Vous pouvez également rechercher les enregistrements problématiques dans la table de contrôle Application des exceptions (`dmslogs.awsdms_apply_exceptions`) et les modifier manuellement dans la base de données cible. Pour de plus amples informations, veuillez consulter [Paramètres de réglage du traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ AWS DMS ne prend pas en charge la réplication de tables et de schémas dont le nom inclut un caractère spécial de l'ensemble suivant.

  `\\ -- \n \" \b \r ' \t ;` 
+ Le masquage des données n'est pas pris en charge. AWS DMS migre les données masquées sans les masquer.
+ AWS DMS réplique jusqu'à 32 767 tables avec des clés primaires et jusqu'à 1 000 colonnes pour chaque table. Cela est dû au fait que AWS DMS crée un article de réplication SQL Server pour chaque table répliquée, et les articles de réplication de SQL Server présentent ces limites.
+ Lorsque vous utilisez la capture des données de modification (CDC), vous devez définir toutes les colonnes qui constituent un index unique en tant que `NOT NULL`. Si cette exigence n’est pas remplie, l’erreur système SQL Server 22838 se produit. 
+ Vous risquez de perdre des événements si SQL Server archive le journal des transactions actif vers le journal de sauvegarde ou les tronque du journal des transactions actif.

Les limitations suivantes s'appliquent lors de l'accès aux journaux de transactions de sauvegarde :
+ Les sauvegardes chiffrées ne sont pas prises en charge.
+ Les sauvegardes stockées sur une URL ou sur Windows Azure ne sont pas prises en charge.
+ AWS DMS ne prend pas en charge le traitement direct des sauvegardes du journal des transactions au niveau des fichiers à partir de dossiers partagés alternatifs.
+ Pour les sources Cloud SQL Server autres qu'Amazon RDS pour Microsoft SQL Server AWS DMS , prend en charge la réplication continue (CDC) uniquement avec le journal des transactions actif. Vous ne pouvez pas utiliser le journal de sauvegarde avec la CDC. Vous risquez de perdre des événements si SQL Server les archive du journal des transactions actif vers le journal de sauvegarde ou les tronque du journal des transactions actif avant que DMS ne puisse les lire. 
+ Pour les sources Amazon RDS for Microsoft SQL Server AWS DMS , les versions 3.5.2 et antérieures prennent en charge la réplication continue (CDC) uniquement avec le journal des transactions actif, car DMS ne peut pas accéder au journal de sauvegarde avec CDC. Vous risquez de perdre des événements si RDS pour SQL Server les archive du journal des transactions actif vers le journal de sauvegarde, ou les tronque du journal des transactions actif avant que DMS ne puisse les lire. Cette limitation ne s'applique pas aux AWS DMS versions 3.5.3 et supérieures.
+ AWS DMS ne prend pas en charge le proxy CDC pour Amazon RDS pour SQL Server en tant que source.
+ Si la source SQL Server devient indisponible pendant une tâche de chargement complet, AWS DMS il est possible que la tâche soit marquée comme terminée après plusieurs tentatives de reconnexion, même si la migration des données reste incomplète. Dans ce scénario, les tables cibles contiennent uniquement les enregistrements migrés avant la perte de connexion, ce qui peut créer des incohérences de données entre les systèmes source et cible. Pour garantir l'exhaustivité des données, vous devez soit redémarrer entièrement la tâche de chargement complet, soit recharger les tables spécifiques concernées par l'interruption de connexion.

## Autorisations pour les tâches SQL Server
<a name="CHAP_Source.SQLServer.Permissions"></a>

**Topics**
+ [Autorisations pour les tâches de chargement complet uniquement](#CHAP_Source.SQLServer.Permissions.FullLoad)
+ [Autorisations pour les tâches faisant l'objet d'une réplication continue](#CHAP_Source.SQLServer.Permissions.Ongoing)

### Autorisations pour les tâches de chargement complet uniquement
<a name="CHAP_Source.SQLServer.Permissions.FullLoad"></a>

Les autorisations suivantes sont requises pour effectuer des tâches de chargement complet uniquement. Notez qu’ AWS DMS ne crée pas l’identifiant de connexion `dms_user`. Pour plus d'informations sur la création d'un identifiant pour SQL Server, consultez la rubrique [Création d'un utilisateur de base](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-user?view=sql-server-ver16) de données dans *la documentation de Microsoft*.

```
USE db_name;
                
                CREATE USER dms_user FOR LOGIN dms_user; 
                ALTER ROLE [db_datareader] ADD MEMBER dms_user; 
                GRANT VIEW DATABASE STATE to dms_user;
                GRANT VIEW DEFINITION to dms_user;
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;
```

### Autorisations pour les tâches faisant l'objet d'une réplication continue
<a name="CHAP_Source.SQLServer.Permissions.Ongoing"></a>

Les instances SQL Server autogérées peuvent être configurées pour une réplication continue à l'aide de DMS avec ou sans utilisation du `sysadmin` rôle. Pour les instances de SQL Server, où vous ne pouvez pas accorder le `sysadmin` rôle, assurez-vous que l'utilisateur DMS dispose des privilèges décrits ci-dessous.

**Configurer des autorisations pour une réplication continue à partir d'une base de données SQL Server autogérée**

1. Créez un nouveau compte SQL Server avec authentification par mot de passe à l'aide de SQL Server Management Studio (SSMS) ou comme décrit précédemment dans[Autorisations pour les tâches de chargement complet uniquement](#CHAP_Source.SQLServer.Permissions.FullLoad), par exemple,`self_managed_user`.

1. Exécutez les `GRANT` commandes suivantes : 

   ```
   GRANT VIEW SERVER STATE TO self_managed_user;
   
   USE msdb;
       GRANT SELECT ON msdb.dbo.backupset TO self_managed_user;
       GRANT SELECT ON msdb.dbo.backupmediafamily TO self_managed_user;
       GRANT SELECT ON msdb.dbo.backupfile TO self_managed_user;
       
   USE db_name;
       CREATE USER self_managed_user FOR LOGIN self_managed_user;
       ALTER ROLE [db_owner] ADD MEMBER self_managed_user;
       GRANT VIEW DEFINITION to self_managed_user;
   ```

1. Outre les autorisations précédentes, l'utilisateur a besoin de l'une des autorisations suivantes :
   + L'utilisateur doit être membre du rôle de serveur `sysadmin` fixe
   + Configurations et autorisations telles que décrites dans [Configuration de la réplication continue sur une instance SQL Server dans un environnement de groupe de disponibilité : sans le rôle sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.ag) ou[Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.standalone), en fonction de votre configuration source.

#### Configurer des autorisations pour une réplication continue à partir d'une base de données SQL Server dans le cloud
<a name="CHAP_Source.SQLServer.Permissions.Cloud"></a>

Une instance SQL Server hébergée dans le cloud est une instance exécutée sur Amazon RDS pour Microsoft SQL Server, une instance gérée Azure SQL ou toute autre instance SQL Server cloud gérée prise en charge par DMS.

Créez un nouveau compte SQL Server avec authentification par mot de passe à l'aide de SQL Server Management Studio (SSMS) ou comme décrit précédemment dans[Autorisations pour les tâches de chargement complet uniquement](#CHAP_Source.SQLServer.Permissions.FullLoad), par exemple,`rds_user`.

Exécutez les commandes GRANT suivantes.

```
GRANT VIEW SERVER STATE TO rds_user;
```

Pour les sources Amazon RDS for Microsoft SQL Server, la version 3.5.3 et les versions ultérieures de DMS prennent en charge la lecture à partir des sauvegardes du journal des transactions. Pour garantir que DMS est en mesure d'accéder aux sauvegardes des journaux, en plus de ce qui précède, accordez des privilèges `master` utilisateur ou les privilèges suivants sur une source RDS SQL Server :

```
USE msdb;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_task_status TO rds_user;
    
USE db_name;
    CREATE USER rds_user FOR LOGIN rds_user;
    ALTER ROLE [db_owner] ADD MEMBER rds_user;
    GRANT VIEW DEFINITION to rds_user;
```

Pour les instances gérées SQL Amazon Azure, accordez les privilèges suivants :

```
GRANT SELECT ON msdb.dbo.backupset TO rds_user;
GRANT SELECT ON msdb.dbo.backupmediafamily TO rds_user;
GRANT SELECT ON msdb.dbo.backupfile TO rds_user;
```

## Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server
<a name="CHAP_Source.SQLServer.Prerequisites"></a>

Vous pouvez utiliser la réplication continue (capture des données de modification ou CDC) pour une base de données SQL Server autogérée sur site ou sur Amazon EC2, ou une base de données de cloud telle que Amazon RDS ou une instance gérée par Microsoft Azure SQL.

Les conditions suivantes s'appliquent précisément lorsque la réplication continue est utilisée avec une base de données SQL Server comme source pour AWS DMS :
+ SQL Server doit être configuré pour des sauvegardes complètes et vous devez effectuer une sauvegarde avant de commencer la réplication des données.
+ Le modèle de récupération doit être défini sur **Bulk logged** ou **Full**.
+ La sauvegarde SQL Server sur plusieurs disques n'est pas prise en charge. Si la sauvegarde est définie pour écrire la sauvegarde de la base de données dans plusieurs fichiers sur différents disques, AWS DMS vous ne pouvez pas lire les données et la AWS DMS tâche échoue.
+ Pour les sources SQL Server autogérées, les définitions du diffuseur de publication de réplication SQL Server pour la source utilisée dans une tâche de CDC DMS ne sont pas supprimées lorsque vous supprimez la tâche. Un administrateur système SQL Server doit supprimer ces définitions de SQL Server pour les sources autogérées.
+ Pendant le CDC, il AWS DMS doit consulter les sauvegardes du journal des transactions de SQL Server pour lire les modifications. AWS DMS ne prend pas en charge les sauvegardes du journal des transactions SQL Server créées à l'aide de logiciels de sauvegarde tiers qui *ne sont pas* au format natif. Pour prendre en charge les sauvegardes du journal des transactions qui *sont* au format natif et qui ont été créées à l’aide d’un logiciel de sauvegarde tiers, ajoutez l’attribut de connexion `use3rdPartyBackupDevice=Y` au point de terminaison source.
+ Pour les sources SQL Server autogérées, sachez que SQL Server ne capture pas les modifications sur les tables nouvellement créées tant qu'elles n'ont pas été publiées. Lorsque des tables sont ajoutées à une source SQL Server, AWS DMS gère la création de la publication. Toutefois, ce processus peut prendre plusieurs minutes. Les opérations réalisées sur les tables nouvellement créées pendant ce délai ne sont pas capturées ni répliquées sur la cible. 
+ AWS DMS la capture des données de modification nécessite l'activation de la journalisation complète des transactions dans SQL Server. Pour activer la journalisation complète des transactions dans SQL Server, activez MS-REPLICATION ou CHANGE DATA CAPTURE (CDC).
+ Les entrées *tlog* SQL Server ne seront pas marquées pour être réutilisées tant que la tâche de capture MS CDC n’aura pas traité ces modifications.
+ Les opérations CDC ne sont pas prises en charge sur les tables de mémoire optimisée. Cette limitation s’applique à SQL Server 2014 (lorsque la fonctionnalité a été introduite pour la première fois) et aux versions ultérieures.
+ AWS DMS la capture des données de modification nécessite une base de données de distribution par défaut sur Amazon EC2 ou On-Prem SQL Server comme source. Vous devez donc vous assurer d’avoir activé le distributeur lors de la configuration de la réplication MS pour les tables comportant des clés primaires.

## Méthodes de compression prises en charge pour SQL Server
<a name="CHAP_Source.SQLServer.Compression"></a>

Notez ce qui suit concernant la prise en charge des méthodes de compression SQL Server dans AWS DMS :
+ AWS DMS prend en charge la Row/Page compression dans SQL Server version 2008 et versions ultérieures.
+ AWS DMS ne prend pas en charge le format de stockage Vardecimal.
+ AWS DMS ne prend pas en charge les colonnes clairsemées et la compression de structure en colonnes.

## Utilisation de groupes de AlwaysOn disponibilité SQL Server autogérés
<a name="CHAP_Source.SQLServer.AlwaysOn"></a>

Les groupes de disponibilité SQL Server Always On assurent la haute disponibilité et la reprise après sinistre comme alternative au niveau de l’entreprise à la mise en miroir de base de données. 

Dans AWS DMS, vous pouvez migrer les modifications à partir d'une seule réplique de groupe de disponibilité principal ou secondaire.

### Utilisation du réplica de groupe de disponibilité principal
<a name="CHAP_Source.SQLServer.AlwaysOn.Primary"></a>

 

**Pour utiliser le groupe de disponibilité principal comme source dans AWS DMS, procédez comme suit :**

1. Activez l’option de distribution pour toutes les instances de SQL Server dans vos réplicas de disponibilité. Pour de plus amples informations, veuillez consulter [Configuration de la réplication continue sur une instance SQL Server autogérée](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC).

1. Dans la AWS DMS console, ouvrez les paramètres de la base de données source SQL Server. Pour **Nom du serveur**, spécifiez le nom DNS (Domain Name Service) ou l’adresse IP qui a été configuré(e) pour l’écouteur du groupe de disponibilité. 

Lorsque vous démarrez une AWS DMS tâche pour la première fois, le démarrage peut prendre plus de temps que d'habitude. Cette lenteur est due au fait que la création des articles de la table est dupliquée par le serveur du groupe de disponibilité. 

### Utilisation d’un réplica de groupe de disponibilité secondaire
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary"></a>

**Pour utiliser un groupe de disponibilité secondaire comme source dans AWS DMS, procédez comme suit :**

1. Utilisez les mêmes informations d'identification pour vous connecter à des répliques individuelles que celles utilisées par l'utilisateur du point de terminaison AWS DMS source.

1. Assurez-vous que votre instance de AWS DMS réplication peut résoudre les noms DNS de toutes les répliques existantes et s'y connecter. Vous pouvez utiliser la requête SQL suivante pour obtenir les noms DNS de tous vos réplicas.

   ```
   select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar
   JOIN sys.availability_databases_cluster adc
   ON adc.group_id = ar.group_id AND adc.database_name = '<source_database_name>';
   ```

1. Lorsque vous créez le point de terminaison source, spécifiez le nom DNS de l’écouteur du groupe de disponibilité pour le **nom du serveur** du point de terminaison ou pour l’**adresse du serveur** du secret de point de terminaison. Pour plus d’informations sur les écouteurs de groupe de disponibilité, consultez [Qu’est-ce qu’un écouteur de groupe de disponibilité ?](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15) dans la documentation de SQL Server.

   Vous pouvez utiliser un serveur DNS public ou un serveur DNS sur site pour résoudre l’écouteur du groupe de disponibilité, le réplica principal et les réplicas secondaires. Pour utiliser un serveur DNS sur site, configurez Amazon Route 53 Resolver. Pour de plus amples informations, veuillez consulter [Utilisation de votre propre serveur de noms sur site](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).

1. Ajoutez les attributs de connexion supplémentaires suivants au point de terminaison source.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.SQLServer.html)

1. Activez l’option de distribution sur tous les réplicas de votre groupe de disponibilité. Ajoutez tous les nœuds à la liste des distributeurs. Pour de plus amples informations, veuillez consulter [Pour configurer la distribution](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC.Setup).

1. Exécutez la requête suivante sur le réplica principal en lecture-écriture pour activer la publication de la base de données. Vous n’exécutez cette requête qu’une seule fois pour la base de données. 

   ```
   sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';
   ```



#### Limitations
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.limitations"></a>

Les limitations de l’utilisation d’un réplica de groupe de disponibilité secondaire sont les suivantes :
+ AWS DMS ne prend pas en charge Safeguard lors de l'utilisation d'une réplique de groupe de disponibilité en lecture seule comme source. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS ne prend pas en charge l'attribut de connexion `setUpMsCdcForTables` supplémentaire lors de l'utilisation d'une réplique de groupe de disponibilité en lecture seule comme source. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS peut utiliser une réplique de groupe de disponibilité secondaire autogérée comme base de données source pour une réplication continue (capture des données de modification, ou CDC) à partir de la version 3.4.7. Les réplicas de lecture SQL Server Multi-AZ cloud ne sont pas pris en charge. Si vous utilisez des versions précédentes de AWS DMS, assurez-vous d'utiliser la réplique du groupe de disponibilité principal comme base de données source pour CDC.

#### Basculement vers d’autres nœuds
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.failover"></a>

Si vous définissez l'attribut de connexion `ApplicationIntent` supplémentaire pour votre point de terminaison sur`ReadOnly`, votre AWS DMS tâche se connecte au nœud en lecture seule ayant la priorité de routage en lecture seule la plus élevée. Il bascule ensuite vers les autres nœuds en lecture seule de votre groupe de disponibilité lorsque le nœud en lecture seule ayant la priorité la plus élevée n’est pas disponible. Si vous ne le définissez pas`ApplicationIntent`, votre AWS DMS tâche se connecte uniquement au nœud principal (lecture/écriture) de votre groupe de disponibilité.

## Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS
<a name="CHAP_Source.SQLServer.ConnectionAttrib"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source SQL Server comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}'` JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec SQL Server en tant que source sont indiqués dans le tableau suivant.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.SQLServer.html)

## Types de données sources pour SQL Server
<a name="CHAP_Source.SQLServer.DataTypes"></a>

La migration de données qui utilise SQL Server comme source AWS DMS prend en charge la plupart des types de données SQL Server. Le tableau suivant indique les types de données source SQL Server pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données SQL Server  |  AWS DMS types de données  | 
| --- | --- | 
|  BIGINT  |  INT8  | 
|  BIT  |  BOOLEAN  | 
|  DECIMAL  |  NUMERIC  | 
|  INT  |  INT4  | 
|  MONEY  |  NUMERIC  | 
|  NUMERIC (p,s)  |  NUMERIC   | 
|  SMALLINT  |  INT2  | 
|  SMALLMONEY  |  NUMERIC  | 
|  TINYINT  |  UINT1  | 
|  REAL  |  REAL4  | 
|  FLOAT  |  REAL8  | 
|  DATETIME  |  DATETIME  | 
|  DATETIME2 (SQL Server 2008 et versions ultérieures)  |  DATETIME  | 
|  SMALLDATETIME  |  DATETIME  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  DATETIMEOFFSET  |  WSTRING  | 
|  CHAR  |  CHAÎNE  | 
|  VARCHAR  |  CHAÎNE  | 
|  VARCHAR (max)  |  CLOB TEXT Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données CLOB pour une tâche spécifique. Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server. Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  NCHAR  |  WSTRING  | 
|  NVARCHAR (length)  |  WSTRING  | 
|  NVARCHAR (max)  |  NCLOB NTEXT Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation de SupportLobs pour une tâche spécifique. Pour plus d’informations sur l’activation de la prise en charge des objets LOB, consultez [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md).  Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server. Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  BINAIRE  |  BYTES  | 
|  VARBINARY  |  BYTES  | 
|  VARBINARY (max)  |  BLOB IMAGE Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server. Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données BLOB pour une tâche spécifique. AWS DMS prend en charge les types de données BLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  TIMESTAMP  |  BYTES  | 
|  UNIQUEIDENTIFIER  |  CHAÎNE  | 
|  HIERARCHYID   |  Utilisez HIERARCHYID lors de la réplication sur un point de terminaison cible SQL Server. Utilisez WSTRING (250) lors de la réplication sur tous les autres points de terminaison cibles.  | 
|  xml  |  NCLOB Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server. Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données NCLOB pour une tâche spécifique. Pendant le CDC, AWS DMS prend en charge les types de données NCLOB uniquement dans les tables qui incluent une clé primaire.  | 
|  GEOMETRY  |  Utilisez GEOMETRY lors de la réplication de points de terminaison cibles qui prennent en charge ce type de données. Utilisez CLOB lors de la réplication de points de terminaison cibles qui ne prennent pas en charge ce type de données.  | 
|  GEOGRAPHY  |  Utilisez GEOGRAPHY lors de la réplication de points de terminaison cibles qui prennent en charge ce type de données. Utilisez CLOB lors de la réplication de points de terminaison cibles qui ne prennent pas en charge ce type de données.  | 

AWS DMS ne prend pas en charge les tables qui incluent des champs contenant les types de données suivants. 
+ CURSOR
+ SQL\$1VARIANT
+ TABLE

**Note**  
Les types de données définis par l'utilisateur sont pris en charge selon leur type de base. Par exemple, un type de données défini par l'utilisateur basé sur DATETIME est traité en tant que type de données DATETIME.

# Capture des modifications de données pour une réplication continue à partir de SQL Server
<a name="CHAP_Source.SQLServer.CDC"></a>

Cette rubrique décrit comment configurer la réplication CDC sur une source SQL Server.

**Topics**
+ [Capture des modifications de données pour SQL Server autogéré sur site ou sur Amazon EC2](#CHAP_Source.SQLServer.CDC.Selfmanaged)
+ [Configuration de la réplication continue sur une instance de base de données SQL Server cloud](#CHAP_Source.SQLServer.Configuration)

## Capture des modifications de données pour SQL Server autogéré sur site ou sur Amazon EC2
<a name="CHAP_Source.SQLServer.CDC.Selfmanaged"></a>

Pour capturer les modifications à partir d’une base de données Microsoft SQL Server source, assurez-vous que la base de données est configurée pour des sauvegardes complètes. Configurez la base de données en mode récupération complète ou en mode journalisation en bloc.

Pour une source SQL Server autogérée, AWS DMS utilise ce qui suit :

**Réplication Microsoft**  
Pour capturer les modifications pour des tables comportant des clés primaires. Vous pouvez le configurer automatiquement en octroyant des privilèges d'administrateur système à l'utilisateur du AWS DMS point de terminaison sur l'instance SQL Server source. Vous pouvez également suivre les étapes décrites dans cette section pour préparer la source et utiliser un utilisateur ne disposant pas des privilèges d'administrateur système pour le AWS DMS point de terminaison.

**MS-CDC**  
Pour capturer les modifications pour des tables sans clés primaires. Activez MS-CDC au niveau de la base de données et individuellement pour toutes les tables.

Lorsque vous configurez une base de données SQL Server pour la réplication continue (CDC), vous pouvez procéder de différentes manières :
+ Configurez la réplication continue en utilisant le rôle sysadmin.
+ Configurez la réplication continue pour qu'elle n'utilise pas le rôle sysadmin.

**Note**  
Vous pouvez utiliser le script suivant pour rechercher toutes les tables sans clé primaire ou unique :  

```
USE [DBname]
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name
FROM sys.tables
WHERE OBJECTPROPERTY(object_id, 'TableHasPrimaryKey') = 0
        AND  OBJECTPROPERTY(object_id, 'TableHasUniqueCnst') = 0
ORDER BY schema_name, table_name;
```

### Configuration de la réplication continue sur une instance SQL Server autogérée
<a name="CHAP_Source.SQLServer.CDC.MSCDC"></a>

Cette section contient des informations sur la configuration de la réplication continue sur une instance SQL Server autogérée en utilisant ou non le rôle sysadmin.

**Topics**
+ [Configuration de la réplication continue sur une instance SQL Server autogérée : Utilisation du rôle sysadmin](#CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin)
+ [Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin](#CHAP_SupportScripts.SQLServer.standalone)
+ [Configuration de la réplication continue sur une instance SQL Server dans un environnement de groupe de disponibilité : sans le rôle sysadmin](#CHAP_SupportScripts.SQLServer.ag)

#### Configuration de la réplication continue sur une instance SQL Server autogérée : Utilisation du rôle sysadmin
<a name="CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin"></a>

AWS DMS la réplication continue pour SQL Server utilise la réplication native de SQL Server pour les tables dotées de clés primaires et la capture des données de modification (CDC) pour les tables sans clés primaires.

Avant de configurer la réplication continue, consultez [Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

Pour les tables avec des clés primaires, AWS DMS vous pouvez généralement configurer les artefacts requis sur la source. En revanche, pour les instances SQL Server source autogérées, assurez-vous de configurer manuellement la distribution SQL Server en premier. Ensuite, les utilisateurs de la AWS DMS source disposant d'une autorisation d'administrateur système peuvent créer automatiquement la publication pour les tables avec des clés primaires.

Pour vérifier si la distribution a déjà été configurée, exécutez la commande suivante.

```
sp_get_distributor
```

Si le résultat est `NULL` pour la distribution de colonnes, cela signifie que la distribution n’est pas configurée. Vous pouvez procéder comme suit pour configurer la distribution.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup"></a>

**Pour configurer la distribution**

1. Connectez-vous à la base de données source SQL Server à l’aide de l’outil SQL Server Management Studio (SSMS).

1. Ouvrez le menu contextuel (clic droit) pour le dossier **Replication**, puis choisissez **Configurer la distribution**. L’assistant Configurer la distribution s’affiche. 

1. Suivez les instructions de l’assistant pour entrer les valeurs par défaut et créer la distribution.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup.CDC"></a>

**Pour configurer la CDC**

AWS DMS la version 3.4.7 et les versions ultérieures peuvent configurer MS CDC pour votre base de données et toutes vos tables automatiquement si vous n'utilisez pas de réplique en lecture seule. Pour utiliser cette fonctionnalité, définissez l’ECA `SetUpMsCdcForTables` sur true. Pour plus d'informations sur ECAs, voir[Paramètres de point de terminaison](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.ConnectionAttrib).

Pour les versions AWS DMS antérieures à 3.4.7, ou pour une réplique en lecture seule en tant que source, effectuez les opérations suivantes :

1. Pour les tables sans clés primaires, configurez MS-CDC pour la base de données. Pour ce faire, utilisez un compte auquel le rôle sysadmin est affecté et exécutez la commande suivante.

   ```
   use [DBname]
   EXEC sys.sp_cdc_enable_db
   ```

1. Configurez ensuite MS-CDC pour chacune des tables sources. Pour chaque table disposant de clés uniques mais ne disposant pas de clé primaire, exécutez la requête suivante afin de configurer MS-CDC.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @index_name = N'unique_index_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

1. Pour chaque table ne disposant pas de clé primaire ou de clé unique, exécutez la requête suivante afin de configurer MS-CDC.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL
   GO
   ```

Pour plus d'informations sur la configuration de MS-CDC pour des tables spécifiques, consultez la [documentation SQL Server](https://msdn.microsoft.com/en-us/library/cc627369.aspx). 

#### Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin
<a name="CHAP_SupportScripts.SQLServer.standalone"></a>

Cette section décrit comment configurer la réplication continue pour une source de base de données SQL Server autonome qui n’exige pas que le compte d’utilisateur dispose des privilèges sysadmin.

**Note**  
Après avoir exécuté les étapes de cette section, l’utilisateur DMS qui n’est pas un administrateur système sera autorisé à effectuer les étapes suivantes :  
Lire les modifications du journal de transactions en ligne
Accéder au disque pour lire les modifications des fichiers de sauvegarde des journaux de transactions
Ajouter ou modifier la publication utilisée par DMS
Ajouter des articles à la publication

1. Configurez Microsoft SQL Server pour la réplication comme décrit dans [Capture des modifications de données pour une réplication continue à partir de SQL Server](#CHAP_Source.SQLServer.CDC).

1. Activez la réplication Microsoft sur la base de données source. Cela peut être fait manuellement ou en exécutant la tâche une fois en tant qu’utilisateur sysadmin.

1. Créez le schéma `awsdms` sur la base de données source à l’aide du script suivant :

   ```
   use master
   go
   create schema awsdms
   go
   
   
   -- Create the table valued function [awsdms].[split_partition_list] on the Master database, as follows:
   USE [master]
   GO
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   go
   
   if (object_id('[awsdms].[split_partition_list]','TF')) is not null
   
   drop function [awsdms].[split_partition_list];
   
   go
   
   create function [awsdms].[split_partition_list]
   
   (
   
   @plist varchar(8000), --A delimited list of partitions
   
   @dlm nvarchar(1) --Delimiting character
   
   )
   
   returns @partitionsTable table --Table holding the BIGINT values of the string fragments
   
   (
   
   pid bigint primary key
   
   )   
   
   as
   
   begin
   
   declare @partition_id bigint;
   
   declare @dlm_pos integer;
   
   declare @dlm_len integer;
   
   set @dlm_len = len(@dlm);
   
   while (charindex(@dlm,@plist)>0)
   
   begin
   
   set @dlm_pos = charindex(@dlm,@plist);
   
   set @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
   
   insert into @partitionsTable (pid) values (@partition_id)
   
   set @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
   
   end
   
   set @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
   
   insert into @partitionsTable (pid) values ( @partition_id );
   
   return
   
   end
   
   GO
   ```

1. Créez la procédure `[awsdms].[rtm_dump_dblog]` sur la base de données Master à l’aide du script suivant :

   ```
   use [MASTER]
   
   go
   
   if (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null drop procedure [awsdms].[rtm_dump_dblog];
   go
   
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   GO
   
   
   
   CREATE procedure [awsdms].[rtm_dump_dblog]
   
   (
   
   @start_lsn varchar(32),
   
   @seqno integer,
   
   @filename varchar(260),
   
   @partition_list varchar(8000), -- A comma delimited list: P1,P2,... Pn
   
   @programmed_filtering integer,
   
   @minPartition bigint,
   
   @maxPartition bigint
   
   )
   
   as begin
   
   declare @start_lsn_cmp varchar(32); -- Stands against the GT comparator
   
   SET NOCOUNT ON -- – Disable "rows affected display"
   
   set @start_lsn_cmp = @start_lsn;
   
   if (@start_lsn_cmp) is null
   
   set @start_lsn_cmp = '00000000:00000000:0000';
   
   if (@partition_list is null)
   
   begin
   
   RAISERROR ('Null partition list waspassed',16,1);
   
   return
   
   end
   
   if (@start_lsn) is not null
   
   set @start_lsn = '0x'+@start_lsn;
   
   if (@programmed_filtering=0)
   
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1]
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   else
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1] -- After Image
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   
   SET NOCOUNT OFF -- Re-enable "rows affected display"
   
   end
   
   GO
   ```

1. Créez le certificat sur la base de données Master à l’aide du script suivant :

   ```
   Use [master]
   Go
   
   CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert] ENCRYPTION BY PASSWORD = N'@5trongpassword'
   
   WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions';
   ```

1. Créez la connexion à partir du certificat à l’aide du script suivant : 

   ```
   Use [master]
   Go
   
   CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE [awsdms_rtm_dump_dblog_cert];
   ```

1. Ajoutez la connexion au rôle serveur sysadmin à l’aide du script suivant :

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
   ```

1. Ajoutez la signature à [master].[awsdms].[rtm\$1dump\$1dblog] utilisant le certificat, à l’aide du script suivant : 

   ```
   Use [master]
   GO
   ADD SIGNATURE
   TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@5trongpassword';
   ```
**Note**  
Si vous recréez la procédure stockée, vous devez ajouter à nouveau la signature.

1. Créez [awsdms]. [rtm\$1position\$11st\$1timestamp] dans la base de données principale à l’aide du script suivant :

   ```
   use [master]
       if object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
       DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
       go
       create procedure [awsdms].[rtm_position_1st_timestamp]
       (
       @dbname                sysname,      -- Database name
       @seqno                 integer,      -- Backup set sequence/position number within file
       @filename              varchar(260), -- The backup filename
       @1stTimeStamp          varchar(40)   -- The timestamp to position by
       ) 
       as begin
   
       SET NOCOUNT ON       -- Disable "rows affected display"
   
       declare @firstMatching table
       (
       cLsn varchar(32),
       bTim datetime
       )
   
       declare @sql nvarchar(4000)
       declare @nl                       char(2)
       declare @tb                       char(2)
       declare @fnameVar                 nvarchar(254) = 'NULL'
   
       set @nl  = char(10); -- New line
       set @tb  = char(9)   -- Tab separator
   
       if (@filename is not null)
       set @fnameVar = ''''+@filename +''''
   
       set @sql='use ['+@dbname+'];'+@nl+
       'select top 1 [Current LSN],[Begin Time]'+@nl+
       'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @fnameVar+','+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default)'+@nl+
       'where operation=''LOP_BEGIN_XACT''' +@nl+
       'and [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
   
       --print @sql
       delete from  @firstMatching 
       insert into @firstMatching  exec sp_executesql @sql    -- Get them all
   
       select top 1 cLsn as [matching LSN],convert(varchar,bTim,121) as [matching Timestamp] from @firstMatching;
   
       SET NOCOUNT OFF      -- Re-enable "rows affected display"
   
       end
       GO
   ```

1. Créez le certificat sur la base de données Master à l’aide du script suivant :

   ```
   Use [master]
   Go
   CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
   ENCRYPTION BY PASSWORD = '@5trongpassword'
   WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
   ```

1. Créez la connexion à partir du certificat à l’aide du script suivant :

   ```
   Use [master]
   Go
   CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert];
   ```

1. Ajoutez la connexion au rôle sysadmin à l’aide du script suivant :

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
   ```

1. Ajoutez la signature à [master].[awsdms].[rtm\$1position\$11st\$1timestamp] en utilisant le certificat à l’aide du script suivant :

   ```
   Use [master]
       GO
       ADD SIGNATURE
       TO [master].[awsdms].[rtm_position_1st_timestamp]
       BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
       WITH PASSWORD = '@5trongpassword';
   ```

1. Accordez à l’utilisateur DMS l’accès lui permettant d’exécuter la nouvelle procédure stockée à l’aide du script suivant :

   ```
   use master
   go
   GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dms_user;
   ```

1. Créez un utilisateur avec les autorisations et les rôles suivants dans chacune des bases de données suivantes :
**Note**  
Vous devez créer le compte d’utilisateur dmsnosysadmin avec le même SID sur chaque réplica. La requête SQL suivante peut aider à vérifier la valeur SID du compte dmsnosysadmin sur chaque réplica. Pour plus d’informations sur la création d’un utilisateur, consultez [CREATE USER (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) dans la [documentation sur Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Pour plus d’informations sur la création de comptes d’utilisateur SQL pour la base de données Azure SQL, consultez [Géoréplication active](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

   ```
   use master
   go
   grant select on sys.fn_dblog to [DMS_user]
   grant view any definition to [DMS_user]
   grant view server state to [DMS_user]--(should be granted to the login).
   grant execute on sp_repldone to [DMS_user]
   grant execute on sp_replincrementlsn to [DMS_user]
   grant execute on sp_addpublication to [DMS_user]
   grant execute on sp_addarticle to [DMS_user]
   grant execute on sp_articlefilter to [DMS_user]
   grant select on [awsdms].[split_partition_list] to [DMS_user]
   grant execute on [awsdms].[rtm_dump_dblog] to [DMS_user]
   ```

   ```
   use msdb
   go
   grant select on msdb.dbo.backupset to self_managed_user
   grant select on msdb.dbo.backupmediafamily to self_managed_user
   grant select on msdb.dbo.backupfile to self_managed_user
   ```

   Exécutez le script suivant sur la base de données source :

   ```
   use Source_DB
       Go
       EXEC sp_addrolemember N'db_owner', N'DMS_user'
   ```

1. Enfin, ajoutez un attribut de connexion supplémentaire (ECA) au point de terminaison SQL Server source :

   ```
   enableNonSysadminWrapper=true;
   ```

#### Configuration de la réplication continue sur une instance SQL Server dans un environnement de groupe de disponibilité : sans le rôle sysadmin
<a name="CHAP_SupportScripts.SQLServer.ag"></a>

Cette section décrit comment configurer la réplication continue pour une source de base de données SQL Server dans un environnement de groupe de disponibilité qui n’exige pas que le compte d’utilisateur dispose des privilèges sysadmin.

**Note**  
Après avoir exécuté les étapes de cette section, l’utilisateur DMS qui n’est pas un administrateur système sera autorisé à effectuer les étapes suivantes :  
Lire les modifications du journal de transactions en ligne
Accéder au disque pour lire les modifications des fichiers de sauvegarde des journaux de transactions
Ajouter ou modifier la publication utilisée par DMS
Ajouter des articles à la publication

**Pour configurer la réplication continue sans utiliser l’utilisateur sysadmin dans un environnement de groupe de disponibilité**

1. Configurez Microsoft SQL Server pour la réplication comme décrit dans [Capture des modifications de données pour une réplication continue à partir de SQL Server](#CHAP_Source.SQLServer.CDC).

1. Activez la réplication Microsoft sur la base de données source. Cela peut être fait manuellement ou en exécutant la tâche une fois en ayant recours à un utilisateur sysadmin.
**Note**  
Vous devez configurer le distributeur de réplication Microsoft comme local ou de manière à autoriser l’accès aux utilisateurs non sysadmin via le serveur lié associé.

1. Si l’option de point de terminaison **Utiliser exclusivement sp\$1repldone au sein d’une seule tâche** est activée, arrêtez la tâche Log Reader de réplication Microsoft.

1. Sur chaque réplica, procédez comme suit :

   1. Créez le schéma `[awsdms]`[awsdms] dans la base de données Master :

      ```
      CREATE SCHEMA [awsdms]
      ```

   1. Créez la fonction à valeur de table `[awsdms].[split_partition_list]` sur la base de données Master :

      ```
      USE [master]
      GO
      
      SET ansi_nulls on
      GO
        
      SET quoted_identifier on
      GO
      
      IF (object_id('[awsdms].[split_partition_list]','TF')) is not null
        DROP FUNCTION [awsdms].[split_partition_list];
      GO
      
      CREATE FUNCTION [awsdms].[split_partition_list] 
      ( 
        @plist varchar(8000),    --A delimited list of partitions    
        @dlm nvarchar(1)    --Delimiting character
      ) 
      RETURNS @partitionsTable table --Table holding the BIGINT values of the string fragments
      (
        pid bigint primary key
      ) 
      AS 
      BEGIN
        DECLARE @partition_id bigint;
        DECLARE @dlm_pos integer;
        DECLARE @dlm_len integer;  
        SET @dlm_len = len(@dlm);
        WHILE (charindex(@dlm,@plist)>0)
        BEGIN 
          SET @dlm_pos = charindex(@dlm,@plist);
          SET @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
          INSERT into @partitionsTable (pid) values (@partition_id)
          SET @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
        END 
        SET @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
        INSERT into @partitionsTable (pid) values (  @partition_id  );
        RETURN
      END
      GO
      ```

   1. Créez la procédure `[awsdms].[rtm_dump_dblog]` sur la base de données Master :

      ```
      USE [MASTER] 
      GO
      
      IF (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null
        DROP PROCEDURE [awsdms].[rtm_dump_dblog]; 
      GO
      
      SET ansi_nulls on
      GO 
      
      SET quoted_identifier on 
      GO
                                          
      CREATE PROCEDURE [awsdms].[rtm_dump_dblog]
      (
        @start_lsn            varchar(32),
        @seqno                integer,
        @filename             varchar(260),
        @partition_list       varchar(8000), -- A comma delimited list: P1,P2,... Pn
        @programmed_filtering integer,
        @minPartition         bigint,
        @maxPartition         bigint
      ) 
      AS 
      BEGIN
      
        DECLARE @start_lsn_cmp varchar(32); -- Stands against the GT comparator
      
        SET NOCOUNT ON  -- Disable "rows affected display"
      
        SET @start_lsn_cmp = @start_lsn;
        IF (@start_lsn_cmp) is null
          SET @start_lsn_cmp = '00000000:00000000:0000';
      
        IF (@partition_list is null)
          BEGIN
            RAISERROR ('Null partition list was passed',16,1);
            return
            --set @partition_list = '0,';    -- A dummy which is never matched
          END
      
        IF (@start_lsn) is not null
          SET @start_lsn = '0x'+@start_lsn;
      
        IF (@programmed_filtering=0)
          SELECT
            [Current LSN],
            [operation],
            [Context],
            [Transaction ID],
            [Transaction Name],
            [Begin Time],
            [End Time],
            [Flag Bits],
            [PartitionID],
            [Page ID],
            [Slot ID],
            [RowLog Contents 0],
            [Log Record],
            [RowLog Contents 1] -- After Image
          FROM
            fn_dump_dblog (
              @start_lsn, NULL, N'DISK', @seqno, @filename,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default)
          WHERE 
            [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND       
                [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
              )
            OR
            ([operation] = 'LOP_HOBT_DDL')
          )
          ELSE
            SELECT
              [Current LSN],
              [operation],
              [Context],
              [Transaction ID],
              [Transaction Name],
              [Begin Time],
              [End Time],
              [Flag Bits],
              [PartitionID],
              [Page ID],
              [Slot ID],
              [RowLog Contents 0],
              [Log Record],
              [RowLog Contents 1] -- After Image
            FROM
              fn_dump_dblog (
                @start_lsn, NULL, N'DISK', @seqno, @filename,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default)
            WHERE [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
              )
              OR
              ([operation] = 'LOP_HOBT_DDL')
            )
            SET NOCOUNT OFF -- Re-enable "rows affected display"
      END
      GO
      ```

   1. Créez un certificat sur la base de données Master :

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions'
      ```

   1. Créez une connexion à partir du certificat :

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE
        [awsdms_rtm_dump_dblog_cert];
      ```

   1. Ajoutez la connexion au rôle serveur sysadmin :

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
      ```

   1. Ajoutez la signature à la procédure [master].[awsdms].[rtm\$1dump\$1dblog] utilisant le certificat :

      ```
      USE [master]
      GO
      
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_dump_dblog]
        BY CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Note**  
Si vous recréez la procédure stockée, vous devez ajouter à nouveau la signature.

   1. Créez la procédure `[awsdms].[rtm_position_1st_timestamp]` sur la base de données Master :

      ```
      USE [master]
      IF object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
        DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
      GO
      CREATE PROCEDURE [awsdms].[rtm_position_1st_timestamp]
      (
        @dbname                sysname,      -- Database name
        @seqno                 integer,      -- Backup set sequence/position number within file
        @filename              varchar(260), -- The backup filename
        @1stTimeStamp          varchar(40)   -- The timestamp to position by
      ) 
      AS 
      BEGIN
        SET NOCOUNT ON       -- Disable "rows affected display"
      
        DECLARE @firstMatching table
        (
          cLsn varchar(32),
          bTim datetime
        )
        DECLARE @sql nvarchar(4000)
        DECLARE @nl                       char(2)
        DECLARE @tb                       char(2)
        DECLARE @fnameVar                 sysname = 'NULL'
      
        SET @nl  = char(10); -- New line
        SET @tb  = char(9)   -- Tab separator
      
        IF (@filename is not null)
          SET @fnameVar = ''''+@filename +''''
        SET @filename = ''''+@filename +''''
        SET @sql='use ['+@dbname+'];'+@nl+
          'SELECT TOP 1 [Current LSN],[Begin Time]'+@nl+
          'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @filename +','+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default)'+@nl+
          'WHERE operation=''LOP_BEGIN_XACT''' +@nl+
          'AND [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
      
          --print @sql
          DELETE FROM @firstMatching 
          INSERT INTO @firstMatching  exec sp_executesql @sql    -- Get them all
          SELECT TOP 1 cLsn as [matching LSN],convert(varchar,bTim,121) AS[matching Timestamp] FROM @firstMatching;
      
          SET NOCOUNT OFF      -- Re-enable "rows affected display"
      
      END
      GO
      ```

   1. Créez un certificat sur la base de données Master :

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
      ```

   1. Créez une connexion à partir du certificat :

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE
        [awsdms_rtm_position_1st_timestamp_cert];
      ```

   1. Ajoutez la connexion au rôle serveur sysadmin :

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
      ```

   1. Ajoutez la signature à la procédure `[master].[awsdms].[rtm_position_1st_timestamp]` utilisant le certificat :

      ```
      USE [master]
      GO
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_position_1st_timestamp]
        BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Note**  
Si vous recréez la procédure stockée, vous devez ajouter à nouveau la signature.

   1. Créez un utilisateur avec les éléments suivants permissions/roles dans chacune des bases de données suivantes :
**Note**  
Vous devez créer le compte d’utilisateur dmsnosysadmin avec le même SID sur chaque réplica. La requête SQL suivante peut aider à vérifier la valeur SID du compte dmsnosysadmin sur chaque réplica. Pour plus d’informations sur la création d’un utilisateur, consultez [CREATE USER (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) dans la [documentation sur Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Pour plus d’informations sur la création de comptes d’utilisateur SQL pour la base de données Azure SQL, consultez [Géoréplication active](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

      ```
      SELECT @@servername servername, name, sid, create_date, modify_date
        FROM sys.server_principals
        WHERE name = 'dmsnosysadmin';
      ```

   1. Accordez des autorisations sur la base de données Master pour chaque réplica :

      ```
      USE master
      GO 
      
      GRANT select on sys.fn_dblog to dmsnosysadmin;
      GRANT view any definition to dmsnosysadmin;
      GRANT view server state to dmsnosysadmin -- (should be granted to the login).
      GRANT execute on sp_repldone to dmsnosysadmin;
      GRANT execute on sp_replincrementlsn to dmsnosysadmin;
      GRANT execute on sp_addpublication to dmsnosysadmin;
      GRANT execute on sp_addarticle to dmsnosysadmin;
      GRANT execute on sp_articlefilter to dmsnosysadmin;
      GRANT select on [awsdms].[split_partition_list] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_dump_dblog] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dmsnosysadmin;
      ```

   1. Accordez des autorisations sur la base de données msdb pour chaque réplica :

      ```
      USE msdb
      GO
      GRANT select on msdb.dbo.backupset TO self_managed_user
      GRANT select on msdb.dbo.backupmediafamily TO self_managed_user
      GRANT select on msdb.dbo.backupfile TO self_managed_user
      ```

   1. Ajoutez le rôle `db_owner` à `dmsnosysadmin` sur la base de données source. La base de données étant synchronisée, vous pouvez vous contenter d’ajouter le rôle sur le réplica principal uniquement.

      ```
      use <source DB>
      GO 
      EXEC sp_addrolemember N'db_owner', N'dmsnosysadmin'
      ```

## Configuration de la réplication continue sur une instance de base de données SQL Server cloud
<a name="CHAP_Source.SQLServer.Configuration"></a>

Cette section explique comment configurer la CDC sur une instance de base de données SQL Server hébergée sur le cloud. Une instance SQL Server hébergée sur le cloud est une instance exécutée sur Amazon RDS for SQL Server, une instance gérée par Azure SQL ou toute autre instance SQL Server gérée dans le cloud. Pour en savoir plus sur les limitations relatives à la réplication continue pour chaque type de base de données, consultez [Limitations relatives à l'utilisation de SQL Server comme source pour AWS DMS](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Limitations). 

Avant de configurer la réplication continue, consultez [Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

À la différence des sources Microsoft SQL Server autogérées, Amazon RDS for SQL Server ne prend pas en charge la réplication Microsoft. Par conséquent, AWS DMS vous devez utiliser MS-CDC pour les tables avec ou sans clés primaires.

Amazon RDS n'accorde pas de privilèges d'administrateur système pour configurer les artefacts de réplication AWS DMS utilisés pour les modifications continues dans une instance SQL Server source. Veillez à activer MS-CDC pour l’instance Amazon RDS (en utilisant des privilèges d’utilisateur principal) comme décrit dans la procédure suivante.

**Pour activer MS-CDC pour une instance de base de données SQL Server cloud**

1. Exécutez l’une des requêtes suivantes au niveau de la base de données.

   Pour une instance de base de données RDS for SQL Server, utilisez cette requête.

   ```
   exec msdb.dbo.rds_cdc_enable_db 'DB_name'
   ```

   Pour une instance de base de données gérée par Azure SQL, utilisez cette requête.

   ```
   USE DB_name 
   GO 
   EXEC sys.sp_cdc_enable_db 
   GO
   ```

1. Pour chaque table disposant d’une clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

   Pour chaque table disposant de clés uniques mais ne disposant pas de clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @index_name = N'unique_index_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

    Pour chaque table ne disposant pas de clé unique ni de clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL
   GO
   ```

1. Définissez la période de conservation :
   + Pour les instances RDS for SQL Server qui se répliquent à l'aide de DMS version 3.5.3 ou ultérieure, assurez-vous que la période de rétention est définie sur la valeur par défaut de 5 secondes. Si vous effectuez une mise à niveau ou passez de DMS 3.5.2 ou d'une version antérieure à DMS 3.5.3 ou version ultérieure, modifiez la valeur de l'intervalle d'interrogation une fois les tâches exécutées sur la nouvelle instance ou sur l'instance mise à niveau. Le script suivant définit la période de rétention à 5 secondes :

     ```
     use dbname
     EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 5
     exec sp_cdc_stop_job 'capture'
     exec sp_cdc_start_job 'capture'
     ```
   + Le paramètre `@pollinginterval` est mesuré en secondes avec une valeur recommandée définie sur 86399. Cela signifie que le journal des transactions conserve les modifications pendant 86 399 secondes (un jour) lorsque `@pollinginterval = 86399`. La procédure `exec sp_cdc_start_job 'capture'` lance les paramètres.
**Note**  
Dans certaines versions de SQL Server, si la valeur de `pollinginterval` est définie sur plus de 3 599 secondes, elle est réinitialisée à la valeur par défaut de 5 secondes. Dans ce cas, les entrées du T-Log sont purgées avant de AWS DMS pouvoir les lire. Pour déterminer quelles versions de SQL Server sont concernées par ce problème connu, consultez [cet article de la base de connaissances Microsoft](https://support.microsoft.com/en-us/topic/kb4459220-fix-incorrect-results-occur-when-you-convert-pollinginterval-parameter-from-seconds-to-hours-in-sys-sp-cdc-scan-in-sql-server-dac8aefe-b60b-7745-f987-582dda2cfa78).

     Si vous utilisez Amazon RDS avec le mode multi-AZ, veillez à configurer également votre instance secondaire de sorte qu’elle ait les bonnes valeurs en cas de basculement.

     ```
     exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , <5 or preferred value>
     ```

**Pour maintenir la période de rétention lorsqu'une tâche de AWS DMS réplication est arrêtée pendant plus d'une heure**
**Note**  
Les étapes suivantes ne sont pas nécessaires pour une réplication de source RDS pour SQL Server à l'aide de DMS 3.5.3 et versions ultérieures.

1. Arrêtez la tâche qui tronque les journaux de transactions à l’aide de la commande suivante. 

   ```
   exec sp_cdc_stop_job 'capture'
   ```

1. Trouvez votre tâche sur la AWS DMS console et reprenez-la.

1. Choisissez l’onglet **Surveillance**, puis vérifiez la métrique `CDCLatencySource`. 

1. Une fois que la métrique `CDCLatencySource` est égale à 0 (zéro) et ne change plus, redémarrez la tâche qui tronque les journaux de transactions à l’aide de la commande suivante.

   ```
   exec sp_cdc_start_job 'capture'
   ```

N’oubliez pas de démarrer la tâche qui tronque les journaux de transactions SQL Server. Dans le cas contraire, l’espace de stockage sur votre instance SQL Server risque de se remplir.

### Paramètres recommandés lors de l'utilisation de RDS pour SQL Server comme source pour AWS DMS
<a name="CHAP_Source.SQLServer.Configuration.Settings"></a>

#### Pour AWS DMS 3.5.3 et versions ultérieures
<a name="CHAP_Source.SQLServer.Configuration.Settings.353"></a>

**Note**  
La version initiale de la fonctionnalité de sauvegarde des journaux de RDS pour SQL Server est activée par défaut pour les points de terminaison que vous avez créés ou modifiés après la publication de la version 3.5.3 de DMS. Pour utiliser cette fonctionnalité pour les points de terminaison existants, modifiez le point de terminaison sans apporter de modifications.

AWS DMS la version 3.5.3 introduit le support pour la lecture à partir des sauvegardes de journaux. Le DMS s'appuie principalement sur la lecture des journaux de transactions actifs pour répliquer les événements. Si une transaction est sauvegardée avant que DMS ne puisse la lire dans le journal actif, la tâche accède aux sauvegardes RDS à la demande et lit les journaux de sauvegarde suivants jusqu'à ce qu'elle rattrape le journal des transactions actif. Pour garantir que DMS a accès aux sauvegardes des journaux, définissez la période de conservation automatique des sauvegardes RDS sur au moins un jour. Pour plus d'informations sur la définition de la période de conservation automatique des sauvegardes, consultez la section [Période de conservation des sauvegardes](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention) dans le *guide de l'utilisateur Amazon RDS*.

Une tâche DMS accédant aux sauvegardes de journaux utilise le stockage sur l'instance RDS. Notez que la tâche accède uniquement aux sauvegardes de journaux nécessaires à la réplication. Amazon RDS supprime ces sauvegardes téléchargées en quelques heures. Cette suppression n'affecte pas les sauvegardes Amazon RDS conservées dans Amazon S3, ni les fonctionnalités d'Amazon RDS. `RESTORE DATABASE` Il est conseillé d'allouer du stockage supplémentaire sur votre source RDS pour SQL Server si vous avez l'intention de répliquer à l'aide de DMS. Une façon d'estimer la quantité de stockage nécessaire consiste à identifier la sauvegarde à partir de laquelle DMS va démarrer ou reprendre la réplication, et à additionner les tailles de fichier de toutes les sauvegardes suivantes à l'aide de la fonction de métadonnées RDS`tlog backup`. Pour plus d'informations sur cette `tlog backup` fonction, consultez la [liste des sauvegardes de journaux de transactions disponibles](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html#USER.SQLServer.AddlFeat.TransactionLogAccess.Listing) dans le *guide de l'utilisateur Amazon RDS*. 

Vous pouvez également choisir d'activer le dimensionnement automatique du stockage et/ou de déclencher le dimensionnement du stockage en fonction de la CloudWatch `FreeStorageSpace` métrique de votre instance Amazon RDS.

Nous vous recommandons vivement de ne pas démarrer ou reprendre trop loin dans les sauvegardes du journal des transactions, car cela pourrait entraîner un remplissage du stockage sur votre instance SQL Server. Dans ce cas, il est conseillé de démarrer un chargement complet. La réplication à partir de la sauvegarde du journal des transactions est plus lente que la lecture des journaux de transactions actifs. Pour de plus amples informations, veuillez consulter [Traitement de sauvegarde du journal des transactions pour RDS pour SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md#CHAP_Troubleshooting_Latency_Source_SQLServer_backup).

Notez que l'accès aux sauvegardes du journal nécessite des privilèges supplémentaires. Pour plus d'informations, voir les informations détaillées dans [Configurer des autorisations pour une réplication continue à partir d'une base de données SQL Server dans le cloud](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Permissions.Cloud) Assurez-vous d'accorder ces privilèges avant que la tâche ne commence à se répliquer.

#### Pour AWS DMS 3.5.2 et versions antérieures
<a name="CHAP_Source.SQLServer.Configuration.Settings.352"></a>

Lorsque vous utilisez Amazon RDS for SQL Server en tant que source, la tâche de capture MS-CDC repose sur les `maxscans` paramètres et. `maxtrans` Ces paramètres régissent le nombre maximum d'analyses effectuées par la capture MS-CDC dans le journal des transactions et le nombre de transactions traitées pour chaque analyse.

Pour les bases de données où le nombre de transactions est supérieur à `maxtrans*maxscans`, l’augmentation de la valeur `polling_interval` peut entraîner une accumulation d’enregistrements dans le journal des transactions actif. À son tour, cette accumulation peut entraîner une augmentation de la taille du journal des transactions.

Notez que cela AWS DMS ne repose pas sur la tâche de capture MS-CDC. La tâche de capture MS-CDC marque les entrées du journal des transactions comme ayant été traitées. Cela permet à la tâche de sauvegarde du journal des transactions de supprimer les entrées du journal des transactions.

Nous vous recommandons de surveiller la taille du journal des transactions et la réussite des tâches MS-CDC. Si les tâches MS-CDC échouent, le journal des transactions peut augmenter de manière excessive et provoquer des échecs de AWS DMS réplication. Vous pouvez surveiller les erreurs des tâches de capture MS-CDC à l’aide de la vue de gestion dynamique `sys.dm_cdc_errors` de la base de données source. Vous pouvez surveiller la taille du journal des transactions à l’aide de la commande de gestion `DBCC SQLPERF(LOGSPACE)`.

**Pour remédier à l’augmentation du journal des transactions provoquée par MS-CDC**

1. Vérifiez le `Log Space Used %` pour lequel la base de données AWS DMS est en train de se répliquer et vérifiez qu'il augmente continuellement.

   ```
   DBCC SQLPERF(LOGSPACE)
   ```

1. Identifiez ce qui bloque le processus de sauvegarde du journal des transactions.

   ```
   Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();
   ```

   Si la valeur `log_reuse_wait_desc` est égale à `REPLICATION`, la conservation de la sauvegarde du journal est due à la latence dans MS-CDC.

1. Augmentez le nombre d’événements traités par la tâche de capture en augmentant les valeurs des paramètres `maxtrans` et `maxscans`.

   ```
   EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 
   exec sp_cdc_stop_job 'capture'
   exec sp_cdc_start_job 'capture'
   ```

Pour résoudre ce problème, définissez les valeurs de `maxscans` et de `maxtrans` manière à ce `maxtrans*maxscans` qu'elles soient égales au nombre moyen d'événements générés pour les tables AWS DMS répliquées à partir de la base de données source chaque jour.

Si vous définissez ces paramètres sur une valeur supérieure à la valeur recommandée, les tâches de capture traitent tous les événements des journaux de transactions. Si vous définissez ces paramètres sur une valeur inférieure à la valeur recommandée, la latence MS-CDC augmente ainsi que la taille de votre journal des transactions.

L’identification des valeurs appropriées pour `maxscans` et `maxtrans` peut s’avérer difficile, car les modifications de la charge de travail produisent un nombre variable d’événements. Dans ce cas, nous vous recommandons de configurer la surveillance sur la latence MS-CDC. Pour plus d’informations, consultez [Monitor the process](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver15#Monitor) dans la documentation de SQL Server. Configurez ensuite `maxtrans` et `maxscans` de manière dynamique en fonction des résultats de la surveillance.

Si la AWS DMS tâche ne parvient pas à trouver les numéros de séquence du journal (LSNs) nécessaires pour reprendre ou poursuivre la tâche, celle-ci peut échouer et nécessiter un rechargement complet.

**Note**  
Lors de l'utilisation AWS DMS pour répliquer des données à partir d'une source RDS pour SQL Server, vous pouvez rencontrer des erreurs lorsque vous tentez de reprendre la réplication après un événement stop-start de l'instance Amazon RDS. Cela est dû au fait que le processus SQL Server Agent redémarre le processus de capture lorsqu’il redémarre après l’événement d’arrêt/démarrage. Cela permet de contourner l’intervalle d’interrogation MS-CDC.  
De ce fait, sur les bases de données dont le volume de transactions est inférieur au traitement de la tâche de capture MS-CDC, les données peuvent être traitées ou marquées comme répliquées et sauvegardées avant de AWS DMS pouvoir reprendre là où elles s'étaient arrêtées, ce qui entraîne l'erreur suivante :  

```
[SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764)
```
Pour atténuer ce problème, définissez les valeurs `maxtrans` et `maxscans` comme recommandé précédemment.

# Utilisation de la base de données Microsoft Azure SQL comme source pour AWS DMS
<a name="CHAP_Source.AzureSQL"></a>

Avec AWS DMS, vous pouvez utiliser la base de données SQL Microsoft Azure comme source de la même manière que SQL Server. AWS DMS prend en charge, en tant que source, la même liste de versions de base de données prises en charge pour SQL Server exécuté sur site ou sur une instance Amazon EC2. 

Pour de plus amples informations, veuillez consulter [Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS](CHAP_Source.SQLServer.md).

**Note**  
AWS DMS ne prend pas en charge les opérations de capture de données modifiées (CDC) avec Azure SQL Database.

# Utilisation de l'instance gérée Microsoft Azure SQL comme source pour AWS DMS
<a name="CHAP_Source.AzureMgd"></a>

Avec AWS DMS, vous pouvez utiliser Microsoft Azure SQL Managed Instance comme source de la même manière que SQL Server. AWS DMS prend en charge, en tant que source, la même liste de versions de base de données prises en charge pour SQL Server exécuté sur site ou sur une instance Amazon EC2. 

Pour de plus amples informations, veuillez consulter [Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS](CHAP_Source.SQLServer.md).

# Utilisation du serveur flexible Microsoft Azure Database pour PostgreSQL comme source pour AWS DMS
<a name="CHAP_Source.AzureDBPostgreSQL"></a>

Avec AWS DMS, vous pouvez utiliser le serveur flexible Microsoft Azure Database pour PostgreSQL comme source, de la même manière que PostgreSQL.

Pour plus d'informations sur les versions du serveur flexible Microsoft Azure Database pour PostgreSQL qui sont prises en charge en tant AWS DMS que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md)

## Configuration du serveur flexible Microsoft Azure pour PostgreSQL pour la réplication logique et le décodage
<a name="CHAP_Source.AzureDBPostgreSQL.setup"></a>

Vous pouvez utiliser les fonctionnalités de réplication logique et de décodage du serveur flexible Microsoft Azure Database pour PostgreSQL dans le cadre de la migration de base de données.

Pour le décodage logique, DMS utilise le plug-in `test_decoding` ou `pglogical`. Si le plug-in `pglogical` est disponible sur une base de données PostgreSQL source, DMS crée un emplacement de réplication en utilisant `pglogical`, sinon le plug-in `test_decoding` est utilisé. 

Pour configurer votre serveur flexible Microsoft Azure pour PostgreSQL en tant que point de terminaison source pour DMS, effectuez les étapes suivantes : 

1. Ouvrez la page Paramètres du serveur sur le portail.

1. Définissez le paramètre `wal_level` du serveur sur `LOGICAL`.

1. Si vous souhaitez utiliser l’extension `pglogical`, définissez les paramètres `shared_preload_libraries` et `azure.extensions` sur `pglogical`.

1. Définissez le paramètre `max_replication_slots` sur le nombre maximal de tâches DMS que vous envisagez d’exécuter simultanément. Dans Microsoft Azure, la valeur par défaut de ce paramètre est 10. La valeur maximale de ce paramètre dépend de la mémoire disponible de votre instance PostgreSQL, ce qui permet de prévoir entre 2 et 8 emplacements de réplication par Go de mémoire.

1. Définissez le paramètre `max_wal_senders` sur une valeur supérieure à 1. Le paramètre `max_wal_senders`définit le nombre de tâches simultanées qui peuvent s'exécuter. La valeur par défaut est 10.

1. Définissez la valeur du paramètre `max_worker_processes` sur au moins 16. Dans le cas contraire, des erreurs telles que les suivantes peuvent survenir :

   ```
   WARNING: out of background worker slots.
   ```

1. Enregistrez les Modifications. Redémarrez le serveur pour appliquer les modifications.

1. Vérifiez que votre instance PostgreSQL autorise le trafic réseau provenant de votre ressource de connexion.

1. Accordez des autorisations de réplication à un utilisateur existant ou créez un nouvel utilisateur avec des autorisations de réplication à l’aide des commandes suivantes. 
   + Accordez des autorisations de réplication à un utilisateur existant à l’aide de la commande suivante :

     ```
     ALTER USER <existing_user> WITH REPLICATION;
     ```
   + Créez un nouvel utilisateur avec des autorisations de réplication à l’aide de la commande suivante : 

     ```
     CREATE USER aws_dms_user PASSWORD 'aws_dms_user_password';
     GRANT azure_pg_admin to aws_dms_user;
     ALTER ROLE aws_dms_user REPLICATION LOGIN;
     ```

Pour plus d’informations sur la réplication logique avec PostgreSQL, consultez les rubriques suivantes :
+ [Activation de la capture des données de modification (CDC) à l’aide de la réplication logique](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security)
+ [Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10)
+ [Réplication logique et décodage logique dans le serveur flexible Azure Database pour PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-logical) dans la [documentation Azure Database pour PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/).

# Utilisation du serveur flexible Microsoft Azure Database pour MySQL comme source pour AWS DMS
<a name="CHAP_Source.AzureDBMySQL"></a>

Avec AWS DMS, vous pouvez utiliser le serveur flexible Microsoft Azure Database pour MySQL comme source, de la même manière que MySQL.

Pour plus d'informations sur les versions du serveur flexible Microsoft Azure Database pour MySQL prises AWS DMS en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md). 

Pour plus d'informations sur l'utilisation d'une base de données compatible MySQL gérée par le client avec, consultez. AWS DMS[Utilisation d'une base de données compatible MySQL autogérée comme source pour AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.CustomerManaged)

## Limitations liées à l'utilisation d'Azure MySQL comme source pour AWS Database Migration Service
<a name="CHAP_Source.AzureDBMySQL.limitations"></a>
+ La valeur par défaut de la variable système de serveur flexible Azure MySQL `sql_generate_invisible_primary_key` est`ON`, et le serveur ajoute automatiquement une clé primaire invisible générée (GIPK) à toute table créée sans clé primaire explicite. AWS DMS ne prend pas en charge la réplication continue pour les tables MySQL avec des contraintes GIPK.

# Utilisation d'OCI MySQL Heatwave comme source pour AWS DMS
<a name="CHAP_Source.heatwave"></a>

Avec AWS DMS, vous pouvez utiliser OCI MySQL Heatwave comme source de la même manière que MySQL. L’utilisation d’OCI MySQL Heatwave en tant que source nécessite quelques modifications de configuration supplémentaires.

Pour plus d'informations sur les versions d'OCI MySQL Heatwave compatibles AWS DMS en tant que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md)

## Configuration d’OCI MySQL Heatwave pour la réplication logique
<a name="CHAP_Source.heatwave.setup"></a>

Pour configurer votre instance OCI MySQL Heatwave en tant que point de terminaison source pour DMS, procédez comme suit :

1. Connectez-vous à la console OCI et ouvrez le menu principal des hamburgers (≡) dans le coin supérieur gauche.

1. Choisissez **Bases de données**, **Systèmes de bases de données**.

1. Ouvrez le menu **Configurations**.

1. Choisissez **Créer une configuration**.

1. Entrez un nom de configuration, tel que **dms\$1configuration**.

1. Choisissez la forme de votre instance OCI MySQL Heatwave actuelle. Vous pouvez trouver la forme dans l’onglet de propriétés **Configuration du système de bases de données** de l’instance, dans la section **Configuration du système de base de données : Forme**.

1. Dans la section **Variables d’utilisateur**, choisissez la variable système `binlog_row_value_options`. Sa valeur par défaut est `PARTIAL_JSON`. Effacez la valeur.

1. Choisissez le bouton **Créer**.

1. Ouvrez votre SQLHeatwave instance OCI My, puis cliquez sur le bouton **Modifier**.

1. Dans la section **Configuration**, choisissez le bouton **Modifier la configuration**, puis choisissez la configuration de forme que vous avez créée à l’étape 4.

1. Une fois que les modifications ont pris effet, votre instance est prête pour la réplication logique.

# Utilisation de Google Cloud pour MySQL comme source pour AWS DMS
<a name="CHAP_Source.GC"></a>

Avec AWS DMS, vous pouvez utiliser Google Cloud pour MySQL comme source de la même manière que MySQL. 

Pour plus d'informations sur les versions de GCP MySQL prises AWS DMS en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md). 

Pour de plus amples informations, veuillez consulter [Utilisation d'une base de données compatible MySQL comme source pour AWS DMS](CHAP_Source.MySQL.md).

**Note**  
Support pour GCP MySQL 8.0 en tant que source est disponible dans la AWS DMS version 3.4.6.  
AWS DMS ne prend pas en charge le mode SSL `verify-full` pour les instances GCP pour MySQL.  
Le paramètre de sécurité GCP MySQL `Allow only SSL connections` n'est pas pris en charge, car il nécessite la vérification des certificats du serveur et du client. AWS DMS prend uniquement en charge la vérification des certificats de serveur.  
AWS DMS prend en charge la valeur par défaut de GCP CloudSQL pour MySQL `CRC32` pour l'indicateur de `binlog_checksum` base de données.

# Utilisation de Google Cloud pour PostgreSQL comme source pour AWS DMS
<a name="CHAP_Source.GCPostgres"></a>

Vous pouvez utiliser Google Cloud pour PostgreSQL comme source de la même manière que les bases de données PostgreSQL autogérées. AWS DMS

Pour plus d'informations sur les versions de GCP PostgreSQL prises en charge en tant AWS DMS que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md) 

Pour de plus amples informations, veuillez consulter [Utilisation d'une base de données PostgreSQL comme source AWS DMS](CHAP_Source.PostgreSQL.md).

## Configuration de Google Cloud pour PostgreSQL pour la réplication logique et le décodage
<a name="CHAP_Source.GCPostgres.setup"></a>

Vous pouvez utiliser les fonctionnalités de réplication logique et de décodage dans Google Cloud SQL pour PostgreSQL au cours de la migration de base de données.

Pour le décodage logique, DMS utilise l’un des plug-ins suivants :
+ `test_decoding`
+ `pglogical`

Si le plug-in `pglogical` est disponible sur une base de données PostgreSQL source, DMS crée un emplacement de réplication en utilisant `pglogical`, sinon le plug-in `test_decoding` est utilisé. 

Notez ce qui suit à propos de l'utilisation du décodage logique avec AWS DMS :

1. Avec Google Cloud SQL pour PostgreSQL, activez le décodage logique en attribuant à l’indicateur `cloudsql.logical_decoding` la valeur `on`.

1. Pour activer `pglogical`, attribuez à l’indicateur `cloudsql.enable_pglogical` la valeur `on`, puis redémarrez la base de données.

1. Pour utiliser les fonctionnalités de décodage logique, vous devez créer un utilisateur PostgreSQL avec l’attribut `REPLICATION`. Lorsque vous utilisez l’extension `pglogical`, l’utilisateur doit avoir le rôle `cloudsqlsuperuser`. Pour créer un utilisateur avec le rôle `cloudsqlsuperuser`, procédez comme suit :

   ```
   CREATE USER new_aws_dms_user WITH REPLICATION
   IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'new_aws_dms_user_password';
   ```

   Pour définir cet attribut sur un utilisateur existant, procédez comme suit :

   ```
   ALTER USER existing_user WITH REPLICATION;
   ```

1. Définissez le paramètre `max_replication_slots` sur le nombre maximal de tâches DMS que vous envisagez d’exécuter simultanément. Dans Google Cloud SQL, la valeur par défaut de ce paramètre est 10. La valeur maximale de ce paramètre dépend de la mémoire disponible de votre instance PostgreSQL, ce qui permet de prévoir entre 2 et 8 emplacements de réplication par Go de mémoire.

Pour plus d’informations sur la réplication logique avec PostgreSQL, consultez les rubriques suivantes :
+ [Activation de la capture des données de modification (CDC) à l’aide de la réplication logique](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security)
+ [Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10)
+ [Configurer la réplication logique et le décodage](https://cloud.google.com/sql/docs/postgres/replication/configure-logical-replication) dans la [documentation de Cloud SQL pour PostgreSQL](https://cloud.google.com/sql/docs/postgres).

# Utilisation d'une base de données PostgreSQL comme source AWS DMS
<a name="CHAP_Source.PostgreSQL"></a>

Vous pouvez migrer les données d'une ou de plusieurs bases de données PostgreSQL à l'aide de. AWS DMS Avec une base de données PostgreSQL en tant que source, vous pouvez migrer les données vers une autre base de données PostgreSQL ou vers l’une des autres bases de données prises en charge. 

Pour plus d'informations sur les versions de PostgreSQL compatibles en tant AWS DMS que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md) 

AWS DMS prend en charge PostgreSQL pour les types de bases de données suivants : 
+ Bases de données sur site
+ Bases de données sur une instance Amazon EC2
+ Bases de données sur une instance de base de données Amazon RDS
+ Bases de données sur une instance de base de données basée sur Amazon Aurora PostgreSQL-Compatible Edition
+ Bases de données sur une instance de base de données basée sur Amazon Aurora PostgreSQL-Compatible Edition sans serveur

**Note**  
DMS prend en charge Amazon Aurora PostgreSQL sans serveur V1 en tant que source pour le chargement complet uniquement. Mais vous pouvez utiliser Amazon Aurora PostgreSQL sans serveur V2 en tant que source pour les tâches Chargement complet, Chargement complet \$1 CDC et CDC uniquement.

Vous pouvez utiliser Secure Socket Layers (SSL) pour chiffrer les connexions entre votre point de terminaison PostgreSQL et l’instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison PostgreSQL, consultez [Utilisation du protocole SSL avec AWS Database Migration Service](CHAP_Security.SSL.md).

Lorsque vous utilisez PostgreSQL en tant que source, la seule exigence de sécurité supplémentaire consiste à ce que le compte d’utilisateur spécifié soit un utilisateur enregistré dans la base de données PostgreSQL.

Pour configurer une base de données PostgreSQL en tant que point de terminaison AWS DMS source, procédez comme suit :
+ Créez un utilisateur PostgreSQL doté des autorisations appropriées pour AWS DMS fournir l'accès à votre base de données source PostgreSQL.
**Note**  
Si la base de données source PostgreSQL est autogérée, consultez [Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) pour plus d’informations.
Si la base de données source PostgreSQL est gérée par Amazon RDS, consultez [Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) pour plus d’informations.
+ Créez un point de terminaison source PostgreSQL conforme à la configuration de base de données PostgreSQL que vous avez choisie.
+ Créez une tâche ou un ensemble de tâches pour migrer vos tables.

  Pour créer une full-load-only tâche, aucune autre configuration de point de terminaison n'est nécessaire.

  Avant de créer une tâche pour la capture des données de modification (une tâche CDC uniquement ou une tâche de chargement complet \$1 CDC), consultez [Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) ou [Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC).

**Topics**
+ [Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites)
+ [Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL)
+ [Activation de la capture des données de modification (CDC) à l’aide de la réplication logique](#CHAP_Source.PostgreSQL.Security)
+ [Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL](#CHAP_Source.PostgreSQL.v10)
+ [Migration de PostgreSQL vers PostgreSQL à l'aide de AWS DMS](#CHAP_Source.PostgreSQL.Homogeneous)
+ [Migration depuis Babelfish pour Amazon Aurora PostgreSQL à l'aide de AWS DMS](#CHAP_Source.PostgreSQL.Babelfish)
+ [Supprimer AWS DMS des artefacts d'une base de données source PostgreSQL](#CHAP_Source.PostgreSQL.CleanUp)
+ [Paramètres de configuration supplémentaires lors de l’utilisation d’une base de données PostgreSQL en tant que source DMS](#CHAP_Source.PostgreSQL.Advanced)
+ [Lire la réplique en tant que source pour PostgreSQL](#CHAP_Source.PostgreSQL.ReadReplica)
+ [Utilisation du paramètre de point de `MapBooleanAsBoolean` terminaison PostgreSQL](#CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting)
+ [Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib)
+ [Limitations de l’utilisation d’une base de données PostgreSQL en tant que source DMS](#CHAP_Source.PostgreSQL.Limitations)
+ [Types de données sources pour PostgreSQL](#CHAP_Source-PostgreSQL-DataTypes)

## Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites"></a>

Avec une base de données PostgreSQL autogérée comme source, vous pouvez migrer les données vers une autre base de données PostgreSQL ou vers l'une des autres bases de données cibles prises en charge par. AWS DMS La base de données source peut être sur une base de données sur site ou un moteur autogéré s’exécutant sur une instance Amazon EC2. Vous pouvez utiliser une instance de base de données pour les tâches de chargement complet et pour les tâches de capture des données de modification (CDC).

### Conditions préalables à l'utilisation d'une base de données PostgreSQL autogérée en tant que source AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites.SelfManaged"></a>

Avant de migrer des données à partir d’une base de données source PostgreSQL autogérée, procédez comme suit : 
+ Assurez-vous d’utiliser une base de données PostgreSQL version 9.4.x ou ultérieure.
+ Pour les tâches de chargement complet \$1 CDC ou les tâches de CDC uniquement, accordez des autorisations de super-utilisateur pour le compte d’utilisateur spécifié pour la base de données source PostgreSQL. Le compte d’utilisateur a besoin d’autorisations de super-utilisateur pour accéder aux fonctions spécifiques à la réplication dans la source. Le compte utilisateur DMS a besoin des autorisations SELECT sur toutes les colonnes pour réussir la migration des tables. En cas d'autorisations manquantes sur les colonnes, DMS crée une table cible à l'aide de mappages de types de données DMS réguliers, ce qui entraîne des différences de métadonnées et des échecs de tâches.
+ Ajoutez l'adresse IP du serveur de AWS DMS réplication au fichier de `pg_hba.conf` configuration et activez la réplication et les connexions par socket. Un exemple suit.

  ```
              # Replication Instance
              host all all 12.3.4.56/00 md5
              # Allow replication connections from localhost, by a user with the
              # replication privilege.
              host replication dms 12.3.4.56/00 md5
  ```

  Le fichier de configuration `pg_hba.conf` de PostgreSQL contrôle l'authentification du client. (HBA signifie authentification basée sur l'hôte.) Le fichier est traditionnellement stocké dans le répertoire de données du cluster de base de données. 
+ Si vous configurez une base de données comme source de réplication logique à l'aide AWS DMS de [Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC)

**Note**  
Certaines AWS DMS transactions restent inactives pendant un certain temps avant que le moteur DMS ne les réutilise. En utilisant le paramètre `idle_in_transaction_session_timeout` dans PostgreSQL versions 9.6 et ultérieures, vous pouvez provoquer l’expiration et l’échec des transactions inactives. Ne mettez pas fin aux transactions inactives lorsque vous utilisez AWS DMS. 

### Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites.CDC"></a>

AWS DMS prend en charge la capture des données de modification (CDC) à l'aide de la réplication logique. Pour activer la réplication logique d’une base de données source PostgreSQL autogérée, définissez les paramètres suivants dans le fichier de configuration `postgresql.conf` :
+ Configurez `wal_level = logical`.
+ Définissez une valeur supérieure à 1 pour `max_replication_slots`.

  Définissez la valeur `max_replication_slots` selon le nombre de tâches que vous souhaitez exécuter. Par exemple, pour exécuter cinq tâches, vous définissez au moins cinq emplacements. Les emplacements s'ouvrent automatiquement dès qu'une tâche commence et restent ouvert même lorsque la tâche n'est plus en cours d'exécution. Assurez-vous de supprimer manuellement les emplacements ouverts. Notez que DMS supprime automatiquement les emplacements de réplication lorsque la tâche est supprimée, si DMS les a créés.
+ Définissez une valeur supérieure à 1 pour `max_wal_senders`.

  Le paramètre `max_wal_senders`définit le nombre de tâches simultanées qui peuvent s'exécuter.
+ Le paramètre `wal_sender_timeout` met fin aux connexions de réplication qui sont inactives plus longtemps que le nombre de millisecondes spécifié. La valeur par défaut pour une base de données PostgreSQL sur site est de 60 000 millisecondes (60 secondes). La définition de la valeur sur 0 (zéro) désactive le mécanisme d’expiration et constitue une valeur valide pour DMS.

  Lorsque vous définissez `wal_sender_timeout` sur une valeur différente de zéro, une tâche DMS avec CDC nécessite au moins 10 000 millisecondes (10 secondes) et échoue si la valeur est inférieure à 10 000. Définissez une valeur inférieure à 5 minutes pour éviter tout retard lors du basculement multi-AZ d’une instance de réplication DMS.

Certains paramètres sont statiques et vous ne pouvez les définir qu’au démarrage du serveur. Toute modification apportée à leurs entrées dans le fichier de configuration (pour une base de données autogérée) ou le groupe de paramètres de base de données (pour une base de données RDS for PostgreSQL) est ignorée jusqu’au redémarrage du serveur. Pour plus d’informations, consultez la [documentation sur PostgreSQL](https://www.postgresql.org/docs/current/intro-whatis.html).

Pour plus d’informations sur l’activation de la CDC, consultez [Activation de la capture des données de modification (CDC) à l’aide de la réplication logique](#CHAP_Source.PostgreSQL.Security).

## Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL"></a>

Vous pouvez utiliser une instance de base de données PostgreSQL AWS gérée comme source pour. AWS DMS Vous pouvez effectuer à la fois des tâches de chargement complet et des tâches de capture des données de modification (CDC) à l’aide d’une source PostgreSQL gérée par AWS. 

### Conditions préalables à l'utilisation d'une base de AWS données PostgreSQL gérée comme source DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.Prerequisites"></a>

Avant de migrer des données depuis une base de données source AWS PostgreSQL gérée, procédez comme suit :
+ Nous vous recommandons d'utiliser un compte AWS utilisateur avec les autorisations minimales requises pour l'instance de base de données PostgreSQL comme compte utilisateur pour le point de terminaison source PostgreSQL pour. AWS DMS L’utilisation du compte principal n’est pas recommandée. Le compte doit avoir le rôle `rds_superuser` et le rôle `rds_replication`. Le rôle `rds_replication` accorde les autorisations permettant de gérer des emplacements logiques et de diffuser les données à l’aide d’emplacements logiques.

  Assurez-vous de créer plusieurs objets à partir du compte d’utilisateur principal pour le compte que vous utilisez. Pour en savoir plus sur la création de ces objets, consultez [Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser).
+ Si la base de données source se trouve dans un cloud privé virtuel (VPC), choisissez le groupe de sécurité de VPC qui permet d’accéder à l’instance de base de données où réside la base de données. Cette action est nécessaire pour que l’instance de réplication DMS se connecte avec succès à l’instance de base de données source. Lorsque la base de données et l’instance de réplication DMS se trouvent dans le même VPC, ajoutez le groupe de sécurité approprié à ses propres règles entrantes.

**Note**  
Certaines AWS DMS transactions restent inactives pendant un certain temps avant que le moteur DMS ne les réutilise. En utilisant le paramètre `idle_in_transaction_session_timeout` dans PostgreSQL versions 9.6 et ultérieures, vous pouvez provoquer l’expiration et l’échec des transactions inactives. Ne mettez pas fin aux transactions inactives lorsque vous utilisez AWS DMS.

### Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC"></a>

AWS DMS prend en charge le CDC sur les bases de données PostgreSQL Amazon RDS lorsque l'instance de base de données est configurée pour utiliser la réplication logique. Le tableau suivant récapitule la compatibilité de réplication logique de chaque version de AWS PostgreSQL gérée. 


|  Version PostgreSQL  |  AWS DMS support de chargement complet   |  AWS DMS Soutien du CDC  | 
| --- | --- | --- | 
|  Compatibilité d’Aurora PostgreSQL version 2.1 avec PostgreSQL 10.5 (ou antérieur)  |  Oui  |  Non  | 
|  Compatibilité d’Aurora PostgreSQL version 2.2 avec PostgreSQL 10.6 (ou ultérieur)   |  Oui  |  Oui  | 
|  Compatibilité de RDS for PostgreSQL avec PostgreSQL 10.21 (ou ultérieur)  |  Oui  |  Oui  | 

**Pour activer la réplication logique pour une instance DB RDS PostgreSQL**

1. Utilisez le compte utilisateur AWS principal pour l'instance de base de données PostgreSQL comme compte utilisateur pour le point de terminaison source PostgreSQL. Le compte d'utilisateur principal a les rôles nécessaires qui lui permettent de configurer la capture des données modifiées. 

   Si vous utilisez un compte autre que le compte d’utilisateur principal, assurez-vous de créer plusieurs objets à partir du compte principal pour le compte que vous utilisez. Pour de plus amples informations, veuillez consulter [Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser).

1. Définissez le paramètre `rds.logical_replication` de votre groupe de paramètres DB CLUSTER sur 1. Ce paramètre statique nécessite un redémarrage de l'instance DB pour son application. Pour l'application de ce paramètre, AWS DMS définit les paramètres `wal_level`, `max_wal_senders`, `max_replication_slots` et `max_connections`. Ces modifications de paramètres peuvent augmenter la génération WAL (Write ahead log) ; de sorte qu’il faut uniquement définir `rds.logical_replication` lorsque vous utilisez des emplacements de réplication logique.

1. Le paramètre `wal_sender_timeout` met fin aux connexions de réplication qui sont inactives plus longtemps que le nombre de millisecondes spécifié. La valeur par défaut pour une base de données PostgreSQL AWS gérée est de 30 000 millisecondes (30 secondes). La définition de la valeur sur 0 (zéro) désactive le mécanisme d’expiration et constitue une valeur valide pour DMS.

   Lorsque vous définissez `wal_sender_timeout` sur une valeur différente de zéro, une tâche DMS avec CDC nécessite au moins 10 000 millisecondes (10 secondes) et échoue si la valeur est comprise entre 0 et 10 000. Définissez une valeur inférieure à 5 minutes pour éviter tout retard lors du basculement multi-AZ d’une instance de réplication DMS.

1.  Assurez-vous que la valeur du paramètre `max_worker_processes` dans le groupe de paramètres de votre cluster de bases de données est supérieure ou égale aux valeurs combinées totales de `max_logical_replication_workers`, `autovacuum_max_workers` et `max_parallel_workers`. Un nombre élevé de processus de travail en arrière-plan peut avoir un impact sur les charges de travail d’application sur les instances de petite taille. Vous devez donc surveiller les performances de la base de données si vous définissez `max_worker_processes` sur une valeur supérieure à la valeur par défaut.

1.  Lorsque vous utilisez Aurora PostgreSQL en tant que source avec CDC, définissez sur. `synchronous_commit` `ON`

**Pour utiliser PostgreSQL MultiAZ DB Cluster Read Replica pour CDC (réplication en cours)**

1. Définissez les `sync_replication_slots` paramètres `rds.logical_replication` et de votre groupe de paramètres DB CLUSTER sur 1. Ces paramètres statiques nécessitent un redémarrage de l'instance de base de données pour prendre effet.

1. Exécutez la commande suivante pour créer la `awsdms_ddl_audit` table sur Writer et pour la `objects_schema` remplacer par le nom du schéma à utiliser :

   ```
   CREATE TABLE objects_schema.awsdms_ddl_audit
   (
     c_key    bigserial primary key,
     c_time   timestamp,    -- Informational
     c_user   varchar(64),  -- Informational: current_user
     c_txn    varchar(16),  -- Informational: current transaction
     c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
     c_oid    integer,      -- For future use - TG_OBJECTID
     c_name   varchar(64),  -- For future use - TG_OBJECTNAME
     c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
     c_ddlqry  text         -- The DDL query associated with the current DDL event
   );
   ```

1. Exécutez la commande suivante pour créer la `awsdms_intercept_ddl` fonction et pour la `objects_schema` remplacer par le nom du schéma à utiliser :

   ```
   CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
     RETURNS event_trigger
   LANGUAGE plpgsql
   SECURITY DEFINER
     AS $$
     declare _qry text;
   BEGIN
     if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
            SELECT current_query() into _qry;
            insert into objects_schema.awsdms_ddl_audit
            values
            (
            default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
            );
            delete from objects_schema.awsdms_ddl_audit;
   end if;
   END;
   $$;
   ```

1. Exécutez la commande suivante pour créer le déclencheur `awsdms_intercept_ddl` d'événement :

   ```
   CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();
   ```

   Assurez-vous que tous les utilisateurs et tous les rôles qui accèdent à ces événements disposent des autorisations DDL nécessaires. Par exemple :

   ```
   grant all on public.awsdms_ddl_audit to public;
   grant all on public.awsdms_ddl_audit_c_key_seq to public;
   ```

1. Créez un emplacement de réplication sur Writer :

   ```
   SELECT * FROM pg_create_logical_replication_slot('dms_read_replica_slot', 'test_decoding', false, true);
   ```

1. Assurez-vous que le slot de réplication est disponible sur Reader :

   ```
   select * from pg_catalog.pg_replication_slots where slot_name = 'dms_read_replica_slot';
   
   slot_name            |plugin       |slot_type|datoid|database|temporary|active|active_pid|xmin|catalog_xmin|restart_lsn|confirmed_flush_lsn|wal_status|safe_wal_size|two_phase|inactive_since               |conflicting|invalidation_reason|failover|synced|
   ---------------------+-------------+---------+------+--------+---------+------+----------+----+------------+-----------+-------------------+----------+-------------+---------+-----------------------------+-----------+-------------------+--------+------+
   dms_read_replica_slot|test_decoding|logical  |     5|postgres|false    |false |          |    |3559        |0/180011B8 |0/180011F0         |reserved  |             |true     |2025-02-10 15:45:04.083 +0100|false      |                   |false   |false |
   ```

1. Créez un point de terminaison source DMS pour Read Replica et définissez le nom du slot de réplication logique via l'attribut Extra Connection :

   ```
   slotName=dms_read_replica_slot;
   ```

1. Créez et lancez la tâche CDC/FL\$1CDC.
**Note**  
Pour les migrations CDC/FL\$1CDC, DMS considère l'heure de début de la tâche comme la position de départ du CDC. Tous les anciens LSNs provenant du slot de réplication sont ignorés.

### Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser"></a>

Dans certains cas, vous risquez de ne pas utiliser le compte d’utilisateur principal pour l’instance de base de données Amazon RDS PostgreSQL que vous utilisez en tant que source. Dans ce cas, créez plusieurs objets afin de capturer des événements DDL (data definition language). Vous créez ces objets dans le compte autre que le compte principal, puis vous créez un déclencheur dans le compte utilisateur principal.

**Note**  
Si vous définissez le paramètre de point de terminaison `CaptureDdls` sur `false` sur le point de terminaison source, vous n’avez pas besoin de créer la table et le déclencheur suivants sur la base de données source.

Utilisez la procédure suivante pour créer ces objets.

**Pour créer des objets**

1. Choisissez le schéma où les objets doivent être créés. Le schéma par défaut est `public`. Assurez-vous que le schéma existe et qu'il est accessible par le compte `OtherThanMaster`. 

1. Connectez-vous à l’instance de base de données PostgreSQL en utilisant un compte d’utilisateur autre que le compte principal, à savoir le compte `OtherThanMaster` dans notre cas.

1. Créez la table `awsdms_ddl_audit` en exécutant la commande suivante, en remplaçant `objects_schema` dans le code suivant par le nom du schéma à utiliser.

   ```
   CREATE TABLE objects_schema.awsdms_ddl_audit
   (
     c_key    bigserial primary key,
     c_time   timestamp,    -- Informational
     c_user   varchar(64),  -- Informational: current_user
     c_txn    varchar(16),  -- Informational: current transaction
     c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
     c_oid    integer,      -- For future use - TG_OBJECTID
     c_name   varchar(64),  -- For future use - TG_OBJECTNAME
     c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
     c_ddlqry  text         -- The DDL query associated with the current DDL event
   );
   ```

1. Créez la fonction `awsdms_intercept_ddl` en exécutant la commande suivante, en remplaçant `objects_schema` dans le code suivant par le nom du schéma à utiliser.

   ```
   CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
     RETURNS event_trigger
   LANGUAGE plpgsql
   SECURITY DEFINER
     AS $$
     declare _qry text;
   BEGIN
     if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
            SELECT current_query() into _qry;
            insert into objects_schema.awsdms_ddl_audit
            values
            (
            default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
            );
            delete from objects_schema.awsdms_ddl_audit;
   end if;
   END;
   $$;
   ```

1. Déconnectez-vous du compte `OtherThanMaster` et connectez-vous avec un compte auquel le rôle `rds_superuser` a été attribué.

1. Créez le déclencheur d’événements `awsdms_intercept_ddl` en exécutant la commande suivante.

   ```
   CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
   EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();
   ```

1. Assurez-vous que tous les utilisateurs et rôles qui accèdent à ces événements disposent des autorisations DDL nécessaires. Par exemple :

   ```
   grant all on public.awsdms_ddl_audit to public;
   grant all on public.awsdms_ddl_audit_c_key_seq to public;
   ```

Une fois que vous avez terminé la procédure précédente, vous pouvez créer le point de terminaison source AWS DMS à l'aide du compte `OtherThanMaster`.

**Note**  
Ces événements sont déclenchés par les instructions `CREATE TABLE`, `ALTER TABLE` et `DROP TABLE`.

## Activation de la capture des données de modification (CDC) à l’aide de la réplication logique
<a name="CHAP_Source.PostgreSQL.Security"></a>

Vous pouvez utiliser la fonctionnalité de réplication logique native de PostgreSQL pour activer la capture des données de modification (CDC) lors de la migration de base de données pour les sources PostgreSQL. Vous pouvez utiliser cette fonctionnalité avec une instance de base de données PostgreSQL autogérée et avec une instance de base de données SQL Amazon RDS for PostgreSQL. Cette approche réduit les temps d’arrêt et permet de garantir que la base de données cible est synchronisée avec la base de données PostgreSQL source.

AWS DMS prend en charge le CDC pour les tables PostgreSQL avec des clés primaires. Si une table ne possède pas de clé primaire, les journaux d'écriture anticipée (WAL) n'incluent pas d'image antérieure de la ligne de base de données. Dans ce cas, DMS ne peut pas mettre à jour la table. Ici, vous pouvez utiliser des paramètres de configuration supplémentaires et l’identité du réplica de table comme solution de contournement. Toutefois, cette approche peut générer des journaux supplémentaires. Nous vous recommandons d’utiliser l’identité du réplica de table comme solution de contournement uniquement après avoir effectué des tests méticuleux. Pour de plus amples informations, veuillez consulter [Paramètres de configuration supplémentaires lors de l’utilisation d’une base de données PostgreSQL en tant que source DMS](#CHAP_Source.PostgreSQL.Advanced).

**Note**  
REPLICA IDENTITY FULL est compatible avec un plug-in de décodage logique, mais pas avec un plug-in pglogical. Pour plus d’informations, consultez la [documentation de pglogical](https://github.com/2ndQuadrant/pglogical#primary-key-or-replica-identity-required).

Pour le chargement complet et les tâches CDC et CDC uniquement, AWS DMS utilise des emplacements de réplication logiques pour conserver les journaux WAL à des fins de réplication jusqu'à ce qu'ils soient décodés. Au redémarrage (et non à la reprise) pour une tâche de chargement complet \$1 CDC ou une tâche de CDC, l’emplacement de réplication est recréé.

**Note**  
Pour le décodage logique, DMS utilise le plug-in test\$1decoding ou pglogical. Si le plug-in pglogical est disponible sur une base de données PostgreSQL source, DMS crée un emplacement de réplication à l’aide de pglogical. Sinon, un plug-in test\$1decoding est utilisé. Pour plus d’informations sur le plug-in test\$1decoding, consultez la [documentation de PostgreSQL](https://www.postgresql.org/docs/9.4/test-decoding.html).  
Si le paramètre de base de données `max_slot_wal_keep_size` est défini sur une valeur autre que celle par défaut et que le paramètre `restart_lsn` d’un emplacement de réplication dépasse la taille du LSN actuel, la tâche DMS échoue en raison de la suppression des fichiers WAL requis.

### Configuration du plug-in pglogical
<a name="CHAP_Source.PostgreSQL.Security.Pglogical"></a>

Mis en œuvre en tant qu’extension PostgreSQL, le plug-in pglogical est un système et un modèle de réplication logique pour la réplication sélective des données. Le tableau suivant identifie les versions de base de données PostgreSQL source qui prennent en charge le plug-in pglogical.


|  Source PostgreSQL   |  Prend en charge pglogical  | 
| --- | --- | 
|  PostgreSQL 9.4 autogéré ou version ultérieure  |  Oui  | 
|  Amazon RDS PostgreSQL 9.5 ou version antérieure  |  Non  | 
|  Amazon RDS PostgreSQL 9.6 ou version ultérieure  |  Oui  | 
|  Aurora PostgreSQL 1.x jusqu’à 2.5.x  |  Non  | 
|  Aurora PostgreSQL 2.6.x ou version ultérieure  |  Oui  | 
|  Aurora PostgreSQL 3.3.x ou version ultérieure  |  Oui  | 

Avant de configurer pglogical pour l'utiliser avec AWS DMS, activez d'abord la réplication logique pour la capture des données de modification (CDC) sur votre base de données source PostgreSQL. 
+ Pour en savoir plus sur l’activation de la réplication logique pour la CDC sur les bases de données sources PostgreSQL *autogérées*, consultez [Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC).
+ Pour en savoir plus sur l’activation de la réplication logique pour la CDC sur les bases de données sources PostgreSQL *gérées par AWS*, consultez [Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC).

Une fois la réplication logique activée sur la base de données source PostgreSQL, suivez les étapes ci-dessous pour configurer pglogical en vue de son utilisation avec DMS.

**Pour utiliser le plugin pglogical pour une réplication logique sur une base de données source PostgreSQL avec AWS DMS**

1. Créez une extension pglogical sur la base de données PostgreSQL source :

   1. Définissez le paramètre correct :
      + Pour les bases de données PostgreSQL autogérées, définissez le paramètre de base de données `shared_preload_libraries= 'pglogical'`.
      + Pour les bases de données PostgreSQL sur Amazon RDS et Amazon Aurora PostgreSQL-Compatible Edition, définissez le paramètre `shared_preload_libraries` sur `pglogical` dans le même groupe de paramètres RDS.

   1. Redémarrez la base de données source PostgreSQL.

   1. Sur la base de données PostgreSQL, exécutez la commande `create extension pglogical;`.

1. Exécutez la commande suivante pour vérifier que pglogical a été correctement installé :

   `select * FROM pg_catalog.pg_extension`

Vous pouvez désormais créer une AWS DMS tâche qui capture les données de modification pour le point de terminaison de votre base de données source PostgreSQL.

**Note**  
Si vous n’activez pas pglogical dans la base de données source PostgreSQL, AWS DMS utilise le plug-in `test_decoding` par défaut. Lorsque pglogical est activé pour le décodage logique, AWS DMS utilise pglogical par défaut. Mais vous pouvez définir l’attribut de connexion supplémentaire, `PluginName`, pour utiliser le plug-in `test_decoding` à la place.

## Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL
<a name="CHAP_Source.PostgreSQL.v10"></a>

Pour activer les points de départ CDC natifs avec PostgreSQL en tant que source, définissez l’attribut de connexion supplémentaire `slotName` sur le nom d’un emplacement de réplication logique existant lorsque vous créez le point de terminaison. Cet emplacement de réplication logique contient les modifications en cours à partir du moment de la création du point de terminaison, il prend donc en charge la réplication à partir d'un point précédent dans le temps. 

PostgreSQL écrit les modifications de base de données dans des fichiers WAL qui sont uniquement ignorés après qu' AWS DMS a réussi à lire les modifications à partir de l'emplacement de réplication logique. L'utilisation d'emplacements de réplication logique permet de protéger les modifications consignées, pour qu’elles ne soient pas supprimées avant d’être consommées par le moteur de réplication. 

Toutefois, selon le taux de changement et de consommation, les modifications conservées dans un emplacement de réplication logique peuvent entraîner une utilisation élevée du disque. Nous vous recommandons de définir des alarmes d’utilisation de l’espace dans l’instance PostgreSQL source lorsque vous utilisez des emplacements de réplication logique. Pour de plus amples informations sur l'utilisation de l'attribut de connexion supplémentaire `slotName`, veuillez consulter [Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib).

La procédure suivante décrit cette approche plus en détail.

**Pour utiliser un point de départ CDC natif afin de configurer une charge CDC d'un point de terminaison source PostgreSQL**

1. Identifiez l'emplacement de réplication logique utilisé par une tâche de réplication antérieure (tâche parent) que vous souhaitez utiliser comme point de départ. Interrogez ensuite la `pg_replication_slots` vue sur votre base de données source pour vous assurer que cet emplacement ne possède aucune connexion active. S’il en a, résolvez-les et fermez-les avant de poursuivre.

   Pour les étapes suivantes, il faut supposer que votre emplacement de réplication logique est `abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef`. 

1. Créez un nouveau point de terminaison source qui inclut le paramètre d'attribut de connexion supplémentaire suivant.

   ```
   slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;
   ```

1. Créez une nouvelle tâche uniquement CDC à l'aide de la console AWS CLI ou AWS DMS de l'API. Par exemple, à l’aide de l’interface de ligne de commande, vous pouvez exécuter la commande `create-replication-task` suivante. 

   ```
   aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test 
   --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 
   --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 
   --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE 
   --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" 
   --replication-task-settings "file://task-pg.json"
   ```

   Dans la commande précédente, les options suivantes sont définies :
   + L’option `source-endpoint-arn` est définie sur la nouvelle valeur que vous avez créée à l’étape 2.
   + L’option `replication-instance-arn` est définie sur la même valeur que pour la tâche parent à l’étape 1.
   + Les options `table-mappings` et `replication-task-settings` sont définies sur les mêmes valeurs que pour la tâche parent à l’étape 1.
   + L’option `cdc-start-position` est définie sur une valeur de position de départ. Pour trouver cette position de départ, recherchez la vue `pg_replication_slots` de votre base de données source ou affichez les détails de la console pour la tâche parent à l'étape 1. Pour de plus amples informations, veuillez consulter [Définition d'un point de départ natif CDC](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint.Native).

   Pour activer le mode de démarrage CDC personnalisé lors de la création d'une nouvelle tâche uniquement CDC à l'aide de la AWS DMS console, procédez comme suit :
   + Dans la section **Paramètres de tâche**, pour **Mode de départ CDC pour les transactions sources**, choisissez **Activer le mode de départ CDC personnalisé**.
   + Pour **Point de départ CDC personnalisé pour les transactions sources**, choisissez **Spécifier un numéro de séquence de journal**. Spécifiez le numéro SCN ou choisissez **Spécifier un point de contrôle de récupération** et fournissez un point de contrôle de récupération.

   Lorsque cette tâche CDC s'exécute, AWS DMS une erreur est générée si le slot de réplication logique spécifié n'existe pas. Il déclenche également une erreur si la tâche n’est pas créée avec un paramètre valide pour `cdc-start-position`.

Lorsque vous utilisez des points de départ CDC natifs avec le plug-in pglogical et que vous souhaitez utiliser un nouvel emplacement de réplication, effectuez les étapes de configuration suivantes avant de créer une tâche de CDC. 

**Pour utiliser un nouvel emplacement de réplication qui n’a pas été créé précédemment dans le cadre d’une autre tâche DMS**

1. Créez un emplacement de réplication, comme indiqué ci-dessous :

   ```
   SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');
   ```

1. Une fois que la base de données a créé l’emplacement de réplication, obtenez les valeurs de **restart\$1lsn** et **confirmed\$1flush\$1lsn** pour l’emplacement et notez-les :

   ```
   select * from pg_replication_slots where slot_name like 'replication_slot_name';
   ```

   Notez que la position de départ CDC native d’une tâche de CDC créée après l’emplacement de réplication ne peut pas être antérieure à la valeur de **confirmed\$1flush\$1lsn**.

   Pour en savoir plus sur les valeurs de **restart\$1lsn** et **confirmed\$1flush\$1lsn**, consultez [pg\$1replication\$1slots](https://www.postgresql.org/docs/14/view-pg-replication-slots.html). 

1. Créez un nœud pglogical.

   ```
   SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');
   ```

1. Créez deux ensembles de réplications à l’aide de la fonction `pglogical.create_replication_set`. Le premier ensemble de réplications assure le suivi des mises à jour et des suppressions des tables dotées de clés primaires. Le deuxième ensemble de réplications assure uniquement le suivi des insertions et porte le même nom que le premier ensemble de réplications, avec le préfixe « i ».

   ```
   SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false);
   SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true);
   ```

1. Ajoutez une table à l’ensemble de réplications.

   ```
   SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true);
   SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true);
   ```

1. Définissez l’attribut de connexion supplémentaire (ECA) suivant lorsque vous créez le point de terminaison source.

   ```
   PluginName=PGLOGICAL;slotName=slot_name;
   ```

Vous pouvez désormais créer une tâche de CDC uniquement avec un point de départ natif PostgreSQL à l’aide du nouvel emplacement de réplication. Pour plus d’informations sur le plug-in pglogical, consultez la [documentation de pglogical 3.7](https://www.enterprisedb.com/docs/pgd/3.7/pglogical/).

## Migration de PostgreSQL vers PostgreSQL à l'aide de AWS DMS
<a name="CHAP_Source.PostgreSQL.Homogeneous"></a>

Lorsque vous migrez d'un moteur de base de données autre que PostgreSQL vers une base de données PostgreSQL AWS DMS , c'est presque toujours le meilleur outil de migration à utiliser. En revanche, lorsque vous effectuez une migration à partir d’une base de données PostgreSQL vers une base de données PostgreSQL, les outils PostgreSQL peuvent être plus efficaces.

### Utilisation des outils natifs PostgreSQL pour migrer des données
<a name="CHAP_Source.PostgreSQL.Homogeneous.Native"></a>

Nous vous recommandons d’utiliser les outils de migration de base de données PostgreSQL, par exemple `pg_dump`, dans les conditions suivantes : 
+ Vous avez une migration homogène, dans laquelle vous effectuez une migration d'une base de données PostgreSQL source vers une base de données PostgreSQL cible. 
+ Vous migrez une base de données entière.
+ Les outils natifs vous permettent de migrer vos données avec une interruption minimale. 

L’utilitaire pg\$1dump utilise la commande COPY pour créer un schéma et un vidage des données d’une base de données PostgreSQL. Le script de vidage généré par pg\$1dump charge les données dans une base de données portant le même nom et recrée les tables, les index et les clés étrangères. Pour restaurer les données dans une base de données portant un autre nom, utilisez la commande `pg_restore` et le paramètre `-d`.

Si vous migrez des données d’une base de données source PostgreSQL exécutée sur EC2 vers une cible Amazon RDS for PostgreSQL, vous pouvez utiliser le plug-in pglogical.

Pour plus d’informations sur l’importation d’une base de données PostgreSQL dans Amazon RDS for PostgreSQL ou Amazon Aurora PostgreSQL-Compatible Edition, consultez [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html).

### Utilisation de DMS pour migrer des données de PostgreSQL vers PostgreSQL
<a name="CHAP_Source.PostgreSQL.Homogeneous.DMS"></a>

 AWS DMS peut migrer des données, par exemple, d'une base de données PostgreSQL source installée sur site vers une instance Amazon RDS for PostgreSQL ou Aurora PostgreSQL cible. La migration des types de données PostgreSQL principaux ou de base réussit souvent.

**Note**  
Lorsque vous répliquez des tables partitionnées d’une source PostgreSQL vers une cible PostgreSQL, il n’est pas nécessaire de mentionner la table parent dans les critères de sélection de la tâche DMS. En mentionnant la table parent, cela déclenche la duplication des données dans les tables enfants de la cible, ce qui peut entraîner une violation de la PK. En sélectionnant uniquement les tables enfants dans les critères de sélection du mappage de table, la table parent est automatiquement remplie.

Les types de données pris en charge sur la base de données source mais non pris en charge sur la cible risquent de ne pas réussir à migrer. AWS DMS diffuse certains types de données sous forme de chaînes si le type de données est inconnu. La migration de certains types de données, tels que JSON et XML, peut réussir s'il s'agit de fichiers peu volumineux, mais peut échouer s'il s'agit de documents volumineux. 

Lorsque vous effectuez une migration du type de données, prenez en considération ce qui suit :
+ Dans certains cas, le type de données PostgreSQL NUMERIC (p, s) ne spécifie aucune précision ni échelle. Pour DMS versions 3.4.2 et versions antérieures, DMS utilise une précision de 28 et une échelle de 6 par défaut, soit NUMERIC(28,6). Par exemple, la valeur 0,611111104488373 de la source est convertie en 0,611111 sur la cible PostgreSQL.
+ Une table avec un type de données ARRAY doit posséder une clé primaire. Une table dont le type de données ARRAY ne contient pas de clé primaire est suspendue pendant le chargement complet.

Le tableau suivant montre les types de données PostgreSQL source et indique si leur migration peut réussir :


| Type de données | Réussite de la migration | Migre partiellement | ne migre pas | Commentaires | 
| --- | --- | --- | --- | --- | 
| INTEGER | X |  |  |  | 
| SMALLINT | X |  |  |  | 
| BIGINT | X |  |  |  | 
| NUMERIC/DECIMAL(p,s) |  | X |  | Où 0<p<39 et 0<s | 
| NUMERIC/DECIMAL |  | X |  | Où p>38 ou p=s=0 | 
| REAL | X |  |  |  | 
| DOUBLE | X |  |  |  | 
| SMALLSERIAL | X |  |  |  | 
| SERIAL | X |  |  |  | 
| BIGSERIAL | X |  |  |  | 
| MONEY | X |  |  |  | 
| CHAR |  | X |  | Sans précision spécifiée | 
| CHAR(n) | X |  |  |  | 
| VARCHAR |  | X |  | Sans précision spécifiée | 
| VARCHAR(n) | X |  |  |  | 
| TEXT | X |  |  |  | 
| BYTEA | X |  |  |  | 
| TIMESTAMP | X |  |  | Les valeurs infinies positives et négatives sont tronquées à « 9999-12-31 23:59:59 » et « 4713-01-01 00:00:00 BC » respectivement. | 
| TIMESTAMP WITH TIME ZONE |  | X |  |  | 
| DATE | X |  |  |  | 
| TIME | X |  |  |  | 
| TIME WITH TIME ZONE | X |  |  |  | 
| INTERVAL |  | X |  |  | 
| BOOLEAN | X |  |  |  | 
| ENUM |  |  | X |  | 
| CIDR | X |  |  |  | 
| INET |  |  | X |  | 
| MACADDR |  |  | X |  | 
| TSVECTOR |  |  | X |  | 
| TSQUERY |  |  | X |  | 
| xml |  | X |  |  | 
| POINT | X |  |  | Type de données spatiales PostGIS | 
| LINE |  |  | X |  | 
| LSEG |  |  | X |  | 
| BOX |  |  | X |  | 
| PATH |  |  | X |  | 
| POLYGON | X |  |  | Type de données spatiales PostGIS | 
| CIRCLE |  |  | X |  | 
| JSON |  | X |  |  | 
| ARRAY | X |  |  | Nécessite une clé primaire | 
| COMPOSITE |  |  | X |  | 
| RANGE |  |  | X |  | 
| LINESTRING | X |  |  | Type de données spatiales PostGIS | 
| MULTIPOINT | X |  |  | Type de données spatiales PostGIS | 
| MULTILINESTRING | X |  |  | Type de données spatiales PostGIS | 
| MULTIPOLYGON | X |  |  | Type de données spatiales PostGIS | 
| GEOMETRYCOLLECTION | X |  |  | Type de données spatiales PostGIS | 

### Migration de types de données spatiales PostGIS
<a name="CHAP_Source.PostgreSQL.DataTypes.Spatial"></a>

Les *données spatiales* identifient les informations géométriques d'un objet ou d'un emplacement dans l'espace. Les bases de données relationnelles objet PostgreSQL prennent en charge les types de données spatiales PostGIS. 

Avant de migrer des objets de données spatiales PostgreSQL, assurez-vous que le plug-in PostGIS est activé au niveau global. Cela garantit la AWS DMS création des colonnes de données spatiales source exactes pour l'instance de base de données cible PostgreSQL.

Pour les migrations homogènes de PostgreSQL vers PostgreSQL AWS DMS , prend en charge la migration des types et sous-types d'objets de données géométriques et géographiques (coordonnées géodésiques) de PostGIS tels que les suivants :
+  POINT 
+  LINESTRING 
+  POLYGON 
+  MULTIPOINT 
+  MULTILINESTRING 
+  MULTIPOLYGON 
+  GEOMETRYCOLLECTION 

## Migration depuis Babelfish pour Amazon Aurora PostgreSQL à l'aide de AWS DMS
<a name="CHAP_Source.PostgreSQL.Babelfish"></a>

Vous pouvez migrer les tables sources PostgreSQL de Babelfish for Aurora vers tous les points de terminaison cibles pris en charge à l'aide de. AWS DMS

Lorsque vous créez votre point de terminaison AWS DMS source à l'aide de la console DMS, de l'API ou des commandes CLI, vous définissez la source **sur Amazon Aurora PostgreSQL** et le nom de la base de données sur. **babelfish\$1db** Dans la section **Paramètres du point de terminaison**, assurez-vous que le **DatabaseMode**est défini sur **Babelfish** et que le nom de la base de données Babelfish T-SQL source **BabelfishDatabaseName**est défini sur Babelfish. Au lieu d'utiliser le port TCP Babelfish**1433**, utilisez le port TCP Aurora PostgreSQL. **5432**

Vous devez créer vos tables avant de migrer les données afin de vous assurer que DMS utilise les types de données et les métadonnées de table appropriés. Si vous ne créez pas vos tables sur la cible avant d'exécuter la migration, DMS peut créer les tables avec des types de données et des autorisations incorrects.

### Ajout de règles de transformation à votre tâche de migration
<a name="CHAP_Source.PostgreSQL.Babelfish.Transform"></a>

Lorsque vous créez une tâche de migration pour une source Babelfish, vous devez inclure des règles de transformation garantissant que DMS utilise les tables cibles pré-créées.

Si vous avez défini le mode de migration multi-bases de données lorsque vous avez défini votre cluster Babelfish pour PostgreSQL, ajoutez une règle de transformation qui renomme le nom du schéma en schéma T-SQL. Par exemple, si le nom du schéma T-SQL est le même que `dbo` celui de votre schéma Babelfish pour PostgreSQL`mydb_dbo`, renommez le schéma en utilisant une règle de transformation. `dbo` *Pour trouver le nom du schéma PostgreSQL, [consultez l'architecture de Babelfish dans le guide de l'utilisateur](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/babelfish-architecture.html) Amazon Aurora.* 

Si vous utilisez le mode base de données unique, il n'est pas nécessaire d'utiliser une règle de transformation pour renommer les schémas de base de données. Les noms de schéma PostgreSQL sont mappés aux noms one-to-one de schéma de la base de données T-SQL.

L'exemple de règle de transformation suivant montre comment renommer le nom du schéma de `mydb_dbo` retour en `dbo` :

```
{
    "rules": [
        {
            "rule-type": "transformation",
            "rule-id": "566251737",
            "rule-name": "566251737",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "mydb_dbo"
            },
            "rule-action": "rename",
            "value": "dbo",
            "old-value": null
        },
        {
            "rule-type": "selection",
            "rule-id": "566111704",
            "rule-name": "566111704",
            "object-locator": {
                "schema-name": "mydb_dbo",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}
```

### Limitations liées à l'utilisation d'un point de terminaison source PostgreSQL avec des tables Babelfish
<a name="CHAP_Source.PostgreSQL.Babelfish.Limitations"></a>

Les limitations suivantes s'appliquent lors de l'utilisation d'un point de terminaison source PostgreSQL avec des tables Babelfish :
+ DMS prend uniquement en charge la migration depuis Babelfish version 16.2/15.6 et versions ultérieures, et DMS version 3.5.3 et ultérieure.
+ DMS ne reproduit pas les modifications de définition de table Babelfish sur le point de terminaison cible. Une solution à cette limitation consiste à appliquer d'abord les modifications de définition de table sur la cible, puis à modifier la définition de table sur la source Babelfish.
+ Lorsque vous créez des tables Babelfish avec le type de données BYTEA, DMS les convertit en type de `varbinary(max)` données lors de la migration vers SQL Server en tant que cible.
+ DMS ne prend pas en charge le mode LOB complet pour les types de données binaires. Utilisez plutôt le mode LOB limité pour les types de données binaires.
+ DMS ne prend pas en charge la validation des données pour Babelfish en tant que source.
+ Pour le réglage de la tâche **en mode de préparation de la table cible**, utilisez uniquement les modes **Ne rien faire** ou **Tronquer**. N’utilisez pas le mode **Supprimer les tables sur la cible**. Lorsque vous utilisez **Drop tables on target**, DMS peut créer les tables avec des types de données incorrects.
+ Lorsque vous utilisez la réplication continue (CDC ou Full load et CDC), définissez l'attribut de connexion `PluginName` supplémentaire (ECA) sur`TEST_DECODING`.
+ DMS ne prend pas en charge la réplication (CDC ou Full load et CDC) de tables partitionnées pour Babelfish en tant que source.

## Supprimer AWS DMS des artefacts d'une base de données source PostgreSQL
<a name="CHAP_Source.PostgreSQL.CleanUp"></a>

Pour capturer les événements DDL, AWS DMS crée divers artefacts dans la base de données PostgreSQL lorsqu'une tâche de migration démarre. Lorsque la tâche se termine, vous pouvez supprimer ces objets.

Pour supprimer les artefacts, émettez les instructions suivantes (dans leur ordre d’apparition), où `{AmazonRDSMigration}` est le schéma dans lequel les artefacts ont été créés. Procédez avec prudence lors de la suppression d’un schéma. Ne supprimez jamais un schéma opérationnel, surtout s'il est public.

```
drop event trigger awsdms_intercept_ddl;
```

Le déclencheur d'événements n'appartient pas à un schéma spécifique.

```
drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}
```

## Paramètres de configuration supplémentaires lors de l’utilisation d’une base de données PostgreSQL en tant que source DMS
<a name="CHAP_Source.PostgreSQL.Advanced"></a>

Vous pouvez ajouter des paramètres de configuration supplémentaires lors de la migration des données d'une base de données PostgreSQL de deux façons :
+ Vous pouvez ajouter des valeurs à l'attribut de connexion supplémentaire pour capturer les événements DDL et pour spécifier le schéma dans lequel les objets de base de données DDL opérationnelle sont créés. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib).
+ Vous pouvez remplacer les paramètres de chaîne de connexion. Choisissez cette option pour effectuer l’une des opérations suivantes :
  + Spécifiez les AWS DMS paramètres internes. Ces paramètres étant rarement nécessaires, ils ne sont pas présentés dans l’interface utilisateur.
  + Spécifiez les valeurs pass-through (passthru) pour le client de base de données spécifique. AWS DMS inclut des paramètres intermédiaires dans la chaîne de connexion transmise au client de base de données.
+ En utilisant le paramètre au niveau de la table dans les versions 9.4 et supérieures de `REPLICA IDENTITY` PostgreSQL, vous pouvez contrôler les informations écrites dans write-ahead logs (). WALs Il le fait notamment pour identifier WALs les lignes mises à jour ou supprimées. `REPLICA IDENTITY FULL`enregistre les anciennes valeurs de toutes les colonnes de la ligne. À utiliser `REPLICA IDENTITY FULL` avec précaution pour chaque table, car il n'est peut-être pas nécessaire de `FULL` générer un nombre supplémentaire de WALs ce qui pourrait ne pas être nécessaire. Pour plus d’informations, consultez [ALTER TABLE-REPLICA IDENTITY](https://www.postgresql.org/docs/devel/sql-altertable.html). 

## Lire la réplique en tant que source pour PostgreSQL
<a name="CHAP_Source.PostgreSQL.ReadReplica"></a>

Utilisez les répliques de lecture PostgreSQL comme sources CDC pour réduire la charge de la base de données AWS DMS principale. Cette fonctionnalité est disponible à partir de PostgreSQL 16.x et AWS DMS nécessite la version 3.6.1 ou ultérieure. L'utilisation de répliques de lecture pour le traitement par le CDC réduit l'impact opérationnel sur votre base de données principale.

**Note**  
La version 16.x d'Amazon RDS PostgreSQL comporte des limites en matière de réplication logique en lecture dans les configurations à trois AZ (TAZ). Pour une prise en charge complète de la réplication logique en lecture dans les déploiements TAZ, vous devez utiliser PostgreSQL version 17.x ou ultérieure.

### Conditions préalables
<a name="CHAP_Source.PostgreSQL.ReadReplica.prereq"></a>

Avant d'utiliser une réplique en lecture comme source CDC pour AWS DMS, vous devez activer la réplication logique à la fois sur l'instance de base de données principale et sur sa réplique en lecture afin de créer un décodage logique sur une réplique en lecture. Effectuez les opérations suivantes :
+ Activez la réplication logique à la fois sur votre instance de base de données principale et sur sa réplique en lecture, ainsi que sur tout autre paramètre de base de données requis. Pour plus d'informations, consultez la section [Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.RDSPostgreSQL).
+ Pour les tâches CDC uniquement, créez un emplacement de réplication sur l'instance principale (du rédacteur). Pour plus d'informations, consultez la section [Utilisation de points de départ CDC natifs pour configurer le chargement CDC d'une source PostgreSQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10). Cette action est nécessaire car les répliques en lecture ne prennent pas en charge la création d'un slot de réplication.
+ Pour PostgreSQL version 16, le slot doit être créé manuellement sur le réplica en lecture.
+ Pour les versions 17 et ultérieures de PostgreSQL, le slot de réplication doit être créé sur le serveur principal et il est automatiquement synchronisé avec le réplica en lecture.
+ Lorsque vous utilisez des tâches CDC à chargement complet ou uniquement des tâches CDC, AWS DMS vous pouvez gérer automatiquement les emplacements de réplication logiques sur les instances principales, mais pas sur les répliques en lecture. Pour les répliques de lecture de PostgreSQL version 16, vous devez supprimer et recréer manuellement les emplacements de réplication avant de redémarrer une tâche (et non de la reprendre). Le fait de sauter cette étape peut entraîner l'échec des tâches ou des positions de départ du CDC incorrectes. À partir de la version 17 de PostgreSQL, la synchronisation des emplacements logiques depuis l'instance principale automatise ce processus.

Une fois les conditions requises remplies, vous pouvez configurer votre point de terminaison AWS DMS source avec la réplication de la source `SlotName` de réplication lue dans les paramètres du point de terminaison et configurer votre AWS DMS tâche à l'aide des points de départ CDC natifs. Pour plus d'informations, voir [Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.ConnectionAttrib) [et Utilisation de points de départ CDC natifs pour configurer le chargement CDC d'une](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) source PostgreSQL.

## Utilisation du paramètre de point de `MapBooleanAsBoolean` terminaison PostgreSQL
<a name="CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting"></a>

Vous pouvez utiliser les paramètres de point de terminaison PostgreSQL pour mapper un booléen en tant que booléen de votre source PostgreSQL à une cible Amazon Redshift. Par défaut, un type BOOLEAN est migré au format varchar(5). Vous pouvez indiquer à `MapBooleanAsBoolean` d’autoriser PostgreSQL à migrer le type booléen en tant que booléen, comme illustré dans l’exemple suivant.

```
--postgre-sql-settings '{"MapBooleanAsBoolean": true}'
```

Notez que vous devez définir ce paramètre à la fois sur les points de terminaison sources et cibles pour qu’il prenne effet.

Comme MySQL n'a pas de type BOOLEAN, utilisez une règle de transformation plutôt que ce paramètre lors de la migration de données BOOLEAN vers MySQL.

## Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS
<a name="CHAP_Source.PostgreSQL.ConnectionAttrib"></a>

Vous pouvez utiliser les paramètres du point de terminaison et les attributs de connexion supplémentaires (ECAs) pour configurer votre base de données source PostgreSQL. Vous spécifiez les paramètres du point de terminaison lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--postgre-sql-settings '{"EndpointSetting": "value", ...}'` JSON.

Le tableau suivant indique les paramètres du point de terminaison ECAs que vous pouvez utiliser avec PostgreSQL en tant que source.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.PostgreSQL.html)

## Limitations de l’utilisation d’une base de données PostgreSQL en tant que source DMS
<a name="CHAP_Source.PostgreSQL.Limitations"></a>

Les limites suivantes s'appliquent lorsque vous utilisez PostgreSQL comme source pour AWS DMS :
+ AWS DMS ne fonctionne pas avec Amazon RDS pour PostgreSQL 10.4 ou Amazon Aurora PostgreSQL 10.4 en tant que source ou cible.
+ Une table capturée doit posséder une clé primaire. Si une table ne possède pas de clé primaire, AWS DMS ignore les opérations d'enregistrement DELETE et UPDATE pour cette table. Consultez [Activation de la capture des données de modification (CDC) à l’aide de la réplication logique](#CHAP_Source.PostgreSQL.Security) pour obtenir une solution de contournement. 

  **Remarque :** nous ne recommandons pas de migrer sans Key/Unique index principal, sinon des limitations supplémentaires s'appliquent, telles que la capacité « NON » d'application par lots, la fonctionnalité LOB complète, la validation des données et l'impossibilité de répliquer efficacement vers la cible Redshift.
+ AWS DMS ignore une tentative de mise à jour d'un segment de clé primaire. Dans ces cas, la cible identifie la mise à jour comme une mise à jour n'ayant mis à jour aucune ligne. Toutefois, comme les résultats de la mise à jour d'une clé primaire dans PostgreSQL sont imprévisibles, aucun enregistrement n'est écrit dans la table d'exceptions.
+ AWS DMS ne prend pas en charge l'option d'exécution **Start Process Changes from Timestamp**.
+ AWS DMS ne reproduit pas les modifications résultant d'opérations de partition ou de sous-partition (`ADD`,`DROP`, ou`TRUNCATE`).
+ La réplication de plusieurs tables portant le même nom lorsque chaque nom a une majuscule différente (par exemple, table1 et table1) peut entraîner un comportement imprévisible. TABLE1 En raison de ce problème, AWS DMS ne prend pas en charge ce type de réplication.
+ Dans la plupart des cas, AWS DMS prend en charge le traitement des modifications des instructions DDL CREATE, ALTER et DROP pour les tables. AWS DMS ne prend pas en charge ce traitement des modifications si les tables sont contenues dans un bloc de corps de fonction ou de procédure interne ou dans d'autres constructions imbriquées.

  Par exemple, la modification suivante n’est pas capturée.

  ```
  CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
  LANGUAGE plpgsql
  AS $$
  BEGIN
  create table attu.distributors1(did serial PRIMARY KEY,name
  varchar(40) NOT NULL);
  END;
  $$;
  ```
+ Actuellement, les types de données `boolean` dans une source PostgreSQL sont migrés vers une cible SQL Server en tant que type de données `bit` avec des valeurs incohérentes. Pour contourner le problème, créez au préalable le tableau avec un type de `VARCHAR(1)` données pour la colonne (ou faites AWS DMS créer le tableau). Ensuite, faites en sorte que le traitement en aval traite un « F » comme Faux et un « T » comme Vrai.
+ AWS DMS ne prend pas en charge le traitement des modifications des opérations TRUNCATE.
+ Le type de données LOB OID n'est pas migré vers la cible.
+ AWS DMS prend en charge le type de données PostGIS uniquement pour les migrations homogènes.
+ Si votre source est une base de données PostgreSQL sur site ou sur une instance Amazon EC2, assurez-vous que le plug-in de sortie test\$1decoding est installé sur le point de terminaison source. Vous trouverez ce plug-in dans le package contrib PostgreSQL. Pour plus d'informations sur le plug-in test\$1decoding, consultez la [documentation PostgreSQL](https://www.postgresql.org/docs/10/static/test-decoding.html).
+ AWS DMS ne prend pas en charge le traitement des modifications pour définir ou annuler les valeurs par défaut des colonnes (en utilisant la clause ALTER COLUMN SET DEFAULT sur les instructions ALTER TABLE).
+ AWS DMS ne prend pas en charge le traitement des modifications pour définir la nullité des colonnes (en utilisant la clause ALTER COLUMN [SET\$1DROP] NOT NULL sur les instructions ALTER TABLE).
+ Lorsque la réplication logique est activée, le nombre maximal de modifications conservées en mémoire par transaction est de 4 Mo. Ensuite, les modifications sont déversées sur le disque. En conséquence, `ReplicationSlotDiskUsage` augmente et `restart_lsn` n’avance pas tant que la transaction n’est pas terminée ou arrêtée et que la restauration n’est pas terminée. Comme il s’agit d’une transaction longue, sa restauration peut prendre beaucoup de temps. Évitez donc les transactions de longue durée ou les nombreuses sous-transactions lorsque la réplication logique est activée. Divisez plutôt la transaction en plusieurs transactions plus petites. 

  Sur les versions 13 et ultérieures d'Aurora PostgreSQL, vous pouvez régler le paramètre pour contrôler `logical_decoding_work_mem` le moment où des déversements de DMS modifient les données sur le disque. Pour de plus amples informations, veuillez consulter [Déversez des fichiers dans Aurora PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill).
+ Une table avec un type de données ARRAY doit posséder une clé primaire. Une table dont le type de données ARRAY ne contient pas de clé primaire est suspendue pendant le chargement complet.
+ AWS DMS ne prend pas en charge la migration des métadonnées des tables liées au partitionnement des tables ou à l'héritage des [tables.](https://www.postgresql.org/docs/15/ddl-inherit.html) Lorsque AWS DMS vous rencontrez une table partitionnée ou une table utilisant l'héritage, le comportement suivant est observé :
  + AWS DMS identifie et signale les tables parent et enfant impliquées dans le partitionnement ou l'héritage dans la base de données source.
  + **Création de table sur la cible** : dans la base de données cible, AWS DMS crée la table en tant que table standard (non partitionnée, non héritée), en préservant la structure et les propriétés des tables sélectionnées, mais pas la logique de partitionnement ou d'héritage.
  + **Différenciation des enregistrements dans les tables héritées** : pour les tables utilisant l'héritage, AWS DMS ne distingue pas les enregistrements appartenant aux tables enfants lors du remplissage de la table parent. Par conséquent, il n'utilise pas de requêtes SQL avec une syntaxe telle que :`SELECT * FROM ONLY parent_table_name`.
+ Afin de répliquer les tables partitionnés d’une source PostgreSQL vers une cible PostgreSQL, commencez par créer manuellement les tables parent et enfant sur la cible. Définissez ensuite une tâche distincte pour effectuer la réplication sur ces tables. Dans ce cas, définissez la configuration de la tâche sur **Tronquer avant le chargement**.
+ Le type de données PostgreSQL `NUMERIC` n'est pas fixe. Lors du transfert de données de type `NUMERIC` sans précision ni échelle, DMS utilise `NUMERIC(28,6)` (une précision de 28 et une échelle de 6) par défaut. Par exemple, la valeur 0,611111104488373 de la source est convertie en 0,611111 sur la cible PostgreSQL.
+ AWS DMS prend en charge Aurora PostgreSQL Serverless V1 en tant que source pour les tâches à chargement complet uniquement. AWS DMS prend en charge Aurora PostgreSQL Serverless V2 en tant que source pour les tâches à chargement complet, à chargement complet, CDC et CDC uniquement.
+ AWS DMS ne prend pas en charge la réplication d'une table avec un index unique créé à l'aide d'une fonction de coalesce.
+ Si la définition de la clé primaire sur la source et la cible ne correspond pas, les résultats de la réplication peuvent être imprévisibles.
+ Lorsque vous utilisez la fonctionnalité de chargement parallèle, la segmentation de table en fonction des partitions ou des sous-partitions n’est pas prise en charge. Pour plus d’informations sur le chargement parallèle, consultez [Utilisation du chargement parallèle pour certaines tables, vues et collections](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad). 
+ AWS DMS ne prend pas en charge les contraintes différées.
+ AWS DMS la version 3.4.7 prend en charge PostgreSQL 14.x en tant que source avec les limitations suivantes :
  + AWS DMS ne prend pas en charge le traitement des modifications lors de validations en deux phases.
  + AWS DMS ne prend pas en charge la réplication logique pour diffuser de longues transactions en cours.
+ AWS DMS ne prend pas en charge le proxy CDC pour Amazon RDS pour PostgreSQL en tant que source.
+ Lorsque vous utilisez des [filtres de source](CHAP_Tasks.CustomizingTasks.Filters.md) qui ne contiennent pas de colonne de clé primaire, les opérations `DELETE` ne sont pas capturées.
+ Si la base de données source est également la cible d’un autre système de réplication tiers, les modifications DDL risquent de ne pas être migrées pendant la CDC. En effet, cette situation peut empêcher le déclencheur d’événement `awsdms_intercept_ddl` de s’activer. Pour contourner ce problème, modifiez ce déclencheur dans la base de données source comme suit :

  ```
  alter event trigger awsdms_intercept_ddl enable always;
  ```
+ AWS DMS ne prend pas en charge la réplication des modifications apportées aux définitions de clés primaires dans la base de données source. Si la structure de la clé primaire est modifiée au cours d'une tâche de réplication active, les modifications ultérieures apportées aux tables concernées ne sont pas répliquées sur la cible.
+ Dans le cadre d'une réplication DDL dans le cadre d'un script, le nombre total maximum de commandes DDL par script est de 8192 et le nombre total maximum de lignes par script est de 8192 lignes.
+ AWS DMS ne prend pas en charge les vues matérialisées.
+ Pour le chargement complet et les tâches CDC utilisant une réplique en lecture comme source, il est AWS DMS impossible de créer des emplacements de réplication sur les répliques en lecture.

## Types de données sources pour PostgreSQL
<a name="CHAP_Source-PostgreSQL-DataTypes"></a>

Le tableau suivant indique les types de données sources PostgreSQL pris en charge lors de l' AWS DMS utilisation et le mappage AWS DMS par défaut vers les types de données.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données PostgreSQL  |  Types de données DMS  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  NUMERIC (p,s)  |  Si la précision se situe entre 0 et 38, utilisez NUMERIC. Si la précision est 39 ou supérieure, utilisez STRING.  | 
|  DECIMAL(P,S)  |  Si la précision se situe entre 0 et 38, utilisez NUMERIC. Si la précision est 39 ou supérieure, utilisez STRING.  | 
|  REAL  |  REAL4  | 
|  DOUBLE  |  REAL8  | 
|  SMALLSERIAL  |  INT2  | 
|  SERIAL  |  INT4  | 
|  BIGSERIAL  |  INT8  | 
|  MONEY  |  NUMERIC(38,4) Le type de données MONEY est mappé sur FLOAT dans SQL Server.  | 
|  CHAR  |  WSTRING (1)  | 
|  CHAR(N)  |  WSTRING (n)  | 
|  VARCHAR(N)  |  WSTRING (n)  | 
|  TEXT  |  NCLOB  | 
|  CITEXT  |  NCLOB  | 
|  BYTEA  |  BLOB  | 
|  TIMESTAMP  |  DATETIME  | 
|  TIMESTAMP WITH TIME ZONE  |  DATETIME  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIME WITH TIME ZONE  |  TIME  | 
|  INTERVAL  |  STRING (128) : 1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS  | 
|  BOOLEAN  |  CHAR (5) Vrai ou faux ?  | 
|  ENUM  |  STRING (64)  | 
|  CIDR  |  STRING (50)  | 
|  INET  |  STRING (50)  | 
|  MACADDR  |  STRING (18)  | 
|  BIT (n)  |  STRING (n)  | 
|  BIT VARYING (n)  |  STRING (n)  | 
|  UUID  |  CHAÎNE  | 
|  TSVECTOR  |  CLOB  | 
|  TSQUERY  |  CLOB  | 
|  xml  |  CLOB  | 
|  POINT  |  STRING (255) "(x,y)"  | 
|  LINE  |  STRING (255) "(x,y,z)"  | 
|  LSEG  |  STRING (255) "((x1,y1),(x2,y2))"  | 
|  BOX  |  STRING (255) "((x1,y1),(x2,y2))"  | 
|  PATH  |  CLOB "((x1,y1),(xn,yn))"  | 
|  POLYGON  |  CLOB "((x1,y1),(xn,yn))"  | 
|  CIRCLE  |  STRING (255) "(x,y),r"  | 
|  JSON  |  NCLOB  | 
|  JSONB  |  NCLOB  | 
|  ARRAY  |  NCLOB  | 
|  COMPOSITE  |  NCLOB  | 
|  HSTORE  |  NCLOB  | 
|  INT4GAMME  |  STRING (255)  | 
|  INT8GAMME  |  STRING (255)  | 
|  NUMRANGE  |  STRING (255)  | 
|  STRRANGE  |  STRING (255)  | 

### Utilisation des types de données source LOB pour PostgreSQL
<a name="CHAP_Source-PostgreSQL-DataTypes-LOBs"></a>

Les tailles de colonne PostgreSQL affectent la conversion des types de données LOB PostgreSQL en types de données AWS DMS . Pour utiliser cela, procédez comme suit pour les types de données AWS DMS  :
+ BLOB : définissez **Limiter la taille LOB à** sur la valeur **Taille LOB maximale (Ko)** lors de la création de la tâche.
+ CLOB — La réplication traite chaque caractère comme un UTF8 caractère. Par conséquent, recherchez la longueur de la chaîne de caractères la plus longue dans la colonne, à savoir `max_num_chars_text` dans cet exemple. Utilisez cette longueur pour spécifier la valeur de **Limiter la taille LOB à**. Si les données comprennent des caractères à 4 octets, multipliez par 2 pour spécifier la valeur, en octets, de **Limit LOB size to (Limiter la taille LOB à)** Dans ce cas, la valeur de **Limit LOB size to (Limiter la taille LOB à)** est égale à `max_num_chars_text` multiplié par 2.
+ NCLOB : la réplication gère chaque caractère en tant que caractère à deux octets. Par conséquent, recherchez la longueur de la chaîne de caractères la plus longue dans la colonne (`max_num_chars_text`) et multipliez-la par 2. Faites-le pour spécifier la valeur de **Limiter la taille LOB à**. Dans ce cas, la valeur de **Limit LOB size to (Limiter la taille LOB à)** est égale à `max_num_chars_text` multiplié par 2. Si les données comprennent des caractères à 4 octets, multipliez encore par 2. Dans ce cas, la valeur de **Limit LOB size to (Limiter la taille LOB à)** est égale à `max_num_chars_text` multiplié par 4.

# Utilisation d'une base de données compatible MySQL comme source pour AWS DMS
<a name="CHAP_Source.MySQL"></a>

Vous pouvez migrer des données depuis n'importe quelle base de données compatible MySQL (MySQL, MariaDB ou Amazon Aurora MySQL) à l'aide du Database Migration Service. AWS 

Pour plus d'informations sur les versions de MySQL AWS DMS prises en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md). 

Vous pouvez utiliser SSL pour chiffrer les connexions entre votre point de terminaison compatible MySQL et l'instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison compatible MySQL, consultez [Utilisation du protocole SSL avec AWS Database Migration Service](CHAP_Security.SSL.md).

Dans les sections suivantes, le terme « autogéré » s’applique à toute base de données installée sur site ou sur Amazon EC2. Le terme « géré par AWS » s’applique à toute base de données sur Amazon RDS, Amazon Aurora ou Amazon S3.

Pour plus de détails sur l'utilisation de bases de données compatibles avec MySQL AWS DMS, consultez les sections suivantes.

**Topics**
+ [Migration de MySQL vers MySQL en utilisant AWS DMS](#CHAP_Source.MySQL.Homogeneous)
+ [Utiliser n'importe quelle base de données compatible avec MySQL comme source pour AWS DMS](#CHAP_Source.MySQL.Prerequisites)
+ [Utilisation d'une base de données compatible MySQL autogérée comme source pour AWS DMS](#CHAP_Source.MySQL.CustomerManaged)
+ [Utilisation d'une base AWS de données compatible avec MySQL gérée comme source pour AWS DMS](#CHAP_Source.MySQL.AmazonManaged)
+ [Limitations relatives à l'utilisation d'une base de données MySQL comme source pour AWS DMS](#CHAP_Source.MySQL.Limitations)
+ [Prise en charge des transactions XA](#CHAP_Source.MySQL.XA)
+ [Paramètres du point de terminaison lors de l'utilisation de MySQL comme source pour AWS DMS](#CHAP_Source.MySQL.ConnectionAttrib)
+ [Types de données sources pour MySQL](#CHAP_Source.MySQL.DataTypes)

**Note**  
Lors de la configuration des règles de mappage AWS Database Migration Service (AWS DMS), il est important d'éviter d'utiliser des caractères génériques (%) pour les noms de base de données ou de schéma. Au lieu de cela, vous devez spécifier explicitement uniquement les bases de données créées par l'utilisateur qui doivent être migrées. L'utilisation d'un caractère générique inclut toutes les bases de données dans le processus de migration, y compris les bases de données système qui ne sont pas requises sur l'instance cible. Étant donné que l'utilisateur principal MySQL Amazon RDS ne dispose pas des autorisations nécessaires pour importer des données dans les bases de données du système cible, la tentative de migration de ces bases de données système échoue.

## Migration de MySQL vers MySQL en utilisant AWS DMS
<a name="CHAP_Source.MySQL.Homogeneous"></a>

Pour une migration hétérogène, lorsque vous migrez d'un moteur de base de données autre que MySQL vers une base de données MySQL, AWS DMS c'est presque toujours le meilleur outil de migration à utiliser. Mais pour une migration homogène, lorsque vous migrez d’une base de données MySQL vers une base de données MySQL, nous vous recommandons d’utiliser un projet de migrations de données homogènes. Les migrations de données homogènes utilisent des outils de base de données natifs pour fournir des performances et une précision de migration de données améliorées par rapport à AWS DMS.

## Utiliser n'importe quelle base de données compatible avec MySQL comme source pour AWS DMS
<a name="CHAP_Source.MySQL.Prerequisites"></a>

Avant de commencer à utiliser une base de données MySQL en tant que source pour AWS DMS, assurez-vous que vous remplissez les conditions préalables suivantes. Ces prérequis s'appliquent aux sources autogérées ou AWS gérées.

Vous devez disposer d'un compte AWS DMS doté du rôle d'administrateur de réplication. Ce rôle nécessite les privilèges suivants :
+ **REPLICATION CLIENT** : ce privilège est obligatoire pour les tâches de CDC uniquement. En d'autres termes, full-load-only les tâches ne nécessitent pas ce privilège. 
**Note**  
Pour la version 10.5.2\$1 de MariaDB, vous pouvez utiliser BINLOG MONITOR, qui remplace REPLICATION CLIENT.
+ **REPLICATION SLAVE** : ce privilège est obligatoire pour les tâches de CDC uniquement. En d'autres termes, full-load-only les tâches ne nécessitent pas ce privilège.
+ **SUPER** : ce privilège est nécessaire uniquement dans les versions de MySQL antérieures à 5.6.6.

L' AWS DMS utilisateur doit également disposer des privilèges SELECT pour les tables sources destinées à la réplication.

Accordez les privilèges suivants si vous utilisez des évaluations de prémigration spécifiques à MySQL :

```
grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only
```

Si vous utilisez une source RDS et que vous prévoyez d'exécuter des évaluations de prémigration spécifiques à MySQL, ajoutez l'autorisation suivante :

```
grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check
```

Si le paramètre `BatchEnable` est défini`true`, il est nécessaire d'accorder :

```
grant create temporary tables on `<schema>`.* to <dms_user>;
```

## Utilisation d'une base de données compatible MySQL autogérée comme source pour AWS DMS
<a name="CHAP_Source.MySQL.CustomerManaged"></a>

Vous pouvez utiliser les bases de données compatibles MySQL autogérées suivantes comme sources pour AWS DMS :
+ MySQL Community Edition
+ MySQL Standard Edition
+ MySQL Enterprise Edition
+ MySQL Cluster Carrier Grade Edition
+ MariaDB Community Edition
+ MariaDB Enterprise Edition
+ MariaDB Column Store

Pour utiliser la CDC, assurez-vous d’activer la journalisation binaire. Pour activer la journalisation binaire, les paramètres suivants doivent être configurés dans le fichier `my.ini` (Windows) ou `my.cnf` (UNIX) de MySQL.


| Paramètre | Value | 
| --- | --- | 
| `server_id` | Définissez ce paramètre à une valeur 1 ou supérieure. | 
| `log-bin` | Définissez le chemin d'accès au fichier journal binaire, par exemple `log-bin=E:\MySql_Logs\BinLog`. N'ajoutez pas d'extension de fichier. | 
| `binlog_format` | Définissez ce paramètre à `ROW`. Nous recommandons d’utiliser ce paramètre lors de la réplication car, dans certains cas, lorsque `binlog_format` est défini sur `STATEMENT`, cela peut entraîner des incohérences lors de la réplication des données sur la cible. Le moteur de base de données écrit également des données incohérentes similaires sur la cible lorsque `binlog_format` est défini sur `MIXED`, car le moteur de base de données bascule automatiquement vers la journalisation basée sur `STATEMENT`, ce qui peut entraîner l’écriture de données incohérentes dans la base de données cible. | 
| `expire_logs_days` | Définissez ce paramètre à une valeur 1 ou supérieure. Pour éviter l'utilisation excessive d'espace disque, nous recommandons de ne pas utiliser la valeur par défaut de 0. | 
| `binlog_checksum` | Définissez ce paramètre sur `NONE` pour la version 3.4.7 ou antérieure de DMS. | 
| `binlog_row_image` | Définissez ce paramètre à `FULL`. | 
| `log_slave_updates` | Définissez ce paramètre sur `TRUE` si vous utilisez un réplica en lecture MySQL ou MariaDB comme source. | 

Si vous utilisez une réplique en lecture MySQL ou MariaDB comme source pour une tâche de migration DMS en **utilisant le mode Migrer les données existantes et répliquer les modifications en cours**, il existe un risque de perte de données. DMS n'écrit pas de transaction pendant le chargement complet ou pendant le CDC dans les conditions suivantes :
+ La transaction avait été validée sur l'instance principale avant le début de la tâche DMS.
+ La transaction n'a été validée dans la réplique qu'après le démarrage de la tâche DMS, en raison du décalage entre l'instance principale et la réplique.

Plus le délai entre l'instance principale et la réplique est long, plus le risque de perte de données est élevé.

Si votre source utilise le moteur de base de données NDB (en cluster), les paramètres suivants doivent être configurés pour permettre la capture des données modifiées sur les tables qui utilisent ce moteur de stockage. Ajoutez ces modifications dans le fichier `my.ini` (Windows) ou `my.cnf` (UNIX) de MySQL.


| Paramètre | Value | 
| --- | --- | 
| `ndb_log_bin` | Définissez ce paramètre à `ON`. Cette valeur garantit que les modifications dans les tables en cluster sont journalisées dans le journal binaire. | 
| `ndb_log_update_as_write` | Définissez ce paramètre à `OFF`. Cette valeur empêche d'écrire des instructions UPDATE en tant qu'instructions INSERT dans le journal binaire. | 
| `ndb_log_updated_only` | Définissez ce paramètre à `OFF`. Cette valeur permet de s'assurer que le journal binaire contient l'ensemble de la ligne, pas seulement les colonnes modifiées. | 

## Utilisation d'une base AWS de données compatible avec MySQL gérée comme source pour AWS DMS
<a name="CHAP_Source.MySQL.AmazonManaged"></a>

Vous pouvez utiliser les bases de données compatibles avec MySQL AWS gérées suivantes comme sources pour : AWS DMS
+ MySQL Community Edition
+ MariaDB Community Edition
+ Amazon Aurora MySQL-Compatible Edition

Lorsque vous utilisez une base de données compatible avec MySQL AWS gérée comme source pour AWS DMS, assurez-vous de remplir les conditions préalables suivantes pour le CDC :
+ Pour activer les journaux binaires pour RDS for MySQL et pour RDS for MariaDB, activez les sauvegardes automatiques au niveau de l’instance. Pour activer les journaux binaires pour un cluster Aurora MySQL, modifiez la variable `binlog_format` dans le groupe de paramètres.

  Pour plus d’informations sur la configuration des sauvegardes automatiques, consultez [Utilisation des sauvegardes](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) dans le *Guide de l’utilisateur Amazon RDS*.

  Pour plus d’informations sur la configuration de la journalisation binaire pour une base de données Amazon RDS for MySQL, consultez [Configuration de la journalisation binaire MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) dans le *Guide de l’utilisateur Amazon RDS*. 

  Pour plus d’informations sur la configuration de la journalisation binaire pour un cluster Aurora MySQL, consultez [Comment puis-je activer la journalisation binaire pour mon cluster Amazon Aurora MySQL ?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/) 
+ Si vous envisagez d’utiliser la CDC, activez la journalisation binaire. Pour plus d’informations sur la configuration de la journalisation binaire pour une base de données Amazon RDS for MySQL, consultez [Configuration de la journalisation binaire MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) dans le *Guide de l’utilisateur Amazon RDS*.
+ Assurez-vous que les journaux binaires sont disponibles pour AWS DMS. Étant donné que les bases de données compatibles avec MySQL AWS gérées purgent les journaux binaires dès que possible, vous devez augmenter la durée pendant laquelle les journaux restent disponibles. Par exemple, pour accroître la rétention des journaux à 24 heures, exécutez la commande suivante. 

  ```
   call mysql.rds_set_configuration('binlog retention hours', 24);
  ```
+ Définissez le paramètre `binlog_format` sur `"ROW"`.
**Note**  
Sur MySQL ou MariaDB, `binlog_format` est un paramètre dynamique. Vous n’avez donc pas besoin de redémarrer pour que la nouvelle valeur prenne effet. Toutefois, la nouvelle valeur ne s’appliquera qu’aux nouvelles sessions. Si vous redéfinissez `binlog_format` sur `ROW` à des fins de réplication, la base de données peut toujours créer des journaux binaires ultérieurs en utilisant le format `MIXED`, si ces sessions ont débuté avant que vous n’ayez modifié la valeur. Cela peut AWS DMS empêcher de capturer correctement toutes les modifications apportées à la base de données source. Lorsque vous modifiez le paramètre `binlog_format` sur une base de données MariaDB ou MySQL, veillez à redémarrer la base de données pour fermer toutes les sessions existantes, ou à redémarrer toute application effectuant des opérations DML (Data Manipulation Language). Le fait de forcer votre base de données à redémarrer toutes les sessions après avoir modifié le `binlog_format` paramètre pour `ROW` garantir que votre base de données écrit toutes les modifications ultérieures de la base de données source dans le bon format, afin de AWS DMS pouvoir correctement capturer ces modifications.
+ Définissez le paramètre `binlog_row_image` sur `"Full"`. 
+ Définissez le `binlog_checksum` paramètre sur `"NONE"` pour la version 3.4.7 ou antérieure de DMS. Pour plus d’informations sur la définition des paramètres dans Amazon RDS MySQL, consultez [Utilisation des sauvegardes](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) dans le *Guide de l’utilisateur Amazon RDS*.
+ Si vous utilisez un réplica en lecture Amazon RDS MySQL ou Amazon RDS MariaDB en tant que source, activez les sauvegardes sur le réplica en lecture et assurez-vous de définir le paramètre `log_slave_updates` sur `TRUE`.

## Limitations relatives à l'utilisation d'une base de données MySQL comme source pour AWS DMS
<a name="CHAP_Source.MySQL.Limitations"></a>

Lorsque vous utilisez une base de données MySQL comme source, tenez compte des éléments suivants :
+  La capture des données de modification (CDC) n’est pas prise en charge pour Amazon RDS MySQL 5.5 ou antérieur. Pour Amazon RDS MySQL, vous devez utiliser la version 5.6, 5.7 ou 8.0 pour activer la CDC. La CDC est prise en charge pour les sources MySQL 5.5 autogérées. 
+ Pour la CDC, `CREATE TABLE`, `ADD COLUMN`, `DROP COLUMN`, la modification du type de données de colonne et `renaming a column` sont pris en charge. Toutefois, `DROP TABLE`, `RENAME TABLE` et les mises à jour apportées à d’autres attributs, tels que la valeur par défaut de la colonne, la possibilité de valeur NULL de la colonne, le jeu de caractères, etc., ne sont pas pris en charge.
+  Pour les tables partitionnées sur la source, lorsque vous définissez le **mode de préparation des tables cibles** sur **Supprimer les tables sur la cible**, vous AWS DMS créez une table simple sans aucune partition sur la cible MySQL. Pour migrer des tables partitionnées vers une table partitionnée sur la cible, créez à l’avance les tables partitionnées sur la base de données MySQL cible.
+  L'utilisation d'une `ALTER TABLE table_name ADD COLUMN column_name` instruction pour ajouter des colonnes au début (FIRST) ou au milieu d'un tableau (AFTER) n'est pas prise en charge pour les cibles relationnelles. Les colonnes sont toujours ajoutées à la fin de la table. Lorsque la cible est Amazon S3 ou Amazon Kinesis Data Streams, l'ajout de colonnes à l'aide de FIRST ou AFTER est pris en charge.
+ La capture des données modifiées (CDC) n'est pas prise en charge quand un nom de table contient des caractères minuscules et majuscules, et le moteur source est hébergé sur un système d'exploitation avec des noms de fichier sensibles à la casse. Un exemple est Microsoft Windows ou OS X utilisant HFS\$1.
+ Vous pouvez utiliser Aurora MySQL Compatible Edition Serverless v1 pour le chargement complet, mais vous ne pouvez pas l'utiliser pour CDC. En effet, vous ne pouvez pas activer les prérequis pour MySQL. Pour plus d’informations , consultez [Groupes de paramètres et Aurora sans serveur v1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups). 

  Aurora MySQL Compatible Edition Serverless v2 prend en charge le CDC.
+  L'attribut AUTO\$1INCREMENT sur une colonne n'est pas migré vers une colonne de base de données cible.
+  La capture des modifications n'est pas prise en charge lorsque les journaux binaires ne sont pas stockés sur un stockage en bloc standard. Par exemple, le CDC ne fonctionne pas lorsque les journaux binaires sont stockés sur Amazon S3.
+  AWS DMS crée des tables cibles avec le moteur de stockage InnoDB par défaut. Si vous avez besoin d'utiliser un moteur de stockage autre qu'InnoDB, vous devez créer manuellement la table et y migrer les données à l'aide du [mode « Ne rien faire »](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
+ Vous ne pouvez pas utiliser les répliques Aurora MySQL comme source, AWS DMS sauf si le mode de tâche de migration de votre DMS est **Migrer les données existantes**, chargement complet uniquement.
+  Si la source compatible avec MySQL est arrêtée pendant le chargement complet, la AWS DMS tâche ne s'arrête pas avec une erreur. La tâche se termine avec succès, mais la cible peut ne pas être synchronisée avec la source. Si cela se produit, redémarrez la tâche ou rechargez les tables affectées.
+  Les index créés sur une partie d'une valeur de colonne ne sont pas migrés. Par exemple, l'index CREATE INDEX first\$1ten\$1chars ON customer (name(10)) n'est pas créé sur la cible.
+ Dans certains cas, la tâche est configurée pour ne pas être répliquée LOBs (la valeur SupportLobs « » est fausse dans les paramètres de la tâche ou l'**option Ne pas inclure les colonnes LOB** est sélectionnée dans la console des tâches). Dans ces cas, AWS DMS ne migre aucune colonne MEDIUMBLOB, LONGBLOB, MEDIUMTEXT et LONGTEXT vers la cible.

  Les colonnes BLOB, TINYBLOB, TEXT et TINYTEXT ne sont pas affectées et sont migrées vers la cible.
+ Les tables de données temporelles ou les tables gérées par version du système ne sont pas prises en charge dans les bases de données sources et cibles MariaDB.
+ En cas de migration entre deux clusters Amazon RDS Aurora MySQL, le point de terminaison source RDS Aurora MySQL doit être read/write une instance et non une instance de réplique. 
+ AWS DMS ne prend actuellement pas en charge la migration des vues pour MariaDB.
+ AWS DMS ne prend pas en charge les modifications DDL pour les tables partitionnées pour MySQL. Pour ignorer la suspension de table en cas de modification de DDL de partition pendant la CDC, définissez `skipTableSuspensionForPartitionDdl` sur `true`.
+ AWS DMS prend uniquement en charge les transactions XA dans les versions 3.5.0 et supérieures. Les versions précédentes ne prennent pas en charge les transactions XA. AWS DMS ne prend pas en charge les transactions XA dans MariaDB version 10.6 ou supérieure. Pour plus d'informations, voir ci-dessous. [Prise en charge des transactions XA](#CHAP_Source.MySQL.XA)
+ AWS DMS ne sont pas utilisés GTIDs pour la réplication, même si les données source en contiennent. 
+ AWS DMS ne prend pas en charge le journal binaire amélioré Aurora MySQL.
+ AWS DMS ne prend pas en charge la compression des transactions du journal binaire.
+ AWS DMS ne propage pas les événements ON DELETE CASCADE et ON UPDATE CASCADE pour les bases de données MySQL utilisant le moteur de stockage InnoDB. Pour ces événements, MySQL ne génère pas d’événements binlog pour refléter les opérations en cascade sur les tables enfants. Par conséquent, AWS DMS impossible de répliquer les modifications correspondantes dans les tables enfants. Pour de plus amples informations, veuillez consulter [Non-migration des index, des clés étrangères ou des mises à jour ou suppressions en cascade](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes).
+ AWS DMS ne capture pas les modifications apportées aux colonnes calculées (`VIRTUAL`et`GENERATED ALWAYS`). Pour contourner cette limitation, procédez comme suit :
  + Pré-créez la table cible dans la base de données cible et créez la tâche AWS DMS avec le paramètre de tâche de chargement complet `DO_NOTHING` ou `TRUNCATE_BEFORE_LOAD`.
  + Ajoutez une règle de transformation pour retirer la colonne calculée de la portée de tâche. Pour en savoir plus sur les règles de transformation, consultez [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
+ En raison des limites internes de MySQL, la taille du traitement BINLOGs ne AWS DMS peut pas dépasser 4 Go. BINLOGs une taille supérieure à 4 Go peut entraîner l'échec des tâches DMS ou d'autres comportements imprévisibles. Vous devez réduire la taille des transactions pour éviter des transactions BINLOGs supérieures à 4 Go.
+ AWS DMS ne prend pas en charge les backticks (```) ou les guillemets simples (`'`) dans les noms de schéma, de table et de colonne.
+ AWS DMS ne migre pas les données des colonnes invisibles de votre base de données source. Pour inclure ces colonnes dans le périmètre de votre migration, utilisez l'instruction ALTER TABLE pour les rendre visibles.

## Prise en charge des transactions XA
<a name="CHAP_Source.MySQL.XA"></a>

Une transaction Extended Architecture (XA) est une transaction qui peut être utilisée pour regrouper une série d’opérations provenant de plusieurs ressources transactionnelles en une seule transaction globale fiable. Une transaction XA utilise un protocole de validation en deux phases. En général, la capture des modifications avec des transactions XA ouvertes peut entraîner une perte de données. Si votre base de données n'utilise pas de transactions XA, vous pouvez ignorer cette autorisation et la configuration `IgnoreOpenXaTransactionsCheck` en utilisant la valeur par défaut. `TRUE` Pour commencer la réplication à partir d’une source qui contient des transactions XA, procédez comme suit :
+ Assurez-vous que l'utilisateur du AWS DMS terminal dispose des autorisations suivantes :

  ```
  grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
  ```
+ Définissez le paramètre de point de terminaison `IgnoreOpenXaTransactionsCheck` sur `false`.

**Note**  
AWS DMS ne prend pas en charge les transactions XA sur MariaDB Source DB version 10.6 ou supérieure.

## Paramètres du point de terminaison lors de l'utilisation de MySQL comme source pour AWS DMS
<a name="CHAP_Source.MySQL.ConnectionAttrib"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source MySQL comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--my-sql-settings '{"EndpointSetting": "value", ...}'` JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec MySQL en tant que source sont indiqués dans le tableau suivant.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.MySQL.html)

## Types de données sources pour MySQL
<a name="CHAP_Source.MySQL.DataTypes"></a>

Le tableau suivant indique les types de données source de base de données MySQL pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données MySQL  |  AWS DMS types de données  | 
| --- | --- | 
|  INT  |  INT4  | 
|  BIGINT  |  INT8  | 
|  MEDIUMINT  |  INT4  | 
|  TINYINT  |  INT1  | 
|  SMALLINT  |  INT2  | 
|  UNSIGNED TINYINT  |  UINT1  | 
|  UNSIGNED SMALLINT  |  UINT2  | 
|  UNSIGNED MEDIUMINT  |  UINT4  | 
|  UNSIGNED INT  |  UINT4  | 
|  UNSIGNED BIGINT  |  UINT8  | 
|  DECIMAL(10)  |  NUMERIC (10,0)  | 
|  BINAIRE  |  BYTES(1)  | 
|  BIT  |  BOOLEAN  | 
|  BIT(64)  |  BYTES(8)  | 
|  BLOB  |  BYTES(65535)  | 
|  LONGBLOB  |  BLOB  | 
|  MEDIUMBLOB  |  BLOB  | 
|  TINYBLOB  |  BYTES(255)  | 
|  DATE  |  DATE  | 
|  DATETIME  |  DATETIME DATETIME sans valeur entre parenthèses est répliqué sans millisecondes. DATETIME avec une valeur entre parenthèses comprise entre 1 et 5 (par exemple, `DATETIME(5)`) est répliqué en millisecondes. Lors de la réplication d’une colonne DATETIME, l’heure reste la même sur la cible. Elle n’est pas convertie au format UTC.  | 
|  TIME  |  CHAÎNE  | 
|  TIMESTAMP  |  DATETIME Lors de la réplication d’une colonne TIMESTAMP, l’heure est convertie au format UTC sur la cible.  | 
|  YEAR  |  INT2  | 
|  DOUBLE  |  REAL8  | 
|  FLOAT  |  REAL(DOUBLE) Si les valeurs FLOAT ne sont pas comprises dans la plage suivante, utilisez une transformation pour mapper FLOAT à STRING. Pour plus d'informations sur les transformations, consultez [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). La plage de valeurs FLOAT prise en charge est -1.79E\$1308 à -2.23E-308, 0 et 2.23E-308 à 1.79E\$1308  | 
|  VARCHAR (45)  |  WSTRING (45)  | 
|  VARCHAR (2000)  |  WSTRING (2000)  | 
|  VARCHAR (4000)  |  WSTRING (4000)  | 
|  VARBINARY (4000)  |  BYTES (4000)  | 
|  VARBINARY (2000)  |  BYTES (2000)  | 
|  CHAR  |  WSTRING  | 
|  TEXT  |  WSTRING  | 
|  LONGTEXT  |  NCLOB  | 
|  MEDIUMTEXT  |  NCLOB  | 
|  TINYTEXT  |  WSTRING(255)  | 
|  GEOMETRY  |  BLOB  | 
|  POINT  |  BLOB  | 
|  LINESTRING  |  BLOB  | 
|  POLYGON  |  BLOB  | 
|  MULTIPOINT  |  BLOB  | 
|  MULTILINESTRING  |  BLOB  | 
|  MULTIPOLYGON  |  BLOB  | 
|  GEOMETRYCOLLECTION  |  BLOB  | 
|  ENUM  |  CHAÎNE () *length* *length*Voici la longueur de la plus longue valeur de l'ENUM.  | 
|  SET  |  CHAÎNE () *length* *length*Voici la longueur totale de toutes les valeurs du SET, y compris les virgules.  | 
|  JSON  |  CLOB  | 

**Note**  
Dans certains cas, vous pouvez spécifier les types de données DATETIME et TIMESTAMP avec une valeur « zéro » (c’est-à-dire 0000-00-00). Dans ce cas, assurez-vous que la base de données cible de la tâche de réplication prend en charge les valeurs « zéro » pour les types de données DATETIME et TIMESTAMP. Dans le cas contraire, ces valeurs sont enregistrées en tant que valeurs NULL dans la cible.

# Utilisation d'une base de données SAP ASE comme source pour AWS DMS
<a name="CHAP_Source.SAP"></a>

Vous pouvez migrer des données depuis une base de données SAP Adaptive Server Enterprise (ASE), anciennement connue sous le nom de Sybase, à l'aide de. AWS DMS Avec une base de données SAP ASE comme source, vous pouvez migrer des données vers n'importe quelle autre base de données AWS DMS cible prise en charge. 

Pour plus d'informations sur les versions de SAP ASE prises AWS DMS en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md).

Pour plus de détails sur l'utilisation des bases de données SAP ASE AWS DMS, consultez les sections suivantes.

**Topics**
+ [Conditions préalables à l'utilisation d'une base de données SAP ASE comme source pour AWS DMS](#CHAP_Source.SAP.Prerequisites)
+ [Limitations liées à l'utilisation de SAP ASE comme source pour AWS DMS](#CHAP_Source.SAP.Limitations)
+ [Autorisations requises pour utiliser SAP ASE comme source pour AWS DMS](#CHAP_Source.SAP.Security)
+ [Suppression du point de troncature](#CHAP_Source.SAP.Truncation)
+ [Paramètres du point de terminaison lors de l'utilisation de SAP ASE comme source pour AWS DMS](#CHAP_Source.SAP.ConnectionAttrib)
+ [Types de données sources pour SAP ASE](#CHAP_Source.SAP.DataTypes)

## Conditions préalables à l'utilisation d'une base de données SAP ASE comme source pour AWS DMS
<a name="CHAP_Source.SAP.Prerequisites"></a>

Pour qu'une base de données SAP ASE serve de source AWS DMS, procédez comme suit :
+ Activez la réplication SAP ASE pour les tables en utilisant la commande `sp_setreptable`. Pour plus d’informations, consultez les [Sybase Infocenter Archive]( http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc32410_1501/html/refman/X37830.htm). 
+ Désactivez `RepAgent` sur la base de données SAP ASE. Pour plus d'informations, voir [Arrêter et désactiver le RepAgent thread dans la base de données principale](http://infocenter-archive.sybase.com/help/index.jsp?topic=/com.sybase.dc20096_1260/html/mra126ag/mra126ag65.htm). 
+ Pour effectuer une réplication vers SAP ASE version 15.7 sur une instance Windows EC2 configurée pour les caractères non latins (chinois, par exemple), installez SAP ASE 15.7 SP121 sur l'ordinateur cible.

**Note**  
Pour la réplication continue de la capture des données de modification (CDC), DMS exécute `dbcc logtransfer` et `dbcc log` pour lire les données du journal des transactions.

## Limitations liées à l'utilisation de SAP ASE comme source pour AWS DMS
<a name="CHAP_Source.SAP.Limitations"></a>

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données SAP ASE comme source pour AWS DMS :
+ Vous ne pouvez exécuter qu'une seule AWS DMS tâche avec réplication continue ou CDC pour chaque base de données SAP ASE. Vous pouvez exécuter plusieurs full-load-only tâches en parallèle.
+ Vous ne pouvez pas renommer une table. Par exemple, la commande suivante échoue.

  ```
  sp_rename 'Sales.SalesRegion', 'SalesReg;
  ```
+ Vous ne pouvez pas renommer une colonne. Par exemple, la commande suivante échoue.

  ```
  sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';
  ```
+ Les valeurs zéro situées à la fin des chaînes de type de données binaires sont tronqués lors de la réplication vers la base de données cible. Par exemple, `0x0000000000000000000000000100000100000000` dans la table source devient `0x00000000000000000000000001000001` dans la table cible.
+ Si la base de données par défaut est définie pour ne pas autoriser les valeurs NULL, AWS DMS crée la table cible avec des colonnes qui n'autorisent pas les valeurs NULL. Par conséquent, si un chargement complet ou une tâche de réplication CDC contient des valeurs vides, AWS DMS une erreur est générée. Vous pouvez éviter ces erreurs en autorisant les valeurs NULL dans la base de données source à l'aide des commandes suivantes.

  ```
  sp_dboption database_name, 'allow nulls by default', 'true'
  go
  use database_name
  CHECKPOINT
  go
  ```
+ La commande d'index `reorg rebuild` n'est pas prise en charge.
+ AWS DMS ne prend pas en charge les clusters ou n'utilise pas MSA (Multi-Site Availability) /Warm Standby comme source.
+ Lorsque l’expression d’en-tête de transformation `AR_H_TIMESTAMP` est utilisée dans les règles de mappage, les millisecondes ne sont pas capturées pour une colonne ajoutée.
+ L’exécution d’opérations de fusion pendant la CDC entraîne une erreur irrécupérable. Pour rétablir la synchronisation de la cible, effectuez un chargement complet.
+ Les événements déclencheurs de restauration ne sont pas pris en charge pour les tables qui utilisent un schéma de verrouillage des lignes de données.
+ AWS DMS Impossible de reprendre une tâche de réplication après avoir supprimé une table comprise dans le périmètre de la tâche depuis une base de données SAP source. Si la tâche de réplication DMS a été arrêtée et a effectué une opération DML (INSERT, UPDATE, DELETE) suivie de la suppression de la table, vous devez redémarrer la tâche de réplication.

## Autorisations requises pour utiliser SAP ASE comme source pour AWS DMS
<a name="CHAP_Source.SAP.Security"></a>

Pour utiliser une base de données SAP ASE comme source dans une AWS DMS tâche, vous devez accorder des autorisations. Accordez au compte utilisateur spécifié dans les définitions AWS DMS de base de données les autorisations suivantes dans la base de données SAP ASE : 
+ sa\$1role
+ replication\$1role
+ sybase\$1ts\$1role
+ Par défaut, lorsque vous devez être autorisé à exécuter la procédure `sp_setreptable` stockée, l'option AWS DMS de réplication SAP ASE est activée. Si vous souhaitez exécuter `sp_setreptable` sur une table directement depuis le point de terminaison de la base de données et non par AWS DMS lui-même, vous pouvez utiliser l'attribut de connexion `enableReplication` supplémentaire. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison lors de l'utilisation de SAP ASE comme source pour AWS DMS](#CHAP_Source.SAP.ConnectionAttrib).

## Suppression du point de troncature
<a name="CHAP_Source.SAP.Truncation"></a>

Lorsqu'une tâche démarre, AWS DMS crée une `$replication_truncation_point` entrée dans la vue `syslogshold` système, indiquant qu'un processus de réplication est en cours. Pendant AWS DMS son fonctionnement, il avance le point de troncature de réplication à intervalles réguliers, en fonction de la quantité de données déjà copiées sur la cible.

Une fois l'`$replication_truncation_point`entrée établie, maintenez la AWS DMS tâche en cours d'exécution pour éviter que le journal de base de données ne devienne trop volumineux. Si vous souhaitez arrêter définitivement la AWS DMS tâche, supprimez le point de troncature de réplication en exécutant la commande suivante :

```
dbcc settrunc('ltm','ignore')
```

Une fois le point de troncature supprimé, vous ne pouvez pas reprendre la AWS DMS tâche. Le journal continue d'être tronqué automatiquement aux points de contrôle (si la troncature est configurée).

## Paramètres du point de terminaison lors de l'utilisation de SAP ASE comme source pour AWS DMS
<a name="CHAP_Source.SAP.ConnectionAttrib"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source SAP ASE comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--sybase-settings '{"EndpointSetting": "value", ...}'` JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec SAP ASE en tant que source sont indiqués dans le tableau suivant.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.SAP.html)

## Types de données sources pour SAP ASE
<a name="CHAP_Source.SAP.DataTypes"></a>

Pour obtenir la liste des types de données source SAP ASE pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données, consultez le tableau suivant. AWS DMS ne prend pas en charge les tables sources SAP ASE avec des colonnes de type de données UDT (UDT) défini par l'utilisateur. Les colonnes répliquées avec ce type de données sont créées en tant que NULL. 

Pour plus d'informations sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section [Cibles pour la migration des données](CHAP_Target.md) relative à votre point de terminaison cible.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Type de données SAP ASE  |  AWS DMS types de données  | 
| --- | --- | 
| BIGINT | INT8 | 
| UNSIGNED BIGINT | UINT8 | 
| INT | INT4 | 
| UNSIGNED INT | UINT4 | 
| SMALLINT | INT2 | 
| UNSIGNED SMALLINT | UINT2 | 
| TINYINT | UINT1 | 
| DECIMAL | NUMERIC | 
| NUMERIC | NUMERIC | 
| FLOAT | REAL8 | 
| DOUBLE | REAL8 | 
| REAL | REAL4 | 
| MONEY | NUMERIC | 
| SMALLMONEY | NUMERIC | 
| DATETIME | DATETIME | 
| BIGDATETIME | DATETIME(6) | 
| SMALLDATETIME | DATETIME | 
| DATE | DATE | 
| TIME | TIME | 
| BIGTIME | TIME | 
| CHAR | CHAÎNE | 
| UNICHAR | WSTRING | 
| NCHAR | WSTRING | 
| VARCHAR | CHAÎNE | 
| UNIVARCHAR | WSTRING | 
| NVARCHAR | WSTRING | 
| BINAIRE | BYTES | 
| VARBINARY | BYTES | 
| BIT | BOOLEAN | 
| TEXT | CLOB | 
| UNITEXT | NCLOB | 
| IMAGE | BLOB | 

# Utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB"></a>

 Pour plus d'informations sur les versions de MongoDB prises AWS DMS en charge en tant que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md) 

Notez les éléments suivants concernant la prise en charge des versions de MongoDB :
+ Les versions AWS DMS 3.4.5 et ultérieures prennent en charge les versions 4.2 et 4.4 de MongoDB. 
+ Les versions AWS DMS 3.4.5 et ultérieures ainsi que les versions de MongoDB 4.2 et ultérieures prennent en charge les transactions distribuées. Pour plus d’informations sur les transactions distribuées MongoDB, consultez [Transactions](https://docs.mongodb.com/manual/core/transactions/) dans la [documentation de MongoDB](https://www.mongodb.com/docs/).
+ Les versions AWS DMS 3.5.0 et ultérieures ne prennent pas en charge les versions de MongoDB antérieures à 3.6.
+ Les versions AWS DMS 3.5.1 et ultérieures prennent en charge la version 5.0 de MongoDB.
+ Les versions AWS DMS 3.5.2 et ultérieures prennent en charge la version 6.0 de MongoDB.
+ Les versions AWS DMS 3.5.4 et ultérieures prennent en charge les versions 7.0 et 8.0 de MongoDB.



Si vous n'êtes pas encore familiarisé avec MongoDB, soyez conscient des concepts importants suivants relatifs aux bases de données MongoDB : 
+ Un enregistrement dans MongoDB est un *document*, c'est-à-dire une structure de données composée de paires champ-valeur. La valeur d'un champ peut contenir d'autres documents, tableaux et tableaux de documents. Un document correspond à peu près à une ligne dans une table de base de données relationnelle.
+ Une *collection* dans MongoDB est un groupe de documents et équivaut à peu près à une table de base de données relationnelle.
+ Une *base de données* dans MongoDB est un ensemble de collections et équivaut à peu près à un schéma dans une base de données relationnelle.
+ Au niveau interne, un document MongoDB est stocké sous forme de fichier JSON binaire (BSON) dans un format compressé qui contient un type pour chaque champ du document. Chaque document présente un ID unique.

AWS DMS prend en charge deux modes de migration lors de l'utilisation de MongoDB comme source, *en mode Document ou en mode* *Table*. Vous spécifiez le mode de migration à utiliser lorsque vous créez le point de terminaison MongoDB ou en définissant le paramètre **Mode métadonnées** à partir de la console AWS DMS . Vous pouvez éventuellement créer une deuxième colonne nommée `_id` qui fait office de clé primaire en cochant la case **\$1id en tant que colonne séparée** dans le panneau de configuration du point de terminaison. 

Le mode de migration que vous choisissez affecte le format résultant des données cibles, comme indiqué ci-après. 

**Mode document**  
En mode document, le document MongoDB est migré tel quel, ce qui signifie que ses données sont regroupées en une seule colonne nommée `_doc` dans une table cible. Le mode document est défini par défaut lorsque MongoDB est utilisé comme point de terminaison source.  
Prenons l'exemple des documents suivants dans une collection MongoDB appelée myCollection.  

```
 db.myCollection.find()
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 }
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 }
```
Une fois les données migrées vers une table de base de données relationnelle à l'aide du mode document, les données sont structurées comme suit. Les champs de données du document MongoDB sont regroupés dans la colonne ` _doc`.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.MongoDB.html)
Vous pouvez éventuellement définir l'attribut de connexion supplémentaire `extractDocID` sur *true* pour créer une seconde colonne nommée `"_id"`, qui servira de clé primaire. Pour pouvoir utiliser CDC, définissez ce paramètre sur *true*.  
Lorsque vous utilisez CDC avec des sources qui produisent des [transactions multidocuments](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), le `ExtractDocId` paramètre **doit être** défini sur *true*. Si ce paramètre n'est pas activé, la AWS DMS tâche échouera lorsqu'elle rencontrera une transaction comportant plusieurs documents.  
En mode document, AWS DMS gère la création et le changement de nom des collections comme suit :  
+ Si vous ajoutez une nouvelle collection à la base de données source, AWS DMS créez une nouvelle table cible pour la collection et répliquez tous les documents. 
+ Si vous renommez une collection existante dans la base de données source, AWS DMS ne renomme pas la table cible. 
Si le point de terminaison cible est Amazon DocumentDB, exécutez la migration en **mode document**.

**Mode table**  
En mode table, AWS DMS transforme chaque champ de premier niveau d'un document MongoDB en colonne dans la table cible. Si un champ est imbriqué, AWS DMS ajuste les valeurs imbriquées dans une seule colonne. AWS DMS ajoute ensuite un champ clé et des types de données au jeu de colonnes de la table cible.   
Pour chaque document MongoDB, AWS DMS ajoute chaque clé et chaque type au jeu de colonnes de la table cible. Par exemple, le mode table permet de AWS DMS migrer l'exemple précédent vers le tableau suivant.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.MongoDB.html)
Les valeurs imbriquées sont mises à plat dans une colonne contenant des noms de clé séparés par un point. La colonne est nommée en utilisant la forme concaténée des noms de champs mis à plat, séparés par des points. Par exemple, AWS DMS migre un document JSON contenant un champ de valeurs imbriquées, par exemple `{"a" : {"b" : {"c": 1}}}` dans une colonne nommée `a.b.c.`  
Pour créer les colonnes cibles, AWS DMS scanne un nombre spécifié de documents MongoDB et crée un ensemble de tous les champs et de leurs types. AWS DMS utilise ensuite cet ensemble pour créer les colonnes de la table cible. Si vous créez ou modifiez votre point de terminaison source MongoDB à l'aide de la console , vous pouvez spécifier le nombre de documents à analyser. La valeur par défaut est de 1000 documents. Si vous utilisez le AWS CLI, vous pouvez utiliser l'attribut de connexion supplémentaire`docsToInvestigate`.  
En mode tableau, AWS DMS gère les documents et les collections comme suit :  
+ Lorsque vous ajoutez un document à une collection existante, le document est répliqué. Si certains champs ne figurent pas dans la cible, ils ne sont pas répliqués.
+ Lorsque vous mettez à jour un document, celui-ci est répliqué. Si certains champs ne figurent pas dans la cible, ils ne sont pas répliqués.
+ La suppression d'un document est pleinement prise en charge.
+ L'ajout d'une nouvelle collection n'entraîne pas la création d'une nouvelle table dans la cible lorsque cela est effectué durant une tâche CDC.
+ Dans la phase Change Data Capture (CDC), AWS DMS il n'est pas possible de renommer une collection.

**Topics**
+ [Autorisations nécessaires lors de l'utilisation de MongoDB comme source pour AWS DMS](#CHAP_Source.MongoDB.PrerequisitesCDC)
+ [Configuration d’un ensemble de réplicas MongoDB pour la CDC](#CHAP_Source.MongoDB.PrerequisitesCDC.ReplicaSet)
+ [Exigences de sécurité lors de l'utilisation de MongoDB comme source pour AWS DMS](#CHAP_Source.MongoDB.Security)
+ [Segmentation des collections MongoDB et migration en parallèle](#CHAP_Source.MongoDB.ParallelLoad)
+ [Migration de plusieurs bases de données lors de l'utilisation de MongoDB comme source pour AWS DMS](#CHAP_Source.MongoDB.Multidatabase)
+ [Limitations liées à l'utilisation de MongoDB comme source pour AWS DMS](#CHAP_Source.MongoDB.Limitations)
+ [Paramètres de configuration du point de terminaison lors de l'utilisation de MongoDB comme source pour AWS DMS](#CHAP_Source.MongoDB.Configuration)
+ [Types de données sources pour MongoDB](#CHAP_Source.MongoDB.DataTypes)

## Autorisations nécessaires lors de l'utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB.PrerequisitesCDC"></a>

Pour une AWS DMS migration avec une source MongoDB, vous pouvez créer soit un compte utilisateur avec des privilèges root, soit un utilisateur autorisé uniquement sur la base de données à migrer. 

Le code suivant permet de créer un utilisateur qui sera le compte racine.

```
use admin
db.createUser(
  {
    user: "root",
    pwd: "password",
    roles: [ { role: "root", db: "admin" } ]
  }
)
```

Pour une source MongoDB 3.x, le code suivant permet de créer un utilisateur avec des autorisations minimales sur la base de données à migrer.

```
use database_to_migrate
db.createUser( 
{ 
    user: "dms-user",
    pwd: "password",
    roles: [ { role: "read", db: "local" }, "read"] 
})
```

Pour une source MongoDB 4.x, le code suivant permet de créer un utilisateur avec des privilèges minimum.

```
{ resource: { db: "", collection: "" }, actions: [ "find", "changeStream" ] }
```

Par exemple, créez le rôle suivant dans la base de données « admin ».

```
use admin
db.createRole(
{
role: "changestreamrole",
privileges: [
{ resource: { db: "", collection: "" }, actions: [ "find","changeStream" ] }
],
roles: []
}
)
```

Une fois le rôle créé, créez un utilisateur dans la base de données à migrer.

```
 use test
> db.createUser( 
{ 
user: "dms-user12345",
pwd: "password",
roles: [ { role: "changestreamrole", db: "admin" }, "read"] 
})
```

## Configuration d’un ensemble de réplicas MongoDB pour la CDC
<a name="CHAP_Source.MongoDB.PrerequisitesCDC.ReplicaSet"></a>

Pour utiliser la réplication continue ou le CDC avec MongoDB, AWS DMS il faut accéder au journal des opérations MongoDB (oplog). Pour créer le journal oplog, vous devez déployer un ensemble de réplicas, s'il n'en existe pas encore. Pour obtenir plus d'informations, consultez [ la documentation MongoDB](https://docs.mongodb.com/manual/tutorial/deploy-replica-set/).

Vous pouvez utiliser la capture des données modifiées (CDC) avec le nœud principal ou secondaire d'un ensemble de réplicas MongoDB comme point de terminaison source.

**Pour convertir une instance autonome en un ensemble de réplicas**

1. Utilisation d'une ligne de commande, se connecter à `mongo`.

   ```
   mongo localhost
   ```

1. Arrêtez le service `mongod`.

   ```
   service mongod stop
   ```

1. Redémarrez `mongod` à l'aide de la commande suivante :

   ```
   mongod --replSet "rs0" --auth -port port_number
   ```

1. Testez la connexion à l'ensemble de réplicas à l'aide des commandes suivantes :

   ```
   mongo -u root -p password --host rs0/localhost:port_number 
     --authenticationDatabase "admin"
   ```

Si vous prévoyez d'effectuer une migration en mode document, sélectionnez l'option `_id as a separate column` lors de la création du point de terminaison MongoDB. La sélection de cette option permet de créer une seconde colonne nommée `_id`, qui agit en tant que clé primaire. Cette deuxième colonne est requise AWS DMS pour prendre en charge les opérations du langage de manipulation de données (DML).

**Note**  
AWS DMS utilise le journal des opérations (oplog) pour enregistrer les modifications au cours de la réplication en cours. Si MongoDB vide les enregistrements du journal avant de les AWS DMS lire, vos tâches échouent. Nous vous recommandons de dimensionner le journal des opérations pour conserver les modifications pendant au moins 24 heures. 

## Exigences de sécurité lors de l'utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB.Security"></a>

AWS DMS prend en charge deux méthodes d'authentification pour MongoDB. Les deux méthodes d'authentification sont utilisées pour chiffrer le mot de passe. Elles sont donc utilisées uniquement lorsque le paramètre `authType` est défini sur *PASSWORD*.

Les méthodes d'authentification MongoDB sont les suivantes :
+ **MONGODB-CR** : pour la rétrocompatibilité
+ **SCRAM-SHA-1** : méthode par défaut lors de l’utilisation de MongoDB version 3.x et 4.0

Si aucune méthode d'authentification n'est spécifiée, AWS DMS utilise la méthode par défaut pour la version de la source MongoDB.

## Segmentation des collections MongoDB et migration en parallèle
<a name="CHAP_Source.MongoDB.ParallelLoad"></a>

Pour améliorer les performances d’une tâche de migration, les points de terminaison source MongoDB prennent en charge deux options de chargement complet en parallèle dans le mappage de table. 

En d’autres termes, vous pouvez migrer une collection en parallèle en utilisant la segmentation automatique ou la segmentation par plage avec le mappage de table pour un chargement complet en parallèle dans les paramètres JSON. Avec l'autosegmentation, vous pouvez spécifier les critères AWS DMS pour segmenter automatiquement votre source pour la migration dans chaque thread. Avec la segmentation par plage, vous pouvez déterminer AWS DMS la plage spécifique de chaque segment pour que le DMS migre dans chaque thread. Pour plus d’informations sur ces paramètres, consultez [Règles des paramètres de table et de collection et opérations](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).

### Migration d’une base de données MongoDB en parallèle à l’aide de plages de segmentation automatique
<a name="CHAP_Source.MongoDB.ParallelLoad.AutoPartitioned"></a>

Vous pouvez migrer vos documents en parallèle en spécifiant les critères permettant à AWS DMS de partitionner (segmenter) automatiquement vos données pour chaque thread. Vous spécifiez notamment le nombre de documents à migrer par thread. À l'aide de cette approche, AWS DMS tente d'optimiser les limites des segments pour des performances maximales par thread.

Vous pouvez spécifier les critères de segmentation à l’aide des options table-settings suivantes dans table-mapping.


|  Option table-settings  |  Description  | 
| --- | --- | 
|  `"type"`  |  (Obligatoire) Définie sur `"partitions-auto"` pour MongoDB en tant que source.  | 
|  `"number-of-partitions"`  |  (Facultatif) Nombre total de partitions (segments) utilisées pour la migration. La valeur par défaut est 16.  | 
|  `"collection-count-from-metadata"`  |  (Facultatif) Si cette option est définie sur `true`, AWS DMS utilise une estimation du nombre de collections pour déterminer le nombre de partitions. Si cette option est définie sur`false`, AWS DMS utilise le nombre réel de collectes. La valeur par défaut est `true`.  | 
|  `"max-records-skip-per-page"`  |  (Facultatif) Le nombre d'enregistrements à ignorer simultanément lors de la détermination des limites de chaque partition. AWS DMS utilise une approche de saut paginé pour déterminer la limite minimale d'une partition. La valeur par défaut est 10 000.  La définition d’une valeur relativement élevée peut entraîner des délais d’expiration du curseur et des échecs de tâche. La définition d’une valeur relativement faible entraîne un plus grand nombre d’opérations par page et ralentit le chargement complet.   | 
|  `"batch-size"`  |  (Facultatif) Limite le nombre de documents renvoyés dans un lot. Chaque lot nécessite un aller retour jusqu’au serveur. Si la taille du lot est égale à zéro (0), le curseur utilise la taille de lot maximale définie par le serveur. La valeur par défaut est 0.  | 

L’exemple suivant illustre un mappage de table pour la segmentation automatique.

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "parallel-load": {
                "type": "partitions-auto",
                "number-of-partitions": 5,
                "collection-count-from-metadata": "true",
                "max-records-skip-per-page": 1000000,
                "batch-size": 50000
            }
        }
    ]
}
```

La segmentation automatique présente les limitations suivantes. Pour chaque segment, la migration extrait séparément le nombre de collections et la valeur minimale de `_id` pour la collection. Elle ignore ensuite un certain nombre d’enregistrements par page pour calculer la limite minimale pour ce segment. 

Par conséquent, assurez-vous que la valeur minimale de `_id` reste constante pour chaque collection, jusqu’à ce que toutes les limites de segment de la collection soient calculées. Si vous modifiez la valeur minimale de `_id` d’une collection lors du calcul de ses limites de segment, cela peut entraîner une perte de données ou des erreurs de lignes en double.

### Migration d’une base de données MongoDB en parallèle à l’aide de la segmentation par plage
<a name="CHAP_Source.MongoDB.ParallelLoad.Ranges"></a>

Vous pouvez migrer vos documents en parallèle en spécifiant les plages pour chaque segment d’un thread. En utilisant cette approche, vous indiquez AWS DMS aux documents spécifiques à migrer dans chaque fil de discussion en fonction de votre choix de plages de documents par fil.

L’image suivante illustre une collection MongoDB composée de sept éléments, qui utilise `_id` comme clé primaire.

![\[Collection MongoDB composée de sept éléments.\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-docdb-collection.png)


Pour diviser la collection en trois segments spécifiques afin de AWS DMS migrer en parallèle, vous pouvez ajouter des règles de mappage de tables à votre tâche de migration. Cette approche est illustrée dans l’exemple de code JSON suivant.

```
{ // Task table mappings:
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "rule-action": "include"
    }, // "selection" :"rule-type"
    {
      "rule-type": "table-settings",
      "rule-id": "2",
      "rule-name": "2",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "parallel-load": {
        "type": "ranges",
        "columns": [
           "_id",
           "num"
        ],
        "boundaries": [
          // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79
          // and num less-than-or-equal-to 2.
          [
             "5f805c97873173399a278d79",
             "2"
          ],
          // Second segment selects documents with _id > 5f805c97873173399a278d79 and
          // _id less-than-or-equal-to 5f805cc5873173399a278d7c and
          // num > 2 and num less-than-or-equal-to 5.
          [
             "5f805cc5873173399a278d7c",
             "5"
          ]                                   
          // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c.
        ] // :"boundaries"
      } // :"parallel-load"
    } // "table-settings" :"rule-type"
  ] // :"rules"
} // :Task table mappings
```

Cette définition de mappage de table divise la collection source en trois segments et la migre en parallèle. Les limites de segmentation sont les suivantes.

```
Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records)
Data with _id > "5f805c97873173399a278d79" and num > 2 and _id  less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 (3 records)
Data with _id > "5f805cc5873173399a278d7c" and num > 5 (2 records)
```

Une fois la tâche de migration terminée, vous pouvez vérifier dans les journaux de tâches que les tables sont chargées en parallèle, comme indiqué dans l’exemple suivant. Vous pouvez également vérifier la clause `find` de MongoDB utilisée pour décharger chaque segment de la table source.

```
[TASK_MANAGER    ] I:  Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86  (replicationtask_util.c:752)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is initialized.   (mongodb_unload.c:157)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } }  (mongodb_unload.c:328)

[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TASK_MANAGER    ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752)
 
[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) 

[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328)
 
[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TARGET_LOAD     ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480.

[TASK_MANAGER    ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred.
```

Actuellement, AWS DMS prend en charge les types de données MongoDB suivants en tant que colonne clé de segment :
+ Double
+ String
+ ObjectId
+ Entier 32 bits
+ Entier 64 bits

## Migration de plusieurs bases de données lors de l'utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB.Multidatabase"></a>

AWS DMS les versions 3.4.5 et supérieures prennent en charge la migration de plusieurs bases de données en une seule tâche pour toutes les versions de MongoDB prises en charge. Si vous souhaitez migrer plusieurs bases de données, procédez comme suit :

1. Lorsque vous créez le point de terminaison source MongoDB, procédez de l’une des manières suivantes :
   + Sur la page **Créer un point de terminaison** de la console DMS, assurez-vous que le **Nom de base de données** est vide sous **Configuration du point de terminaison**.
   + À l'aide de la AWS CLI `CreateEndpoint` commande, attribuez une valeur de chaîne vide au `DatabaseName` paramètre dans`MongoDBSettings`.

1. Pour chaque base de données que vous souhaitez migrer à partir d’une source MongoDB, spécifiez le nom de la base de données sous forme de nom de schéma dans le mappage de table de la tâche. Pour ce faire, utilisez la saisie guidée dans la console ou effectuez votre saisie directement dans le code JSON. Pour plus d’informations sur la saisie guidée, consultez [Spécification des règles de sélection de table et de transformation à partir de la console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Pour plus d’informations sur le code JSON, consultez [Règles et actions de sélection](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).

Vous pouvez par exemple spécifier le code JSON suivant pour migrer trois bases de données MongoDB.

**Example Migrer toutes les tables dans un schéma**  
Le code JSON suivant permet de migrer toutes les tables à partir des bases de données `Customers`, `Orders` et `Suppliers` du point de terminaison source vers votre point de terminaison cible.  

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "Customers",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "selection",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "Orders",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "selection",
            "rule-id": "3",
            "rule-name": "3",
            "object-locator": {
                "schema-name": "Inventory",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}
```

## Limitations liées à l'utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB.Limitations"></a>

Les limites suivantes s'appliquent à l'utilisation de MongoDB comme source pour : AWS DMS
+ En mode table, les documents d’une collection doivent être cohérents dans le type de données qu’ils utilisent pour la valeur du même champ. Par exemple, si un document d’une collection inclut `'{ a:{ b:value ... }'`, tous les documents de la collection qui font référence à `value` dans le champ `a.b` doivent utiliser le même type de données pour `value`, quel que soit l’endroit où il apparaît dans la collection.
+ Lorsque l'option `_id` est définie comme une colonne distincte, la chaîne d'ID ne peut pas contenir plus de 200 caractères.
+ Les clés de type de tableau et d'ID d'objet sont converties en colonnes dotées des préfixes `array` et `oid` en mode table.

  En interne, ces colonnes sont référencées avec les noms préfixés. Si vous utilisez des règles de transformation AWS DMS qui font référence à ces colonnes, assurez-vous de spécifier la colonne préfixée. Par exemple, vous spécifiez `${oid__id}` et pas `${_id}`, ou `${array__addresses}` et pas `${_addresses}`. 
+  Les noms de collection et les noms de clé ne peuvent pas contenir le symbole du dollar (\$1). 
+ AWS DMS ne prend pas en charge les collections contenant le même champ avec des majuscules et minuscules (majuscules, minuscules) en mode table avec une cible RDBMS. Par exemple, AWS DMS il n'est pas possible d'avoir deux collections nommées `Field1` et`field1`. 
+ Le mode table et le mode document présentent les limitations décrites précédemment.
+ La migration en parallèle à l’aide de la segmentation automatique présente les limitations décrites ci-dessus.
+ Les filtres de source ne sont pas pris en charge pour MongoDB.
+ AWS DMS ne prend pas en charge les documents dont le niveau d'imbrication est supérieur à 97.
+ AWS DMS nécessite des données source codées en UTF-8 lors de la migration vers des cibles autres que DocumentDB. Pour les sources contenant des caractères non UTF-8, convertissez-les en UTF-8 avant la migration ou migrez-les plutôt vers Amazon DocumentDB.
+ AWS DMS ne prend pas en charge les fonctionnalités suivantes de MongoDB version 5.0 :
  + Repartitionnement en direct
  + Chiffrement au niveau des champs côté client (CSFLE)
  + Migration de collections de séries temporelles
**Note**  
Une collection de séries temporelles migrée pendant la phase de chargement complet sera convertie en collection normale dans Amazon DocumentDB, car DocumentDB ne prend pas en charge les collections de séries temporelles.

## Paramètres de configuration du point de terminaison lors de l'utilisation de MongoDB comme source pour AWS DMS
<a name="CHAP_Source.MongoDB.Configuration"></a>

Lorsque vous configurez votre point de terminaison source MongoDB, vous pouvez spécifier plusieurs paramètres de configuration de point de terminaison à l'aide de la AWS DMS console. 

Le tableau suivant décrit les paramètres de configuration disponibles lors de l'utilisation des bases de données MongoDB comme source AWS DMS . 


| Paramètre (attribut) | Valeurs valides | Valeur par défaut et description | 
| --- | --- | --- | 
|  **Mode d’authentification**  |  `"none"` `"password"`  |  La valeur `"password"` invite à entrer un nom d’utilisateur et un mot de passe. Lorsque `"none"` est spécifié, les paramètres de nom d’utilisateur et de mot de passe ne sont pas utilisés.  | 
|  **Source d’authentification**  |  Un nom de base de données MongoDB valide.  |  Nom de la base de données MongoDB que vous souhaitez utiliser pour valider vos informations d’identification pour l’authentification. La valeur par défaut est `"admin"`.   | 
|  **Mécanisme d’authentification**  |  `"default"` `"mongodb_cr"` `"scram_sha_1"`  |  Mécanisme d’authentification. La valeur ` "default"` est `"scram_sha_1"`. Ce paramètre n'est pas utilisé lorsque la valeur `authType` est définie sur `"no"`.  | 
|  **Mode métadonnées**  |  Document et table  |  Choisit le mode document ou le mode table.   | 
|  **Nombre de documents à numériser** (`docsToInvestigate`)  |  Un nombre entier positif supérieur à `0`.  |  Utilisez cette option en mode table uniquement pour définir la définition de table cible.  | 
|  **\$1id en tant que colonne séparée**  |  Case cochée  |  Case à cocher facultative qui permet de créer une seconde colonne nommée `_id` qui sert de clé primaire.  | 
|   `ExtractDocID`   |  `true` `false`  |  `false` : utilisez cet attribut lorsque `NestingLevel` est défini sur `"none"`.  Lorsque vous utilisez CDC avec des sources qui produisent des [transactions multidocuments](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), le `ExtractDocId` paramètre **doit être** défini sur. `true` Si ce paramètre n'est pas activé, la AWS DMS tâche échouera lorsqu'elle rencontrera une transaction comportant plusieurs documents.  | 
|  `socketTimeoutMS`  |  Nombre entier supérieur ou égal à 0. Attribut de connexion supplémentaire (ECA) uniquement.  |  Ce paramètre est exprimé en millisecondes et configure le délai de connexion pour les clients MongoDB. Si la valeur est inférieure ou égale à zéro, la valeur par défaut du client MongoDB est utilisée.  | 
|   `UseUpdateLookUp`   |  `true` `false`  |  Lorsque c'est vrai, lors des événements de mise à jour du CDC, AWS DMS copie l'intégralité du document mis à jour vers la cible. Lorsqu'il est défini sur false, AWS DMS utilise la commande de mise à jour MongoDB pour mettre à jour uniquement les champs modifiés dans le document sur la cible.  | 
|   `ReplicateShardCollections`   |  `true` `false`  |  Lorsque c'est vrai, AWS DMS réplique les données vers des collections de partitions. AWS DMS utilise ce paramètre uniquement si le point de terminaison cible est un cluster Elastic DocumentDB. Lorsque ce paramètre est défini sur true, notez les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.MongoDB.html)  | 
|  `useTransactionVerification`  |  `true` `false`  |  Lorsque`false`, désactive la vérification entre le flux de modifications et les journaux.   Vous pouvez rater des opérations en cas de divergence entre les flux de modifications et les entrées du journal journal, car le comportement par défaut du DMS consiste à échouer la tâche dans de tels scénarios. Valeur par défaut : `true`.   | 
|  `useOplog`  |  `true` `false`  |  Quand`true`, permet à la tâche DMS de lire directement depuis « oplog » plutôt que d'utiliser le flux de modifications. Valeur par défaut : `false`.  | 

Si vous choisissez **Document** comme **Mode métadonnées**, différentes options sont disponibles. 

Si le point de terminaison cible est DocumentDB, assurez-vous d’exécuter la migration en **Mode document**. Modifiez également le point de terminaison source et sélectionnez l’option **\$1id en tant que colonne séparée**. Il s’agit d’un prérequis obligatoire si votre charge de travail MongoDB source implique des transactions.

## Types de données sources pour MongoDB
<a name="CHAP_Source.MongoDB.DataTypes"></a>

La migration de données qui utilise MongoDB comme source prend en AWS DMS charge la plupart des types de données MongoDB. Dans le tableau suivant, vous trouverez les types de données source MongoDB pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données. Pour de plus amples informations sur les types de données MongoDB, veuillez consulter [Types BSON](https://docs.mongodb.com/manual/reference/bson-types) dans la documentation MongoDB.

Pour obtenir des informations sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section relative au point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données MongoDB  |  AWS DMS types de données  | 
| --- | --- | 
| Booléen | Booléen | 
| Binaire | BLOB | 
| Date | Date | 
| Horodatage | Date | 
| Int | INT4 | 
| Long | INT8 | 
| Double | REAL8 | 
| Chaîne (UTF-8) | CLOB | 
| Tableau | CLOB | 
| OID | String | 
| REGEX | CLOB | 
| CODE | CLOB | 

# Utilisation d'Amazon DocumentDB (compatible avec MongoDB) comme source pour AWS DMS
<a name="CHAP_Source.DocumentDB"></a>

Pour en savoir plus sur les versions d’Amazon DocumentDB (compatible avec MongoDB) prises en charge par AWS DMS en tant que source, consultez [Sources pour AWS DMS](CHAP_Introduction.Sources.md).

 En utilisant Amazon DocumentDB en tant que source, vous pouvez migrer des données d’un cluster Amazon DocumentDB vers un autre cluster Amazon DocumentDB. Vous pouvez également migrer les données d'un cluster Amazon DocumentDB vers l'un des autres points de terminaison cibles pris en charge par. AWS DMS

Si vous utilisez Amazon DocumentDB pour la première fois, prenez connaissance des concepts importants suivants relatifs aux bases de données Amazon DocumentDB :
+ Un enregistrement dans Amazon DocumentDB est un *document*, une structure de données composée de paires champ-valeur. La valeur d'un champ peut contenir d'autres documents, tableaux et tableaux de documents. Un document correspond à peu près à une ligne dans une table de base de données relationnelle.
+ Une *collection* dans Amazon DocumentDB est un groupe de documents et équivaut à peu près à une table de base de données relationnelle.
+ Une *base de données* dans Amazon DocumentDB est un ensemble de collections et équivaut à peu près à un schéma dans une base de données relationnelle.

AWS DMS prend en charge deux modes de migration lors de l'utilisation d'Amazon DocumentDB comme source, le mode document et le mode table. Vous spécifiez le mode de migration lorsque vous créez le point de terminaison source Amazon DocumentDB dans la AWS DMS console, à l'aide de l'option **Mode métadonnées** ou de l'attribut de connexion supplémentaire. `nestingLevel` Vous trouverez ci-dessous une explication sur la manière dont le choix du mode de migration affecte le format des données cibles.

**Mode document**  
En *mode document*, le document JSON est migré tel quel. Cela signifie que les données du document sont regroupées dans l’un des deux éléments suivants. Lorsque vous utilisez une base de données relationnelle en tant que cible, les données correspondent à une colonne unique nommée `_doc` dans une table cible. Lorsque vous utilisez une base de données non relationnelle en tant que cible, les données correspondent à un document JSON unique. Le mode document est le mode par défaut. Nous recommandons de l’utiliser lors de la migration vers une cible Amazon DocumentDB.  
Prenons l’exemple des documents suivants dans une collection Amazon DocumentDB appelée `myCollection`.  

```
 db.myCollection.find()
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 }
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 }
```
Une fois les données migrées vers une table de base de données relationnelle à l'aide du mode document, les données sont structurées comme suit. Les champs de données du document sont regroupés dans la colonne ` _doc`.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DocumentDB.html)
Vous pouvez éventuellement définir l’attribut de connexion supplémentaire `extractDocID` sur `true` pour créer une seconde colonne nommée `"_id"`, qui servira de clé primaire. Si vous souhaitez utiliser la capture des données de modification (CDC), définissez ce paramètre sur `true`, sauf lorsque vous utilisez Amazon DocumentDB en tant que cible.  
Lorsque vous utilisez CDC avec des sources qui produisent des [transactions multidocuments](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), le `ExtractDocId` paramètre **doit être** défini sur. `true` Si ce paramètre n'est pas activé, la AWS DMS tâche échouera lorsqu'elle rencontrera une transaction comportant plusieurs documents.  
Si vous ajoutez une nouvelle collection à la base de données source, AWS DMS créez une nouvelle table cible pour la collection et répliquez tous les documents. 

**Mode table**  
En *mode table*,AWS DMS transforme chaque champ de niveau supérieur d’un document Amazon DocumentDB en colonne dans la table cible. Si un champ est imbriqué, AWS DMS ajuste les valeurs imbriquées dans une seule colonne. AWS DMS ajoute ensuite un champ clé et des types de données au jeu de colonnes de la table cible.   
Pour chaque document Amazon DocumentDB, AWS DMS ajoute chaque clé et chaque type au jeu de colonnes de la table cible. Par exemple, le mode table permet de AWS DMS migrer l'exemple précédent vers le tableau suivant.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DocumentDB.html)
Les valeurs imbriquées sont mises à plat dans une colonne contenant des noms de clé séparés par un point. La colonne est nommée en utilisant la forme concaténée des noms de champs mis à plat, séparés par des points. Par exemple, AWS DMS migre un document JSON contenant un champ de valeurs imbriquées, par exemple `{"a" : {"b" : {"c": 1}}}` dans une colonne nommée `a.b.c.`  
Pour créer les colonnes cibles, AWS DMS scanne un certain nombre de documents Amazon DocumentDB et crée un ensemble de tous les champs et de leurs types. AWS DMS utilise ensuite cet ensemble pour créer les colonnes de la table cible. Si vous créez ou modifiez le point de terminaison source Amazon DocumentDB à l’aide de la console, vous pouvez spécifier le nombre de documents à analyser. La valeur par défaut est de 1 000 documents. Si vous utilisez le AWS CLI, vous pouvez utiliser l'attribut de connexion supplémentaire`docsToInvestigate`.  
En mode tableau, AWS DMS gère les documents et les collections comme suit :  
+ Lorsque vous ajoutez un document à une collection existante, le document est répliqué. Si certains champs ne figurent pas dans la cible, ils ne sont pas répliqués.
+ Lorsque vous mettez à jour un document, celui-ci est répliqué. Si certains champs ne figurent pas dans la cible, ils ne sont pas répliqués.
+ La suppression d'un document est pleinement prise en charge.
+ L'ajout d'une nouvelle collection n'entraîne pas la création d'une nouvelle table dans la cible lorsque cela est effectué durant une tâche CDC.
+ Dans la phase Change Data Capture (CDC), AWS DMS il n'est pas possible de renommer une collection.

**Topics**
+ [Définition des autorisations pour utiliser Amazon DocumentDB en tant que source](#CHAP_Source.DocumentDB.Permissions)
+ [Configuration de CDC pour un cluster Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureCDC)
+ [Connexion à Amazon DocumentDB à l’aide du protocole TLS](#CHAP_Source.DocumentDB.TLS)
+ [Création d’un point de terminaison source Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureEndpoint)
+ [Segmentation des collections Amazon DocumentDB et migration en parallèle](#CHAP_Source.DocumentDB.ParallelLoad)
+ [Migration de plusieurs bases de données lors de l'utilisation d'Amazon DocumentDB comme source pour AWS DMS](#CHAP_Source.DocumentDB.Multidatabase)
+ [Limitations liées à l'utilisation d'Amazon DocumentDB comme source pour AWS DMS](#CHAP_Source.DocumentDB.Limitations)
+ [Utilisation des paramètres de point de terminaison avec Amazon DocumentDB en tant que source](#CHAP_Source.DocumentDB.ECAs)
+ [Types de données sources pour Amazon DocumentDB](#CHAP_Source.DocumentDB.DataTypes)

## Définition des autorisations pour utiliser Amazon DocumentDB en tant que source
<a name="CHAP_Source.DocumentDB.Permissions"></a>

Lorsque vous utilisez la source Amazon DocumentDB pour une AWS DMS migration, vous pouvez créer un compte utilisateur avec des privilèges root. Vous pouvez également créer un utilisateur doté d’autorisations uniquement pour la base de données à migrer. 

Le code suivant permet de créer un utilisateur en tant que compte racine.

```
use admin
db.createUser(
  {
    user: "root",
    pwd: "password",
    roles: [ { role: "root", db: "admin" } ]
  })
```

Pour Amazon DocumentDB 3.6, le code suivant permet de créer un utilisateur doté de privilèges minimum sur la base de données à migrer.

```
use db_name
db.createUser( 
    {
        user: "dms-user",
        pwd: "password",
        roles: [{ role: "read", db: "db_name" }]
    }
)
```

Pour Amazon DocumentDB 4.0 et versions ultérieures, AWS DMS utilise un flux de modifications à l'échelle du déploiement. Ici, le code suivant permet de créer un utilisateur doté de privilèges minimum.

```
db.createUser( 
{ 
    user: "dms-user",
    pwd: "password",
    roles: [ { role: "readAnyDatabase", db: "admin" }] 
})
```

## Configuration de CDC pour un cluster Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.ConfigureCDC"></a>

Pour utiliser la réplication continue ou le CDC avec Amazon DocumentDB, AWS DMS il faut accéder aux flux de modifications du cluster Amazon DocumentDB. Pour obtenir une description de la séquence chronologique des événements de mise à jour dans les collections et les bases de données de votre cluster, consultez [Utilisation des flux de modifications](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) dans le *Guide du développeur Amazon DocumentDB*. 

Authentifiez-vous auprès de votre cluster Amazon DocumentDB à l’aide du shell MongoDB. Ensuite, exécutez la commande suivante pour activer les flux de modifications.

```
db.adminCommand({modifyChangeStreams: 1,
    database: "DB_NAME",
    collection: "", 
    enable: true});
```

Cette approche active le flux de modifications pour toutes les collections de la base de données. Une fois les flux de modifications activés, vous pouvez créer une tâche de migration qui migre les données existantes tout en répliquant les modifications en cours. AWS DMS continue de capturer et d'appliquer les modifications même après le chargement des données en masse. Les bases de données sources et cibles sont finalement synchronisées, ce qui réduit au maximum le temps d’indisponibilité d’une migration.

**Note**  
AWS DMS utilise le journal des opérations (oplog) pour enregistrer les modifications au cours de la réplication en cours. Si Amazon DocumentDB efface les enregistrements du journal avant de les AWS DMS lire, vos tâches échoueront. Nous vous recommandons de dimensionner le journal des opérations pour conserver les modifications pendant au moins 24 heures.

## Connexion à Amazon DocumentDB à l’aide du protocole TLS
<a name="CHAP_Source.DocumentDB.TLS"></a>

Par défaut, un cluster Amazon DocumentDB récemment créé n’accepte que les connexions sécurisées qui utilisent le protocole TLS (Transport Layer Security). Lorsque le protocole TLS est activé, chaque connexion à Amazon DocumentDB nécessite une clé publique.

Vous pouvez récupérer la clé publique d'Amazon DocumentDB en téléchargeant le fichier `rds-combined-ca-bundle.pem` depuis un AWS compartiment Amazon S3 hébergé. Pour plus d’informations sur le téléchargement de ce fichier, consultez [Chiffrement des connexions à l’aide de TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) dans le *Guide du développeur Amazon DocumentDB*. 

Après avoir téléchargé le `rds-combined-ca-bundle.pem` fichier, vous pouvez importer la clé publique qu'il contient AWS DMS. Les étapes suivantes expliquent comment procéder.

**Pour importer votre clé publique à l'aide de la AWS DMS console**

1. Connectez-vous au AWS Management Console et choisissez AWS DMS.

1. Dans le volet de navigation, choisissez **Certificates**.

1. Sélectionnez **Importer un certificat**. La page **Importer un nouveau certificat de CA** s’affiche.

1. Dans la section **Configuration de certificat**, effectuez l’une des opérations suivantes :
   + Pour **Identifiant de certificat**, entrez un nom unique pour le certificat, par exemple `docdb-cert`.
   + Choisissez **Choisir un fichier**, accédez à l’emplacement où vous avez enregistré le fichier `rds-combined-ca-bundle.pem`, puis sélectionnez-le.

1. Choisissez **Ajouter un certificat CA**.

L'exemple AWS CLI suivant utilise la AWS DMS `import-certificate` commande pour importer le `rds-combined-ca-bundle.pem` fichier de clé publique.

```
aws dms import-certificate \
    --certificate-identifier docdb-cert \
    --certificate-pem file://./rds-combined-ca-bundle.pem
```

## Création d’un point de terminaison source Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.ConfigureEndpoint"></a>

Vous pouvez créer un point de terminaison source Amazon DocumentDB à l’aide de la console ou d’ AWS CLI. Procédez comme suit avec la console.

**Pour configurer un point de terminaison source Amazon DocumentDB à l'aide de la console AWS DMS**

1. Connectez-vous au AWS Management Console et choisissez AWS DMS.

1. Choisissez **Points de terminaison** dans le volet de navigation, puis **Créer un point de terminaison**.

1. Pour **Identifiant de point de terminaison**, indiquez un nom qui vous permet de l’identifier facilement, tel que `docdb-source`.

1. Pour **Moteur source**, choisissez **Amazon DocumentDB (compatible avec MongoDB)**.

1. Pour **Nom du serveur**, entrez le nom du serveur sur lequel réside le point de terminaison de la base de données Amazon DocumentDB. Par exemple, vous pouvez entrer le nom DNS public de votre instance Amazon EC2, tel que `democluster.cluster-cjf6q8nxfefi.us-east-2.docdb.amazonaws.com`.

1. Pour **Port**, entrez 27017.

1. Pour **SSL mode (Mode SSL)**, choisissez **verify-full**. Si vous avez désactivé SSL sur votre cluster Amazon DocumentDB, vous pouvez ignorer cette étape.

1. Pour **Certificat CA**, choisissez le certificat Amazon DocumentDB, `rds-combined-ca-bundle.pem`. Pour obtenir des instructions sur l’ajout de ce certificat, consultez [Connexion à Amazon DocumentDB à l’aide du protocole TLS](#CHAP_Source.DocumentDB.TLS).

1. Pour **Nom de base de données**, entrez le nom de la base de données à migrer.

Procédez comme suit avec l’interface de ligne de commande.

**Pour configurer un point de terminaison source Amazon DocumentDB à l'aide du AWS CLI**
+ Exécutez la AWS DMS `create-endpoint` commande suivante pour configurer un point de terminaison source Amazon DocumentDB, en remplaçant les espaces réservés par vos propres valeurs.

  ```
  aws dms create-endpoint \
             --endpoint-identifier a_memorable_name \
             --endpoint-type source \
             --engine-name docdb \
             --username value \
             --password value \
             --server-name servername_where_database_endpoint_resides \
             --port 27017 \
             --database-name name_of_endpoint_database
  ```

## Segmentation des collections Amazon DocumentDB et migration en parallèle
<a name="CHAP_Source.DocumentDB.ParallelLoad"></a>

Pour améliorer les performances d’une tâche de migration, les points de terminaison sources Amazon DocumentDB prennent en charge deux options de la fonctionnalité de chargement complet en parallèle dans le mappage de table. En d’autres termes, vous pouvez migrer une collection en parallèle en utilisant les options de segmentation automatique ou de segmentation par plage du mappage de table pour un chargement complet en parallèle dans les paramètres JSON. Les options de segmentation automatique vous permettent de spécifier les critères pour AWS DMS segmenter automatiquement votre source pour la migration dans chaque thread. Les options de segmentation de plage vous permettent de définir AWS DMS la plage spécifique de chaque segment pour que DMS migre dans chaque thread. Pour plus d’informations sur ces paramètres, consultez [Règles des paramètres de table et de collection et opérations](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).

### Migration d’une base de données Amazon DocumentDB en parallèle à l’aide de plages de segmentation automatique
<a name="CHAP_Source.DocumentDB.ParallelLoad.AutoPartitioned"></a>

Vous pouvez migrer vos documents en parallèle en spécifiant les critères AWS DMS pour partitionner (segmenter) automatiquement vos données pour chaque thread, notamment le nombre de documents à migrer par thread. En utilisant cette approche, AWS DMS tente d’optimiser les limites de segment pour augmenter les performances par thread.

Vous pouvez spécifier les critères de segmentation à l’aide des options table-settings suivantes dans table-mapping :


|  Option table-settings  |  Description  | 
| --- | --- | 
|  `"type"`  |  (Obligatoire) Définissez cette option sur `"partitions-auto"` pour Amazon DocumentDB en tant que source.  | 
|  `"number-of-partitions"`  |  (Facultatif) Nombre total de partitions (segments) utilisées pour la migration. La valeur par défaut est 16.  | 
|  `"collection-count-from-metadata"`  |  (Facultatif) Si ce paramètre est défini sur`true`, AWS DMS utilise une estimation du nombre de collectes pour déterminer le nombre de partitions. S'il est défini sur`false`, AWS DMS utilise le nombre réel de collectes. La valeur par défaut est `true`.  | 
|  `"max-records-skip-per-page"`  |  (Facultatif) Le nombre d'enregistrements à ignorer simultanément lors de la détermination des limites de chaque partition. AWS DMS utilise une approche de saut paginé pour déterminer la limite minimale d'une partition. La valeur par défaut est 10 000. La définition d’une valeur relativement élevée peut entraîner des délais d’expiration du curseur et des échecs de tâche. La définition d’une valeur relativement faible entraîne un plus grand nombre d’opérations par page et ralentit le chargement complet.   | 
|  `"batch-size"`  |  (Facultatif) Limite le nombre de documents renvoyés dans un lot. Chaque lot nécessite un aller retour jusqu’au serveur. Si la taille du lot est égale à zéro (0), le curseur utilise la taille de lot maximale définie par le serveur. La valeur par défaut est 0.  | 

L’exemple suivant illustre un mappage de table pour la segmentation automatique.

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "parallel-load": {
                "type": "partitions-auto",
                "number-of-partitions": 5,
                "collection-count-from-metadata": "true",
                "max-records-skip-per-page": 1000000,
                "batch-size": 50000
            }
        }
    ]
}
```

La segmentation automatique présente les limitations suivantes. Pour chaque segment, la migration extrait séparément le nombre de collections et la valeur minimale de `_id` pour la collection. Elle ignore ensuite un certain nombre d’enregistrements par page pour calculer la limite minimale pour ce segment. Par conséquent, assurez-vous que la valeur minimale de `_id` reste constante pour chaque collection, jusqu’à ce que toutes les limites de segment de la collection soient calculées. Si vous modifiez la valeur minimale de `_id` d’une collection lors du calcul de ses limites de segment, cela peut entraîner une perte de données ou des erreurs de lignes en double.

### Migration d’une base de données Amazon DocumentDB en parallèle à l’aide de plages de segments spécifiques
<a name="CHAP_Source.DocumentDB.ParallelLoad.Ranges"></a>

L’exemple suivant illustre une collection Amazon DocumentDB composée de sept éléments, qui utilise `_id` comme clé primaire.

![\[Collection Amazon DocumentDB composée de sept éléments.\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-docdb-collection.png)


Pour diviser la collection en trois segments et la migrer en parallèle, vous pouvez ajouter des règles de mappage de table à votre tâche de migration, comme indiqué dans l’exemple JSON suivant.

```
{ // Task table mappings:
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "rule-action": "include"
    }, // "selection" :"rule-type"
    {
      "rule-type": "table-settings",
      "rule-id": "2",
      "rule-name": "2",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "parallel-load": {
        "type": "ranges",
        "columns": [
           "_id",
           "num"
        ],
        "boundaries": [
          // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79
          // and num less-than-or-equal-to 2.
          [
             "5f805c97873173399a278d79",
             "2"
          ],
          // Second segment selects documents with _id > 5f805c97873173399a278d79 and
          // _id less-than-or-equal-to 5f805cc5873173399a278d7c and
          // num > 2 and num less-than-or-equal-to 5.
          [
             "5f805cc5873173399a278d7c",
             "5"
          ]                                   
          // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c.
        ] // :"boundaries"
      } // :"parallel-load"
    } // "table-settings" :"rule-type"
  ] // :"rules"
} // :Task table mappings
```

Cette définition de mappage de table divise la collection source en trois segments et la migre en parallèle. Les limites de segmentation sont les suivantes.

```
Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records)
Data with _id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 and not in (_id less-than-or-equal-to  "5f805c97873173399a278d79" and num less-than-or-equal-to 2) (3 records)
Data not in (_id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5) (2 records)
```

Une fois la tâche de migration terminée, vous pouvez vérifier dans les journaux de tâches que les tables sont chargées en parallèle, comme indiqué dans l’exemple suivant. Vous pouvez également vérifier la clause `find` d’Amazon DocumentDB utilisée pour décharger chaque segment de la table source.

```
[TASK_MANAGER    ] I:  Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86  (replicationtask_util.c:752)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is initialized.   (mongodb_unload.c:157)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } }  (mongodb_unload.c:328)

[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TASK_MANAGER    ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752)
 
[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) 

[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328)
 
[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TARGET_LOAD     ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480.

[TASK_MANAGER    ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred.
```

Actuellement, AWS DMS prend en charge les types de données Amazon DocumentDB suivants sous forme de colonne clé de segment :
+ Double
+ String
+ ObjectId
+ Entier 32 bits
+ Entier 64 bits

## Migration de plusieurs bases de données lors de l'utilisation d'Amazon DocumentDB comme source pour AWS DMS
<a name="CHAP_Source.DocumentDB.Multidatabase"></a>

AWS DMS les versions 3.4.5 et supérieures prennent en charge la migration de plusieurs bases de données en une seule tâche uniquement pour les versions 4.0 et supérieures d'Amazon DocumentDB. Si vous souhaitez migrer plusieurs bases de données, procédez comme suit :

1. Lorsque vous créez le point de terminaison source Amazon DocumentDB :
   + Dans le formulaire AWS DMS, AWS Management Console laissez le **nom de la base de données** vide sous **Configuration du point de terminaison** sur la page **Créer un point de terminaison**.
   + Dans le AWS Command Line Interface (AWS CLI), attribuez une valeur de chaîne vide au **DatabaseName**paramètre dans **Document DBSettings** que vous spécifiez pour l'**CreateEndpoint**action.

1. Pour chaque base de données que vous souhaitez migrer à partir de ce point de terminaison source Amazon DocumentDB, attribuez à chaque base de données le nom d’un schéma dans table-mapping pour la tâche en utilisant la saisie guidée dans la console ou directement dans le code JSON. Pour plus d’informations sur la saisie guidée, consultez la description dans [Spécification des règles de sélection de table et de transformation à partir de la console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Pour plus d’informations sur le code JSON, consultez [Règles et actions de sélection](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).

Vous pouvez par exemple spécifier le code JSON suivant pour migrer trois bases de données Amazon DocumentDB.

**Example Migrer toutes les tables dans un schéma**  
Le code JSON suivant permet de migrer toutes les tables à partir des bases de données `Customers`, `Orders` et `Suppliers` du point de terminaison source vers votre point de terminaison cible.  

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "Customers",
                "table-name": "%"
            },
            "object-locator": {
                "schema-name": "Orders",
                "table-name": "%"
            },
            "object-locator": {
                "schema-name": "Inventory",
                "table-name": "%"
            },
            "rule-action": "include"
        }
    ]
}
```

## Limitations liées à l'utilisation d'Amazon DocumentDB comme source pour AWS DMS
<a name="CHAP_Source.DocumentDB.Limitations"></a>

Les limites suivantes s'appliquent à l'utilisation d'Amazon DocumentDB comme source pour : AWS DMS
+ Lorsque l'option `_id` est définie comme une colonne distincte, la chaîne d'ID ne peut pas contenir plus de 200 caractères.
+ Les clés de type de tableau et d'ID d'objet sont converties en colonnes dotées des préfixes `array` et `oid` en mode table.

  En interne, ces colonnes sont référencées avec les noms préfixés. Si vous utilisez des règles de transformation AWS DMS qui font référence à ces colonnes, assurez-vous de spécifier la colonne préfixée. Par exemple, spécifiez `${oid__id}` et pas `${_id}`, ou `${array__addresses}` et pas `${_addresses}`. 
+  Les noms de collection et les noms de clé ne peuvent pas contenir le symbole du dollar (\$1). 
+ Le mode table et le mode document ont les limitations décrites précédemment.
+ La migration en parallèle à l’aide de la segmentation automatique présente les limitations décrites ci-dessus.
+ Une source Amazon DocumentDB (compatible avec MongoDB) ne prend pas en charge l’utilisation d’un horodatage spécifique comme position de départ pour la capture des données de modification (CDC). Une tâche de réplication continue commence à capturer les modifications quel que soit l’horodatage.
+ AWS DMS ne prend pas en charge les documents dont le niveau d'imbrication est supérieur à 97 pour les AWS DMS versions inférieures à 3.5.2.
+ Les filtres de source ne sont pas pris en charge pour DocumentDB.
+ AWS DMS ne prend pas en charge la réplication CDC (capture des données de modification) pour DocumentDB en tant que source en mode cluster élastique.

## Utilisation des paramètres de point de terminaison avec Amazon DocumentDB en tant que source
<a name="CHAP_Source.DocumentDB.ECAs"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source Amazon DocumentDB comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec Amazon DocumentDB en tant que source sont indiqués dans le tableau suivant.


| Nom d’attribut | Valeurs valides | Valeur par défaut et description | 
| --- | --- | --- | 
|   `NestingLevel`   |  `"none"` `"one"`  |  `"none"` : spécifiez `"none"` pour utiliser le mode document. Spécifiez `"one"` pour activer le mode table.  | 
|   `ExtractDocID`   |  `true` `false`  |  `false` : utilisez cet attribut lorsque `NestingLevel` est défini sur `"none"`.  Lorsque vous utilisez CDC avec des sources qui produisent des [transactions multidocuments](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), le `ExtractDocId` paramètre **doit être** défini sur. `true` Si ce paramètre n'est pas activé, la AWS DMS tâche échouera lorsqu'elle rencontrera une transaction comportant plusieurs documents.  | 
|   `DocsToInvestigate`   |  Un nombre entier positif supérieur à `0`.  |  `1000` : utilisez cet attribut lorsque `NestingLevel` est défini sur `"one"`.   | 
|   `ReplicateShardCollections `   |  `true` `false`  |  Lorsque c'est vrai, AWS DMS réplique les données vers des collections de partitions. AWS DMS utilise ce paramètre uniquement si le point de terminaison cible est un cluster Elastic DocumentDB. Lorsque ce paramètre est défini sur true, notez les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DocumentDB.html)  | 

## Types de données sources pour Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.DataTypes"></a>

Le tableau suivant répertorie présente les types de données sources Amazon DocumentDB pris en charge lors de l’utilisation de AWS DMS. Vous trouverez également le mappage par défaut à partir AWS DMS des types de données dans ce tableau. Pour plus d’informations sur les types de données, consultez [BSON types](https://docs.mongodb.com/manual/reference/bson-types) dans la documentation de MongoDB.

Pour obtenir des informations sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section relative au point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données Amazon DocumentDB  |  AWS DMS types de données  | 
| --- | --- | 
| Booléen | Booléen | 
| Binaire | BLOB | 
| Date | Date | 
| Horodatage | Date | 
| Int | INT4 | 
| Long | INT8 | 
| Double | REAL8 | 
| Chaîne (UTF-8) | CLOB | 
| Tableau | CLOB | 
| OID | String | 

# Utilisation d'Amazon S3 comme source pour AWS DMS
<a name="CHAP_Source.S3"></a>

Vous pouvez migrer des données depuis un compartiment Amazon S3 à l'aide de AWS DMS. Pour ce faire, fournissez un accès à un compartiment Amazon S3 contenant un ou plusieurs fichiers de données. Dans ce compartiment S3, incluez un fichier JSON qui décrit la mise en correspondance entre les données et les tables de base de données de ces données dans ces fichiers.

Les fichiers de données source doivent être présents dans le compartiment Amazon S3 avant que le chargement complet ne démarre. Vous spécifiez le nom de compartiment à l'aide du paramètre `bucketName`. 

Les fichiers de données sources peuvent être dans les formats suivants :
+ Valeur séparée par des virgules (.csv)
+ Parquet (version DMS 3.5.3 et versions ultérieures). Pour plus d'informations sur l'utilisation de fichiers au format Parquet, consultez. [Utilisation de fichiers au format Parquet dans Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.Parquet)

Pour les fichiers de données source au format de valeurs séparées par des virgules (.csv), nommez-les selon la convention de dénomination suivante. Dans cette convention, *`schemaName`* est le schéma source et *`tableName`* est le nom d'une table dans ce schéma.

```
/schemaName/tableName/LOAD001.csv
/schemaName/tableName/LOAD002.csv
/schemaName/tableName/LOAD003.csv
...
```

 Par exemple, supposons que vos fichiers de données se trouvent dans `amzn-s3-demo-bucket` au chemin Amazon S3 suivant.

```
s3://amzn-s3-demo-bucket/hr/employee
```

Au moment du chargement, AWS DMS suppose que le nom du schéma source est `hr` et que le nom de la table source est`employee`.

En plus de `bucketName` (ce qui est obligatoire), vous pouvez éventuellement fournir un `bucketFolder` paramètre pour spécifier où AWS DMS rechercher les fichiers de données dans le compartiment Amazon S3. En reprenant l'exemple précédent, si vous définissez `bucketFolder` sur`sourcedata`, AWS DMS lit les fichiers de données dans le chemin suivant.

```
s3://amzn-s3-demo-bucket/sourcedata/hr/employee
```

Vous pouvez spécifier le délimiteur de colonne, le délimiteur de ligne, l'indicateur de valeur null et d'autres paramètres à l'aide d'attributs de connexion supplémentaires. Pour de plus amples informations, veuillez consulter [Paramètres du point de terminaison pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.Configuring).

Vous pouvez spécifier le propriétaire du compartiment et empêcher toute tricherie en utilisant le paramètre de point de terminaison Amazon S3 `ExpectedBucketOwner`, comme indiqué ci-dessous. Ensuite, lorsque vous soumettez une demande pour tester une connexion ou effectuer une migration, S3 compare l’ID de compte du propriétaire du compartiment au paramètre spécifié.

```
--s3-settings='{"ExpectedBucketOwner": "AWS_Account_ID"}'
```

**Topics**
+ [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef)
+ [Utilisation du CDC avec Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.CDC)
+ [Conditions préalables à l'utilisation d'Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.Prerequisites)
+ [Limitations liées à l'utilisation d'Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.Limitations)
+ [Paramètres du point de terminaison pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.Configuring)
+ [Types de données source pour Amazon S3](#CHAP_Source.S3.DataTypes)
+ [Utilisation de fichiers au format Parquet dans Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.Parquet)

## Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS
<a name="CHAP_Source.S3.ExternalTableDef"></a>

En plus des fichiers de données, vous devez fournir une définition de table externe. Une *définition de table externe* est un document JSON qui décrit comment AWS DMS interpréter les données d'Amazon S3. La taille maximale de ce document est de 2 Mo. Si vous créez un point de terminaison source à l'aide AWS DMS de la console de gestion, vous pouvez saisir le code JSON directement dans le champ de mappage des tables. Si vous utilisez le AWS Command Line Interface (AWS CLI) ou l' AWS DMS API pour effectuer des migrations, vous pouvez créer un fichier JSON pour spécifier la définition de la table externe.

Supposons que vous disposez d'un fichier de données qui inclut les éléments suivants.

```
101,Smith,Bob,2014-06-04,New York
102,Smith,Bob,2015-10-08,Los Angeles
103,Smith,Bob,2017-03-13,Dallas
104,Smith,Bob,2017-03-13,Dallas
```

Voici un exemple de définition de table externe pour ces données.

```
{
    "TableCount": "1",
    "Tables": [
        {
            "TableName": "employee",
            "TablePath": "hr/employee/",
            "TableOwner": "hr",
            "TableColumns": [
                {
                    "ColumnName": "Id",
                    "ColumnType": "INT8",
                    "ColumnNullable": "false",
                    "ColumnIsPk": "true"
                },
                {
                    "ColumnName": "LastName",
                    "ColumnType": "STRING",
                    "ColumnLength": "20"
                },
                {
                    "ColumnName": "FirstName",
                    "ColumnType": "STRING",
                    "ColumnLength": "30"
                },
                {
                    "ColumnName": "HireDate",
                    "ColumnType": "DATETIME"
                },
                {
                    "ColumnName": "OfficeLocation",
                    "ColumnType": "STRING",
                    "ColumnLength": "20"
                }
            ],
            "TableColumnsTotal": "5"
        }
    ]
}
```

Les éléments figurant dans ce document JSON sont les suivants :

`TableCount` : nombre de tables source. Cet exemple comporte une seule table.

`Tables` : tableau comprenant un mappage JSON par table source. Cet exemple comporte une seule carte. Chaque carte comprend les éléments suivants :
+ `TableName` : nom de la table source.
+ `TablePath` : chemin dans votre compartiment Amazon S3 où AWS DMS peut trouver le fichier de chargement complet des données. Si une valeur `bucketFolder` est spécifiée, elle est ajoutée en préfixe au chemin.
+ `TableOwner` : nom du schéma pour cette table.
+ `TableColumns` : tableau d’un ou plusieurs mappages, chacun décrivant une colonne de la table source :
  + `ColumnName` : nom d’une colonne de la table source.
  + `ColumnType` : type de données de la colonne. Pour connaître les types de données valides, consultez [Types de données source pour Amazon S3](#CHAP_Source.S3.DataTypes).
  + `ColumnLength` : nombre d’octets dans cette colonne. La longueur de colonne maximale est limitée à 2147483647 octets (2 047 MegaBytes) car une source S3 ne supporte pas le mode FULL LOB. `ColumnLength`est valide pour les types de données suivants :
    + BYTE
    + CHAÎNE
  + `ColumnNullable` : valeur booléenne égale à `true` si cette colonne peut contenir des valeurs NULL (par défaut, `false`).
  + `ColumnIsPk` : valeur booléenne égale à `true` si cette colonne fait partie de la clé primaire (par défaut, `false`).
  + `ColumnDateFormat` : format de date d’entrée pour une colonne de types DATE, TIME et DATETIME ; utilisé pour analyser une chaîne de données dans un objet de date. Les valeurs possibles incluent :

    ```
    - YYYY-MM-dd HH:mm:ss
    - YYYY-MM-dd HH:mm:ss.F
    - YYYY/MM/dd HH:mm:ss
    - YYYY/MM/dd HH:mm:ss.F
    - MM/dd/YYYY HH:mm:ss
    - MM/dd/YYYY HH:mm:ss.F
    - YYYYMMdd HH:mm:ss
    - YYYYMMdd HH:mm:ss.F
    ```
+ `TableColumnsTotal` : nombre total de colonnes. Ce nombre doit correspondre au nombre d'éléments dans le tableau `TableColumns`.

Si vous ne spécifiez pas le contraire, AWS DMS supposez que `ColumnLength` c'est zéro.

**Note**  
Dans les versions prises en charge de AWS DMS, les données source S3 peuvent également contenir une colonne d'opération facultative comme première colonne avant la valeur de la `TableName` colonne. Cette colonne d'opération identifie l'opération (`INSERT`) utilisée pour migrer les données vers un point de terminaison cible S3 lors d'un chargement complet.   
Si elle est présente, la valeur de cette colonne est le caractère initial du mot-clé de l'opération `INSERT` (`I`). Si cette valeur est spécifiée, cette colonne indique généralement que la source S3 a été créée par DMS en tant que cible S3 au cours d'une migration précédente.   
Dans les versions de DMS antérieures à 3.4.2, cette colonne n’était pas présente dans les données source S3 créées à partir d’un chargement complet DMS précédent. L'ajout de cette colonne aux données cible S3 permet au format de toutes les lignes écrites dans la cible S3 d'être cohérent si celles-ci sont écrites lors d'un chargement complet ou d'un chargement CDC. Pour plus d'informations sur les options pour le formatage des données S3 cible, consultez [Indication des opérations de base de données source dans des données S3 migrées](CHAP_Target.S3.md#CHAP_Target.S3.Configuring.InsertOps).

Pour une colonne de type NUMERIC, spécifiez la précision et l'échelle. La *précision* est le nombre total de chiffres dans un nombre et l'*échelle* est le nombre de chiffres à droite de la virgule. Vous utilisez les éléments `ColumnPrecision` et `ColumnScale` pour cela, comme indiqué ci-après.

```
...
    {
        "ColumnName": "HourlyRate",
        "ColumnType": "NUMERIC",
        "ColumnPrecision": "5"
        "ColumnScale": "2"
    }
...
```

Pour une colonne de type DATETIME dont les données contiennent des fractions de seconde, spécifiez l’échelle. L’*échelle* est le nombre de chiffres pour les fractions de seconde. Elle est comprise entre 0 et 9. Vous utilisez l’élément `ColumnScale` pour cela, comme indiqué ci-après.

```
...
{
      "ColumnName": "HireDate",
      "ColumnType": "DATETIME",
      "ColumnScale": "3"
}
...
```

Si vous ne spécifiez pas le contraire, AWS DMS suppose qu'`ColumnScale`il est égal à zéro et tronque les fractions de secondes.

## Utilisation du CDC avec Amazon S3 comme source pour AWS DMS
<a name="CHAP_Source.S3.CDC"></a>

Après avoir AWS DMS effectué un chargement complet des données, il peut éventuellement répliquer les modifications de données sur le point de terminaison cible. Pour ce faire, vous chargez les fichiers de capture des données de modification (fichiers CDC) dans votre compartiment Amazon S3. AWS DMS lit ces fichiers CDC lorsque vous les téléchargez, puis applique les modifications au point de terminaison cible. 

Les fichiers CDC sont nommés comme suit :

```
CDC00001.csv
CDC00002.csv
CDC00003.csv
...
```

**Note**  
Pour répliquer des fichiers CDC dans le dossier des données de modification, chargez-les dans un ordre lexical (séquentiel). Par exemple, chargez le fichier CDC00002 .csv avant le fichier CDC00003 .csv. Sinon, le CDC00002 fichier .csv est ignoré et n'est pas répliqué si vous le chargez après le fichier .csv. CDC00003 Mais le fichier CDC00004 .csv se réplique correctement s'il est chargé après CDC00003 le fichier .csv.

Pour indiquer où se AWS DMS trouvent les fichiers, spécifiez le `cdcPath` paramètre. Pour continuer avec l'exemple précédent, si vous définissez `cdcPath` sur `changedata`, AWS DMS lit les fichiers CDC correspondant au chemin suivant.

```
s3://amzn-s3-demo-bucket/changedata
```

Si vous définissez `cdcPath` sur `changedata` et `bucketFolder` sur `myFolder`, AWS DMS lit les fichiers CDC au chemin suivant.

```
s3://amzn-s3-demo-bucket/myFolder/changedata
```

Les enregistrements figurant dans un fichier CDC sont formatés comme suit :
+ Opération : opération de modification à effectuer : `INSERT` ou `I`, `UPDATE` ou `U`, `DELETE` ou `D`. Ces mot-clé et ces valeurs de caractères ne sont pas sensibles à la casse.
**Note**  
Dans AWS DMS les versions prises en charge, AWS DMS vous pouvez identifier l'opération à effectuer pour chaque enregistrement de chargement de deux manières. AWS DMS peut le faire à partir de la valeur du mot clé de l'enregistrement (par exemple,`INSERT`) ou à partir du caractère initial du mot clé (par exemple,`I`). Dans les versions précédentes, l'opération de chargement était AWS DMS reconnue uniquement à partir de la valeur complète du mot clé.   
Dans les versions précédentes de AWS DMS, la valeur complète du mot clé était écrite pour enregistrer les données du CDC. De plus, les versions précédentes écrivaient la valeur d’opération sur toute cible S3 à l’aide du mot-clé initial uniquement.   
La reconnaissance des deux formats AWS DMS permet de gérer l'opération quelle que soit la manière dont la colonne d'opération est écrite pour créer les données source S3. Cette approche prend en charge l'utilisation de données cible S3 comme source pour une migration ultérieure. Avec cette approche, vous n'avez pas besoin de modifier le format de la valeur initiale d'un mot-clé qui apparaît dans la colonne d'opération de la source S3 ultérieure.
+ Nom de la table : nom de la table source.
+ Nom du schéma : nom du schéma source.
+ Données : une ou plusieurs colonnes qui représentent les données à modifier.

Voici un exemple de fichier CDC pour une table nommée `employee`.

```
INSERT,employee,hr,101,Smith,Bob,2014-06-04,New York
UPDATE,employee,hr,101,Smith,Bob,2015-10-08,Los Angeles
UPDATE,employee,hr,101,Smith,Bob,2017-03-13,Dallas
DELETE,employee,hr,101,Smith,Bob,2017-03-13,Dallas
```

## Conditions préalables à l'utilisation d'Amazon S3 comme source pour AWS DMS
<a name="CHAP_Source.S3.Prerequisites"></a>

Pour utiliser Amazon S3 comme source pour AWS DMS, votre compartiment S3 source doit se trouver dans la même AWS région que l'instance de réplication DMS qui migre vos données. De plus, le compte AWS que vous utilisez pour la migration doit avoir un accès en lecture au compartiment source. Pour les AWS DMS versions 3.4.7 et supérieures, DMS doit accéder au compartiment source via un point de terminaison VPC ou une route publique. Pour plus d'informations sur les points de terminaison VPC, consultez. [Configuration des points de terminaison VPC pour AWS DMS](CHAP_VPC_Endpoints.md)

Le rôle Gestion des identités et des accès AWS (IAM) attribué au compte utilisateur utilisé pour créer la tâche de migration doit disposer de l'ensemble d'autorisations suivant.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
       {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*"
            ]
        }
    ]
}
```

------

Le rôle Gestion des identités et des accès AWS (IAM) attribué au compte utilisateur utilisé pour créer la tâche de migration doit disposer de l'ensemble d'autorisations suivant si le versionnement est activé sur le compartiment Amazon S3.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
       {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*"
            ]
        }
    ]
}
```

------

## Limitations liées à l'utilisation d'Amazon S3 comme source pour AWS DMS
<a name="CHAP_Source.S3.Limitations"></a>

Les limitations suivantes s’appliquent lorsque vous utilisez Amazon S3 en tant que source :
+ N’activez pas la gestion des versions pour S3. Si vous avez besoin de la gestion des versions S3, utilisez des politiques de cycle de vie pour supprimer les anciennes versions de manière active. Dans le cas contraire, la connexion de test du point de terminaison risque d’échouer en raison du délai d’attente d’appel `list-object` S3. Pour créer une politique de cycle de vie pour un compartiment S3, consultez [Gestion du cycle de vie de votre stockage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). Pour supprimer une version d’un objet S3, consultez [Suppression des versions d’objet d’un compartiment activé pour la gestion des versions](https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html).
+ Un compartiment S3 compatible VPC (VPC de passerelle) est pris en charge dans les versions 3.4.7 et ultérieures.
+ MySQL convertit le `time` type de données en. `string` Pour voir les valeurs `time` des types de données dans MySQL, définissez la colonne de la table cible comme `string` suit et définissez le paramètre du **mode de préparation de la table cible** de la tâche sur **Truncate**.
+ AWS DMS utilise le type de `BYTE` données en interne pour les données à la fois dans les types de `BYTES` données `BYTE` et de données.
+ Les points de terminaison source S3 ne prennent pas en charge la fonctionnalité de rechargement des tables DMS.
+ AWS DMS ne prend pas en charge le mode LOB complet avec Amazon S3 en tant que source.

Les limites suivantes s'appliquent lors de l'utilisation de fichiers au format Parquet dans Amazon S3 en tant que source :
+ Les dates sont incluses `MMYYYYDD` ou ne `DDMMYYYY` sont pas prises en charge pour la fonctionnalité de partitionnement de dates de S3 Parquet Source.

## Paramètres du point de terminaison pour Amazon S3 en tant que source pour AWS DMS
<a name="CHAP_Source.S3.Configuring"></a>

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source Amazon S3 comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--s3-settings '{"EndpointSetting": "value", ...}'` JSON.

**Note**  
AWS DMS utilise par défaut une connexion sécurisée au point de terminaison Amazon S3 sans qu'il soit nécessaire de spécifier le mode ou le certificat SSL.

Les paramètres de point de terminaison que vous pouvez utiliser avec Amazon S3 en tant que source sont indiqués dans le tableau suivant.


| **Option** | **Description** | 
| --- | --- | 
| BucketFolder |  (Facultatif) Un nom de dossier dans le compartiment S3. Si cet attribut est spécifié, les fichiers de données source et les fichiers CDC sont lus à partir du chemin `s3://amzn-s3-demo-bucket/bucketFolder/schemaName/tableName/` et `s3://amzn-s3-demo-bucket/bucketFolder/`, respectivement. Si cet attribut n'est pas spécifié, le chemin utilisé est `schemaName/tableName/`.  `'{"BucketFolder": "sourceData"}'`  | 
| BucketName |  Le nom du compartiment S3. `'{"BucketName": "amzn-s3-demo-bucket"}'`  | 
| CdcPath | Emplacement des fichiers CDC. Cet attribut est requis si une tâche capture les données modifiées ; dans le cas contraire, il est facultatif. S'il CdcPath est présent, AWS DMS lit les fichiers CDC à partir de ce chemin et réplique les modifications de données sur le point de terminaison cible. Pour de plus amples informations, veuillez consulter [Utilisation du CDC avec Amazon S3 comme source pour AWS DMS](#CHAP_Source.S3.CDC). `'{"CdcPath": "changeData"}'`  | 
| CsvDelimiter |  Le délimiteur utilisé pour séparer les colonnes des fichiers sources. La valeur par défaut est une virgule. Un exemple suit. `'{"CsvDelimiter": ","}'`  | 
| CsvNullValue |  Chaîne définie par l'utilisateur qui est AWS DMS considérée comme nulle lors de la lecture depuis la source. La valeur par défaut est une chaîne vide. Si vous ne définissez pas ce paramètre, AWS DMS traite une chaîne vide comme une valeur nulle. Si vous définissez ce paramètre sur une chaîne telle que « \$1 N », AWS DMS traitez cette chaîne comme une valeur nulle et traitez les chaînes vides comme une valeur de chaîne vide.  | 
| CsvRowDelimiter |  Le délimiteur utilisé pour séparer les lignes des fichiers sources. La valeur par défaut est un caractère de saut de ligne (`\n`). `'{"CsvRowDelimiter": "\n"}'`  | 
| DataFormat |  Définissez cette valeur sur `Parquet` pour lire les données au format Parquet. `'{"DataFormat": "Parquet"}'`  | 
| IgnoreHeaderRows |  Lorsque cette valeur est définie sur 1, AWS DMS ignore le premier en-tête de ligne d'un fichier .csv. La valeur 1 active la fonctionnalité, la valeur 0 désactive la fonctionnalité. La valeur par défaut est 0. `'{"IgnoreHeaderRows": 1}'`  | 
| Rfc4180 |  Lorsque cette valeur est définie sur `true` ou `y`, chaque guillemet double de tête doit être suivi d’un guillemet double de fin. Ce format est conforme à RFC 4180. Lorsque ce paramètre est défini sur `false` ou `n`, les chaînes littérales sont copiées vers la cible en l'état. Dans ce cas, un délimiteur de colonne ou de ligne indique la fin du champ. Par conséquent, vous ne pouvez pas utiliser un délimiteur dans le cadre de la chaîne, car il indique une fin de la valeur. La valeur par défaut est `true`. Valeurs valides : `true`, `false`, `y`, `n` `'{"Rfc4180": false}'`  | 

## Types de données source pour Amazon S3
<a name="CHAP_Source.S3.DataTypes"></a>

Migration de données utilisant Amazon S3 comme source pour les AWS DMS besoins de mappage des données d'Amazon S3 vers AWS DMS des types de données. Pour de plus amples informations, veuillez consulter [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef).

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).

Les types de AWS DMS données suivants sont utilisés avec Amazon S3 comme source :
+ BYTE : requiert `ColumnLength`. Pour de plus amples informations, veuillez consulter [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ DATE
+ TIME
+ DATETIME : pour plus d’informations et pour obtenir un exemple, consultez l’exemple de type DATETIME dans [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ INT1
+ INT2
+ INT4
+ INT8
+ NUMÉRIQUE — Nécessite `ColumnPrecision` et. `ColumnScale` AWS DMS prend en charge les valeurs maximales suivantes :
  + **ColumnPrecision: 38**
  + **ColumnScale: 31**

  Pour plus d’informations et pour obtenir un exemple, consultez l’exemple de type NUMERIC dans [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ REAL4
+ REAL8
+ STRING : requiert `ColumnLength`. Pour de plus amples informations, veuillez consulter [Définition de tables externes pour Amazon S3 en tant que source pour AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ UINT1
+ UINT2
+ UINT4
+ UINT8
+ BLOB
+ CLOB
+ BOOLEAN

## Utilisation de fichiers au format Parquet dans Amazon S3 comme source pour AWS DMS
<a name="CHAP_Source.S3.Parquet"></a>

Dans les AWS DMS versions 3.5.3 et ultérieures, vous pouvez utiliser des fichiers au format Parquet dans un compartiment S3 comme source pour la réplication à chargement complet ou la réplication CDC. 

DMS prend uniquement en charge les fichiers au format Parquet en tant que source que DMS génère en migrant des données vers un point de terminaison cible S3. Les noms de fichiers doivent être au format pris en charge, sinon DMS ne les inclura pas dans la migration.

Pour les fichiers de données source au format Parquet, ils doivent se trouver dans le dossier et dans la convention de dénomination suivants.

```
schema/table1/LOAD00001.parquet
schema/table2/LOAD00002.parquet
schema/table2/LOAD00003.parquet
```

Pour les fichiers de données source pour les données CDC au format Parquet, nommez-les et stockez-les en utilisant le dossier et la convention de dénomination suivants.

```
schema/table/20230405-094615814.parquet
schema/table/20230405-094615853.parquet
schema/table/20230405-094615922.parquet
```

Pour accéder aux fichiers au format Parquet, définissez les paramètres de point de terminaison suivants :
+ Définissez `DataFormat` sur `Parquet`. 
+ Ne définissez pas le `cdcPath` réglage. Assurez-vous de créer vos fichiers au format Parquet dans les dossiers de schéma ou de table spécifiés. 

*Pour plus d'informations sur les paramètres des points de terminaison S3, consultez [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) dans la référence de l'AWS Database Migration Service API.*

### Types de données pris en charge pour les fichiers au format Parquet
<a name="CHAP_Source.S3.Parquet.Datatypes"></a>

AWS DMS prend en charge les types de données source et cible suivants lors de la migration de données à partir de fichiers au format Parquet. Assurez-vous que votre table cible comporte des colonnes contenant les types de données appropriés avant de procéder à la migration.


| Type de données source | Types de données cibles | 
| --- | --- | 
| BYTE | BINARY | 
| DATE | DATE32 | 
| TIME | TIME32 | 
| DATETIME | TIMESTAMP | 
| INT1 | INT8 | 
| INT2 | INT16 | 
| INT4 | INT32 | 
| INT8 | INT64 | 
| NUMERIC | DECIMAL | 
| REAL4 | FLOAT | 
| REAL8 | DOUBLE | 
| STRING | STRING | 
| UINT1 | UINT8 | 
| UINT2 | UINT16 | 
| UINT4 | UINT32 | 
| UINT8 | UINT | 
| WSTRING | STRING | 
| BLOB | BINARY | 
| NCLOB | STRING | 
| CLOB | STRING | 
| BOOLEAN | BOOL | 

# Utilisation d'IBM Db2 pour Linux, Unix, Windows et de la base de données Amazon RDS (Db2 LUW) comme source pour AWS DMS
<a name="CHAP_Source.DB2"></a>

Vous pouvez migrer les données d'une base de données IBM Db2 pour Linux, Unix, Windows et Amazon RDS (Db2 LUW) vers n'importe quelle base de données cible prise en charge à l'aide de (). AWS Database Migration Service AWS DMS

Pour plus d'informations sur les versions de Db2 sous Linux, Unix, Windows et RDS qui sont prises AWS DMS en charge en tant que source, consultez. [Sources pour AWS DMS](CHAP_Introduction.Sources.md) 

Vous pouvez utiliser le protocole SSL pour chiffrer les connexions entre votre point de terminaison Db2 LUW et l'instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison Db2 LUW, consultez [Utilisation du protocole SSL avec AWS Database Migration Service](CHAP_Security.SSL.md).

Lorsqu'elle AWS DMS lit des données depuis une base de données source IBM Db2, elle utilise le niveau d'isolation par défaut CURSOR STABILITY (CS) pour Db2 version 9.7 et versions ultérieures. Pour plus d'informations, consultez la [documentation IBM Db2 pour Linux, UNIX et Windows](https://www.ibm.com/docs/en/db2/12.1.0).

## Conditions préalables à l'utilisation de DB2 LUW comme source pour AWS DMS
<a name="CHAP_Source.DB2.Prerequisites"></a>

Les conditions préalables suivantes sont requises pour que vous puissiez utiliser une base de données Db2 LUW comme source.

Pour activer la réplication continue, également appelée capture de données modifiées (CDC), effectuez les opérations suivantes :
+ Définissez la base de données pour qu'elle soit récupérable, ce qui AWS DMS nécessite de capturer les modifications. Une base de données est récupérable si l’un ou les deux paramètres de configuration de base de données `LOGARCHMETH1` ou `LOGARCHMETH2` sont définis sur `ON`.

  Si votre base de données est récupérable, vous AWS DMS pouvez accéder au Db2 `ARCHIVE LOG` si nécessaire.
+ Assurez-vous que les journaux de DB2 transactions sont disponibles, avec une période de conservation suffisante pour être traités par AWS DMS. 
+ DB2 requiert `SYSADM` ou `DBADM` autorise l'extraction des enregistrements du journal des transactions. Accordez les autorisations suivantes au compte utilisateur :
  + `SYSADM` ou `DBADM`
  + `DATAACCESS`
**Note**  
Pour les tâches à chargement complet uniquement, le compte d’utilisateur DMS doit disposer de l’autorisation DATAACCESS.
+ Lorsque vous utilisez IBM DB2 for LUW version 9.7 comme source, définissez l'attribut de connexion supplémentaire (ECA) `CurrentLsn` comme suit :

  `CurrentLsn=LSN`, où `LSN` spécifie un numéro de séquence de journal (LSN) à partir duquel vous souhaitez démarrer la réplication. Ou `CurrentLsn=scan`.
+ Lorsque vous utilisez Amazon RDS pour DB2 LUW comme source, assurez-vous que les journaux d'archivage sont disponibles pour. AWS DMSÉtant donné que les bases de données DB2 AWS gérées purgent les journaux d'archives dès que possible, vous devez augmenter la durée pendant laquelle les journaux restent disponibles. Par exemple, pour augmenter la durée de conservation des journaux à 24 heures, exécutez la commande suivante :

  ```
  db2 "call rdsadmin.set_archive_log_retention( ?, 'TESTDB', '24')"
  ```

  Pour plus d'informations sur les procédures Amazon RDS pour DB2 LUW, consultez la [référence des procédures stockées Amazon RDS pour DB2](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/db2-stored-procedures.html) dans le guide de l'utilisateur d'*Amazon Relational Database Service*.
+ Accordez les privilèges suivants si vous utilisez DB2 des évaluations de prémigration spécifiques :

  ```
  GRANT CONNECT ON DATABASE TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBM.SYSDUMMY1 TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBMADM.ENV_INST_INFO TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBMADM.DBCFG TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.SCHEMATA TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.COLUMNS TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.TABLES TO USER <DMS_USER>;
  GRANT EXECUTE ON FUNCTION SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID TO <DMS_USER>;
  GRANT EXECUTE ON PACKAGE NULLID.SYSSH200 TO USER <DMS_USER>;
  ```

## Limitations liées à l'utilisation de DB2 LUW comme source pour AWS DMS
<a name="CHAP_Source.DB2.Limitations"></a>

AWS DMS ne prend pas en charge les bases de données en cluster. Toutefois, vous pouvez définir une base de données Db2 LUW distincte pour chacun des points de terminaison d'un cluster. Par exemple, vous pouvez créer une tâche de migration à chargement complet avec l’un des nœuds du cluster, puis créer des tâches distinctes à partir de chaque nœud.

AWS DMS ne prend pas en charge le type de `BOOLEAN` données de votre base de données source DB2 LUW.

Les limitations suivantes s'appliquent lorsque vous utilisez la réplication continue (CDC) :
+ Lorsqu'une table comportant plusieurs partitions est tronquée, le nombre d'événements DDL affichés dans la AWS DMS console est égal au nombre de partitions. En effet, Db2 LUW enregistre une DDL distincte pour chaque partition.
+ Les actions de DDL suivantes ne sont pas prises en charge sur les tables partitionnées :
  + ALTER TABLE ADD PARTITION
  + ALTER TABLE DETACH PARTITION
  + ALTER TABLE ATTACH PARTITION
+ AWS DMS ne prend pas en charge une migration de réplication continue à partir d'une instance de secours HADR ( DB2High Availability Disaster Recovery). L’instance de secours n’est pas accessible.
+ Le type de données DECFLOAT n'est pas pris en charge. Par conséquent, les modifications apportées aux colonnes DECFLOAT sont ignorées lors de la réplication continue.
+ L'instruction RENAME COLUMN n'est pas prise en charge.
+ Lorsque vous effectuez des mises à jour de tables de clustering multidimensionnel (MDC), chaque mise à jour est affichée dans la AWS DMS console sous la forme INSERT \$1 DELETE.
+ Lorsque le paramètre de tâche **Inclure les colonnes LOB dans la réplication** n'est pas activé, toute table comportant des colonnes LOB est suspendue pendant la réplication continue.
+ Pour les versions 10.5 et supérieures de DB2 LUW, les colonnes de chaîne de longueur variable contenant des données stockées sont ignorées. out-of-row Cette limitation s’applique uniquement aux tables créées avec une taille de ligne étendue pour les colonnes dont les types de données sont VARCHAR et VARGRAPHIC. Pour contourner cette limitation, déplacez la table vers un espace de table dont la taille de page est supérieure. Pour plus d'informations, voir [Que puis-je faire si je souhaite modifier le format de page des DB2 espaces disque logiques]( https://www.ibm.com/support/pages/what-can-i-do-if-i-want-change-pagesize-db2-tablespaces ) ?
+ Pour une réplication continue, DMS ne prend pas en charge la migration des données chargées au niveau de la page par l'utilitaire DB2 LOAD. Utilisez plutôt l’utilitaire IMPORT qui utilise des insertions SQL. Pour plus d’informations, consultez les [différences entre les utilitaires d’importation et de chargement]( https://www.ibm.com/docs/en/db2/11.1?topic=utilities-differences-between-import-load-utility). 
+ Pendant l'exécution d'une tâche de réplication, DMS capture CREATE TABLE DDLs uniquement si les tables ont été créées avec l'attribut DATA CAPTURE CHANGE.
+ DMS présente les limites suivantes lors de l'utilisation de la fonctionnalité de partition de base de données (DPF) DB2 :
  + DMS ne peut pas coordonner les transactions entre les nœuds DB2 dans un environnement DPF. Cela est dû à des contraintes au sein de l'interface API IBM DB2 READLOG. Dans le format DPF, les transactions peuvent s'étendre sur plusieurs nœuds DB2, en fonction de la manière dont les données sont DB2 partitionnées. Par conséquent, votre solution DMS doit capturer les transactions de chaque nœud DB2 indépendamment.
  + DMS peut capturer les transactions locales à partir de chaque nœud Db2 du cluster DPF en le configurant `1` sur plusieurs points de `connectNode` terminaison sources DMS. Cette configuration correspond aux numéros de nœuds logiques définis dans le fichier de configuration DB2 du serveur`db2nodes.cfg`.
  + Les transactions locales sur des nœuds Db2 individuels peuvent faire partie d'une transaction globale plus importante. DMS applique chaque transaction locale indépendamment sur la cible, sans coordination avec les transactions sur les autres nœuds Db2. Ce traitement indépendant peut entraîner des complications, notamment lorsque des lignes sont déplacées entre des partitions.
  + Lorsque DMS se réplique à partir de plusieurs nœuds Db2, il n'y a aucune garantie quant à l'ordre correct des opérations sur la cible, car le DMS applique les opérations indépendamment pour chaque nœud Db2. Vous devez vous assurer que la capture des transactions locales indépendamment de chaque nœud DB2 fonctionne pour votre cas d'utilisation spécifique.
  + Lors de la migration depuis un environnement DPF, nous vous recommandons d'exécuter d'abord une tâche de chargement complet sans événements mis en cache, puis d'exécuter des tâches uniquement en mode CDC. Nous recommandons d'exécuter une tâche par nœud DB2, en commençant par l'horodatage de début du chargement complet ou le LRI (identifiant d'enregistrement du journal) que vous avez défini à l'aide de l'attribut de connexion `StartFromContext` endpoint extra. Pour plus d'informations sur la détermination du point de départ de la réplication, consultez [la section Recherche de la valeur LSN ou LRI pour le démarrage de la réplication](https://www.ibm.com/support/pages/db2-finding-lsn-or-lri-value-replication-start) dans la documentation *IBM Support*. 
+ Pour la réplication continue (CDC), si vous prévoyez de démarrer la réplication à partir d'un horodatage spécifique, vous devez définir l'attribut de connexion `StartFromContext` supplémentaire sur l'horodatage requis.
+ À l'heure actuelle, DMS ne prend pas en charge la fonctionnalité Db2 PureScale, une extension de DB2 LUW que vous pouvez utiliser pour dimensionner votre solution de base de données.
+ L'option `DATA CAPTURE CHANGES` table est une condition préalable essentielle aux processus de réplication des DB2 données. Le fait de ne pas activer cette option lors de la création de tables peut entraîner des données manquantes, en particulier pour les tâches de réplication CDC (Change Data Capture) uniquement initiées depuis un point de départ antérieur. AWS DMS activera cet attribut par défaut lors du redémarrage d'une tâche CDC ou FULL\$1CDC. Cependant, les modifications apportées à la base de données source avant le redémarrage de la tâche risquent de ne pas être prises en compte.

  ```
  ALTER TABLE TABLE_SCHEMA.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;
  ```

## Paramètres du point de terminaison lors de l'utilisation de DB2 LUW comme source pour AWS DMS
<a name="CHAP_Source.DB2.ConnectionSettings"></a>

Vous pouvez spécifier les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console, ou à l'aide de la `create-endpoint` commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/create-endpoint.html)figurant dans le

`--ibm-db2-settings '{"EndpointSetting1": "value1","EndpointSetting2": "value2"}'`

Syntaxe JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec Db2 LUW en tant que source sont indiqués dans le tableau suivant.


| Nom du paramètre | Description | 
| --- | --- | 
|  `CurrentLsn`  |  Pour une réplication en continu (CDC), utilisez `CurrentLsn` pour spécifier un numéro de séquence de journal où vous voulez que la réplication démarre.   | 
|  `MaxKBytesPerRead`  |  Nombre maximal d'octets par lecture, sous forme d'une valeur NUMÉRIQUE (NUMBER). La valeur par défaut est de 64 Ko.  | 
|  `SetDataCaptureChanges`  |  Active la réplication en continu (CDC) en tant que valeur BOOLÉENNE. Par défaut, la valeur est true.  | 

## Attributs de connexion supplémentaires (ECAs) lors de l'utilisation de DB2 LUW comme source pour AWS DMS
<a name="CHAP_Source.DB2.ConnectionAttrib"></a>

Vous pouvez spécifier les attributs de connexion supplémentaires (ECAs) lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console, ou à l'aide de la `create-endpoint` commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/create-endpoint.html)figurant dans le

`--extra-connection-attributes 'ECAname1=value1;ECAname2=value2;'`

Le tableau suivant indique ECAs ce que vous pouvez utiliser avec DB2 LUW comme source.


| Nom d'attribut | Description | 
| --- | --- | 
|  `ConnectionTimeout`  |  Utilisez cet ECA pour définir le délai de connexion du point de terminaison pour le point de terminaison DB2 LUW, en secondes. La valeur par défaut est de 10 secondes. Exemple : `ConnectionTimeout=30;`  | 
|  `executeTimeout`  |  Attribut de connexion supplémentaire qui définit le délai d'expiration de l'instruction (requête) pour le point de terminaison DB2 LUW, en secondes. La valeur par défaut est de 60 secondes. Exemple : `executeTimeout=120;`  | 
|  `StartFromContext`  |  Pour une réplication continue (CDC), utilisez `StartFromContext` pour spécifier la limite inférieure d’un journal à partir de laquelle démarrer la réplication. `StartFromContext` accepte différentes formes de valeurs. Les valeurs valides sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Source.DB2.html) Pour déterminer la LRI/LSN plage d'un fichier journal, exécutez la `db2flsn` commande comme indiqué dans l'exemple suivant. <pre>db2flsn -db SAMPLE -lrirange 2</pre> La sortie est similaire à l’exemple suivant.  <pre><br />S0000002.LOG: has LRI range 00000000000000010000000000002254000000000004F9A6 to <br />000000000000000100000000000022CC000000000004FB13</pre> Dans cette sortie, le fichier journal est S0000002.LOG et la valeur du **StartFromContext**LRI correspond aux 34 octets situés à la fin de la plage. <pre>0100000000000022CC000000000004FB13</pre>  | 

## Types de données source pour IBM Db2 LUW
<a name="CHAP_Source.DB2.DataTypes"></a>

La migration de données qui utilise Db2 LUW comme source prend en AWS DMS charge la plupart des types de données DB2 LUW. Le tableau suivant indique les types de données source DB2 LUW pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données. Pour plus d'informations sur les types de donnée Db2 LUW, consultez la [documentation Db2 LUW](https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008483.html).

Pour obtenir des informations sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section relative au point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Types de données Db2 LUW  |  AWS DMS types de données  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  DECIMAL (p,s)  |  NUMERIC (p,s)  | 
|  FLOAT  |  REAL8  | 
|  DOUBLE  |  REAL8  | 
|  REAL  |  REAL4  | 
|  DECFLOAT (p)  |  Si la précision est 16, alors REAL8 ; si la précision est 34, alors STRING  | 
|  GRAPHIC (n)  |  WSTRING, pour des chaînes graphiques à longueur fixe de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 127  | 
|  VARGRAPHIC (n)  |  WSTRING, pour des chaînes graphiques à longueur variable, avec une longueur supérieure à 0 et inférieure ou égale à 16 352 caractères à 2 octets  | 
|  LONG VARGRAPHIC (n)  |  CLOB, pour des chaînes graphiques à longueur variable, avec une longueur supérieure à 0 et inférieure ou égale à 16 352 caractères à 2 octets  | 
|  CHARACTER (n)  |  STRING, pour des chaînes à longueur fixe de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 255  | 
|  VARCHAR(n)  |  STRING, pour des chaînes à longueur variable de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 32,704  | 
|  LONG VARCHAR (n)  |  CLOB, pour des chaînes à longueur variable de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 32,704  | 
|  CHAR (n) FOR BIT DATA  |  BYTES  | 
|  VARCHAR (n) FOR BIT DATA  |  BYTES  | 
|  LONG VARCHAR FOR BIT DATA  |  BYTES  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIMESTAMP  |  DATETIME  | 
|  BLOB (n)  |  BLOB La longueur maximale est de 2 147 483 647 octets  | 
|  CLOB (n)  |  CLOB La longueur maximale est de 2 147 483 647 octets  | 
|  DBCLOB (n)  |  CLOB La longueur maximale est de 1 073 741 824 caractères à deux octets  | 
|  xml  |  CLOB  | 

# Utilisation d'IBM Db2 pour les z/OS bases de données comme source pour AWS DMS
<a name="CHAP_Source.DB2zOS"></a>

Vous pouvez migrer les données d'une base de données IBM for vers n'importe quelle z/OS base de données cible prise en charge à l'aide de AWS Database Migration Service (AWS DMS). 

Pour plus d'informations sur les versions de DB2 prises z/OS AWS DMS en charge en tant que source, consultez[Sources pour AWS DMS](CHAP_Introduction.Sources.md).

## Conditions préalables à l'utilisation de Db2 pour z/OS comme source pour AWS DMS
<a name="CHAP_Source.DB2zOS.Prerequisites"></a>

Pour utiliser une z/OS base de données IBM Db2 for comme entrée source AWS DMS, accordez les privilèges suivants à la base de données Db2 pour l' z/OS utilisateur spécifié dans les paramètres de connexion du point de terminaison source.

```
GRANT SELECT ON SYSIBM.SYSTABLES TO Db2USER;
GRANT SELECT ON SYSIBM.SYSTABLESPACE TO Db2USER;
GRANT SELECT ON SYSIBM.SYSTABLEPART TO Db2USER;                    
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO Db2USER;
GRANT SELECT ON SYSIBM.SYSDATABASE TO Db2USER;
GRANT SELECT ON SYSIBM.SYSDUMMY1 TO Db2USER
```

Accordez également les tables source SELECT ON `user defined`.

Un point de terminaison AWS DMS IBM Db2 for z/OS source s'appuie sur le pilote de serveur de données IBM pour ODBC pour accéder aux données. Le serveur de base de données doit disposer d’une licence IBM ODBC Connect valide pour que DMS puisse se connecter à ce point de terminaison.

## Limitations liées à l'utilisation de Db2 pour z/OS comme source pour AWS DMS
<a name="CHAP_Source.DB2zOS.Limitations"></a>

Les limites suivantes s'appliquent lors de l'utilisation d'une z/OS base de données IBM Db2 for comme source pour AWS DMS :
+ Seules les tâches de réplication à chargement complet sont prises en charge. La capture des données modifiées (CDC) n'est pas prise en charge.
+ Le chargement parallèle n’est pas pris en charge.
+ La validation de données des vues n’est pas prise en charge.
+ Les noms des schémas, des tables et des colonnes doivent être spécifiés en MAJUSCULES dans les mappages de tables pour les transformations de Column/table niveau et les filtres de sélection au niveau des lignes.

## Types de données source pour IBM Db2 for z/OS
<a name="CHAP_Source.DB2zOS.DataTypes"></a>

Les migrations de données qui utilisent Db2 z/OS comme source prennent en AWS DMS charge la plupart des types de données DB2 pour les types de z/OS données. Le tableau suivant présente le Db2 pour les types de données z/OS source pris en charge lors de l'utilisation AWS DMS, ainsi que le mappage par défaut à partir AWS DMS des types de données.

Pour plus d'informations sur Db2 pour les types de z/OS données, consultez la [documentation IBM Db2](https://www.ibm.com/docs/en/db2-for-zos/12?topic=elements-data-types). z/OS 

Pour obtenir des informations sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section relative au point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  DB2 pour les types de z/OS données  |  AWS DMS types de données  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  DECIMAL (p,s)  |  NUMERIC (p,s) Si une virgule est définie sur une virgule (,) dans la DB2 configuration, configurez Replicate pour prendre en charge le paramètre. DB2   | 
|  FLOAT  |  REAL8  | 
|  DOUBLE  |  REAL8  | 
|  REAL  |  REAL4  | 
|  DECFLOAT (p)  |  Si la précision est 16, alors REAL8 ; si la précision est 34, alors STRING  | 
|  GRAPHIC (n)  |  Si n>=127, alors WSTRING, pour des chaînes graphiques à longueur fixe de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 127  | 
|  VARGRAPHIC (n)  |  WSTRING, pour des chaînes graphiques à longueur variable, avec une longueur supérieure à 0 et inférieure ou égale à 16 352 caractères à 2 octets  | 
|  LONG VARGRAPHIC (n)  |  CLOB, pour des chaînes graphiques à longueur variable, avec une longueur supérieure à 0 et inférieure ou égale à 16 352 caractères à 2 octets  | 
|  CHARACTER (n)  |  STRING, pour des chaînes à longueur fixe de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 255  | 
|  VARCHAR(n)  |  STRING, pour des chaînes à longueur variable de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 32,704  | 
|  LONG VARCHAR (n)  |  CLOB, pour des chaînes à longueur variable de caractères à deux octets, avec une longueur supérieure à 0 et inférieure ou égale à 32,704  | 
|  CHAR (n) FOR BIT DATA  |  BYTES  | 
|  VARCHAR (n) FOR BIT DATA  |  BYTES  | 
|  LONG VARCHAR FOR BIT DATA  |  BYTES  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIMESTAMP  |  DATETIME  | 
|  BLOB (n)  |  BLOB La longueur maximale est de 2 147 483 647 octets  | 
|  CLOB (n)  |  CLOB La longueur maximale est de 2 147 483 647 octets  | 
|  DBCLOB (n)  |  CLOB La longueur maximale est de 1 073 741 824 caractères à deux octets  | 
|  xml  |  CLOB  | 
|  BINAIRE  |  BYTES  | 
|  VARBINARY  |  BYTES  | 
|  ROWID  |  BYTES. Pour plus d’informations sur l’utilisation de ROWID, consultez les rubriques suivantes.   | 
|  TIMESTAMP WITH TIME ZONE  |  Non pris en charge.  | 

Les colonnes ROWID sont migrées par défaut lorsque le mode de préparation des tables cibles pour la tâche est défini sur DROP\$1AND\$1CREATE (par défaut). La validation des données ignore ces colonnes, car les lignes n’ont aucun sens en dehors de la base de données et de la table spécifiques. Pour désactiver la migration de ces colonnes, vous pouvez effectuer l’une des étapes préparatoires suivantes : 
+ Pré-créez la table cible sans ces colonnes. Définissez ensuite le mode de préparation des tables cibles de la tâche sur DO\$1NOTHING ou TRUNCATE\$1BEFORE\$1LOAD. Vous pouvez utiliser AWS Schema Conversion Tool (AWS SCT) pour créer au préalable la table cible sans les colonnes.
+ Ajoutez une règle de mappage de table à une tâche qui filtre ces colonnes afin qu’elles soient ignorées. Pour de plus amples informations, veuillez consulter [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).

## Classements EBCDIC dans le service de modernisation de PostgreSQL pour les mainframes AWS
<a name="CHAP_Source.DB2zOS.EBCDIC"></a>

AWS Le programme de modernisation du mainframe vous aide à moderniser vos applications mainframe pour les adapter à des environnements d'exécution AWS gérés. Il fournit des outils et des ressources pour vous aider à planifier et à implémenter vos projets de migration et de modernisation. Pour plus d'informations sur la modernisation et la migration du mainframe, voir [Modernisation du mainframe](https://aws.amazon.com/mainframe/) avec. AWS

Certains ensembles de z/OS données IBM Db2 for sont codés dans le jeu de caractères EBCDIC (Extended Binary Coded Decimal Interchange). Ce jeu de caractères développé avant ASCII (American Standard Code for Information Interchange) est désormais couramment utilisé. Une *page de code* mappe chaque caractère du texte aux caractères d’un jeu de caractères. Une page de code traditionnelle contient les informations de mappage entre un point de code et un ID de caractère. Un *ID de caractère* est une chaîne de données de caractères de 8 octets. Un *point de code* est un nombre binaire de 8 bits qui représente un caractère. Les points de code sont généralement des représentations hexadécimales de leurs valeurs binaires.

Si vous utilisez actuellement Micro Focus ou BluAge un composant du service Mainframe Modernization, vous devez demander de AWS DMS *décaler* (traduire) certains points de code. Vous pouvez utiliser les paramètres des AWS DMS tâches pour effectuer les quarts de travail. L'exemple suivant montre comment utiliser l' AWS DMS `CharacterSetSettings`opération pour mapper les changements dans un paramètre de tâche DMS.

```
"CharacterSetSettings": {
        "CharacterSetSupport": null,
        "CharacterReplacements": [
{"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
            }
        ]
    }
```

Certains classements EBCDIC existent déjà pour PostgreSQL et comprennent le décalage nécessaire. Plusieurs pages de code différentes sont prises en charge. Les sections suivantes fournissent des exemples JSON de ce que vous devez décaler pour toutes les pages de code prises en charge. Vous pouvez simplement saisir copy-and-past le JSON dont vous avez besoin dans votre tâche DMS.

### Classements EBCDIC spécifiques à Micro Focus
<a name="CHAP_Source.DB2zOS.EBCDIC.MicroFocus"></a>

Pour Micro Focus, décalez un sous-ensemble de caractères selon vos besoins pour les classements suivants.

```
 da-DK-cp1142m-x-icu
 de-DE-cp1141m-x-icu
 en-GB-cp1146m-x-icu
 en-US-cp1140m-x-icu
 es-ES-cp1145m-x-icu
 fi-FI-cp1143m-x-icu
 fr-FR-cp1147m-x-icu
 it-IT-cp1144m-x-icu
 nl-BE-cp1148m-x-icu
```

**Example Décalages de données Micro Focus par classement :**  
**en\$1us\$1cp1140m**  
Décalage de code :  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1141m**  
Décalage de code :  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1142m**  
Décalage de code :  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1143m**  
Décalage de code :  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1144m**  
Décalage de code :  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1145m**  
Décalage de code :  

```
0000    0180
00A6    0160
00B8    0161
00A8    017D
00BC    017E
00BD    0152
00BE    0153
00B4    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1146m**  
Décalage de code :  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1147m**  
Décalage de code :  

```
0000    0180
00B8    0160
00A8    0161
00BC    017D
00BD    017E
00BE    0152
00B4    0153
00A6    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1148m**  
Décalage de code :  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```

### BluAge collations EBCDIC spécifiques
<a name="CHAP_Source.DB2zOS.EBCDIC.BluAge"></a>

Pour BluAge, décalez toutes les *valeurs basses* et *hautes* suivantes selon vos besoins. Ces classements ne doivent être utilisés que pour prendre en charge le BluAge service de migration du mainframe.

```
da-DK-cp1142b-x-icu
 da-DK-cp277b-x-icu
 de-DE-cp1141b-x-icu
 de-DE-cp273b-x-icu
 en-GB-cp1146b-x-icu
 en-GB-cp285b-x-icu
 en-US-cp037b-x-icu
 en-US-cp1140b-x-icu
 es-ES-cp1145b-x-icu
 es-ES-cp284b-x-icu
 fi-FI-cp1143b-x-icu
 fi-FI-cp278b-x-icu 
 fr-FR-cp1147b-x-icu
 fr-FR-cp297b-x-icu
 it-IT-cp1144b-x-icu
 it-IT-cp280b-x-icu
 nl-BE-cp1148b-x-icu
 nl-BE-cp500b-x-icu
```

**Example BluAge Changements de données :**  
**da-DK-cp277b** et **da-DK-cp1142b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**de-DE-273b** et **de-DE-1141b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**en-GB-285b** et **en-GB-1146b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**en-us-037b** et **en-us-1140b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**es-ES-284b** et **es-ES-1145b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**fi\$1FI-278b** et **fi-FI-1143b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**fr-FR-297b** et **fr-FR-1147b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**it-IT-280b** et **it-IT-1144b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**nl-BE-500b** et **nl-BE-1148b**  
Décalage de code :  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappage d'entrée correspondant pour une AWS DMS tâche :  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```