Миграция с Oracle на PostgreSQL: пошаговый план для крупных БД 2026

Чёткий план миграции с Oracle на PostgreSQL для нагруженных систем: от инвентаризации схемы до переключения трафика и оптимизации после релиза.

миграция Oracle ora2pg импортозамещение Postgres Pro

Уход Oracle с российского рынка и требования по импортозамещению по 187-ФЗ и Указу №166 заставляют крупные компании переводить ядро бизнеса на PostgreSQL. В большинстве проектов 1IT мы видим базы 5-50 ТБ с тысячами пакетов PL/SQL — миграция таких систем требует не скрипта, а программы из 6-8 этапов.

С чего начать: инвентаризация и оценка стоимости

Перед запуском миграции команда «Первый ИТ Альянс» проводит аудит исходной БД. Главный инструмент — отчёт ora2pg --type SHOW_REPORT, который оценивает сложность переноса в человеко-днях и подсвечивает несовместимые конструкции.

Размер схемы, количество таблиц, индексов, партиций
Использование Oracle-специфичных фич: AQ, Spatial, Text, Java in DB
Объём PL/SQL: пакеты, триггеры, функции, materialized views
Зависимости приложений: JDBC, ODBC, ORM, BI-системы
RPO/RTO требования и допустимое окно простоя

Выбор целевой СУБД: ванильный PostgreSQL или Postgres Pro

Для систем КИИ обычно выбирают Postgres Pro Enterprise или Tantor — они входят в реестр отечественного ПО и поддерживают 64-битные транзакции, инкрементальные бэкапы CFS, многомастер. Для остальных задач достаточно PostgreSQL 16 на Astra Linux SE или РЕД ОС.

Перенос схемы и данных через ora2pg

Установить ora2pg, настроить ORACLE_DSN и параллелизм (PARALLEL_TABLES = 8-16)
Сгенерировать DDL: ora2pg -t TABLE,SEQUENCE,VIEW,INDEX,TRIGGER
Перенести типы данных: NUMBER → numeric, VARCHAR2 → varchar, CLOB → text
Скопировать данные через COPY с разбивкой по партициям
Создать FK и индексы после загрузки — это в 5-10 раз быстрее
Сверить контрольные суммы по каждой таблице

Что делать с PL/SQL и хранимой логикой

Это самый болезненный этап. ora2pg конвертирует ~70% кода автоматически, остальное переписывается вручную на PL/pgSQL. Иерархические запросы CONNECT BY заменяются на рекурсивные CTE, MERGE — на INSERT ON CONFLICT, аналитика DECODE — на CASE.

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

Запускаем параллельную репликацию через Oracle GoldenGate или Debezium + Kafka. Приложение переключается на PostgreSQL в режиме read-only, прогоняем нагрузочное тестирование на проде в течение 7-14 дней, затем cut-over в субботу ночью с откатным планом на 48 часов.

После миграции: настройка и мониторинг

Тюнинг shared_buffers, effective_cache_size, work_mem под новый профиль нагрузки
Настройка autovacuum агрессивнее, чем по умолчанию
Подключение pg_stat_statements и pgBadger
Мониторинг через Zabbix + mamonsu или Prometheus + postgres_exporter
Регулярные тренировки восстановления из бэкапа

Частые вопросы

Сколько длится миграция БД на 10 ТБ?+

В среднем 6-9 месяцев: 2 месяца аудит и пилот, 3-4 месяца разработка и переписывание PL/SQL, 1 месяц нагрузочные тесты, 1-2 месяца сопровождение после cut-over.

Можно ли мигрировать без простоя?+

Да, через логическую репликацию (GoldenGate, SharePlex, Debezium). Окно переключения сокращается до 5-15 минут — это время DNS/коннект-стринг свитча.

Что делать с лицензиями Oracle после миграции?+

Поддержку можно отключить со следующего года, но сами бинари оставьте на 6-12 месяцев в режиме read-only — на случай экстренного отката или аудита.

Нужна помощь по этой теме?

Обсудим задачу и предложим план за 24 часа. Работаем с компаниями из России и СНГ с 1999 года.

Получить консультацию +7 (495) 648-68-37