#Oracle #Postgres #ora2pg #миграция #легаси

После тщательного анализа различных подходов и отсутствия подходящего решения, мы приняли решение разделить миграцию на несколько волн. Практика показала, что такой подход был бы оправдан в любом случае, поскольку объем данных на ПРОМ-сервере оказался значительно больше, чем предполагалось изначально.

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

На DEV стенде для автоматизации процесса был создан командный файл, который избавляет от необходимости выполнять рутинные операции вручную. На ПРОМ-сервере же сохранилась возможность запуска каждой волны отдельно, что оказалось оптимальным решением для контроля и повышения надежности процесса.

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

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

Как уже стало привычным, на этом этапе возникли определенные сложности. Для реализации партиционирования в Postgres были добавлены составные первичные ключи во всех таблицах, где в Oracle использовались ключи по одному полю.

Такие существенные изменения могли бы пройти гладко, если бы делались отдельно от миграции, но задача стояла в переходе за один приём.

Это потребовало разработки решения для генерации поля с партицией на лету.

Подробности реализации этого подхода будут описаны в следующей главе.