Re: alter system dump...

"John" <j_barbe_at_hotmail.com> wrote in message news:8bc78dd8.0106010223.cca3da5_at_posting.google.com...
> > 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 not this problem that I want to solve.
> Transactions that affects chained rows can't be displayed by logminer
> so I was just wondering if it's possible to get information about this
> transactions by looking directly in the redo log files.
>

in order to do this, you need to keep track of all of the chained and migrated rows. you'd need to know the current state of all chained and migrated rows for a particular table at the point in time you started reading the log, and then you'd need to detect transactions that cause row migration or chaining, and then keep track of the rows that were affected by those changes... all of which is a non-trivial task.

at least, that's what the log based replication solution we have does for us... but i sincerely doubt the software vendor is going to give away its proprietary technology... not when it represents such a competetive advantage for them...

HTH Received on Sat Jun 02 2001 - 23:44:59 CDT