Рекомендуемый подход, как изменить схему производственной базы данных SQL?
Скажите, что существует база данных с 100 +, таблицы и основная функция добавляются, который требует, чтобы 20 из существующих таблиц были изменены и 30 более добавленных. Изменения были сделаны за долгое время (6 месяцев) несколькими разработчиками на базе данных разработки. Давайте предположим, что изменения не делают существующие производственные данные недопустимыми (например, существует значение по умолчанию, оценивает/аннулирует позволенный добавленными столбцами, нет никаких новых отношений или ограничений, которые не могли быть выполнены).
Что самый легкий путь состоит в том, чтобы опубликовать эти изменения в схеме к производственной базе данных? Предпочтительно, не завершая работу базы данных для расширенного количества времени.
4 ответа
Не существует общего ответа на вопрос о том, как внести "изменения" без простоя. Ответ действительно зависит от каждого конкретного случая, основываясь на том, что именно является изменениями. Некоторые изменения не влияют на время простоя (например, добавление новых таблиц), некоторые изменения имеют минимальное влияние (например, добавление столбцов в существующие таблицы без изменения размера данных, например, новый nullable столбец, который не увеличивает размер null bitmap), а другие изменения приведут к хаосу во время простоя (любая операция, которая изменит размер данных, заставит перестроить индекс и заблокировать таблицу на время). Некоторые изменения невозможно применить без *значительного* простоя. Я знаю случаи, когда изменения применялись параллельно: создается копия базы данных, настраивается репликация для поддержания ее в актуальном состоянии, затем копия изменяется и синхронизируется, наконец, операции переносятся на измененную копию, которая становится основной базой данных. На конференции PASS 2009 Мишель Уффорд представила презентацию, в которой упоминалось, как компания godaddy прошла через такие изменения, длившиеся несколько недель .
Но в меньшем масштабе вы должны применять изменения через хорошо протестированный сценарий и измерять воздействие на тестовую оценку.
Но главный вопрос заключается в том, будут ли это последние изменения, которые вы когда-либо вносили в схему? Наконец, вы нашли идеальную схему для приложения, и производственная база данных никогда не изменится? Поздравляю, как только вы справитесь с этой задачей, можете идти отдыхать. Но в реальности вы столкнетесь с той же проблемой через 6 месяцев. Настоящая проблема заключается в вашем процессе разработки, в котором разработчики вносят изменения из SSMS или из VS Server Explored прямо в базу данных. Ваш процесс разработки должен прилагать сознательные усилия для принятия стратегии изменения схемы на основе версионности и сценариев T-SQL, подобной той, что описана в Контроль версий и ваша база данных.
Напишите сценарий T-SQL, выполняющий необходимые изменения. Протестируйте его на копии вашей производственной базы данных (восстановите из последней резервной копии, чтобы получить копию). Исправьте неизбежные ошибки, которые обнаружит тест. Повторяйте, пока сценарий не заработает идеально.
Затем, когда пришло время собственно миграции: заблокируйте БД, чтобы только администраторы могли войти в систему. Сделайте резервную копию. Запускаем скрипт. Проверить результаты. Верните БД в оперативный режим.
Самая длинная часть - это резервное копирование, но вы были бы сумасшедшим, если бы этого не сделали. Вы должны знать, сколько времени занимает резервное копирование, общий процесс не займет много времени, так что именно столько времени должно быть у вас на время простоя. Середина ночи подходит для большинства предприятий.
Используйте инструмент для создания сценария сравнения и запускайте его во время окна обслуживания. Я использую для этого RedGate SQL Compare и очень им доволен.
Я успешно использую dbdeploy уже несколько лет. Он позволяет вашим разработчикам создавать небольшие sql-изменения, которые затем могут быть применены к вашей базе данных. Изменения отслеживаются по таблице changelog в базе данных, так что она знает, что применять.