Discussion :

[romain_kdp]

Bonjour,

Je souhaite migrer une base postgres dans SQL Server 2005.

En fait, je travaille sur un logiciel (clementine de SPSS) qui ne se connecte pas à postgres mais à SQL Server. Je dois donc opérer la migration, mais je ne suis pas très au fait des pb de migrations et notamment de SQL server.

J'ai navigué ds SQL Server, créer une base a été facile, par contre pour l'import de donnée c'est déjà moins "end user".

Je sollicite donc l'aide de tous les initiés à SQl Server 2005 sur le sproblématiques de migration de base de données.

Merci de votre aide

Romain

[rudib]

Bonjour,

Tu peux faire la migration en utilisant SSIS (Integration Services) (quelle Edition de SQL Server 2005 utilises-tu ?), qui se connectera à PostgreSQL via ses providers ODBC ou OLEDB. Ensuite, à l'intérieur de SSIS, c'est un peu complexe. Il devrait y avoir un assistant qq part... je ne l'ai pas sous la main sur le moment. Jette un oeil et regarde si tu t'en sors, sinon repose les questions.

[romain_kdp]

j'utilise la version standard de SQL Server 2005, elle comprend donc SSIS,l'ETL de SQL Server, mais c'est effectivement un peu complexe, le dts de SQL server 2000 était bien plus simple. Il comprenait notamment en natif les liens pour se connecter à une base Postgres.

Sous SQl 2005, ces drivers ne semblent pas apparent, tout du moins dans l'assistant d'import de donnée. J'ai juste une indication du type "microsoft ole db provider for odbc drivers". Ca veut dire quoi? Que la connexion avec Postgres se fera via des driver odbc, mais qu'ils ne sont pas présent dans SQl Server? Si c'est le cas il faut aller les chercher? La version 2005 n'a pas pu régresser par rapport à la version 2000 sur l'import de donnée?

[rudib]

Il y a des provider développés par l'équipe de pg, et j'ai entendu dire qu'ils étaient assez bons (?). Il y en a un ici : http://pgfoundry.org/projects/oledb/

Microsoft ne livre pas de driver PG autant que je sache.

Pour le reste, je jetterai un oeil sur SSIS chez moi si j'ai le temps. Je me demande s'il n'y a pas d'assistant qq part ? Tu n'as pas dans les menus de SSMS une entrée genre "import data" ?

[romain_kdp]

En cliquant droit sur une base donnée dans SQL Server 2005, on va sur le menu "tâche" puis sur le menu "import data". Pas de soucis jusque là! C'est plus au niveau de la connexion ensuite avec PG. Je vais essayer le lien que tu m'as transmis.Merci d'ailleurs!
J'ai cependant un doute , ce mode opératoire me permettra t il de migrer toute la base de donnée (350 tables!!!)?
Comment fait on de manière générale pour migrer une base de donnée dans SQl Server? Je pensais naivement qu'un ETL fournissait une interface graphique qui simplifiait tt!

[romain_kdp]

J'ai testé le lien OLE DB de PG.

1-lors du lancement de l'import de DATA SQL SERVER propose postgres désormais. (on avance!)
2-Malheureusement, qd ttes les spécifications demandées sont renseignées (Datasource, localisation,utilisateur, pwd), je teste la connexion, SQl server me met un message d'erreur:
"Echec du test de connexion en raison d'un erreur survenue lors de l'initialisation du fournisseur. Erreur non spécifiée"

Sais tu ce que ça signifie?

[rudib]

Tu as eu aussi une bonne réponse sur les forums de MSDN France

Ok, donc le pilote OLEDB de PG n'est pas aussi irréprochable que ça... Ton message d'erreur indique un problème de provider.

Un ETL ne simplifie pas forcément cette étape. l'ETL est fait pour un travail répétitif sur des ,étadonnées fixes, pas pour un import d'une seule fois.

Essaie peut-être le driver ODBC (il doit y en avoir un )

Si ça ne marche pas, tu as aussi la possibilité de faire le reverse-engineering du schéma de ta base PG avec un outil de modélisation (une version d'essai d'un outil du commerce par exemple. Pas Embarcadero ER/Studio, que je viens de vérifier : il ne supporte pas PG. Peut-être powerdesigner), pour regénérer le modèle dans SQL Server. Ensuite, en exportant les données sous forme de script d'insertion ou en essayant le provider OLEDB ou ODBC en serveur lié (linked server).

Essaie de scripter tout ça. En général dans ce genre de migration, on doit refaire les choses plusieurs fois, soit parce qu'on passe par une phase de test, soit qu'il y a des points à corriger.

[romain_kdp]

Tu as eu aussi une bonne réponse sur les forums de MSDN France
***Ah, bon? J'ai regardé, mais je n'ai rien trouvé!

Ok, donc le pilote OLEDB de PG n'est pas aussi irréprochable que ça... Ton message d'erreur indique un problème de provider.
***Cad? Le pilote fournit par PG n'est pas valable?

Un ETL ne simplifie pas forcément cette étape. l'ETL est fait pour un travail répétitif sur des ,étadonnées fixes, pas pour un import d'une seule fois.

Essaie peut-être le driver ODBC (il doit y en avoir un )
***J'ai effectivement un driver ODBC. Je l'ai testé via le test de connexion proposé dans le menu "\panneau de config\outils d'adm°\source de données ODBC", la connexion est effective. Par contre dans le menu import de donnée de SQL server, le driver odbc PG installé n'apparait pas. J'ai des pilotes ".Net", des "Ole DB", "SQL Native Client", "SQLXMLOLEDB", et bien sur le pilote "PG OLE DB"

Si ça ne marche pas, tu as aussi la possibilité de faire le reverse-engineering du schéma de ta base PG avec un outil de modélisation (une version d'essai d'un outil du commerce par exemple. Pas Embarcadero ER/Studio, que je viens de vérifier : il ne supporte pas PG. Peut-être powerdesigner), pour regénérer le modèle dans SQL Server. Ensuite, en exportant les données sous forme de script d'insertion ou en essayant le provider OLEDB ou ODBC en serveur lié (linked server).
***A ce niveau là j'ai explosé mon seuil d'incompétence!!! Je suis utilisateur de base de donnée, mais pas expert dans ce domaine. Je crois avoir été très naif en imaginant qu'en passant par une solution microsoft tt serait pré-paramétré et que je pourrais migrer tte une base en un clin d'oeil. Il semble que ce soit un vrai métier DBA finalement!

Essaie de scripter tout ça. En général dans ce genre de migration, on doit refaire les choses plusieurs fois, soit parce qu'on passe par une phase de test, soit qu'il y a des points à corriger.

[rudib]

Salut,

Bon, j'ai honte de ce que je vais dire, mais ça peut sans doute le faire sans que tu te prennes trop la tête.
Si tu as Access, essaie d'importer les tables PG avec le driver que tu as installé. Quand tu as tout mis dans Access, tu as un assistant d'upsizing vers SQL Server. Ca le fera peut-être ?

Autrement il y a ceci :
http://www.2haveit.com/listdetail.php?id=36222

[romain_kdp]

Si tu as Access, essaie d'importer les tables PG avec le driver que tu as installé.
***L'idée est bonne, mais j'ai des tables qui sont de tailles indécentes (exemple table de logs de mails sur 6 mois d'ancienneté elle fait 38 millions de lignes) aussi le pauvre Access n'y résistera pas!

Autrement il y a ceci :
http://www.2haveit.com/listdetail.php?id=36222

Qu'est ce que cela vaut ce type de soft? C'est sérieux? Je suis dubitatif, les pilotes fournis par PG ne fonctionne pas et un soft edité par une autre entité que PG pourrait avoir les bons pilotes?

Merci en tt cas

[rudib]

Le soft en question passe peut-être en natif au lieu d'utiliser de l'OLEDB.

En effet, il ne faut pas rêver, avec ce genre de volumétrie, il vaut mieux le faire à la main.

[romain_kdp]

Je vais tester tt de même l'outil vu qu'il le propose en test. Mon intuition est que c'est une IHM et qu'il faut lui donner les pilotes (ie ceux déjà utilisés qui n'ont pas été d'un grand succès!).

Qu'entends tu par "faire à la main"?

De guerre las, je crains que je vais m'affranchir des pb de connexions avec Postgres. J'envisage d'exporter toutes les tables en fichier plats et de les recharger ensuite dans sql server. Qu'en penses tu? Y a t il des précautions à prendre? Y a t il un moyen d'automatiser un export en fichier plats de toutes les tables d'une base? Ensuite j'imagine qu'au sein de SQL server il faudra définir une seule fois table à table l'import; les maj seront automatisables?

Merci

[rudib]

Qu'entends tu par "faire à la main"?

Justement : passer par des fichiers plats

Y a t il des précautions à prendre?

Générer des CREATE TABLE et des INSERT plutôt standard.
Pour le CREATE TABLE, tu peux passer justement par un outil de modélisation en version démo, en faisant du reverse engineering (recréation du modèle à partir de la base) de PG, puis génération du modèle logique, puis création du modèle physique SQL Server.
Ou alors générer les CREATE TABLE en script, et changer à la main la syntaxe pour les types de données, les index, les contraintes, ...

Y a t il un moyen d'automatiser un export en fichier plats de toutes les tables d'une base? Ensuite j'imagine qu'au sein de SQL server il faudra définir une seule fois table à table l'import; les maj seront automatisables?
Merci

L'idée est soit de faire un dump en fichiers plats, et d'utiliser du BULK INSERT du côté SQL Server, ou alors de générer des instructions INSERT INTO (une instruction de la norme SQL ANSI en général bien respectée dans les SGBD, donc portable), pour les relancer en SQL Server. De toute manière met tout ça en script pour le réutiliser.

Ici de l'aide de la communauté PG sur les drivers PG : il y a des options du driver à considérer, du peux générer un log aussi.

Pour exporter PostgreSQL, tu as pg_dump, ou pg_dumpall pour plusieurs bases.
Pour le csv, tu as la commande COPY, c'est dans la faq PG de developpez.

[romain_kdp]

Tout d'abord, merci Rudi de tes bons conseils.

Quelques questions:

Tu proposes d'utiliser un outil de reverse engineering (recréation du modèle à partir de la base) de PG, puis génération du modèle logique, puis création du modèle physique SQL Server.

Quelle est la valeur ajoutée de recréer tout le modèle? Si j'insert toutes les tables une à une, je disposerais de toutes les clefs qui les relies entre elles, je devrais certainement recréer les index et certains format de données, est ce que ce sera suffisant? Perdrais-je certaines propriétés de la base en insérant table à table?

D'autres part à lire les posts sur les forums, je constaste que les tâches d'export et d'import sont des sources d'erreur. Est ce à dire que même en ayant définit une fois ces procédures (export/import), il y a toujours des erreurs?

Merci encore

[rudib]

Pour le reverse engineering, c'est pour éviter de générer des CREATE TABLE pour chaque table, avec des types de données incompatibles d'un système à l'autre qu'il faut corriger à la main. C'est simplement pour gagner du temps.

Pour les erreurs, il y en a toujours en informatique Si les données sont cohérentes d'un côté comme de l'autre, notamment grâce à des contraintes de domaine (type de données compatibles, etc), je ne vois pas de raison à ce qu'il y ai toujours des erreurs. Ceci dit si tu gères les erreurs éventuelles dans ton script, et que tu mets tes imports dans une transaction, cela ne peut être que mieux.

[romain_kdp]

Rudi,

Pour info je te mets la réponse que m"a fait l"avant vente Microsoft:

Pour la migration, il est nécessaire d’utiliser un fournisseur de données permettant l’accès à la base PostGRE

Utiliser le Wizard de copie de donnée de SSMS (SQL Server Management Studio).

En cas d’erreur de conversion, sauvegarder la package SSIS généré et l’éditer pour traiter les conversions requises.

La copie de vue doit être testé.

Il est peut probable que les procédures stockées (ou triggers) puissent être migré automatiquement (réécriture probablement nécessaire)



Des internautes préfère utiliser la version DTS 2000 plutôt que SSIS

***************************
Le SSMS est en fait l'interface d'import que j'ai déjà utilisé et qui a besoin des pilotes ole db/odbc PG. Cette solution ne fonctionne pas.

Le DTS 2000, c'est l'extracteur de données de SQl 2000, qui effectivement comprend un pilote qui permet de lire du PG. Le Pb c'est qu'à l'import on ne peut prendre que qq tables à la fois ( moins de 4 en fait). P ê du aux volumétries des tables?

En somme, il semble que pour la connectique avec PG SQl server n'a pas évolué!

Qu'est que c'est une procédure stockée?

Il me reste à tester le lien que tu m'as envoyé hier sur le soft qui prétend faire l'import de PG vers SQL Server.

Cpdt, compte tenu des volumétries importantes de mes tables, des pb de connectiques avec PG, je pense que passer par un export en fichier plats, puis un import ds SQL server 2005 me semble le plus fiable. Qu'en penses tu?

Microsoft sous entend également que PG repose sur une vieille technologie. c'est vrai?

[rudib]

Pour le pilote qui ne fonctionne pas, tu auras peut-être de l'aide avec la communauté PG. C'est peut-être une question de paramétrage du pilote.

Pour la régression je ne sais pas, mais SSIS est complètement redesigné et n'a plus rien à voir avec DTS.

Je serais aussi pour les fichiers plats, vu ton volume de données. Regarde du côté de BCP.EXE ou du BULK INSERT.

Les procédures stockées, ce sont des procédures (du code SQL) qui résident sur le serveur. Grossos modo cela veut dire que s'il y a du code SQL écrit, il faudra réécrire.

C'est de l'intérêt de Microsoft de considérer que tout ce qui n'est pas eux repose sur une vieille technologie. PG est un SGBD solide. Si je dois monter un SGBD libre aujourd'hui, je regarderai quand même du côté Firebird plutôt que PG, mais c'est à tester. Ca dépend des volumes et des besoins.

[romain_kdp]

Rudi,

En fait, pour avoir les drivers ODBC je m'étais adressé à la communauté PG. Aussi je n'ai plus de grands espoirs de connexions à la base PG.

Ma base aujourd'hui fait 3.5 Go réparties sur 370 tables.

La mise en oeuvre de l'export en fichier plat, puis la reconstitution de la base sous SQL Server, cela prend combien de temps pour un expert? Je sais que cela dépend de bcp de paramètres, mais bon peux tu me faire une estimation?

Merci

R.

[rudib]

Il peut y avoir pas mal de surprises. Un jour, éventuellement deux, si tout va bien. Avec un bon éditeur de texte pour faire des rechercher/remplacer en cas de problème, ça aide.