Скрипты ручного запуска не будут работать. Ни разные инструменты, к слову. Diff работает для 2,4 или 10 баз данных. Но не масштабируется, потому что вам нужна надежность при наличии сбоев (автономные базы данных, сервер перезапускает все это).
Развертывание осуществляется путем планирования сценариев обновления. Например, посмотрите, как MySpace делает это для более 1000 баз данных: MySpace использует SQL Server Service Broker для защиты целостности 1 петабайта данных . главное, что они используют гарантированный, надежный механизм доставки (SSB) для развертывания сценариев обслуживания схемы. Вам нужен асинхронный, надежный механизм для запуска сценариев, поскольку целевые базы данных могут быть автономными, выполнять плановое обслуживание, unreacahbe и т. Д., А также надежный механизм доставки, такой как Service Broker, может обрабатывать все повторные попытки и связанные с этим проблемы (обработка дубликатов, подтверждений и т. Д.). Вы также можете посмотреть Асинхронное выполнение процедуры , чтобы узнать, как обрабатывать выполнение скрипта через SSB.
Что касается самих сценариев, я рекомендую вам начать рассматривать схему базы данных и данные конфигурации как версионный ресурс. Я уже несколько раз решал эту проблему, например. см. Положите ли вы статические данные вашей базы данных в систему управления версиями? Как?
Обновление
Полагаю, у меня есть какое-то объяснение, почему я считаю неправильным подход. Просто чтобы прояснить ситуацию, я говорю о развертывании сотен серверов и тысяч баз данных. Оригинальный пост сравнивает себя с Facebook, и я желаю им успеха в достижении этого размера, но также задаются вопросы о принципах проектирования , поэтому я говорю, что обсуждение масштабирования на уровне облаков уместно.
Я вижу две проблемы с инструментами сравнения:
Доступность. Все инструменты сравнения работают, подключаясь как к «мастеру», так и к «копии», поэтому они могут выполнять свою работу только тогда, когда оба находятся в сети. Это создает «горячую точку», единственную точку отказа, «главную» копию, доступность которой становится критической для развертывания обновлений. Высокая доступность всегда приходит за плату. Это также оставляет проблему доступности «копии» как второстепенные детали реализации, схема обновления должна обрабатывать повторные попытки и тайм-ауты и отключаться от клиента самостоятельно (ни в коем случае не тривиальная проблема).
Атомарность. Инструменты diff ожидают стабильной схемы 'master'. Это фактически останавливает «мастера» во время обновления. Несмотря на то, что этим можно управлять в небольшом масштабе, в больших масштабах это становится проблемой, поскольку обновление самого мастера до v. N + 1 становится гонкой против всех тысяч баз данных, хотя некоторые из них все еще могут обновляться с v. N-1. .
Решения на основе сценариев, которые поставляют сценарий обновления в «копию», решают обе эти проблемы. Кроме того, инструменты сравнения, такие как vsdbcmd.exe , основанные на VSDB .dbschema, лучше, чем «живой» инструмент сравнения, поскольку файл «master» dbschema может быть доставлен на машину «копирования» и превращает весь процесс обновления в локальная операция.
В целом, я также верю, что обновление на основе сценариев с использованием управления версиями метаданных лучше, чем обновление на основе diff, из-за причин тестирования и контроля исходного кода, о которых я уже говорил в ссылке на Q1525591.