Journal Migration Sybase --> PostgreSQL

Posté par  .
Étiquettes : aucune
0
10
mar.
2004
Durant mon stage, je dois étudier les possibilités de migration de bases sybase vers PostgreSQL.
Le but est de migrer tout vers un serveur de test, de voir si la migration s'est bien passée puis de benchmarker tout ça pour voir si ça tient la charge.
Jusque là ça parrait simple. Pour exporter les table, il n'y a pas beaucoup de modifs à faire, pour les données non plus (sauf peut être pour les binry). Mais le gros "problème" de ces bases c'est le très nombre de procédures (4359 pour être exacte). Même si elles ne font pas toute 50 lignes, je penses qu'une migration "à la main" est impensable.
J'aurais donc aimé savoir si quelqu'un connaissait une solution (par exemple un script) même si celle ci n'est pas complète, elle pourrait déjà constituer une base.

PS : si vous avec des conseils pour la migration, ils sont aussi les bienvenus.

  • # Re: Migration Sybase --> PostgreSQL

    Posté par  (site web personnel) . Évalué à 1.

    Qu'est ce que c'est comme langage pour le procédure stockée ?

    • [^] # Re: Migration Sybase --> PostgreSQL

      Posté par  . Évalué à 1.

      sous Sybase (j'ai oublié de préciser : la version est la 11.0.2), les procédures sont en Transac-SQL (un peu le même que celui de SQL Serveur puisque MS s'étaient basés sur une ancienne version de Sybase pour faire SQLServeur)
      Donc l'expérience d'une migration à partir d'un MS SQL pourrait m'être utile (pour l'instant, j'ai trouvé des docs avec des conseils mais ça reste assez vague)

  • # Re: Migration Sybase --> PostgreSQL

    Posté par  . Évalué à 1.

    Il faut aussi examiner les applications qui interrogent cette base.

    Est ce que vous avez les sources ? La capacité à les recompiler ? Comment sont construitent les requêtes ?

    Le "SQL standard" est un mythe : il faut lister l'ensemble des requêtes pour voir quelles sont celles qui font des trucs spécifiques Sybase (par exemple, tu parles de bases au pluriel. Si tu essayes de faire des jointures entre tables de plusieurs bases, tu es mal avec Postgres).

    Ensuite, pour les procédures stockées, il faut regrouper celles qui font des trucs similaires, en réécrire quelques unes à la main et ensuite écrire une moulinette (en perl par exemple) pour construire les autres sur le même modèle.

    A moins que la base soit hyper clean (mais avec 4359 procédures, ça me parait peu probable), c'est un travail énorme.

    • [^] # Re: Migration Sybase --> PostgreSQL

      Posté par  . Évalué à 1.

      La migration des applis est un problème séparé pour moi (pour l'instant elles n'utilisent même pas toutes ODBC) et même si mon travail aboutit sur un "non ce n'est pas possible de migrer vers Postgres", il est prévu qu'elles soient modifiées pour acceder à Sybase (à une nouvelle version) par ODBC.
      Pour l'instant, il faut déja savoir si cette migration est possible : parceque s'il faut plus 2 ans à temps plein pour réécrire les procédures, ça ne passera pas.
      C'est justement l'interret que je sois là en tant que stagiaire (même si au final mon boulot permet de dire que ça n'est pas possible, ça n'aura pas empéché le service de tourner).
      Beaucoup des applis utilisent des procédures stockées pour leur renvoyer le résultat de requètes (c'est d'ailleur pour ça qu'il y en a tant).
      Par contre l'avantage c'est qu'il y a très peu de triggers (moins de 300), pas de contraintes sur les tables et pas de gestion poussée des droits.
      Donc de toute manière, je vais essayer de faire un script de migration automatique de procédure (même s'il y en a qques une a faire migrer manuellement car elle sont trop complexes)... Mais c'est vrai qu'avec une base de départ, ça serait plus facile.

  • # Re: Migration Sybase --> PostgreSQL

    Posté par  . Évalué à 1.

    4359 procedures ???

    c'est monstrueux !

    Ici on a des bases qui doivent gerer 5 Millions de comptes et on a au grand maxi 500 procedures pour une bonne trentaine de services divers (10 a 15 procs par service environ).

    Je ne sais pas où tu es mais il me semble qu'avant tout changement, si vous voulez ce changement, il y a un travail de rationnalisation a faire , de netoyage des doublons , de suppression des procs qui ne sont plus utilisées.

    Si vous envisagez de passer a postgres il faudrait definir un service typique a assurer avec une trentaine de procedures qui servirait de premier banc d'essai de portage.

    • [^] # Re: Migration Sybase --> PostgreSQL

      Posté par  . Évalué à 1.

      En fait, la base a été créé, il y a une bonne quinzaine d'année et elle a évolué petit à petit. Donc au début, sybase ne gérait pas bien les trigger, pas bien les roles, pas bien tout un tas de chose... Don la plupart des logiciels qui accèdent à cette base n'utilisent pas directement des requêtes mais appellent une procédure qui leur renvoie le résultat.

      Bien sûr, je vais commencer par convertir uniquement une partie des procédures. Mais le problème est que je doit faire une étude précise pour savoir si la migration totale est réalisable.
      En plus, comme cette base est vraiment centrale pour le système d'information, il n'y aura pas de migration partielle (pour la prod) ce sera soit tout soit rien.

      Enfin, même si certaines procédures ne sont plus utilisées et devraient être supprimée, je penses que mon chef ne voudra pas "dépenser" un grand nombre d'heure d'une personne qui conait la base à bosser sur ces suppressions avec moi avant d'être sur que la migration peut se faire.

  • # demande d'aide sur les migrations

    Posté par  . Évalué à 1.

    slt, je voudrais savoir quelle a été ta démarche pour tester et effectuer la migration de tes bases de données de Sybase en Postgresql(outil et script utilisés, tes besoins, toute information utile), en effet je suis en stage et je vien juste de commencer et je sais pas par ou commencer. Merci à kikonque pourrai me filer un petit coup de main.

    • [^] # Re: demande d'aide sur les migrations

      Posté par  . Évalué à 1.

      Je n'ai trouvé aucun script existant pour réaliser la migration.
      Je suis donc en train de créer mon propre script Perl de manière empirique :
      • j'exporte en la structure de sybase (extraction sous forme de fichiers de script SQL),
      • je regarde ce qui ne passe pas sous PostgreSQL,
      • je transforme le SQL grâce à mon script Perl jusqu'à ce que je n'ai plus de problèmes,
      • et je fait de même pour tous les types de structure (table, index, vue, ...)

      Pour les données, je n'ai pas eu trop de problème (enfin pour l'instant) :
      lors de la réecriture du script SQL de création des tables, pour chaque table, je crée une commande bcp (logiciel d'extraction de données) puis je modifie un peu le fichier (les formats de date/heure ne sont pas compatibles) et je les importe directement dans postgreSQL.

      Je suis en stage à la cci de haute-savoie jusqu'au 25 juin.

      Je penses qu'on pourait se contacter par mail pour affiner un peu plus et éventuellement travailler en commun pour avancer plus rapidement.

      • [^] # Re: demande d'aide sur les migrations

        Posté par  . Évalué à 1.

        oups j'ai oublié de de filler mon mail
        virginie.quesnay(AT)free.fr

        • [^] # SQLserver -> postgresql

          Posté par  . Évalué à 1.

          slt, la moi oci g une base test de 46 tables a faire passer de sqlserver à postgresql, g plus ou moins etudier les deux sgbd. au niv de la creation des tabvles et de l'exportation des données, ca ne pose pas prob, mais je dois exportert plus d'une 50 aine de prod stockées et ca ne marche pas du tout. J'ai d'abord essayer avec l'outil de modélisation PowerAMC et ca ne m'a pas fait de génération automatique comme la génération de la base de données qui avai bien marché. Mais ca ne compile pas pour la génératiuon de script de prod stock. enfin la jetudie les prod stock et je rame un peu pour le lieu ou je suis en stage.(adresse laurent_suos@hotmail.com)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.