Re: alter system dump...

Why do you want to go thru the redo logs to find out about chained rows ? Check dba_tables for the column chain_cnt to see which tables have chained rows in them. Check v$sysstat (or run utlbstat/utlestat) for the statistic "table fetch continued rows" to see if chained rows are even a performance issue. Finally, if they are an issue, the do "analyze table tablename list chained rows;", delete these rows from the original table and reinsert them. If this eliminates the chained rows, then they were not chained (only migrated). If you still find chain_cnt for that table, then you cannot do anything other than increase the block size by rebuiling your database. You will not gain anything from identifying statements that are accessing chained rows until you fix the chained rows problem itself.

> Actually that's the chained rows problem that i'm trying to avoid by
> using this file directly.
> and without understanding basics I won't be able to find a folution
> for such a problem.
> I mean if I can't find a classic DML in this file I won't be able to
> find chained rows or partitionned tables.
> So that's why I'm interested in the different parameter of this file.
>
Received on Fri Jun 01 2001 - 00:34:46 CDT