Discussion :

[ptitmika]

Bonjour,

Je dois essayer de convaincre un client qui possède actuellement une license Oracle 9i, dont il est content, de migrer vers Oracle 10g.

En tant que développeur, le point qui me donne envi de bosser avec la 10g est la possibilité d'effectuer du debug dans les procédures stockées.

Je suis donc actuellement à la recherche d'arguments valables pour convaincre mon client que la 10g c'est super plus beaucoup mieux pour lui aussi (ben oui, il s'en fiche un peu de mon debug des procédures stockées lui).

J'ai pour l'instant pu trouver les arguments suivants sur divers site :

l'administration de grappes de serveurs via un mécanisme de distribution des programmes sur plusieurs machines, en vue notamment de répartir la charge lors du passage en production - et garantir ainsi le bon fonctionnement du service. Un mécanisme qui est celui de la "grille".

possibilité d'allouer des ressources machine à un logiciel au regard de règles préétablies, une période de l'année ou un moment de la journée par exemple

Cette nouvelle mouture inaugure également l'apparition d'un assistant d'administration des espaces mémoire et de leur allocation (par tables, etc.).

Simplification de l’installation

Merci par avance de votre contribution

[orafrance]

Si tu n'as pas d'argument c'est qu'il n'a probablement pas besoin (les 2 premiers arguments n'intéressant probablement pas du tout le client)
Si le but c'est de vendre une migration à tout prix, désolé mais j'appelle ça de la malhonnêteté

Sinon, CBO amélioré, bug corrigé, support assuré pendant plus longtemps et gestion des sauvegardes simplifié.

[pifor]

Concernant le support de la 9.2 il faut noter que:
- premier support s'arrête en juillet 2007
- extended support s'arrête en juillet 2010
- sustaining support est illimité

Pour la 10.1, ajouter 2 ans par rapport à la 9.2
Pour la 10.2, ajouter 3 ans par rapport à la 9.2

Source: page 10 de http://www.oracle.com/support/librar...-datasheet.pdf

[NGasparotto]

ptitmika,

Les arguments que tu avances ne concernent effectivement pas du tout, mais alors pas du tout l'utilisateur.

Le premier argument d'une migration, est la question du support, ou plutôt du désupport de sa version actuelle.
La 9i n'en a plus que pour quelques mois... à devoir être supportée, en mode normal (il y aura bien "extended support", mais ca coûtera plus cher). La 11g devrait arriver d'ici la fin de l'année, et Oracle fera tout pour se débarrasser de la 9i au plus vite.

Sinon, si l'appli rencontre des bugs, etc., voir s'ils sont corrigés en 10g, s'ils y a des workarounds lourds, voir s'ils ne sont pas implémentés d'office en 10g etc.

Ensuite, il faut voir dans le contexte propre de l'appli, de qui fait l'admin, de l'historique de l'appli (si une migration 8i => 9i a eu lieu récemment, c'est difficile de migrer à nouveau...), etc.

Et parce qu'en général, on n'a pas une base pour avoir une base, il y a généralement une appli qui tourne dessus, il faut donc tout de même avoir préalablement validé ton appli en 10g, et/ou avoir demander au vendeur du logiciel la compatibilité.

Nicolas.

[plaineR]

En tant que développeur, le point qui me donne envi de bosser avec la 10g est la possibilité d'effectuer du debug dans les procédures stockées.

C'est faible comme motivation D'autant plus qu'il existe de nombreux outils pour faire du debuggage de procédures stockées.

Au niveau du développement, je trouve qu'il y assez peu de nouveautés par rapport à la 9i :
- dbms_scheduler
- utl_mail (intérêt très limité car impossible d'envoyer des pièces jointes de plus de 32k)
- utl_file permettant d'écrire des fichiers binaires
- la taille des LOBs quasiment illimités
- de nombreuses fonctions qui s'applicait uniquement au varchar sont applicables au CLOB
- et comme l'a dit Fred tout ce qui concerne l'optimisation des requêtes

Les principales nouveautés sont surtout au niveau de l'administration. En ce qui concerne le développement, hormis quelques besoins patrticuliers, il n'y a pas vraiment d'arguments pour passer en 10g.

[NGasparotto]

En ce qui concerne le développement, hormis quelques besoins patrticuliers, il n'y a pas vraiment d'arguments pour passer en 10g.

Moi j'aime bien les expressions régulières.

Nicolas.

[orafrance]

les amis vous semblez oublier de rapprocher le coût d'une migration par rapport au gain en terme de dév

[NGasparotto]

les amis vous semblez oublier de rapprocher le coût d'une migration par rapport au gain en terme de dév

Biensur que le coût de migration n'est pas négligeable. C'est pour ca que je dis qu'il est difficile à justifier si une migration vient d'être faite.

Mais le choix devrait être entre un coût de migration et ne pas (plus) avoir de support ou tout du moins un surplus à payer.

Nicolas.

[orafrance]

attention, n'oublions pas qu'une version continue sa vie même après le support standard

[NGasparotto]

attention, n'oublions pas qu'une version continue sa vie même après le support standard

Oui, il y a l'extended support, comme je l'ai mentionné précédemment, mais c'est plus cher que le support standard.

Nicolas.

[orafrance]

même sans l'extended t'arrive à survivre. Par exemple en 8i, il n'y a aucun souci aujourd'hui

[NGasparotto]

même sans l'extended t'arrive à survivre. Par exemple en 8i, il n'y a aucun souci aujourd'hui

Je suis bien d'accord, nous avons ici encore pas mal de bases 8i.
En fait, tout depend de la sensibilité de l'application, à mon avis plus elle est sensible (gestion paies par exemple) , plus on a intérêt de suivre les dernières versions, ou tout du moins de suivre le support.

C'est une question de corrélation entre la mise en oeuvre des moyens et ce que l'on veut.

Nicolas.

[ptitmika]

Merci pour vos réponses rapides.

En fait, nous allons développer une nouvelle application pour ce client sur laquelle reposera son activité principale dans les années à venir.

Personnellement, je suis pas très chaud pour débuter le développement d'un nouveau produit en n'utilisant pas les dernières technologies disponibles, surtout si ce nouveau produit doit vivre et être maintenu durant plusieurs années, d'où l'idée de débuter l'appli sous 10g.

Cependant, à la vue de vos réponses, il semble qu'il n'y a pas grand chose de révolutionnaire justifiant le coût d'achat d'une nouvelle license.

Encore merci d'avoir répondu si vite

[NGasparotto]

Merci pour vos réponses rapides.

En fait, nous allons développer une nouvelle application pour ce client sur laquelle reposera son activité principale dans les années à venir.

Personnellement, je suis pas très chaud pour débuter le développement d'un nouveau produit en n'utilisant pas les dernières technologies disponibles, surtout si ce nouveau produit doit vivre et être maintenu durant plusieurs années, d'où l'idée de débuter l'appli sous 10g.

Pour un nouveau produit, mieux vaut partir sur la dernière version disponible au début du dev, d'autant plus que celle-ci est une Release 2 (donc théoriquement plus robuste qu'une Release 1). En effet autant la r1 de la 9i que la r1 de la 10g ont été bien vite oubliées, et sans regret.

Une migration finira toujours par coûter plus cher que juste l'acquisition de la license en début de projet.

Mais il ne s'agit pas de migration s'il s'agit d'un nouveau projet ?

Les derniers projets à être partis en 9i chez nous le sont depuis le début d'année dernière et regrette déjà de ne pas être directement allé sur la 10.2

Nicolas.

[orafrance]

en effet, pour un nouveau projet ça se justifie

[ptitmika]

Mais il ne s'agit pas de migration s'il s'agit d'un nouveau projet ?

Oui, il s'agit bien d'un nouveau projet.

Les derniers projets à être partis en 9i chez nous le sont depuis le début d'année dernière et regrette déjà de ne pas être directement allé sur la 10.2

Quels sont les points qui vous font regretter vos choix ?

[NGasparotto]

Quels sont les points qui vous font regretter vos choix ?

Qu'il faudra prévoir une migration de base de données toujours très difficile à justifier aux clients. Alors même que l'application est certifiée sur la 10g et que celle-ci était disponible.
C'est un peu comme acheter un nouveau PC aujourd'hui, tant qu'à faire, autant partir avec Vista plutôt que XP (bon, c'est juste un exemple...).

Déjà vu : refuser des migrations successives (8.0.6,8.1,x,9.x,10.x) , sous prétexte que tout fonctionne bien, jusqu'au jour où ils s'aperçoivent qu'il ont trois versions de retard (ou plus), et qu'il y a plein de bugs avec les derniers OS (forcément non supportées par les vieilles versions d'Oracle), et que certaines fonctionnalités des dernières versions pourrait alléger certains workaround maison vraiment lourd.
La question de la migration devient alors d'actualité, mais le coût est désormais prohibitif, passer de la 7.x à la 10g représente un risque non négligeable pour l'application, et donc pour le client.

Enfin, tout ca pour dire qu'il faut prendre en compte chaque contexte client/fournisseur. Ne pas vendre à tout prix une migration dans la toute nouvelle dernière version (attendre un peu ne peut pas faire de mal, à part bug avéré et corrigé), et en même temps profiter des dernières technos pour les nouveaux projets ne semble pas être un abus ou une gageure, bien au contraire, l'application n'en sera que plus pérenne.

Nicolas.

[ptitmika]

Bon, les jeux sont fait, on utilisera Oracle 9i.