Я использую SQL Server 2008 Enterprise. Мне нужно перенести базу данных (в целом) на другой сервер (чтобы создать дубликат базы данных для настройки другой тестовой среды).
У меня есть два варианта: (1) сделать полную резервную копию на исходном сервере / восстановить на целевом сервере; (2) отсоединение от исходного сервера / подключение к целевому серверу.
Какие плюсы и минусы двух решений в соответствии с моими требованиями?
заранее спасибо, Джордж
Я вздрагиваю при мысли об отсоединении базы данных, копировании ее файлов в другое место, а затем повторном подключении ее на производственном сервере (и прикреплении копии на тестовом сервере). Резервное копирование предназначено для создания полной копии базы данных без простоев. Это также не дает возможности для файлов исходной базы данных быть случайно перемещенными / удаленными / поврежденными, что я видел несколько раз (из-за ошибки пользователя - опечатки или скольжения мыши) во время операций отсоединения / присоединения. Кроме того, перенос базы данных + журналов потенциально может привести к гораздо большему размеру передаваемого файла, чем просто резервная копия.
Просто сделайте резервную копию, а затем скопируйте / переместите файл резервной копии на целевой сервер. Это много Это безопаснее с производственной точки зрения.
Надеюсь, администратор базы данных может вмешаться, поскольку я не специалист по БД. Но я знаю, что столкнулся с проблемами, связанными со схемой, при отсоединении / присоединении, а не резервном копировании / восстановлении. Я всегда думаю, что более безопасный путь - резервное копирование и восстановление.
Отсоединение / присоединение потенциально выполняется быстрее, в зависимости от вашей модели восстановления и от того, используете ли вы сжатие в резервной копии. Отсоединение и присоединение выполняются почти мгновенно, тогда как требуется время, чтобы записать файл резервной копии на исходном сервере, а затем записать файлы db на целевой сервер.
Резервное копирование и восстановление сократят время простоя исходного сервера, в то время как отсоединение и подключение будут в целом быстрее, так как вам не нужно сначала копировать резервную копию в целевую систему и восстанавливать ее (если вы не используете физический носитель для передачи резервной копии. файл с одного сервера на другой).
Я бы по-прежнему выбрал резервное копирование / восстановление: он прост в использовании и понимании, а время безотказной работы всегда является желательным свойством в производственной системе. Кроме того, вы можете использовать это для проверки своей стратегии резервного копирования, создав вместо этого обычную резервную копию для восстановления или создав новую.
После того, как БД смонтирована, вам все равно нужно будет пройти через разрешения и схему, чтобы настроить их в новом месте. В обоих случаях вам может потребоваться передать все ключи, используемые для шифрования, прежде чем пытаться восстановить данные.
Я всегда использую Backkup / Restore - это менее инвазивно, оно поддерживает вашу БД в оперативном режиме и является довольно идиотским доказательством - я живое свидетельство этого.
Я предполагаю, что вы делаете резервные копии ежедневно / еженедельно / что угодно ... что может быть проще, чем просто скопировать резервные копии на тестовый сервер? [Очевидно, что при 100 ГБ потребуется время!]
Я не знаю точно, что вы здесь пытаетесь сделать, но у вас также есть возможность выполнить репликацию моментального снимка в Enterprise, что позволит вам регулярно обновлять среду разработки или промежуточную среду.