Oracle数据表默认值列添加与行迁移(Row Migration)
在笔者之前的文章中,已经探讨过给一个数据表添加有默认值列是一项非常“危险”的事情,特别是在在线生产环境下。给一张大数据表添加有默认值列,最直接的有下面几个严重危害:
系统高负荷运行,消耗大量资源。添加列操作是一次性的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
下面,我们来证明发生了行链接情况。
系统高负荷运行,消耗大量资源。添加列操作是一次性的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
下面,我们来证明发生了行链接情况。
相关推荐
FellowYourHeart 2020-10-05
bianxq 2020-06-28
景泽元的编程 2020-06-21
韩学敏 2020-06-17
wuhen 2020-06-14
morexyoung 2020-06-13
lanmantech 2020-06-07
敏敏张 2020-06-06
勇往直前 2020-06-01
msmysql 2020-05-29
Noseparte 2020-05-28
zhangxiaojiakele 2020-05-25
CSDN0BLOG 2020-05-16
IBMRational 2020-05-14
Zhangdragonfly 2020-05-14
gamestart0 2020-04-10
仁鱼 2020-05-10
lijiawnen 2020-05-01
dayi 2020-04-29