Резервное копирование/восстановление SQL Server vs. detach/attach

У меня есть одна база данных, которая содержит самые последние данные, и я хочу реплицировать содержимое базы данных на некоторые другие серверы. Из-за нетехнических причин я не могу напрямую использовать функцию репликации или функцию синхронизации для синхронизации с другими экземплярами SQL Server.

Теперь у меня есть два решения, и я хочу изучить плюсы и минусы для каждого решения. Спасибо!

Решение 1: отсоедините исходную базу данных, которая содержит самые последние данные, затем скопируйте на целевые серверы, которым нужны самые последние данные, и прикрепите базу данных на целевых серверах;

Решение 2: сделайте полную резервную копию исходного сервера для всей базы данных, затем скопируйте данные на целевые серверы и выполните полное восстановление на стороне целевого сервера.

спасибо заранее, Джордж

Ответ 1

Параметр Detach/Attach часто быстрее, чем выполнение резервного копирования, так как ему не нужно создавать новый файл. Таким образом, время от сервера А до сервера Б почти чисто время копирования файла.

Параметр "Резервное копирование/восстановление" позволяет выполнять полную резервную копию, восстанавливать ее, а затем выполнять дифференциальную резервную копию, что означает, что время простоя может быть уменьшено между двумя.

Если репликация данных вам нужна, значит, вы хотите, чтобы база данных функционировала в обоих местах? В этом случае вам, вероятно, понадобится опция резервного копирования/восстановления, так как это оставит текущую базу данных полностью работоспособной.

РЕДАКТИРОВАТЬ: просто уточнить несколько моментов. По прошествии времени я имею в виду, что если вы переносите базу данных с одного сервера на другой, вы, как правило, будете останавливать людей, использующих его, пока он находится в пути. Следовательно, с точки "остановки" на сервере А до точки "запуска" на сервере Б это можно считать простоем. В противном случае любые действия, выполняемые в базе данных на сервере A во время транзита, не будут реплицироваться на сервер B.

Что касается "создания нового файла". Если вы отделите базу данных, вы можете немедленно скопировать файл MDF. Это уже готово к копированию. Однако, если вы выполняете резервное копирование, вам придется ждать создания файла .BAK, а затем переместить его в новое место для восстановления. Опять же все это сводится к тому, что это копия моментального снимка или миграция.

Ответ 2

Резервное копирование и восстановление имеют гораздо больший смысл, даже если вы можете выбрать несколько дополнительных минут из опции отсоединения. Перед отсоединением вы должны отключить исходную базу данных в автономном режиме (отключить всех), а затем db недоступен до повторного подключения. Вы также должны отслеживать все файлы, тогда как при резервном копировании все файлы сгруппированы. А с последними версиями SQL Server резервные копии сжимаются.

И просто для исправления: резервные копии БД и дифференциальные резервные копии не обрезают журнал и не прерывают цепочку журналов.

Кроме того, функция COPY_ONLY имеет значение только для дифференциальной базы, а не для LOG. Все резервные копии журналов могут применяться последовательно из любой резервной копии при условии, что в цепочке журналов не было прерываний. Существует небольшая разница с точкой архива, но я не вижу, что это имеет значение.

Ответ 3

Решение 2 было бы моим выбором... Прежде всего потому, что он не будет создавать простоя в исходной базе данных. Единственный недостаток, который я вижу, заключается в том, что в зависимости от модели восстановления базы данных журнал транзакций будет усечен, если вы хотите восстановить любые данные из журнала транзакций, которые вы должны были набивать, вам придется использовать файл резервной копии.

EDIT: Найдена хорошая ссылка; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx