Как я могу поддерживать согласованную схему БД для 18 баз данных (sql server)?

Question

У нас есть 18 баз данных, которые должны иметь идентичные схемы, но этого не делают.В определенных сценариях таблица была добавлена к одному из них, но не ко всем остальным.Или же определенные хранимые процедуры требовались в нескольких базах данных, но не в остальных.Или наш администратор базы данных забыл запустить скрипт для добавления представлений во все базы данных.

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

Answer 1

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

Для магазинов .NET, работающих под управлением SQL Server, также существует Версия базы данных Visual Studio, который может создавать сценарии изменений для изменений схемы, которые могут быть проверены в системе управления версиями и автоматически созданы с помощью вашего процесса CI / build.

Answer 2

Сравнение SQL by Red Gate - отличный инструмент для этого.

Answer 3

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

Чтобы поддерживать синхронизацию баз данных, вам необходимо выполнить несколько действий:

1) Вам нужна политика в отношении того, кто может вносить изменения в производство.Как правило, это должен быть только администратор базы данных (команда администраторов баз данных для более крупных организаций) и 1 или 2 бэкэпа.Резервные копии должны вносить изменения только при отключении администратора базы данных или в экстренных случаях.Резервные копии НЕ должны развертываться на регулярной основе.Установите права доступа к базе данных в соответствии с этой политикой.

2) Процесс и инструменты для управления запросами на развертывание.В идеале у вас должна быть среда разработки, тестовая среда и производственная среда.Разработчики должны выполнять начальную разработку в среде разработки и при необходимости вносить изменения в тестирование и продакшн.Вам понадобится какой-то способ сообщить администратору базы данных, когда следует вносить изменения.Я бы НЕ рекомендовал процесс, при котором вы кричите на следующий куб.В крупных организациях может быть комитет по контролю за изменениями, и изменения вносятся только раз в месяц.Небольшие компании могут просто запросить тестирование по запросу разработчика, и после тестирования передается запрос на развертывание в производство.Одна небольшая компания, в которой я работал, использовала Отслеживание проблем для этих запросов.

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

3) Вы сказали, что иногда объектам нужно перейти только к нескольким базам данных.Имея всего 18 баз данных, вероятно, на одном сервере, я бы рекомендовал сделать так, чтобы каждая база данных точно соответствовала объектам.usp_DoSomething нужен только 5 DBS?Ну и что?Внесите это во все базы данных.Этим будет намного легче управлять.Мы сделали это таким образом в системе из 6 серверов с примерно 250-300 базами данных.Были исключения, но они были сгруппированы.Базы данных на сервере C получили этот дополнительный набор объектов.Базы данных на сервере L получили этот другой набор.

4) Вы сказали, что иногда администратор базы данных забывает развернуть сценарии изменения для всех баз данных.Это говорит мне о том, что ему нужны инструменты для развертывания изменений.Вероятно, он берет SQL-скрипт, открывает его в анализаторе запросов или Manegement Studio (или что бы вы ни использовали) и вручную переходит к каждой базе данных и выполняет SQL.Это не является хорошим долгосрочным (или краткосрочным) решением. Красные Ворота (у создателей SQLCompare выше) есть много отличных инструментов. Мультискриптум похоже, это может сработать для целей развертывания.Я работал с администратором базы данных, который написал свой собственный инструмент в SQL Server 2000, используя O-SQl.Для этого потребуется файл SQL и выполнить его в каждой базе данных на сервере.Он должен был выполнить это на каждом сервере, но это превосходило выполнение на каждой базе данных.Я также помог написать инструмент VB.net, который делал бы то же самое, за исключением того, что он также просматривал список серверов, поэтому его нужно было выполнить только один раз.

5) Управление версиями.Моя нынешняя команда не использует систему управления версиями, и у меня нет достаточно времени, чтобы рассказать вам, сколько проблем это вызывает.Если у вас нет какой-либо системы управления версиями, приобретите ее.

Answer 4

У меня недостаточно репутации, чтобы прокомментировать приведенный выше ответ, но pro-версия SQL Compare имеет скриптовый API.Учитывая, что вам необходимо реплицировать данные во все эти базы данных, вы могли бы использовать это для создания автоматизированного задания либо для генерации сценариев изменения, либо для проверки того, что все базы данных синхронизированы.Это также ненамного дороже стандартной версии.

Answer 5

Помимо использования инструментов сравнения баз данных, с 18 базами данных у вас должен быть администратор базы данных, поэтому примените политику, согласно которой только администратор базы данных может изменять таблицы на уровне базы данных, ограничив доступ к СОЗДАНИЮ и ИЗМЕНЕНИЮ только администратору базы данных.Как в ваших тестовых, так и в действующих базах данных.Конечно, в базе данных разработчиков этого быть не должно!Заставьте разработчиков, которые создавали или изменяли схемы, волей-неволей обращаться к администратору базы данных.

Answer 6

Создайте единый скрипт DDL / SQL с управлением исходным кодом для каждого выпуска и Только используйте его для обновления баз данных.Инструменты diff могут быть полезны, но в основном для проверки того, что вы не допустили ошибки, и устранения неполадок в случае сбоя политик.Объедините скрипты DDL, SQL и хранимых процедур в один скрипт, чтобы было нелегко "забыть" запустить один из скриптов.

Answer 7

У нас есть инструмент под названием DB Schema Difftective, который может сравнивать и синхронизировать схемы базы данных.С помощью нашего другого инструмента, DB MultiRun, вы можете легко развертывать сгенерированные (синхронизировать) скрипты на нескольких серверах БД (на основе проекта).

Answer 8

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