# Миграция с Oracle на PostgreSQL - как правильно осуществить перенос базы данных

> Объясняем в этой статье, как выполняется миграция с Oracle на PostgreSQL: какие этапы включает перенос данных из одной системы на другую – правила перехода.

**URL:** https://whitetigersoft.ru/blog/mobile-app-development/migraciya-s-oracle-na-postgresql
**Тип страницы:** Статья блога
**Дата публикации:** 2026-04-29
**Время чтения:** 14 мин

---

Перенос системы с одной базы данных на другую – это не просто «переключить кнопку». Особенно когда речь идет о миграции с Oracle на PostgreSQL. На первый взгляд они похожи: у обеих технологий есть свои языки, таблицы, функции. Но на практике различий хватает, и именно они чаще всего становятся причиной ошибок, сбоев и лишних затрат, а также могут заметно влиять на performance системы. Главная сложность в том, что код, который отлично работает в одной СУБД, не получится просто взять и запустить на другой. У каждой свой язык, правила и ограничения. Отличаются типы информации, работа со строками и числами, поведение временных таблиц и даже такие вещи, как транзакции и обработка ошибок. В этой статье специалисты ИТ-агентства расскажут, чем отличаются БД, где чаще всего возникают проблемы, какие инструменты помогают упростить переезд и как снизить риски. Поговорим не только о теории, но и о реальных нюансах, с которыми сталкиваются команды на практике. Если вы планируете полную миграцию или уже находитесь в процессе, статья поможет заранее понять, где могут быть подводные камни и как пройти этот путь спокойнее и без лишних потерь. Общее устройство Чтобы проще понять различия между системами, сначала разберемся, как вообще они устроены и зачем нужны. Oracle PL/SQL Это язык программирования, который появился еще в 1988 г. Сейчас он выглядит немного непривычно, так как многие ЯП сегодня (кроме, например, Python) развивались на основе Си. А PL/SQL вырос из другого направления – Ada, которое создавалось для задач Министерства обороны США. Со временем он стал мощным инструментом: в нем есть обработка ошибок, удобная структура кода и возможность разбивать логику на части. Хотя сейчас его постепенно вытесняют более современные подходы, в свое время он считался очень продуманным решением. Появился PL/SQL из практической необходимости. Обычного Structured Query Language часто не хватало для сложной логики. Поэтому в язык добавили переменные, условия, циклы и обработку исключений. Также появилась модульность. Важно понимать: PL/SQL – это отдельный язык, а не «расширенный Structured Query Language». У него свой механизм выполнения. Когда из SQL вызывается функция, application временно переключается на исполнение PL/SQL кода, а затем возвращается. Само кодовое содержимое находится прямо внутри базы и выполняется там же. Это удобно – можно скрыть внутреннюю логику от пользователя и сделать ее недоступной для прямого изменения. Поэтому такие решения часто использовались в системах, где важна защита информации. Так как это полноценный язык программирования, в нем есть свои типы данных. Также доступны курсоры и возможность подключать внешний код, написанный на Си или Джава. PostgreSQL PL/pgSQL Этот язык возник позже – в 1997 г. Его изначально создавали так, чтобы разработчикам Oracle было проще на него перейти. Поэтому синтаксис во многом похож. Главное отличие – подход к модульности. В Оракул используются пакеты, а здесь – схемы. Пакетная поддержка появилась только в 15 версии (в 2022 году), и пока она ограничена. В остальном возможности очень похожи: код хранится прямо в БД; исходный текст выполняется внутри нее; есть свои типы данных (например, RECORD, SETOF, TABLE); поддерживаются курсоры; можно подключать внешнее кодовое содержимое на Си; есть дополнительные ЯП. По общей идее языки близки, но различия в деталях как раз и создают основные сложности. Расхождения в форматах Хотя технологии во многом похожи, на практике при переносе чаще всего «ломается» именно работа с информацией. Разберем самые частые и неприятные моменты, с которыми сталкиваются при переходе с одного ЯП на другой. Строки Есть важный нюанс, который часто упускают. В PostgreSQL пустая строка и NULL – это разные вещи. А в Oracle она автоматически считается нулевым указателем. Из-за этого при миграции нужно внимательно проверить все условия. Если раньше было сравнение с пустой строкой, в Постгрес придется явно проводить проверку через IS NULL, иначе логика будет работать неправильно. Еще один момент – типы строчек. В Оракл обычно используют VARCHAR2. В Постгрес такого нет. Поэтому его заменяют на VARCHAR. Кроме того, в нем есть отдельный тип TEXT для хранения длинных текстов. В целом отличия небольшие, но код все равно придется немного поправить. Целые числа Здесь ситуация сложнее. В Оракл часто используют NUMBER, а в Постгрес – NUMERIC. При этом Oracle позволяет работать с очень большими числами – до 38 цифр. В PostgreSQL тоже можно использовать NUMERIC, но он функционирует медленнее, особенно при вычислениях. Например, операции с такими числами могут выполняться в десятки или сотни раз дольше, чем с обычными целыми типами. Поэтому при экспорте важно подумать: нужны ли такие большие значения на самом деле. Если, например, количество товаров ограничено миллионом, вполне достаточно обычного integer. Также в PL/SQL есть свои числовые значения. Они по смыслу близки к типам Постгрес и часто могут быть без проблем заменены. Отдельная большая тема – дата и время. В различных системах эти типы устроены по-разному: где-то используется date, в других случаях – datetime или timestamp. Это отдельный пласт сложностей, который требует внимательной проверки. Большие информационные массивы В Oracle крупные файлы хранятся отдельно от основной записи. Для этого используются типы BLOB (для бинарных данных) и CLOB (для текста). Работа с ними происходит через специальные функции. Со временем в Оракл добавили дополнительные возможности: автоматическое удаление дублей, сжатие и шифрование таких сведений. В PostgreSQL тоже есть механизм для хранения больших объектов, но он устроен иначе. Для них используется отдельная системная таблица. Есть ограничения: общий размер – до 32 ТБ; один объект – до 4 ТБ; их количество – около 4 млрд. Для большинства задач этого более чем достаточно. Но если речь идет о крупных системах с большим объемом информации, эти ограничения нужно учитывать заранее. Прочие расхождения Есть еще ряд различий в работе самих механизмов базы. Именно они зачастую вызывают неожиданные сложности при переносе и требуют отдельного внимания. Временные таблицы На практике часто возникает задача: собрать промежуточные сведения, обработать их по шагам и затем использовать в основном обращении. Это удобно, когда большой запрос делят на несколько этапов – так легче разобраться и проверить логику. После выполнения такие структуры уже не нужны. В Oracle есть 2 варианта: глобальные временные таблицы (в более новых версиях) и сессионные. В PostgreSQL первого решения нет. Используются только таблицы, которые живут в рамках одной сессии. При этом можно выбрать их поведение: удаляются после коммита; очищаются только данные; сведения сохраняются после commit. Из-за этого при переносе глобальных временных таблиц из Оракл приходится искать обходные решения и немного менять логику. Автономные транзакции В Оракл есть удобная возможность – выполнять часть операций отдельно от главной. Например, можно записать событие в журнал, даже если основное действие потом откатится. В Постгрес такой возможности долгое время не было. Обычно используют обходной путь – выполнение запроса через отдельное соединение (например, через dblink). Но у этого подхода есть минус: каждое обращение требует времени на подключение и проверки, из-за чего все работает медленнее. Чтобы ускорить процесс, часто заранее открывают соединение и используют его повторно. Позже появились дополнительные решения, например, расширение pg_variables. Оно позволяет хранить сведения на уровне сессии, не привязываясь к транзакциям (или при необходимости учитывать их). С его помощью можно держать как простые значения, так и наборы данных. В некоторых версиях PostgreSQL (например, в коммерческих сборках) автономные транзакции уже реализованы напрямую, что сильно упрощает задачу. Средства отказоустойчивости Следующее важное отличие – как системы защищаются от сбоев. В Oracle имеется базовая функция Data Guard. Она позволяет держать резервную копию базы, которая синхронизируется с основной, и автоматически переключаться на нее при проблемах. В Постгрес используется другой подход – потоковая репликация. Плюс есть внешние инструменты, которые помогают управлять отказоустойчивостью и автоматическим переключением. Например: Patroni, Stolon или Pg_auto_failover. Другие несовместимости Кроме перечисленного, есть еще ряд различий, которые не всегда очевидны, но могут создать проблемы при переносе: иерархические запросы реализованы по-разному; различается работа с параллельной обработкой данных; есть отличия в условиях, которые вычисляются во время выполнения; по-разному устроены очереди; отличаются коллекции; нет прямых аналогов пользовательских констант и исключений; отсутствуют глобальные структуры уровня пакетов; различны команды; нет функции DECODE в привычном виде; иначе работает встроенный планировщик задач. Все эти моменты не всегда критичны по отдельности, но в сумме могут заметно усложнить процесс и потребовать доработки кода вручную. Инструменты перехода с Oracle на PostgreSQL Мы разобрали основные сложности, теперь логичный вопрос – как с ними справляться на практике? Сразу честно: полностью автоматического решения по принципу «нажал кнопку – все готово» не существует. Если кто-то обещает такой результат, почти наверняка речь идет о маркетинге. Даже у платных решений обычно есть оговорка: часть работы делает программа, остальное – специалисты вручную. Если говорить проще, такие инструменты работают как онлайн-переводчик. Они могут быстро переложить код с одного языка на другой, но итог все равно нужно проверять и дорабатывать. Иначе есть риск получить ошибки, которые в реальной системе стоят очень дорого. Тем не менее существует несколько популярных решений, которые помогают ускорить процесс и снять часть нагрузки. Ora2pg Это один из самых известных инструментов с открытым исходным кодом. Его давно развивает международное сообщество, и он специально создан для миграции данных из Oracle в PostgreSQL. Работает так: подключается к базе Оракл и формирует готовые скрипты для Постгрес. Сам инструмент написан на Perl, поэтому его нужно заранее установить. Что он делает хорошо: переносит структуру и права доступа; выгружает сведения, включая большие объекты; конвертирует процедуры, функции, пакеты и триггеры (но их почти всегда надо дорабатывать вручную). Дополнительно умеет: создавать внешние подключения; выгружать представления; оценивать сложность и примерную стоимость миграции. Но есть и ограничения: серверный код после переноса почти всегда требует ручной правки; не поддерживаются некоторые конструкции, например, локальные функции, составные триггеры, переменные, стандартные пакеты Оракл и специфичные рекурсивные запросы. В среднем инструмент закрывает большую часть работы – примерно до 80%, но итог сильно зависит от конкретного проекта. Orafce Это еще один open source инструмент, который помогает сократить объем переделок. Его задача – «добавить» в PostgreSQL привычные возможности Oracle. Например, он реализует: псевдотаблицу DUAL; тип date и связанные функции; некоторые пакеты, такие как DBMS_OUTPUT и UTL_FILE; специальные триггеры, которые помогают корректно обрабатывать различия между пустой строкой и NULL. За счет этого можно не переписывать большое количество SQL запросов – библиотека сглаживает отличия между системами. В простых проектах такой подход экономит очень много времени. Ora2pgpro Это коммерческая версия ora2pg, которую развивает компания Postgres Pro. Она ориентирована на перенос данных в их собственную сборку PostgreSQL и использует дополнительные возможности платформы, например, поддержку автономных транзакций. В этой версии учтено гораздо больше нюансов, поэтому уровень автоматизации заметно выше. В ряде случаев удается закрыть почти весь объем работ – до 90 ??95%. Но даже здесь полностью без ручной проверки не обойтись. После перемещения все равно нужно внимательно проверить результат и прогнать тесты, чтобы убедиться, что система работает корректно. Выбор инструмента для переезда Универсального решения здесь нет – все зависит от вашей задачи. Важно учитывать, куда вы переносите систему, сколько у вас ресурсов и насколько сложный код уже используется в проекте. Если нет серверной логики (процедур, функций и прочего), можно обойтись более простым вариантом. Например, подключить orafce и перенести только SQL запросы – это самый легкий сценарий. Если же серверный код есть, без более серьезных инструментов не обойтись. Обычно в таком случае рассматривают ora2pg или его расширенную версию. При этом последняя ориентирована на работу с платформой Postgres Pro и предполагает использование коммерческой поддержки, что подходит не всем компаниям. Если попытаться применить расширенную версию вместе с обычным PostgreSQL, придется дополнительно настраивать инструмент и отключать функции, которые доступны только в платной среде. Особенности миграции Когда план уже есть и инструменты выбраны, начинается самое сложное – работа по переносу. Здесь важно понимать: даже при хорошем подходе процесс редко проходит идеально гладко. Всегда всплывают детали, которые нельзя было заранее учесть. Как упростить процедуру Первое правило – не пытаться перенести все сразу. Гораздо безопаснее разбить задачу на этапы. Например: сначала структура, потом данные, затем код и только после этого – тестирование. Полезно заранее подготовить систему: убрать неиспользуемые объекты; упростить сложные участки логики; привести исходный текст к более понятному виду. Чем «чище» база, тем легче будет перемещение. Также стоит сразу настроить тестовую среду и прогонять проверки на каждом этапе. Это позволит быстро находить ошибки и не копить их до финала. Сложности с кодом Основные проблемы обычно возникают именно в серверной логике. Автоматические инструменты могут переписать код, но не всегда делают это корректно. Чаще всего приходится вручную дорабатывать: процедуры и функции; триггеры; сложные SQL запросы; работу с исключениями и транзакциями. Особенно много времени уходит на старые системы, где код писался годами разными разработчиками. Там часто встречаются нестандартные решения, которые сложно перенести «как есть». Проверка системы и целостности данных После миграции нельзя просто запустить программу и надеяться, что все заработает правильно. Обязательно нужна проверка. Что важно сделать: сравнить сведения в старой и новой базе; проверить ключевые сценарии функционирования системы; убедиться, что расчеты дают те же результаты; протестировать нагрузку. Иногда ошибки проявляются не сразу, а только при реальной работе пользователей. Поэтому этап тестирования лучше не сокращать. Заключение Перенос Oracle на PostgreSQL – это не разовое действие, а полноценный проект. Здесь важны и технические знания, и аккуратность, и планирование. Даже при использовании хороших инструментов полностью избежать ручной работы не получится. Но при грамотном подходе можно значительно снизить риски и пройти этот путь без серьезных потерь. Главное – не спешить, проверять каждый этап и заранее понимать, где могут возникнуть сложности.