日前接到一个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果然数值非常高，但是测试环境和另外一个数据更大的表却不是，所以解决办法是找个时间对表进行重建就行了。




set lines 150 pages 100 numwidth 7
col program for a38
col username for a10
col spid for a7
select s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from v$session s, v$process p, DBA_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;




PROGRAM SID STATUS USERNAME JOB_NAME SPID SERIAL# PID
-------------------------------------- ------- -------- ---------- ------------------------------ ------- ------- -------
oracle@server02 (DW04) 2235 ACTIVE SYS SYS_EXPORT_TABLE_01 5417 59 190
oracle@server02 (DW03) 2165 ACTIVE SYS SYS_EXPORT_TABLE_01 5415 469 188
oracle@server02 (DW02) 2091 ACTIVE SYS SYS_EXPORT_TABLE_01 5375 1443 186
oracle@server02 (DW01) 2199 ACTIVE SYS SYS_EXPORT_TABLE_01 5267 169 189
oracle@server02 (DW00) 1840 ACTIVE SYS SYS_EXPORT_TABLE_01 65409 233 179
oracle@server02 (DM00) 1408 ACTIVE SYS SYS_EXPORT_TABLE_01 63477 3517 39
ude@server02 (TNS V1-V3) 3 ACTIVE SYS SYS_EXPORT_TABLE_01 62550 103 192


7 rows selected.




打开trace文件日志跟踪，等待10分钟
execute sys.dbms_system.set_ev(2199,169,10046,8,'');
关闭trace文件日志跟踪
execute sys.dbms_system.set_ev(2199,169,10046,0,'');


找到trace文件
sypmjt2_dw01_5267.trc


可以看到
WAIT #140365092251440: nam='db file sequential read' ela= 6275 file#=27 block#=3137332 blocks=1 obj#=75841554 tim=1470634155505446
WAIT #140365092251440: nam='db file sequential read' ela= 14319 file#=29 block#=3340314 blocks=1 obj#=75841554 tim=1470634155519872


oracle 进行表分析，并查看CHAIN_CNT数值
SQL> analyze table USER.TABLE compute statistics;


Table analyzed.


SQL> select table_name,chain_cnt from dba_tables where table_name='TABLE';


TABLE_NAME CHAIN_CNT
------------------------------ ----------
TABLE 17


注意，chain_cnt记录的是行迁移和行连接的数量，不要以为这个值大于0就发生了行迁移，也可能是行连接，此时要分析表的结构，查看到底是行连接或者是行迁移

日前接到一个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果然数值非常高，但是测试环境和另外一个数据更大的表却不是，所以解决办法是找个时间对表进行重建就行了。




set lines 150 pages 100 numwidth 7
col program for a38
col username for a10
col spid for a7
select s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from v$session s, v$process p, DBA_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;




PROGRAM SID STATUS USERNAME JOB_NAME SPID SERIAL# PID
-------------------------------------- ------- -------- ---------- ------------------------------ ------- ------- -------
oracle@server02 (DW04) 2235 ACTIVE SYS SYS_EXPORT_TABLE_01 5417 59 190
oracle@server02 (DW03) 2165 ACTIVE SYS SYS_EXPORT_TABLE_01 5415 469 188
oracle@server02 (DW02) 2091 ACTIVE SYS SYS_EXPORT_TABLE_01 5375 1443 186
oracle@server02 (DW01) 2199 ACTIVE SYS SYS_EXPORT_TABLE_01 5267 169 189
oracle@server02 (DW00) 1840 ACTIVE SYS SYS_EXPORT_TABLE_01 65409 233 179
oracle@server02 (DM00) 1408 ACTIVE SYS SYS_EXPORT_TABLE_01 63477 3517 39
ude@server02 (TNS V1-V3) 3 ACTIVE SYS SYS_EXPORT_TABLE_01 62550 103 192


7 rows selected.




打开trace文件日志跟踪，等待10分钟
execute sys.dbms_system.set_ev(2199,169,10046,8,'');
关闭trace文件日志跟踪
execute sys.dbms_system.set_ev(2199,169,10046,0,'');


找到trace文件
sypmjt2_dw01_5267.trc


可以看到
WAIT #140365092251440: nam='db file sequential read' ela= 6275 file#=27 block#=3137332 blocks=1 obj#=75841554 tim=1470634155505446
WAIT #140365092251440: nam='db file sequential read' ela= 14319 file#=29 block#=3340314 blocks=1 obj#=75841554 tim=1470634155519872


oracle 进行表分析，并查看CHAIN_CNT数值
SQL> analyze table USER.TABLE compute statistics;


Table analyzed.


SQL> select table_name,chain_cnt from dba_tables where table_name='TABLE';


TABLE_NAME CHAIN_CNT
------------------------------ ----------
TABLE 17


注意，chain_cnt记录的是行迁移和行连接的数量，不要以为这个值大于0就发生了行迁移，也可能是行连接，此时要分析表的结构，查看到底是行连接或者是行迁移