Я системный администратор, недавно получивший некоторую ответственность администратора баз данных SQL. Могу без неохоты добавить, что это мир, в который я очень хочу погрузиться.
Мне интересно узнать об одном из аспектов нашей существующей настройки (где задачи администратора базы данных ранее в значительной степени оставались на усмотрение разработчиков), а именно о механизме обновления одной из наших производственных баз данных.
По сути, происходит следующее: каждый раз при изменении базовых данных один из разработчиков создает новую базу данных в среде разработки и восстанавливает ее в производственной среде. Чтобы облегчить это, команде разработчиков были предоставлены разрешения dbcreator. Это происходит один или два раза в неделю.
Может ли кто-нибудь из более опытных администраторов баз данных обнаружить недостатки в этом подходе? Следует ли мне настаивать на том, чтобы все операции восстановления выполнялись самостоятельно (я написал команды T-SQL для использования командой разработчиков вместо SSMS, которая требовала прав системного администратора для просмотра доступных носителей)? Может ли что-то пойти не так во время восстановления, что приведет к отключению базы данных?
Мы используем стандартную версию SQL Server 2008 R2.
Спасибо всем.
Как правило, у меня возникает проблема с командой разработчиков, применяющей изменения к производственной базе данных, за которую я отвечаю.
Если бы я был на вашем месте, я бы изменил процесс и применил все изменения базы данных в рабочей среде. Это избавляет от неожиданностей (для вас) и добавляет новый взгляд на процесс в тот самый момент, когда это необходимо.
Я также твердо верю в использование инструментов сравнения. В настоящее время я выбираю RedGate SQL Compare (для сравнения структур) и RedGate SQL Data Compare (для сравнения данных). Вы также можете использовать Visual Studio for Database Professionals, если она у вас загружена.
Еще одно преимущество использования инструментов сравнения заключается в том, что они минимизируют изменения в измененной базе данных, предоставляя вам набор сценариев, которые вы можете добавить в свою систему управления версиями для документирования каждого выпуска.
Следование по этому пути устраняет необходимость для разработчиков иметь повышенные разрешения в производственной базе данных и должно снизить вашу уязвимость. На мой взгляд, уменьшение экспозиции - это всегда хорошо.
Я предполагаю, что это база данных только для чтения? Если так, то особых проблем с этим не вижу. То, как я делал это раньше, - это сохранять сценарии обновления, написанные для базы данных dev (естественно, в системе управления версиями!), А затем просто повторно применять те, которые были с момента последнего обновления, в prod. Этот метод, вероятно, немного быстрее, чем полное восстановление БД, хотя это, вероятно, не должно иметь большого значения, если вы не делаете его часто или если восстановление небольшое. По-прежнему хорошо делать снимок продукта перед каждым обновлением, на случай, если что-то пойдет не так и продукт и разработчик расходятся.