¿La mejor manera de crear un script de reversión de SQL Server?

Question

Estoy trabajando en algunos cambios de esquema en una base de datos existente.

Hice una copia de seguridad de la base de datos para obtener una copia dev y he realizado mis cambios Crearé un solo script de rollo para migrar los cambios en la máquina de producción en una sola transacción.

¿Existe alguna práctica recomendada para crear un encuadre de script de reversión si surge un problema de implementación? Antes he escrito entonces a mano usando el siguiente patrón:

• Eliminar nuevas restricciones e índices
• Modificar tablas para eliminar nuevas columnas
• Eliminar tablas agregadas
• Confirmar transacción

¿Hay un mejor enfoque?

Answer 1

Básicamente, no creo que haya mucho que agregar, aparte de su enfoque. Así es como lo hacemos en nuestra empresa, nosotros los desarrolladores somos responsables de crear el script y el script de rollback, y somos responsables de dejar el DB en el mismo estado en que estaba antes de que se apliquen los cambios iniciales. Luego, los DBA lo ejecutan en producción, si hay un problema, ejecutarán el script de reversión y todo volverá a la normalidad. Solo tenga en cuenta las dependencias y el orden en el que modifica sus objetos y luego cree el script de retroceso hacia atrás.

Answer 2

Te estás perdiendo el quinto paso

• Eliminar nuevas restricciones e índices
• Modificar tablas para eliminar nuevas columnas
• Eliminar tablas agregadas
• Confirmar transacción
• Pruebe el infierno del script antes de ejecutarlo en producción

Un enfoque más eficiente es registrar los cambios a medida que ocurren como RoR < a href = "http://wiki.rubyonrails.org/rails/pages/UsingMigrations" rel = "nofollow noreferrer"> migrations do . Para cada cambio de base de datos, crea un script que aplicará el cambio y lo revertirá (a su elección, por supuesto). Luego, puede tener esos scripts bajo el control de versiones al igual que su código.

Además, si mantiene un número de versión en la base de datos, puede automatizarlo un poco más, identificando cada script con un número de versión y haciendo que aumente o disminuya el número de versión en la base de datos según la acción realizada.

Answer 3

Si se trata de una base de datos relativamente pequeña, simplemente realice una copia de seguridad antes de aplicar la actualización. Si todo se vuelve loco, debes hacer una restauración.

Una vez que se publique y se ingresen nuevos datos, realmente no se puede revertir. Solo tienes que solucionar los problemas.

Answer 4

Si usa una herramienta como la Comparación de SQL de Redgate, puede ejecutar la comparación entre las dos bases de datos de ambas maneras y usar ambas para crear los scripts que necesita. la secuencia de comandos dev to prod tendría los cambios que está realizando y la secuencia de comandos prd to dev volvería al estado original de la base de datos de producción. Esto asegura que no olvides nada en ninguno de los dos scripts también.

Answer 5

Con SQL Server 2005 o una versión más reciente también puede crear una instantánea de base de datos, que le permite volver a ese estado en cualquier momento. Vea esta página para más información:

http://msdn.microsoft.com/en-us/library /ms175158.aspx