Actualizaciones acumulativas de MS SQL Server: mejores prácticas

Estoy tratando de tener una idea de las mejores prácticas recomendadas para las actualizaciones acumulativas de SQL Server .

Actualmente, corremos con la idea de "no hacer nada a menos que un problema solucionado por la CU sea uno que nosotros experimentemos". Eso funciona desde un enfoque de "si no está roto, no lo arregles", pero me pregunto si es realmente una buena idea ya que muchas de las CU tienen mejoras de rendimiento. Tal vez estemos considerando agregar la CU a los parches aplicados durante nuestros ciclos de mantenimiento periódicos un mes o dos después de que se lance la CU.

¿Qué hacen los demás y por qué?

Como una actualización de la pregunta que afecta las respuestas a continuación, el 24 de marzo de 2016, el equipo de SQL Server de Microsoft anunció que estaban actualizando su modelo de servicio . Microsoft recomienda que todos los usuarios instalen todas las CU publicadas después de enero de 2016:

A partir de las versiones de CU de enero, estos mensajes de precaución se han actualizado, ahora recomendamos la instalación continua y proactiva de CU a medida que estén disponibles. Debe planear instalar una CU con el mismo nivel de confianza que planea instalar los SP (Service Packs) a medida que se lanzan. Esto se debe a que las CU están certificadas y probadas al nivel de SP. Además, los datos CSS de Microsoft indican que un porcentaje significativo de los problemas de los clientes a menudo se abordan previamente en una CU lanzada, pero no se aplican de manera proactiva. Más aún, las CU contienen un valor agregado además de las revisiones. Estos también pueden contener actualizaciones de compatibilidad, registro y confiabilidad que mejoran la experiencia general.

Además de las actualizaciones de mensajes y orientación, hemos realizado actualizaciones al modelo de adquisición de CU.

Adquisición de cambios:

• Las CU, por supuesto, tradicionalmente se han puesto a disposición en el servidor "Hotfix" (acompañado por el "lenguaje de precaución" asociado con un 'QFE' o 'Hotfix'). La inconsistencia aquí es que las CU ya no son realmente revisiones rápidas simples. Las actualizaciones incluidas se prueban bien a nivel de integración de sistemas individuales y completos en la actualidad.
• Por lo tanto, ahora estamos colocando la última CU por línea de base admitida por la corriente principal (2012 SP2 / SP3 y 2014 RTM / SP1 hoy) en microsoft.com/downloads, tal como se hace hoy para los Service Packs
• Además, pronto lanzaremos y mantendremos todas las CU en el Catálogo de Windows Update para facilitar la adquisición y distribución
• Solo las correcciones provisionales de CU 'a pedido' se colocarán en el servidor de revisión en adelante
• Para reducir la fricción, descargar CU desde microsoft.com/downloads no requerirá proporcionar / recibir un correo electrónico y una URL
• También estamos evaluando ofrecer la última CU como una actualización opcional en Microsoft Update, al igual que los Service Packs de hoy

Soy un gran defensor de mantenerme al día con la actualización acumulativa más reciente, pero solo si su ciclo de pruebas / control de calidad puede garantizar una prueba de regresión completa y adecuada. Glenn Berry de SQLskills también es un defensor de este enfoque .

La propia recomendación de Microsoft es aplicar únicamente CUs que solucionen problemas que lo afectan, aunque han aflojado esa postura recientemente . El problema es que puede verse afectado por uno o más de esos problemas y no saberlo, o podría verse afectado mañana incluso si aún no lo ha afectado. ¿Pasará e intentará reproducir el problema detrás de cada arreglo en cada CU para su rama? ¿Vas a hacer esto continuamente para asegurarte de que aún no estás afectado?

Seré sincero: nunca tuve problemas para aplicar una CU a mis instancias. Y, de hecho, su proceso de lanzamiento de CU ha sido mucho más confiable que el ciclo de lanzamiento del service pack, y en muchos casos (incluido el más reciente con SQL Server 2012 Service Pack 2 ), no desea aplicar el service pack hasta el primer CU para esa rama se ha lanzado de todos modos. En este caso, hay una revisión provisional para resolver el problema que no se solucionó a tiempo para crear el código del Service Pack, pero eso no siempre es cierto.

Solíamos mantenernos al día con las CU. Aproximadamente 1 mes después del lanzamiento, los aplicaríamos si estábamos experimentando un problema corregido por ellos o no.

Sin embargo, después de encontrarnos con un gran problema, detuvimos esta práctica. En nuestro caso, un service pack que habíamos instalado solucionó un problema con la indexación de texto completo que estábamos experimentando. Unos meses más tarde, una de las CU retiró esa solución en particular. Esto nos causó todo tipo de problemas que requirieron bastante investigación para descubrir qué sucedió. Terminamos codificando un trabajo que luego se arruinó cuando una nueva CU rompió algo más ... Resultado neto: el servidor se volvió a instalar desde cero hasta un nivel SP / CU particular y se congeló.

El rendimiento de nuestra aplicación es tal que no nos preocupan las nuevas mejoras de rendimiento de SQL que puedan surgir, por lo que no es un problema. Además, los informes y otras consultas están retirando constantemente los resultados válidos, por lo que cualquier ajuste nuevo es innecesario. Lo que significa que tiene que ser un problema de seguridad antes de considerar aplicar una CU en este momento.

Estoy completamente de acuerdo con Aaron: solo haga esto si su ciclo de prueba / control de calidad puede probarlo correctamente. De lo contrario, diría que se mantenga alejado a menos que corrija un problema al que realmente se enfrenta. E incluso entonces, pruebe cada pequeña faceta con datos reales para asegurarse de que no rompan algo de lo que pueda estar dependiendo.