¿Cuáles son las razones para seguir utilizando SQL Server 2000?

De las preguntas sobre StackOverflow y en otros lugares, noté que todavía hay personas que usan SQL Server 2000. Para ser sincero, el mayor efecto en mí es que tengo que recordar cómo solíamos hacer las cosas sin expresiones de tabla comunes.

Aún así, me gustaría saber si hay razones reales (más allá de "no está roto") para seguir usando SQL Server 2000. Por ejemplo, sé que hay personas que tienen que usar .NET 1.1 porque tienen que soportar Sistemas Windows 2000. ¿Hay alguna razón práctica similar para no actualizar un sistema SQL Server 2000 a SQL Server 2008 o 2005?

La mente empresarial suele ser muy diferente a la tuya. ¿Por qué usar algo más nuevo si no generará más ingresos, sino solo gastos (migración, reciclaje, etc.)?

La mejor razón por la que puedo pensar es una variación de "no está roto" que dice así: tiene una aplicación comercial que funciona con SQL 2000 pero genera errores con SQL 2005. Puede que no sea la prioridad comercial correcta para su organización en este momento para abrir el capó de esa aplicación (que no está roto) y hacer que funcione con una base de datos más nueva.

Soporte heredado

SQL Server 2005 no es totalmente compatible con SQL Server 2000. Analysis Services tiene grandes incompatibilidades. Mudarse a SQL Server 2005 tiene un costo distinto de cero por las pruebas de regresión y la transferencia. Muchas organizaciones no tienen el requisito de mudarse, por lo que no se mudarán hasta que tengan que hacerlo.

La mayoría de los proveedores de DBMS (MS incluido) admitirán una versión de un DBMS durante aproximadamente 10 años, que es más larga que la mayoría de los otros tipos de software. Si cruzas sus palmas con plata (en cantidad suficiente), también firmarán contratos específicos para extender el soporte en una versión específica por más tiempo.

Otras razones para seguir con las versiones anteriores están realmente motivadas por circunstancias específicas, como evitar una versión fallida conocida (por ejemplo, MySQL 5.1 o SQL2000 anterior a SP3) o problemas de certificación o compatibilidad.

Mantener una base de datos de producción de SQL Server 2000

Para un sistema operativo que funciona y se encuentra en una fase madura de su ciclo de vida sin muchos cambios importantes, probablemente no haya una razón convincente para actualizar antes de que el DBMS deje de ser compatible. Sin embargo, debe planificar una ruta de actualización ordenada para esa eventualidad. Oracle es bastante conocido por las personas que mantienen sistemas de producción en versiones antiguas.

SQL Server 2000 se está acercando a su fin de vida, por lo que no querrá realizar nuevos trabajos de desarrollo en él. Sin embargo, una aplicación de producción debe mantenerse con un plan para salir cuando sea necesario. Probablemente tendrá una reescritura en sus manos si su aplicación está escrita en VB6 o ASP clásico, pero ese es un problema diferente; -}.

El caso contrario

Si tuviera un proyecto totalmente nuevo, normalmente recomendaría la última versión de la plataforma DBMS simplemente porque le brinda la ventana más larga de soporte de proveedores. Nadie debería tener SQL Server 2000 como estándar corporativo para nuevos proyectos: la EOL está demasiado cerca. Para un nuevo proyecto, este es, con mucho, el argumento más fuerte para pasar a una versión más nueva. Los argumentos sobre el ahorro de dinero no retienen el agua; la aplicación incurrirá en costos de portabilidad innecesarios dentro de un par de años si comienza a usar SQL2000 ahora.

El punto clave para el trabajo de campo nuevo es que una selección demasiado conservadora acorta la vida útil de la aplicación antes de que se requiera una actualización. Normalmente, se querría una razón específica para no utilizar la versión actual de una plataforma DBMS.

No actualizamos porque tenemos un software financiero que se basa en él, y el proveedor solo está pensando en apoyar este nuevo "SQL 2005" del que han estado escuchando el blog de niños locos últimamente.

Francamente, me duele mi tener una mezcla de cosas que mantener, pero no casi tanto como lo haría daño a todos en la empresa a tener un problema con el sistema de financiación de pop-up, y luego tener el punto proveedor de software de finanzas en nosotros y reímos cuando pedimos ayuda y mencionamos que los problemas comenzaron desde que actualizamos a SQL 2005 antes de que lo ratificaran.

También hay mucho que decir para no arreglar las cosas si en realidad no están rotas. Quiero actualizar todos mis servidores SQL a 2008 en algún momento ... Realmente lo hago. Pero hay muchas más cosas que podría estar haciendo que realmente mejoren el resultado final del negocio de maneras que sean comprensibles y cuantificables para mis gerentes y usuarios ... bueno, eso siempre será lo primero.

Usted menciona a los desarrolladores que no les gusta trabajar con SQL 2000 en su respuesta a la respuesta de Mastermind. Sospecho que un método para lidiar con eso sería el que usarían mis jefes si decidiera que "no me gusta" admitir SQL 2000: "Gracias por su tiempo trabajando aquí, la puerta está a su izquierda". Al final del día, a todos nos pagan para que las cosas funcionen, nos guste o no.

En nuestro caso, no se trata tanto de "por qué seguir usando 2000" como de "la actualización cuesta ¿CUÁNTO?". La mayoría de nuestras aplicaciones no usan nada que necesite características específicas de 2005, por lo que no hay una razón convincente, y probablemente no lo será hasta que Microsoft deje de admitirlo.

Costo.

El software más nuevo sigue siendo un software adicional, que cuesta dinero adicional.

Esto puede ser, y a menudo es, una economía falsa debido a los muchos inconvenientes del uso de sistemas obsoletos, pero es la única razón real que tiene sentido.

La nueva licencia para SQL Server 2008 (estándar) cuesta un poco menos de $ 2,000 por 1 servidor con 5 CAL o $ 6,000 por 1 licencia de CPU. Puedo escuchar a mi antiguo jefe decir "no está roto, pero ¿costará cuánto actualizar esos 2 servidores?" (en ese momento 2 x CPU dual que requieren licencias de CPU).

Después de haber usado SQL2000 durante siete años, mi primera experiencia de 2005 fue en un entorno VMWare ESX. El rendimiento apestaba (el ISP estaba proporcionando la experiencia VMWare y cuando comenzamos las pruebas de carga descubrimos que estaban teniendo problemas importantes no solo con nuestro servidor, sino que también afectaron nuestra experiencia), y se combinaron con todo lo que se movió / cambió de nombre (el antiguo gerente de la empresa era muuuy mucho más rápido): estábamos más contentos de posponer la actualización. Entonces estábamos esperando el lanzamiento de 2008, por lo que solo estamos actualizando a 2008 (o migrando algunos datos a MySQL / PostgresSQL).

Microsoft seguía brindando soporte general para el año 2000 hasta algún momento del año pasado, por lo que solo recientemente hemos tenido una razón más convincente para actualizar.

Las pequeñas empresas también tienen un problema de recursos: aprender, planificar, probar la actualización lleva tiempo e impacta en otras operaciones. Si tiene que actualizar alguna otra aplicación que se encuentra en SQL Server al mismo tiempo, esto también puede ser muy costoso.

Por un tiempo, coqueteamos con el cambio a código abierto, y aunque eso era una posibilidad, también congelaba cualquier actualización.

¿Por qué no actualizar a sql server 2008, entonces en realidad puede reducir su costo, debido a la compresión de datos, un mantenimiento más fácil y un rendimiento mejorado (índices filtrados)? Recientemente actualizamos una instalación de SQL Server 2000 y ahorramos el 75% del espacio en disco, y el rendimiento aumentó dramáticamente.

Otra mejora fue la concurrencia debido al nuevo mecanismo de bloqueo introducido en SQL Server 2005.

/ Håkan Winther

Las grandes organizaciones son riesgosas e ignorantes, lo que lleva a tomar decisiones realmente tontas. Cuando estaba haciendo cosas de Unix alrededor de 2003/2004, nos quedamos atrapados con un entorno Solaris 2.5.1 que se lanzó cuando estaba en décimo grado más o menos porque era tecnología "probada" y era "demasiado caro" para actualizar.

Demasiado caro es a menudo hablar de PHB para "Fui tonto al presupuesto para una actualización de $ 1000 en un proyecto de $ 10M".

En el caso del software de pila de Microsoft, las personas a menudo son adversas a la actualización porque no querían lidiar con el troll de licencias dentro de la compañía y compraron una licencia OEM de Dell / IBM / etc., y no tienen ganas de lidiar con el aros burocráticos involucrados en la actualización.

No compro (juego de palabras) el argumento del "costo inicial", pero desafortunadamente el costo inicial es algo con lo que muchos PHB se obsesionan, por lo que es válido dejarlo en pie.

Para mí, la única razón convincente serían las aplicaciones que lo usan. Si usted es una casa de SharePoint 2003, por ejemplo, NO HAY MANERA de que vaya a actualizar a SQL 2005 o 2008 sin también realizar una actualización de SharePoint, lo cual no es un asunto trivial.

En nuestra organización, se supone que todo el nuevo desarrollo se realizará en SQL 2005/2008, pero tenemos tantas aplicaciones heredadas de 2000, que no vale la pena el tiempo / energía / dinero para convertirlas a todas.

Además de los problemas de compatibilidad (DTS a SSIS es el más importante para nosotros), también implementamos un conjunto de pautas / restricciones de seguridad en SQL 2005 que no habíamos aplicado para SQL 2000. (sin usuarios de dbo, solo permisos de esquema, etc.)

En nuestra organización, hay varias razones. Algunos son bastante específicos para nuestro caso, y otros un poco más genéricos.

1) Incompatibilidades. Hemos tenido algunos casos en los que el software que se escribió internamente para SQL2005 tiene problemas al instalar en SQL2000. El caso que vi más recientemente terminó debido a que los parámetros se declararon explícitamente que no existen en 2000, y a una diferencia en el nombre de la tabla de índice del sistema. (sys.indexes vs sysindexes)

2) Entrenamiento. Nuestros desarrolladores ciertamente conocen 2005, y preferirían estar desarrollando en él, o 2008 ya. Sin embargo, el trabajo de mantener todo operativo depende del NOC, no de los desarrolladores. Nadie en nuestro NOC ha recibido capacitación formal en SQL, y las diferencias entre los dos, solo desde el punto de vista de la herramienta administrativa, son suficientes para tener esto en cuenta.

3) Costo de actualizar productos existentes. Para nosotros, este es uno grande. No estoy hablando del costo de la licencia de Microsoft aquí. En nuestro negocio, una actualización de cualquiera de nuestros productos existentes (incluso si no actualizamos retroactivamente todo lo que ya está en el campo) requeriría un proceso de recertificación costoso y prolongado a través de varios laboratorios de prueba reguladores y de certificación diferentes. Estamos creando nuevos productos en SQL2005, pero no estamos actualizando los anteriores por este motivo.

El proceso de certificación también significa que terminaríamos con una mezcla de nuevas compilaciones, donde ciertas jurisdicciones obtendrían SQL2000 y otras obtendrían SQL2005, en función de si las aprobaciones se hubieran recibido o no. Preferimos, por la razón # 2, mantener nuestro entorno de producción lo más consistente posible.

4) Diferencias generales. Esta es realmente una extensión del # 1. Hay muchas pequeñas cosas que cambiaron, algunas de las cuales nos causan dolores de cabeza. Ejemplo, SQL2005 en Server2003 impondrá políticas de contraseña de Windows en cuentas sql. No es algo malo en sí mismo, pero rompe casi todo nuestro software (y mucho de terceros) debido a la forma en que interactuamos con la base de datos.

En resumen, la inercia.

Una buena publicación de blog que ya hizo la misma pregunta.

Sé que hay personas que tienen que usar .NET 1.1 porque tienen que admitir sistemas Windows 2000.

Siguiendo esa lógica, una razón práctica para ejecutar MSSQL 2000 es porque puede admitir sistemas Windows NT 4.

Lo creas o no, pero SQL Server 2005 realmente se ejecuta en Windows Server 2000.