1. Rollback segment большой отдельный не потребуется, если разделить обновление на более скромные порции тысяч по 10.
Сделать это можно разными способами.
- можно делать update по диапазону rowid на базе карты экстентов - тут есть дополнительная опция в виде dbms_parallel_execute.
- можно делать fetch over commit в сочетании с batch update при условии, что доступ будет FTS (при индексном сильно проще налететь на ora-1555).
2. От redo на update не уйти, но имеет смысл проверить наличие и убрать supplemental logging и mat.view logs.
Еще можно перевести базу в noarchivelog на время обновления с последующей резервной копией после переключения обратно.
3. В любом случае рассмотрите вариант предоставления доступа через систему view в отдельной схеме, для выдачи наружу этот вариант тоже может подойти (в зависимости от способа передачи).

Андрюх, загоняешься. Read consistency в случае update работает несколько иначе.

Их давно отменили.

Расходы на хранение временного сегмента о 100 ярдах в табличном пространстве данных не учитываем, с вариантом обновления по частям не сравниваем :)

Вы работаете с копией, восстановленной из backup и имеете задачу системно решить вопрос data masking для передачи базы наружу на регулярной основе?
Возможно, Вам следует рассмотреть какой-либо из вариантов логического standby.

100 ярдов * 100 таблиц по линку?
Я бы даже рассматривать не стал.
Даже sql*plus copy command симпатичнее, не говоря об ETL-решениях.

CTAS по dblink сохраняет?
Ну и я не видел такого требования от ТС.

Я как-то хотел заюзать в одном проекте (на 11g, если склероз не врет).
Оказалось, что оно тихо игнорится.
Вразумление снизошло толи из доки, толи с металинка - за давностью не помню, просто принял к сведению.

chained/migrated rows

Так ТС не желает же гонять move по боевой БД. Как минимум, это требует резерв по свободному месту, которого может не быть.
Что касается chained, то их легко можно получить и на не особо длинных записях. Всего-то надо 256+ колонок и +-все записи будут сhained, я такое встречал :)