Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Spécification des paramètres de conversion de schéma pour les projets de migration
Après avoir créé un projet de migration, vous pouvez spécifier les paramètres de conversion dans la conversion de schéma DMS. La configuration de vos paramètres de conversion de schéma permet d’améliorer les performances du code converti.
**Pour modifier les paramètres de conversion**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Choisissez **Projets de migration**. La page **Projets de migration** s’ouvre.
1. Choisissez votre projet de migration. Choisissez **Conversion de schéma**, puis **Lancer la conversion de schéma**.
1. Cliquez sur **Paramètres**. La page **Paramètres** s’ouvre.
1. Dans la section **Conversion**, modifiez les paramètres.
1. Choisissez **Appliquer**, puis **Conversion de schéma**.
Pour toutes les paires de conversion, vous pouvez limiter le nombre de commentaires contenant des éléments d’action dans le code converti. Pour limiter le nombre de commentaires dans le code converti, ouvrez les paramètres de conversion dans votre projet de migration.
Pour **Commentaires dans le code SQL converti**, choisissez le niveau de gravité des éléments d’action. La conversion de schéma DMS ajoute des commentaires dans le code converti pour les éléments d’action de gravité sélectionnée et supérieure. Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**.
Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
Les autres paramètres de conversion sont différents pour chaque paire de bases de données sources et cibles.
**Topics**
+ [Comprendre les paramètres de conversion d'Oracle vers MySQL](schema-conversion-oracle-mysql.md)
+ [Comprendre les paramètres de conversion d'Oracle vers PostgreSQL](schema-conversion-oracle-postgresql.md)
+ [Comprendre les paramètres de conversion de SQL Server vers MySQL](schema-conversion-sql-server-mysql.md)
+ [Comprendre les paramètres de conversion de SQL Server vers PostgreSQL](schema-conversion-sql-server-postgresql.md)
+ [Comprendre les paramètres de conversion de PostgreSQL vers MySQL](schema-conversion-postgresql-mysql.md)
+ [Comprendre les paramètres de conversion d'IBM Db2 for LUW vers Amazon RDS for PostgreSQL](schema-conversion-db2-luw-postgresql.md)
+ [Comprendre les paramètres de conversion d'IBM Db2 z/OS pour Amazon RDS pour DB2](schema-conversion-db2-zos-db2.md)
+ [Comprendre les paramètres de conversion d'IBM Db2 for z/OS vers Amazon RDS for PostgreSQL](schema-conversion-db2-zos-postgresql.md)
+ [Comprendre les paramètres de conversion de SAP ASE (Sybase ASE) vers PostgreSQL](schema-conversion--sybase-ASE.md)
# Comprendre les paramètres de conversion d'Oracle vers MySQL
Les paramètres de conversion Oracle vers MySQL dans la conversion de schéma DMS sont les suivants :
+ Votre base de données Oracle source peut utiliser la pseudocolonne `ROWID`. MySQL ne prend pas en charge de fonctionnalité similaire. La conversion de schéma DMS peut émuler la pseudocolonne `ROWID` dans le code converti. Pour ce faire, activez l’option **Générer l’ID de ligne**.
Si votre code Oracle source n’utilise pas la pseudocolonne `ROWID`, désactivez l’option **Générer l’ID de ligne**. Dans ce cas, le code converti fonctionne plus rapidement.
+ Votre code Oracle source peut inclure les fonctions `TO_CHAR`, `TO_DATE` et `TO_NUMBER` avec des paramètres que MySQL ne prend pas en charge. Par défaut, la conversion de schéma DMS émule l’utilisation de ces paramètres dans le code converti.
Vous pouvez utiliser les fonctions `TO_CHAR`, `TO_DATE` et `TO_NUMBER` MySQL natives lorsque votre code Oracle source ne contient pas de paramètres non pris en charge par MySQL. Dans ce cas, le code converti fonctionne plus rapidement. Pour ce faire, sélectionnez les valeurs suivantes :
+ **Utiliser une fonction MySQL TO\$1CHAR native**
+ **Utiliser une fonction MySQL TO\$1DATE native**
+ **Utiliser une fonction MySQL TO\$1NUMBER native**
+ Votre base de données et vos applications peuvent s’exécuter dans différents fuseaux horaires. Par défaut, la conversion de schéma DMS émule les fuseaux horaires dans le code converti. Toutefois, vous n’avez pas besoin de cette émulation lorsque votre base de données et vos applications utilisent le même fuseau horaire. Dans ce cas, sélectionnez **Améliorer les performances du code converti lorsque la base de données et les applications utilisent le même fuseau horaire**.
# Comprendre les paramètres de conversion d'Oracle vers PostgreSQL
Les paramètres de conversion Oracle vers PostgreSQL dans la conversion de schéma DMS sont les suivants :
+ Pour convertir les objets de base de données applicables à l'aide de l'IA générative, activez le paramètre **IA générative**. Les objets convertis avec succès à l'aide de l'IA générative seront clairement identifiés grâce à **l'élément d'action 5444**, qui stipule : « Cette conversion utilise des modèles d'apprentissage automatique qui génèrent des prédictions basées sur des modèles de données. Pour de plus amples informations, veuillez consulter [Conversion d'objets de base de données avec l'IA générative](schema-conversion-convert.databaseobjects.md).
+ Vous pouvez convertir les schémas correspondant aux différentes versions prises en charge de votre base de données cible, et pas uniquement à la version la plus récente. Pour spécifier une version, utilisez le paramètre de **version du moteur cible**. Les options de conversion disponibles varient en fonction de la version du moteur que vous sélectionnez. Actuellement, les versions 14 et 15 de PostgreSQL sont prises en charge (leurs paramètres sont identiques). Notez que l'utilisation d'une version du moteur cible lors de la conversion du schéma différente de la version spécifiée dans ce paramètre peut entraîner des problèmes de compatibilité et des erreurs lors de l'exécution de l'opération Appliquer à la cible.
+ AWS DMS peut convertir les vues matérialisées Oracle en tables ou en vues matérialisées sur PostgreSQL. Pour **Vues matérialisées**, choisissez le mode de conversion de vos vues matérialisées sources.
+ Votre base de données Oracle source peut utiliser la pseudocolonne `ROWID`. PostgreSQL ne prend pas en charge de fonctionnalité similaire. La conversion de schéma DMS peut émuler la pseudocolonne `ROWID` dans le code converti à l’aide du type de données `bigint` ou `character varying`. Pour ce faire, choisissez **Utiliser le type de données bigint pour émuler la pseudocolonne ROWID** ou **Utiliser le type de données character varying pour émuler la pseudocolonne ROWID** pour **ID de ligne**.
+ Pour convertir le type de données NUMBER en le type de données numérique le mieux adapté, en fonction de la précision et de l'échelle, vous pouvez sélectionner Utiliser le mappage de type de données optimisé pour les colonnes du type de données NUMBER.
+ Si votre code Oracle source n’utilise pas la pseudocolonne `ROWID`, choisissez **Ne pas générer**. Dans ce cas, le code converti fonctionne plus rapidement.
+ Votre code Oracle source peut inclure les fonctions `TO_CHAR`, `TO_DATE` et `TO_NUMBER` avec des paramètres que PostgreSQL ne prend pas en charge. Par défaut, la conversion de schéma DMS émule l’utilisation de ces paramètres dans le code converti.
Vous pouvez utiliser les fonctions `TO_CHAR`, `TO_DATE` et `TO_NUMBER` PostgreSQL natives lorsque votre code Oracle source ne contient pas de paramètres non pris en charge par PostgreSQL. Dans ce cas, le code converti fonctionne plus rapidement. Pour ce faire, sélectionnez les valeurs suivantes :
+ **Utiliser une fonction PostgreSQL TO\$1CHAR native**
+ **Utiliser une fonction PostgreSQL TO\$1DATE native**
+ **Utiliser une fonction PostgreSQL TO\$1NUMBER native**
+ Votre base de données et vos applications peuvent s’exécuter dans différents fuseaux horaires. Par défaut, la conversion de schéma DMS émule les fuseaux horaires dans le code converti. Toutefois, vous n’avez pas besoin de cette émulation lorsque votre base de données et vos applications utilisent le même fuseau horaire. Dans ce cas, sélectionnez **Améliorer les performances du code converti lorsque la base de données et les applications utilisent le même fuseau horaire**.
+ Pour continuer à utiliser des séquences dans votre code converti, sélectionnez **Remplir les séquences converties avec la dernière valeur générée côté source**.
+ Dans certains cas, la base de données Oracle source peut uniquement stocker des valeurs entières dans les colonnes de clé primaire ou étrangère du type de données `NUMBER`. Dans ces cas, AWS DMS vous pouvez convertir ces colonnes en type de `BIGINT` données. Cette approche améliore les performances de votre code converti. Pour ce faire, sélectionnez **Convertir les colonnes de clé primaire et étrangère du type de données NUMBER en type de données BIGINT**. Assurez-vous que votre source n’inclut pas de valeurs à virgule flottante dans ces colonnes pour éviter toute perte de données.
+ Pour ignorer les déclencheurs et les contraintes désactivés dans votre code source, choisissez **Convertir uniquement les déclencheurs et les contraintes actifs**.
+ Vous pouvez utiliser la conversion de schéma DMS pour convertir des variables de chaîne appelées en tant que code SQL dynamique. Le code de la base de données peut modifier les valeurs de ces variables de chaîne. Pour vous assurer que cela convertit AWS DMS toujours la dernière valeur de cette variable de chaîne, sélectionnez **Convertir le code SQL dynamique créé dans des routines appelées**.
+ PostgreSQL versions 10 et antérieures ne prend pas en charge les procédures. Si vous n'êtes pas habitué à utiliser les procédures dans PostgreSQL AWS DMS , vous pouvez convertir les procédures Oracle en fonctions PostgreSQL. Pour ce faire, sélectionnez **Convertir les procédures en fonctions**.
+ Pour obtenir des informations supplémentaires sur les éléments d’action qui se sont produits, vous pouvez ajouter des fonctions spécifiques au pack d’extension. Pour ce faire, sélectionnez **Ajouter des fonctions de pack d’extension qui déclenchent des exceptions définies par l’utilisateur**. Choisissez ensuite les niveaux de gravité pour déclencher les exceptions définies par l’utilisateur. Assurez-vous d’appliquer le schéma du pack d’extension après avoir converti vos objets de base de données source. Pour plus d’informations sur les packs d’extension, consultez [Utilisation de packs d’extension](extension-pack.md).
+ Votre base de données Oracle source peut inclure des contraintes avec les noms générés automatiquement. Si votre code source utilise ces noms, assurez-vous de sélectionner **Conserver les noms des contraintes générées par le système**. Si votre code source utilise ces contraintes, mais pas leur nom, désactivez cette option pour augmenter la vitesse de conversion.
+ Si vos bases de données sources et cibles s’exécutent dans des fuseaux horaires différents, la fonction qui émule la fonction Oracle intégrée `SYSDATE` renvoie des valeurs différentes de celles de la fonction source. Pour garantir que vos fonctions source et cible renvoient les mêmes valeurs, choisissez **Définir le fuseau horaire de la base de données source**.
+ Vous pouvez utiliser les fonctions de l’extension orafce dans votre code converti. Pour ce faire, pour **Routines intégrées orafce**, sélectionnez les fonctions à utiliser. Pour plus d'informations sur Oracle, voir [orace](https://github.com/orafce/orafce) on. GitHub
# Comprendre les paramètres de conversion de SQL Server vers MySQL
Les paramètres de conversion SQL Server vers MySQL dans la conversion de schéma DMS sont les suivants :
+ Votre base de données SQL Server source peut stocker le résultat de `EXEC` dans une table. La conversion de schéma DMS crée des tables temporaires et une procédure supplémentaire pour émuler cette fonctionnalité. Pour utiliser cette émulation, sélectionnez **Créer des routines supplémentaires pour gérer les jeux de données ouverts**.
# Comprendre les paramètres de conversion de SQL Server vers PostgreSQL
Les paramètres de conversion SQL Server vers PostgreSQL dans la conversion de schéma DMS sont les suivants :
+ Pour convertir les objets de base de données applicables à l'aide de l'IA **générative, activez le paramètre IA générative**. Les objets convertis avec succès à l'aide de l'IA générative seront clairement identifiés grâce à **l'élément d'action 7744**, qui stipule : « Cette conversion utilise des modèles d'apprentissage automatique qui génèrent des prédictions basées sur des modèles de données ». Pour de plus amples informations, veuillez consulter [Conversion d'objets de base de données avec l'IA générative](schema-conversion-convert.databaseobjects.md).
+ Dans SQL Server, vous pouvez utiliser des index portant le même nom dans différentes tables. Toutefois, dans PostgreSQL, tous les noms d’index que vous utilisez dans le schéma doivent être uniques. Pour vous assurer que la conversion de schéma DMS génère des noms uniques pour tous vos index, sélectionnez **Générer des noms uniques pour les index**.
+ PostgreSQL versions 10 et antérieures ne prend pas en charge les procédures. Si vous n'êtes pas habitué à utiliser les procédures dans PostgreSQL AWS DMS , vous pouvez convertir les procédures SQL Server en fonctions PostgreSQL. Pour ce faire, sélectionnez **Convertir les procédures en fonctions**.
+ Votre base de données SQL Server source peut stocker le résultat de `EXEC` dans une table. La conversion de schéma DMS crée des tables temporaires et une procédure supplémentaire pour émuler cette fonctionnalité. Pour utiliser cette émulation, sélectionnez **Créer des routines supplémentaires pour gérer les jeux de données ouverts**.
+ Vous pouvez définir le modèle à utiliser pour les noms de schéma dans le code converti. Pour **Noms de schémas**, choisissez l’une des options suivantes :
+ **DB** : utilise le nom de base de données SQL Server en tant que nom de schéma dans PostgreSQL.
+ **SCHEMA** : utilise le nom de schéma SQL Server en tant que nom de schéma dans PostgreSQL.
+ **DB\$1SCHEMA** : utilise une combinaison des noms de schéma et de base de données SQL Server en tant que nom de schéma dans PostgreSQL.
+ Vous pouvez conserver les lettres majuscules dans les noms des opérandes sources. Pour éviter la conversion des noms d'opérandes en minuscules, sélectionnez **Éviter de convertir les noms en minuscules pour les opérations qui font la distinction entre majuscules et minuscules**. Cette option n'est applicable que si la fonction de distinction majuscules/minuscules est activée dans la base de données source.
+ Vous pouvez conserver les noms de paramètre de la base de données source. La conversion de schéma DMS peut ajouter des guillemets doubles aux noms des paramètres dans le code converti. Pour ce faire, sélectionnez **Conserver les noms des paramètres d’origine**.
+ Vous pouvez conserver la longueur des paramètres de routine de votre base de données source. La conversion de schéma DMS crée des domaines et les utilise pour spécifier la longueur des paramètres de routine. Pour ce faire, sélectionnez **Conserver la longueur des paramètres**.
+ Pour convertir des objets intégrés non pris en charge en objets stub, activez le paramètre **Convertir les objets intégrés non pris en charge en objets stub** :
+ Lorsqu'il est activé, DMS SC remplace les objets intégrés non pris en charge par les objets stub correspondants dans la base de données cible. Cette fonctionnalité convertit les sections de code qui seraient normalement incluses dans le problème de migration 7811 ou 7904. Il crée des objets stub en fonction du type des objets intégrés source `PROCEDURE` pour les procédures, les vues ou `VIEW` les tables.
La conversion d'un objet de base de données source avec un appel d'un objet non pris en charge entraîne un appel d'un objet stub et un problème de migration 7822.
Vous pouvez choisir de créer des objets stub dans un schéma distinct en activant l'option **Créer des objets stub dans un schéma distinct**. Lorsque cette option est sélectionnée, les objets stub sont créés dans un schéma spécial nommé `aws_sqlserver_stub` dans la base de données cible. S'ils ne sont pas sélectionnés, ils sont créés dans le même schéma que les objets appelants.
+ Les routines Stub sont nommées en fonction du nom complet de la routine intégrée d'origine. Pour les vues stub, la convention de dénomination inclut le nom `system_schema_name$builtin_view_name` du schéma du système.
Lors de la reconversion, le DMS SC vérifie la présence de routines stub existantes dans la base de données cible. Si une routine portant le même nom et les mêmes paramètres d'entrée existe déjà, elle n'est pas remplacée.
Après la conversion, passez en revue et implémentez le code personnalisé pour les routines stub selon les besoins.
+ `CITEXT`le type de données pour tous les types de données de chaîne définis dans DMS Schema Conversion inclut les éléments suivants :
+ **Pour utiliser le `CITEXT` type de données pour des opérations de chaîne qui ne distinguent pas les majuscules des minuscules lors de la conversion de SQL Server vers PostgreSQL, activez le paramètre Utiliser CITEXT pour tous les types de données de chaîne.** Cette option permet de maintenir un comportement cohérent lors de la migration d'un serveur SQL ne distinguant pas les majuscules et minuscules vers un environnement PostgreSQL distinguant les majuscules et minuscules.
+ Lorsqu'il est activé, le DMS SC convertit tous les types de données de chaîne pertinents de la base de données source SQL Server vers PostgreSQL. `CITEXT` Cela élimine le besoin d'appels de fonction LOWER () explicites dans les conditions et convertit automatiquement les expressions de chaîne dans les opérations conditionnelles en`CITEXT`.
+ Pour déterminer si votre instance SQL Server distingue les majuscules et minuscules, exécutez la requête suivante :
```
SELECT SERVERPROPERTY('COLLATION');
```
Un résultat contenant « CI » indique l'absence de distinction majuscules/majuscules, tandis que « CS » indique la distinction majuscules/minuscules.
+ La `CITEXT` conversion peut ne pas s'appliquer dans les scénarios dans lesquels des paramètres de classement explicites distinguant les majuscules et minuscules sont utilisés au niveau du serveur, de la base de données ou des colonnes.
Pour utiliser cette fonctionnalité, assurez-vous que le `CITEXT` module est installé et disponible dans votre base de données PostgreSQL cible.
+ Lorsque vous utilisez la conversion de `CITEXT` type de données, tenez compte des meilleures pratiques suivantes :
+ Activez cette fonctionnalité lors de la migration depuis un serveur SQL ne distinguant pas les majuscules des minuscules afin de maintenir un comportement cohérent dans PostgreSQL.
+ Vérifiez le code de votre application pour vous assurer qu'il ne repose pas sur des opérations de chaîne faisant la distinction majuscules/majuscules.
+ Testez soigneusement votre application après la migration pour vérifier que le comportement insensible aux majuscules et minuscules est maintenu comme prévu.
# Comprendre les paramètres de conversion de PostgreSQL vers MySQL
Les paramètres de conversion de PostgreSQL vers MySQL dans DMS Schema Conversion sont les suivants :
+ **Commentaires dans le code SQL converti** : ce paramètre inclut des commentaires dans le code converti pour les actions dont le niveau de gravité est sélectionné ou supérieur. Ce paramètre prend en charge les valeurs suivantes :
+ Erreurs uniquement
+ Erreurs et avertissements
+ Tous les messages
# Comprendre les paramètres de conversion d'IBM Db2 for LUW vers Amazon RDS for PostgreSQL
**Note**
La console AWS de gestion ne prend pas en charge la création de projets de migration dans DMS Schema Conversion qui utilisent IBM Db2 for LUW comme fournisseur de données source et Amazon RDS for PostgreSQL comme fournisseur de données cibles. Utilisez plutôt l'API de conversion de schéma AWS CLI ou DMS.
Les paramètres de conversion d'IBM Db2 pour Linux, UNIX et Windows vers Amazon RDS for PostgreSQL dans DMS Schema Conversion sont les suivants :
+ **Commentaires dans le code SQL converti** : ce paramètre inclut des commentaires dans le code converti pour les actions dont le niveau de gravité est sélectionné ou supérieur. Ce paramètre prend en charge les valeurs suivantes :
+ Erreurs uniquement
+ Erreurs et avertissements
+ Tous les messages
# Comprendre les paramètres de conversion d'IBM Db2 z/OS pour Amazon RDS pour DB2
Les paramètres de DB2 conversion d'IBM pour z/OS vers Amazon RDS dans DMS Schema Conversion sont les suivants :
+ **Commentaires dans le code SQL converti** : ce paramètre inclut des commentaires dans le code converti pour les actions dont le niveau de gravité est sélectionné ou supérieur. Ce paramètre prend en charge les valeurs suivantes :
+ Erreurs uniquement
+ Erreurs et avertissements
+ Tous les messages
# Comprendre les paramètres de conversion d'IBM Db2 for z/OS vers Amazon RDS for PostgreSQL
**Note**
La console AWS de gestion ne prend pas en charge la création de projets de migration dans DMS Schema Conversion qui utilisent IBM Db2 z/OS comme fournisseur de données source et Amazon RDS for PostgreSQL comme fournisseur de données cible. Utilisez plutôt l'API de conversion de schéma AWS CLI ou DMS.
Les paramètres de conversion d'IBM Db2 pour z/OS vers Amazon RDS for PostgreSQL dans DMS Schema Conversion sont les suivants :
+ **Commentaires dans le code SQL converti** : ce paramètre inclut des commentaires dans le code converti pour les actions dont le niveau de gravité est sélectionné ou supérieur. Ce paramètre prend en charge les valeurs suivantes :
+ Erreurs uniquement
+ Erreurs et avertissements
+ Tous les messages
# Comprendre les paramètres de conversion de SAP ASE (Sybase ASE) vers PostgreSQL
Les paramètres de conversion de SAP ASE (Sybase ASE) vers PostgreSQL dans DMS Schema Conversion sont les suivants :
+ Pour convertir les objets de base de données applicables à l'aide de l'IA **générative, activez le paramètre IA générative**. Les objets convertis avec succès à l'aide de l'IA générative seront clairement identifiés grâce à **l'action 3077**, qui stipule : « Cette conversion utilise des modèles d'apprentissage automatique qui génèrent des prédictions basées sur des modèles de données ». Pour de plus amples informations, veuillez consulter [Conversion d'objets de base de données avec l'IA générative](schema-conversion-convert.databaseobjects.md).
+ **Commentaires dans le code SQL converti :** ce paramètre inclut des commentaires dans le code converti pour les actions dont le niveau de gravité est sélectionné ou supérieur. Ce paramètre prend en charge les valeurs suivantes :
+ Erreurs uniquement
+ Erreurs et avertissements
+ Tous les messages
+ Vous pouvez définir le modèle à utiliser pour les noms de schéma dans le code converti. Pour **Noms de schémas**, choisissez l’une des options suivantes :
+ **DB** — Utilise le nom de base de données SAP ASE (Sybase ASE) comme nom de schéma dans PostgreSQL.
+ **SCHÉMA** — Utilise le nom du schéma SAP ASE (Sybase ASE) comme nom de schéma dans PostgreSQL.
+ **DB\$1SCHEMA** — Utilise une combinaison de la base de données SAP ASE (Sybase ASE) et des noms de schéma comme nom de schéma dans.
+ Vous pouvez conserver la majuscule exacte des noms d'objets dans votre base de données source. Pour ce faire, sélectionnez Traiter les noms des objets de base de données source en distinguant les majuscules et minuscules. Lorsque cette option est désactivée, tous les noms d'objets de base de données sont convertis en minuscules.
+ Vous pouvez éviter de convertir les opérandes en minuscules lors d'opérations qui ne font pas la distinction entre majuscules et minuscules. La conversion du schéma DMS n'appliquera pas la fonction LOWER aux opérandes du code converti. Pour ce faire, sélectionnez **Éviter de convertir les opérandes en minuscules pour les opérations qui ne font pas la distinction entre majuscules et minuscules**. Lorsque cette option n'est pas sélectionnée (par défaut), DMS Schema Conversion applique automatiquement la fonction LOWER pour convertir les opérandes en minuscules avant d'effectuer des comparaisons sans distinction majuscules/majuscules.
+ Dans SAP ASE (Sybase ASE), vous pouvez créer des index portant des noms identiques dans différentes tables. PostgreSQL exige que tous les noms d'index d'un schéma soient uniques. Pour garantir que la conversion de AWS schéma crée des noms d'index uniques lors de la migration, sélectionnez **Générer des noms uniques pour les index.** Cette option ajoute automatiquement des préfixes aux noms d'index afin d'éviter les conflits de noms dans votre base de données PostgreSQL cible.