Можно ли скопировать файлы базы данных, когда база данных находится в сети?

9

Я работаю над созданием рабочей копии рабочей базы данных на SQL Server 2008 R2 SP1. Активная база данных в настоящее время легко используется двумя разработчиками для запросов только для чтения, но для новой базы данных также будут выполняться обновления.

Поскольку размер базы данных составляет 2,1 ТБ, а на восстановление и обновление до последней сборки, необходимой для тестирования, потребовалось всего 3 дня, я изначально планировал создать новый набор файлов резервных копий, а затем выполнить восстановление из этих файлов. Это позволило бы мне создать разрабатываемую копию базы данных на одном и том же экземпляре SQL и компьютере без необходимости переводить текущую базу данных в автономный режим.

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

Поскольку я не могу перевести базу данных в автономный режим ни для чего, кроме как перенести файлы журнала (я могу закончить это до того, как люди зайдут утром), есть ли способ скопировать файлы базы данных в реальном времени, не переводя базу данных в автономное состояние? Или я должен ждать, пока люди не пойдут домой, чтобы сделать это?

Шон Лонг
источник

Ответы:

11

Почему резервное копирование / восстановление базы данных объемом 2,1 ТБ занимает 3 дня? Если все дело в перемещении резервной копии, я подозреваю, что копирование файлов MDF / LDF будет на самом деле медленнее, поскольку, по крайней мере, резервная копия может быть сжата. И если речь идет только о восстановлении, то запись копий файла не должна выполняться быстрее самого процесса восстановления - убедитесь, что у вас включена мгновенная инициализация файла . Или получите более быстрый ввод / вывод во вторичной системе.

В любом случае, нет, вы не можете копировать файлы MDF / LDF, когда база данных находится в оперативном режиме, для этого вам нужно перевести ее в автономный режим. И это абсолютно НАИБОЛЕЕ безопасный способ копирования базы данных. Если что-то случится с файлами, пока они отключены / отключены, у вас теперь будет ноль копий вашей базы данных.

Я бы посоветовал изучить способы ускорения резервного копирования / восстановления - будь то обеспечение того, чтобы вы сжимали свои резервные копии и передавали файлы наилучшим из возможных способов, используя наилучшую доступную подсистему ввода-вывода, улучшая операции ввода-вывода, делая уверен, что МФИ включен и т. д.

Другим вариантом, который следует рассмотреть, является доставка журналов с циклическим перебором - при условии полного восстановления производства и регулярного резервного копирования журналов вы можете выполнять доставку журналов в одну базу данных, в то время как разработчики работают над другой, а когда вы достигаете стабильной точки, восстанавливайте с восстановлением. и пусть разработчики переключатся, взяв свои последние изменения с собой. Теперь повторно инициализируйте доставку журналов для копии, с которой они только что прекратили работать, и она будет готова к ним при следующем "стабильном" сокращении, без ожидания.

Аарон Бертран
источник
Резервное копирование займет неизвестное количество часов (я не создавал исходную резервную копию). Восстановление занимает 10 часов, затем запуск обновлений для загрузки в нашу сборку разработки занимает еще 8 часов. Так что на самом деле, если мы говорим о 24-часовом дне, это займет всего 18 часов. Говоря о 8 часовых днях, это в основном 3 дня (добавляя время для копирования файлов). Существуют АБСОЛЮТНО способы настройки самого процесса резервного копирования / восстановления, и это то, что я собираюсь сделать сейчас, когда я знаю, что именно так я и хочу идти.
Шон Лонг
0

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

Таннер Корбин
источник
0

Я видел другие ответы, и они имеют смысл. Однако, просто чтобы ответить на ваш вопрос, вы, безусловно, можете копировать файлы базы данных, не переводя БД в автономный режим. Для этого вам нужно будет использовать программирование SMO. Проверьте это: http://technet.microsoft.com/en-us/library/ms162175(v=sql.100).aspx

Обратите внимание, что приведенная ссылка предназначена для общих объектов программирования SMO, а не для конкретного ответа на этот вопрос. Я еще этого не сделал, но скоро собираюсь попробовать это и сообщу всем (если я помню), что я узнаю.

Мандар Шиндаги
источник
-1

Можно ли скопировать файлы базы данных, когда база данных находится в сети?

Да.

Все, что вам нужно сделать, это установить базу данных только для чтения:

  1. Запустить:

    USE [master]
    GO
    ALTER DATABASE [Database] SET READ_ONLY WITH NO_WAIT
    GO
  2. Скопируйте файлы базы данных - MDF, LDF и т. Д. В новое место назначения.

  3. После завершения копирования вы можете отсоединить и повторно прикрепить на новом месте. Просто убедитесь, что вы сбросили опцию «только для чтения», и вы используете ту же учетную запись пользователя при манипулировании этими файлами. Кроме того, вы можете удалить старые файлы после перемещения.

Другой метод

После того, как файлы успешно скопированы (шаг 2 выше):

Вы можете установить базу данных в Single_Userрежим: затем:

  1. Запустить:

    USE [master]
    GO
    ALTER DATABASE [Database] SET  Single_USER WITH NO_WAIT
    GO
  2. D:\ быть новым местом

    ALTER DATABASE Database MODIFY FILE
    (NAME = DATABASE, FILENAME = 'D:\DATABASE.mdf')
    GO
    ALTER DATABASE OHDSI MODIFY FILE
    (NAME = DATABASE_LOG, FILENAME = 'D:\DATABASE_LOG.ldf')
    GO
  3. Убедитесь, что файлы данных в новом расположении ( D:\) имеют полный доступ к учетной записи службы под управлением SQL Server.

  4. Перезапустите службы SQL

  5. Запустить:

    USE [master]
    GO
    ALTER DATABASE [Database] SET  Multi_USER WITH NO_WAIT
    GO

Выполнено!

RAVicioso
источник
Прежде всего обратите внимание, что перевод БД в режим «только для чтения» приводит к эффективному отключению, если при обычном использовании требуется запись в базу данных. Во-вторых, я ожидаю, что в SQL Server файлы по-прежнему будут заблокированы для использования, если они читаются; если ваш личный опыт или документация MS говорят об обратном, отредактируйте это в своем ответе. В-третьих, совет, который я обычно видел для изменения местоположения файла, заключается в переводе БД в автономный режим , а не только в однопользовательский режим. Опять же, если у вас есть личный опыт или документы MS, предлагающие иное, внесите изменения в ответ. Спасибо!
RDFozz
Это правильно! Только для чтения не позволит пользователям писать, но они смогут читать. Во-вторых, да, вы можете перевести базу данных в автономный режим, но вопрос заключается в том, чтобы быть в сети. Процесс, который я описал выше, работает с минимальным временем простоя. Спасибо.
RAVicioso
@RAVicioso база данных, доступная только для чтения, также является простоем. Если вы не можете записывать новые данные (например, принимать заказы), ваша система фактически не работает. Это кажется плохой идеей, не так ли?
Эрик Дарлинг
@sp_BlitzErik - Решение работает, но вы не сможете писать во время этого типа обслуживания. В вашем примере: «принимать заказы», ​​это не так.
RAVicioso