Требования Указа № 166 и приказов Минцифры закрыли путь к продлению лицензий Oracle и Microsoft SQL Server для значимых объектов КИИ. Уходить с зарубежных СУБД приходится не «когда-нибудь», а в этом бюджетном году. Главный страх заказчиков – не выбор платформы, а сама миграция: данные продакшена нельзя остановить на выходные, а откатить наполовину перенесённую базу почти невозможно. Перенос без простоя – вопрос плана, а не везения.

Сначала аудит, потом инструменты

Прежде чем выбирать целевую платформу, посчитайте, что именно вы переносите. Инвентаризируйте объём данных, число таблиц, хранимые процедуры, триггеры, представления и внешние интеграции. Отдельно отметьте проприетарные конструкции – пакеты PL/SQL, иерархические запросы CONNECT BY, специфичные типы Oracle. Эти места дадут до 70% трудозатрат проекта.

Параллельно зафиксируйте требования к простою. Для биллинга или АБС допустимое окно – минуты, для внутреннего хранилища отчётности – часы. От этой цифры зависит стратегия: разовый дамп ночью или непрерывная репликация с переключением. Не путайте миграцию СУБД с уходом от прикладного ПО – если вы одновременно сворачиваете поддержку SAP, разделите эти проекты по срокам, иначе риски сложатся.

Выбор стратегии переноса

Подходов три, и выбор диктует допустимое окно простоя.

  • Big bang – остановили источник, перенесли дамп, запустили целевую базу. Просто и дёшево, но требует длинного окна и честного отката. Годится для систем, которые переживут ночь обслуживания.
  • Параллельная работа – старая и новая СУБД работают одновременно, приложение пишет в обе. Сложно в коде, зато даёт спокойный переходный период и быстрый откат.
  • Логическая репликация с дозаливкой – переносите исторические данные заранее, а изменения догоняете CDC-потоком вплоть до момента переключения. Простой сокращается до минут переключения трафика.

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

Целевую платформу выбирайте из реестра отечественного ПО – Postgres Pro, Tantor, Jatoba. Их совместимость с PostgreSQL упрощает перенос, но расширения и системные функции всё равно проверяйте поштучно.

Проверка целостности и переключение

Перенос без сверки – не миграция, а лотерея. Заложите три уровня контроля: совпадение числа строк по таблицам, контрольные суммы по ключевым полям и бизнес-сверку отчётов на одинаковую дату в обеих системах. Расхождение в финансовых остатках на одну копейку обнаружится позже и дороже.

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

Не забудьте про периферию. Мобильные клиенты и выездные приложения кешируют данные локально и переживают переключение бэкенда хуже стационарных рабочих мест – их тестируйте отдельно.

Вывод

Перенос данных без простоя – это аудит проприетарных конструкций, репликация под допустимое окно и трёхуровневая сверка с готовым откатом. Везение тут не нужно – нужен план и репетиция переключения на тестовом контуре. Сама миграция СУБД проходит проще, когда инвентаризация источников и приёмка целевого хранилища выстроены в единый процесс с самого начала.