sql-server - significa - restaurar base de datos sql server 2012 a 2008

Despliegue de bases de datos de SQL Server de Test a Live (14)

Actualmente estoy trabajando lo mismo para ti. No solo implementa las bases de datos de SQL Server desde la prueba hasta la versión en vivo, sino que también incluye todo el proceso desde Local -> Integración -> Prueba -> Producción. Entonces, ¿qué puede hacerme fácil todos los días? No hago ninguna tarea con Red-Gate SQL Compare . No estoy trabajando para RedGate, pero debo decir que es una buena elección.

Me pregunto cómo pueden gestionar el despliegue de una base de datos entre 2 Servidores SQL, específicamente SQL Server 2005. Ahora, hay un desarrollo y uno en vivo. Como esto debería ser parte de un buildscript (lote de Windows estándar, incluso con la complejidad actual de esos scripts, podría cambiar a PowerShell o más adelante), Enterprise Manager / Management Studio Express no cuentan.

¿Copiaría el archivo .mdf y lo adjuntaría? Siempre soy un poco cuidadoso cuando trabajo con datos binarios, ya que esto parece ser un problema de compatibilidad (aunque el desarrollo y la versión en vivo deberían ejecutar la misma versión del servidor en todo momento).

O bien, dada la falta de "EXPLAIN CREATE TABLE" en T-SQL, ¿hace algo que exporte una base de datos existente en SQL-Scripts que puede ejecutar en el servidor de destino? En caso afirmativo, ¿existe alguna herramienta que pueda volcar automáticamente una Base de datos determinada en Consultas SQL y que se ejecute fuera de la línea de comandos? (De nuevo, Enterprise Manager / Management Studio Express no cuentan).

Y por último, dado que la base de datos en vivo ya contiene datos, la implementación puede no implicar la creación de todas las tablas, sino la diferencia de estructura y ALTER TABLE las reales, que también pueden necesitar verificación / conversión de datos cuando cambian los campos existentes.

Ahora, escuché muchas cosas geniales sobre los productos de Red Gate , pero para los proyectos de hobby, el precio es un poco elevado.

Entonces, ¿qué está utilizando para implementar automáticamente las bases de datos de SQL Server de Test to Live?

Al igual que Rob Allen, utilizo SQL Compare / Data Compare de Redgate. También uso el asistente de publicación de la base de datos de Microsoft. También tengo una aplicación de consola que escribí en C # que toma un script sql y lo ejecuta en un servidor. De esta forma, puede ejecutar scripts grandes con comandos ''IR'' en él desde una línea de comando o en un script por lotes.

Utilizo las bibliotecas Microsoft.SqlServer.BatchParser.dll y Microsoft.SqlServer.ConnectionInfo.dll en la aplicación de la consola.

Al usar SMO / DMO, no es demasiado difícil generar un script de su esquema. Los datos son un poco más divertidos, pero todavía factibles.

En general, tomo el enfoque de "Guión It", pero es posible que desee considerar algo en esta línea:

Distinga entre desarrollo y estadificación, de modo que pueda desarrollar con un subconjunto de datos ... esto crearía una herramienta para simplemente desplegar algunos datos de producción, o generar datos falsos en lo que a seguridad se refiere.
Para el desarrollo del equipo, cada cambio en la base de datos deberá coordinarse entre los miembros de su equipo. Los cambios en el esquema y los datos pueden entremezclarse, pero un solo script debe habilitar una característica dada. Una vez que todas sus características estén listas, las agrupará en un solo archivo SQL y ejecutará eso para restaurar la producción.
Una vez que su organización haya aceptado su aceptación, usted vuelve a ejecutar el único archivo SQL en la máquina de producción.

He utilizado las herramientas de Red Gate y son excelentes herramientas, pero si no puede pagarlas, construir las herramientas y trabajar de esta manera no está demasiado lejos de lo ideal.

Estoy de acuerdo en que programar todo es la mejor manera de hacerlo y es lo que defiendo en el trabajo. Debería realizar un script de todo, desde creación de DB y objetos hasta rellenar sus tablas de búsqueda.

Todo lo que hagas en la interfaz de usuario no se traducirá (especialmente para los cambios ... no tanto para las primeras implementaciones) y acabará requiriendo herramientas como las que ofrece Redgate.

Estoy usando el mecanismo de migración de Subsónico, así que solo tengo un archivo DLL con clases en orden secuencial que tienen 2 métodos, arriba y abajo. Existe un enlace continuo de script de integración / compilación en nant, de modo que pueda automatizar la actualización de mi base de datos.

No es el mejor del mundo, pero es mejor que escribir DDL.

Hago toda la creación de mi base de datos como DDL y luego envuelvo ese DDL en una clase de mantenimiento de esquema. Debo hacer varias cosas para crear el DDL en primer lugar, pero fundamentalmente hago todo el maint de esquema en el código. Esto también significa que si uno necesita hacer cosas que no son DDL que no se relacionan bien con SQL, puede escribir lógica de procedimiento y ejecutarla entre terrones de DDL / DML.

Mis dbs tienen una tabla que define la versión actual para que pueda codificar un conjunto relativamente sencillo de pruebas:

¿Existe el DB? Si no es así crearlo.
¿El DB es la versión actual? De lo contrario, ejecute los métodos, en secuencia, que actualicen el esquema (es posible que desee solicitar al usuario que confirme e, idealmente, haga copias de seguridad en este punto).

Para una aplicación de usuario único, simplemente ejecuto esto en su lugar; para una aplicación web, actualmente bloqueamos al usuario si las versiones no coinciden y tenemos una aplicación de mapeo de esquema independiente que ejecutamos. Para usuarios múltiples, dependerá del entorno particular.

¿La ventaja? Bueno, tengo un alto nivel de confianza en que el esquema para las aplicaciones que usan esta metodología es constante en todas las instancias de esas aplicaciones. No es perfecto, hay problemas, pero funciona ...

Hay algunos problemas cuando se desarrolla en un entorno de equipo, ¡pero eso es más o menos un hecho de todos modos!

Murph

He llevado a cabo una codificación manual de todas mis sentencias DDL (crea / altera / elimina), las he agregado a mi .sln como archivos de texto y el uso de versiones normales (con subversión, pero cualquier control de revisión debería funcionar). De esta manera, no solo obtengo el beneficio del control de versiones, sino que la actualización en vivo desde dev / stage es el mismo proceso para el código y la base de datos: etiquetas, ramas y demás funcionan de todos modos.

De lo contrario, acepto que Redgate es costoso si no tiene una compañía comprándolo para usted. Sin embargo, si puede conseguir que una compañía lo compre por usted, ¡realmente lo vale!

No olvides la solución de Microsoft al problema: Visual Studio 2008 Database Edition . Incluye herramientas para implementar cambios en las bases de datos, produciendo una diferencia entre las bases de datos para el esquema y / o cambios de datos, pruebas unitarias, generación de datos de prueba.

Es bastante caro, pero utilicé la edición de prueba por un tiempo y pensé que era brillante. Hace que la base de datos sea tan fácil de trabajar como cualquier otro código.

Para mis proyectos, alternar entre SQL Compare de REd Gate y el Asistente de publicación de bases de datos de Microsoft, que puede descargar gratis aquí .

El Wizard no es tan ingenioso como SQL Compare o SQL Data Compare pero funciona. Un problema es que los scripts que genera pueden necesitar reorganización y / o edición para fluir de una vez.

En el lado positivo, puede mover su esquema y datos, lo cual no está mal para una herramienta gratuita.

También mantengo scripts para todos mis objetos y datos. Para la implementación escribí esta utilidad gratuita - http://www.sqldart.com . Le permitirá reordenar los archivos de script y ejecutará todo el lote dentro de una transacción.

Trabajo de la misma manera que Karl, manteniendo todos mis scripts SQL para crear y modificar tablas en un archivo de texto que guardo en control de fuente. De hecho, para evitar el problema de tener que tener un script, examine la base de datos en vivo para determinar qué ALTERs ejecutar, generalmente trabajo así:

En la primera versión, ubico todo durante la prueba en una secuencia de comandos SQL y trato todas las tablas como CREAR. Esto significa que termino bajando y leyendo tablas mucho durante las pruebas, pero eso no es gran cosa al principio del proyecto (ya que generalmente estoy pirateando los datos que estoy usando en ese momento).
En todas las versiones posteriores, hago dos cosas: hago un nuevo archivo de texto para mantener los scripts SQL de actualización, que contienen solo las ALTERs para esa versión. Y realizo los cambios en el original, también creo un nuevo script de base de datos. De esta forma, una actualización solo ejecuta el script de actualización, pero si tenemos que volver a crear el DB, no necesitamos ejecutar 100 scripts para llegar allí.
Dependiendo de cómo estoy implementando los cambios en la base de datos, generalmente pondré una tabla de versiones en el DB que contiene la versión del DB. Entonces, en lugar de tomar decisiones humanas sobre qué secuencias de comandos ejecutar, el código que tengo ejecutando las secuencias de comandos crear / actualizar utiliza la versión para determinar qué ejecutar.

Lo único que no hará es ayudar si parte de lo que está pasando de la prueba a la producción son los datos, pero si quiere administrar la estructura y no pagar por un buen, pero costoso paquete de administración de BD, realmente no es muy difícil. También descubrí que es una buena manera de mantener un seguimiento mental de tu base de datos.

RedGate SqlCompare es un camino a seguir en mi opinión. Hacemos la implementación de DB de forma regular y desde que comencé a usar esa herramienta nunca he mirado hacia atrás. Interfaz muy intuitiva y ahorra mucho tiempo al final.

La versión Pro también se ocupará de las secuencias de comandos para la integración del control de origen.

Estoy de acuerdo con mantener todo en control de fuente y escribir manualmente todos los cambios. Los cambios en el esquema para una sola versión van a un archivo de script creado específicamente para esa versión. Todos los procesos, vistas, etc. almacenados deberían ir a archivos individuales y tratarse como .cs o .aspx en lo que respecta al control de fuente. Uso un script de PowerShell para generar un gran archivo .sql para actualizar las cosas de programabilidad.

No me gusta automatizar la aplicación de cambios de esquema, como nuevas tablas, nuevas columnas, etc. Cuando realizo una publicación de producción, me gusta revisar el comando de cambio de comando por comando para asegurarme de que cada uno funcione como se espera. No hay nada peor que ejecutar un gran script de cambio en la producción y obtener errores porque olvidó algunos pequeños detalles que no se presentaron en el desarrollo.

También aprendí que los índices deben tratarse como los archivos de código y ponerlos en control de fuente.

Y definitivamente debería tener más de 2 bases de datos: dev y live. Debería tener una base de datos de desarrollo que todos utilicen para las tareas diarias de desarrollo. Luego, una base de datos de etapas que imita la producción y se usa para realizar las pruebas de integración. Luego, tal vez una copia completa reciente de la producción (restaurada a partir de una copia de seguridad completa), si es factible, por lo que su última ronda de pruebas de instalación va en contra de algo que sea lo más real posible.

Si tiene una compañía comprándola, Toad de Quest Software tiene este tipo de funcionalidad de administración integrada. Básicamente es una operación de dos clics para comparar dos esquemas y generar una secuencia de comandos de sincronización de uno a otro.

Tienen ediciones para la mayoría de las bases de datos populares, incluido por supuesto Sql Server.