Quelles sont les raisons d'utiliser toujours SQL Server 2000?

D'après les questions sur StackOverflow et ailleurs, je remarque qu'il y a encore des gens qui utilisent SQL Server 2000. Pour être honnête, le plus grand effet sur moi est que je dois me rappeler comment nous faisions les choses sans Common Table Expressions.

Néanmoins, j'aimerais savoir s'il existe des raisons réelles (au-delà de "ce n'est pas cassé") de continuer à utiliser SQL Server 2000. Par exemple, je sais qu'il y a des gens qui doivent utiliser .NET 1.1 parce qu'ils doivent prendre en charge Systèmes Windows 2000. Existe-t-il des raisons pratiques similaires de ne pas mettre à niveau un système SQL Server 2000 vers SQL Server 2008 ou 2005?

L'esprit d'entreprise est généralement très différent du vôtre. Pourquoi utiliser quelque chose de plus récent s'il ne génère pas plus de revenus, mais seulement des dépenses (migration, recyclage, etc.)?

La meilleure raison pour laquelle je peux penser est une variation de "ce n'est pas cassé" qui se présente comme ceci: Vous avez une application métier qui fonctionne avec SQL 2000 mais génère des erreurs avec SQL 2005. Ce n'est peut-être pas la bonne priorité commerciale pour votre organisation en ce moment pour ouvrir le capot sur cette application (qui n'est pas cassée) et la faire fonctionner avec une base de données plus récente.

Prise en charge héritée

SQL Server 2005 n'est pas totalement rétrocompatible avec SQL Server 2000. Analysis Services présente des incompatibilités majeures. Le passage à SQL Server 2005 a un coût non nul pour les tests de régression et le portage. De nombreuses organisations ne sont pas obligées de déménager, donc elles ne bougeront pas avant de le faire.

La plupart des fournisseurs de SGBD (MS inclus) prendront en charge une version d'un SGBD pendant environ 10 ans, ce qui est plus long que la plupart des autres types de logiciels. Si vous croisez leurs paumes avec de l'argent (en quantité suffisante), ils concluront également des contrats spécifiques pour étendre le support sur une version spécifique plus longtemps que cela.

D'autres raisons de rester avec des versions plus anciennes sont vraiment motivées par des circonstances spécifiques telles que l'évitement d'une version bâclée connue (par exemple MySQL 5.1 ou pré-SP3 SQL2000) ou des problèmes de certification ou de compatibilité.

Maintenance d'une base de données de production SQL Server 2000

Pour un système opérationnel qui fonctionne et se trouve dans une phase mature de son cycle de vie sans beaucoup de changements majeurs en cours, il n'y a probablement aucune raison impérieuse de procéder à une mise à niveau avant que le SGBD ne se retire du support principal. Cependant, vous devez planifier un chemin de mise à niveau ordonné pour cette éventualité. Oracle est assez réputé pour les personnes qui maintiennent des systèmes de production sur des versions anciennes.

SQL Server 2000 approche de sa fin de vie, vous ne voudriez donc pas y faire de nouveaux travaux de développement. Cependant, une application de production doit être maintenue avec un plan de départ lorsque vous en avez besoin. Vous aurez probablement une réécriture sur les mains si votre application est écrite en VB6 ou ASP classique - mais c'est un problème différent; -}.

Le contre-étui

Si j'avais un projet entièrement nouveau, je recommanderais généralement la dernière version de la plate-forme SGBD simplement parce qu'elle vous offre la plus longue fenêtre de support des fournisseurs. Personne ne devrait toujours avoir SQL Server 2000 comme standard d'entreprise pour les nouveaux projets - la fin de vie est trop proche. Pour un nouveau projet, c'est de loin l'argument le plus fort pour passer à une version plus récente. Les arguments pour économiser de l'argent ne tiennent pas la route; l'application entraînera des frais de portage inutiles dans quelques années si vous commencez maintenant sur SQL2000.

Le point clé pour les travaux nouveaux est qu'une sélection trop conservatrice raccourcit la durée de vie de l'application avant qu'une mise à niveau ne soit requise. On voudrait normalement une raison spécifique pour ne pas opter pour la version actuelle d'une plate-forme SGBD.

Nous ne faisons pas de mise à niveau parce que nous avons un logiciel financier qui en dépend, et le vendeur ne pense qu'à prendre en charge ce nouveau "SQL 2005" dont il a récemment entendu parler le blog des enfants fous.

Franchement, cela me fait mal d'avoir un mélange de choses à supporter, mais pas autant que cela nuirait à tout le monde dans l'entreprise d'avoir un problème avec le système financier, et ensuite d'avoir le fournisseur de logiciels de finance pointé sur nous et rire lorsque nous avons demandé de l'aide et mentionné que les problèmes ont commencé depuis la mise à niveau vers SQL 2005 avant qu'ils ne l'aient ratifié.

Il y a aussi beaucoup à dire pour ne pas réparer les choses si elles ne sont pas réellement cassées. Je veux mettre à niveau tous mes serveurs SQL vers 2008 à un moment donné ... vraiment. Mais il y a tellement plus de choses que je pourrais faire qui améliorent réellement le résultat net de l'entreprise de manière compréhensible et quantifiable pour mes gestionnaires et les utilisateurs ... eh bien, cela va toujours venir en premier.

Vous mentionnez que les développeurs n'aiment pas travailler avec SQL 2000 dans votre réponse à la réponse de Mastermind. Je soupçonne qu'une méthode pour y faire face serait celle que mes patrons utiliseraient si je décidais que je "n'aimais pas" la prise en charge de SQL 2000: "Merci pour votre temps de travail ici, la porte est à gauche". À la fin de la journée, nous sommes tous payés pour faire fonctionner les choses, que cela nous plaise ou non.

Dans notre cas, il s'agit moins de «pourquoi continuer à utiliser 2000» que de «la mise à niveau coûte combien?». La plupart de nos applications n'utilisent rien qui nécessite des fonctionnalités spécifiques à 2005, il n'y a donc aucune raison impérieuse, et cela ne le sera probablement pas tant que Microsoft n'aura plus pris en charge cette fonctionnalité.

Coût.

Un logiciel plus récent est toujours un logiciel supplémentaire, ce qui coûte de l'argent supplémentaire.

Cela peut être, et est souvent, une fausse économie en raison des nombreux inconvénients de l'utilisation de systèmes obsolètes, mais c'est la seule vraie raison qui ait du sens.

La nouvelle licence pour SQL Server 2008 (standard) coûte un peu moins de 2 000 $ pour 1 serveur avec 5 licences CAL ou 6 000 $ pour 1 licence CPU. J'entends mon ancien patron dire "ce n'est pas cassé, mais ça va coûter combien pour mettre à niveau ces 2 serveurs?" (à ce moment-là 2 x double CPU nécessitant des licences CPU).

Ayant utilisé SQL2000 pendant sept ans, ma première expérience de 2005 a été dans un environnement VMWare ESX. Les performances étaient nulles (le FAI fournissait l'expertise VMWare et lorsque nous avons commencé les tests de charge, nous avons constaté qu'ils rencontraient des problèmes majeurs non seulement avec notre serveur mais avaient un impact sur notre expérience), et combinés avec tout ce qui était déplacé / renommé (l'ancien gestionnaire d'entreprise était tellement ... beaucoup plus rapide) - nous étions plus heureux de reporter la mise à niveau. Ensuite, nous attendions la sortie de 2008, donc nous ne faisons que passer à 2008 (ou migrer certaines données vers MySQL / PostgresSQL).

Microsoft offrait toujours un support général pour 2000 jusqu'à un certain temps l'année dernière, donc ce n'est que récemment que nous avons eu une raison plus convaincante de mettre à niveau.

Les petites entreprises ont également un problème de ressources - apprendre, planifier, tester la mise à niveau prend du temps et a un impact sur d'autres opérations. Si vous devez mettre à niveau une autre application qui se trouve sur SQL Server en même temps, cela peut aussi devenir très coûteux.

Pendant un certain temps, nous avons flirté avec le passage à l'open-source, et même si c'était une possibilité, cela a également mis un frein à toute mise à niveau.

Pourquoi ne pas mettre à niveau vers SQL Server 2008, alors vous pouvez réellement réduire vos coûts, grâce à la compression de données, à une maintenance plus facile et à des performances améliorées (index filtrés)? Récemment, nous avons mis à niveau une installation SQL Server 2000 et économisé 75% de l'espace disque, et les performances ont considérablement augmenté.

Une autre amélioration a été la concurrence en raison du nouveau mécanisme de verrouillage introduit dans le serveur SQL 2005.

/ Håkan Winther

Les grandes organisations sont hostiles au risque et ignorantes, ce qui conduit à des décisions vraiment stupides. Quand je faisais des trucs Unix vers 2003/2004, nous étions coincés avec un environnement Solaris 2.5.1 qui était sorti quand j'étais en 10e année, car c'était une technologie "éprouvée" et sa mise à niveau était "trop ​​chère".

Trop cher, c'est souvent PHB-parler pour "J'étais stupide de budget pour une mise à niveau de 1000 $ dans un projet de 10 M $".

Dans le cas du logiciel de pile Microsoft, les gens sont souvent défavorables à la mise à niveau car ils ne voulaient pas traiter avec le troll des licences au sein de l'entreprise et ont acheté une licence OEM de Dell / IBM / etc, et n'ont pas envie de traiter avec le cerceaux bureaucratiques impliqués dans la mise à niveau.

Je n'achète pas (jeu de mots voulu) l'argument "coût initial", mais malheureusement, le coût initial est quelque chose que beaucoup de PHB obsèdent donc il est valide de le laisser tenir.

Pour moi, la seule raison impérieuse serait les applications qui l'utilisent. Si vous êtes une maison SharePoint 2003, par exemple, vous ne pourrez PAS passer à SQL 2005 ou 2008 sans entreprendre également une mise à niveau SharePoint, ce qui n'est pas anodin.

Dans notre organisation, tous les nouveaux développements sont censés être sur SQL 2005/2008, mais nous avons tellement d'applications héritées 2000, cela ne vaut tout simplement pas le temps / l'énergie / l'argent pour les convertir toutes.

Outre les problèmes de compatibilité (DTS vers SSIS est le plus important pour nous), nous avons également mis en œuvre un ensemble de directives / restrictions de sécurité sur SQL 2005 que nous n'avions pas appliquées pour SQL 2000. (pas d'utilisateurs dbo, autorisations de schéma uniquement, etc.)

Dans notre organisation, il y a plusieurs raisons. Certains sont assez spécifiques à notre cas, et d'autres un peu plus génériques.

1) Incompatibilités. Nous avons eu quelques cas où des logiciels écrits en interne pour SQL2005 rencontraient des problèmes lors de l'installation sur SQL2000. Le cas que j'ai vu le plus récemment a fini par être dû à des paramètres explicitement déclarés qui n'existent pas en 2000 et à une différence dans le nom de la table d'index du système. (sys.indexes vs sysindexes)

2) Formation. Nos développeurs connaissent certainement 2005, et préféreraient développer dessus, ou 2008 déjà. Cependant, le travail de garder tout opérationnel incombe au CNO, pas aux développeurs. Personne dans notre CNO n'a reçu de formation SQL formelle, et les différences entre les deux, juste du point de vue de l'outil administratif, sont suffisantes pour en faire une considération.

3) Coût de mise à niveau des produits existants. Pour nous, c'est un gros problème. Je ne parle pas du coût de la licence de Microsoft ici. Dans notre entreprise, une mise à niveau de l'un de nos produits existants (même si nous n'avons pas mis à niveau rétroactivement tout ce qui existe déjà sur le terrain) nécessiterait un processus de recertification coûteux et long à travers plusieurs laboratoires de test de réglementation et de certification différents. Nous construisons de nouveaux produits sur SQL2005, mais ne mettons pas à niveau les anciens pour cette raison.

Le processus de certification signifie également que nous nous retrouverions avec un mélange de nouvelles versions, où certaines juridictions obtiendraient SQL2000 et d'autres obtiendraient SQL2005, selon que les approbations avaient été reçues ou non. Nous préférons, pour la raison n ° 2, garder notre environnement de production aussi cohérent que possible.

4) Différences générales. C'est vraiment une extension de # 1. Il y a beaucoup de petites choses qui ont changé, dont certaines nous causent des maux de tête. Par exemple, SQL2005 sur Server2003 appliquera les stratégies de mot de passe Windows sur les comptes SQL. Ce n'est pas une mauvaise chose en soi, mais il casse presque tous nos logiciels (et beaucoup de tiers) en raison de la façon dont nous interagissons avec la base de données.

Bref, l'inertie.

Un bon article de blog qui posait déjà la même question.

Je sais que certaines personnes doivent utiliser .NET 1.1 car elles doivent prendre en charge les systèmes Windows 2000.

Suivant cette logique, une raison pratique d'exécuter MSSQL 2000 est que vous pouvez prendre en charge les systèmes Windows NT 4!

Croyez-le ou non, mais SQL Server 2005 fonctionne en fait sur Windows Server 2000.