Недавно мы написали о том, насколько экономически разумно «переезжать» с Oracle на PostgreSQL. В этом материале хотели бы поделиться практическим опытом, как осуществить миграцию небольшой СУБД, и какие подводные камни вас могут ожидать при этом. Один из наших крупных клиентов — российский банк — захотел мигрировать небольшую типовую базу данных с Oracle на Postgres. В целом, забегая вперед, можно утверждать, что миграция прошла в штатном режиме, однако мы столкнулись с несколькими важными нюансами, которые рекомендуем учитывать коллегам. Основная проблема, возникшая при переезде, была связана с mview. В нем была прописана функция regexp_replace. Характерно, что в Oracle она организована по одному принципу, а в PostgreSQL — совсем иначе. Однако функция в обоих СУБД называется одинаково, и из-за этого вывод запроса был некорректным. Нам пришлось проявить смекалку в поисках альтернативного варианта. И он нашелся! Речь идет о расширении под Postgres, которое называется orafce. Все бы было хорошо, но у этого расширения есть определенный нюанс, из-за которого нам надо было немного переписывать код, добавив в эту функцию «oracle.». При помощи orafce можно успешно использовать операторы дат Oracle в Postgres. Более подробно, как использовать это расширение, можно почитать по ссылке https://github.com/orafce/orafce. Так, в решении нашей задачи пришлось изменить в выгруженной схеме smallint на Boolean, поскольку по умолчанию для логического типа данных в схеме oracle использовался NUMBER(1). Ниже последовательность наших действий при миграции схемы в хронологическом порядке. Устанавливаем ora2pg и необходимые компоненты: Изменяем config созданного проекта. Редактируем подключение к Oracle: Редактируем подключение к Postgres: Указываем схему в Oracle и предполагаемую схему в Postgres:   Остальные настройки конфигурации, чтобы не повторяться, можно легко найти в документации к ora2pg. Далее редактируем pg_hba и перезапускаем Postgres: Проверяем подключение к схеме в базе Oracle и оцениваем миграцию: Важно, что данные команды мы запускали в главной папке проекта. Далее запускаем ./export_schema.sh для выгрузки схемы. Так как в нашем случае нужно было заранее использовать orafce для функции regexp_replace, нам пришлось предварительно создать базу и пользователя в Postgres и загрузить расширение CREATE EXTENSION orafce. После запуска ./import_all.sh -h localhost -d test -o test -U postgres –I несколько раз возникали ошибки импорта, которые мы впоследствии исправили. В нашем варианте большинство ошибок было в коде mview. Следующим шагом мы отдельно загружаем индексы, ограничения на первичные и внешние ключи и триггеры: После тестирования нам пришлось исправить некоторые проблемы в базе, например, рассинхронизацию sequence. Однако в целом миграция прошла успешно. И результат вместе с базой мы благополучно передали заказчику. Таким образом, если объем данных в таблицах исчисляется сотнями гигабайт, мы рекомендуем, при наличии ИТ-ресурсов, запускать миграцию при помощи ora2pg в несколько потоков. Подробная информация о том, как это сделать, есть в документации к ora2pg. Это действительно сильно ускоряет выгрузку и загрузку данных. Схемы малого и среднего объема переносить на Postgres достаточно легко, и в текущее время эта задача особенно актуальна. Мы полагаем, что более крупные схемы в несколько терабайт разумнее мигрировать при помощи goldengate + ora2pg. При этом ora2pg – миграция структуры, а goldengate – миграция данных. Делали ли вы миграции СУБД похожего объема? С какими трудностями пришлось столкнуться и, главное, как их удалось преодолеть? Jet Service Team