Pull to refresh

Comments 16

Я думаю стоит отметить, что эта тулза в состоянии также и конвертнуть PLSQL в PGPLSQL, но делает это не совсем хорошо. Но, все таки, может быть проще поправить уже конвертнутое решение, чем писать все самому.
Не совсем хорошо это мягко сказано. На самом деле без сильной боли можно мигрировать только в простых случаях, когда субд как записная книжка используется (кстати, а Оракл то вам зачем нужен был тогда?).
Кроме проблем конвертации кода (не, разобрать PLSQL, построить дерево, трансформировать и кодогенерировать я и сам могу). есть проблема совместимости пакетов, работы с датами, работы с лобами. Для трехзвенок приходится в отсутствии такого понятия как context в PostgreSQL весьма изощрятся. Временные таблицы в оракле временные данные, в постгресе — существуют во время сессии только.
Так что конвертнуть данные это только первый шаг по дороге миграции.
Согласен, что данные — это только начало. Но оговорюсь, что проект был простой, т.е. не содержал логику в PL/SQL.
Почему для такого простого проекта изначально был выбран Oracle? Тут всё просто — у клиента это своего рода корпоративный стандарт.
На данный момент на соседнем проекте, где очень много развесистой бизнес-логики находится в PL/SQL, мы проводим такие эксперименты. Планируем по результатам написать статью, но пока могу сказать, что результаты более чем печальные.
В связи с этим мы были вынуждены, проанализировав и поправив логику приложения, в ущерб гибкости сконвертировать его в «подходящие» типы, например, в varchar2(100)

В Postgres вроде бы нет varchar2. Я так понимаю, перешли на VARCHAR обычный?
Конечно, имелось в виду, что в исходной БД Oracle до миграции некоторые anydata пришлось перевести в varchar2. При конвертации они получили тип varchar в PostgreSQL
А как решили проблему с отсутствием в PostgreSQL такого понятия как пакеты?
Этот проект был простой и логики на PL/SQL не было. На соседнем проекте проводим эксперименты с конвертацией PL/SQL, но я пока не готов аргументированно показать «как надо». Думаю, по результатам, напишем ещё одну статью.
было бы здорово :)
а job тоже не было в проекте?
Я как раз сегодня столкнулся с этим…
А пробовали просто создать dblink в Оракле на Постгре и залить данные на Постгре?
В Оракле для любой БД можно создать коннектор. Например мы создали для mysql и писали туда данные из Оракла. Единственный нюанс нужно было писать 2 раза commit
Для MySQL есть родной как раз.
А вот для постгреса — насколько я знаю нет. Написать можно все что угодно конечно, хоть процедуру на C и ее в триггере вызывать. Сложность миграции при этом правда не снижается.
Мы по-моему не родной использовали, а через ODBC
Есть еще один способ переливки данных — настроить Foreign Data Wrapper для Oracle на стороне Postgres. Но опять же, структура уже должна существовать
Если у вас в PostreSQL уже есть структура таблиц с индексами, то можно сделать и так. Но нам же нужно было создать структуру с нуля. DDL, который есть у вас в Oracle, один в один не выполнится в PostgreSQL, нужна конвертация. Вот тут Ora2Pg и пригодился.
Only those users with full accounts are able to leave comments. Log in, please.