Migration de SQL Server vers PostgreSQL avec AWS Schema Conversion Tool - AWS Schema Conversion Tool
Privilèges pour PostgreSQL en tant que cibleParamètres de conversion SQL Server vers PostgreSQLPartitions SQL Server vers PostgreSQLConsidérations concernant la migration

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.

Migration de SQL Server vers PostgreSQL avec AWS Schema Conversion Tool

Vous pouvez utiliser le pack d'extension SQL Server vers PostgreSQL dans. AWS SCT Ce pack d'extension émule les fonctions de base de données SQL Server dans le code PostgreSQL converti. Utilisez le pack d'extension SQL Server vers PostgreSQL pour émuler SQL Server Agent et SQL Server Database Mail. Pour plus d’informations sur les packs d’extension, consultez Utilisation de packs d'extension avec AWS Schema Conversion Tool.

Rubriques

Privilèges pour PostgreSQL en tant que base de données 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_name par le nom de votre utilisateur. Remplacez ensuite db_name par le nom de votre base de données cible. Enfin, remplacez-le your_password 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.

Paramètres de conversion SQL Server vers PostgreSQL

Pour modifier les paramètres de conversion de SQL Server vers PostgreSQL, choisissez Paramètres, puis Paramètres de conversion. Dans la liste supérieure, choisissez SQL Server, puis SQL Server — PostgreSQL. AWS SCT affiche tous les paramètres disponibles pour la conversion de SQL Server vers PostgreSQL.

Les paramètres de conversion de SQL Server vers PostgreSQL incluent des options pour AWS SCT les éléments suivants :

  • Pour limiter le nombre de commentaires contenant des actions dans le code converti.

    Pour Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la gravité est sélectionnée ou 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.

  • Permettre d'utiliser des index portant le même nom dans différentes tables de SQL Server.

    Dans PostgreSQL, tous les noms d'index que vous utilisez dans le schéma doivent être uniques. Pour vous assurer que cela AWS SCT génère des noms uniques pour tous vos index, sélectionnez Générer des noms uniques pour les index.

  • Pour convertir les procédures SQL Server en fonctions PostgreSQL.

    Les versions 10 et antérieures de PostgreSQL ne prennent pas en charge les procédures. Les clients qui ne sont pas habitués à utiliser les procédures dans PostgreSQL peuvent les convertir AWS SCT en fonctions. Pour ce faire, sélectionnez Convertir les procédures en fonctions.

  • Pour émuler la sortie de EXEC dans un tableau.

    Votre base de données SQL Server source peut stocker le résultat de EXEC dans une table. AWS SCT 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 ensembles de données ouverts.

  • Pour définir le modèle à utiliser pour les noms de schéma dans le code converti. Pour le modèle de génération de nom de schéma, choisissez l'une des options suivantes :

    • <source_db>— Utilise le nom de base de données SQL Server comme nom de schéma dans PostgreSQL.

    • <source_schema>— Utilise le nom du schéma SQL Server comme nom de schéma dans PostgreSQL.

    • _ <source_db><schema>— Utilise une combinaison de noms de schéma et de base de données SQL Server comme nom de schéma dans PostgreSQL.

  • Pour conserver les noms de vos objets source en majuscules.

    Pour éviter de convertir les noms d'objets en minuscules, sélectionnez Éviter de convertir les noms en minuscules pour les opérations faisant la distinction entre majuscules et minuscules. Cette option s'applique uniquement lorsque vous activez la distinction majuscules/minuscules dans votre base de données cible.

  • Pour conserver les noms des paramètres dans votre base de données source.

    Pour ajouter des guillemets doubles aux noms des paramètres dans le code converti, sélectionnez Conserver les noms des paramètres d'origine.

Conversion de partitions SQL Server en partitions PostgreSQL version 10

Lorsque vous convertissez une base de données Microsoft SQL Server vers Amazon Aurora PostgreSQL Compatible Edition (Aurora PostgreSQL) ou Amazon Relational Database Service for PostgreSQL (Amazon RDS for PostgreSQL), tenez compte des points suivants.

Dans SQL Server, vous créez des partitions avec des fonctions de partition. Lorsque vous convertissez une table SQL Server divisée en portions en une table PostgreSQL version 10 divisée en portions, vous devez être conscient de plusieurs problèmes potentiels :

  • SQL Server vous permet de partitionner une table à l'aide d'une colonne sans contrainte NOT NULL. Dans ce cas, toutes les valeurs NULL sont dirigées vers la partition la plus à gauche. PostgreSQL ne prend pas en charge les valeurs NULL pour le partitionnement RANGE.

  • SQL Server vous permet de créer des clés primaires et uniques pour les tables partitionnées. Pour PostgreSQL, vous créez des clés primaires ou uniques pour chaque partition directement. Par conséquent, la contrainte PRIMARY ou UNIQUE KEY doit être supprimée de la table parent lors de la migration vers PostgreSQL. Les noms de clé qui en résultent prennent le format<original_key_name>_<partition_number>.

  • SQL Server vous permet de créer une contrainte de clé étrangère à partir de et vers des tables partitionnées. PostgreSQL ne prend pas en charge les clés étrangères qui référencent des tables partitionnées. De plus, PostgreSQL ne prend pas en charge les références de clé étrangère à partir d'une table partitionnée vers une autre table.

  • SQL Server vous permet de créer des index pour les tables partitionnées. Pour PostgreSQL, un index doit être créé pour chaque partition directement. Par conséquent, les index doivent être supprimés des tables parents lors de la migration vers PostgreSQL. Les noms d'index qui en résultent sont au format <original_index_name>_<partition_number>.

  • PostgreSQL ne prend pas en charge les index partitionnés.

Considérations concernant la migration

Voici quelques points à prendre en compte lors de la migration d'un schéma SQL Server vers PostgreSQL :

  • Dans PostgreSQL, tous les noms des objets dans un schéma doivent être uniques, y compris les index. Les noms d'index doivent être uniques dans le schéma de la table de base. Dans SQL Server, un nom d'index peut être identique pour différentes tables.

    Pour garantir l'unicité des noms d'index, vous AWS SCT donne la possibilité de générer des noms d'index uniques si vos noms d'index ne sont pas uniques. Pour cela, choisissez l'option Generate unique index names (Générer des noms d'index uniques) dans les propriétés du projet. Cette option est activée par défaut. Si cette option est activée, les noms d'index uniques sont créés au format IX_table_name_index_name. Si cette option est désactivée, les noms d'index ne sont pas modifiés.

  • Une instruction GOTO et une étiquette peuvent être utilisées pour modifier l'ordre dans lequel les instructions sont exécutées. Toutes les instructions Transact-SQL qui suivent une instruction GOTO sont ignorées et le traitement continue au niveau de l'étiquette. Les instructions GOTO et les étiquettes peuvent être utilisées à n'importe quel endroit dans une procédure, un lot ou un bloc d'instructions. Les instructions GOTO peuvent également être imbriquées.

    PostgreSQL n'utilise pas les instructions GOTO. Lors de la AWS SCT conversion du code contenant une instruction GOTO, il convertit l'instruction pour utiliser une instruction BEGIN... END ou LOOP... END LOOP. Vous trouverez des exemples de AWS SCT conversion des instructions GOTO dans le tableau suivant.

    Instructions GOTO SQL Server et instructions PostgreSQL converties
    Instruction SQL Server Instruction PostgreSQL 
    BEGIN
   ....
   statement1;
   ....
   GOTO label1;
   statement2;
   ....
   label1:
   Statement3;
   ....
END
    		 
    BEGIN
 label1:
 BEGIN
   ....
   statement1;
   ....
   EXIT label1;
   statement2;
   ....
 END;
   Statement3;
   ....
END
    		 
    BEGIN
   ....
   statement1;
   ....
   label1:
   statement2;
   ....
   GOTO label1;
   statement3;
   ....
   statement4;
   ....
END
    		 
    BEGIN
   ....
   statement1;
   ....
   label1:
   LOOP
    statement2;
    ....
    CONTINUE label1;
    EXIT label1;
   END LOOP; 
    statement3;
    ....
    statement4;
    ....
END
    		 
    BEGIN
   ....
   statement1;
   ....
   label1:
   statement2;
   ....
   statement3;
   ....
   statement4;
   ....
END
    		 
    BEGIN
   ....
   statement1;
   ....
   label1:
   BEGIN
    statement2;
    ....    
    statement3;
    ....
    statement4;
    ....    
   END; 
END

  • PostgreSQL ne prend pas en charge les instructions MERGE. AWS SCT émule le comportement d'une instruction MERGE de la manière suivante :

    • Par une construction INSERT ON CONFLICT.

    • En utilisant l'instruction UPDATE FROM DML, par exemple MERGE sans clause WHEN NOT MATCHED.

    • En utilisant une instruction CURSOR, par exemple avec une clause MERGE avec DELETE ou à l'aide d'une instruction de condition MERGE ON complexe.

  • AWS SCT peut ajouter des déclencheurs de base de données à l'arborescence d'objets lorsque Amazon RDS est la cible.

  • AWS SCT peut ajouter des déclencheurs au niveau du serveur à l'arborescence des objets lorsque Amazon RDS est la cible.

  • SQL Server crée et gère automatiquement deleted des inserted tables. Vous pouvez utiliser ces tables temporaires résidant en mémoire pour tester les effets de certaines modifications de données et pour définir les conditions des actions de déclenchement DML. AWS SCT peut convertir l'utilisation de ces tables dans des instructions de déclenchement DML.

  • AWS SCT peut ajouter des serveurs liés à l'arborescence des objets lorsque Amazon RDS est la cible.

  • Lors de la migration de Microsoft SQL Server vers PostgreSQL, la fonction SUSER_SNAME intégrée est convertie comme suit :

    • SUSER_SNAME – Renvoie le nom de connexion associé à un numéro d'identification de sécurité (SID).

    • SUSER_SNAME(<server_user_sid>) – Non pris en charge.

    • SUSER_SNAME () CURRENT_USER – Renvoie le nom d'utilisateur du contexte d'exécution actuel.

    • SUSER_SNAME (NULL) - Renvoie NULL.

  • La conversion de fonctions avec valeurs de table est prise en charge. Les fonctions avec valeurs de table renvoient une table et peuvent remplacer une table dans une requête.

  • PATINDEX renvoie la position de départ de la première occurrence d'un modèle dans une expression spécifiée sur tous les types de données texte et caractère. Il renvoie des zéros si le modèle n'est pas trouvé. <pattern character><expression character varying>Lors de la conversion de SQL Server vers Amazon RDS for AWS SCT PostgreSQL, le code d'application qui utilise PATINDEX est remplacé par aws_sqlserver_ext.patindex (,).

  • Dans SQL Server, un type de table défini par l'utilisateur est un type qui représente la définition d'une structure de table. Vous utilisez un type de table défini par l'utilisateur afin de déclarer les paramètres de valeur de table pour les procédures ou fonctions stockées. Vous pouvez également utiliser un type de table défini par l'utilisateur pour déclarer les variables de table que vous souhaitez utiliser dans un lot ou dans le corps d'une procédure stockée ou d'une fonction. AWS SCT a émulé ce type dans PostgreSQL en créant une table temporaire.

Lors de la conversion de SQL Server vers PostgreSQL AWS SCT , les objets système SQL Server sont convertis en objets reconnaissables dans PostgreSQL. Le tableau suivant montre la façon dont les objets système sont convertis.

Cas d'utilisation de MS SQL Server Substitution par PostgreSQL

SYS.SCHEMAS

AWS_SQLSERVER_EXT.SYS_SCHEMAS

SYS.TABLES

AWS_SQLSERVER_EXT.SYS_TABLES

SYS.VIEWS

AWS_SQLSERVER_EXT.SYS_VIEWS

SYS.ALL_VIEWS

AWS_SQLSERVER_EXT.SYS_ALL_VIEWS

SYS.TYPES

AWS_SQLSERVER_EXT.SYS_TYPES

SYS.COLUMNS

AWS_SQLSERVER_EXT.SYS_COLUMNS

SYS.ALL_COLUMNS

AWS_SQLSERVER_EXT.SYS_ALL_COLUMNS

SYS.FOREIGN_KEYS

AWS_SQLSERVER_EXT.SYS_FOREIGN_KEYS

SYS.SYSFOREIGNKEYS

AWS_SQLSERVERCLÉS ÉTRANGÈRES _EXT.SYS_SYS

SYS.FOREIGN_KEY_COLUMNS

AWS_SQLSERVER_EXT.SYS_FOREIGN_KEY_COLUMNS

SYS.KEY_CONSTRAINTS

AWS_SQLSERVER_EXT.SYS_KEY_CONSTRAINTS

SYS.IDENTITY_COLUMNS

AWS_SQLSERVER_EXT.SYS_IDENTITY_COLUMNS

SYS.PROCEDURES

AWS_SQLSERVER_EXT.SYS_PROCEDURES

SYS.INDEXES

AWS_SQLSERVER_EXT.SYS_INDEX

SYS.SYSINDEXES

AWS_SQLSERVER_EXT.SYS_SYSINDEXES

SYS.OBJECTS

AWS_SQLSERVER_EXT.SYS_OBJECTS

SYS.ALL_OBJECTS

AWS_SQLSERVER_EXT.SYS_ALL_OBJECTS

SYS.SYSOBJECTS

AWS_SQLSERVEROBJETS _EXT.SYS_SYS

SYS.SQL_MODULES

AWS_SQLSERVERMODULES _EXT.SYS_SQL

SYS.DATABASES

AWS_SQLSERVERBASES DE DONNÉES _EXT.SYS_

INFORMATION_SCHEMA.SCHEMATA

AWS_SQLSERVER_EXT.INFORMATION_SCHÉMA_SCHÉMAS

INFORMATION_SCHEMA.VIEWS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_VIEWS

INFORMATION_SCHEMA.TABLES

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_TABLES

INFORMATION_SCHEMA.COLUMNS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_COLUMNS

INFORMATION_SCHEMA.CHECK_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CHECK_CONSTRAINTS

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_REFERENTIAL_CONTRAINTES

INFORMATION_SCHEMA.TABLE_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_TABLE_CONSTRAINTS

INFORMATION_SCHEMA.KEY_COLUMN_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_KEY_COLUMN_USAGE

INFORMATION_SCHEMA.CONSTRAINT_TABLE_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CONSTRAINT_TABLE_USAGE

INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CONSTRAINT_COLUMN_USAGE

INFORMATION_SCHEMA.ROUTINES

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_ROUTINES

SYS.SYSPROCESSES

AWS_SQLSERVER_EXT.SYS_SYSPROCESSES

sys.system_objects

AWS_SQLSERVER_EXT.SYS_SYSTEM_OBJECTS