Vieweralwan,
Многолетний опыт переходов от версии к версии (начиная с 7.3.2), и с платформу на платформу, которые, по ряду причин, выполнялись только через export/import, показал, что наименее затратным и быстрым, в суммарном выражении , явлется предварительное создание всех схем c раздачей прав (как на исходной базе) на объекты SYS.
В этом случае, пост-импортные действия оказываются минимальными, как и общее время выполнения всех работ.
С одной точки зрения - переход на другую версию/платформу - это действие разовое.
С другой точки зрения - в тестовом режиме всё это обычно репетируется до 3-х раз - то есть это действие многоразовое.
Но с любой точки зрения - выигрыш по конечному результату в наличии.
Лично для меня - наиболее ценными являются сбереженные нервные клетки, которые, как известно, не восстанавливаются :)

Я думаю что универсальных решений нет, все зависит от размера схемы, количества таблиц, индексов, констрейнтов, CLOB и BLOB полей и еще много чего. Базы разные, схемы тем более, то что в одном случае помогает сократить время импорта в другом только увеличивает.

Viewerflexgen...все зависит от размера схемы, количества таблиц, индексов, констрейнтов, CLOB и BLOB полей и еще много чего
Вы не совсем поняли техническую сторону этого подхода. То что вы перечислили - вещи совершенно к этому не относящиеся.
Предварительное создание профайлов, ролей, схем, раздача объектных привилегий на схему SYS (чаще всего на пакеты), позволяет ещё на начальном этапе избежать обидных ошибок, из-за которых импорт может свалится частично или полностью. Поверьте, очень обидно, когда это происходит уже на конечном этапе.
В базах с большим количеством схем и сложными взаимозависимостями, это помогает избежать ошибок создания объектов при импорте и необходимости их ручного воссоздания (чтение лога импорта при таких ошибках превщается в весьма незанимательную процедуру)
Да, очень заманчиво положится на интеллект утилит экспорта/импорта. Но нет нечего совершенного.
А вот "облегчить" им работу, а самое главное самому себе, ибо нет ничего более нудного и время поглощающего, чем воссоздание несозданных объектов. А самое главное - их связей, зависимостей, грантов.
Молчу о психологичком состоянии админа - когда приходится запускать пользователей в базу, а у самого нет уверенности, что всё стоит по местам.
К сожалению, как разумно ленивые, мы к этому подходу (не я один) пришли лишь лет через пять, когда накопился статистический опыт.
Последние несколько лет миграции баз проходять быстро, безболезненно, с минимальными пост-проверками.
И спим спокойно :)

На нынешнем месте работы, а работаю я тут уже 6 лет, нами было проведено несколько сотен разного рода экспортов/импортов. Всего же я работаю на этом поприще вот уже 22 года, посему думаю что я неплохо знаю как и что надо делать.

Например, 5 лет назад я был участником проекта апгрейда Siebel 6 на Siebel 8, частью проекта была миграция всех схем с Oracle 8i на Oracle 11.2.0.3, с серверов Alpha Tru64 на сервера Linux. Основной задачей было сохранить все данные, накопившиеся за 10 лет. Первоначально представители Oracle заявили что подобное невозможно, предложили нам просто построить систему с нуля. Как выяснилось у них даже специалистов по Siebel 6 уже не было.

Проект занял год, а сама миграция и апгрейд - 36 часов. Все что было вами перечислено - роли, профили, права доступа, tablespaces и т.д., все что можно было создать заранее было создано заранее, но когда в базе более 3 тысяч таблиц и более 15 тысяч индексов то поневоле задумаешься, а как бы сделать так что бы уложиться в заданное время, плюс надо учесть что сама миграция - это всего лишь треть от общего объема работ. Мы тогда не одну собаку съели и не с одним пудом соли только на экспорте/импорте. И когда мы отдавали базу после импорта, мы были уверены на 101% что ни один объект не потерян, ни одно право доступа не утеряно, все объекты скомпилированы.

Это всего один пример, вот еще - каждый год мы обновляем Test и Beta environments данными с Production, таких баз у нас 18, т.е. каждый год 36 экспортов/импортов баз размером от 4 ТБ до 17 ТБ.

З.Ы. Прошло 5 лет, и мы опять работаем над апгрейдом Siebel. :-)