Уровень совместимости: переход с измеримым результатом

Установка новой версии SQL Server и повышение уровня совместимости базы связаны, но являются разными изменениями. Если одновременно менять схему, индексы и приложение, объяснить регрессию значительно труднее. Контролируемый переход создаёт точки сравнения, позволяющие связать изменившееся поведение важных запросов с конкретным действием.

Создайте два отдельных исходных состояния

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

Следующий запрос только читает сведения в проверяемой базе. Представление Query Store требует прав просмотра, соответствующих установленной версии. Сохраните результат вместе с датой и идентификатором тестовой нагрузки.

SELECT SERVERPROPERTY('ProductVersion') AS EngineVersion;
SELECT name, compatibility_level
FROM sys.databases WHERE database_id=DB_ID();
SELECT actual_state_desc, desired_state_desc, readonly_reason,
       current_storage_size_mb, max_storage_size_mb
FROM sys.database_query_store_options;

Желаемое состояние READ_WRITE не доказывает фактическую запись Query Store. Проверьте реальное состояние, расход места и причину перехода в чтение. Правила сбора и хранения должны сохранять исходные данные до конца сравнения. Переполненное хранилище может прекратить запись именно тогда, когда свидетельства особенно нужны. Проверьте присутствие новых интервалов, а не только значение настройки.

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

Повышайте уровень отдельным экспериментом

На тестовом SQL Server 2022 базу с уровнем 150 можно отдельно проверить на 160. Закомментированный шаблон намеренно называет учебную базу. Перед адаптацией убедитесь в поддержке реальным движком. Число совместимости не устанавливает отсутствующую версию сервера.

-- Example only: SQL Server 2022, isolated practice database.
-- ALTER DATABASE [CompatibilityPractice]
-- SET COMPATIBILITY_LEVEL = 160;

Запишите время перехода, чтобы не смешивать интервалы Query Store до и после. Изменение может вызывать перекомпиляцию. Разделяйте начальную компиляцию, прогрев и устойчивое выполнение. Не очищайте весь кеш планов экземпляра как обычный шаг измерения: это отдельное воздействие на посторонние базы.

Сопоставляйте число выполнений и стоимость вместе. Улучшение среднего может скрыть редкий критический запрос, ставший намного медленнее. Рост суммарного CPU иногда означает лишь больше обращений. Проверяйте длительность, CPU, чтения, планы и конкуренцию важных запросов. Для распределения пользовательской задержки используйте телеметрию приложения, не ожидая всех процентилей от агрегированных интервалов Query Store.

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

Определите приёмку и настоящий возврат

Заранее задайте измеримые критерии: задержку критических операций, срок завершения пакета, ошибки и запас ресурсов при ожидаемой нагрузке. Назовите принимающего решение и период наблюдения. Успешное утро не проверяет месячный процесс. Сохраняйте также результаты функциональных проверок, поскольку правильность ответа важнее одного выигрыша времени.

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

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

Техническая документация: Microsoft Learn: Upgrade workflow · Microsoft Learn: Compatibility levels · Microsoft Learn: Query Store state.