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 replicate o la función sync 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: desconecte la base de datos de origen que contiene los datos más recientes, luego copie a los servidores de destino que necesita los datos más recientes, y adjuntar la base de datos en los servidores de destino;
Solución 2: haga 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 lado del servidor de destino.
Gracias de antemano, George
3 answers
La opción Separar / Adjuntar a menudo es más rápida que realizar una copia de seguridad, ya que no tiene que crear un nuevo archivo. Por lo tanto, el tiempo del Servidor A al Servidor B es casi puramente el tiempo de copia del archivo.
La opción Copia de seguridad / Restauración 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 es la replicación de datos lo que busca, significa que desea que la base de datos funcione en ambos ¿ubicaciones? En ese caso, es probable que desee la opción de copia de seguridad / restauración, ya que dejará la base de datos actual completamente funcional.
EDITAR: Solo para aclarar algunos puntos. Por tiempo de inactividad me refiero a que si está migrando una base de datos de un servidor a otro, generalmente estará evitando que la gente la use mientras está en tránsito. Por lo tanto, desde el punto" stop "en el Servidor A hasta el punto" start " 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, tiene que esperar a que el .Archivo BAK que se creará y luego moverlo a su nueva ubicación para una restauración. Una vez más, todo esto se reduce a una copia instantánea o una migración.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-02-18 18:22:04
Hacer copias de seguridad y restaurar tiene mucho más sentido, incluso si puede esperar unos minutos adicionales de una opción de desacoplar adjuntar en su lugar. Debe desconectar la base de datos original (desconectar a todos) antes de separarla, 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 todos los archivos se agrupan. Y con las versiones más recientes de SQL Server las copias de seguridad se comprimen.
Y solo para corregir algo: Las copias de seguridad de la base de datos y las copias de seguridad diferenciales no truncan el registro ni rompen la cadena de registros.
Además, la funcionalidad COPY_ONLY solo importa para la base diferencial, no para el REGISTRO. Todas las copias de seguridad de registros se pueden aplicar en secuencia desde cualquier copia de seguridad asumiendo que no hubo interrupción en la cadena de registros. Hay una ligera diferencia con el punto de archivo, pero no puedo ver dónde importa.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-09-17 14:18:56
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. La única desventaja 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 dato del registro de transacciones que se rellena, tendría que usar su archivo de copia de seguridad.
EDITAR: Encontré un buen enlace; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-03-04 11:30:06