Las mejores prácticas para SQL Server cambio 2.008 esquema

Question

Busco a la información relativa a lo siguiente:

¿Cuáles son las mejores prácticas para actualizar el esquema de mi dev DB a mi producción DB, o incluso más sucintamente realizar cambios de esquema DB en general.

La base de datos de producción es el back-end para dos sitios web ASP.NET distintos.

Nuestro proceso de cambio de esquema es bastante robusto y cada "migración" en realidad es un archivo .cs que contiene los cambios de esquema. Luego usaremos ADO.NET para aplicar los cambios de esquema contra el db.

Mi pregunta es más acerca de la conectividad de la base de datos.

Debo detener los dos sitios web que están accediendo a la base de datos. Supongo que debería. Debería poner el DB en modo de usuario único. Parece que debería pero no estoy completamente seguro de eso.

¿Qué podría estar perdiendo? ¿Cuáles son las cosas que te han mordido en la mano antes con respecto a los cambios en el esquema de DB?

Answer 1

Si las actualizaciones cambian cosas como nombres de columnas, parámetros de proceso almacenados, etc., siempre desconecte las aplicaciones antes de hacer una actualización de esquema.

Si las actualizaciones son solo para cosas que no afectan el procesamiento normal de los datos, entonces podría ser capaz de hacerlo "caliente". Esta categoría es cuando agrega elementos como índices, tablas, etc.

Si alguien está usando la aplicación mientras se procesa una actualización de esquema, es muy posible que se encuentre en una situación en la que la consistencia de los datos se vea afectada.

Si esta actualización requiere una actualización correspondiente a los archivos de su aplicación web, saque el sitio (s) fuera de línea antes de realizar la actualización. No sabe quién podría estar viendo una página y está a punto de hacer clic en enviar solo para obtener un error ...

Normalmente, el mantenimiento de este tipo se realiza durante las horas pico. Deberá notificar a los usuarios con anticipación sobre cuándo el sitio estará inactivo y por cuánto tiempo.

Además, utilizamos herramientas como SQL Compare de Redgate para crear secuencias de comandos de nuestras actualizaciones de db. Esto se practica en un servidor de transición que se actualizó a partir de los datos de producción antes del empuje real para garantizar que no haya sorpresas y que se pueda realizar muy rápidamente.

En relación con el Modo de usuario único, normalmente se usa para limitar el acceso a una base de datos a una única instancia de Management Studio. No es algo que normalmente hacemos como parte de nuestras implementaciones.

Answer 2

Situación ideal, pero no siempre alcanzable: Realiza cambios de esquema que son compatibles con la versión > del viejo > de su sitio web. A continuación, libera V <nuevo> en sus servidores web. Una vez que todos sus servidores web estén en V <nuevo>, puede realizar las limpiezas (rellenar los valores perdidos, etc.) y luego realizar los cambios de nulabilidad adecuados.

Answer 3

No he considerado la ruta .cs/ado.net para realizar cambios en el esquema. Lo que hacemos es crear archivos 'delta' .SQL - SQL para hacer los cambios. Se ejecutan contra un esquema de revisión conocida para realizar los cambios, y ejecutar .SQL forma parte de una implementación.

De la mejor manera posible, también intentamos que sea seguro ejecutarlo varias veces comprobando el esquema para cosas específicas como la existencia de una columna, índice, etc. De esta forma podrían ejecutarse "accidentalmente" varias veces.

Cuando implementamos tenemos momentos específicos del día/semana, advertimos a los usuarios/clientes, desconectamos sitios web, etc. Con implementaciones de 'prácticas' que se realizan casi todos los días en los servidores de desarrollo y estadificación los últimos días antes del lanzamiento , la confianza del despliegue final es alta.

Al mantener los cambios de esquema en SQL, se parecen más al SQL del esquema "maestro" que modifican y, por lo tanto, son más fáciles de seguir. Menos para depurar también!

También se gestionan en TFS junto con el resto del código.