在笔者之前的文章中，已经探讨过给一个数据表添加有默认值列是一项非常危险的事情，特别是在在线生产环境下。给一张大数据表添加有默认值列，最直接的有下面几个严重危害： 系统高负荷运行，消耗大量资源。添加列操作是一次性的ddl操作，生成大量的redo log记
在笔者之前的文章中，已经探讨过给一个数据表添加有默认值列是一项非常“危险”的事情，特别是在在线生产环境下。给一张大数据表添加有默认值列，最直接的有下面几个严重危害：
系统高负荷运行，消耗大量资源。添加列操作是一次性的ddl操作，生成大量的redo log记录；
长期数据表锁定，阻碍生产系统作业。添加数据列期间，对数据表添加独占锁，此时阻碍其他dml操作；
破坏原有存储结构，造成大量的行迁移（row migration）数据。在每个数据行尝试添加进默认值，进行膨胀的同时，由于rowid的特性，会引起严重的行链接情况，损害原有数据表存储结构；
本文主要想聊聊由于默认值添加带来的行链接（row migration）现象。
1、从row migration现象谈起
row migration本质上是一种由于oracle存储特性和数据行定位特性而发生的一种现象。在oracle中，所有的数据行都是保留在数据块单元上的。一个数据块可以容纳若干条数据（通常条件下）。一些数据列，如varchar2类型，大部分情况下都是根据输入数据的长度进行空间分配。
那么，如果数据行列填入了更大的数据，也就是空间发生了拓展。数据块存储上就会发生何种变化呢？每个数据块都会预留一部分的空闲空间，作为数据行变化预留位置。如果长度继续拓展，那么会发生什么呢？
oracle会尝试将这个数据行拷贝出，找个新的数据块进行存储。这样，就可以放下数据块。那么，一个新的问题出现了，就是rowid问题。
在oracle中，rowid是定位一条记录的物理地址。rowid包括数据文件相对编号、对象号、数据块号和slot行号。rowid普遍作为数据行的标记，保存在相关的索引叶子节点上。但是，当一个数据行被转移存储到另一个数据块，本质上物理存储位置已经发生变化。索引等对象中包括的rowid面临着失效的问题。
oracle解决这个问题是通过“虚拟门牌”的方法。这个数据行位置虽然已经到另外的地方，但是对应的rowid并没有发生变化。当我们检索数据，server process定位到原来的位置时，它会找到一个转换跳转地址，那里面记录着真正的rowid地址。这个就是发生了row migration。
row migration给系统性能带来了很多潜在的问题。比如，一行数据原来只需要寻找一个数据块记录，现在就需要寻找多个数据块才可以。这样就是带来的性能问题。
我们在进行默认值数据行添加的时候，就会带来row migration的爆发。
2、row migration与默认值列添加
下面我们通过实验，来证明row migration的出现。我们选择11gr2环境进行实验。
sql> select * from v$version;
banner
--------------------------------------------------------------------------------
oracle database 11g enterprise edition release 11.2.0.1.0 - production
pl/sql release 11.2.0.1.0 - production
core       11.2.0.1.0        production
sql> create table t as select object_id from dba_objects where 1=0;
table created
--添加若干条记录；
sql> insert into t select object_id from dba_objects where rownum
99 rows inserted
sql> commit;
commit complete
数据表t，在存储结构和空间分配上情况如下：
sql> exec dbms_stats.gather_table_stats(user,'t',cascade => true);
pl/sql procedure successfully completed
sql> select bytes, blocks,extents from user_segments where segment_name='t';
bytes    blocks   extents
---------- ---------- ----------
    65536         8         1
sql> select blocks from user_tables where table_name='t';
blocks
----------
        1
user_segment中记录着给数据段分配的总空间，但这并不代表全部的hwm位置。user_tables中的blocks，才代表hwm下数据块的个数。从上面的结果看，hwm下一共只有一个数据块。从rowid分析看，实际也的确如此。
sql> select dbms_rowid.rowid_block_number(rowid) blockno, count(*) from t group by dbms_rowid.rowid_block_number(rowid);
blockno  count(*)
---------- ----------
    85857        99
下面我们进行数据列添加。
sql> alter table t add vc varchar2(1000) default lpad('t',500,'t');
table altered
executed in 0.078 seconds
对应的空间使用情况如下：
sql> exec dbms_stats.gather_table_stats(user,'t',cascade => true);
pl/sql procedure successfully completed
executed in 0.141 seconds
sql> select blocks from user_tables where table_name='t';
blocks
----------
       12
executed in 0.016 seconds
sql> select bytes, blocks,extents from user_segments where segment_name='t';
bytes    blocks   extents
---------- ---------- ----------
   131072        16         2
sql> select dbms_rowid.rowid_block_number(rowid) blockno, count(*) from t group by dbms_rowid.rowid_block_number(rowid);
blockno  count(*)
---------- ----------
    85857        99
executed in 0.016 seconds
上面的情况可以看出，oracle的数据表t已经推高了水位线hwm到12个块，从空间分配也分配了新的extent使用。
但是，所有数据行rowid没有变化。所有数据行的“门牌号”都没有变化，但是存储呢？很诡异的增加了。正常容量下，数据块情况应该是如下：
sql> create table t_bak as select * from t;
table created
sql> exec dbms_stats.gather_table_stats(user,'t_bak',cascade => true);
pl/sql procedure successfully completed
sql> select bytes, blocks,extents from user_segments where segment_name='t_bak';
bytes    blocks   extents
---------- ---------- ----------
   131072        16         2
sql> select blocks from user_tables where table_name='t_bak';
blocks
----------
        8
sql> select dbms_rowid.rowid_block_number(rowid) blockno, count(*) from t_bak group by dbms_rowid.rowid_block_number(rowid);
blockno  count(*)
---------- ----------
    86589        14
    86588        14
    86585        14
    86586        14
    86591        14
    86590        14
    86587        14
    86592         1
8 rows selected
下面，我们来证明发生了行链接情况。
3、数据表行链接检验
analyze语句一度是非常流行的收集数据表统计量的操作方式。但是随着dbms_stats包的成熟推广，analyze在统计量收集方面的功能已经渐渐弱化。但是，oracle依然保留了这个语句的两个基本功能：对数据表进行行链接（row migration）检测和索引健康程度检测。
下面使用analyze语句进行数据表t的检测。首先我们需要创建分析结果的容纳数据表。
--调用oracle_home下的脚本；
sql>@?/rdbms/admin/utlchain.sql
table created.
sql> desc chained_rows;
name                                     null?   type
----------------------------------------- -------- ----------------------------
owner_name                                        varchar2(30)
table_name                                        varchar2(30)
cluster_name                                      varchar2(30)
partition_name                                    varchar2(30)
subpartition_name                                 varchar2(30)
head_rowid                                        rowid
analyze_timestamp                                 date
sql> create public synonym chained_rows for chained_rows;
synonym created.
sql> grant all on chained_rows to public;
grant succeeded.
分析数据表，如下：
--检验数据行row migration情况；
sql> analyze table t list chained rows into chained_rows;
table analyzed
executed in 0.125 seconds
--发生row migration次数；
sql> select count(*) from chained_rows;
count(*)
----------
       86
executed in 0.016 seconds
sql> select head_rowid from chained_rows where rownum
head_rowid
------------------
aaasucaabaaau9haan
aaasucaabaaau9haao
aaasucaabaaau9haap
aaasucaabaaau9haaq
executed in 0.016 seconds
sql> select * from t where rowid='aaasucaabaaau9haaq';
object_id vc
---------- --------------------------------------------------------------------------------
       38 tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
executed in 0.016 seconds
在99行记录中，发生了86次行链接row migration情况。
4、结论
解决oracle row migration的方法，就是进行数据表重构，重新对存储结构和rowid进行整理。我们说，在生产环境下，进行有默认值数据列的添加操作，会引起一系列的问题，要三思而行。