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

Перенос системы с одной базы данных на другую – это не просто «переключить кнопку». Особенно когда речь идет о миграции с Oracle на PostgreSQL. На первый взгляд они похожи: у обеих технологий есть свои языки, таблицы, функции. Но на практике различий хватает, и именно они чаще всего становятся причиной ошибок, сбоев и лишних затрат, а также могут заметно влиять на performance системы.

Главная сложность в том, что код, который отлично работает в одной СУБД, не получится просто взять и запустить на другой. У каждой свой язык, правила и ограничения. Отличаются типы информации, работа со строками и числами, поведение временных таблиц и даже такие вещи, как транзакции и обработка ошибок.

В этой статье специалисты ИТ-агентства White Tiger Soft расскажут, чем отличаются БД, где чаще всего возникают проблемы, какие инструменты помогают упростить переезд и как снизить риски. Поговорим не только о теории, но и о реальных нюансах, с которыми сталкиваются команды на практике. Если вы планируете полную миграцию или уже находитесь в процессе, статья поможет заранее понять, где могут быть подводные камни и как пройти этот путь спокойнее и без лишних потерь.

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

Это язык программирования, который появился еще в 1988 г. Сейчас он выглядит немного непривычно, так как многие ЯП сегодня (кроме, например, Python) развивались на основе Си. А PL/SQL вырос из другого направления – Ada, которое создавалось для задач Министерства обороны США.

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

Появился PL/SQL из практической необходимости. Обычного Structured Query Language часто не хватало для сложной логики. Поэтому в язык добавили переменные, условия, циклы и обработку исключений. Также появилась модульность.

Важно понимать: PL/SQL – это отдельный язык, а не «расширенный Structured Query Language». У него свой механизм выполнения. Когда из SQL вызывается функция, application временно переключается на исполнение PL/SQL-кода, а затем возвращается.

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

Так как это полноценный язык программирования, в нем есть свои типы данных. Также доступны курсоры и возможность подключать внешний код, написанный на Си или Джава.

Этот язык возник позже – в 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.

Работает так: подключается к базе Оракл и формирует готовые скрипты для Постгрес. Сам инструмент написан на Perl, поэтому его нужно заранее установить.

Что он делает хорошо:

• переносит структуру и права доступа;
• выгружает сведения, включая большие объекты;
• конвертирует процедуры, функции, пакеты и триггеры (но их почти всегда надо дорабатывать вручную).

Дополнительно умеет:

• создавать внешние подключения;
• выгружать представления;
• оценивать сложность и примерную стоимость миграции.

Но есть и ограничения:

• серверный код после переноса почти всегда требует ручной правки;
• не поддерживаются некоторые конструкции, например, локальные функции, составные триггеры, переменные, стандартные пакеты Оракл и специфичные рекурсивные запросы.

В среднем инструмент закрывает большую часть работы – примерно до 80%, но итог сильно зависит от конкретного проекта.

Это еще один open-source инструмент, который помогает сократить объем переделок. Его задача – «добавить» в PostgreSQL привычные возможности Oracle. Например, он реализует:

• псевдотаблицу DUAL;
• тип date и связанные функции;
• некоторые пакеты, такие как DBMS_OUTPUT и UTL_FILE;
• специальные триггеры, которые помогают корректно обрабатывать различия между пустой строкой и NULL.

За счет этого можно не переписывать большое количество SQL-запросов – библиотека сглаживает отличия между системами. В простых проектах такой подход экономит очень много времени.

Это коммерческая версия ora2pg, которую развивает компания Postgres Pro. Она ориентирована на перенос данных в их собственную сборку PostgreSQL и использует дополнительные возможности платформы, например, поддержку автономных транзакций.

В этой версии учтено гораздо больше нюансов, поэтому уровень автоматизации заметно выше. В ряде случаев удается закрыть почти весь объем работ – до 90–95%.

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

Универсального решения здесь нет – все зависит от вашей задачи. Важно учитывать, куда вы переносите систему, сколько у вас ресурсов и насколько сложный код уже используется в проекте.

Если нет серверной логики (процедур, функций и прочего), можно обойтись более простым вариантом. Например, подключить orafce и перенести только SQL-запросы – это самый легкий сценарий.

Если же серверный код есть, без более серьезных инструментов не обойтись. Обычно в таком случае рассматривают ora2pg или его расширенную версию. При этом последняя ориентирована на работу с платформой Postgres Pro и предполагает использование коммерческой поддержки, что подходит не всем компаниям. Если попытаться применить расширенную версию вместе с обычным PostgreSQL, придется дополнительно настраивать инструмент и отключать функции, которые доступны только в платной среде.

Когда план уже есть и инструменты выбраны, начинается самое сложное – работа по переносу. Здесь важно понимать: даже при хорошем подходе процесс редко проходит идеально гладко. Всегда всплывают детали, которые нельзя было заранее учесть.

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

Полезно заранее подготовить систему:

• убрать неиспользуемые объекты;
• упростить сложные участки логики;
• привести исходный текст к более понятному виду.

Чем «чище» база, тем легче будет перемещение. Также стоит сразу настроить тестовую среду и прогонять проверки на каждом этапе. Это позволит быстро находить ошибки и не копить их до финала.

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

Чаще всего приходится вручную дорабатывать:

• процедуры и функции;
• триггеры;
• сложные SQL-запросы;
• работу с исключениями и транзакциями.

Особенно много времени уходит на старые системы, где код писался годами разными разработчиками. Там часто встречаются нестандартные решения, которые сложно перенести «как есть».

После миграции нельзя просто запустить программу и надеяться, что все заработает правильно. Обязательно нужна проверка. Что важно сделать:

• сравнить сведения в старой и новой базе;
• проверить ключевые сценарии функционирования системы;
• убедиться, что расчеты дают те же результаты;
• протестировать нагрузку.

Иногда ошибки проявляются не сразу, а только при реальной работе пользователей. Поэтому этап тестирования лучше не сокращать.

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