Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Migration SGBD Discussion :

Migration Oracle vers Firebird, avis?


Sujet :

Migration SGBD

  1. #1
    Membre expérimenté
    Avatar de sat83
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2004
    Messages
    1 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2004
    Messages : 1 040
    Points : 1 309
    Points
    1 309
    Par défaut Migration Oracle vers Firebird, avis?
    Bonjour à tous,
    Ma société possède un parc d'applications (environ 50) de gestion développées en C++ et dialoguant avec une base de donnée Oracle 9.i. Les liaisons à la bases de données sont effectués via des alias ODBC.

    Nous souhaiterions nous passer de la base Oracle et migrer vers une base gratuite. Notre premier choix s'est porté sur Firebird, mais il n'est pas arrété.

    Avant de me lancer dans ce projet, je souhaiterais connaitre votre avis sur cette migration, les questions à se poser avant, les problèmes que je rencontrerais, les différences notables entre les bases, ou toute autre information ou retour utile.

    Si vous avez besoin d'autres infos, n'hésitez pas à me demander!

    Par avance merci!
    Ce que l'on apprend par l'effort reste toujours ancré plus longtemps...

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 683
    Points : 2 573
    Points
    2 573
    Par défaut
    En gratuit, je pense que PostgreSQL sera bien plus proche d'Oracle en terme d'architecture, de fonctionnalités et de performance que Firebird.

  3. #3
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 782
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 782
    Points : 6 665
    Points
    6 665
    Billets dans le blog
    1
    Par défaut
    Ou comment passer d'une Rolls Royce à une Axiam...

    Effectivement, PostgreSQL sera plus proche fonctionnellement de Oracle.

    A noter tout de même que selon les volumes et les besoins en performances :
    - Oracle XE existe, et est gratuit
    - SQL Server Express aussi

    Oracle XE restera, s'il est applicable, le meilleur choix, puisque vous ne changerez pas de produit.

    SQL Server Express, s'il est applicable, sera le second meilleur choix, puisqu'il sera ce qu'il y a de plus proche d'Oracle en termes de fonctionnalités et de performances.

    A noter tout de même que selon l'utilisation actuelle de la base, vous vous lancez dans un chantier monstrueux, qui pourrait coûter bien plus cher au final que les licences Oracle.

    Bon courage en tout cas !
    On ne jouit bien que de ce qu’on partage.

  4. #4
    Membre expérimenté
    Avatar de sat83
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2004
    Messages
    1 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2004
    Messages : 1 040
    Points : 1 309
    Points
    1 309
    Par défaut
    Merci pour vos réponses...
    Je ne connaissais pas PostgreSQL, je vais chercher un peu de doc la dessus.

    Pour Oracle XE, les limitations (si je ne me trompe pas) sont qu'il n'utilise qu'un seul CPU, que 1GB de RAM, et qu'il se limite à 11GB de données, c'est bien ça?
    Est-ce que cela n'affecte pas trop les performances (je pense surtout à la RAM)?
    Est ce que la version est bridée en terme de fonctionnalités?

    Je pense clairement qu'Oracle est surdimensionné pour nos besoins, la version XE peut être un bon compromis pour limiter le coût.

    Notre utilisation de base de données:
    - Une 30aine d'applications C++ attaquant la base
    - Quelques centaines de table dans quelques dizaines de schéma
    - Environ 300 utilisateurs
    - Quelques dizaines d'utilisateurs en simultané (mais pas intensif)
    - Au niveau volumétrie on doit être à quelques GB

    Est en choisissant Oracle XE les performances baisseront significativement pour nos utilisateurs?
    Ce que l'on apprend par l'effort reste toujours ancré plus longtemps...

  5. #5
    Membre émérite

    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 683
    Points : 2 573
    Points
    2 573
    Par défaut
    Les performances dépendent de tellement de paramètres et leur appréciation subjective. Vous devez bien avoir des bases de test, testez l'application sur une version XE et vous aurez la meilleure réponse qui soit.

  6. #6
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    19 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 515
    Points : 46 177
    Points
    46 177
    Par défaut
    fireBird est une cata en terme de verrouillage et de transaction.... De plus cela semble quasi mort...

    Effectivement PostGreSQL est bien plus dynamique et performant pour ce changement.

    Attention cependant à certaines pièges.

    A me lire : http://blog.developpez.com/sqlpro/p1...esql-ou-com-2/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 782
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 782
    Points : 6 665
    Points
    6 665
    Billets dans le blog
    1
    Par défaut
    Pour en revenir aux limitations de Oracle XE, voici quelques éléments de réponse.
    Déjà, je n'ai pas re-consulté les limitations telles qu'elles existent maintenant : elles sont sujettes à évolution d'une version à l'autre, et je ne me suis jamais vraiment penché sur la problème.

    Toutefois, en parallèle avec mon expérience avec SQL Server Express :

    Utilisation d'un seul CPU au lieu de plusieurs
    Ceci était une grosse limitation il y a quelques années lorsque les CPU étaient mono-coeur, et qu'il fallait utilise le SMP pour disposer de plusieurs CPU sur une même machine. Ensuite, on a eu droit à différentes version du multi-coeur, avec le hyperthreading, et autres joyeusetés. Aujourd'hui, les CPU Intel tout du moins, disposent de plusieurs coeurs, qui agissent comme autant de CPU physiques. Cependant, lorsqu'un coeur est largement plus utilisé que les autres, ces derniers se downclock alors que celui qui est utilisé s'overclock grandement. Il en résulte le fait que lorsqu'on utilise un seul coeur sur un CPU 8 coeurs, alors il tourne près de 8 fois plus vite que si tous les coeurs étaient utilisés en même temps. On revient donc à des performances brutes similaires. Enfin, le CPU est loin d'être la partie du SGBD qui pose le plus de problèmes en termes de performances.

    Utilisation limitée de la RAM
    Là, c'est bien plus problématique. En effet, 1 Go de mémoire pour une base de données, c'est un peu limite. En même temps, je travaille ici sur un ERP qui utilise Oracle 10gR2 avec 2 Go sur le serveur pour une base de données de 60 Go.
    Ils viennent de migrer sur Oracle 11gR2, avec 6 Go, et c'est effectivement plus rapide. Mais l'ancien serveur tournait quand même tout à fait honorablement vu à la fois le modèle des données, la complexité des traitements qui tournaient dessus, et surtout leur nombre (plusieurs dizaines de traitements lourds en permanance). Je pense donc que même si la limitation est de 1 Go, selon l'utilisation, cela pourrait ne pas être si important en termes de perte de performance.

    La taille de la base
    Là, effectivement, si la base est plus grosse que ce que permet de gérer Oracle XE, il y a problème

    Les moyens de contourner l'ensemble de tous ces problèmes
    Vous parlez d'application distinctes et de différents schéma. J'en déduit donc que :
    - Une partie des applications travaille sur des données sur lesquelles d'autres applications ne travaillent pas : il est donc à priori possible de découper la base de données en plusieurs
    - Ceci se confirme par votre utilisation de schéma
    - A l'aide de DBLINK, vous pouvez faire inter-agir, moyennant effectivement une perte importante de performance cependant, plusieurs bases de données ensemble.
    Après analyse, j'imagine qu'il vous est possible de transformer votre "unique grosse base" en plusieurs bases distinctes (référentiel produit, référentiel client, référentiel compta, etc.) avec des volumes peu importants transitant entre les bases. Ceci demandera la réécriture de quelques requêtes pour passer par des DBlink, voir l'utilisation de plusieurs bases par les applications. Vous devriez pouvoir masquer une partie de ces changements à l'aide de vues (genre une table "produit" dans la base référentiel compta, qui pointe sur un dblink vers la table "produit" de la base référentiel produit)

    Une fois vos base distinctes, vous pourrez sans problème utiliser un serveur différent par base de données, et ainsi "virtuellement" multiplier le nombre de CPU, quantité de RAM et taille de stockage utilisé par votre base.

    Bon, après, ça reste du bricolage : il faut mûrement analyser l'impact de telle ou telle décision avant de vous lancer. Mais ça me semble tout de même moins radical que de changer de SGBD, et opter pour un nouveau qui sera à la fois plus limité (difficile d'avoir autant de fonctionnalités que dans Oracle) et qui demandera de toute façon à réécrire la moitié des requêtes et peut-être revoir une partie du schéma
    On ne jouit bien que de ce qu’on partage.

  8. #8
    Membre expérimenté
    Avatar de sat83
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2004
    Messages
    1 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2004
    Messages : 1 040
    Points : 1 309
    Points
    1 309
    Par défaut
    Merci pour toutes ces réponses...

    Je vais développer les différents arguments à mon responsable pour qu'il fasse sont choix, mais je pense que nous nous orienterons vers Oracle Express Edition qui limitera considérablement le travail de migration.

    Merci à tous!
    Ce que l'on apprend par l'effort reste toujours ancré plus longtemps...

  9. #9
    Expert éminent
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 085
    Points : 9 570
    Points
    9 570
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Il en résulte le fait que lorsqu'on utilise un seul coeur sur un CPU 8 coeurs, alors il tourne près de 8 fois plus vite que si tous les coeurs étaient utilisés en même temps.
    Je pense que c'est "un peu" exagéré. Dans le cas d'un CPU 8 coeurs à 2Ghz, si un seul coeur est utilisé il ne tournera pas à 16Ghz !
    En fait dans ce cas, le procésseur overclocke légèrment le seul coeur qui tourne, en restant dans son enveloppe thermique.
    Comme on peut le voir par exemple, l'élévation en fréquence n'est "que" de 700Mhz pour un CPU à 3.2Ghz.
    Par contre il est vrai que le seul coeur actif dispose de toute la bande passante disponible, et de l'intégralité du cache de niveau 3, mais je doute que celà suffise pour qu'un seul coeur actif soit 8 fois plus rapide que quand il doit partager ces ressources avec les autres coeurs.

    Tatayo.

  10. #10
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 927
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 927
    Points : 15 861
    Points
    15 861
    Par défaut
    Surtout que la version Express est limitée à un core, pas à un CPU.

  11. #11
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 782
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 782
    Points : 6 665
    Points
    6 665
    Billets dans le blog
    1
    Par défaut
    Merci Tatayo pour la précision.

    Mais bon, comme je le disais, il est rare que le CPU soit, de toute façon, le goulot d'étranglement sur un SGBD (ou alors on a des requêtes à la mord-moi-le-noeud qui font des concaténations et des calculs dans tous les sens, généralement en réponse à un besoin créé par une lacune en SQL)
    On ne jouit bien que de ce qu’on partage.

  12. #12
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 604
    Points : 13 210
    Points
    13 210
    Par défaut
    Citation Envoyé par sat83 Voir le message
    Bonjour à tous,
    Ma société possède un parc d'applications (environ 50) de gestion développées en C++ et dialoguant avec une base de donnée Oracle 9.i. Les liaisons à la bases de données sont effectués via des alias ODBC.

    Nous souhaiterions nous passer de la base Oracle et migrer vers une base gratuite. !
    La première question qui me vient à l'esprit est "en combien de temps pensez vous avoir un ROI épongeant le cout de la migration" ?

    En effet, une migration de base peut être d'un coup assez colossal (que le SGBD cible soit gratuit ou pas), en particulier venant d'Oracle :

    Par exemple, si vous avez développé de nombreux "packages", en PL/SQL sachez que la fonctionnalité n'a de facto pas d'équivalent en Sql Server et PostGre.

    Dans un autre exemple, la migration des proc stoc de Sql Server vers Oracle peut être un cauchemar (pas de notion de retour de données dans les PS Oracle). Et un long etc .....

    Paradoxalement, ce genre de migration peut très bien ne se réveler économiquement rentable qu'avec des applis plus ou moins mal écrites n'exploitant pas le SGBD (l'utilisant comme un "super ISAM" si vous préférez).

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

Discussions similaires

  1. Migration Oracle vers fireBird
    Par ensisoft dans le forum Firebird
    Réponses: 4
    Dernier message: 08/10/2007, 23h54
  2. [IBX] migration paradox vers firebird : Comment fonctionne TIBTable ?
    Par Benjamin GAGNEUX dans le forum Bases de données
    Réponses: 3
    Dernier message: 07/07/2006, 11h22
  3. Migration Paradox vers Firebird 1.5
    Par breiz35 dans le forum Débuter
    Réponses: 11
    Dernier message: 15/03/2006, 13h06
  4. [Migration] Oracle vers SQL Server 2005 - Problème de BLOB
    Par thomasrenault dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 03/02/2006, 11h26
  5. migration oracle to Firebird
    Par bud1703 dans le forum Débuter
    Réponses: 3
    Dernier message: 19/08/2005, 02h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo