SQL Server 2005 SP1 и методичка миграции с 2000: первый клиент переехал

Когда Microsoft в апреле выкатил SP1 для SQL Server 2005, у нас в списке сопровождаемых серверов числилось три клиента, которые всё ещё сидели на SQL Server 2000. Не потому что не хотели переходить - просто каждый раз находились веские причины отложить: то 1С не проверена, то квартальный закрытие, то «лучше после нового года». Понять можно.

SP1 снял часть наших собственных сомнений. До него SQL Server 2005 RTM был с характером: несколько известных проблем со стабильностью движка, кое-что с LOB-полями, пара неприятных моментов в плане запросов. После SP1 картина заметно чище - Microsoft закрыл несколько сотен багов, включая вещи, которые в проде реально встречались. Мы решили, что теперь методичку по миграции можно писать всерьёз, а не «в теории».

Что проверяли перед переездом

Три блока, без которых к клиенту не шли.

Совместимость 1С 8.0. Это главный камень преткновения. У двух из трёх клиентов 1С 8.0 - рабочая лошадка, и поломать её в ходе миграции базы - значит остановить бизнес. Проверяли на тестовом стенде: разворачивали копию БД клиента на SQL Server 2005 SP1, поднимали 1С-сервер и гоняли основные операции - проведение документов, формирование регламентных отчётов, закрытие периода. Спойлер: заработало. Но не без нюансов: один из клиентских запросов от платформы 1С падал с ошибкой из-за разного поведения оптимизатора. Пришлось найти и разрешить через database compatibility level - временно выставили 80 (режим совместимости с SQL Server 2000), чтобы поведение запросов не менялось. Потом разберём по-нормальному.

Проверка хранимых процедур и UDF. У каждого клиента за годы накопился свой слой SP и функций - часть написана давно, часть дорабатывалась на ходу. В SQL Server 2005 ряд синтаксических конструкций ведёт себя строже: например, GROUP BY с неагрегированными колонками, которые SQL Server 2000 молча пропускал, теперь может не пройти. Прогоняли через SET QUOTED_IDENTIFIER, проверяли все UDF на совместимость типов. У первого клиента нашли четыре функции с проблемами - две поправили сразу, две оставили на после миграции с compatibility level 80.

Тест производительности. Переезд ради переезда нам не нужен - важно понять, что не хуже. Взяли набор самых тяжёлых запросов из рабочей базы первого клиента: ежедневный отчёт по остаткам, агрегация по продажам за квартал, несколько JOIN-ов по большим таблицам. Прогнали на SQL Server 2000 и на 2005 SP1 - по несколько раз, смотрели execution plan и фактическое время.

Результат оказался лучше, чем мы рассчитывали.

Первый клиент переехал - и что получилось

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

Когда в понедельник подтянули статистику - выигрыш по производительности запросов оказался около 30% на тех же серверах. Не от оптимизации, не от новых индексов - просто от смены движка. SQL Server 2005 SP1 заметно лучше строит планы выполнения для запросов с подзапросами и вложенными агрегациями. Плюс улучшенное управление памятью: под тем же объёмом рабочей нагрузки сервер перестал страдать от pressure на buffer pool так, как это было на 2000-м.

Клиент доволен. Мы тоже - без затрат на железо получили резерв производительности, который позволит нормально расти ещё пару лет без апгрейда.

Что осталось

Два клиента пока ждут. У одного - 1С и кастомные SP, там проверки займут ещё несколько недель. У второго - вопрос с окном обслуживания: бизнес работает шесть дней в неделю, подходящего момента пока нет. Планируем взяться в августе.

Методичку мы сделали, обкатали на первом случае - теперь она стала заметно конкретнее. Весь процесс - часть того, чем занимается сопровождение серверной инфраструктуры: не просто «сервер работает», а плановое движение вперёд, когда экосистема созрела.