Рекомендуемый подход, как изменить схему производственной базы данных SQL?

Question

Скажем, что есть база данных со 100 + столами и добавлена ​​основная функция, которая требует изменения 20 существующих таблиц и еще 30 добавленных. Изменения были сделаны в течение длительного времени (6 месяцев) несколькими разработчиками в базе данных разработки. Предположим, что изменения не приводят к тому, что какие-либо существующие производственные данные недействительны (например, в добавленных столбцах допустимы значения/значения по умолчанию), никаких новых отношений или ограничений, которые не могут быть выполнены, не существует).

Что является самым простым способом опубликовать эти изменения в схеме в производственной базе данных? Предпочтительно, без остановки базы данных в течение длительного времени.

Answer 1

Существует не общий ответ о том, как сделать «изменения» без простоя. Ответ действительно зависит от случая к случаю, основываясь на том, какие именно изменения. Некоторые изменения не влияют на время простоя (например, добавление новых таблиц), некоторые изменения оказывают минимальное влияние (например, добавление столбцов в существующие таблицы без изменения размера данных, например новый столбец с нулевым значением, который делает snot, увеличивая размер нулевой растровой карты) и другие изменения разрушат хаос во время простоя (любая операция, которая изменит размер данных, заставит и индексирует перестройку и заблокирует таблицу на время). Некоторые изменения невозможно применить без значительного * простоя. Я знаю случаи, когда изменения были применены параллельно: создается копия базы данных, репликация настроена так, чтобы она была актуальной, затем копия была изменена и сохранена в синхронизации, и, наконец, операции перемещаются в модифицированную копию, которая становится основная база данных. Существует презентация на PASS 2009 given by Michelle Ufford, в которой упоминается, как godaddy пережил такое изменение, которое длилось недель.

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

Но настоящий вопрос: это будет последние изменений, которые вы когда-либо делаете на схему? Наконец, вы обнаружили идеальную схему для приложения, и база данных производства никогда не изменится? Поздравляю, как только вы это сделаете, вы можете отправиться на отдых. Но реалистично, вы столкнетесь с той же проблемой через 6 месяцев. реальной проблемой является ваш процесс разработки, с разработчиками и внесение изменений из SSMS или VS Server Explored прямо в базу данных.Ваш процесс разработки должен предпринять сознательные усилия для принятия стратегии изменения схемы, основанной на версиях и сценариях T-SQL, например, описанных в Version Control and your Database.

Answer 2

Напишите сценарий T-SQL, который выполняет необходимые изменения. Проверьте его на копии вашей производственной базы данных (восстановление из последней резервной копии, чтобы получить копию). Исправьте неизбежные ошибки, которые обнаружит тест. Повторяйте, пока скрипт работает отлично.

Затем, когда пришло время для фактической миграции: заблокируйте БД, чтобы только администраторы могли войти в систему. Возьмите резервную копию. Запустите скрипт. Проверьте результаты. Верните DB обратно в Интернет.

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

Answer 3

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

Answer 4

Используйте инструмент для создания различий скрипта и запустить его во время окна обслуживания. Я использую RedGate SQL Compare для этого и был очень доволен этим.