Skip site navigation (1) Skip section navigation (2)

Re: Migration SQL Serveur 2008 vers PostgreSQL

From: "F(dot) BROUARD / SQLpro" <sqlpro(at)club-internet(dot)fr>
To:
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL
Date: 2012-01-05 08:30:06
Message-ID: 4F055F8E.9000807@club-internet.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Le 04/01/2012 11:46, Dimitri Fontaine a écrit :
> "F. BROUARD / SQLpro"<sqlpro(at)club-internet(dot)fr>  writes:
>>> J'ai vu quelques outils et/ou scripts sur le net, mais j'aurai bien aimé avoir
>>> une retour d'expérience d'une personne qui aurait déjà fait ce travail pour
>>> prendre une direction sérieuse sans trop perdre de temps.
>>
>> il n'existe aucun outil capable de traduire automatiquement les fonctions,
>> triggers et procédures de l'un vers l'autre.
>
> Je ne sais pas à quel point cela est vrai, mais à mon avis il faut
> commencer par cataloguer les fonctionnalités MS SQL utilisées et voir si
> PostgreSQL propose une équivalence.

vision utopique et naïve... Il existe en standard
1 351 procédures stockées systèmes
136 procédures stockées systèmes étendues
43 fonctions tables systèmes
42 fonctions scalaires système

Si la base de données utilise ces routines, il faudrait aussi les 
"traduire" sachant que les procédures étendues sont codées en C et qu'il 
n'est pas possible d'avoir le code source...

Bref, quelques années/homme de travail préliminaire !

>
>> En sus, PG étant très limité :
>
> C'est exagérer.  Les fonctions PostgreSQL sont très avancées et
> permettent de faire de nombreuses choses.  En particulier il est
> possible de les implémenter dans de nombreux languages, ce qui est
> parfois utile (j'ai un cas de migration avec du pljava relativement
> intéressant sous la main).
>
>> - au niveau des procédures stockées (en fait elle n'existent pas, seule des
>> fonctions atomiques existant dans PG) ce qui pose problème si des
>> transactions sont encapsulées dans les PS.
>
> Il s'agit ici d'un vrai problème à détecter au plus tôt dans le plan de
> migration, en effet.

Pour cela vous pouvez faire la requête suivante :

SELECT O.object_id, S.name AS NOM_SCHEMA,
        O.name AS NOM_ROUTINE, type_desc AS NATURE
FROM  sys.objects AS O
       INNER JOIN sys.sql_modules AS SQ
             ON O.object_id = SQ.object_id
       INNER JOIN sys.schemas AS S
             ON O.schema_id = S.schema_id
WHERE definition LIKE '%BEGIN TRAN%' COLLATE French_CI_AI
    OR definition LIKE '%COMMIT%' COLLATE French_CI_AI
    OR definition LIKE '%ROLLBACK%' COLLATE French_CI_AI

Ceci ne vous garantie pas de trouver que des routines encapsulant des 
transactions, mais c'est un excellent point de départ...

>
>> - au niveau des triggers, car PG n'autorise pas la mise à jour de la table
>> cible et de même que pour les PS il n 'est pas possible de piloter la
>> transaction à l'intérieur du déclencheur.
>
> Comme le dit Guillaume, il est tout à fait possible de mettre à jour la
> table cible depuis un trigger avec PostgreSQL.
>
> La seule vrai grande limite apparente serait donc le contrôle des
> transactions depuis une procédure stockée.  Il existe des contournements
> afin de réaliser cela avec PostgreSQL, comme dblink et plproxy.
>
>> Enfin, il y a une grande différence de syntaxe entre PG et MS SQL Server.
>> Bref, il faudra sans doute recoder toutes les routines...
>
> Il existe un outil permettant de convertir automatiquement depuis la
> syntaxe PLSQL de Oracle vers la syntaxe de PostgreSQL.  Il existe aussi
> une implémentation de PLSQL dans PostgreSQL, en tant que langage de
> procédure stockées.
>
> Il est certainement possible de réaliser le même genre d'outils pour les
> procédures stockées de MS SQL (pl/tsql), il reste à déterminer si cela
> est une option rentable pour votre projet de migration et à plus long
> terme (cela ajoute une dépendance dans le cas de pl/tsql, mais peut être
> un bon compromis afin de démarrer au plus tôt sous PostgreSQL et de
> terminer le portage de l'application dans des délais raisonnables).
>
> Si cela n'était pas rentable, effectivement, une conversion manuelle me
> semble la piste à retenir.


Ce sera sans aucun doute la voie la plus sage !

A +


-- 
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR  :  http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************


In response to

Responses

pgsql-fr-generale by date

Next:From: Cousin FlorenceDate: 2012-01-05 08:52:00
Subject: RE : Migration SQL Serveur 2008 vers PostgreSQL
Previous:From: Jehan-Guillaume (ioguix) de RorthaisDate: 2012-01-04 15:55:42
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group