Si vous créez un réseau Microsoft .NET et que le backend exécute une base de données Oracle, vous devez alors migrer le backend vers SQL Server. Le cœur de cette question n’est pas de comparer les performances des bases de données mais de trouver l’outil qui vous convient le mieux. Pour répondre à ces deux questions sous l’architecture .NET, il n’y a qu’une seule réponse : .NET Server. Dans cet article, nous explorons d'abord pourquoi vous avez un serveur Oracle sur votre réseau, puis nous expliquons comment le migrer vers SQL Server et enfin expliquons les avantages et les inconvénients de cette décision.
Oracle dans votre système
Si vous disposez d'un serveur Oracle sur votre réseau, vous devez déterminer pourquoi vous en avez besoin : qui l'utilise, quelles applications l'utilisent, quelles applications s'exécutent dessus, etc.
Qui l'utilise ?
Vous devez d’abord savoir qui utilise le serveur Oracle. Sinon, se précipiter pour déplacer le serveur avant d’avoir une réponse risque de conduire à une grosse erreur. Bien sûr, si vous voulez vraiment faire cela, c'est un moyen rapide de trouver l'utilisateur de la base de données. Mais nous vous déconseillons tout de même de le faire.
Les administrateurs réseau peuvent avoir mis en place des procédures pour surveiller ou enregistrer l'utilisation d'Oracle. Les développeurs voudront peut-être utiliser les serveurs actuels pour développer des applications. Les responsables peuvent avoir besoin de générer des rapports analytiques basés sur les données stockées dans la base de données ou d'utiliser le backend Oracle pour prendre des décisions commerciales. Et les utilisateurs de la base de données peuvent se trouver partout dans le monde. Vous devez prendre en compte toutes ces possibilités lors de la détermination des utilisateurs qui seront concernés par le processus de migration d'Oracle vers SQL Server.
Quelles applications l’utiliseront ?
Supposons maintenant que vous demandiez à tous les utilisateurs, un par un, de savoir qui utilise Oracle ? Et leur réponse est exactement non, vous devez alors vérifier le fichier journal pour comprendre quels postes de travail accèdent à la base de données. Lorsque vous vérifiez ces fichiers journaux, vous constaterez peut-être que non seulement le poste de travail accède à la base de données, mais que d'autres serveurs accèdent également à la base de données.
D'accord, prenez un stylo et notez les serveurs qui accèdent à la base de données, puis découvrez à partir de quelles applications spécifiques ces serveurs accèdent à la base de données. Ces applications peuvent être identifiées en comparant les données stockées dans la table de données avec les applications exécutées sur le serveur.
Quelles applications s'exécutent sur le serveur Oracle ?
Maintenant que vous connaissez les utilisateurs et les applications externes qui accèdent à la base de données, vous devez maintenant savoir quelles applications s'exécutent sur le serveur de base de données lui-même. Ces applications peuvent être des procédures stockées dans une base de données (et les déclencheurs correspondants, les types de données personnalisés, les paramètres de sécurité, etc.) ou il peut s'agir d'applications indépendantes qui ne s'exécutent pas dans Oracle. Vous devez particulièrement prêter attention aux outils de développement Oracle ajoutés au serveur.
Migration vers SQL Server
Vous ne devriez jamais être tenté de débrancher immédiatement votre serveur Oracle et d'installer SQL Server. Vous devez réfléchir à deux fois avant de migrer des serveurs critiques. Pourquoi ce processus est-il spécifiquement nommé migration ? Et ce n’est pas parce que la migration ne se produit pas toujours soudainement. Si vous prenez quelques mesures simples et raisonnables, le processus de migration peut se dérouler sans aucun obstacle.
Pour migrer des applications versdes applications natives et des applications externes,
procédez comme suit :
1. Installez un nouveau serveur SQL sur le réseau.
2. Créez les "périphériques" et les tables de données utilisés par l'application.
3. Interdisez à l'application d'accéder à la base de données et mettez l'application hors ligne.
4. Copiez les données actuelles d'Oracle vers SQL Server.
5. Pointez toutes les applications vers la nouvelle base de données.
6. Autorisez les applications à accéder à de nouvelles données dans les tables de données et les appareils.
Il existe un problème fatal lorsqu'onenvisage de migrer SQL
entre SQL Server et Oracle : ils parlent deux dialectes SQL différents, SQL-PL/SQL (Oracle) et Transact-SQL (Microsoft).
Dans la plupart des cas, si vous pouvez utiliser un langage SQL, vous pouvez probablement utiliser l'autre langage SQL. En tenant compte des fonctions, opérateurs, instructions SQL, etc., j'ai spécialement compilé une référence du programmeur SQL. Ces informations montrent les fonctionnalités prises en charge par divers SGBD. Bien sûr, si ces fournisseurs américains de produits SQL respectent honnêtement le standard américain SQL (ANSI-SQL), pourquoi y aurait-il un si gros problème !
De plus, vous pouvez également rencontrer les problèmes suivants :
Table double d'Oracle - sur SQL Server, vous pouvez rencontrer des instructions telles que select 'x';. Sur Oracle, cette instruction doit être convertie en select 'x' from dual;. dual est une table système générée par Oracle. Outre ce problème de syntaxe SQL, vous ne pouvez pas copier cette table sur votre serveur SQL car il s'agit d'une table système Oracle.
Troncature : les deux SGBD prennent en charge les fonctions FLOOR et ROUND, mais Oracle dispose également d'une fonction TRUNC supplémentaire. Si votre système Oracle utilise la fonction TRUNC, vous devrez rééditer les parties impliquées - vous devrez peut-être penser à la remplacer par la fonction FLOOE ou ROUND.
Concaténation-SQL Server 7 ne prend pas en charge la méthode de connexion ANSI ||, contrairement à SQL Server 2000. Les deux bases de données utilisent désormais le signe plus (+) pour représenter les connexions, mais il est préférable d'utiliser ce symbole pour les opérations arithmétiques !
Cela dépend des versions spécifiques des deux serveurs que vous utilisez. Les problèmes de migration du langage SQL apparaîtront presque toujours de manière soudaine et inattendue.
L'analyse de rentabilité en faveur de l'abandon d'Oracle
Cette migration de base de données n'est pas un simple jeu émotionnel, et le choix des produits Microsoft plutôt qu'Oracle est soutenu par l'analyse de rentabilisation. Oracle a consacré des ressources considérables pour vaincre Microsoft devant les tribunaux et dans les batailles de propagande. Cependant, d'un point de vue économique, Oracle n'est pas plus rentable. De plus, Oracle n'a qu'un seul produit de base, ce qui est encore moins confiant que Microsoft. En plus du processus de vente compliqué, vous feriez mieux de trouver une entreprise plus impressionnante pour vous accompagner. L'entreprise doit être saine et prospère, et ses produits doivent être généralement populaires. Elle doit garantir que l'entreprise soit très forte pendant au moins quelques années avant de rencontrer des adversaires plus puissants.
Que pouvez-vous gagner en migrant vers SQL Server ?
Tout d’abord, vous obtenez un système hautement cohérent avec votre architecture réseau. Vous n'avez pas besoin d'une personne dédiée pour gérer votre système UNIX. Les outils de gestion adaptés aux SGBD fonctionnent de manière optimale avec ces outils de système d'exploitation réseau.
Deuxièmement, le système implémente la prise en charge intégrée des applications .NET. L'architecture .NET ne nécessite pas l'utilisation de SQL Server, mais ce serveur est la base de données par défaut. Les pilotes ODBC pour Oracle sont certes bons, mais ils constituent toujours un point de défaillance possible.
Troisièmement, le coût de l'utilisation d'Oracle sur le réseau .NET est plus élevé que celui de l'utilisation de SQL Server. Vous pouvez bénéficier de réductions lorsque vous achetez davantage de licences de serveur Win2K ainsi que des licences VS.NET et Office.
Enfin, même si vous achetez un système SQL Server séparément, il peut être moins cher qu'Oracle. De nos jours, marchander une licence Oracle peut donner l’impression de s’arracher les dents. Je me souviens avoir demandé le prix à un représentant commercial et il m'a en fait répondu : « Pouvez-vous vous le permettre ? »
Résumé
Si vous construisez un réseau .NET, il est logique d'utiliser SQL Server comme SGBD car il s'agit de Microsoft .NET. la suite d'applications serveur. La migration d'une plateforme à une autre est un processus important qui doit être soigneusement réfléchi et planifié. Avant de changer de plate-forme, vous devez disposer d’une base .NET unifiée, efficace, facile à gérer et fiable.