Обновление MS SQL Server между мажорными версиями

Обновление MS SQL Server между мажорными версиями

Обновление SQL Server с устаревшей версии на современную — это не просто запустить Setup.exe и нажать Next. В нашей практике был кейс: клиент обновился без предварительного тестирования, и за ночь деградировали 15% запросов из-за изменений в оптимизаторе при повышении compatibility level. В понедельник утром production лежал. Наш опыт 10+ лет в миграции SQL Server позволяет гарантировать безопасный переход. Правильный upgrade — это проект на несколько недель, а не несколько часов. По статистике Microsoft, более 75% сбоев при обновлении связаны с непроверенной совместимостью приложений. Оценим ваш проект и предложим оптимальный план — свяжитесь для консультации. Разберём ключевые изменения и процесс миграции.

Что меняется между версиями: критические различия

Каждая мажорная версия несёт изменения в Cardinality Estimator, синтаксисе T-SQL, поведении функций и ограничениях. Compatibility level базы данных частично изолирует от этих изменений — но не полностью.

Ключевые изломы при переходе через несколько версий:

• Новый Cardinality Estimator (CE) — переписывает оценки кардинальности. Запросы с множественными JOIN и корреляциями могут получить другие планы.
• Intelligent Query Processing (IQP) — автоматическая адаптация планов, batch mode on rowstore. В большинстве случаев улучшает производительность, но может удивить нестабильностью планов первые дни.
• Parameter Sensitive Plan optimization — улучшенный Degree of Parallelism Feedback. Accelerated Database Recovery (ADR) изменяет поведение transaction log.

Какой способ миграции выбрать?

Три подхода, у каждого свои компромиссы:

In-place upgrade — запуск Setup.exe поверх существующей установки. Минимальные усилия, один downtime. Риск: нет rollback без восстановления из бэкапа. Подходит для Dev/Test.

Side-by-side migration — новый сервер с новой версией, перенос баз через backup/restore или detach/attach. Позволяет проверить совместимость до переключения. Production downtime — только время переноса последней транзакции и переключения DNS/connection strings. Рекомендуемый подход для продакшна.

Log shipping / AG as migration tool — настраиваем Always On AG или Log Shipping между старым и новым сервером, синхронизируем, делаем failover. Downtime измеряется минутами. Сложнее в реализации, но идеально для баз с требованием минимального RTO.

По данным Microsoft, side-by-side migration снижает риски на 80% по сравнению с in-place upgrade. — SQL Server Upgrade Guide

Предварительный аудит — 80% успеха

-- Проверить текущий compatibility level всех баз
SELECT name, compatibility_level, state_desc, recovery_model_desc
FROM sys.databases
WHERE database_id > 4 -- исключаем системные
ORDER BY name;

-- Deprecated features, которые будут удалены в новой версии
SELECT * FROM sys.dm_os_performance_counters
WHERE counter_name = 'Deprecated features' AND cntr_value > 0;

-- Проверка использования deprecated синтаксиса
-- (нужно включить trace flag или Extended Events сессию)
CREATE EVENT SESSION [DeprecatedFeatures] ON SERVER
ADD EVENT sqlserver.deprecation_announcement,
ADD EVENT sqlserver.deprecation_final_support
ADD TARGET package0.ring_buffer
WITH (STARTUP_STATE = ON);

ALTER EVENT SESSION [DeprecatedFeatures] ON SERVER
STATE = START;

-- Объекты, использующие устаревший синтаксис (пример для GROUP BY ALL, *= JOIN)
SELECT OBJECT_NAME(object_id), definition
FROM sys.sql_modules
WHERE definition LIKE '%GROUP BY ALL%'
   OR definition LIKE '%*=%'
   OR definition LIKE '%=%*%';

-- Linked servers, которые могут потребовать перенастройки
SELECT name, product, provider, data_source
FROM sys.servers
WHERE is_linked = 1;

Почему нужно тестировать на новом compatibility level?

Даже с сохранением старого compatibility level некоторые изменения поведения не блокируются. Например, новые версии могут изменить порядок сортировки или обработку NULL в inline-функциях. Поэтому обязателен период мониторинга с Query Store.

Процесс side-by-side миграции

Шаг 1: Установка нового сервера. Новый SQL Server устанавливается с теми же collation настройками (критично! изменение collation после установки невозможно без переустановки). Проверяем: SELECT SERVERPROPERTY('Collation') на старом сервере.

Шаг 2: Миграция системных объектов. Логины, роли, linked servers, SQL Agent jobs — они в системных базах, не переносятся с пользовательскими базами автоматически.

-- Скрипт для генерации CREATE LOGIN для всех SQL логинов
SELECT 'CREATE LOGIN [' + name + '] WITH PASSWORD = 0x' + CONVERT(VARCHAR(MAX), password_hash, 2) + ' HASHED, ' +
       'SID = 0x' + CONVERT(VARCHAR(MAX), sid, 2) + ', ' +
       'CHECK_EXPIRATION = ' + CASE is_expiration_checked WHEN 1 THEN 'ON' ELSE 'OFF' END + ', ' +
       'CHECK_POLICY = ' + CASE is_policy_checked WHEN 1 THEN 'ON' ELSE 'OFF' END + ';'
FROM sys.sql_logins
WHERE name NOT LIKE '##%' AND name != 'SA';

Шаг 3: Тестирование на новой версии с сохранением старого compatibility level. Восстанавливаем базы на новом сервере, оставляем compatibility level как на старом. Прогоняем нагрузочные тесты и проверяем application logs.

-- Оставить старый compatibility level после restore
ALTER DATABASE AppDB SET COMPATIBILITY_LEVEL = 140;
-- предыдущий уровень на новом сервере
-- Query Store для сравнения производительности до/после
ALTER DATABASE AppDB SET QUERY_STORE = ON
(
    OPERATION_MODE = READ_WRITE,
    INTERVAL_LENGTH_MINUTES = 30,
    MAX_STORAGE_SIZE_MB = 2000
);

Шаг 4: Постепенное поднятие compatibility level. Не поднимаем сразу на максимальный — идём по шагам, после каждого шага период мониторинга.

-- Использовать Query Tuning Assistant (QTA) для сравнения планов
-- после изменения compatibility level
-- В SSMS: Management -> Query Store -> Query Tuning Assistant
-- Проверить регрессии через Query Store
SELECT TOP 20
    q.query_id,
    qt.query_sql_text,
    rs_before.avg_duration / 1000.0 AS avg_ms_before,
    rs_after.avg_duration / 1000.0 AS avg_ms_after,
    (rs_after.avg_duration - rs_before.avg_duration) / rs_before.avg_duration * 100 AS pct_change
FROM sys.query_store_query q
JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
-- ... (join с двумя периодами runtime stats)
WHERE rs_after.avg_duration > rs_before.avg_duration * 1.5 -- деградация > 50%
ORDER BY pct_change DESC;

Шаг 5: Переключение production. Finalize: меняем connection strings или DNS, переводим старый сервер в readonly, мониторим первые 48 часов.

Типичные проблемы при обновлении

Что входит в работу (deliverables)

• Полный аудит совместимости с отчетом по deprecated features.
• План миграции с пошаговым расписанием.
• Настройка тестовой среды и нагрузочное тестирование.
• Миграция с минимальным downtime.
• Документация по новому окружению и обучение команды.
• Поддержка после перехода в течение 48 часов.

Сроки и ориентировочная стоимость

Стоимость рассчитывается индивидуально после аудита текущей инфраструктуры. Получите консультацию — оценим ваш проект за 1 день.

Дополнительную информацию можно найти в официальной документации Microsoft по обновлению SQL Server.