Pregunta Copia de seguridad / restauración de SQL Server vs. separar / adjuntar


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.

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

Solución 1: separar la base de datos fuente que contiene los datos más recientes, luego copiar a los servidores de destino que necesitan los datos más recientes y adjuntar 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 los datos a los servidores de destino y realice una recuperación completa en el servidor de destino.

gracias por adelantado, Jorge


32
2018-03-04 11:02


origen


Respuestas:


La opción Separar / Adjuntar es a menudo más rápida que realizar 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, cualquier acción realizada en la base de datos en el servidor A durante el tránsito no se replicará en el servidor B.

En lo que respecta a la "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.


24
2018-03-04 11:08



Copia de seguridad y restauración tiene mucho más sentido, incluso si puede esperar unos 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.


8
2017-09-17 14:18



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


4
2018-03-04 11:10