Миграция с Oracle на PostgreSQL

Учётная система живёт на Oracle больше десяти лет: в базе 1 200 таблиц, 340 хранимых процедур и 60 пакетов на PL/SQL, и компания решила переходить на PostgreSQL. Таблицы и данные переносятся почти сами. Тревожит другое. Сколько процедур придётся переписывать руками? Не станут ли отчёты считаться вдвое дольше? И на сколько встанет система в день переключения? Rule 90 переносит приложение вместе с базой: схему, данные, хранимый код и запросы самого приложения. Скорость проверяем на копии рабочих данных до переключения, а переключаемся в окно, о котором договорились заранее, с проверенным откатом. Первый этап — двухнедельное обследование.

Что переносится при миграции с Oracle на PostgreSQL

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

Первую часть делает бесплатная утилита Ora2Pg. Она подключается к Oracle, сама вынимает структуру и данные и готовит SQL для PostgreSQL. С кодом на PL/SQL она справляется только в простых случаях, и её автор прямо пишет, что процедуры, пакеты и триггеры после неё нужно проверять и дорабатывать вручную.

Где миграция требует ручной работы

Больше всего работы дают пакеты. В PostgreSQL пакетов нет, функции из них раскладывают по схемам, а общие переменные пакета заменяют другим способом хранить состояние сессии. Следом идут различия, которые не видны, пока не сломается отчёт. В Oracle пустая строка считается NULL, а в PostgreSQL нет, поэтому условия вида «поле не заполнено» начинают возвращать другие строки. Тип DATE в Oracle хранит и время, а одноимённый тип в PostgreSQL только дату, и если перенести тип по названию, из документов пропадут часы и минуты.

Часть объектов прямого аналога не имеет. Ora2Pg переносит bitmap-индексы как обычные b-tree, связи с другими базами (database links) не переносит вовсе, а hash-секции не поддерживает. Всё это решается, но каждый такой случай нужно найти заранее.

Условная база учётной системы в отчёте Ora2Pg

До разговора с подрядчиком у Ora2Pg можно получить отчёт: что лежит в базе и сколько работы потребует перенос. Трудоёмкость он считает в условных единицах, одна единица — около пяти минут работы специалиста по PostgreSQL. Вот как мог бы выглядеть итог для базы из начала, числа условные, подставьте свои:

По такой таблице видно главное: размер базы в этой оценке почти ничего не решает. 900 ГБ данных переносятся по отлаженному сценарию, а время уходит на 340 процедур и 60 пакетов, где живёт логика компании. База на 5 ТБ из одних таблиц, скорее всего, переедет быстрее, чем база на 50 ГБ с тысячей процедур.

«На PostgreSQL отчёты станут считаться дольше»

Могут, если перенести запросы как есть и не проверить. Две базы по-разному строят план запроса и по-разному используют индексы, поэтому до переключения самые тяжёлые запросы и отчёты прогоняем на копии рабочих данных и сравниваем время с Oracle. Где PostgreSQL проигрывает, меняем индексы или сам запрос. Вопросы производительности разбираем вместе с профильным специалистом по СУБД.

Переключение с откатом и порядок работы

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

За две недели обследования смотрим схему, объём хранимого кода и запросы приложения и составляем план переезда. План с ценой и сроком ложится в договор, доработки сверх плана оцениваем отдельно. Раз в неделю вы видите, какие модули уже работают на PostgreSQL. После переключения три месяца действует гарантия, а скрипты миграции, документация и доступы к новой базе остаются у компании.

Вопросы о миграции с Oracle