trace.log
Импорт по опыту всегда проходит дольше.

У меня опыта с такими объёмами не было.

На сколько дольше, в 2 раза?

это зависит от количества и размеров индексов

Ещё вопрос.


c compression=all дамп получился 1,5 Тб., выполнялся 12 часов.

если без compression, то expdp пройдёт быстрее?
Завтра это попробую.

Q.TarantinoAlionaесли без compression, то expdp пройдёт быстрее?
Завтра это попробую.
сколько parallel выставляла?
если дисковая подсистема шутрая и количество CPU позволяет - то можно поиграть с количеством потоков.

про количество parallel я уже спрашивала и Вячеслав Любомудров уже подсказал.

У меня 24 процессора, 34 таблицы > 10G.
Вчера поставила parallel=24, expdp выполнился за 12 часов.

Сегодня поставила parallel=48 - это явно многовато,
expdp работает явно быстрее, предполагаю, что проскочит за 8 часов, но в alert.log много сообщений WARNING: aiowait timed out 2 times

Вчера такие сообщения проскакивали, но редко.

Завтра попробую parallel=34 compression=NONE

Вопрос-то был такой:
ускорит ли compression=NONE процесс или нет, стоит ли пробовать?

Тролин,

Господа вы не внимательно читали, я уже об этом и писала, что retention увеличить нельзя, UNDO увеличивать нельзя.
Поэтому будем останавливать ПО пользователей.

Именно поэтому БД 2 года и работает с corrupt-блоками в UNDO.

А сейчас я пока экспериментальные замеры времени провожу.
Сегодня отключим Golden Gate, который грузит самые большие таблицы и повторим.
Надо добиться протокола без ошибок.

Вячеслав ЛюбомудровAlionaИменно поэтому БД 2 года и работает с corrupt-блоками в UNDO.Есть подозрение, что именно из-за этого ты и получишь 1555 независимо от UNDO_RETENTION и т.п.

У меня такого подозрения нет вот почему.

1.Первый раз выполняла expdp parallel=4, получила ORA-0155 по трём таблицам, дамп выполнялся 36 часов.
Golden Gate не отключали.
Как только получила ошибку по самой большой таблице в 300Гб, сразу запустила её выгрузку отдельно, она приспокойненько выгрузилась, а в это время expdp ещё долго работал.

2. Второй раз выполняла expdp parallel=24, получила ORA-0155 по 7 таблицам,
дамп выполнялся 12 часов.
Golden Gate не отключали.

3.Вчера третий раз выполняла expdp parallel=48 (это уже многовато, сильно I/O нагрузила)
Golden Gate отключили. за рабочий день, почти все таблицы успели выгрузиться, чуть-чуть осталось, несколько таблиц из прошлых (ORA-0155 по 7 таблицам) выгрузились без ошибок, но пришлось остановить. :(

4. Останавливаем Golden Gate вечером, и опять запускаю expdp parallel=24.
Есть большая надежда на то, что пройдёт без ошибок.

Вот ещё идея пришла.
Мне сейчас для дампа временно подключили диск 6 Тб.

Если выпросить диск чуть больше 10 Тб (размер БД 10Т) ,диск 6 Тб уже будет не нужен.
Создать на этом-же сервере вторую БД и запустить
impdp NETWORK_LINK=база_источник

Golden Gate по любому надо будет остановить, другие пользователи смогут работать.

Вячеслав ЛюбомудровAlionaИменно поэтому БД 2 года и работает с corrupt-блоками в UNDO.Есть подозрение, что именно из-за этого ты и получишь 1555 независимо от UNDO_RETENTION и т.п.

Сегодня expdp прошёл без ошибок, УРА !

ТролинAliona,

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

Вчера бегло просматривала документацию, таких ограничений не заметила

Nobody1111Alionaускорит ли compression=NONE процесс или нет, стоит ли пробовать?
зависит от

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

.
Выгружада с компресией parallel=24.
CPU idele 72%
a I/O уже напрягался, в alert.log появлялись предупреждения
WARNING: aiowaite timed out 1 times