ESTIMATE_ONLY ?

Это и есть приблизительный размер дампа (данные тащить надо все, а вот индексы не надо -- достаточно команды на пересоздание)
Ну и плюс тонкости со сжатыми таблицами (если не DIRECT_PATH, то в дамп они попадут разжатыми) и, соответственно тонкости с DIRECT_PATH (там сжатые таблицы поедут сжатыми, но вот насчет обычных разреженных таблиц точно не скажу, возможно пустое место не поедет, но есть вероятность что блоки поедут как есть)
Ну, а файлов для дампа ты можешь использовать несколько, разложив их по разным местам

На скорость заливки очень сильно влияют типы данных, если много LOB-ов все будет достаточно медленно
Но тебе ничего не мешает выполнять импорт (да и экспорт) в параллель

Никто2223Aliona,

Если мне память не изменяет, то это связано с тем, что какой-то ДМЛ не параллелится. Параллелить DML/DDL совсем не обязательно, если экспорт был сделан в несколько потоков (и файлов, соответственно), то и импорт можно будет запустить так, чтоб каждый подчиненнный процесс заливал из своего файла (PARALLEL <= количеству дамп-файлов), а не лезли всем колхозом в один файл, мешаясь друг другу
Если еще и файлы дампа разложены на разных устройствах -- вообще замечательно
Никто22231. Експорт дампа нужных схем
2. Импорт только стркутуры этих данных на целевую БД (metadata_only)
3. Удаление констрейнтов/индексов руками (они тормозят импорт)
4. Импорт данных в созданную структуру (DATA_ONLY)
5. Восстановление индексов, пк и фк (фк при валидации медленно работает если поля не индексированы) руками же хоть с parallel, хоть в К потоков.Если заливать в пустую БД, то ничего удалять и восстанавливать не придется, ибо индексы и констрейнты поднимутся только после заливки данных
Хотя, так действительно можно увеличить количество потоков пересоздания индексов (если PARALLEL не достаточно), но ведь PARALLEL можно увеличить и в процессе импорта

Конечно, все это только если редакция позволяет

С expdp не пролезет ни через pipe, ни на ленту
Но подключить чужие диски по NFS вполне нормально