expdp导出表数量接近但是时间差距明显原因

日前接到一个case，用户反映一个表导出时间特别长，因为担心影响第二天业务，不得不放弃继续导出，但是另外一个表比这个问题表数量更大，但是反而顺利导出，用户在相同版本测试环境上也能顺利导出，当然测试环境和生产环境还是有差异的，客户说那个环境是用两个月前的备份恢复而成的，但是数据量差距并不十分明显，但是导出时间却天壤之别，于是让客户对expdp进行trace，因为导出时间特别长，所以只做了30min的，通过tkprof 查看，时间基本都是io操作，但是因为另外一个表比这个数据量还大却能顺利导出，所以可以排除是IO瓶颈问题，于是查看原始trace文件，大量的db file sequential read，统计了一下，数量非常之多，接近了blocks数量，随便查找了一个block#，居然发现有多条记录，例如下面的block#=1985

WAIT #140339720797184: nam=’db file sequential read’ ela= 4 file#=14 block#=1985 blocks=1 obj#=110002 tim=1458371261234480
WAIT #140339720797184: nam=’db file sequential read’ ela= 7 file#=13 block#=1989 blocks=1 obj#=110002 tim=1458371261234585
<skiping>……
WAIT #140339720797184: nam=’db file sequential read’ ela= 3 file#=14 block#=1985 blocks=1 obj#=110002 tim=1458371261234500
WAIT #140339720797184: nam=’db file sequential read’ ela= 8 file#=11 block#=1993 blocks=1 obj#=110002 tim=1458371261235086
WAIT #140339720797184: nam=’db file sequential read’ ela= 4 file#=8 block#=2385 blocks=1 obj#=110002 tim=1458371261234521
WAIT #140339720797184: nam=’db file sequential read’ ela= 4 file#=12 block#=2481 blocks=1 obj#=110002 tim=1458371261234541

为啥相同block要读取多遍呢，难道是遇到了bug？客户环境是10.2.0.5，expdp方面的bug应该是相当少的，突然想到应该是有行迁移或行链接造成的，于是让用户进行表分析，并查看CHAIN_CNT果然数值非常高，但是测试环境和另外一个数据更大的表却不是，所以解决办法是找个时间对表进行重建就行了。