Best way to update 8 out of10 million records

Question

Hi friends,
I want to update a table 8 million records of a table which has 10 millions records, what could be the best strategy if the table has a BLOB column with 600GB worth of data. BLOB itself is 550GB.  I am not updating the BLOB column.
Usually with non-BLOB data i have tried doing "CREATE TABLE new_table as select <do the update "here"> from old_table;" method .
How should i approach this one?

Answer 1

@Mark D Powell
To give you a background my client faced this problem  a week ago , This is part of a daily cleanup activity .
Right now i don't have the access to it due to security issue . I could only take few AWR reports and stats when the access window was opened. So basically next time when i get the access i want to close the issue once and for all
Coming to your questions:
So what is wrong with just issuing an update to update all 8 Million rows? 
In a previous run , of a single update with full table scan in the plan with no parallel degree it started reading from UNDO(current_obj=-1 on event "db file sequential read" wait event) and errored out after 24 hours with tablespace full on the tablespace which contains the BLOB data(a separate tablespace)
To add to the problem redo log files were sized too less , about 50MB only .
The wait events (from DBA_HIST_ACTIVE_SESS_HISTORY )for the problematic sql id shows
-  log file switch (checkpoint incomplete) and log file switch completion as the events comprising 62% of the wait events
-CPU 29%.
-db file sequential read 6%.
-direct path read 2% and others contributing a little.
30 % of the samples "db file sequential read" had a current_obj#=-1 & p1 showing undo file id.
Is there any concurrent DML against this table? If not, the parallel DML would be an option though it may not really be needed. 
I think there was in the previous run and i have asked to avoid in the next run.
How large are the base table rows?
AVG_ROW_LEN is 227
How many indexes are effected by the update if any?
The last column of the primary key column is the only column to be updated ( i mean used in the "SET" clause of the update)
Do you expect the update will cause any row migration?
Yes i think so because the only column which is going to be updated is the same column on which the table is partitioned.
Now if there is a lot of concurrent DML on the table you probably want to use pl/sql so you can loop through the data issuing a commit every N rows so as to not lock other concurrent sessions out of the table for too long a period of time.  This may well depend on if you can write a driving cursor that can be restarted in the event of interruption and would skip over rows that have already been updated.  If not you might want to use a driving table to control the processing.
Right now to avoid UNDO issue i have suggested to use PL/SQL approach & have asked increasing the REDO size to atleast 10 times more.
My big question after seeing the wait events profile for the session is:
Which was the main issue here , redo log size or the reading from UNDO which hit the update statement. The buffer gets had shot to 600 million , There are only 220k blocks in the table.