Discussion :

[sat83]

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!

[vmolines]

En gratuit, je pense que PostgreSQL sera bien plus proche d'Oracle en terme d'architecture, de fonctionnalités et de performance que Firebird.

[StringBuilder]

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 !

[sat83]

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?

[vmolines]

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.

[SQLpro]

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 +

[StringBuilder]

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

[sat83]

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!

[tatayo]

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 là 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.

[Waldar]

Surtout que la version Express est limitée à un core, pas à un CPU.

[StringBuilder]

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)

[Bluedeep]

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).