Re: 10gR2 - direct path load with enabled indexes - lots of undo generated from indexes

Thanks Dimitre I read the who whole thread.

Still the following two items puzzle me from a technology point of view. 1. why is there no special case where the index is empty at the start of the transaction
2. why does it take as much undo space as the whole index, to undo a merge of something big into something non-existant.

On 5/30/06, Radoulov, Dimitre <cichomitiko_at_gmail.com> wrote:
>
>
> > All: Just to clarify, we are talking about undo (rollback data - for
> > transaction recovery). Not about redo (online redo logs for crash
> > recovery).
>
> From Tom Kyte's forum:
>
> <quote>
>
> q1) you have indexes on the table. indexes cannot be "appended" to, they
> must
> be modified. These modifications must be logged. The redo/undo for the
> table
> itself is not generated, the redo/undo for the INDEXES always is.
>
> </quote>
>
> http://tinyurl.com/lujwg
>
> > All: Just to clarify, we are talking about undo (rollback data - for
> > transaction recovery). Not about redo (online redo logs for crash
> > recovery).
>
> From Tom Kyte's forum:
>
> <quote>
>
> q1) you have indexes on the table. indexes cannot be "appended" to, they
> must
> be modified. These modifications must be logged. The redo/undo for the
> table
> itself is not generated, the redo/undo for the INDEXES always is.
>
> </quote>
>
> http://tinyurl.com/lujwg
>
>
> Dimitre

-- 
Christo Kutrovsky
Senior Database/System Administrator
The Pythian Group - www.pythian.com
I blog at http://www.pythian.com/blogs/
--
http://www.freelists.org/webpage/oracle-l