Миграция с Oracle на PostgreSQL — это перенос поведения, а не только таблиц: PL/SQL, заданий, прав и привычек приложений. Начинаем с реестра объектов и запросов, переносим на стенд, сверяем данные, гоняем вашу нагрузку и переключаем с точкой отката. Oracle остаётся рабочим, пока новая база не отработала срок без замечаний.
Обследование и план — от 250 000 ₽, 2–3 неделиПеренос — от 800 000 ₽, цена после обследованияOracle — точка отката до конца параллельного периода
Первая из них объясняет, почему перенос ломается не на таблицах, остальные — как мы с этим работаем.
Данные переносятся предсказуемо. Дорого обходится поведение: как база обращается с пустой строкой, датой, ошибкой внутри транзакции. Код может отработать без единой ошибки и вернуть другой результат, поэтому мы проверяем смысл, а не синтаксис.
Что лежит в базе, кто к ней обращается и что она делает ночью — без этого срок и сумма превращаются в догадку. Обследование стека и план — от 250 000 ₽, цена фиксированная и вычитается из следующего этапа.
Инструменты вроде ora2pg считают объекты, переносят структуру и дают заготовку кода. Решает человек: каждую процедуру, триггер и пакет читают и сверяют на одинаковых данных. Отчёт конвертера по вашей базе показываем целиком.
До конца параллельного периода старая база остаётся рабочей и служит точкой отката. Остановка записи на переключении всё равно будет: её длину называем заранее и пишем в регламент, а не обещаем «без простоя».
Годами копились процедуры, триггеры и пакеты. Авторов нет, документации нет, а часть правил бизнеса существует только там.
Отчёты, скрипты и приложения подключаются напрямую. Часть из них без исходников, часть работает под чужими учётными записями.
Конвертер перенёс таблицы, дошёл до первой несовместимости и остановился. С тех пор ситуация не улучшилась.
Планировщик, ссылки на другие базы, выгрузки в файлы и по почте. О них вспоминают, когда ночью что-то не пришло.
Оптимизатор строит планы иначе, а подсказок в ядре нет. Запрос, который летал, может замедлиться, и узнать это нужно до переключения.
Лицензия или поддержка заканчиваются, а три подрядчика назвали три суммы. Частая причина расхождения — разный учёт логики: одни считают только таблицы, другие читают каждую процедуру.
Таблица — типовой список. В вашей базе встретится часть строк, и найти именно их — задача обследования. Версии и состав расширений уточняем для вашей сборки.
Те же места в виде пошагового плана разобраны в статье «Как перейти с Oracle на PostgreSQL». Здесь — то, что мы по каждому решаем на проекте.
Эти различия не дают сообщения об ошибке, поэтому находят их сравнением результатов, а не запуском. Слева привычное поведение Oracle, справа — что произойдёт, если перенести код без правок.
Отсюда правило приёмки: результаты процедур и отчётов сравниваем на одинаковых входных данных построчно, а порядок сортировки проверяем отдельным пунктом.
Этих вещей нет в списке таблиц, но их отсутствие замечают первыми.
Сценарии RMAN не переносятся. Строим копии с архивом журнала предзаписи, WAL (например, pgBackRest или Barman) и проверяем восстановление на точку во времени учебным запуском.
Аналога RAC в обычном PostgreSQL нет. Задачу решают репликацией и автоматическим переключением (например, Patroni); схему считаем под ваши требования к простою и потере данных.
Пользователей и роли переносим, но системные привилегии Oracle прямых аналогов не имеют, поэтому права сверяем по факту. Тонкий доступ по строкам собирается заново (row-level security), аудит даёт расширение вроде pgaudit. Прозрачное шифрование зависит от сборки: требования проверяем заранее.
Быстрого (инкрементального) обновления в ядре нет, обновление полное. Для больших представлений считаем время и при необходимости заменяем таблицей с догрузкой.
Механизмы вроде Advanced Queuing заменяют внешним брокером или таблицей-очередью с блокировкой строк. Выясняем, кто пишет в очередь и кто из неё читает.
В PostgreSQL каждое соединение — отдельный процесс, и очень много одновременных соединений обходится дорого. Ставим пул соединений (например, PgBouncer) и проверяем настройки приложений.
Без неё цена и срок — догадка. Все названия словарных представлений ниже — примеры, точный набор уточняем для вашей версии Oracle.
Если у приложения нет исходников, объём работ определяется в первую очередь трассировкой работающей системы. Любая цена без неё — оценка на глаз.
Названия сборок — примеры. Реестр российского ПО, версии и лицензионные условия меняются, поэтому проверяйте их на дату решения. Мы помогаем сравнить варианты, выбор и договор с вендором остаются за вами.
От списка объектов до вывода старой базы. Остановиться можно после любого шага: всё сделанное остаётся у вас по акту.
Перенос данных — самая предсказуемая часть. Труднее доказать, что перенесено всё и без искажений.
Способ загрузки выбираем по объёму и допустимой остановке: выгрузка и загрузка файлами, чтение из Oracle через oracle_fdw, для догона изменений — репликация журнала (например, Debezium или средства самого Oracle, если они у вас есть). Что подойдёт, зависит от версии Oracle и объёма журналов; решаем на обследовании.
Быстрый способ ошибиться — сравнить два-три запроса, которые вспомнили. Дорогой — не снять замер до переноса.
Планировщик PostgreSQL устроен иначе: запрос, который летал на Oracle, может замедлиться, и наоборот. Поэтому до приёмки мы называем не «будет быстрее», а порог по каждой ключевой операции.
База переезжает целиком только тогда, когда можно изменить приложения, которые к ней обращаются. SQL, зашитый в код, отчёты и слой доступа с диалектом Oracle (NVL, DECODE, ROWNUM, внешние соединения (+), CONNECT BY, обращения к последовательностям, разбор кодов ORA-) придётся править там, где он написан.
Если исходников нет, возможны три пути: слой совместимости между приложением и базой (представления и функции, повторяющие привычные вызовы), доработка у вендора или решение оставить эту базу на Oracle. Какой путь честный, видно из инвентаризации по трассировке запросов, а не из документации. Oracle Forms, Reports и APEX привязаны к Oracle и не переезжают вместе с базой (приложения APEX хранятся внутри самой базы Oracle): это отдельный проект, и мы оцениваем его отдельно.
Перенос не делается в закрытой комнате. Без этих шести вещей он замедляется, а оценка срока перестаёт работать.
Учётная запись с правом читать словарь и статистику. В боевой базе без согласования ничего не меняем.
Люди, которые могут изменить код приложений или обратиться к вендору с запросом на поддержку PostgreSQL.
Бухгалтер, технолог или аналитик, которые подтверждают бизнес-сверку: цифры должен признавать тот, кто ими пользуется.
Стенд с копией данных (при необходимости обезличенной) и серверы под PostgreSQL.
Сборка, поддержка и лицензионные условия — ваше решение и ваш договор с вендором.
Согласованное время, когда запись остановлена, а ответственные от бизнеса и от ИТ на связи.
Перенос — от 800 000 ₽, итог зависит от числа объектов PL/SQL и приложений. Сроки этапов — ориентиры для типовой базы: часть этапов идёт одновременно, поэтому общий срок не равен их сумме, а точные цифры называем после обследования. Перенос серверов на Linux считается отдельно. Ступени цен — на странице «Цены и сроки», общий обзор услуги — на странице «Миграция на СУБД и Linux».
Реестр объектов и зависимостей, запросы приложений, профиль нагрузки, отчёт о совместимости. Цена фиксированная, от 250 000 ₽, и вычитается из следующего этапа.
Таблицы, индексы, ограничения, последовательности, права. Загрузка, сверка строк и контрольных сумм.
Пакеты, процедуры, функции, триггеры, задания, ссылки между базами. Сконвертированное читаем руками.
Правка SQL, зашитого в код, смена диалекта в слое доступа, слой совместимости там, где исходников нет.
Прогон вашего профиля запросов, планы, индексы, параметры. Сравнение с замером, снятым до переноса.
Резервное копирование с проверкой восстановления, репликация, автоматическое переключение, мониторинг.
Догон изменений, ежедневная сверка, репетиция отката, регламент переключения. Старая база остаётся рабочей.
Инструкции и обучение администраторов (включая автоочистку vacuum и контроль раздувания таблиц), разбор инцидентов после запуска. Сверх пакета — 5 000 ₽ в час.
Остановиться можно после любого этапа: отчёт, скрипты и протоколы остаются у вас по акту.
Реестр объектов и зависимостей, запросы приложений, профиль нагрузки, отчёт о совместимости с оценкой по позициям. Остановиться можно здесь: отчёт остаётся у вас.
Поднимаем PostgreSQL на стенде, переносим схему и данные, сверяем строки и контрольные суммы. Перенос оформлен скриптами и повторяется.
PL/SQL в PL/pgSQL, задания, связи между базами, правки SQL в приложениях. Каждый объект читаем и сравниваем с исходным на одинаковых данных.
Прогон реального профиля, планы, индексы, параметры. Сравнение с замером до переноса и с порогами, согласованными заранее.
Изменения догоняют новую базу, сверка идёт по расписанию, расхождения разбираются. Отрепетированы переключение и откат.
Остановка записи по регламенту, наблюдение в первые дни в согласованные часы, затем документы, обучение администраторов и, по желанию, сопровождение.
Статья про шаги, разбор похожей задачи на другой СУБД и общие страницы про миграцию. Разбор — про типовую задачу, а не про наш проект.
Пять шагов миграции и список того, что ломается чаще всего. Эта страница разбирает те же шаги глубже, с таблицами по объектам.
Разбор похожей задачи на другой СУБД, а не описание нашего проекта: трассировка запросов, сверка и репетиция отката.
Общая страница про перенос баз: для обеих СУБД, без деталей по Oracle.
Если база стоит на Windows Server, перенос серверов и каталога пользователей идёт отдельной работой.
Названия — примеры. Состав подбираем под вашу версию Oracle, выбранную сборку PostgreSQL и требования контура.
Поддержка Oracle или лицензия заканчивается. Нужен план с ценой и точками, где можно остановиться, а не презентация.
Один-два администратора держат базу и не успевают ещё и переносить. Инвентаризацию и сверку берём на себя, решения остаются у вас.
ERP, биллинг, АБС: если база — часть чужой коробки, сначала выясняем у вендора, поддерживается ли PostgreSQL. Без этого переносить опасно.
Конвертер перенёс таблицы и встал на логике. Разбираем, где именно, и не повторяем тот же путь заново.
Короткий созвон: версия и размер базы, сколько в ней PL/SQL, кто к ней обращается и к какому сроку нужен результат. По итогам скажем, что переносится как есть, где риски и что войдёт в обследование.
Обследование стека и план — от 250 000 ₽, 2–3 недели; цена фиксированная и вычитается из следующего этапа. Перенос — от 800 000 ₽, итоговая сумма зависит от числа объектов PL/SQL, числа приложений и требований к отказоустойчивости. Перенос серверов на Linux считается отдельно. Точную цену называем после обследования, а не до него.
Ориентир для небольшой типовой базы — от одного до трёх месяцев вместе с параллельным периодом; при большом объёме PL/SQL и нескольких приложениях срок больше. Дольше всего идёт не загрузка данных, а перенос логики PL/SQL и правка приложений. Срок называем после обследования, когда известно число объектов и потребителей.
Частично. Инструменты вроде ora2pg переносят структуру почти целиком и дают заготовку кода, но синтаксис не равен смыслу: пакеты, автономные транзакции, иерархические запросы и обработка ошибок требуют ручной работы. Мы читаем каждый объект и сравниваем результаты на одинаковых данных. Отчёт конвертера по вашей базе сразу покажет, сколько объектов он пометил как непереносимые.
В обычном PostgreSQL прямого аналога пакета нет. Обычно пакет раскладывают на отдельную схему с функциями, а состояние пакета выносят в параметры, временные таблицы или настройки сессии. Часть встроенных пакетов DBMS_ и UTL_ имеет аналоги в расширении orafce; что именно, проверяем по списку реально вызываемых процедур.
В Oracle пустая строка хранится как NULL, в PostgreSQL это разные значения. Данные переедут как NULL, но новый код начнёт вставлять настоящие пустые строки, и условия, уникальные ключи и проверки поведут себя иначе. Мы находим такие места в коде и решаем по каждому: нормализовать значения или изменить условие.
Остановка записи на переключении нужна почти всегда. Её длина зависит от схемы: при догоне изменений репликацией окно меньше, при простой выгрузке и загрузке больше. Миграцию совсем без остановки мы не обещаем; длину окна записываем в регламент заранее.
Зависит от требований к реестру российского ПО, поддержке вендора и нужным расширениям. Названия — примеры; актуальные записи в реестре, версии и условия лицензии проверяйте на дату решения. Основа переноса почти не зависит от сборки, но состав расширений и функций у сборок разный, поэтому нужные вам мы проверяем до выбора.
Сверка идёт в пять уровней: количество строк, контрольные суммы по диапазонам ключа, выборка строк с краевыми значениями, бизнес-сверка (остатки, обороты, число открытых документов) и сравнение результатов отчётов на одинаковых данных. Все расхождения объясняются письменно, протокол остаётся у вас.
Заранее сказать нельзя: одни запросы ускоряются, другие замедляются, потому что оптимизатор строит планы иначе, а подсказок в ядре нет. Поэтому мы снимаем профиль нагрузки до переноса, прогоняем его на PostgreSQL и до приёмки согласовываем порог по каждой ключевой операции.
Сначала снять его запросы трассировкой на работающей системе, включая закрытие периода. Дальше три пути: слой совместимости между приложением и базой, доработка у вендора или решение оставить эту базу на Oracle. Какой путь честный, видно после обследования.
До открытия записи в PostgreSQL — да, это возврат подключений приложений. После — только если настроена обратная репликация или вы готовы потерять изменения, уже внесённые в новую базу. Поэтому условия отката и необходимость обратной репликации решаем и репетируем до переключения.
Информационную базу 1С таблицами не переносят: используют штатную выгрузку и загрузку средствами платформы 1С на другую СУБД. Порядок и поддерживаемые версии зависят от вашей версии платформы, поэтому уточняем их на обследовании.
