Содержание
Oracle и MS SQL в российских компаниях продолжают работать — но продлевать поддержку напрямую больше нельзя, а каждая новая ИТ-система на них увеличивает будущий объём переноса. Поэтому миграция с Oracle на PostgreSQL из «когда-нибудь» превратилась в плановый проект: у неё есть отработанный жизненный цикл, зрелые инструменты автоматизации и понятная экономика. Эта статья — план такого проекта глазами заказчика, а не инженера: что чем заменяется, из каких этапов состоит переход, где съедается больше всего времени и денег и сколько стоят лицензии целевой СУБД.
Чем заменить Oracle-специфику: короткий ответ
Самая дорогая часть миграции — не данные, а хранимая логика: пакеты PL/SQL, системные пакеты, работа с большими объектами. Именно здесь решается выбор целевой СУБД. Ниже — соответствия по официальной матрице возможностей Postgres Pro:
| Что используется в Oracle | Ванильный PostgreSQL | Postgres Pro Enterprise |
|---|---|---|
| Пакеты PL/SQL | Нет — код раскладывается по схемам и переписывается | Пакеты PL/pgSQL: CREATE PACKAGE, глобальные переменные, приватные подпрограммы |
| Системные пакеты UTL_HTTP, UTL_MAIL, UTL_SMTP | Нет | Встроенные utl_http, utl_mail, utl_smtp — API почти полностью совпадает с Oracle |
| DBMS_APPLICATION_INFO | Нет | Расширение pgpro_application_info: метрики сессий в представлениях v$session и v$session_longops |
| DBMS_LOB и внешние файлы BFILE | Пакета нет; свои Large Objects с другим API | Пакет dbms_lob, внешние файлы pgpro_bfile, хранилище Superfile для больших объектов |
| Коллекции и ассоциативные массивы | Массивы, код переписывается вручную | Коллекции в pg_variables и автоматический экспорт коллекций Oracle |
| Хинты планировщика | Нет | pg_hint_plan — указания планировщику в SQL-комментариях |
| Oracle ILM: вытеснение редких данных на дешёвые диски | Нет | pgpro_ilm |
| Автоматическая конвертация кода | Свободная утилита ora2pg | ora2pgpro 2.0 — транспилятор с полным разбором кода |
Если из левой колонки в вашей системе используются только данные и простые процедуры — читайте раздел про ванильный PostgreSQL: возможно, платить вообще не придётся.
Почему компании переносят базы с Oracle и MS SQL
Причины у всех одни и те же, и паники среди них нет — только арифметика рисков.
Поддержка. Oracle и Microsoft приостановили работу в России: прямые контракты на поддержку и обновления не продлеваются. Критичная СУБД без патчей безопасности — риск, который с каждым годом дорожает.
Регуляторика. Госсектору, госкомпаниям и субъектам КИИ нужен софт из реестра российского ПО — подробно о требованиях к значимым объектам мы писали в статье о КИИ и 187-ФЗ. Postgres Pro в реестре, у сертифицированных редакций есть сертификат ФСТЭК.
Технологическая близость. PostgreSQL — классическая реляционная СУБД, близкая к Oracle по архитектуре и методам работы, с большим числом успешных проектов миграции. Из всех вариантов замены этот — с наименьшим расстоянием переноса. Как Postgres Pro выглядит на фоне других российских СУБД — в сравнении российских СУБД.
Этапы миграции с Oracle на PostgreSQL
Жизненный цикл проекта, который вендор использует в собственных проектах миграции, состоит из семи этапов.
- Выбор приложения и аудит. Мигрируют не «всё сразу», а по информационным системам — первой обычно берут некритичную. Аудит отвечает на вопросы: сколько строк PL/SQL, какие системные пакеты задействованы, кто и как подключается к базе.
- Оценка трудозатрат. По результатам аудита считается бюджет и выбирается целевая СУБД — здесь же становится видно, окупит ли Oracle-совместимость Enterprise сокращение ручной работы.
- Конвертация схемы и кода. Таблицы, индексы, представления и хранимая логика переводятся в синтаксис PostgreSQL — руками или транспилятором ora2pgpro.
- Перенос и синхронизация данных. Самая предсказуемая часть проекта. В ora2pgpro есть проверка корректности: данные исходной таблицы Oracle сопоставляются с результатом в Postgres Pro, материализованные представления переносятся снимками.
- Тестирование. Функциональное и нагрузочное: сверяются результаты запросов, планы выполнения и время отклика под боевой нагрузкой.
- Переход в промышленную эксплуатацию. Обычно через период параллельной работы двух СУБД с синхронизацией данных и коротким окном переключения.
- Оптимизация и сопровождение. PostgreSQL настраивается иначе, чем Oracle: тюнинг планов, автовакуум, мониторинг.
Честная оценка: дольше всего длятся конвертация логики и тестирование. Перенос данных, которого обычно боятся, — быстрая и хорошо автоматизированная часть.
Перенос логики PL/SQL: где теряют время
Свободная утилита ora2pg переносит схему и грубо конвертирует код, но с конструкциями Oracle справляется частично: результат для пакетов и коллекций приходится дописывать вручную — а это тысячи строк.
В Postgres Pro Enterprise на этот случай есть два инструмента. Первый — транспилятор ora2pgpro 2.0 в составе СУБД: в отличие от ora2pg, он строит полное дерево разбора исходного PL/SQL-кода и генерирует работоспособный PL/pgSQL, включая пакеты, коллекции и автономные транзакции. Второй — сами пакеты в PL/pgSQL: CREATE PACKAGE, функция инициализации, глобальные переменные, приватные подпрограммы. Приложению не нужно менять обращения вида имя_пакета.функция() — структура кода сохраняется, а не размазывается по схемам.
Отдельный случай — логика, завязанная на системные пакеты: отправка почты из СУБД (UTL_MAIL, UTL_SMTP), HTTP-вызовы (UTL_HTTP), инструментирование длительных операций (DBMS_APPLICATION_INFO), работа с большими объектами (DBMS_LOB, BFILE). На ванильном PostgreSQL всё это выносится из базы в приложение — по сути, отдельный проект разработки. В Enterprise эти пакеты встроены, и их API почти полностью совпадает с Oracle.
Ванильный PostgreSQL или Postgres Pro Enterprise
Бесплатного PostgreSQL достаточно, если бизнес-логика живёт в приложении, а не в базе: PL/SQL-кода мало, системные пакеты не используются, команда готова сама сопровождать СУБД и собирать отказоустойчивость из открытых компонентов. В этом случае честный ответ — платить не за что: берите ванильный PostgreSQL, этапы проекта не изменятся.
Enterprise оправдан, когда в базе накоплена серьёзная логика: каждый пакет PL/SQL на ванили — ручное переписывание, а на Enterprise — работа транспилятора плюс проверка. И когда СУБД критична: нужны кластер, сжатие, инструменты мониторинга и вендор, который отвечает за результат поддержкой с жёстким SLA. Чем редакции отличаются между собой и от бесплатной сборки — в обзоре Postgres Pro и PostgreSQL.
Товар Postgres Pro Enterprise от 358 172 ₽ Смотреть →Если система переросла один сервер, у вендора есть распределённая СУБД Postgres Pro Shardman — горизонтальное масштабирование на десятки узлов:
Товар Postgres Pro Shardman от 146 255 ₽ Смотреть →Миграция с MS SQL: два разных случая
База 1С. Перенос информационной базы 1С с MS SQL (или Oracle) на Postgres Pro выполняется только средствами платформы 1С: выгрузка в dt-файл и загрузка в пустую базу, перенос без промежуточного файла командой ibcmd infobase replicate --target-dbms=PostgreSQL либо механизм распределённых информационных баз. Первоначальную загрузку ускоряют настройками кластера: max_parallel_maintenance_workers — до половины ядер сервера, автовакуум на время загрузки отключают и затем возвращают. Подробно про выбор СУБД под 1С — в статье PostgreSQL для 1С.
Собственная система на MS SQL. Этапы те же, что и для Oracle: аудит, конвертация схемы, перенос данных, тестирование. Отличие — в переносе логики: T-SQL переводится в PL/pgSQL, и объём этой работы оценивается на аудите так же, как объём PL/SQL.
Сколько стоят лицензии Postgres Pro Enterprise
Postgres Pro Enterprise лицензируется по ядрам процессора — физическим ядрам сервера или vCPU виртуальной машины. Правила простые, но их легко посчитать неправильно:
- лицензия бессрочная и включает год гарантийного обслуживания; минимум на одну установку — 2 ядра;
- цена за одно ядро x86-64 — 716 344 ₽, вариант с расширенной гарантией 3 года — 988 557 ₽;
- в отказоустойчивых конфигурациях лицензируются все серверы кластера и все реплики, синхронные и асинхронные; голосующий узел-арбитр BiHA лицензии не требует;
- пример: продуктив на 8 ядер плюс реплика на 8 ядер — это 16 лицензий по цене ядра.
Тестовый контур на время миграции покупать не нужно: правила лицензирования Postgres Pro разрешают развернуть одну тестовую среду и одну среду разработки без дополнительных лицензий — каждая по мощности не больше купленного продуктива.
Поддержка сверх гарантийного года оформляется сертификатом технической поддержки на 1–5 лет. SLA вендора при действующем сертификате: реакция на заявку — от 15 минут в режиме 24×7, решение критичной проблемы — 4 часа, исправление ошибки в коде — 24 часа.
Как купить на юрлицо
Мигсофт поставляет Postgres Pro организациям: счёт в рублях по безналу, договор, закрывающие документы, комплект для тендера. Postgres Pro Enterprise включён в Единый реестр российского ПО, поэтому лицензии не облагаются НДС; сертификаты технической поддержки идут отдельной строкой с НДС 22 % — в счёте это разведено сразу, бухгалтерии ничего не нужно пересчитывать.
Пришлём расчёт лицензий под вашу конфигурацию — бесплатно, в течение рабочего дня. Лицензирование по ядрам с репликами и виртуализацией — то место, где ошибка всплывает на приёмке. Напишите, сколько серверов, ядер и реплик в целевой схеме, — вернём точный расчёт и спецификацию для закупки.
Частые вопросы
Сколько длится миграция с Oracle на PostgreSQL? +
Срок определяется на аудите — первом этапе проекта — и зависит в основном от объёма хранимой логики и требований к тестированию. Перенос данных — быстрая часть; дольше всего длятся конвертация PL/SQL и проверка системы под нагрузкой. Транспилятор ora2pgpro сокращает именно самую длинную часть.
Можно ли перенести базу без остановки сервиса? +
Полностью без окна переключения — редкий случай; на практике окно сокращают до минимума параллельной эксплуатацией с синхронизацией данных. У вендора для таких проектов есть Postgres ProGate — решение для миграции и репликации данных со сравнением и проверкой целостности; его применение прорабатывается в рамках проекта миграции.
Что будет с Oracle Forms и APEX? +
Это части стека Oracle, вместе с СУБД они не переносятся: экранные формы и приложения переписываются на другой стек. Планируйте это отдельным проектом рядом с миграцией базы — на аудите объём такой переработки оценивается сразу.
Нужно ли покупать лицензии на время параллельной работы двух СУБД? +
Лицензии Postgres Pro нужны на продуктивный контур новой СУБД. Тестовая среда и среда разработки входят в купленный объём без доплаты, поэтому периоды тестирования и опытной эксплуатации дополнительных лицензий не требуют.
