sql-server - servidor - restaurar base de datos sql server

La mejor forma de copiar una base de datos(SQL Server 2008) (9)

Pregunta tonta: ¿cuál es la mejor manera de copiar instancias en un entorno en el que quiero actualizar un servidor de desarrollo con instancias de un servidor de producción?

He hecho backup-restore, pero escuché detach-copy-attach y un tipo incluso me dijo que simplemente copiaría los archivos de datos entre los sistemas de archivos ....

¿Son estos los tres (o dos, el último suena sospechoso) métodos aceptados?

Según entiendo, el segundo método es más rápido pero requiere un tiempo de inactividad en la fuente debido al aspecto de separación.

Además, en esta situación (queriendo una copia exacta de la producción en un servidor de desarrollo) ¿cuál es la práctica aceptada para transferir inicios de sesión, etc.? ¿Debo hacer una copia de seguridad y restaurar las bases de datos del usuario + master + msdb?

A continuación se muestra lo que hago para copiar una base de datos desde el entorno de producción a mi entorno local:

Crea una base de datos vacía en tu servidor sql local
Haga clic derecho en la nueva base de datos -> tareas -> importar datos
En el Asistente para importación y exportación de SQL Server, seleccione el nombre de servidor de env del producto como fuente de datos. Y seleccione su nueva base de datos como datos de destino.

Ejecuto un SP para DEJAR caer la (s) mesa (s) y luego uso un paquete DTS para importar las tablas de producción más recientes a mi caja de desarrollo. Luego me voy a casa y vuelvo a la mañana siguiente. No es elegante; Pero funciona para mí.

El método de separar / copiar / adjuntar eliminará la base de datos. Eso no es algo que quieras en la producción.

La copia de seguridad / restauración solo funcionará si tiene permisos de escritura en el servidor de producción. Trabajo con Amazon RDS y no.

El método de importación / exportación no funciona realmente debido a las claves externas, a menos que haga las tablas una por una en el orden en que se referencian entre sí. Puede hacer una importación / exportación a una nueva base de datos. Eso copiará todas las tablas y datos, pero no las claves externas.

Esto suena como una operación común que uno necesita hacer con la base de datos. ¿Por qué SQL Server no maneja esto correctamente? Cada vez que tuve que hacer esto fue frustrante.

Una vez dicho esto, la única solución sencilla que he encontrado es Sql Azure Migration Tool, que mantiene la comunidad. Funciona con SQL Server también.

Es difícil separar los dB de producción u otros dB en ejecución y lidiar con ese tiempo de inactividad, por lo que casi siempre uso un método de copia de seguridad / restauración.

Si también quieres asegurarte de mantener tus inicios de sesión sincronizados, echa un vistazo al artículo de MS KB sobre cómo usar el proceso almacenado sp_help_revlogin para hacerlo.

La forma más fácil es en realidad una secuencia de comandos.

Ejecutar esto en producción:

USE MASTER; BACKUP DATABASE [MyDatabase] TO DISK = ''C:/temp/MyDatabase1.bak'' -- some writeable folder. WITH COPY_ONLY

Este comando hace una copia de seguridad completa de la base de datos en un solo archivo, sin interferir con la disponibilidad de la producción o la programación de la copia de seguridad, etc.

Para restaurar, solo ejecuta esto en tu desarrollador o prueba SQL Server:

USE MASTER; RESTORE DATABASE [MyDatabase] FROM DISK = ''C:/temp/MyDatabase1.bak'' WITH MOVE ''MyDatabase'' TO ''C:/Sql/MyDatabase.mdf'', -- or wherever these live on target MOVE ''MyDatabase_log'' TO ''C:/Sql/MyDatabase_log.ldf'', REPLACE, RECOVERY

A continuación, guarde estos scripts en cada servidor. Conveniencia con un clic.

Editar:
Si recibe un error al restaurar que los nombres lógicos no coinciden, puede obtenerlos así:

RESTORE FILELISTONLY FROM disk = ''C:/temp/MyDatabaseName1.bak''

Si utiliza los inicios de sesión de SQL Server (no la autenticación de Windows), puede ejecutar esto después de restaurar cada vez (en la máquina de desarrollo / prueba):

use MyDatabaseName; sp_change_users_login ''Auto_Fix'', ''userloginname'', null, ''userpassword'';

La forma más rápida de copiar una base de datos es separar el método de copiar y adjuntar, pero los usuarios de producción no tendrán acceso a la base de datos mientras se desconecta el prod db. Puede hacer algo como esto si su DB de producción es, por ejemplo, un sistema de punto de venta que nadie usa durante la noche.

Si no puede separar el archivo db de producción, debe usar la copia de seguridad y la restauración.

Deberá crear los inicios de sesión si no están en la nueva instancia. No te recomiendo que copies las bases de datos del sistema.

Puede usar SQL Server Management Studio para crear los scripts que crean los inicios de sesión que necesita. Haga clic con el botón derecho en el inicio de sesión que necesita para crear y seleccione Script Login as / Create.

Esto mostrará una lista de los usuarios huérfanos:

EXEC sp_change_users_login ''Report''

Si ya tiene una identificación de usuario y contraseña para este usuario, resuélvala haciendo:

EXEC sp_change_users_login ''Auto_Fix'', ''user''

Si desea crear una nueva identificación y contraseña de inicio de sesión para este usuario, corríjala haciendo:

EXEC sp_change_users_login ''Auto_Fix'', ''user'', ''login'', ''password''

Si desea tomar una copia de una base de datos en vivo, realice el método de copia de seguridad / restauración.

[En SQLS2000, no estoy seguro acerca de 2008:] Solo tenga en cuenta que si usa cuentas de SQL Server en esta base de datos, a diferencia de las cuentas de Windows, si el DB maestro es diferente o está desincronizado en el servidor de desarrollo, las cuentas de usuario no se traducirá cuando hagas la restauración. He oído hablar de un SP para reasignarlos, pero no recuerdo cuál fue.

Utilicé EMS SQL Backup y tiene la tarea de envío de base de datos que se puede programar fácilmente. Debes especificar la carpeta de red compartida. La copia se realiza a través de una copia de seguridad / copia / restauración también, pero se puede configurar rápidamente. Parece que no hay capacidad para manejar inicios de sesión en el programa y tendrá que hacerlo manualmente.

ACTUALIZAR:
Mi consejo a continuación le indica cómo hacer un script de un DB utilizando SQL Server Management Studio, pero la configuración predeterminada en SSMS omite todo tipo de partes cruciales de una base de datos (como índices y factores desencadenantes) por algún motivo. Por lo tanto, creé mi propio programa para crear correctamente una base de datos que incluye casi todos los tipos de objetos DB que haya agregado. Recomiendo usar esto en su lugar. Se llama SQL Server Scripter y se puede encontrar aquí:
https://bitbucket.org/jez9999/sqlserverscripter

Me sorprende que nadie haya mencionado esto, porque es realmente útil: puedes volcar una base de datos (su esquema y datos) en un script, usando SQL Server Management Studio.

Haga clic con el botón derecho en la base de datos, elija "Tareas | Generar scripts ..." y luego seleccione para crear scripts de objetos de base de datos específicos. Seleccione los que desea copiar a la nueva base de datos (es probable que desee seleccionar al menos las tablas y esquemas). Luego, para la pantalla "Establecer opciones de secuencia de comandos", haga clic en "Avanzado", desplácese hacia abajo hasta "Tipos de datos para secuencia de comandos" y seleccione "Esquema y datos". Haga clic en Aceptar y termine de generar el script. Verás que esto ha generado un largo script para ti que crea las tablas de la base de datos e inserta los datos en ellas. Luego puede crear una nueva base de datos y cambiar la declaración USE [DbName] en la parte superior de la secuencia de comandos para reflejar el nombre de la nueva base de datos a la que desea copiar la anterior. ¡Ejecute el script y los datos y el esquema de la base de datos anterior se copiarán en el nuevo!

Esto le permite hacer todo desde el estudio de SQL Server Management, y no es necesario tocar el sistema de archivos.