Ha habido cierta controversia en curso en la comunidad de SQL Server acerca de la conveniencia de instalar Service Packs (SP) y actualizaciones acumulativas (CU) para SQL Server. Hay varias posiciones básicas diferentes que las organizaciones suelen adoptar sobre este tema, como se indica a continuación:
- La organización instala Service Packs y actualizaciones acumulativas de forma periódica
- La organización instala Service Packs, pero no instala actualizaciones acumulativas
- La organización no instala Service Packs ni actualizaciones acumulativas
El primer caso es una organización que intentará mantenerse razonablemente al día con los Service Packs de SQL Server y las Actualizaciones acumulativas de SQL Server mediante un procedimiento exhaustivo de prueba e implementación. Esta es la mejor política en mi opinión. Mi posición es que su organización está mucho mejor si se mantiene al día con los Service Packs y las Actualizaciones acumulativas (siempre y cuando tenga los procedimientos de prueba e implementación y la infraestructura necesaria para respaldar esa política).
El segundo caso es una organización que (quizás después de cierto retraso) instalará SQL Server Service Packs, pero no instalará actualizaciones acumulativas de SQL Server por ningún motivo. Esto no es tan bueno como el primer caso, pero es mucho mejor que el tercer caso.
En el tercer caso, algunas organizaciones nunca instalan ningún Service Pack de SQL Server ni actualizaciones acumulativas de SQL Server, por ningún motivo. En algunos casos, en realidad permanecen en la compilación original de lanzamiento a fabricación (RTM) de la versión principal de SQL Server que están ejecutando, durante la vida útil de la instancia. Esta es la política menos deseable, por varias razones.
Microsoft tiene una política de retirar ramas de código (ya sea la rama RTM o una rama de Service Pack posterior) para una versión particular de SQL Server cuando tiene dos ramas de antigüedad. Por ejemplo, cuando se lanzó SQL Server 2008 R2 Service Pack 2, la rama RTM original (independientemente del nivel de CU) se retiró y se convirtió en un "paquete de servicio no compatible". Esto significa que no habrá más revisiones ni actualizaciones acumulativas para esa rama, y que solo obtendrá asistencia limitada para la resolución de problemas de Microsoft CSS durante un caso de asistencia hasta que instale un paquete de servicio compatible en su instancia.
Razones por las que se aplaza el mantenimiento de SQL Server
En algunos casos, es posible que una organización no esté al tanto de cómo SQL Server se mantiene normalmente con una combinación de Service Packs, actualizaciones acumulativas y revisiones. Muchas organizaciones tienen políticas rígidas y de arriba hacia abajo sobre cómo mantienen y dan servicio a productos como SQL Server, lo que impide la instalación regular de SP y/o CU por parte de los administradores de bases de datos. También es posible que no puedan prestar servicio a sus instancias de SQL Server por el hecho de que están utilizando bases de datos de terceros que solo son compatibles con proveedores con ciertas versiones especificadas por el proveedor y niveles de Service Pack de SQL Server.
Muchas organizaciones también tienen un temor comprensible de "romper" una instancia de SQL Server o una aplicación que dependa de esa instancia. También pueden carecer del tiempo y los recursos para realizar un nivel adecuado de pruebas de aplicaciones y sistemas después de instalar una versión actualizada de SQL Server en una instancia en un entorno de prueba. En algunos casos, es posible que no tengan un entorno de prueba dedicado (que es un problema importante aparte).
Es posible que algunas organizaciones no cuenten con una solución de alta disponibilidad en funcionamiento (como el clúster de conmutación por error tradicional, la creación de reflejo de la base de datos o los grupos de disponibilidad) en su entorno de producción, por lo que dudan mucho más en realizar cualquier tipo de servicio que posiblemente cause un servidor de base de datos se reinicia y provoca una interrupción relativamente larga. En realidad, pueden tener una solución de alta disponibilidad, pero rara vez la prueban con una conmutación por error de producción, y pueden tener menos confianza en su funcionamiento y confiabilidad.
Razones para mantener SQL Server con regularidad
Después de enumerar algunas de las razones comunes por las que las organizaciones pueden optar por no dar servicio a SQL Server con regularidad, es hora de abordar algunos de estos argumentos. En primer lugar, la ignorancia acerca de cómo Microsoft suele dar servicio a SQL Server ya no es realmente una excusa válida. Microsoft tiene un blog de servicios de lanzamiento de SQL, donde anuncian los paquetes de servicio y las actualizaciones acumulativas para SQL Server. Matthias Bernt explicó la estrategia de servicio general para SQL Server en su publicación:Un enfoque modificado para los Service Packs, con más detalles sobre el enfoque del modelo de servicio incremental de SQL Server disponible en este artículo de la base de conocimientos de Micosoft.
La versión resumida del modelo de servicio es que los problemas individuales de SQL Server se corrigen con revisiones. Debe ponerse en contacto con Microsoft CSS y abrir un caso de soporte para obtener acceso a una revisión individual (a menos que sea una revisión relacionada con la seguridad, que Microsoft Update elimina). Dependiendo de su nivel de soporte pagado con Microsoft, este puede ser un proceso relativamente tedioso y lento. También existe el problema de que es muy poco probable que la mayoría de los clientes de SQL Server estén al tanto de las revisiones existentes que no se han publicado como parte de una actualización acumulativa de SQL Server. Esto significa que es poco probable que la mayoría de los clientes obtengan e implementen revisiones individuales de manera regular.
Las actualizaciones acumulativas son resúmenes de una serie de revisiones (por lo general, entre 10 y 50 revisiones) que se publican cada ocho semanas. Estas actualizaciones acumulativas son en realidad acumulativas (como su nombre lo indica), por lo que obtendrá todas las revisiones publicadas anteriormente para su versión y rama (RTM, SP1, SP2, etc.) del código cuando instale una actualización acumulativa. Esto significa que la afirmación común sobre las organizaciones que "solo aplican actualizaciones acumulativas para corregir problemas específicos que están experimentando" en realidad no es particularmente válida en la vida real.
Por ejemplo, si estaba ejecutando la compilación RTM de SQL Server 2012 Service Pack 1 (11.0.3000) y decidió instalar SQL Server 2012 Service Pack 1 Cumulative Update 3 (11.0.3349) porque incluía una revisión para una aplicación específica. problema que en realidad estaba encontrando, en realidad obtendría todas las revisiones para SP1 CU1, SP1 CU2 y SP1 CU3, lo que equivaldría a más de 100 revisiones.
Como afirma Microsoft sobre las actualizaciones acumulativas:“Debido a que las compilaciones son acumulativas, cada nueva versión de revisión contiene todas las revisiones y todas las revisiones de seguridad que se incluyeron con la versión anterior de revisión de SQL Server 2012 SP 1. Le recomendamos que considere aplicar la versión de corrección más reciente que contenga esta revisión”. Básicamente, esto significa que si detecta un problema relevante en particular que se solucionó en una CU anterior, debe seguir adelante e implementar la última CU relevante en el sistema (que también incluirá esa revisión).
Un argumento que escucho con frecuencia acerca de por qué las organizaciones no implementan actualizaciones acumulativas es que "no se someten a pruebas de regresión completas como lo son los Service Packs, por lo que no las implementamos". Hay cierta validez en este punto de vista, pero también existe la idea errónea de que las actualizaciones acumulativas son simplemente pruebas unitarias, sin ninguna prueba de regresión. Este no es el caso.
La documentación de Microsoft sobre las actualizaciones acumulativas indica que, dado que "aplican pruebas de regresión incrementales a lo largo del ciclo de desarrollo, seguidas de 2 semanas de pruebas enfocadas dentro de la ventana de lanzamiento de 8 semanas, los procesos de control de calidad asociados con las CU superan a los de las revisiones individuales". Esto significa que en realidad corre menos riesgos al implementar una CU que se ha sometido a pruebas de regresión incrementales y que también ha tenido dos semanas de pruebas enfocadas que si fuera a implementar una revisión única que solo se ha probado por unidad.
Durante los últimos seis o siete años, he implementado personalmente muchas, muchas actualizaciones acumulativas y Service Packs en una gran cantidad de sistemas que ejecutan SQL Server 2005 a SQL Server 2012, y aún no he encontrado ningún problema importante. Tampoco he oído hablar de ningún problema generalizado al hacer este tipo de trabajo que se haya informado en blogs, Twitter, etc. Podría ser que yo (y todos los que conozco) hayamos tenido suerte, o tal vez las actualizaciones acumulativas y los Service Packs no son del todo tan riesgoso como algunas personas creen (siempre que los pruebe y los implemente correctamente).
La importancia de un plan de prueba e implementación
A menos que nunca planee hacer ningún tipo de mantenimiento del servidor o actualizaciones de aplicaciones durante la vida útil de su sistema (lo que parece una propuesta poco probable), realmente necesita desarrollar algún tipo de procedimiento y plan de prueba e implementación que seguiría como parte de realizar cualquier tipo de cambio en el servidor.
Este plan puede comenzar relativamente simple, pero se volverá más complejo y completo a medida que adquiera más experiencia en el mantenimiento regular de sus instancias de SQL Server y aplique las lecciones que aprenda con cada implementación. Idealmente, seguiría este plan cada vez que realice un cambio en el sistema, pero eso puede no ser posible en todos los casos.
Aquí hay algunos pasos iniciales y pruebas que deben incluirse en este tipo de plan.
- Instalar CU en una máquina virtual de prueba
- ¿La CU se instala sin problemas ni errores?
- ¿La instalación de CU requiere un reinicio del sistema?
- ¿Todos los servicios relevantes de SQL Server se reinician después de la instalación?
- ¿Parece que SQL Server funciona correctamente después de la instalación?
- Instalar la CU en varios sistemas de desarrollo
- ¿La CU se instala sin problemas ni errores?
- ¿Parece que SQL Server funciona correctamente durante el uso diario normal?
- ¿Sus aplicaciones parecen funcionar correctamente durante las pruebas unitarias?
- Instalar la CU en un entorno de integración o control de calidad compartido
- ¿Seguiste un plan de implementación específico y una lista de verificación para la instalación?
- ¿Todas las aplicaciones que usan SQL Server pasan la prueba de humo?
- ¿Todas las aplicaciones superan alguna prueba automatizada disponible?
- ¿Todas las aplicaciones superan pruebas funcionales manuales más detalladas?
- Instalar la CU en su entorno de Producción
- Utilice una estrategia de actualización gradual cuando sea posible
- Utilice una lista de verificación detallada paso a paso durante la implementación
- Actualice su lista de verificación con elementos perdidos y lecciones aprendidas
Conclusión
Lo que espero lograr aquí es lograr que más profesionales de bases de datos comiencen a moverse hacia una mentalidad en la que realmente quieran mantener regularmente sus instancias de SQL Server, en lugar de dudar o tener miedo de hacerlo. Esto puede implicar una cantidad significativa de trabajo adicional al principio, ya que es posible que deba convencer a otras personas de su organización para que se unan a sus planes. Es posible que deba presionar a otras partes de la organización para que desarrollen mejores planes de prueba, y tendrá que crear una lista de verificación de implementación. También deberá obtener la autorización de la empresa para las ventanas de mantenimiento (que deberían ser relativamente cortas con las actualizaciones continuas), de modo que pueda implementar actualizaciones en sus sistemas de producción de forma regular.
A cambio de este trabajo adicional, tendrá un sistema mejor mantenido que es menos probable que tenga problemas en el futuro. Estará en una configuración totalmente compatible con Microsoft y tendrá más confianza en su(s) tecnología(s) de alta disponibilidad, ya que en realidad las ejercitará de manera regular. También obtendrá una valiosa experiencia a medida que planifica e implementa todo esto, lo que mejorará sus habilidades para solucionar problemas en el futuro.
