Microsoft vous accompagne dans votre migration d'Oracle vers SQL Server 2017
Avec une formation et des licences gratuites

Le , par Michael Guilloux, Chroniqueur Actualités
SQL Server 2017 est officiellement disponible depuis le 2 octobre et pour la première fois, le logiciel de base de données de Microsoft ne sera pas destiné uniquement à Windows, mais également à Linux.

Absent du monde Linux, Microsoft n’avait pas donné d’autres choix aux entreprises que celui d’opter pour Oracle, en ce qui concerne les SGBD propriétaires. Maintenant que le géant du logiciel propose une version de sa base de données sur Linux, il a décidé d’accompagner les entreprises dans leur migration d’Oracle sur Linux vers SQL Server 2017 sur Linux. Les organisations peuvent donc dès maintenant planifier leur migration pour bénéficier de licences gratuites, une formation gratuite et des services de migration subventionnés. Microsoft met également en avant un coût total de possession (TCO) qui ne représente qu’une infime partie de celui d’Oracle.

Il faut noter que cette offre ne s’applique pas qu'à Linux. Vous pouvez également en profiter pour migrer d’Oracle vers SQL Server 2017 sous Windows. L’offre comprend des licences gratuites, des services de support pour démarrer votre migration et accéder au cours SQL Server Essentials de Microsoft pour la formation d'administrateur de base de données Oracle. Cette offre vous permettra de découvrir les fonctionnalités clés de SQL Server grâce à des ateliers pratiques et à des démonstrations réalisées par des instructeurs, mais également apprendre à déployer vos applications sur site ou dans le cloud. En ce qui concerne les fonctionnalités de SQL Server 2017, on peut citer parmi les plus importantes :

  • l’intelligence artificielle intégrée avec des analyses R et Python ;
  • le calcul de score en natif dans T-SQL : une nouvelle fonctionnalité qui vous permet de calculer les scores sur les modèles de machine learning en temps quasi réel ;
  • la gestion et analyse des données de type graphe ;
  • Adaptive Query Processing : une nouvelle famille de fonctionnalités dans SQL Server qui apportent de l'intelligence aux performances de la base de données. Elle comprend par exemple Adaptive Memory Grants qui surveille la quantité de mémoire utilisée par une requête donnée au fil du temps pour éviter une allocation excessive ou insuffisante de la mémoire, situation qui peut affecter les performances ;
  • Automatic Plan Correction : une fonctionnalité qui assure une performance continue en identifiant et en corrigeant les régressions de performance ;
  • Machine Learning Server for Hadoop (ex R Server), qui apporte des analyses évolutives basées sur R et Python aux environnements Hadoop et Spark ;
  • Power BI Report Server, qui offre une expérience de reporting et de tableaux de bord hybrides en vous permettant de gérer vos rapports SSRS à côté de vos rapports Power BI ;
  • etc.

Il faut noter que l’offre est d'une durée limitée. La formation gratuite et les services subventionnés sont disponibles jusqu’à épuisement des stocks ou jusqu’au 30 juin 2018. Vous devez donc vous enregistrer dès maintenant pour vous assurer de bénéficier de l’offre.

Migrez d'Oracle vers SQL Server 2017 (sous Windows ou Linux) et profitez d'une formation et des licences gratuites

Voir aussi :

Pourquoi passer à SQL Server 2017 sur Linux ?
Découvrez le rapport Magic Quadrant de Gartner sur les SGBD


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 10/10/2017 à 18:01
L'idée est tres séduisante mais generalement ceux qui utilisent Oracle font grand usage du PL/SQL (pour codage des procedures stockées) et le gros du boulot de migration ce n'est pas tant la bascule du modele de données (se fait assez simplement) mais plutot le pb de non migration du code applicatif; et ceci est largement redibitoire (tout reecrire en C# ? le travail est colossal sur des gros projets de BDD - on a essayé et la difference de facture ne couvre pas les depenses liées au "portage" du code+tests etc).
Chez nous ca se chiffre en milliers de lignes de code.

Aussi dans ma boite on utilise sqlserver uniquement sur les nouveaux projets (lorsque pas d'existant logiciel) et que le client exige sqlserver (bon, c'est arrivé une fois en 2 ans).
Meme si sqlServer etait gratos (hors presente offre limitée dans le temps) il y aurait malgré tout des couts de migration de code comme on vend plutot a des gros clients (et non pas a des milliers de sites) du coup on fait avec les prix des licences Oracle (qui sont souvent au final derisoires rapportés au cout du projet).
Avatar de mattdef mattdef - Membre régulier https://www.developpez.com
le 10/10/2017 à 18:22
L'équivalent du PL/SQL en Microsoft est le T-SQL, pas le C#. Et il y a des outils pour convertir tout ça plutôt facilement. Enfin perso j'ai jamais eu de gros problême à ce niveau là
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 10/10/2017 à 18:31
Si je dis ca c'est que nous avons essayé et on etait tres tres tres loin de ce qu'on utilisait avec Oracle. T-SQL ca me ramene il y a 20 ans quand je faisais du Sybase donc le plus adapté c'est certainement plus le C# que T-SQL. Je te parle de 10aines de milliers de code avec utilisation de la plupart des packages DBMS_xxx Oracle (pour lesquels il n'y a pas d'equivalents en T-SQL d'ou l'idee de refaire les equivalents en C# - T-SQL avec ses syntaxes barbares ca te fait devenir aveugle au bout d'une page de code avec tous les symboles cabalistiques du langage).
Je serai curieux de connaitres tes outils miraculeux; je pense que ca tient plus de l'anecdote qu'autre chose (ou alors c'est que tu ne connais que vaguement PL/SQL).
J'ai fais les 2 (Oracle depuis 1997 et SqlServer depuis plus de 2 ans).
Meme PostGreSql en fait un argument de portage depuis Oracle mais en pratique c'est du marketing car seule une infime partie des packages equivalents existent (solution PostGre qu'on a abandonné egalement).
Avatar de mattdef mattdef - Membre régulier https://www.developpez.com
le 10/10/2017 à 19:59
J'ai souvent eu à porter des procédures stockées et des fonctions d'Oracle vers SQL Server et comme je le disais, je n'ai jamais eu de gros souci avec ça.
Après je ne suis pas un expert Oracle et je n'ai peut être jamais eu à faire à des BDD complexes "progammaticalement" parlant.
Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.
Mais je me trompe peut-être...
Avatar de dfiad77pro dfiad77pro - Membre éprouvé https://www.developpez.com
le 10/10/2017 à 20:39
Bonne chance pour automatiser cela si les procs oracles utilisent des Types Tableaux avec des %TYPE %ROW (les références sur un type n'existent pas à ma connaissance sur SQL_SERVER ).

En tout cas sur les bases complexes, c'est pas si évident, notamment si tu utilise l'EBR (Edition multiple). Et ensuite faut se méfier des différences de plan d'exécution/optimiseur ... Bref nous on a une base avec 700 000 lignes de PL/SQL multi-éditionné, 50 schémas...

En effet on a énormément de métier dedans, c'est un choix de conception (y'a des gens qui militent pour ) :

Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.
Dans un service à la rigeur??
Pour moi l'embarquer dans le programme n'est pas toujours une bonne idée sauf dans les cas suivants :
- Pas de besoin d'aller retour entre la base et le clients
- Algo style tableur ou il est nécessaire de calculer à chaque saisie ( pour ensuite pousser le résultat vers la base)
- Tout autre algos ne nécessitant pas de base ( compression vidéo, hors ligne etc..)
Avatar de frfancha frfancha - Membre confirmé https://www.developpez.com
le 10/10/2017 à 21:19
Citation Envoyé par mattdef Voir le message
Pour moi, une bonne BDD, c'est le strict minimum de logique métier
Oui, ben alors pas du tout justement. Tout doit être dans la DB, cela permet d'attaquer la même logique d'où que ce soit.
Et s'il y a bien un truc qui est pérenne dans le temps c'est bien SQL, alors les techniques qui construisent les couches auour changent tous les 3 ans
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 10/10/2017 à 22:00
Pendant des années on a tout codé au plus pres de la BDD (parce que ca a du sens de vouloir centraliser le metier en 1 seul endroit, tirer partie des capacités des BDDs, tirer partie des performances du serveur, mise en cache des requetes, securité au travers procedures stockées etc.).

Depuis ces dernieres années et avec le nombre grandissant de dev C# qui ne voient la BDD que comme du simple stockage (enfin tous les nouveaux rentrés chez nous en tout cas), la conception s'est transformée en 'on met toute l'intelligence/metier' hors de la BDD dans du C# parce que c'est mieux pour les tests unitaires (coder des tests unitaires en PL/SQL c'est pas sexy...).

Conclusion (les WS et autres passent leur temps a lire/ecrire des volumes de données considerables pour les stocker/mapper dans des objets C# (representation memoire a l'identique des tables) - ils en sont arrivés au point de selectionner des volumes et tout faire les tris/filtres etc. localement sur le client.
Bref le boulot et l'intelligence se retrouve deplaces dans une couche WS et ce que fait habituellement la BDD (cache, controle intégrité, tri etc) est réalisée dans le code C#...
Bref pour la plupart des anciens, c'est un non sens (d'ailleurs on le voit au niveau des perfs/charges reseau c'est catastrophique - merci SOA).
La BDD est presque du luxe a ce niveau; de simples fichiers a plats seraient suffisants.

Je suis totalement d'accord avec dfiad77pro. C'est en fonction de ce qu'on veut faire qu'on stocke le code a tel ou tel endroit mais pour moi des qu'il y a du volume on laisse la BDD le faire localement (ca evite les A/R inutiles et couteux) et on ne recupere que le resultat.
Visiblement la logique actuelle (surement avec les clients javascripts qui prennent enormement d'importance), on met tout dans le client. A une autre epoque (qui reviendra c'est cyclique) c'etait on met tout sur le serveur.

D'ailleurs sur la remarque de l'interlocuteur precedent c'est tout a fait ce qu'on a vecu. Sur un gros projet nous avions un intégriste/gourou WPF/SL qui nous a vendu sa sauce comme jamais (une conception rigoureuse, l'etat de l'art au point ou il repassait derriere tout le monde pour refactorer le code...). Bref au bout de 6 ans et des platres essuyés en grande quantité, la techno retenue etant jugée obsolete sur nos nouveaux projets et de passer a des technos clients legers html5.
Quelle partie a pu etre recupérée telle qu'elle ? la BDD SQL + DAL. Quelle partie a du etre refaite entierement ? l'intelligence mise dans couche metier/ WS et les IHM => poubelle.

Donc effectivement depuis nous avons une vision bien differente de toutes nouvelles technos revolutionnaires qui au final ne font rien de mieux que les autres.
Avatar de mattdef mattdef - Membre régulier https://www.developpez.com
le 10/10/2017 à 22:08
Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 10/10/2017 à 22:18
Une requete SQL (CRUD) vers une BDD est l'equivalent d'une requete (WS) qu'on ferait vers un serveur web pour MAJ/inserer/supprimer/recuperer des données.
(On est juste une couche au dessus dans le cas des WS alors que la couche metier est plutot tres proche voir fusionnée avec le moteur BDD. Donc fondamentalement rien de revolutionnaire dans les WS).

quand tu codes un WS il fournit un service qui potentiellement peut etre utilisé a l'identique par beaucoup d'autres consommateurs (SOA).
Avec la BDD ca n'est pas different; juste pas les memes technos employées.
Avatar de martopioche martopioche - Membre confirmé https://www.developpez.com
le 11/10/2017 à 0:32
Citation Envoyé par kilroyFR Voir le message
Depuis ces dernieres années et avec le nombre grandissant de dev C# qui ne voient la BDD que comme du simple stockage (enfin tous les nouveaux rentrés chez nous en tout cas), la conception s'est transformée en 'on met toute l'intelligence/metier' hors de la BDD dans du C# parce que c'est mieux pour les tests unitaires (coder des tests unitaires en PL/SQL c'est pas sexy...).

Conclusion (les WS et autres passent leur temps a lire/ecrire des volumes de données considerables pour les stocker/mapper dans des objets C# (representation memoire a l'identique des tables) - ils en sont arrivés au point de selectionner des volumes et tout faire les tris/filtres etc. localement sur le client.
Bref le boulot et l'intelligence se retrouve deplaces dans une couche WS et ce que fait habituellement la BDD (cache, controle intégrité, tri etc) est réalisée dans le code C#...
Bref pour la plupart des anciens, c'est un non sens (d'ailleurs on le voit au niveau des perfs/charges reseau c'est catastrophique - merci SOA).
La BDD est presque du luxe a ce niveau; de simples fichiers a plats seraient suffisants.

ça y est, ça aussi fallait le copier de Java ? Oh désolé, mais en effet, ça fait plus de 10 ans que j'avais commencé à le voir là bas… Je dirai quand même que c'est révélateur d'une organisation où on se dit qu'un dev remplace un expert données/DBA, mais comme il ne connait rien aux bases de données, tout se fait dans le code…

Citation Envoyé par mattdef Voir le message
Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?
La première aberration que j'ai vu… En fait, non, la formulation exacte est "l'aberration que l'on voit en permanence" est l'absence d'une notion de base comme l'intégrité référentielle (les clauses ON DELETE par exemple). Ces directives doivent être dans la base car elles sont garantes de la cohérence des données.

On n'attaque peut être pas la même logique entre applis, mais les règles métier ne changent pas. Les cas où on a besoin d'utiliser la même logique, c'est lorsqu'on a des règles métier et des données structurées. Quand on ne sait pas ce que l'on fait et que les données sont sans importance, là…
Offres d'emploi IT
Développeur C# / .Net H/F
SidePulse - Ile de France - Paris
Architecte Logiciel WebMethods H/F
Michael Page - Nord Pas-de-Calais - Lille (59000)
DevOps conseiller de voyages - H/F
bluecoders - Ile de France - Paris (75011)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil