Оновлення 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.