Re: Incorrect Migrated/Chained rows...

> The number of columns is the most relevant
> point. A row defined with more than 250-ish
> columns is stored as up to 4 separate row pieces,
> and is therefore chained - even if all 4 pieces are
> in the same block.
>
> If most of your rows are NULL after column 250(-ish),
> then the piece with all the nulls would not be required,
> which is why you would be able to see just a few
> thousand rows apparently chained after copying out
> 400,000 rows.

This skews both dba_tables.chain_cnt value as well as statistics 'table fetch continued row'. OK then, how would you measure the true row-chaining/migration? You can't rely on these stats any longer to decide if table needs reorg/rebuilt.  

> BUT - I discounted the 'long row' theory when I read
> your post, because when you re-copied the table, you
> had no chained rows. It seems like from your description,
> though, that Oracle may have changed the way it handles
> chaining when it is intra-block chaining - a couple of the things
> it did in 8.1 needed refinement.

You mean allowing more than 255 columns. Right?

Anyway, Oracle confirmed this as an open bug (Code + documentation). Bug is still under investigation.. They are correcting the documentation , the part that describes chain_cnt and 'table fetch continued row'.

Thanks Received on Wed Apr 28 2004 - 14:51:40 CDT