Riesgos relacionados con la actualización a SQL Server 2008 R2

Tenemos bastantes servidores SQL que deben actualizarse de la versión 2005 a 2008 R2. El trabajo se planifica antes de mediados de año, ya que Microsoft está finalizando su soporte para el mismo.

Todos los servidores SQL 2005 son SP3 y SP4, y se ejecutan en Windows Server 2003 (cuyo soporte ya ha finalizado, pero tenemos la excepción de la extensión por un año más), pero donde sea necesario también podríamos optar por una actualización del sistema operativo del servidor.

Estos servidores incluyen replicación (transaccional), envío de registros, servicios de informes y un servidor de integración que ejecuta paquetes SSIS.

Mi pregunta aquí no es cómo, más bien me gustaría saber los riesgos involucrados o cualquier verificación previa que se pueda hacer antes de planificar esta actualización.

Además, ¿una actualización en el lugar será un mejor plan que una al lado de la otra para esta migración / actualización?

Esa es una gran pregunta, así que vamos a dividirlo un poco.

¿Qué puedo hacer por adelantado?

Comience con alguna lectura requerida .

• Compatibilidad con versiones anteriores de R2 de 2008
• Compatibilidad con versiones anteriores de 2008

Estos enlaces tienen enlaces a información adicional como

• Características obsoletas de SQL Server
• Funciones de SQL Server descontinuadas
• Rompiendo cambios
• Cambios de comportamiento en las características de SQL Server

Lea cada uno de ellos para ver qué cosas principales están cambiando. Presta especial atención a las funciones que estás utilizando.

Además, debe usar el Asesor de actualizaciones . Comprueba los componentes instalados e identifica aquellos que deberá reparar antes o después de la instalación.

Un montón de ventajas y desventajas aquí en ambos lados.

En su lugar

Pros

• Más fácil. Todas sus configuraciones permanecen iguales, por ejemplo. Además, las cadenas de conexión para sus aplicaciones probablemente no tendrán que cambiarse.
• Más barato No se requiere un segundo conjunto de hardware.

Contras

• El retroceso es difícil a imposible. Si algo sale mal, tendrá que encender y terminar porque el retroceso implica crear un servidor completamente nuevo y reinstalar SQL y luego restaurar las copias de seguridad de sus tablas.

Lado a lado

Básicamente, los pros y los contras son lo contrario de In place.

Pros

• Más seguro: si algo sale mal, eliminas la nueva versión y continúas con la anterior. Entonces puedes intentarlo más tarde.

Contras

• Es más costoso porque tiene que crear un nuevo conjunto de instancias probablemente en nuevos servidores.
• Es más difícil porque tiene que cambiar las cadenas de conexión, asegurarse de que todas sus configuraciones sean iguales, etc.

Ahora puede mitigar el gasto de lado a lado creando una nueva instancia en el mismo servidor, moviendo todo a él y luego desinstalando la instancia anterior. Funciona y, dependiendo de su situación, podría ser la mejor idea.

Honestamente, el cambio de 2005 a 2008 R2 no es tan malo. No es nada en comparación con 2000 - 2005 o 2008 R2 - 2012 (principalmente cambios de SSIS). Yo diría que con una cuidadosa planificación y lectura deberías estar en buena forma.

Entonces, mi pregunta aquí no es cómo, sino ¿me gustaría saber el riesgo involucrado o cualquier verificación previa que se pueda hacer antes de planificar esta actualización?

Debe ejecutar el asesor de actualizaciones y abordar los problemas que informa antes de migrar.

Consulte mi respuesta para obtener una lista extensa de los pasos previos y posteriores a la actualización .

Servidor SQL que debe actualizarse de la versión 2005 a 2008R2

Está eligiendo el camino donde volverá a la casilla 1 (ya que dentro de 3 años, tendrá que actualizar nuevamente). Ver abajo la tabla

¿La actualización Inplace será un mejor plan o uno al lado del otro para esta migración / actualización?

Según mi experiencia, te sugiero que hagas una migración lado a lado ya que estás obteniendo una nueva versión del sistema operativo y SQL. Este es un enfoque mucho más limpio, ya que tendrá sus servidores antiguos todavía disponibles, en caso de que desee realizar una recuperación. Consulte: ¿Las actualizaciones de SQL Server en el lugar están tan mal aconsejadas como solían estar? . No me malinterpretes cuando sugiero una migración de lado a lado, es solo un lado más seguro cuando se trata de retroceder.

En mi opinión, si va a hacer el esfuerzo de migrar, debería ir hasta 2014 incluso si lo ejecuta en modo de compatibilidad 10.0.

Vas a pagar la licencia de todos modos. Además, el esfuerzo de prueba de regresión y la curva de aprendizaje del desarrollador / DBA serán significativos en cualquier caso. Si se detiene en 2008R2 ahora, solo tendrá que repetir el ejercicio nuevamente en un par de años. 2008R2 ya ha visto su último Service Pack y en unos meses (semanas) habrá 3 versiones completas detrás de la versión actual.

Recomiendo que mi organización se traslade de 2008R2 directamente a 2016 por las mismas razones. Espero que comencemos un esfuerzo de prueba tan pronto como 2016 llegue a RTM.

Por cierto, estoy de acuerdo en que se prefiere una actualización de lado a lado. La última vez que hice este ejercicio, ejecutamos la versión "Preproducción" en un entorno de desarrollo durante aproximadamente un mes.