Adjuntar / separar vs copia de seguridad / restaurar

14

Necesito transferir la base de datos (como un todo) a otro servidor, para hacer una base de datos duplicada para configurar otro entorno de prueba.

Tengo dos opciones:

  1. Realice una copia de seguridad completa en el servidor de origen / restaure en el servidor de destino;
  2. Separar en el servidor de origen / adjuntar en el servidor de destino.

¿Cuáles son los pros y los contras de las dos soluciones según mis requisitos?

Estoy usando SQL Server 2008 Enterprise.

sql-server sql-server-2008 backup restore Paul White 9
fuente

Respuestas:

12

La copia de seguridad / restauración normalmente debería ser su método de elección. Será más rápido en la mayoría de las situaciones.

Puede usarlo constantemente, también para que la producción lo pruebe.

Consulte también esta pregunta relacionada, donde se menciona la copia de seguridad / restauración vs separar / adjuntar:

SQL Server Migration restaurar copia de seguridad vs copiar datos y archivos de registro

Asegúrese de agregar la WITH COPY_ONLYopción a la copia de seguridad para que no rompa la cadena de copia de seguridad del plan de mantenimiento existente.

gbn
fuente
SQL 2008 Enterprise introdujo la compresión de respaldo; Lo más probable es que la copia de seguridad comprimida sea significativamente menor que 100 GB y, por lo tanto, sea más rápida de escribir / copiar / cargar que copiar sobre MDF / LDF.
Thomas Rushton el
6
  1. Al separar la base de datos, se desconectará. Haga una copia de seguridad si necesita que la base de datos permanezca en línea mientras la copia a otro servidor.
  2. Mover y restaurar un archivo de respaldo (.bak) puede ser más simple / fácil que mover y adjuntar múltiples archivos mdf / ldf (como lo haría si separara la base de datos).
  3. En el papel, la separación / conexión de una base de datos puede ser técnicamente más rápida, pero en la práctica, es probable que una copia de seguridad / restauración sea más rápida y fácil. Cuando desconecta una base de datos, primero debe desconectar la base de datos original (desconectar a todos y todo), y luego la base de datos no estará disponible hasta que vuelva a conectarla. También debe realizar un seguimiento de todos los archivos, mientras que con una copia de seguridad se agrupan todos los archivos.

Si decide realizar una copia de seguridad / restauración, use la opción WITH COPY_ONLY durante la copia de seguridad para asegurarse de que la cadena de copia de seguridad de cualquier plan de mantenimiento existente no se rompa.

Un archivo .bak se comprime bien, por lo que si decide realizar una copia de seguridad, comprimir la copia de seguridad antes de moverla podría ahorrarle algo de tiempo de transferencia.

Bob Black
fuente
4

Me gustaría hacer una copia de seguridad / restauración, ya que deja la base de datos original en un estado operativo.

Especialmente si está haciendo una conversión de 'producción a prueba', es importante que la base de datos de producción permanezca en línea.

La copia de seguridad / restauración también es una opción más segura : ¿qué sucede si el archivo se corrompe en algún lugar entre el inicio de la separación, la copia, el archivo adjunto, etc.? Al menos si realiza una copia de seguridad y el archivo se corrompe, puede comenzar de nuevo. Si eso sucede con una separación, su base de datos se ha ido.

Además, para mí (aunque es más una sensación que cualquier otra cosa), la copia de seguridad / restauración es un "trabajo diario", mientras que la separación / conexión es algo que haces en circunstancias excepcionales. Sin embargo, no me preguntes de dónde saqué esta idea ;-)

Brimstedt
fuente
1

Siempre he tenido problemas con la parte "restaurar" de la copia de seguridad / restauración. No puedo citar detalles, ya que finalmente me di por vencido y desde entonces he estado separando / copiando / adjuntando.

Lo único acerca de la separación es que TIENE QUE TENER que asegurarse de que el DBMS no va a eliminar también la base de datos. Han sucedido esto, y no es una vista bonita.

Estafado
fuente
55
El DBMS no eliminará la base de datos al separar. ¿En qué tipo de tienda estás si desconectar elimina archivos y restaurar tiene problemas?
gbn
@Will: sp_detach_db no es DROP: 2 comandos separados y no relacionados que deben emitirse por separado. Las bases de datos separadas no pueden DROPped o los archivos eliminados a través de SQL. Una base de datos descartada no se puede separar. Separar no tiene la opción "eliminar archivos" a través de código o SSMS. Por lo tanto, puedo justificar mi primer comentario porque tienes que elegir deliberadamente la opción de eliminar los archivos en DROP. No se separe
gbn
1

Recomiendo una copy_onlycopia de seguridad utilizando este método desde un shell de DOS (para que no interrumpa los registros de transacciones) :

Ejecutar desde el C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupdirectorio:

backup.bat SQLDBNAME

Donde backup.batcontiene (salto de línea agregado para facilitar la lectura) :

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"
djangofan
fuente