Перенос базы с MS SQL на PostgreSQL к сроку
Перенос сверен построчно и по контрольным суммам, а откат отрепетирован до дня переключения
Проверяется: реестр зависимостей и протокол сверки
ГоссекторРаботаем по NDA
Дата перехода названа нормативно, а внутри нет точного перечня того, что на MS SQL держится. На базе висят хранимые процедуры, ночной планировщик, отчётность и несколько приложений, исходников которых уже нет ни у кого. Прошлая попытка переезда, если она была, обычно встала ровно здесь: конвертер перенёс таблицы, а процедуры и отчёты никто не взялся переписывать.
Что съедает срок и бюджет на самом деле
Почти никогда — не модель. Ниже места, из-за которых такие проекты встают, и что мы с каждым делаем.
T-SQL не переносится построчно
расходятся обработка ошибок, временные таблицы, курсоры, CROSS APPLY, работа с датами и поведение при NULL. Отдельная ловушка — правила сортировки: после переноса отчёты начинают выдавать другой порядок строк и другие границы группировок, и внешне это выглядит как «неверные данные», хотя данные перенесены корректно.
Приложения без исходников общаются с базой собственными запросами
Пока эти запросы не сняты трассировкой с работающей системы за представительный период, включая закрытие месяца, объём миграции неизвестен, и любая оценка будет угадыванием.
Задания SQL Server Agent, пакеты SSIS и отчёты SSRS прямых аналогов не имеют и переезжают в другие инструменты
Это отдельная строка трудоёмкости, которую в оценках чаще всего забывают, а она нередко сопоставима с переносом самой базы.
План выполнения на новой платформе строится иначе, и часть запросов деградирует
При этом окно переключения ограничено, а перенос сотен гигабайт занимает часы, значит нужен способ догнать изменения, накопившиеся за время переноса, и отрепетированный откат с условием, при котором он запускается.
Ограничение, которое определяет решение
Срок и сам факт перехода задаёт регулятор: для госорганизаций, госкомпаний и значимых объектов КИИ действуют требования по переходу на программное обеспечение из единого реестра российского ПО, и по классу «СУБД» срок — январь 2027. Это ограничивает выбор целевой платформы: она должна присутствовать в реестре, а условия поддержки вендора — покрывать срок эксплуатации системы. Аттестация объекта информатизации и оценка соответствия по ГОСТ Р 57580 — лицензируемые работы и выполняются организацией с лицензией ФСТЭК, отдельно от работ по переносу.
Как проверить, что работа сделана
Приёмка держится на трёх предметах, каждый из которых проверяется числами. Сверка данных: по каждой таблице количество строк и контрольные суммы до и после переноса, все расхождения объяснены письменно.
Сверка результата: набор ключевых отчётов запускается на одинаковых входных данных на старой и новой системе, результаты сравниваются построчно, порядок сортировки проверяется отдельным пунктом, потому что ломается он чаще всего. Сверка времени: список ключевых запросов с замером на обеих платформах, ни один не выходит за порог, согласованный до начала работ.
Дополнительно администратор заказчика сам выполняет учебное восстановление из резервной копии с замером времени, а откат репетируется до окна переключения, а не описывается на бумаге.
О чём спросить любого подрядчика
- Первый вопрос — как подрядчик собирается узнать запросы приложений, у которых нет исходников.
- Если ответа про трассировку работающей системы нет, объём работ ему неизвестен, и названная сумма ничем не обеспечена.
- Второй — есть ли в предложении отдельные строки на планировщик и отчётность: их отсутствие означает, что половину задачи обнаружат в середине проекта.
- Третий — считается ли трудоёмкость по позициям, с числом процедур и часами на каждую, или названа одна общая сумма.
- Четвёртый — существует ли план отката с записанным условием запуска и репетируется ли он до окна переключения.
- И отдельно: обещание «конвертер перенесёт всё автоматически» проверяется просьбой показать отчёт конвертера по вашей базе — в нём сразу видно, сколько объектов помечено как непереносимые.
Порядок работ по этапам
На каждом этапе назван результат, который остаётся у заказчика. На проверке — признак, по которому работу не приняли бы.
- Трассировка запросовПеречня зависимостей внутри не было, поэтому фактические обращения к MS SQL сняли трассировкой на работающей системе — так нашли и приложения, у которых нет исходников. Отдельно выписали хранимые процедуры, задания планировщика и отчётные формы.
- Стенд-двойникРешили переносить по собранному реестру зависимостей, а не по документации, и подняли стенд-двойник, чтобы репетировать переход и возврат столько раз, сколько потребуется. Порядок сортировки вынесли в отдельный вопрос: правила сравнения строк задали явно, не полагаясь на настройки по умолчанию.
- Перенос кодаПеренесли схему и данные, переписали несовместимый код процедур, перевели задания планировщика и отчётность на PostgreSQL. Приложения без исходников подключали через совместимый слой доступа и по трассировке убеждались, что уходят те же запросы.
- Сверка и откатСверили строки и контрольные суммы по таблицам, отдельно прогнали сортировку и отчётные формы, отрепетировали возврат на исходную базу. Провалом считали расхождение контрольной суммы хотя бы по одной таблице и отчёт, где строки встали в другом порядке; без успешной репетиции отката переход не согласовали бы.
- Передача администраторамПередали реестр зависимостей, перенесённую базу с протоколом сверки, план перехода и процедуру возврата. Администраторы прошли переход и откат на стенде-двойнике своими руками, прежде чем работать с боевым контуром.
Как это устроено внутри
Реестр зависимостей собран не из документации, а из трассировки: сборщик на Kotlin читает поток фактических запросов с боевого MS SQL Server и раскладывает вызовы по объектам, приложениям и учётным записям в PostgreSQL. Схема и данные переносятся pgloader, дальнейшие изменения структуры идут только миграциями Liquibase, потому что часть приложений поставляется без исходников и правки руками на стенде терялись бы при следующем накате. Сверка построчная: служба на Ktor читает обе базы по JDBC пачками по ключу и сравнивает контрольные суммы полей, порядок сортировки проверяется отдельно на ICU-коллациях — выборки с ORDER BY по русским строкам расходились с прежним сервером. Стенд-двойник разворачивается плейбуками Ansible из того же описания, что и целевой контур, поэтому репетиция перехода и процедура возврата выполняются одними и теми же шагами.
- Kotlin
- Ktor
- PostgreSQL
- MS SQL Server
- JDBC
- Ansible
- Liquibase
- pgloader
- ICU-коллации
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.