Re: Incorrect Migrated/Chained rows...

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:<c6nh8s$fsb$1_at_sparta.btinternet.com>...
> 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.

OK I did further tests. I got all the reported chained rows from temp_s_contact_03 into another table TEMP_S_CONTACT_04. and again all the reported chained rows from TEMP_S_CONTACT_04 into TEMP_S_CONTACT_05. Here are my results. Chained rows are reducing in each iteration.. Can you explain why?
From what you explained earlier, nos of migrated/chained rows should have stayed the same with each iterations. Right!!!

TABLE_NAME                     CHAIN_ROW_COUNT
------------------------------ ---------------
TEMP_S_CONTACT_03                         6056
TEMP_S_CONTACT_04                           79
TEMP_S_CONTACT_05                            1   

Here are the nos of blocks for each segments. There were no initial, next extent submitted. and tables were created with default storage settings in DM tablespace. Here is the nos of blocks (8k) for each table.

Table_name                        Blocks
--------------                   ---------
TEMP_S_CONTACT_03                   49607    
TEMP_S_CONTACT_04                     615
TEMP_S_CONTACT_05                     133  

Thanks Received on Wed Apr 28 2004 - 17:47:47 CDT