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-решениях.