El esquema de SQL Server 2014 cambia en un entorno multiusuario 24/7

Tenemos instalado SQL Server 2014 Enterprise para ejecutar una base de datos que debería estar disponible 24/7. Nuestra base de datos es lo suficientemente grande (200gb +). También tenemos muchos servicios que llegan a nuestra base de datos cada minuto para leer, actualizar o insertar nuevos datos. Queremos proporcionar una función de redistribución "en caliente" para nuestros clientes y hacer que nuestras actualizaciones diarias (.net y actualizaciones de esquema) sean transparentes para los clientes. Hemos encontrado una solución basada en clúster con equilibrador de carga para actualizar los archivos binarios de nuestra aplicación, pero aún tenemos algunos malentendidos sobre el proceso de implementación de actualizaciones de la base de datos y cuáles son las mejores prácticas para resolver este problema.

Para los cambios de esquema, desactive un servidor, aplique los cambios de esquema, vuelva a activarlo y luego aplique los mismos cambios a la segunda instancia. ¿Se puede lograr con las herramientas de SQL Server, y este es un enfoque común? ¿Cómo sincronizar los datos después de hacer una copia de seguridad del servidor? ¿O estoy pensando completamente en la dirección equivocada y hay mejores soluciones?

Nuestros cambios comunes de esquema: agregar / soltar columna, agregar / eliminar procedimiento almacenado

A continuación se requerirá un poco más de planificación y pruebas.

Concepto azul-verde:

La esencia de Blue-Green Concept es dividir su producción en 2 entornos y son idénticos en todo momento (sincronización de datos) en donde

1. El Azul (Actual) tendrá la versión actual del esquema / compilación o producto y será su entorno "EN VIVO".

2. Al mismo tiempo, Green será su entorno de ensayo / ensayo en el que actualizará su esquema / compilación o producto a la versión NEXT, realizará una prueba de regresión completa y será despedido por los usuarios de su empresa. Una vez feliz, durante un período de transición, promocionará el Verde para que sea su entorno "EN VIVO" y degradará al Azul para que sea un preprod / puesta en escena o prueba para el próximo lanzamiento.

De esta manera, tiene un tiempo de inactividad muy menor y el riesgo de fallas de implementación en un sistema en vivo (que se encuentra en la ventana de mantenimiento, ya que está realizando la actualización) se minimizará en gran medida. Además, siguiendo el enfoque Azul-Verde, estará oscilando entre la versión EN VIVO y la ANTERIOR, que se organizará para la próxima versión.

Nuevamente, esto requerirá más hardware / licencia, así como también planificación y pruebas.

La mayoría de los pasos se pueden automatizar con DACPAC y PowerShell. Además, si está instalando varias instancias en un servidor, asegúrese de volver a equilibrar la configuración de la Memoria cuando cambie entre Azul y Verde. El entorno LIVE obtiene más memoria que el entorno pasivo.

En mi entorno actual, hemos implementado el modelo azul / verde para la implementación de código ágil que nos permite promover el código cada 2 semanas con un amplio período de tiempo para las pruebas y la aprobación de la empresa. Además, es muy fácil retroceder en caso de que algo salga terriblemente mal. Hemos automatizado la mayoría de las cosas de implementación usando Dacpacs y PowerShell.

(Fuente de imagen)

Consulte también el artículo de Grant Fritchey sobre Solución de problemas de recuperación y recuperación; Desafíos y estrategias

Si su base de datos no se replica, entonces, las columnas de agregar y soltar se ejecutarán realmente rápido. Porque agregar columna es solo una posición vacía que SQL crea. La columna desplegable solo borrará la referencia.

De lo contrario, si hay alguna restricción o índice, tenga cuidado.

ADD/DELETElos procedimientos solo tendrán efecto en la ejecución misma. La recomendación es antes de que cualquier cambio en él ejecute la recompilación

sp_recompile 'myproc'