Назад | Перейти на главную страницу

Восстановление базы данных SQL в производственной среде как механизм обновления

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

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

По сути, происходит следующее: каждый раз при изменении базовых данных один из разработчиков создает новую базу данных в среде разработки и восстанавливает ее в производственной среде. Чтобы облегчить это, команде разработчиков были предоставлены разрешения dbcreator. Это происходит один или два раза в неделю.

Может ли кто-нибудь из более опытных администраторов баз данных обнаружить недостатки в этом подходе? Следует ли мне настаивать на том, чтобы все операции восстановления выполнялись самостоятельно (я написал команды T-SQL для использования командой разработчиков вместо SSMS, которая требовала прав системного администратора для просмотра доступных носителей)? Может ли что-то пойти не так во время восстановления, что приведет к отключению базы данных?

Мы используем стандартную версию SQL Server 2008 R2.

Спасибо всем.

Как правило, у меня возникает проблема с командой разработчиков, применяющей изменения к производственной базе данных, за которую я отвечаю.

Если бы я был на вашем месте, я бы изменил процесс и применил все изменения базы данных в рабочей среде. Это избавляет от неожиданностей (для вас) и добавляет новый взгляд на процесс в тот самый момент, когда это необходимо.

Я также твердо верю в использование инструментов сравнения. В настоящее время я выбираю RedGate SQL Compare (для сравнения структур) и RedGate SQL Data Compare (для сравнения данных). Вы также можете использовать Visual Studio for Database Professionals, если она у вас загружена.

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

Следование по этому пути устраняет необходимость для разработчиков иметь повышенные разрешения в производственной базе данных и должно снизить вашу уязвимость. На мой взгляд, уменьшение экспозиции - это всегда хорошо.

Я предполагаю, что это база данных только для чтения? Если так, то особых проблем с этим не вижу. То, как я делал это раньше, - это сохранять сценарии обновления, написанные для базы данных dev (естественно, в системе управления версиями!), А затем просто повторно применять те, которые были с момента последнего обновления, в prod. Этот метод, вероятно, немного быстрее, чем полное восстановление БД, хотя это, вероятно, не должно иметь большого значения, если вы не делаете его часто или если восстановление небольшое. По-прежнему хорошо делать снимок продукта перед каждым обновлением, на случай, если что-то пойдет не так и продукт и разработчик расходятся.