Уход с Oracle обычно вызван не техническими причинами, а прекращением поддержки и невозможностью продлить лицензии. Это значит, что сроки внешние и сдвинуть их нельзя — тем важнее начать с честной оценки объёма.

Шаг первый: инвентаризация

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

  • Схема: таблицы, индексы, представления, последовательности, ограничения.
  • Логика: пакеты, процедуры, функции, триггеры, задания планировщика.
  • Потребители: все приложения и скрипты, которые ходят в базу напрямую.
  • Профиль нагрузки: самые частые и самые тяжёлые запросы, время отклика по ним.
  • Специфичные для Oracle возможности: иерархические запросы, аналитические функции, секционирование, работа с датами.

Шаг второй: оценка совместимости

Автоматические конвертеры переносят структуру почти полностью и часть логики. Но конвертер переносит синтаксис, а не смысл: результат надо читать. Практика показывает, что от четверти до половины процедур требуют ручной работы, и именно эта доля определяет срок проекта.

Оценка «перенесём за месяц» без чтения хранимых процедур — почти всегда обещание, которое не сбудется.

Шаг третий: перенос на тестовый контур

  1. Переносим схему и данные, сверяем количество записей и контрольные суммы по ключевым таблицам.
  2. Конвертируем логику, каждую сконвертированную процедуру проверяем на тестовых данных.
  3. Переносим права и роли — они почти никогда не переносятся автоматически.
  4. Переводим задания планировщика и следим, чтобы они не запустились дважды.
  5. Правим приложения там, где они используют специфичный для Oracle синтаксис.

Шаг четвёртый: нагрузка

Планировщик PostgreSQL работает иначе, и запросы, которые в Oracle летали, могут внезапно замедлиться в десятки раз. Поэтому после переноса обязателен прогон реального профиля запросов, настройка индексов и параметров, а иногда и переписывание отдельных запросов. Здесь и пригождается базовый замер, снятый на первом шаге.

Шаг пятый: параллельный период и переключение

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

Что чаще всего ломается

  • Работа с датами и часовыми поясами — поведение отличается, и это всплывает в отчётах.
  • Пустая строка и NULL: в Oracle это одно и то же, в PostgreSQL — нет. Ломается логика сравнений.
  • Регистр имён объектов: Oracle приводит к верхнему, PostgreSQL — к нижнему.
  • Автономные транзакции, которых в PostgreSQL нет и которые приходится переписывать.
  • Иерархические запросы: переписываются через рекурсивные общие табличные выражения.

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

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

Типовая база — один-три месяца вместе с параллельным периодом. Основное время уходит на логику, а не на данные.

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

Да. Перенос идёт на тестовом контуре, остановка нужна только на само переключение и обычно измеряется часами.

Нужна ли сертифицированная сборка PostgreSQL?

Зависит от ваших требований к реестру и поддержке. Технически миграция от этого почти не меняется.

Смотрите также: миграция на PostgreSQL и разбор: перенос с MS SQL на PostgreSQL Ещё по теме: Миграция с Oracle на PostgreSQL: PL/SQL, данные, сроки.