We do the read consistency at the block level, not the column level so yes -- the rollback segments would be checked at that point in time. We reconstruct the block as it appeared at the time your query began. We do not bother to check (in fact there would be insufficient data to check if you overwrite the rollback) if the particular COLUMNS you desire have been modified. There is no way for us to do this.

Your choices are:

o suffer the inevitable ora-1555's you will get on the long running queries.

o size a rollback segment sufficiently large to hold the rollback generated by the update WITHOUT committing and use this rollback segment specifically. This will avoid the ora-1555's during the update. drop the rbs after you no longer need it.

o size the rollback segments to be large enough to not wrap in a 3-4 hour period. Make them this big BEFORE you start updating (do not rely on them extending -- extend them yourself). This will avoid the ora-1555.

o since adding 7 columns and then updating them will undoubtably cause MASSIVE row chaining, almost every row in this table will migrate I am sure, consider building the table in its entirety off to the side as a combination of OLD table and the NEW updated rows -- do this as a CREATE TABLE AS SELECT with the unrecoverable option (instead of updating these 7 columns, perform the logic in the SELECT portion of the create table as select you would have done during the update). Index this table using parallel unrecoverable index creates. rename the OLD table to T_OLD. Rename this new table to T. Drop the old table after you are convinced all is well. In order to do the DDL to rename -- you will have to find a short period where no one is querying the table. This will result in a nicely rebuilt, unchained table and no ora-1555's and a very very short downtime window.