如何通过AWR发现行迁移_table fetch continued row统计指标解读-Oracle-PHP中文网

table fetch continued row 高说明表中存在大量行迁移，即UPDATE导致行被整行搬移至新数据块，访问时需额外I/O拼合，反映在堆表的ROWID访问路径中，非行链接或索引问题。

AWR 中 `table fetch continued row` 高说明什么

这个统计值高，基本等于在说：表里存在大量行迁移（row migration）——不是行链接（row chaining），是同一行被拆开放在不同数据块里，且后续访问需要额外 i/o 才能拼完整。它不反映索引扫描问题，只出现在堆表的 table access by index rowid 或全表扫描路径中。

常见错误现象：table fetch continued row 每秒几十甚至上百次，但 db block gets 和 consistent gets 明显偏高，同时 physical reads 却没同比飙升，说明热点行反复被“跳着读”；配合 v$segment_statistics 查具体对象，常会发现某张大表的 logical reads 远高于其 buffer busy waits 或 read by other session，这是迁移而非争用的典型信号。

只对堆表有效；IOT、分区索引组织表、外部表不计入此指标
Oracle 10g 及以后版本才稳定采集，9i 下该值常为 0 或严重低估
单次迁移行被访问 N 次，该计数就 +N，不是“迁移行数量”，而是“被迫二次定位的次数”

怎么从 AWR 报告定位哪张表在迁移

别直接翻 AWR HTML 报告首页的 Top SQL —— table fetch continued row 是实例级累计值，必须下钻到 Segment Statistics 部分。打开 AWR 报告后，按 Ctrl+F 搜 Segment Statistics，找到 “Physical Reads” 或 “Logical Reads” 排名靠前的段，再看同一节里的 Table Fetch Continued Row 列（有些版本叫 Table Fetch By Rowid 子类）。

更准的做法是查 dba_hist_seg_stat：

SELECT owner, object_name, object_type,
       SUM(CASE WHEN stat_name = 'table fetch continued row' THEN value ELSE 0 END) AS continued_fetches
FROM dba_hist_seg_stat s
JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id
WHERE sn.begin_interval_time > SYSDATE - 1
  AND object_type = 'TABLE'
GROUP BY owner, object_name, object_type
HAVING SUM(CASE WHEN stat_name = 'table fetch continued row' THEN value ELSE 0 END) > 1000
ORDER BY continued_fetches DESC;

注意时间范围：必须跨至少两个快照，否则 dba_hist_seg_stat 可能为空
过滤 object_type = 'TABLE' 很关键，索引段也会有该统计但无实际意义
如果结果为空，检查是否启用 STATISTICS_LEVEL = TYPICAL（BASIC 下不收集段级统计）

`ANALYZE TABLE ... LIST CHAINED ROWS` 能不能查出行迁移

不能。这个命令只捕获行链接（chained rows），即 INSERT 时单行就超过块大小，被迫跨块存储的情况。而行迁移（migrated rows）是 UPDATE 导致原块放不下、整行被搬走，LIST CHAINED ROWS 对它完全无感。

真正能抓迁移行的是 v$session_longops 配合 DBMS_ROWID，但太重；生产环境更推荐直接查 CHAINED_ROWS 视图的补充字段或用以下轻量方式：

SELECT COUNT(*) 
FROM your_table 
WHERE ROWID IN (
  SELECT CHAIN_ROWID FROM CHAINED_ROWS 
  WHERE OWNER = 'YOUR_SCHEMA' AND TABLE_NAME = 'YOUR_TABLE'
);

先确保已运行过 ANALYZE TABLE ... LIST CHAINED ROWS 建好 CHAINED_ROWS 表
上面 SQL 返回非零 ≠ 有迁移行，只是说明链式行存在；迁移需结合 dba_tab_partitions 的 avg_row_len 与 pct_free 对比判断
最可靠方式：查 v$sysstat 中 table fetch continued row 增速，再对比对应表的 UPDATE 频率 —— 如果更新密集且 pct_free 设置过低（比如

修复迁移行时最容易被忽略的点

重建表（ALTER TABLE ... MOVE）或收缩（SHRINK SPACE COMPACT）能清理迁移行，但做完之后必须立刻做两件事：更新统计信息、重建受影响的索引。

ALTER TABLE t MOVE 后，所有基于原 ROWID 的索引会失效（STATUS = UNUSABLE），不重建就查不到数据
SHRINK SPACE 要求表启用行移动（ENABLE ROW MOVEMENT），否则报错 ORA-10636: row movement is not enabled
即使用了 SHRINK SPACE CASCADE，也不会自动更新统计信息 —— DBMS_STATS.GATHER_TABLE_STATS 必须手动触发，否则执行计划可能继续走错路
迁移行多通常意味着频繁 UPDATE + 小 pct_free，修复后若不调高 pct_free（比如从 10 改成 20），几周后又会复发