Le meilleur outil pour migrer une base de données PostgreSQL vers MS SQL 2005?

J'ai une base de données dans PostgreSQL 8.3.1 que j'aimerais migrer vers MS SQL Server 2005 (ou peut-être 2008), y compris le schéma de la table et les données. La base de données a une taille d'environ 50 Go avec environ 400 000 000 lignes, donc je pense que les simples instructions INSERT sont hors de question. Quelqu'un pourrait-il recommander le meilleur outil pour effectuer cette migration? Évidemment, il doit être fiable, donc les données sont exactement les mêmes dans la base de données cible que dans la source et il doit être en mesure de copier ce volume de données dans un délai raisonnable.

J'ai fini par n'utiliser aucun outil tiers pour les données car aucun de ceux que j'ai essayés ne fonctionnait pour les grandes tables. Même SSIS a échoué. J'ai cependant utilisé un outil commercial pour le schéma. Mon processus de conversion était donc le suivant:

1. Full Convert Enterprise pour copier le schéma (pas de données).
2. pg_dump pour exporter les données de Postgres au format "texte brut", qui est essentiellement un fichier de valeurs séparées par des tabulations (TSV).
3. Les scripts Python pour transformer les fichiers exportés dans un format bcp comprendraient.
4. bcp pour importer les données dans MSSQL.

L'étape de transformation a pris en charge certaines différences dans les formats utilisés par pg_dump et bcp, telles que:

• pg_dump place des éléments spécifiques à Postgres au début du fichier et termine les données par ".", tandis que bcp s'attend à ce que le fichier entier contienne des données
• pg_dump stocke les valeurs NULL sous la forme "\ N", tandis que bcp n'attend rien à la place d'un NULL (c'est-à-dire aucune donnée entre les séparateurs de colonnes)
• pg_dump code les onglets en "\ t" et les sauts de ligne en "\ n", tandis que bcp les traite littéralement
• pg_dump utilise toujours des tabulations et des sauts de ligne comme séparateurs, tandis que bcp permet à l'utilisateur de spécifier des séparateurs. Cela devient nécessaire si les données contiennent des onglets ou des nouvelles lignes, car ils ne sont pas codés.

J'ai également constaté que certaines contraintes uniques qui étaient bien dans Postgres ont été violées dans MSSQL, j'ai donc dû les supprimer. En effet, NULL = NULL dans MSSQL (c'est-à-dire que NULL est traité comme une valeur unique), mais pas dans Postgres.

Si vous disposez des pilotes de prise en charge Postgres appropriés installés sur votre boîte SQL 2005 (ou si vous souhaitez utiliser Postgres via ODBC, ou si vous souhaitez vider les données de Postgres dans un fichier et les importer à partir de cela), vous pouvez utiliser l'assistant d'importation / exportation dans SQL Server dans afin de copier les données. Cela vous posera diverses questions, puis exécutera l'importation en tant que tâche de package SQL Server Integration Services (SSIS), à l'aide d'opérations d'insertion par lots appropriées.

Cependant, si cet assistant n'est pas une option, il convient de considérer que bien que vous ayez un grand nombre de lignes, la taille individuelle des lignes est <135 octets en moyenne, et compte tenu d'un espace de journal des transactions suffisant pour permettre à une transaction de 50 Go de se produire '' les simples déclarations d'insertion ne sont pas exclues.

http://www.easyfrom.net/

Et voilà :) Malheureusement, c'est un peu cher.

Près de 10 ans plus tard, et ce n'est toujours pas un problème simple. Je me suis retrouvé avec une solution hybride, j'ai roulé mon propre mappeur de schéma en exportant le schéma et les commentaires de table / colonne à l'aide de la commande suivante:

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

J'ai ensuite écrit un script PHP qui a traduit le schéma en T-SQL. J'ai ensuite utilisé le logiciel tiers suivant pour effectuer l'importation réelle des lignes (sans affiliation):

http://www.convert-in.com/pgs2mss.htm

C'était un peu lent, mais jusqu'ici tout va bien. Notre base de données était plus petite que la vôtre, seulement 15 Go, mais cet outil semblait bien le gérer. C'était aussi le moins cher que j'ai pu trouver à environ 50 $. Jusqu'à présent, cela a été un investissement rentable.