SQLCompare - лучший инструмент, который я использовал для поиска различий между базами данных и их синхронизации.
Чтобы синхронизировать базы данных, вам нужно иметь несколько вещей:
1) Вам нужны политики о том, кто может вносить изменения в производство. Как правило, это должны быть только DBA (команда DBA для больших организаций) и 1 или 2 резервные копии. Резервные копии должны вносить изменения только при отсутствии администратора базы данных или в чрезвычайной ситуации. Резервные копии НЕ должны развертываться на регулярной основе. Установите права на базу данных в соответствии с этой политикой.
2) Процесс и инструменты для управления запросами на развертывание. В идеале у вас будет среда разработки, тестовая среда и производственная среда. Разработчики должны выполнить начальную разработку в среде разработчика и внести изменения, необходимые для тестирования и производства. Вам понадобится какой-то способ сообщить администратору базы данных, когда нужно вносить изменения. Я НЕ рекомендовал бы процесс, где вы кричите к следующему кубу. В больших организациях может быть комитет по контролю за изменениями, и изменения могут вноситься только один раз в месяц. Небольшие компании могут просто пройти тестирование запроса разработчика, и после тестирования передается запрос на развертывание в производство. Одна небольшая компания, на которую я работал, использовала для этих запросов Problem Tracker .
Используйте все, что работает в вашей ситуации и бюджете, просто есть процесс и инструменты, которые работают для этого процесса.
3) Вы сказали, что иногда объектам нужно всего лишь перейти к нескольким базам данных. Имея только 18 баз данных, вероятно, на одном сервере, я бы рекомендовал, чтобы каждая Databse точно соответствовала объектам. Только 5 БД нуждаются в usp_DoSomething? И что? Поместите это в каждую базу данных. Это будет намного проще в управлении. Мы сделали это таким образом на 6-серверной системе с 250-300 БД. Были исключения, но они были сгруппированы. Базы данных на сервере C получили этот дополнительный набор объектов. Базы данных на сервере L получили этот другой набор.
4) Вы сказали, что иногда администратор БД забывает развернуть сценарии изменений на всех БД. Это говорит мне о том, что ему / ей нужны инструменты для развертывания изменений. Он / она, вероятно, берет сценарий SQL, открывает его в Query Analyzer или Manegement Studio (или что бы вы ни использовали) и вручную обращается к каждой базе данных и выполняет SQL. Это не хорошее долгосрочное (или краткосрочное) решение. Красные Врата (создатели SQLCompare выше) имеют много замечательных инструментов. MultiScript похоже, что он может работать в целях развертывания. Я работал с администратором базы данных, который написал собственный инструмент в SQL Server 2000, используя O-SQl. Он взял бы файл SQL и выполнил бы его в каждой базе данных на сервере. Он должен был выполнить его на каждом сервере, но он превзошел выполнение на каждой БД. Я также помог написать инструмент VB.net, который бы делал то же самое, за исключением того, что он также просматривал список серверов, поэтому его нужно было выполнить только один раз.
5) Контроль источника. Моя нынешняя команда не использует систему контроля версий, и у меня нет достаточно времени, чтобы рассказать вам, сколько проблем это вызывает. Если у вас нет какой-либо системы контроля версий, получите ее.