Thanks for that. It’s a useful piece of information.

index rebuild online full description

In Oracle 9201, when index recreate process finished,
Oracle will first apply all the changes committed to the journal log,
Then acquire an Share Lock on the Base Table,
Until it get the Share lock,
Then Oracle will apply the journal log in the IOT Table after previous apply(the changes made by the sessions blocking the acquire of the Share Lock),
Then Oracle will clear the interim state(drop the journal table),
Then Oracle will change the dictionary info about the index(mainly change the data_object_id of the index),
Then Oracle release the Share Lock and the Rebuild index process finished completely.

Directly after the start and before the end of the create/rebuild, the table is completely locked. If there are no open transactions on the table in question, these locks are only retained for a short time. However, if there are open transactions on the table in question when the lock is requested (TX enqueue) for the create/rebuild, the rebuild waits until all of these transactions are committed. Event ’10629′ was introcduced to avoid such situations at the start and end.

By the way, if you are using leve = 1 the cleanup by SMON differs and an ORA-08104 can occur.

Regards
Stefan

Thanks for the information.
Do you have any idea if it behaves the same way for both the starting and ending lock – and if there are any variations with version ?
I have the following from the oraus.msg file from 10.2.0.1 (which is less informative than your information):

10629, 00000, "force online index build to backoff and retry DML lock upgrade"
// *Cause:
// *Action: set this event only under the supervision of Oracle development
// *Comment: Change the behaviour of an online index rebuild such that it 
//           will backoff and retry a failed DML lock upgrade.
//           The event level is the number of retries the online index rebuild
//           should wait. Level 1 means backoff and retry indefinitely. Any 
//           other value less than 32 will be adjusted automatically to be 32.

The different levels of event ’10629′ are:
- Level 1 tries as often as required to obtain the enqueue
- Level 32, 64, 96, .. attempts times to obtain the enqueue. If it does not succeed after the specified number of attempts, ORA-00054 occurs.

I also wrote an blog about it on my SAP page (not sure if you are able to see it without having an account on SDN): http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9961

Regards
Stefan

P.S.: Looking forward to your event with Kyle Hailey on 10/06/2010.

I have just put a short note on my blog regarding some locking related to online index rebuilds. It’s a bit more detail on the issue with long active transactions blocking online rebuilds.

Regards

Nigel.

Thanks for the comment – I’ve added a further note to the OTN thread (rather than split the discussion between two places)raising the question of how Oracle handles a scenario in the interval between the lock being released and the last update being applied. If you know how Oracle handles that case I’d be interested in hearing the details; it strikes me that scenarios of that type might be the reason why the code changed between 10g and 11g.