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

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

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

С мат. вью тоже без большого лока, только быстрее в разы.

kapelan,

индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap,
и насколько это совместимо с общей логикой использования целевой таблицы - издалека не видно.

3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
Впрочем, повторяюсь.

1. Если update одной транзакцией, то нужен будет большой rollback segment.

2. Statement restart - серьезная проблема для больших update - убедитесь, что не наступите.

уточню - паралелль здесь не в смысле ENABLE_PARALLEL_DML, а в смысле два независимых процесса, обрабатывающих непересекающиеся диапазоны.

по сути
DBMS_PARALLEL_EXECUTE и делает это вроде бы?
теоретически можно, но не особо смысл есть мне кажется. нет жестких требований к времени. главное - не положить систему

Это чудный механизм согласования целостности при dml.
Применяется при update, delete, select for update и merge (с древним но непофиксенным багом).
Если утрировать (там деталей миллион), то смысл в следующем: бредет процесс update по блокам таблицы.
По их current версиям.
Строчки перебирает, на предикат тестирует.
И набредает на запись, которая:
- подходила под предикат на момент запуска запроса (на scn согласования)
- была изменена после запуска update конкурирующей транзакцией
- изменение вывело запись из предиката.
Упс! думает процесс, тут такое дело, набор данных-то рассогласован, надо что-то делать!
Ну и откатывает ВСЕ произведенные до той поры изменения, хоть 99999999 из 10000000
После чего начинает всё с начала.
...а юзер ждет у моря погоды.
И чем больше времени прошло от запуска запроса, тем выше вероятность влететь в ситуацию рассогласования и тем больший объем rollback он будет откатывать, а затем закатывать обратно на новый scn.