Originally posted by jmodic
That's not surprising, that's an expected behavior. When you add a column with the dafault value to the table in one step, oracle actualy does it in three steps in the background:

Step 1: ALTER TABLE t ADD COLUMN c DEFAULT NULL;
Step 2: UPDATE t SET c = :default_value;
Step 3: COMMIT;
Yeahhh.. I forgot to mention that you have to explicitly issue a COMMIT statement after update, but you're right about the 3steps that oracle internally does when issuing an ALTER TABLE .. ADD COLUMN... DEFAULT ... I could have figure that out if i think more deeper when that problem camed.
BTW, who DBAs that should be reminded that you need to do a COMMIT after INSERT,UPDATE,DELETE command?
Just a thought....

Originally posted by jmodic
Now, step1 by itself is a transaction that has it's own implicit commit (sort of). So when you set the transaction to use a specific RBS before your ALTER TABLE ADD COLUMN command, that specific roollback segment was used only for step1. For step2 oracle immediately chooses another rollback segment. So in fact your effort to force the usage of a particular RBS has exactly the opposite effect - you was kind of preventing it from using the RBS of your choice for the rollback-intensive part of the operation.
Amen to that.... Sometimes, when you do a lot heck of a works, issues that should have been known will also be overlooked. my bad....