Yes,
devmiral...Rollback entries (or UNDO entries, as they are also known) contain an image of data as it appeared prior to a change taking place. For example, if the field, "SCREEN_NAME" contained "SantaMufasa" prior to my updating it to "SantaDave", then "SantaMufasa" would be the datum that Oracle stores in the Rollback entry, while "SantaDave" would reside in the actual record where "SantaMufasa" used to reside.
If the updater issues a "ROLLBACK" command, then Oracle goes to the Rollback entry, obtains "SantaMufasa", and overwrites "SantaDave" with the original value, "SantaMufasa".
If the updater issues a "COMMIT" command, the Oracle releases the Rollback area for use by some other transaction, and the block of data that contains "SantaDave" is now the data that all other uses see when they query that record.
When a transaction begins, Oracle, by default, assigns the transaction to one (and only one) rollback segment.
All of the pre-change data that occurs during that transaction must reside within that single rollback segment.
Oracle DBAs occasionally create a rollback segment that is much larger than the other rollback segments for use by transactions that are known to generate greater-than-usual rollback entries.
Rather than leave up to Oracle's round-robin algorithm, the choice of which rollback segment to assign to the large transaction, one can use the code that you mentioned:
Code:
Set Transaction Use Rollback Segment RBSHUGE;
...which causes the large amount of rollback data to reside (during the transaction) in the HUGE rollback segment.
Did this answer your question?
![[santa] [santa] [santa]](/data/assets/smilies/santa.gif)
Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services:
www.dasages.com]