Присоединить / отключить против резервного копирования / восстановления

Мне нужно перенести базу данных (в целом) на другой сервер, чтобы сделать копию базы данных для настройки другой тестовой среды.

У меня есть два варианта:

1. Сделайте полную резервную копию на исходном сервере / восстановите на конечном сервере;
2. Отключить на исходном сервере / присоединить на конечном сервере.

Каковы плюсы и минусы двух решений в соответствии с моими требованиями?

Я использую SQL Server 2008 Enterprise.

Резервное копирование / восстановление обычно должно быть вашим методом выбора. Это будет быстрее в большинстве ситуаций.

Вы можете использовать его последовательно, а также для производства, чтобы проверить тоже.

Смотрите также этот связанный вопрос, где упоминается резервное копирование / восстановление против отсоединения / подключения:

Резервное копирование восстановления SQL Server vs копировать данные и файлы журналов

Убедитесь, что вы добавили эту WITH COPY_ONLYопцию в резервную копию, чтобы она не нарушала существующую цепочку резервного копирования плана обслуживания.

1. Отключение базы данных переведет ее в автономный режим. Сделайте резервную копию, если вам нужно, чтобы база данных оставалась в сети, пока вы копируете ее на другой сервер.
2. Перемещение и восстановление файла резервной копии (.bak) может быть проще / проще, чем перемещение и присоединение нескольких файлов mdf / ldf (как если бы вы отключили базу данных).
3. На бумаге отсоединение / присоединение базы данных технически может быть быстрее, но на практике резервное копирование / восстановление, вероятно, будет быстрее и проще. При отсоединении базы данных сначала необходимо перевести исходную базу данных в автономный режим (отключить всех и вся), а затем база данных будет недоступна до повторного подключения. Вы также должны отслеживать все файлы, в то время как с резервной копией все файлы сгруппированы.

Если вы решили выполнить резервное копирование / восстановление, используйте параметр WITH COPY_ONLY во время резервного копирования, чтобы убедиться, что цепочка резервного копирования любого существующего плана обслуживания не нарушена.

Файл .bak хорошо сжимается, поэтому, если вы решите сделать резервную копию, сжатие резервной копии перед ее перемещением может сэкономить некоторое время передачи.

Я бы пошел на резервное копирование / восстановление, поскольку он оставляет исходную базу данных в рабочем состоянии.

Особенно, если вы выполняете преобразование «производство в тест», важно, чтобы производственная база данных оставалась онлайн.

Резервное копирование / восстановление также является более безопасным вариантом: что произойдет, если файл будет поврежден где-то между началом отсоединения, копированием, вложением и т. Д.? По крайней мере, если вы выполните резервное копирование и файл станет поврежденным, вы можете начать все сначала. Если это происходит с отсоединением, ваша база данных исчезла.

Кроме того, для меня (хотя это больше чувство, чем что-либо еще), резервное копирование / восстановление - это «повседневная работа», тогда как отсоединение / подключение - это то, что вы делаете в исключительных обстоятельствах. Не спрашивайте меня, откуда у меня эта идея ;-)

У меня всегда были проблемы с «восстановлением» части резервного копирования / восстановления. Я не могу процитировать конкретику, так как в конце концов отказался от нее и с тех пор отрываю / копирую / прикрепляю.

Единственное, что нужно отсоединить, - это то, что вы ДОЛЖНЫ ИМЕТЬ, чтобы убедиться, что СУБД также не удалит базу данных. Имели это случиться, и это не симпатичное зрелище.

Я рекомендую сделать copy_onlyрезервную копию этого метода из оболочки DOS (чтобы не прерывать журналы транзакций) :

Запустить из C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupкаталога:

backup.bat SQLDBNAME

Где backup.batсодержится (разрыв строки добавлен для удобства чтения) :

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