Не существует общего ответа о том, как вносить «изменения» без простоев. Ответ действительно зависит от случая к случаю, в зависимости от того, какие именно изменения. Некоторые изменения не влияют на время простоя (например, добавление новых таблиц), некоторые изменения оказывают минимальное влияние (например, добавление столбцов в существующие таблицы без изменения размера данных, как, например, новый обнуляемый столбец, который не увеличивает размер нулевого растрового изображения) и другие изменения приведут к хаосу во время простоя (любая операция, которая изменит размер данных, приведет к перестроению индекса и индексированию и блокировке таблицы на время). Некоторые изменения невозможно применить без * значительного * простоя. Мне известны случаи, когда изменения были применены параллельно: создается копия базы данных, настраивается репликация, чтобы поддерживать ее актуальность, затем копия изменяется и сохраняется в синхронизации, и, наконец, операции перемещаются в измененную копию, которая становится основная база данных. На PASS 2009 есть презентация, сделанная Мишель Аффорд , в которой упоминается, как крестный отец пережил такое изменение, которое длилось недели .
Но в меньшем масштабе вы должны применить изменения с помощью хорошо протестированного сценария и измерить влияние на оценку теста.
Но на самом деле вопрос заключается в следующем: будут ли последние изменения, которые вы когда-либо вносили в схему? Наконец, вы обнаружили идеальную схему для приложения, и рабочая база данных никогда не изменится? Поздравляю, как только вы это сделаете, вы можете отправиться отдыхать. Но реально вы столкнетесь с той же проблемой через 6 месяцев. настоящая проблема заключается в вашем процессе разработки с разработчиками и внесением изменений из SSMS или VS Server Explore прямо в базу данных. Ваш процесс разработки должен предпринять сознательные усилия для принятия стратегии изменения схемы, основанной на версиях и сценариях T-SQL, подобно описанной в Контроль версий и вашей базе данных .