«Сами мы не местные», или Как мы провели миграцию с Oracle на PostgreSQL

Недавно мы написали о том, насколько экономически разумно «переезжать» с 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 и необходимые компоненты:

rpm -ivh oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-devel-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-jdbc-12.2.0.1.0-1.x86_64.rpm
rpm -ivh oracle-instantclient12.2-sqlplus-12.2.0.1.0-1.x86_64.rpm

yum install -y wget

wget https://yum.oracle.com/RPM-GPG-KEY-oracle-ol7 -O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

yum install -y perl perl-CPAN perl-DBI perl-Time-HiRes perl-YAML perl-local-lib make gcc

yum install -y perl-App-cpanminus

cpanm CPAN::Config
cpanm CPAN::FirstTime

export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/12.2/client64

perl -MCPAN -e 'install DBD::Oracle'
perl -MCPAN -e 'install DBD::Pg'

tar zxf ora2pg-23.1.tar.gz && cd ora2pg-21.1 && perl Makefile.PL && make && make install
ora2pg --project_base /migration/ --init_project test_project

Изменяем config созданного проекта. Редактируем подключение к Oracle:

ORACLE_DSN  dbi:Oracle:host=*****;sid=***;port=1521
ORACLE_USER *****
ORACLE_PWD *****

Редактируем подключение к Postgres:

PG_DSN      dbi:Pg:dbname=***;host=*****;port=5432
PG_USER postgres
PG_PWD  *****

Указываем схему в Oracle и предполагаемую схему в Postgres:

SCHEMA  ****
PG_SCHEMA ****
ora2pg -t SHOW_TABLE -c config/ora2pg.conf

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

Далее редактируем pg_hba и перезапускаем Postgres:

host all all 0.0.0.0/0 md5
systemctl restart postgresql-14

Проверяем подключение к схеме в базе Oracle и оцениваем миграцию:

ora2pg -t SHOW_TABLE -c config/ora2pg.conf
ora2pg -t SHOW_REPORT --estimate_cost -c config/ora2pg.conf export_schema.sh

Важно, что данные команды мы запускали в главной папке проекта. Далее запускаем ./export_schema.sh для выгрузки схемы.

Так как в нашем случае нужно было заранее использовать orafce для функции regexp_replace, нам пришлось предварительно создать базу и пользователя в Postgres и загрузить расширение CREATE EXTENSION orafce.

После запуска ./import_all.sh -h localhost -d test -o test -U postgres –I несколько раз возникали ошибки импорта, которые мы впоследствии исправили. В нашем варианте большинство ошибок было в коде mview.

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

psql -h ***** -U ***** -d **** < /migration/schema/tables/INDEXES_table.sql
psql -h ***** -U ***** -d **** < /migration/schema/tables/CONSTRAINTS_table.sql
psql -h ***** -U ***** -d **** < /migration/schema/tables/FKEYS_table.sql
psql -h ***** -U ***** -d **** < /migration/schema/triggers/trigger.sql

Результат миграции. Стоит ли игра свеч?

После тестирования нам пришлось исправить некоторые проблемы в базе, например, рассинхронизацию sequence. Однако в целом миграция прошла успешно. И результат вместе с базой мы благополучно передали заказчику. Таким образом, если объем данных в таблицах исчисляется сотнями гигабайт, мы рекомендуем, при наличии ИТ-ресурсов, запускать миграцию при помощи ora2pg в несколько потоков. Подробная информация о том, как это сделать, есть в документации к ora2pg. Это действительно сильно ускоряет выгрузку и загрузку данных.

Схемы малого и среднего объема переносить на Postgres достаточно легко, и в текущее время эта задача особенно актуальна. Мы полагаем, что более крупные схемы в несколько терабайт разумнее мигрировать при помощи goldengate + ora2pg. При этом ora2pg – миграция структуры, а goldengate – миграция данных.

Делали ли вы миграции СУБД похожего объема? С какими трудностями пришлось столкнуться и, главное, как их удалось преодолеть?

Jet Service Team