Oracle

行链接(Row chaining) 与行迁移(Row Migration) 摘自itpub
当一行的数据过长而不能插入一个单个数据块中时，可能发生两种事情：行链接(row chaining)或行迁移(row migration)。

  行链接
当第一次插入行时，由于行太长而不能容纳在一个数据块中时，就会发生行链接。在这种情况下，oracle会使用与该块链接的一块或多块数据块来容纳该行的数据。行连接经常在插入比较大的行时才会发生，如包含long, long row, lob等类型的数据。在这些情况下行链接是不可避免的。

  行迁移
  当修改不是行链接的行时，当修改后的行长度大于修改前的行长度，并且该数据块中的空闲空间已经比较小而不能完全容纳该行的数据时，就会发生行迁移。在这种情况下，Oracle会将整行的数据迁移到一个新的数据块上，而将该行原先的空间只放一个指针，指向该行的新的位置，并且该行原先空间的剩余空间不再被数据库使用，这些剩余的空间我们将其称之为空洞，这就是产生表碎片的主要原因，表碎片基本上也是不可避免的，但是我们可以将其降到一个我们可以接受的程度。注意，即使发生了行迁移，发生了行迁移的行的rowid 还是不会变化，这也是行迁移会引起数据库I/O性能降低的原因。其实行迁移是行链接的一种特殊形式，但是它的起因与行为跟行链接有很大不同，所以一般把它从行链接中独立出来，单独进行处理。

行链接和行迁移引起数据库性能下降的原因：
引起性能下降的原因主要是由于引起多余的I/O造成的。当通过索引访问已有行迁移现象的行时，数据库必须扫描一个以上的数据块才能检索到改行的数据。这主要有一下两种表现形式：
1)  导致row migration 或row chaining INSERT 或 UPDATE语句的性能比较差，因为它们需要执行额外的处理
2)  利用索引查询已经链接或迁移的行的select语句性能比较差，因为它们要执行额外的I/O

如何才能检测到行迁移与行链接：
在表中被迁移或被链接的行可以通过带list chained rows选项的analyze语句识别出来。这个命令收集每个被迁移或链接的行的信息，并将这些信息放到指定的输出表中。为了创建这个输出表，运行脚本UTLCHAIN.SQL。

  SQL> ANALYZE TABLE scott.emp LIST CHAINED ROWS;
  SQL> SELECT * FROM chained_rows;
 
当然你也可以通过检查v$sysstat视图中的'table fetch continued row'来检查被迁移或被链接的行。

SQL> SELECT name, value FROM v$sysstat WHERE name = 'table fetch continued row';
  NAME                                                  VALUE
  ----------------------------------------------------------------                           ---------
  table fetch continued row                                  308

尽管行迁移与行链接是两个不同的事情，但是在oracle内部，它们被当作一回事。所以当你检测行迁移与行链接时，你应该仔细的分析当前你正在处理的是行迁移还是行链接。

解决办法
o 在大多数情况下，行链接是无法克服的，特别是在一个表包含象LONGS, LOBs 等这样的列时。当在不同的表中有大量的链接行，并且哪些表的行的长度不是很长时，你可以通过用更大的block size重建数据库的方法来解决它。
  
  例如：当前你的数据库的数据块的大小为4K，但是你的行的平均长度为6k，那么你可以通过用8k大小的数据块来重建数据库的办法解决行链接现象。
        
o 行迁移主要是由于设置的PCTFREE参数过小，导致没有给update操作留下足够的空闲空间引起。为了避免行迁移，所有被修改的表应该设置合适的PCTFREE 值，以便在每个数据块内为数据修改保留足够的空间。可以通过增加PCTFREE值的办法来避免行迁移，但这种解决办法是以牺牲更多的空间为代价的，这也就是我们通常所说的以空间换效率。而且通过增加PCTFREE值的办法只能缓解行迁移现象，而不能完全解决行迁移，所以较好的办法是在设置了合适的PCTFREE值的后，在发现行迁移现象比较严重时，对表的数据进行重组。
   下面是对行迁移数据进行重组的步骤(这种方法也被成为CTAS):
  -- Get the name of the table with migrated rows:
  ACCEPT table_name PROMPT 'Enter the name of the table with migrated rows: '
  
  -- Clean up from last execution
  set echo off
  DROP TABLE migrated_rows;
  DROP TABLE chained_rows;
  
  -- Create the CHAINED_ROWS table
  @.../rdbms/admin/utlchain.sql
  set echo on
  spool fix_mig
  -- List the chained and migrated rows
  ANALYZE TABLE &table_name LIST CHAINED ROWS;
  
  -- Copy the chained/migrated rows to another table
  create table migrated_rows as
    SELECT orig.* 
    FROM &table_name orig, chained_rows cr
    WHERE orig.rowid = cr.head_rowid
      AND cr.table_name = upper('&table_name');
     
  -- Delete the chained/migrated rows from the original table
  DELETE FROM &table_name WHERE rowid IN (SELECT head_rowid FROM chained_rows);
  
  -- Copy the chained/migrated rows back into the original table
  INSERT INTO &table_name SELECT * FROM migrated_rows;
  
  spool off
  
当对一个表进行全表扫描时，我们实际上忽略行迁移中各个指向其它行的指针，因为我们知道，全表扫描会遍历全表，最终会读到发生行迁移的行的行数据，在此时才会处理这些行数据。因此，在全表扫描中，行迁移不会引发其它额外的工作。
当通过索引读一个表的数据时，被迁移的行会引起额外的I/O操作。这是因为从索引中我们会读到数据行的rowid，它告诉数据库到指定文件的指定数据块的指定slot上可以找到需要的数据，但是因为发生了行迁移，此处只存放一个指向数据的指针，而不是真正的数据，所以数据库又需要根据该指针(类似rowid)到指定文件的指定数据块的指定slot上去找真正的数据，重复上面的过程，直到找到真正的数据。我们可以看出，这会引入额外的I/O操作。



摘自itpub的回帖

楼主，chenmolin对行链接和与行迁移的解释是对的，你从网上读到的文章可能有笔误。
（但文章中的：这些剩余的空间我们将其称之为空洞，这就是产生表碎片的主要原因，
我不赞同）。

另外，对于行连接，可以创建更大的BLOCK来容纳（9I以上）。
对于行迁移，可以备份数据后，删除再插入来解决。