EvgeniaMakarovaMelkomyagkii_newbi, да я спросила дба, но они меня послали лесом. Они, по-моему не очень разбираются в 12-шке.

вообще, мы и мигрировать будем в тот же день грубо говоря на 12-шку с 10-ки, так что еще ничего не засетаплено.

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

Все не так просто?
Как сделать, чтобы все же просто было достать бд до релиза и ее юзать ?

Миграция БД и миграция приложения на новую версию БД, это сильно разные вещи

Как правило, это нехилый проект (если только у Вас не игрушечная база)

Прежде чем катить prod на новую версию, желательно
1) функциональное тестирование ( проверка того, что у Вас корректно работают по крайней мере
все business critical компоненты)


2) нагрузочное тестирование - ( проверка что у Вас не поплывут планы и система не встанет колом в самый неподходящий момент).

Без этого, миграция - лотерея

из практики (два очень, разных, очень крупных заказчика):

Первый подход:
миграция 7.3 -> 9i

- Создана рабочая группа, включающая в себя dba, разработчиков, руководителей отделов и ответственного от руководства.

- Выделены ресурсы для стенда, и назначены координаторы для каждой группы.
business critical процессы тестировались под личную подпись каждого начальника отдела.

в процессе работы,
- выполнялось тестовое мигрирование,
- функциональное тестирование сначала разработчикам, затем в отделы.
- каждая проблема регистрировалась в jira и контролировалось ее решение
- создавался пошаговый план миграции.
- после окончания, все сносилось и система по новой мигрировалась по полученному плану.
- был план по откату, в случае форс мажора. С глубиной до 3-х дней (очень дорогой по ресурсам, с полуручным вводом критических данных)

За полгода, не торопясь, было выполнено 4 итерации, пока ошибок не осталось.

Само мигрирование прошло как-то скучно, без огонька. Всплыло 3 незначительных проблемы, которые были оперативно решены.

Второй подход:

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

миграцию выполнили, система почти сразу встала колом, более менее заработала через дня три
через неделю - почти пришла в себя
но грабли, в том числе критические вычищали еще года три

Какое - то магическое число 3 :)
Но увы, это факт

EvgeniaMakarova,

Тогда, Вам имеет смысл смотреть на storage snapshot (если Ваша дисковая система позволяет)
например unix lvm rollback
Лучше от делать на остановленной базе

Бо 10-> 12 дюже серьёзная миграция

боюсь что oracle гарантированная точка восстановления тут мало поможет.
хотя заявлена обратная совместимость rman 10-12