Analyzing chained and migrated rows

Two articles from the renowned authors:

1. Analyze-this by J. Lewis
   Shortcut:
   

   -- gathering statistics populates among others user_tables.chain_cnt
   analyze table [tbl] compute statistics for table;
   -- check gathered data
   -- delete statistics 
   -- otherwise the optimizer will use the chain_cnt to modify 
   -- the cost of indexed access to the table
   analyze table [tbl] delete statistics; 
   exec dbms_stats.gather_table_stats([owner], [tbl]);
   

2. Detect-chained-and-migrated-rows-in-oracle by T.Poder
   Excerpt:
   One way to estimate the impact of chained rows is to just look into the "table fetch continued row" statistic - one can run query/workload and measure this metric from v$sesstat (with snapper for example). And one more way to estimate the total number of chained pieces would be to run something like SELECT /*+ FULL(t) */ MIN(last_col) FROM t and see how much the "table fetch continued row" metric increases throughout the full table scan. The last_col would be the (physical) last column of the table. Note that if a wide row is chained into let's say 4 pieces, then you'd see the metric increase by 3 for a row where 4th row piece had to be fetched.