Практика SQL Server

Изменение схемы без отказа работающих приложений

Согласуйте схему, заполнение данных, совместную работу версий и границы отката при поэтапном внедрении.

Миграция схемы может завершиться успешно, а приложение перестать работать. При постепенном обновлении старые и новые процессы используют одну базу. Переименование столбца или немедленное обязательное заполнение нового поля способно сломать оставшуюся старую версию. Единицей внедрения является договор кода и данных.

Сначала совместимое расширение

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

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

CREATE TABLE #Orders(OrderId int PRIMARY KEY, Amount decimal(12,2));
INSERT #Orders VALUES(1,10),(2,20);
ALTER TABLE #Orders ADD CurrencyCode char(3) NULL;
UPDATE #Orders SET CurrencyCode='USD' WHERE CurrencyCode IS NULL;
SELECT OrderId,Amount,CurrencyCode FROM #Orders ORDER BY OrderId;
IF EXISTS(SELECT 1 FROM #Orders WHERE CurrencyCode IS NULL)
    THROW 50000, 'Backfill is incomplete.', 1;
ALTER TABLE #Orders ALTER COLUMN CurrencyCode char(3) NOT NULL;

В рабочей системе сначала определите заполнение CurrencyCode новыми операциями. USD верен только из-за объявленного смысла учебных данных. Удобный default не определяет настоящую валюту исторических заказов. Неизвестные значения нужно выяснять, а не заменять выдуманными фактами.

Согласование конкурентных изменений

При двух представлениях установите основное для каждой фазы. Двойные записи должны быть атомарными либо сверяться. Иначе ошибка изменит только одну сторону. Резервное чтение может поддерживать доступность и одновременно скрывать расхождения. Измеряйте их до переключения читателей.

Большую таблицу заполняйте возобновляемыми пакетами по стабильному диапазону ключей. Условие не должно перезаписывать более новые значения приложения. Фиксируйте прогресс вместе с изменениями, если он должен переживать сбой. Ограничение изменённых строк не ограничивает автоматически чтения и журнал, создаваемый индексами и триггерами.

Изменения схемы могут ждать долгие транзакции. Задайте подходящие тайм-аут и повтор, исследуйте блокировщиков и не запускайте новые миграции, пока прежняя продолжает ожидать. Возможности online зависят от операции, версии и редакции и не означают полного отсутствия блокировок.

Граница безопасного отката

Перед удалением подтвердите, что поле не требуется поддерживаемым версиям, отчётам, заданиям, экспорту и динамическому SQL. Каталоги помогают, но не находят все строки, собранные вне базы. Дополните инвентаризацию наблюдаемым выполнением и испытанием смешанных версий.

Откат кода прост, пока база поддерживает старый договор. Новые значения могут быть непредставимыми в прежнем формате. Тогда возврат теряет смысл данных, даже если старый столбец существует. Документируйте последнюю обратимую фазу и восстановление с сохранением информации после неё.

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

Удаление старой формы выделяйте в отдельный выпуск после подтверждённой стабильности. Оставьте старый процесс работающим на протяжении всего теста: полный перезапуск лаборатории скрывает проблемы совместного использования. Проверьте ночные задания, экспорт и пул соединений. Установите также период наблюдения, охватывающий редко запускаемые процедуры. Для каждой фазы должно быть понятно, кто читает, кто пишет, какие значения считаются основными и какой возврат ещё сохраняет смысл. Именно эта проверяемая последовательность делает изменение схемы управляемым, а не один успешно выполненный ALTER TABLE.

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

Техническая документация: Microsoft Learn: ALTER TABLE · Microsoft Learn: Dependency metadata.

Вопрос по статье

Есть вопрос по этой теме?

Расскажите, что вы оцениваете или с какой проблемой столкнулись. Мы ответим с практической рекомендацией.

Inquiries are not enabled in this preview.

Задать вопрос по этой статье