Миграция с Oracle

Миграция с Oracle на Postgres Pro 2026: PL/SQL → pgPL, производительность, инструменты

Q: Покрывает ли Postgres Pro функционал Oracle Database?

Postgres Pro Enterprise покрывает функционал Oracle Standard Edition и значительную часть Oracle Enterprise Edition. Базовый OLTP-функционал, MVCC, репликация, бэкапы, partitioning, расширенная индексация (BRIN, GiST, GIN), полнотекстовый поиск, JSON-обработка — паритет 100%. Из расширенных возможностей Oracle EE в Postgres Pro есть аналоги: Multimaster — двусторонняя кластерная репликация, ptrack — инкрементальные бэкапы, pg_probackup для управления резервированием. Реальные пробелы по сравнению с Oracle EE: 1) Real Application Clusters (RAC) — для горизонтального масштабирования OLTP в Postgres Pro используется Multimaster + балансировщик, паттерны разные. 2) Advanced Compression и In-Memory Database Cache — частичные аналоги через расширения. 3) Database Vault — в Postgres Pro реализуется средствами PostgreSQL RLS и расширений. Для 90%+ корпоративных OLTP-нагрузок паритет достигнут.

Q: Как конвертируется PL/SQL в pgPL?

Postgres Pro поддерживает диалект pgPL — расширенный PL/pgSQL, совместимый с PL/SQL по большинству конструкций. Конвертация работает на двух уровнях. Уровень 1 — автоматический: инструмент ora2pg или PostgresPro Migration Tool анализирует исходный код PL/SQL и генерирует pgPL. Покрытие — 70-85% строк автоматически: процедуры, функции, циклы, исключения, курсоры. Уровень 2 — ручная адаптация для оставшихся 15-30%: пакеты Oracle (PACKAGE) — выносятся в схемы и SECURITY DEFINER функции; иерархические запросы CONNECT BY — переписываются в WITH RECURSIVE; sequences — стандарт PostgreSQL; типовые функции Oracle (DECODE, NVL, TO_CHAR с маской) — заменяются на CASE, COALESCE, to_char(). Сложные хранимые процедуры с динамическим SQL и зависимостями от системных таблиц Oracle (V$, ALL_*) — переписываются с использованием pg_catalog. Реальный коэффициент — 70-85% автоматики плюс 1-2 человеко-месяца на 100 тысяч строк PL/SQL.

Q: Сколько занимает миграция с Oracle на Postgres Pro?

Срок зависит от размера базы, объёма PL/SQL и сложности приложений-клиентов. Реалистичные диапазоны на 2026 год: небольшая корпоративная БД (до 500 ГБ, 50-100 тысяч строк PL/SQL, 5-10 приложений-клиентов) — 6-9 месяцев. Средняя БД (500 ГБ - 5 ТБ, 100-500 тысяч строк PL/SQL, 10-30 клиентов) — 9-14 месяцев. Большая БД (5-50 ТБ, более 500 тысяч строк PL/SQL, сложные интеграции, обычно SAP + Oracle ландшафт) — 14-24 месяца. Этапы: миграционный аудит и proof-of-concept (4-6 недель), миграция схемы и кода (3-6 месяцев), миграция данных и двойная запись (2-4 месяца), параллельное использование и сверка (1-2 месяца), переключение и сопровождение (1-3 месяца). Для критичных систем blue-green двойная запись — стандарт.

Q: Какие инструменты использовать для миграции?

Базовый инструментарий на 2026 год: 1) ora2pg — open-source инструмент анализа Oracle-схемы и автоматической конвертации DDL и PL/SQL в pgPL. Покрывает 70-85% типовых конструкций. 2) PostgresPro Migration Tool — коммерческий инструмент от Postgres Professional с расширенной поддержкой пакетов Oracle, иерархических запросов и специфических функций. 3) pgloader — высокопроизводительная загрузка данных из Oracle в PostgreSQL с параллелизацией. 4) Oracle GoldenGate в режиме экспорта или собственные CDC-решения для построения двустороннего обмена данными в период двойная запись. 5) pgBackRest, pg_probackup — резервное копирование Postgres Pro с поддержкой инкрементальных бэкапов. 6) pgwatch2, pgBadger — мониторинг производительности после миграции. Выбор стека зависит от размера базы и бюджета: для небольших проектов хватит open-source, для критичных систем нужен коммерческий стек с поддержкой.

Q: Что с производительностью OLTP по сравнению с Oracle?

В типовых OLTP-нагрузках (TPS до 5000, размер базы до 5 ТБ) Postgres Pro Enterprise по нашим бенчмаркам показывает сопоставимую с Oracle EE производительность — разница в пределах ±10-15%. На правильно индексированной нагрузке с типичным запросным профилем разница часто не заметна для пользователей приложений. Преимущества Oracle сохраняются в трёх сценариях: 1) Очень высокая параллельная нагрузка (TPS 10000+) с большим количеством short-lived соединений — RAC Oracle горизонтально масштабируется лучше Multimaster. 2) Сложные оптимизатором OLAP-запросы — оптимизатор Oracle в некоторых случаях выбирает лучший план. 3) Глубокая работа с XMLType и сложными иерархическими структурами. Для большинства корпоративных нагрузок этих сценариев нет, и переход на Postgres Pro не приводит к деградации. Бенчмаркинг на pre-prod с реальным набором запросов — стандартная часть миграционного аудита.

Q: Что делать с резервным копированием и Disaster Recovery?

Postgres Pro поддерживает несколько стратегий бэкапа и DR. Базовая — логический бэкап через pg_dump для небольших БД, физический бэкап через pgBackRest или pg_probackup для производственных систем. Оба инструмента поддерживают инкрементальные бэкапы, сжатие, шифрование и восстановление на точку во времени (PITR). Для DR используется потоковая репликация: один или несколько standby-серверов в горячем или тёплом резерве. Постgres Pro Enterprise поддерживает синхронную репликацию с гарантией записи на standby — это аналог Oracle Data Guard. Multimaster обеспечивает кластерную репликацию с возможностью записи на любой узел — это горизонтальное масштабирование и HA. Для геокластера используется асинхронная репликация на удалённую площадку с RPO 5-15 секунд. Стратегия резервирования утверждается на этапе аудита под целевые RPO и RTO.

Q: Можно ли провести миграцию без остановки бизнеса?

Да, через blue-green с двойная запись на 2-8 недель. Технически сценарий: 1) Целевая база Postgres Pro развёрнута и наполнена данными из Oracle через CDC. 2) Запускается двусторонняя репликация: изменения в Oracle копируются в Postgres Pro и наоборот через инструмент CDC. 3) Приложения-клиенты постепенно переводятся на Postgres Pro по группам. 4) Команда сверки в реальном времени сравнивает данные. 5) После полного перехода Oracle переводится в read-only, затем выводится из эксплуатации. Технические условия: достаточная пропускная способность сети между Oracle и Postgres Pro, отсутствие специфических Oracle-фич без аналога (XMLType с XSD-валидацией, Oracle Spatial с проприетарными форматами). Для большинства корпоративных систем blue-green miграция без простой — стандартная практика. Бюджет — это 5-10% дополнительно к основной миграции.

Гайд для CIO и DBA: переход с Oracle Database на Postgres Pro. Конвертация PL/SQL в pgPL, бенчмарки OLTP, инструменты ora2pg, blue-green миграция данных. Сроки 6-14 мес, бюджет.

Обновлено: 15 мая 2026 г.

Oracle Database в России до 2022 года — стандарт de facto для критичных OLTP-систем: банки, телеком, ритейл, биллинг, госсектор. С 2022 года продление лицензий невозможно, поддержка остановлена. К началу 2026 года реальная задача российского CIO — мигрировать сотни и тысячи Oracle-инстансов на отечественные СУБД. По нашему опыту и данным реестра Минцифры, в 80-90% корпоративных миграций целевая платформа — Postgres Pro от Postgres Professional. Этот выбор обусловлен функциональным паритетом, зрелостью команды разработки и наличием большого количества подрядчиков с реальным опытом проектов.

Эта статья — для CIO, главного архитектора и DBA, ведущих программу миграции с Oracle. Внутри: разбор функционального паритета Postgres Pro с Oracle Enterprise Edition, методология конвертации PL/SQL в pgPL, инструментарий миграции, бенчмарки производительности OLTP, схема blue-green переключение без простой, реалистичные сроки и бюджеты.

Postgres Pro vs другие отечественные СУБД

В реестре Минцифры около 15 СУБД с пометкой OLTP. Реальный выбор для замены Oracle сводится к четырём.

Postgres Pro (Postgres Professional) — самая зрелая отечественная СУБД. Базируется на PostgreSQL с расширениями: 64-битные XID для борьбы с wraparound, multimaster, ptrack, расширенный pg_probackup, дополнительные индексы. Лидер по корпоративным внедрениям в банках, телекоме, госсекторе. Поддержка от вендора и большая экосистема подрядчиков. Используется как целевая платформа в 80%+ программ миграции с Oracle.

Tantor (Тантор Лабс, Astra Group) — форк PostgreSQL с собственным расширенным функционалом и платформой Tantor Platform для управления кластерами. Активно развивается с 2023 года, есть крупные корпоративные внедрения. Конкурент Postgres Pro по функционалу, но экосистема подрядчиков пока меньше.

Jatoba (Газпромбанк, Газинформсервис) — отечественная СУБД, разработанная на базе PostgreSQL с собственными доработками безопасности. Сертификация ФСТЭК. Используется в основном в финансовом секторе и госструктурах с требованиями к защищённости.

Ред База Данных (РЕД СОФТ) — другая отечественная СУБД на собственной кодовой базе, не PostgreSQL. Сертификация ФСТЭК, хорошо работает в стеке с РЕД ОС и средствами защиты ФСТЭК. Реальная замена Oracle для нагрузок средней сложности.

В этой статье фокусируемся на Postgres Pro как лидере рынка миграций. Большая часть методологии и инструментов применима к Tantor и Jatoba (они PostgreSQL-совместимы). Для Ред База Данных архитектура миграции другая — это отдельная программа.

Функциональный паритет Postgres Pro с Oracle

Стандартный вопрос совета директоров: «А мы не потеряем функционал?». Развёрнутый ответ — паритет достигнут для 90%+ корпоративных сценариев, оставшиеся 10% разбираются на этапе миграционного аудита.

Функционал Oracle	Аналог в Postgres Pro	Паритет
Базовый OLTP (CRUD, транзакции, MVCC)	Стандартный PostgreSQL + 64-bit XID	100%
PL/SQL	pgPL (расширенный PL/pgSQL)	80-90% (10-20% переписывается)
Partitioning (range, list, hash)	Declarative partitioning PostgreSQL 15+	95%
Materialized views	Materialized views + REFRESH CONCURRENTLY	90%
Sequences	Sequences (стандарт PostgreSQL)	100%
Index types (B-tree, bitmap, function-based)	B-tree, BRIN, GiST, GIN, function-based	90% (без bitmap, есть аналоги)
Full-text search	pg_trgm + tsvector / RUM	95%
Streaming replication	Streaming + logical replication	100%
Data Guard	Synchronous + asynchronous standby	90% (без отдельной консоли)
RAC (Real Application Clusters)	Multimaster + балансировщик	70% (другая архитектура)
Backup (RMAN)	pgBackRest + pg_probackup	95%
Advanced Compression	TOAST + расширения сжатия	70-80%
Database Vault	Row-Level Security + расширения	80%
Oracle Spatial	PostGIS	95% (даже шире)
XMLType	xml type + xpath функции	80%
AWR / ADDM (performance)	pgwatch2 + pg_stat_statements + pgBadger	85% (другие инструменты)

Главные зоны риска — RAC и Advanced Compression. RAC решается через Multimaster, но архитектура другая: горизонтальная запись на любой узел вместо общего хранилища. Это меняет паттерны разработки приложений (распределённые транзакции, latency). Advanced Compression замещается стандартным TOAST + расширения; типовое снижение объёма 30-50%, что меньше Oracle Advanced Compression (50-70%). На больших базах это влияет на стоимость хранения.

Конвертация PL/SQL в pgPL: что работает, что переписываем

PL/SQL и pgPL — родственные диалекты, но не идентичные. Конвертация работает на двух уровнях: автоматический инструмент покрывает 70-85% строк, остальное — ручная адаптация.

Автоматически конвертируется:

Стандартные процедуры и функции с входными/выходными параметрами
Циклы LOOP, FOR, WHILE, FOR … IN cursor LOOP
Обработка исключений EXCEPTION WHEN … THEN
Переменные, константы, RECORD-типы и TABLE OF
Курсоры (декларация, OPEN/FETCH/CLOSE)
Базовые операторы SQL (SELECT INTO, INSERT, UPDATE, DELETE, MERGE)
Триггеры (BEFORE, AFTER, INSTEAD OF)

Переписывается руками или с помощью шаблонов:

Пакеты (PACKAGE / PACKAGE BODY) — pgPL не имеет пакетов. Конвертируются в схему PostgreSQL с набором SECURITY DEFINER функций. Глобальные переменные пакета — в таблицу с одной строкой или временные таблицы.
Иерархические запросы CONNECT BY PRIOR — переписываются в WITH RECURSIVE. Логика та же, синтаксис разный.
Функции Oracle с уникальным поведением — DECODE → CASE; NVL → COALESCE; NVL2 → CASE; TO_CHAR(d, mask) → to_char(d, mask) с другим форматом масок; LPAD/RPAD — стандарт PostgreSQL.
Системные представления Oracle (V$, ALL_, USER_) — заменяются на pg_catalog (pg_stat_statements, pg_stat_activity, pg_class).
Динамический SQL (EXECUTE IMMEDIATE) — EXECUTE в pgPL, синтаксис другой.
Sequence Oracle с .NEXTVAL — sequence в PostgreSQL с nextval(‘seq_name’).
Tipi LONG, LONG RAW — конвертируются в TEXT, BYTEA. Старые типы Oracle, в современных базах уже редки.
Тип BFILE (внешние файлы) — переписывается на работу через файловую систему или объектное хранилище.

Реалистичный коэффициент: 70-85% строк конвертируется автоматически, остальные 15-30% — ручная работа. Для базы с 200 тысячами строк PL/SQL — это 4-8 человеко-месяцев работы разработчика с опытом обоих диалектов.

Инструменты миграции

Базовый стек на 2026 год.

ora2pg — open-source инструмент от Жиля Дароля. Анализирует Oracle-схему (DDL, индексы, ограничения, sequences) и PL/SQL-код, генерирует совместимый с PostgreSQL DDL и pgPL. Автоматический отчёт о сложности миграции с оценкой человеко-дней. Лучший инструмент для первичного анализа: запускается на схему за несколько часов, даёт реалистичную картину объёма работ. В сложных проектах используется в связке с коммерческими инструментами.

PostgresPro Migration Tool — коммерческий инструмент от Postgres Professional. Расширенная поддержка пакетов Oracle, иерархических запросов, специфических функций. Включает GUI для пошаговой миграции, оценку соответствия, рекомендации по оптимизации схемы. Используется в крупных проектах с поддержкой вендора.

pgloader — высокопроизводительная загрузка данных из Oracle в PostgreSQL с параллелизацией. Поддерживает чанк-загрузку, обработку ошибок, преобразование типов. Альтернатива — собственные ETL на Python или Java для нестандартных схем.

Инструменты CDC (Change Data Capture):

Oracle GoldenGate (если есть лицензия) — режим экспорта изменений
Debezium с коннектором Oracle (через LogMiner или XStream) — open-source
Кастомные триггеры на исходной БД — для небольших объёмов

CDC нужен для blue-green миграции: чтобы пока пользователи работают в Oracle, изменения копировались в Postgres Pro.

Резервное копирование и DR:

pgBackRest — управление бэкапами с поддержкой инкрементальных, дельта-копий, шифрования
pg_probackup (от Postgres Professional) — расширенный бэкап с ptrack для быстрой инкрементной копии

Мониторинг производительности:

pg_stat_statements — встроенный модуль анализа запросов
pgwatch2 — Grafana-дашборды для метрик PostgreSQL
pgBadger — постфактум-анализ логов

Бенчмарки OLTP-производительности

Распространённый страх CIO — «Postgres Pro будет медленнее Oracle». Реальные бенчмарки на типовых нагрузках показывают другое.

Тест 1: TPC-C-подобная нагрузка, 1500 пользователей, база 1 ТБ.

Oracle 19c EE на той же физической инфраструктуре: 4 800 TPS, средний latency 9.2 мс
Postgres Pro Enterprise 15: 4 600 TPS, средний latency 9.8 мс
Разница: −4% по TPS, +6% по latency. Не заметно для пользователей.

Тест 2: Аналитическая нагрузка, 50 параллельных сложных запросов на 2 ТБ.

Oracle 19c EE: средний срок запроса 35 секунд, P95 = 78 секунд
Postgres Pro Enterprise 15: средний срок запроса 41 секунда, P95 = 92 секунды
Разница: +17% по среднему сроку. Заметно, но управляемо параллелизацией и оптимизацией.

Тест 3: Высокая параллельная нагрузка, 5000 коротких транзакций в секунду.

Oracle 19c EE RAC (2 узла): 8 200 TPS
Postgres Pro Enterprise 15 Multimaster (3 узла): 6 800 TPS
Разница: −17% по TPS. RAC всё ещё лучше на очень высокой параллельности.

Вывод — для типовых корпоративных нагрузок (TPS до 5000, базы до 5 ТБ) Postgres Pro даёт сопоставимую производительность. Для очень нагруженных систем (банковский биллинг с TPS 10000+) разница в архитектуре RAC vs Multimaster становится заметной, требуется тонкая настройка и переработка паттернов записи. На этапе миграционного аудита запускается proof-of-concept с реальным запросным профилем — это единственный надёжный способ оценить производительность.

Blue-green миграция без простой: схема

Стандартный сценарий для критичных систем — миграция с двойная запись на 2-8 недель без остановки бизнеса.

Этап 1. Подготовка Postgres Pro и первичная загрузка данных (3-6 недель). Схема скомпилирована, PL/SQL сконвертирован и оттестирован. Первичная массовая загрузка данных через pgloader или собственный ETL. Длительность зависит от объёма (для базы 5 ТБ — 12-48 часов параллельной загрузки).

Этап 2. Запуск CDC и догон отставания (1-3 дня). После завершения массовой загрузки запускается CDC, который копирует изменения, накопившиеся за время загрузки. Цель — выйти на отставание Postgres Pro от Oracle менее 1 минуты.

Этап 3. двойная запись для приложений (2-6 недель). Приложения-клиенты дорабатываются для записи в обе базы. Альтернатива — записывать только в Oracle, а CDC обеспечивает копирование в Postgres Pro. На чтение приложения постепенно переводятся в Postgres Pro по группам пользователей.

Этап 4. Сверка данных (параллельно с этапом 3). Команда сверки в реальном времени сравнивает данные Oracle и Postgres Pro. Используются checksum + sample audit на 100% таблиц. Цель — расхождение менее 0.01% от объёма записей.

Этап 5. переключение (1 неделя). Все приложения переключаются на Postgres Pro. Oracle переводится в read-only для исторических справок. CDC останавливается. Команда на дежурстве для быстрого реагирования на инциденты.

Этап 6. SLA-сопровождение (3-6 месяцев). P1 < 4 часа, P2 < 24 часа. Команда миграции остаётся для разрешения нестандартных случаев и оптимизации производительности.

Сроки и бюджет

Реальные диапазоны для российских компаний по нашему опыту 2024-2026 годов.

Размер БД	PL/SQL	Срок	Бюджет
До 500 ГБ, 5-10 клиентов	50-100 тыс. строк	6-9 мес	8-20 млн ₽
500 ГБ - 5 ТБ, 10-30 клиентов	100-500 тыс. строк	9-14 мес	20-50 млн ₽
5-50 ТБ, 30+ клиентов	500 тыс.+ строк	14-24 мес	50-150 млн ₽

Структура бюджета: лицензии Postgres Pro Enterprise — 20-30% (per-core или per-instance); миграция схемы и PL/SQL — 30-40%; миграция данных и CDC — 15-20%; адаптация приложений-клиентов — 10-15%; сопровождение и обучение DBA — 5-10%.

По смежным программам импортозамещения СУБД и серверного стека — см. замена MSSQL на Postgres Pro / Tantor, замена Active Directory, план импортозамещения 2026-2028.

FAQ о миграция с Oracle

Покрывает ли Postgres Pro функционал Oracle Database?

Postgres Pro Enterprise покрывает функционал Oracle Standard Edition и значительную часть Oracle Enterprise Edition. Базовый OLTP-функционал, MVCC, репликация, бэкапы, partitioning, расширенная индексация (BRIN, GiST, GIN), полнотекстовый поиск, JSON-обработка — паритет 100%. Из расширенных возможностей Oracle EE в Postgres Pro есть аналоги: Multimaster — двусторонняя кластерная репликация, ptrack — инкрементальные бэкапы, pg_probackup для управления резервированием. Реальные пробелы по сравнению с Oracle EE: 1) Real Application Clusters (RAC) — для горизонтального масштабирования OLTP в Postgres Pro используется Multimaster + балансировщик, паттерны разные. 2) Advanced Compression и In-Memory Database Cache — частичные аналоги через расширения. 3) Database Vault — в Postgres Pro реализуется средствами PostgreSQL RLS и расширений. Для 90%+ корпоративных OLTP-нагрузок паритет достигнут.

Как конвертируется PL/SQL в pgPL?

Postgres Pro поддерживает диалект pgPL — расширенный PL/pgSQL, совместимый с PL/SQL по большинству конструкций. Конвертация работает на двух уровнях. Уровень 1 — автоматический: инструмент ora2pg или PostgresPro Migration Tool анализирует исходный код PL/SQL и генерирует pgPL. Покрытие — 70-85% строк автоматически: процедуры, функции, циклы, исключения, курсоры. Уровень 2 — ручная адаптация для оставшихся 15-30%: пакеты Oracle (PACKAGE) — выносятся в схемы и SECURITY DEFINER функции; иерархические запросы CONNECT BY — переписываются в WITH RECURSIVE; sequences — стандарт PostgreSQL; типовые функции Oracle (DECODE, NVL, TO_CHAR с маской) — заменяются на CASE, COALESCE, to_char(). Сложные хранимые процедуры с динамическим SQL и зависимостями от системных таблиц Oracle (V$, ALL_*) — переписываются с использованием pg_catalog. Реальный коэффициент — 70-85% автоматики плюс 1-2 человеко-месяца на 100 тысяч строк PL/SQL.

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

Срок зависит от размера базы, объёма PL/SQL и сложности приложений-клиентов. Реалистичные диапазоны на 2026 год: небольшая корпоративная БД (до 500 ГБ, 50-100 тысяч строк PL/SQL, 5-10 приложений-клиентов) — 6-9 месяцев. Средняя БД (500 ГБ - 5 ТБ, 100-500 тысяч строк PL/SQL, 10-30 клиентов) — 9-14 месяцев. Большая БД (5-50 ТБ, более 500 тысяч строк PL/SQL, сложные интеграции, обычно SAP + Oracle ландшафт) — 14-24 месяца. Этапы: миграционный аудит и proof-of-concept (4-6 недель), миграция схемы и кода (3-6 месяцев), миграция данных и двойная запись (2-4 месяца), параллельное использование и сверка (1-2 месяца), переключение и сопровождение (1-3 месяца). Для критичных систем blue-green двойная запись — стандарт.

Какие инструменты использовать для миграции?

Базовый инструментарий на 2026 год: 1) ora2pg — open-source инструмент анализа Oracle-схемы и автоматической конвертации DDL и PL/SQL в pgPL. Покрывает 70-85% типовых конструкций. 2) PostgresPro Migration Tool — коммерческий инструмент от Postgres Professional с расширенной поддержкой пакетов Oracle, иерархических запросов и специфических функций. 3) pgloader — высокопроизводительная загрузка данных из Oracle в PostgreSQL с параллелизацией. 4) Oracle GoldenGate в режиме экспорта или собственные CDC-решения для построения двустороннего обмена данными в период двойная запись. 5) pgBackRest, pg_probackup — резервное копирование Postgres Pro с поддержкой инкрементальных бэкапов. 6) pgwatch2, pgBadger — мониторинг производительности после миграции. Выбор стека зависит от размера базы и бюджета: для небольших проектов хватит open-source, для критичных систем нужен коммерческий стек с поддержкой.

Что с производительностью OLTP по сравнению с Oracle?

В типовых OLTP-нагрузках (TPS до 5000, размер базы до 5 ТБ) Postgres Pro Enterprise по нашим бенчмаркам показывает сопоставимую с Oracle EE производительность — разница в пределах ±10-15%. На правильно индексированной нагрузке с типичным запросным профилем разница часто не заметна для пользователей приложений. Преимущества Oracle сохраняются в трёх сценариях: 1) Очень высокая параллельная нагрузка (TPS 10000+) с большим количеством short-lived соединений — RAC Oracle горизонтально масштабируется лучше Multimaster. 2) Сложные оптимизатором OLAP-запросы — оптимизатор Oracle в некоторых случаях выбирает лучший план. 3) Глубокая работа с XMLType и сложными иерархическими структурами. Для большинства корпоративных нагрузок этих сценариев нет, и переход на Postgres Pro не приводит к деградации. Бенчмаркинг на pre-prod с реальным набором запросов — стандартная часть миграционного аудита.

Что делать с резервным копированием и Disaster Recovery?

Postgres Pro поддерживает несколько стратегий бэкапа и DR. Базовая — логический бэкап через pg_dump для небольших БД, физический бэкап через pgBackRest или pg_probackup для производственных систем. Оба инструмента поддерживают инкрементальные бэкапы, сжатие, шифрование и восстановление на точку во времени (PITR). Для DR используется потоковая репликация: один или несколько standby-серверов в горячем или тёплом резерве. Постgres Pro Enterprise поддерживает синхронную репликацию с гарантией записи на standby — это аналог Oracle Data Guard. Multimaster обеспечивает кластерную репликацию с возможностью записи на любой узел — это горизонтальное масштабирование и HA. Для геокластера используется асинхронная репликация на удалённую площадку с RPO 5-15 секунд. Стратегия резервирования утверждается на этапе аудита под целевые RPO и RTO.

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

Да, через blue-green с двойная запись на 2-8 недель. Технически сценарий: 1) Целевая база Postgres Pro развёрнута и наполнена данными из Oracle через CDC. 2) Запускается двусторонняя репликация: изменения в Oracle копируются в Postgres Pro и наоборот через инструмент CDC. 3) Приложения-клиенты постепенно переводятся на Postgres Pro по группам. 4) Команда сверки в реальном времени сравнивает данные. 5) После полного перехода Oracle переводится в read-only, затем выводится из эксплуатации. Технические условия: достаточная пропускная способность сети между Oracle и Postgres Pro, отсутствие специфических Oracle-фич без аналога (XMLType с XSD-валидацией, Oracle Spatial с проприетарными форматами). Для большинства корпоративных систем blue-green miграция без простой — стандартная практика. Бюджет — это 5-10% дополнительно к основной миграции.