Миграция с Oracle на PostgreSQL: чек-лист без потерь

Oracle ушёл из России в 2022 году - но тысячи баз всё ещё работают на нём без патчей безопасности. Если вы дочитаете эту статью до конца, у вас будет конкретный план: что проверить, что переписать, как перенести данные без простоя и не потерять производительность.

Почему Oracle → PostgreSQL - это не замена файла

Многие думают: экспортировал дамп, импортировал - готово. На практике за этим скрываются несовместимые типы данных, другая NULL-семантика, отсутствие пакетов PL/SQL и принципиально иная работа sequence.

Главные архитектурные различия

Oracle и PostgreSQL - разные СУБД с разной философией. Вот ключевые различия, которые важны именно при миграции:

Аспект	Oracle	PostgreSQL
NULL vs пустая строка	'' = NULL	'' ≠ NULL
Тип DATE	Дата + время (до секунд)	Только дата
Boolean	Нет нативного; 0/1 через NUMBER	Нативный BOOLEAN
Пакеты PL/SQL	Встроены, >200 системных	Нет в ванильном PG
Автономные транзакции	Нативно	Только через расширения
Коллекции (VARRAY, nested table)	Нативно в PL/SQL	Только в Postgres Pro Enterprise 16
Sequence	Независимый объект	Независимый объект, но старт по умолчанию = 1

Если приложение писало пустую строку вместо NULL - после миграции запросы WHERE field IS NULL перестанут находить эти строки. Молча.

Что исчезнет и потребует переработки

Перед стартом составьте список объектов-проблематик:

Хранимые процедуры и функции - синтаксис PL/SQL не совместим с PL/pgSQL один к одному
Пакеты Oracle - в open-source PostgreSQL их нет; расширение orafce покрывает только 7 из 200+ системных пакетов
Автономные транзакции (PRAGMA AUTONOMOUS_TRANSACTION) - в ванильном PostgreSQL отсутствуют, эмулируются через dblink или pg_background
Коллекции (VARRAY, nested table, ассоциативные массивы) - требуют полного переписывания или перехода на Postgres Pro Enterprise 16
BFILE, LONG, LONG RAW - нет прямого аналога в PostgreSQL
Системные пакеты (UTL_SMTP, UTL_HTTP, DBMS_LOB и др.) - нужны либо Postgres Pro, либо ручная реализация

Oracle ушёл из РФ: сроки - не ваш союзник

С 2022 года компании, оставшиеся на Oracle, работают без официальных обновлений и поддержки. Небольшие банки и госсектор всё ещё «пережидают» - но уязвимости накапливаются. По данным PGConf.Russia 2025, реальные кейсы показывают: переход возможен даже с базами объёмом 40 ТБ при правильной поэтапной стратегии.

Аудит: чек-лист «что есть в вашей базе»

Прежде чем выбирать инструменты - инвентаризируйте объекты. Без этого оценка трудозатрат - угадывание.

Инвентаризация объектов

Выполните в Oracle:

-- Количество объектов по типам
SELECT object_type, COUNT(*)
FROM all_objects
WHERE owner = 'YOUR_SCHEMA'
GROUP BY object_type
ORDER BY COUNT(*) DESC;

-- Типы данных всех колонок
SELECT DISTINCT data_type
FROM all_tab_columns
WHERE owner = 'YOUR_SCHEMA'
ORDER BY data_type;

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

Таблица маппинга типов данных Oracle → PostgreSQL

Тип Oracle	Тип PostgreSQL	Примечание
NUMBER(p,s)	NUMERIC(p,s)	Или INTEGER/BIGINT для целых
NUMBER(1,0)	BOOLEAN	Часто используется как флаг
VARCHAR2(n)	VARCHAR(n) или TEXT	TEXT без ограничения длины
DATE	TIMESTAMP	Oracle DATE содержит время!
TIMESTAMP	TIMESTAMP	Обычно прямой маппинг
CLOB	TEXT	Без ограничения длины
BLOB	BYTEA	Бинарные данные
LONG / LONG RAW	TEXT / BYTEA	⚠️ Устаревшие типы, нужна ручная обработка
BFILE	Нет прямого аналога	В Postgres Pro Enterprise - технология BFile
ROWNUM	LIMIT / ROW_NUMBER()	Разная семантика в подзапросах

Скрытые ловушки: не дайте им найти вас на проде

Sequence и коллизии ID. При создании sequence в PostgreSQL стартовое значение по умолчанию = 1. Если исторические данные содержат ID выше 1 - новые записи будут конфликтовать с ними. Нужно явно задать START WITH выше максимального существующего ID.

ROWNUM vs LIMIT. В Oracle WHERE ROWNUM < 10 работает до ORDER BY. В PostgreSQL нужен LIMIT - и он применяется после сортировки. Логика может измениться.

CONNECT BY → WITH RECURSIVE. Иерархические запросы Oracle с CONNECT BY переписываются в рекурсивные CTE (WITH RECURSIVE). Это не автоматически - каждый случай нужно проверить.

DECODE → CASE. DECODE(col, val1, res1, val2, res2, default) становится CASE WHEN col = val1 THEN res1 .... Инструменты часто конвертируют автоматически, но всегда перепроверяйте.

Три стратегии переноса: выбирайте осознанно

Офлайн-миграция: просто, но требует простоя

Останавливаете систему → переносите через ora2pg → поднимаете PostgreSQL. Инструменты: ora2pg, fdw, pg_dump-совместимые утилиты.

Когда подходит: допустимо окно простоя от нескольких часов; небольшой объём данных; нет жёстких SLA на доступность.

Когда не подходит: продуктовые системы с круглосуточной нагрузкой.

Онлайн-миграция через CDC: нулевой даунтайм

Это выбор для систем, которые нельзя останавливать.

Как это работает:

Oracle продолжает работать - приложение пишет в него
Debezium читает redo log через LogMiner и стримит изменения в Kafka
Sink-коннектор переносит события в PostgreSQL
После выравнивания лага до нуля - переключаете трафик на новые поды

Важные условия для Debezium + LogMiner:

Включить архивное логирование Oracle: SELECT LOG_MODE FROM V$DATABASE; - должно быть ARCHIVELOG
Имена таблиц и колонок - не длиннее 30 символов (ограничение LogMiner)
Каждая таблица должна иметь первичный ключ
Рекомендуемые образы: Debezium 3.0, Kafka, Zookeeper, Kafka UI

Авторская ремарка. На одном из проектов из-за активных DELETE-операций в нескольких таблицах лаг резко вырос и чуть не сорвал окно переключения. Решение - перейти на soft delete (флаг IS_DELETED) вместо физических удалений на время миграции. Это не интуитивно, но спасает нервы.

Dual write: максимальная консистентность

Новые данные пишутся одновременно в Oracle и PostgreSQL. Читает приложение сначала из Oracle, потом переключается на PostgreSQL. Rollback - просто останавливаете запись в PostgreSQL.

Цена: дополнительные доработки приложения, поддержка двух источников правды. Выбирайте, если потеря даже нескольких секунд данных недопустима.

Пошаговый чек-лист миграции (от аудита до продакшена)

Шаги 1–5: подготовка схемы и кода

Инвентаризация всех объектов Oracle: all_objects, all_tab_columns, all_constraints
Составить таблицу маппинга типов данных для вашей схемы
Очистить базу от устаревших данных (уменьшает объём миграции)
Запустить ora2pg или ora2pgpro в режиме аудита: ora2pg -t SHOW_REPORT
Перенести DDL через Liquibase с разделением DDL/DML через context

О выборе инструмента конвертации. ora2pg - open-source, стандарт де-факто. ora2pgpro от Postgres Professional - коммерческая доработка, поддерживает пакеты Oracle, коллекции и автономные транзакции напрямую. По расчётам Postgres Professional, ora2pgpro сокращает трудозатраты на миграцию до 50%.

Шаги 6–10: доработка кода приложения

Заменить @Lob → @Column(columnDefinition = "text") (для Java/Hibernate-проектов)
Исправить обработку NULL в нативных запросах, особенно в IN-конструкциях
Переписать логику пустой строки: в Oracle '' = NULL, в PostgreSQL - нет
Заменить NUMBER(1,0) / 0/1 → BOOLEAN во всех слоях
Сдвинуть все sequence выше максимального ID в исторических данных

Шаги 11–15: перенос данных

Отключить FK (ALTER TABLE ... DISABLE TRIGGER ALL) и тяжёлые индексы на время bulk-вставки
Настроить Debezium source-коннектор (LogMiner) и sink-коннектор (JDBC PostgreSQL)
Включить Avro + Schema Registry (Apicurio): это сжимает трафик до 10–15 раз и снижает нагрузку на Kafka

# Проверить статус лага Debezium через Kafka Connect API
curl -s http://localhost:8083/connectors/YOUR_CONNECTOR/status | jq '.tasks[].state'

Следить за лагом в Kafka UI: при приближении лага к нулю - переходить к шагу 15
Явно ограничить количество соединений Debezium: без этого коннектор заберёт весь пул PostgreSQL

Шаги 16–20: переключение и закрытие

Дождаться лага = 0 (полная синхронизация Oracle и PostgreSQL)
Поднять поды на PostgreSQL, восстановить FK и индексы, запустить smoke-тесты
Сохранить дамп Oracle как последний рубеж безопасности на 30+ дней
Провести нагрузочное тестирование под реальным трафиком
Настроить мониторинг: pg_stat_activity, pg_stat_statements, alerting на connection pool

Производительность: правда без иллюзий

Где PostgreSQL сопоставим, где отстаёт

В стандартных OLTP-нагрузках PostgreSQL показывает сопоставимую с Oracle производительность. При экстремальных объёмах и нагрузках Oracle исторически был устойчивее - но это не абсолютный закон. ⚠️ Предположительно, точных данных в открытом доступе нет - требуется тестирование на вашей конкретной нагрузке.

Postgres Pro Enterprise рассчитан на инсталляции до 150 ТБ и более 10 000 одновременных пользователей. Его клиенты - РЖД, Росатом, Газпромнефть, ФНС, Федеральное казначейство.

Что настроить после миграции

Oracle-оптимизированные запросы в PostgreSQL могут работать иначе. После переключения обязательно:

Настройте work_mem (по умолчанию 4 МБ - часто мало для сложных запросов)
Проверьте планы запросов через EXPLAIN ANALYZE для топ-20 тяжёлых запросов
Настройте autovacuum - Oracle DBA часто недооценивают его важность
Используйте pgBouncer для управления пулом соединений
Добавьте pg_stat_statements для мониторинга медленных запросов

Postgres Pro vs ванильный PostgreSQL: критерии выбора

Выбирайте ванильный PostgreSQL, если:

Нет хранимых процедур и пакетов PL/SQL
База до 5 ТБ
Бизнес-логика полностью на уровне приложения

Выбирайте Postgres Pro Enterprise, если:

Есть пакеты PL/SQL и автономные транзакции
База > 10 ТБ
Критичны системные пакеты Oracle (UTL_SMTP, DBMS_LOB и др.)
Нужна ФСТЭК-сертификация
Важна поддержка от российского вендора

Авторская ремарка. На PGConf.Russia 2025 был представлен кейс миграции промышленной базы объёмом ~40 ТБ с Oracle на PostgreSQL с использованием ora2pg и поэтапной стратегии. Десятки экземпляров PostgreSQL заменили один большой Oracle. Это работает - но требует тщательного планирования шардирования и балансировки нагрузки.

Альтернативная точка зрения

Не все эксперты считают миграцию срочной. По данным ComNews за октябрь 2025 года, часть малых и средних банков сознательно остаётся на Oracle, надеясь на возвращение вендора или переход к другому коммерческому решению. Это рискованная, но реальная позиция: если ваша система некритична для госрегулирования и вы готовы к рискам безопасности без патчей - у вас есть выбор. Однако для государственных систем и компаний под регуляторными требованиями РФ откладывать миграцию становится всё сложнее.

Нетривиальные факты

Debezium по умолчанию передаёт данные в JSON, и в каждом Kafka-сообщении дублируется полная схема таблицы. При базе с миллионом изменений это легко превращается в ~3 ГБ лишнего трафика. Переход на Avro + Schema Registry (Apicurio) сжимает сообщения в 10–15 раз - без потери данных и с автоматической регистрацией схем. На крупных проектах это существенно снижает нагрузку на Kafka-кластер.

FAQ

Сколько времени занимает миграция с Oracle на PostgreSQL?

Зависит от объёма базы и сложности PL/SQL-логики. Небольшая схема без процедур - от 2–4 недель. Крупная корпоративная система с сотнями пакетов - от 3 до 12 месяцев. ora2pgpro сокращает трудозатраты примерно вдвое по сравнению с ручной конвертацией.

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

Да. CDC через Debezium + Kafka: Debezium читает redo log Oracle через LogMiner и стримит изменения в PostgreSQL. После выравнивания лага до нуля переключаете трафик. Метод требует ARCHIVELOG mode в Oracle и первичных ключей на всех таблицах.

Что делать с хранимыми процедурами и пакетами PL/SQL?

Простые процедуры ora2pg конвертирует автоматически. Пакеты Oracle, автономные транзакции и коллекции (VARRAY, nested table) требуют ручной доработки или перехода на Postgres Pro Enterprise 16, который поддерживает эти конструкции нативно.

Упадёт ли производительность после перехода на PostgreSQL?

В OLTP-нагрузках PostgreSQL сопоставим с Oracle. Важен тюнинг: work_mem, shared_buffers, autovacuum, пул через pgBouncer. Oracle-оптимизированные запросы после миграции проверяйте через EXPLAIN ANALYZE. ⚠️ Точные результаты зависят от конкретной нагрузки - требуется тестирование.

Как проверить корректность переноса данных?

Сравните COUNT(*) по каждой таблице в Oracle и PostgreSQL. Проверьте суммы по числовым полям. Запустите ora2pg -t TEST - он выведет diff объектов между источником и целевой базой. Для критичных таблиц используйте выборочные хеш-запросы.

Главное различие NULL-семантики Oracle и PostgreSQL?

В Oracle пустая строка '' равна NULL. В PostgreSQL - нет: это разные значения. Условия WHERE field IS NULL для строк, записанных через Oracle, могут не найти ничего. Проверьте все SQL-условия и логику приложения до переключения.

Нужно ли переходить на Postgres Pro вместо ванильного PostgreSQL?

Не обязательно. Ванильный PostgreSQL подходит при отсутствии пакетов PL/SQL и базе до 5–10 ТБ. Postgres Pro Enterprise целесообразен при сложной Oracle-логике, объёме > 10 ТБ, требованиях ФСТЭК или LOB-данных типа BFILE.

Источники

Habr.com - «Сказ о том, как мы с Oracle на PostgreSQL переехали» - кейс онлайн-миграции Java-микросервисов через Debezium + Kafka без остановки сервиса.
Postgres Professional - «Облегчённая миграция с Oracle: как перейти на новую платформу» - описание ora2pgpro 2.0, поддержки пакетов Oracle, коллекций, автономных транзакций и системных пакетов в Postgres Pro Enterprise.
YouTube / Postgres Professional - «Миграция с Oracle: большая нагрузка и много шардов» - доклад Алексея Светличного на PGConf.Russia 2025, кейс замены одного большого Oracle десятками PostgreSQL.
PGConf.Russia 2026 - программа конференции, доклады по PostgreSQL и миграции Oracle.
YouTube / IT Elements - «Миграция с Oracle на PostgreSQL с помощью Конвертума: проект RUDATA группы "Интерфакс"» - кейс автоматической миграции с помощью инструмента Конвертум.
Microsoft Learn (RU) - «Преобразование приложений Oracle в PostgreSQL: ограничения» - документация по типам LONG, LONG RAW, BFILE и ограничениям конвертации.
ORA600 Forum - «Инструкция Ora2Pg» - практическое руководство по конфигурации и запуску ora2pg с примерами скриптов.
Habr / OTUS - «Как перейти с Oracle на PostgreSQL, используя Ora2Pg» - конфиги ora2pg, проверка корректности переноса, хеш-запросы.
PostgresPro - «PG performance comparison vs Oracle» - обсуждение сравнительной производительности.

Миграция с Oracle на PostgreSQL: полный чек-лист 2026