web-dev-qa-db-fra.com

Comment migrer une base de données PostgreSQL vers une base SQLServer?

J'ai une base de données PostgreSQL que je souhaite déplacer vers SQL Server - à la fois le schéma et les données. Je suis pauvre donc je ne veux pas payer d’argent. Je suis aussi paresseux, donc je ne veux pas faire beaucoup de travail. Actuellement, je fais ce tableau par tableau, et il y a environ 100 tableaux à faire. C'est extrêmement fastidieux.

Y a-t-il une sorte d'astuce qui fait ce que je veux?

47
Hut8

Vous devriez pouvoir trouver des informations utiles dans la réponse acceptée sur cette page Serverfault: https://serverfault.com/questions/65407/best-tool-to-migrate-a-postgresql-database-to- ms-sql-2005 .

Si vous pouvez obtenir le schéma converti sans les données, vous pourrez peut-être raccourcir les étapes pour les données en utilisant cette commande:

pg_dump --data-only --column-inserts your_db_name > data_load_script.sql

Ce chargement sera assez lent, mais l'option --column-inserts Génère les instructions INSERT les plus génériques possibles pour chaque ligne de données et doit être compatible.

EDIT: suggestions sur la conversion du schéma suit:

Je commencerais par vider le schéma, mais en supprimant tout ce qui a à voir avec la propriété ou les autorisations. Cela devrait suffire:

pg_dump --schema-only --no-owner --no-privileges your_db_name > schema_create_script.sql

Modifiez ce fichier pour ajouter la ligne BEGIN TRANSACTION; Au début et ROLLBACK TRANSACTION; À la fin. Vous pouvez maintenant le charger et l'exécuter dans une fenêtre de requête dans SQL Server. Si vous obtenez des erreurs, assurez-vous d'aller au bas du fichier, mettez en surbrillance l'instruction ROLLBACK et exécutez-la (en appuyant sur F5 pendant que l'instruction est mise en surbrillance).

Fondamentalement, vous devez résoudre chaque erreur jusqu'à ce que le script s'exécute correctement. Ensuite, vous pouvez changer le ROLLBACK TRANSACTION En COMMIT TRANSACTION Et exécuter une dernière fois.

Malheureusement, je ne peux pas vous aider avec les erreurs que vous pouvez voir car je ne suis jamais passé de PostgreSQL à SQL Server, mais l'inverse. Certaines choses que je m'attendrais à être un problème, cependant (évidemment, PAS une liste exhaustive):

  • PostgreSQL effectue automatiquement l'incrémentation des champs en liant un champ NOT NULL INTEGER À un SEQUENCE à l'aide d'un DEFAULT. Dans SQL Server, il s'agit d'une colonne IDENTITY, mais ce n'est pas exactement la même chose. Je ne sais pas s'ils sont équivalents, mais si votre schéma d'origine est plein de champs "id", vous pourriez avoir des ennuis. Je ne sais pas si SQL Server a CREATE SEQUENCE, Vous devrez donc peut-être les supprimer.
  • Les fonctions de base de données/procédures stockées ne se traduisent pas entre les plates-formes RDBMS. Vous devrez supprimer toutes les instructions CREATE FUNCTION Et traduire les algorithmes manuellement.
  • Faites attention au codage du fichier de données. Je suis une personne Linux, donc je ne sais pas comment vérifier l'encodage dans Windows, mais vous devez vous assurer que ce que SQL Server attend est le même que le fichier que vous importez de PostgreSQL. pg_dump A une option --encoding= Qui vous permettra de définir un encodage spécifique. Il me semble que Windows a tendance à utiliser un codage UTF-16 à deux octets pour Unicode, où PostgreSQL utilise UTF-8. J'ai eu des problèmes pour passer de SQL Server à PostgreSQL en raison de la sortie UTF-16, donc cela vaut la peine de faire des recherches.
  • Le type de données PostgreSQL TEXT est simplement un VARCHAR sans longueur maximale. Dans SQL Server, TEXT est ... compliqué (et obsolète). Chaque champ de votre schéma d'origine déclaré comme TEXT devra être examiné pour un type de données SQL Server approprié.
  • SQL Server a des types de données supplémentaires pour les données UNICODE. Je ne le connais pas assez pour faire des suggestions. Je souligne simplement que cela peut être un problème.
50
Matthew Wood

J'ai trouvé un moyen plus rapide et plus simple d'accomplir cela.

Copiez d'abord votre table (ou requête) dans un fichier délimité par des tabulations comme ceci:

COPY (SELECT siteid, searchdist, listtype, list, sitename, county, street, 
   city, state, Zip, georesult, elevation, lat, lng, wkt, unlocated_bool, 
   id, status, standard_status, date_opened_or_reported, date_closed, 
   notes, list_type_description FROM mlocal) TO 'c:\SQLAzureImportFiles\data_script_mlocal.tsv' NULL E''

Ensuite, vous devez créer votre table en SQL, cela ne gérera aucun schéma pour vous. Le schéma doit correspondre à votre fichier tsv exporté dans l'ordre des champs et les types de données.

Enfin, vous exécutez l'utilitaire bcp de SQL pour introduire le fichier tsv comme ceci:

bcp MyDb.dbo.mlocal in "\\NEWDBSERVER\SQLAzureImportFiles\data_script_mlocal.tsv" -S tcp:YourDBServer.database.windows.net -U YourUserName -P YourPassword -c

Quelques choses importantes que j'ai rencontrées. Postgres et SQL Server gèrent différemment les champs booléens. Votre schéma SQL Server doit avoir vos champs booléens définis sur varchar (1) et les données résultantes seront 'f', 't' ou null. Vous devrez ensuite convertir ce champ en un peu. faire quelque chose comme:

ALTER TABLE mlocal ADD unlocated bit;
UPDATE mlocal SET unlocated=1 WHERE unlocated_bool='t';
UPDATE mlocal SET unlocated=0 WHERE unlocated_bool='f';
ALTER TABLE mlocal DROP COLUMN unlocated_bool;

Une autre chose est que les champs de géographie/géométrie sont très différents entre les deux plates-formes. Exportez les champs de géométrie au format WKT à l'aide de ST_AsText(geo) et convertissez-les de manière appropriée du côté de SQL Server.

Il peut y avoir plus d'incompatibilités nécessitant des ajustements comme celui-ci.

MODIFIER. Donc, alors que cette technique fonctionne techniquement, j'essaie de transférer plusieurs millions d'enregistrements de plus de 100 tables vers SQL Azure et bcp vers SQL Azure est assez flou, il s'avère. Je continue à devenir intermittent Impossible d'ouvrir le fichier de données de l'hôte BCP erreurs, le serveur arrive à expiration par intermittence et pour une raison quelconque, certains enregistrements ne sont pas transférés sans indication d'erreurs ou de problèmes. Cette technique n'est donc pas stable pour transférer de grandes quantités de données vers Azure SQL.

1
Brad Mathews