legg,

причитайтесь к тому,что пишет andrey_anonymous.

В качестве правила большого пальца, предлагаю развить в себе рефлекс отторжения update-а.

Увидели в коде слово update - вам должно становиться физически больно, как будто вас ошпарили кипятком, или прижгли окурком.
А написали сами такое слово - должны поставить себя в угол на неделю, без допуска к пиву и женщинам.

Это все при том всём, что у Oracle одна из лучших, если не точно и строго самая лучшая реализация update,
среди всех на сей момент существующих dbms, как-то опирающихся на mvcc.

Прежде всего, следует заметить, что для Oracle ваш миллиард записей, это если уже не совсем маленькая,
но еще вовсе не такая большая таблица.
Далее,
1. Никакого row movement у вас не будет, если а) партицирование таблицы функционально не зависит от изменяемого поля,
б) поле not null, и физически необходимое место для нового значения совпадает с требовавшимся для предыдущего.

2. Если Update производится именно для того, чтобы перенести запись из одной партиции в другую, то тот или иной вариант физического перемещения так или иначе состоится.
Выписанный вами update - построчный, с небольшим преимуществом против обычного построчного, заключающегося в отсутствии переключения контекста между pl/sql и sql машинами. Но объем redo при этом сформируется примерно одинаково неприемлемый.
Именно в этих конкретных обстоятельствах delete bulk collect + forall insert может оказаться, и, скорее всего, окажется предпочтительней.
Для этой конкретной задачи хорошо смотрелся бы Merge с удалением данных на источнике. Но именно такого у Oracle нет.

3. Пока ваша таблица маленькая, (а не шибко большой, в предположении, что записи в ней не слишком широкие, она будет оставаться миллиардов до 10 записей или несколько дольше),
ни о каких альтернативах прямому проходу по блокам таблицы, с разделением на подмножества, можно не шибко задумываться.
И такую маленькую таблицу почти всё равно, на каком железе "крутить".

А дальше надо принять в расчёт, что любая инсталляция умеренно современного Oracle на любую железную конструкцию, отличную от Oracle Exadata, является всего лишь на соплях собранную демонстрационную модель, показывающую - что такое
Oracle вообще, и собираемую для предоставления возможности первичного и приблизительного ознакомления с инструментом.


Oracle, установленный на железо Exadata это просто система качественно другого класса.
Так видится, что имеющихся там инструментов вполне достаточно, чтобы на весьма длинную и плохо просматриваемую в глубину
перспективу считать, что индексы для конкретно этой задачи вам никогда не понадобятся.

Если на "обычном" железе Oracle это обычный, такой же, как и прочие, "High End", то на Exadata - это "Super High End" из другой звёздной системы.
Если Exadata нет и не предвидится, то, может быть, придется когда-то что-то мутить на индексах.
Но это плохо, в некотором отношении.

Если продолжать бросаться "правилами большого пальца", то можно сформулировать такую максиму:
Если ты установил себе Oracle сейчас, но не готов заплатить за Exadata потом
(а там разговор за минимально разумную конфигурацию только начинается от миллиона долларов),
значит ты неудачно произвёл выбор субд для своей системы.
Это просто техническая ошибка, достаточно высокой общей стоимости владения.

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

совсем ничего не понял.
ни почему архивная секция всегда пустая, ни почему она удобно называется active.

так же не понял, какой точно смысл вкладывается в

автор...мы переносим запись в другую партицию и любые манипуляции с этими данными в дальнейшем не будут влиять не текущие бизнес-процессы, на манипуляции других сессий с данными в этой таблице. кроме того будет возможность отладить , проверить-перепроверить результат в процессе тестирования. если что пошло не так , перенесли что то лишнее-ничего не поломается пока что...
за что точно идет идет борьба - за высоту индекса, за размер таблицы в tablespace
кто кому и как именно "мешает".
Кроме того, при массовых процессах такого рода, в зависимости от характера переносимых из текущей партиции данных,
могут, а в вашем сценарии скорее должны разыгрываться истории про коалеск индекса и/или move таблицы.
Процесс такого рода носит явно административный характер, и выполнять его надо в явное время оффтайм, если такое есть, или хотя бы во время минимальной нагрузки, такое в большинстве случаев так или иначе проявляется.
---------------------------
Про вычисляемый столбец вам говорят вот о чем:
Вы же изначально собирались именно update-ить поле на 1, а чтобы понять, с кем именно это сделать,
у вас есть некое условие отбора записей.

Вот это условие, в предположении его его вменяемой простоты, превращается в вычисляемое поле.
И строка сама говорит - меня пора переносить в куда-то.
Как-то так, примерно.