Переход с Oracle на PostgreSQL: подробное руководство по успешной и гладкой миграции

В условиях растущего санкционного давления перед многими компаниями встает задача перехода с лицензионного ПО на решения с открытым исходным кодом. Так, все чаще организации отказываются от использования СУБД Oracle и переключаются на PostgreSQL.

Но несмотря на актуальность темы миграции с Oracle на PostgreSQL, не так легко найти информацию обо всех ее аспектах и возможных подводных камнях. Отвечает ли PostgreSQL требованиям бизнеса? Как подобрать правильные инструменты для миграции? Что вызывает трудности при переносе? Как сократить время простоя при переключении на новую базу? Как минимизировать риски и издержки для бизнеса? В этой статье я расскажу о каждом этапе миграции, возможных проблемах и способах их решения.

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

Преимущества PostgreSQL

В условиях санкций переход с Oracle на PostgreSQL кажется вынужденной мерой и шагом назад. Но так ли это на самом деле? В последнее время PostgreSQL активно развивается и стала одной из самых надежных, производительных и функциональных СУБД. Что подтверждается растущей популярностью PostgreSQL, в том числе среди очень крупных компаний, таких как Яндекс, Газпром, Сбербанк, Авито и Skype. У каждой СУБД есть свои сильные стороны. Давайте рассмотрим, что может предложить PostgreSQL.

Открытый исходный код. Благодаря открытому коду для PostgreSQL существует множество полезных сторонних расширений, в том числе отечественной разработки.

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

Масштабируемость. Широкие возможности в построении кластеров за счет таких решений, как PL/Proxy, Postgres-XC и Postgres-XL.

Объектно-реляционная модель. Сочетание двух моделей в одном решении предоставляет возможность взять лучшее от каждой.

Работа с большими данными. В PostgreSQL нет ограничений на размер базы и количество строк в таблицах. Есть ограничение на размер таблицы в 32 ГБ, но этого более чем достаточно для организации хранения любых данных.

Поддержка функций на различных языках. В PostgreSQL для написания функций можно использовать не только SQL, но и Python, C, C++, Java, JavaScript, PHP, Lua и Ruby.

Оценка исходной базы данных

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

Мы рекомендуем использовать бесплатный инструмент Конвертум Сканер, чтобы упростить и ускорить процесс оценки базы данных. Он предназначен для проведения детального анализа любой базы данных и оценки проекта миграции. Конвертум Сканер подключается к исходной базе данных и собирает информацию важную для определения сложности миграции, объема и сроков работ. В результате формируются подробные отчеты о таблицах, пакетах, хранимых процедурах, функциях и других объектах, которые необходимо перенести из Oracle в PostgreSQL. Пример отчета оценки вы можете увидеть ниже:

Переход с Oracle на PostgreSQL: подробное руководство по успешной и гладкой миграции
Переход с Oracle на PostgreSQL: подробное руководство по успешной и гладкой миграции
Переход с Oracle на PostgreSQL: подробное руководство по успешной и гладкой миграции

Между Oracle и PostgreSQL достаточно различий, чтобы сделать переписывание SQL кода самой трудоемкой частью миграции. Для максимально точной оценки этой стадии отчет Конвертум Сканера содержит информацию об особенностях SQL объектов исходной базы и частоте использования отдельных конструкций, таких как: SELECT, WHILE LOOP, IF ELSE, EXCEPTION, (+) - join операторы, PIPE ROW, PRAGMA, RECORD TYPE, DBMS_* пакеты и т.п. Анализ этих данных поможет определить, как много в исходном коде особенностей PL/SQL, которые не имеют аналогов в PL/pgSQL и потребуют дополнительных усилий при миграции.

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

Инструменты миграции

Автоматизация помогает людям повсеместно. Использование различного ПО помогает существенно упростить миграцию как данных, так и SQL из Oracle в PostgreSQL. Как же выбрать наиболее эффективные из доступных инструментов? Каждая база данных имеет свой уникальный код и структуру данных, поэтому навскидку сложно сделать точный прогноз для каждого инструмента. Необходимо выполнить конвертацию небольшого количества наиболее репрезентативных SQL объектов и таблиц и проанализировать качество полученных результатов.

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

Для переноса данных главный критерий — это скорость. Кроме того, важно учитывать соотношение объема данных и допустимого времени простоя. Рассмотрим два примера:

  • Необходимо перенести 100 ГБ, а время простоя может достигать 7 суток. В этом случае скорости большинства инструментов будет более чем достаточно, а на первый план выйдут такие критерии, как конвертация типов данных, надежность, удобство использования и цена.
  • Объем данных превышает 2 ТБ, время простоя не должно превышать 8 часов. В такой ситуации невозможно обойтись одним инструментом. Вам необходимо оптимизировать настройки исходной и целевой баз данных, серверов и сети, а также, скорее всего, реплицировать данные. К этому вопросу мы еще вернемся далее.

Миграция схемы

Как мы уже отмечали, миграция объектов схемы является наиболее трудоемким и длительным этапом проекта миграции базы данных. Например, один разработчик за месяц вручную выполняет изменение объектов SQL общим объемом не более 5-10 тысяч строк кода. Скорость этой работы зависит от особенностей кода и квалификации разработчика. Базы на Oracle нередко содержат в пакетах, функциях и хранимых процедурах сотни тысяч строк. В таких случаях проект может затянуться на многие месяцы или потребовать большой команды. Благодаря автоматизации конвертации процесс можно ускорить в 2-4 раза.

Широкие возможности PL/SQL могут доставить ряд проблем экспертам по миграции баз данных. Рассмотрим наиболее частые и сложные из них:

Встроенные пакеты. Oracle содержит набор встроенных пакетов, которые расширяют возможности PL/SQL. В базе данных может использоваться множество функций из нескольких пакетов. Как правило, в PostgreSQL нет эквивалентов этих функций, более того, аналогичный функционал сложно реализовать с помощью SQL. При миграции это создает серьезные затруднения. Решением может стать перенос части логики, использующей встроенные пакеты, на уровень приложения.

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

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

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

Миграция бизнес-логики из Oracle в PostgreSQL — сложный и кропотливый процесс. Не существует инструмента, который мог бы выполнить всю работу автоматически. Однако Конвертум Мастер окажет вам значительную помощь, в том числе с решением вышеперечисленных сложностей.

Тестирование

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

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

Если первый вариант невозможен, то приходится тестировать результат так, как тестируют разработанные с нуля базы данных или приложения.

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

Оптимизация

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

Перенос данных

Типы данных в Oracle и PostgreSQL имеют различия, однако в большинстве случаев их несложно сопоставить. Если необходимо перенести небольшой объем данных, в пределах 100 ГБ, то никаких существенных сложностей с миграцией данных не возникает. Однако при больших объемах вы можете столкнутся с тем, что нет возможности остановить систему на время, достаточное для передачи данных и переключения со старой базы на новую. В таком случае следует использовать репликацию данных. Процесс переноса данных с репликацией может отличаться в зависимости от выбранного инструмента. Например, сначала создается резервная копия данных, и сразу после этого включается репликатор, отслеживающий изменения в исходной базе. Затем резервная копия конвертируется и загружается в целевую базу, а в это время исходная продолжает использоваться. Последний этап - это собственно репликация, перенос изменений произошедших за время миграции основного объема данных.

В любом случае важно добиться высокой скорости и надежности миграции данных. В этом вам помогут:

  • увеличение скорости сети;

  • повышение производительности серверов, на которых запущен инструмент миграции, исходная и целевая базы данных;

  • распараллеливание миграции.

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

Заключение

Переход с Oracle на PostgreSQL в настоящее время - это разумное решение по многим причинам. Автоматизация - ключ к успешной миграции с минимальными затратами времени и рисками для бизнеса. Для переноса базы данных с Oracle на PostgreSQL вы можете попробовать набор инструментов Конвертум. Он поддерживает автоматическую миграцию как данных, так и SQL из Oracle в PostgreSQL. А также имеет широкий набор настроек для максимального качества миграции.

Вы можете попробовать инструментарий в действии, воспользовавшись бесплатной демо лицензией. Начните процесс трансформации вашей базы данных Oracle уже сегодня!

1212
4 комментария

Базы на Oracle нередко содержат в пакетах, функциях и хранимых процедурах сотни тысяч строк.

господи. боже. мой.
мама!

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

Ответить

Да, конвертация таких объемов кода кажется невыполнимой задачей. И да, многие даже не пытаются ее решить. Поэтому мы и разработали Конвертум. Практика его применения показывает, что успешная конвертация сотен тысяч строк SQL - задача вполне реальная.

1
Ответить

Тул русский, но слишком много английского...

Ответить

Спасибо, передам ваше замечание в отдел разработки. Будем работать над этим! :)

Ответить