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. # ConnConnecting aux bases de données IBM DB2 pour Linux, UNIX et Windows avec AWS Schema Conversion Tool Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code dans le langage SQL et du code d'application d'IBM Db2 pour Linux, Unix et Windows (Db2 LUW) vers les cibles suivantes. + Amazon RDS for MySQL + Amazon Aurora MySQL-Compatible Edition + Amazon RDS pour PostgreSQL + Amazon Aurora PostgreSQL-Compatible Edition + Amazon RDS for MariaDB AWS SCT prend en charge comme source les versions 9.1, 9.5, 9.7, 10.1, 10.5, 11.1 et 11.5 de Db2 LUW. ## Privilèges pour DB2 LUW en tant que source Les privilèges nécessaires pour se connecter à une base de données DB2 LUW, vérifier les privilèges disponibles et lire les métadonnées du schéma d'une source sont les suivants : + Privilège requis pour établir une connexion : + CONNEXION À LA BASE DE DONNÉES + Privilège requis pour exécuter les instructions SQL : + EXÉCUTER SUR LE PACKAGE NULLID. SYSSH200 + Privilèges requis pour obtenir les informations au niveau de l'instance : + EXÉCUTER SUR LA FONCTION SYSPROC.ENV\$1GET\$1INST\$1INFO + SÉLECTIONNEZ SUR SYSIBMADM.ENV\$1INST\$1INFO + SÉLECTIONNEZ SUR SYSIBMADM.ENV\$1SYS\$1INFO + Privilèges requis pour vérifier les privilèges accordés par le biais de rôles, de groupes et d'autorités : + EXÉCUTER SUR LA FONCTION SYSPROC.AUTH\$1LIST\$1AUTHORTIES\$1FOR\$1AUTHID + EXÉCUTER SUR LA FONCTION SYSPROC.AUTH\$1LIST\$1GROUPS\$1FOR\$1AUTHID + EXÉCUTER SUR LA FONCTION SYSPROC.AUTH\$1LIST\$1ROLES\$1FOR\$1AUTHID + SÉLECTIONNEZ SUR SYSIBMADM.PRIVILEGES + Privilèges requis sur les catalogues et tables système : + SÉLECTIONNEZ SUR SYSCAT.ATTRIBUTES + SÉLECTIONNEZ SUR SYSCAT.CHECKS + SÉLECTIONNEZ SUR SYSCAT.COLIDENTATTRIBUTES + SÉLECTIONNEZ SUR SYSCAT.COLUMNS + SÉLECTIONNEZ SUR SYSCAT.DATAPARTITIONEXPRESSION + SÉLECTIONNEZ SUR SYSCAT.DATAPARTITIONS + SÉLECTIONNEZ SUR SYSCAT.DATATYPEDEP + SÉLECTIONNEZ SUR SYSCAT.DATATYPES + SÉLECTIONNEZ SUR SYSCAT.HIERARCHIES + SÉLECTIONNEZ SUR SYSCAT.INDEXCOLUSE + SÉLECTIONNEZ SUR SYSCAT.INDEXES + SÉLECTIONNEZ SUR SYSCAT.INDEXPARTITIONS + SÉLECTIONNEZ SUR SYSCAT.KEYCOLUSE + SÉLECTIONNER SUR SYSCAT.MODULEOBJECTS + SÉLECTIONNEZ SUR SYSCAT.MODULES + SÉLECTIONNEZ SUR SYSCAT.NICKNAMES + SÉLECTIONNEZ SUR SYSCAT.PERIODS + SÉLECTIONNEZ SUR SYSCAT.REFERENCES + SÉLECTIONNEZ SUR SYSCAT.ROUTINEPARMS + SÉLECTIONNEZ SUR SYSCAT.ROUTINES + SÉLECTIONNEZ SUR SYSCAT.ROWFIELDS + SÉLECTIONNEZ SUR SYSCAT.SCHEMATA + SÉLECTIONNEZ SUR SYSCAT.SEQUENCES + SÉLECTIONNEZ SUR SYSCAT.TABCONST + SÉLECTIONNEZ SUR SYSCAT.TABLES + SÉLECTIONNEZ SUR SYSCAT.TRIGGERS + SÉLECTIONNEZ SUR SYSCAT.VARIABLEDEP + SÉLECTIONNEZ SUR SYSCAT.VARIABLES + SÉLECTIONNEZ SUR SYSCAT.VIEWS + SÉLECTIONNEZ SUR SYSIBM. SYSDUMMY1 + Pour exécuter des instructions SQL, le compte utilisateur a besoin d'un privilège pour utiliser au moins l'une des charges de travail activées dans la base de données. Si aucune des charges de travail n'est affectée à l'utilisateur, vérifiez que la charge de travail utilisateur par défaut est accessible par l'utilisateur : + UTILISATION SUR LA CHARGE DE TRAVAIL SYSDEFAULTUSERWORKLOAD Pour exécuter des requêtes, vous devez créer des espaces de table temporaires pour le système avec une taille de page de 8 k, 16 k et 32 k, si elles n'existent pas déjà. Pour créer les espaces de table temporaires, exécutez les scripts suivants. ``` CREATE BUFFERPOOL BP8K IMMEDIATE ALL DBPARTITIONNUMS SIZE AUTOMATIC NUMBLOCKPAGES 0 PAGESIZE 8K; CREATE SYSTEM TEMPORARY TABLESPACE TS_SYS_TEMP_8K PAGESIZE 8192 BUFFERPOOL BP8K; CREATE BUFFERPOOL BP16K IMMEDIATE ALL DBPARTITIONNUMS SIZE AUTOMATIC NUMBLOCKPAGES 0 PAGESIZE 16K; CREATE SYSTEM TEMPORARY TABLESPACE TS_SYS_TEMP_BP16K PAGESIZE 16384 BUFFERPOOL BP16K; CREATE BUFFERPOOL BP32K IMMEDIATE ALL DBPARTITIONNUMS SIZE AUTOMATIC NUMBLOCKPAGES 0 PAGESIZE 32K; CREATE SYSTEM TEMPORARY TABLESPACE TS_SYS_TEMP_BP32K PAGESIZE 32768 BUFFERPOOL BP32K; ``` ## Connexion à DB2 LUW en tant que source Utilisez la procédure suivante pour vous connecter à votre base de données source Db2 LUW avec AWS Schema Conversion Tool. **Pour vous connecter à une base de données source Db2 LUW** 1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**. 1. **Choisissez **Db2 LUW**, puis Next.** La boîte de dialogue **Ajouter une source** apparaît. 1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche. 1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement : + Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes : 1. Pour **AWS Secret**, choisissez le nom du secret. 1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager. Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md). + Pour saisir manuellement les informations de connexion à la base de données source IBM Db2 LUW, suivez les instructions suivantes : **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.DB2LUW.html) 1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source. 1. Choisissez **Connect pour vous** connecter à votre base de données source. # Migration d'IBM DB2 pour Linux, UNIX et Windows vers Amazon Relational Database Service pour PostgreSQL ou Amazon Aurora PostgreSQL compatible Edition Lorsque vous migrez IBM Db2 LUW vers PostgreSQL, vous AWS SCT pouvez convertir diverses instructions de déclenchement utilisées avec Db2 LUW. Il s'agit notamment des instructions de déclenchement suivantes : + **Événements déclencheurs** : les événements déclencheurs INSERT, DELETE et UPDATE spécifient que l'action déclenchée s'exécute chaque fois que l'événement est appliqué à la table ou à la vue du sujet. Vous pouvez définir n'importe quelle combinaison des événements INSERT, DELETE et UPDATE, mais vous ne pouvez spécifier chaque événement qu'une seule fois. AWS SCT prend en charge les événements déclencheurs uniques et multiples. Concernant les événements, PostgreSQL possède quasiment les mêmes fonctionnalités. + **ÉVÉNEMENT DE COLONNE** — Vous pouvez spécifier un nom de colonne à partir d'une table de base. Le déclencheur est activé uniquement par la mise à jour d'une colonne qui est identifiée dans la colonne des noms de liste. PostgreSQL possède les mêmes fonctionnalités. + **Déclencheurs** d'instructions : ils spécifient que l'action déclenchée n'est appliquée qu'une seule fois pour l'ensemble de l'instruction. Vous ne pouvez pas spécifier ce type de granularité de déclencheur pour un déclencheur BEFORE ou un déclencheur INSTEAD OF. Si cette valeur est spécifiée, un déclencheur UPDATE ou DELETE est activé, même si aucune ligne n'est affectée. PostgreSQL possède également cette fonctionnalité et la déclaration de déclenchement pour les déclencheurs d'instruction est identique pour PostgreSQL et Db2 LUW. + **Clauses de référencement** : elles spécifient les noms de corrélation pour les variables de transition et les noms de table pour les tables de transition. Les noms de corrélation identifient une ligne spécifique dans l'ensemble des lignes affectées par l'opération SQL de déclenchement. Les noms de table identifient l'ensemble complet des lignes affectées. Chaque ligne affectée par une opération SQL de déclenchement est disponible pour l'action déclenchée en identifiant les colonnes avec les noms de corrélation spécifiés. PostgreSQL ne prend pas en charge cette fonctionnalité, et utilise uniquement un nom de corrélation NOUVEAU ou ANCIEN. + **AU LIEU DE DÉCLENCHEURS**, il AWS SCT les prend en charge. ## Conversion de tables partitionnées DB2 LUW en tables partitionnées PostgreSQL version 10 AWS SCT peut convertir des tables DB2 LUW en tables partitionnées dans PostgreSQL 10. Il existe plusieurs restrictions lors de la conversion d'une table partitionnée Db2 LUW en PostgreSQL : + Vous pouvez créer une table partitionnée avec une colonne acceptant la valeur null dans Db2 LUW, et vous pouvez spécifier une partition pour stocker les valeurs NULL. Cependant, PostgreSQL ne prend pas en charge les valeurs NULL pour le partitionnement RANGE. + Db2 LUW peut utiliser une clause INCLUSIVE ou EXCLUSIVE pour définir des valeurs de limite de plage. PostgreSQL prend uniquement en charge INCLUSIVE pour une limite de début et EXCLUSIVE pour une limite de fin. Le nom de partition converti est au format \$1. + Vous pouvez créer des clés primaires ou uniques pour les tables partitionnées dans Db2 LUW. Pour PostgreSQL, vous devez une clé primaire ou unique pour chaque partition directement. Les contraintes de clé primaire ou unique doivent être supprimées de la table parent. Le nom de clé converti est au format \$1. + Vous pouvez créer une contrainte de clé étrangère depuis et vers une table partitionnée dans Db2 LUW. Cependant, PostgreSQL ne prend pas en charge les références de clé étrangère dans les tables partitionnées. PostgreSQL ne prend pas non plus en charge les références de clé étrangère à partir d'une table partitionnée vers une autre table. + Vous pouvez créer un index sur une table partitionnée dans Db2 LUW. Cependant, pour PostgreSQL, vous devez un index pour chaque partition directement. Les index doivent être supprimés de la table parent. Le nom d'index converti est au format \$1. + Vous devez définir des déclencheurs de ligne sur les partitions individuelles, et non sur la table partitionnée. Les déclencheurs doivent être supprimés de la table parent. Le nom de déclencheur converti est au format \$1. ## Privilèges pour PostgreSQL en tant que cible Pour utiliser PostgreSQL comme cible AWS SCT , le privilège est requis. `CREATE ON DATABASE` Assurez-vous d'accorder ce privilège à chaque base de données PostgreSQL cible. Pour utiliser les synonymes publics convertis, remplacez le chemin de recherche par défaut de la base de données par`"$user", public_synonyms, public`. Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges. ``` CREATE ROLE user_name LOGIN PASSWORD 'your_password'; GRANT CREATE ON DATABASE db_name TO user_name; ALTER DATABASE db_name SET SEARCH_PATH = "$user", public_synonyms, public; ``` Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez ensuite *db\$1name* par le nom de votre base de données cible. Enfin, remplacez-le *your\$1password* par un mot de passe sécurisé. Dans PostgreSQL, seul le propriétaire du schéma ou un `superuser` peut supprimer un schéma. Le propriétaire peut supprimer un schéma et tous les objets qu'il inclut même si le propriétaire du schéma ne possède pas certains de ses objets. Lorsque vous utilisez différents utilisateurs pour convertir et appliquer différents schémas à votre base de données cible, un message d'erreur peut s'afficher lorsque vous ne AWS SCT pouvez pas supprimer un schéma. Pour éviter ce message d’erreur, utilisez le rôle `superuser`. # Migration d'IBM DB2 pour Linux, UNIX et Windows vers Amazon RDS for MySQL ou Amazon Aurora MySQL Lorsque vous convertissez une base de données IBM Db2 LUW en RDS for MySQL ou Amazon Aurora MySQL, tenez compte de ce qui suit. ## Privilèges pour MySQL en tant que cible Les privilèges requis pour MySQL en tant que cible sont les suivants : + CRÉER SUR\$1 . \$1 + MODIFIER \$1 . \$1 + DÉPOSEZ \$1 . \$1 + INDEX SUR \$1 . \$1 + RÉFÉRENCES SUR\$1 . \$1 + SELECT ON \$1.\$1 + CRÉER UNE VUE SUR \$1 . \$1 + SHOW VIEW ON \$1.\$1 + DÉCLENCHEUR ACTIVÉ\$1 . \$1 + CRÉER UNE ROUTINE SUR\$1 . \$1 + MODIFIER LA ROUTINE SUR \$1 . \$1 + EXÉCUTER SUR\$1 . \$1 + SELECT ON mysql.proc + INSÉRER, METTRE À JOUR SUR AWS\$1DB 2\$1EXT. \$1 + INSÉRER, METTRE À JOUR, SUPPRIMER SUR AWS\$1DB 2\$1EXT\$1DATA. \$1 + CRÉEZ DES TABLES TEMPORAIRES SUR AWS\$1DB 2\$1EXT\$1DATA. \$1 Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges. ``` CREATE USER 'user_name' IDENTIFIED BY 'your_password'; GRANT CREATE ON *.* TO 'user_name'; GRANT ALTER ON *.* TO 'user_name'; GRANT DROP ON *.* TO 'user_name'; GRANT INDEX ON *.* TO 'user_name'; GRANT REFERENCES ON *.* TO 'user_name'; GRANT SELECT ON *.* TO 'user_name'; GRANT CREATE VIEW ON *.* TO 'user_name'; GRANT SHOW VIEW ON *.* TO 'user_name'; GRANT TRIGGER ON *.* TO 'user_name'; GRANT CREATE ROUTINE ON *.* TO 'user_name'; GRANT ALTER ROUTINE ON *.* TO 'user_name'; GRANT EXECUTE ON *.* TO 'user_name'; GRANT SELECT ON mysql.proc TO 'user_name'; GRANT INSERT, UPDATE ON AWS_DB2_EXT.* TO 'user_name'; GRANT INSERT, UPDATE, DELETE ON AWS_DB2_EXT_DATA.* TO 'user_name'; GRANT CREATE TEMPORARY TABLES ON AWS_DB2_EXT_DATA.* TO 'user_name'; ``` Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé. Pour utiliser Amazon RDS for MySQL ou Aurora MySQL en tant que cible, définissez le paramètre `lower_case_table_names` sur `1`. Cette valeur signifie que le serveur MySQL traite les identifiants des noms d’objets tels que les tables, les index, les déclencheurs et les bases de données sans distinction entre majuscules et minuscules. Si vous avez activé la journalisation binaire dans votre instance cible, définissez le paramètre `log_bin_trust_function_creators` sur `1`. Dans ce cas, vous n’avez pas besoin d’utiliser les caractéristiques `DETERMINISTIC`, `READS SQL DATA` ni `NO SQL` pour créer des fonctions stockées. Pour configurer ces paramètres, créez un nouveau groupe de paramètres de base de données ou modifiez un groupe de paramètres de base de données existant.