2009-03-04 10 views
30

Tengo una base de datos que contiene los datos más recientes y quiero replicar el contenido de la base de datos en algunos otros servidores. Debido a razones no técnicas, no puedo usar directamente la función de réplica o la función de sincronización para sincronizar con otras instancias de SQL Server.Copia de seguridad/restauración de SQL Server frente a separar/adjuntar

Ahora, tengo dos soluciones, y quiero aprender los pros y los contras de cada solución. ¡Gracias!

Solución 1: separe la base de datos fuente que contiene los datos más recientes, luego copie a los servidores de destino que necesitan los datos más recientes y adjunte la base de datos en los servidores de destino;

Solución 2: realice una copia de seguridad completa del servidor de origen para toda la base de datos, luego copie datos en los servidores de destino y realice una recuperación completa en el servidor de destino.

gracias de antemano, George

+0

¿Qué sucede si los datos cambian en las bases de datos de destino, o son básicamente de solo lectura? – RobS

+0

Solo hay cambios en la base de datos fuente. ¿Algún consejo para qué solución es mejor? – George2

Respuesta

24

El Separar/Fijar opción es a menudo más rápido que la realización de una copia de seguridad, ya que no tiene que crear un nuevo archivo. Por lo tanto, el tiempo desde el Servidor A hasta el Servidor B es casi exclusivamente el tiempo de copia del archivo.

La opción Copia de seguridad/Restaurar le permite realizar una copia de seguridad completa, restaurarla y luego realizar una copia de seguridad diferencial, lo que significa que su tiempo de inactividad se puede reducir entre los dos.

Si lo que buscas es la replicación de datos, ¿eso significa que quieres que la base de datos funcione en ambas ubicaciones? En ese caso, probablemente desee la opción de copia de seguridad/restauración ya que eso dejará la base de datos actual completamente funcional.

EDITAR: Solo para aclarar algunos puntos. Por tiempo de inactividad quiero decir que si está migrando una base de datos de un servidor a otro, generalmente detendrá a las personas que la usan mientras está en tránsito. Por lo tanto, desde el punto de "detención" en el Servidor A hasta el punto de "inicio" en el Servidor B, esto podría considerarse tiempo de inactividad. De lo contrario, las acciones realizadas en la base de datos en el servidor A durante el tránsito no se replicarán en el servidor B.

En lo que respecta a "crear un nuevo archivo". Si separa una base de datos, puede copiar el archivo MDF inmediatamente. Ya está listo para ser copiado. Sin embargo, si realiza una copia de seguridad, debe esperar a que se cree el archivo .BAK y luego moverlo a su nueva ubicación para una restauración. De nuevo, todo esto se reduce a esta es una copia de instantánea o una migración.

+0

Dos confusiones: 1. "no tiene que crear un archivo nuevo" - ¿quiere decir nuevo archivo? 2. "el tiempo de inactividad se puede reducir entre los dos": ¿por qué hay tiempo de inactividad? Creo que para SQL Server con copia de seguridad completa y modelo de recuperación completa, no hay tiempo de inactividad para el servidor de origen/destino. – George2

+0

"Si busca la replicación de datos, ¿quiere decir que quiere que la base de datos funcione en ambas ubicaciones?" - Tanto el servidor de origen como el de destino podrían soportar tiempos de inactividad, pero quiero que el tiempo de inactividad del servidor de destino sea lo más breve posible. ¿Algún consejo nuevo sobre la mejor solución? – George2

+0

Gracias Robin, lee tus comentarios editados. ¿Entonces el nuevo archivo te refieres al archivo .bak? Otra pregunta, al utilizar adjuntar/separar, ¿habrá registros de transacciones en el servidor de base de datos de origen o en el servidor de la base de datos de destino? – George2

4

La solución 2 sería mi elección ... Principalmente porque no creará ningún tiempo de inactividad en la base de datos de origen. El único inconveniente que puedo ver es que, dependiendo del modelo de recuperación de la base de datos, el registro de transacciones se truncará, lo que significa que si desea restaurar cualquier información del registro de transacciones que se rellenaría, tendría que usar su archivo de respaldo.

EDIT: Encontró un buen enlace; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx

+0

Puedo asegurarme durante la copia de seguridad de la base de datos de origen, no hay operaciones de inserción/eliminación/actualización, y en la base de datos de destino, es de solo lectura todo el tiempo (todas las modificaciones están en la base de datos de origen). Entonces, en mi caso, ¿no hay registro de transacciones para la copia de seguridad completa en el servidor de origen – George2

+0

y la recuperación completa en el servidor de destino? – George2

+0

al usar adjuntar/separar, ¿habrá registros de transacciones en el servidor de base de datos de origen o en el servidor de la base de datos de destino? – George2

8

Copia de seguridad y restauración tiene mucho más sentido, incluso si usted puede esperar unos pocos minutos adicionales de una opción de desconectar adjuntar en su lugar. Debe desconectar la base de datos original (desconectar a todos) antes de desconectarla, y luego la base de datos no estará disponible hasta que se vuelva a conectar. También debe realizar un seguimiento de todos los archivos, mientras que con una copia de seguridad, todos los archivos están agrupados. Y con las versiones más recientes de SQL Server, las copias de seguridad están comprimidas.

Y solo para corregir algo: las copias de seguridad de bases de datos y las copias de seguridad diferenciales no truncan el registro y no rompen la cadena de registro.

Además, la funcionalidad COPY_ONLY solo importa para la base diferencial, no para el LOG. Todas las copias de seguridad de registro se pueden aplicar en secuencia desde cualquier copia de seguridad suponiendo que no haya interrupción en la cadena de registro. Hay una ligera diferencia con el punto de archivo, pero no puedo ver dónde importa eso.

Cuestiones relacionadas