ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转] Row Movement对系统的影响

[转] Row Movement对系统的影响

原创 Linux操作系统 作者:it_wangych 时间:2009-10-06 15:30:19 0 删除 编辑
ROW MOVEMENT特性最初是在8i时引入的,其目的是提高分区表的灵活性——允许更新Partition Key。这一特性默认是关闭,只是在使用到一些特殊功能时会要求打开。除了之前提到的更新Partition Key,还有2个要求打开的ROW MOVEMENT的功能就是flushback table和Shrink Segment。所以,只有当使用到以上3个功能特性时,ROW MOVEMENT才会真正起作用。我们如果需要知道ROW MOVEMENT会对系统产生什么影响,就只要看这3个功能使用时会产生什么影响。

  Flashback Table

   先看Flashback Table。这一功能能帮助我们及时回滚一些误操作,防止数据意外丢失。在使用该功能之前,必须先打开ROW MOVEMENT,否则就会抛ORA-08189错误。我们看以下例子,可以说明在使用Flashback Table功能时,ROW MOVEMENT产生了什么作用:

  SQL代码 

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->SQL> create table test_move as select * from dba_users;

  
Table created.

  SQL
> select username, rowid from test_move;

  USERNAME ROWID

  
------------------------------ ------------------

  DMP AAAwSfAAFAAAVlMAAA

  MYTBC AAAwSfAAFAAAVlMAAB

  CS2 AAAwSfAAFAAAVlMAAC

  TBC AAAwSfAAFAAAVlMAAD

  WOW AAAwSfAAFAAAVlMAAE

  REPO AAAwSfAAFAAAVlMAAF

  ... ...

  SYSTEM AAAwSfAAFAAAVlMAAk

  OUTLN AAAwSfAAFAAAVlMAAl

  
38 rows selected.

  SQL
> delete from test_move where username = 'MYTBC';

  
1 row deleted.

  SQL
> commit;

  
Commit complete.

  SQL
> flashback table test_move to timestamp(systimestamp - interval '3' minute);

  flashback
table test_move to timestamp(systimestamp - interval '3' minute)

  
*

  ERROR at line
1:

  ORA
-08189: cannot flashback the table because row movement is not enabled

  此时,由于ROW MOVEMENT还未打开,命令出错。继续完成演示:

  SQL代码  

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->SQL> alter table test_move enable row movement;

  
Table altered.

  SQL
> flashback table test_move to timestamp(systimestamp - interval '3' minute);

  Flashback complete.

  SQL
> select username, rowid from test_move;

  USERNAME ROWID

  
------------------------------ ------------------

  DMP AAAwSfAAFAAAVlMAAB

  MYTBC AAAwSfAAFAAAVlMAAm

  CS2 AAAwSfAAFAAAVlMAAn

  TBC AAAwSfAAFAAAVlMAAo

  WOW AAAwSfAAFAAAVlMAAp

  REPO AAAwSfAAFAAAVlMAAq

  ... ...

  SYSTEM AAAwSfAAFAAAVlMABJ

  OUTLN AAAwSfAAFAAAVlMABK

  
38 rows selected.

   当开启ROW MOVEMENT后,表被顺利的flashback了,数据被找回。此时,再比较flashback前后记录的ROWID,大多数记录的物理位置都变化。 这个过程的内部操作, 可以通过对Flashback Table做SQL Trace来进一步观察。通过Trace,我们不难发现,Flashback Table实际是通过Flashback Query将表中数据进行了一次删除、插入操作,因此ROWID会发生变化。


Shrink Segment

  Shrink Segment能帮助我们压缩数据段、整理数据碎片、降低高水位,以提高性能、节省空间。它也同样要求开启ROW MOVEMENT。

  SQL代码

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->SQL> select username, rowid from test_move;

  USERNAME ROWID

  
------------------------------ ------------------

  DMP AAAwShAAFAAAVlQAAA

  MYTBC AAAwShAAFAAAVlQAAB

  CS2 AAAwShAAFAAAVlQAAC

  TBC AAAwShAAFAAAVlQAAD

  WOW AAAwShAAFAAAVlQAAE

  REPO AAAwShAAFAAAVlQAAF

  ... ...

  SYSTEM AAAwShAAFAAAVlQAAk

  OUTLN AAAwShAAFAAAVlQAAl

  
38 rows selected.

  SQL
> delete from test_move where username = 'MYTBC';

  
1 row deleted.

  SQL
> commit;

  
Commit complete.

  SQL
> alter table test_move disable row movement;

  
Table altered.

  SQL
> alter table test_move shrink space;

  
alter table test_move shrink space

  
*

  ERROR at line
1:

  ORA
-10636: ROW MOVEMENT is not enabled

  SQL
> alter table test_move enable row movement;

  
Table altered.

  SQL
> alter table test_move shrink space;

  
Table altered.

  SQL
> select username, rowid from test_move;

  USERNAME ROWID

  
------------------------------ ------------------

  DMP AAAwShAAFAAAVlMAAA

  CS2 AAAwShAAFAAAVlMAAB

  TBC AAAwShAAFAAAVlMAAC

  WOW AAAwShAAFAAAVlMAAD

  REPO AAAwShAAFAAAVlMAAE

  ... ...

  SYSTEM AAAwShAAFAAAVlMAAj

  OUTLN AAAwShAAFAAAVlMAAk

  
37 rows selected.

  SQL
>

  同样,我们可以看到在Shrink后,ROWID也变化了。从对其过程的Trace来看,Shrink对数据的改变不是通过SQL实现的,而是通过更底层的函数来实现的。

   从以上分析来看,在执行上面2种操作操作后,其最大影响就是数据的ROWID会发生变化。因此,他们对我们系统的影响就仅限于那些依赖于ROWID编写 的应用。例如,一个程序需要对大量数据进行处理,为了提高效率和控制进度,我们的代码会先将需要处理的数据记录的ROWID取出放入临时表中,然后再根据 ROWID对数据进行分批进行处理。当ROWID被取出后,如果对表进行了上述操作,就可能会导致后依赖ROWID进行的操作发生错误。但是,这两种操作 都属于维护性操作,第一种操作发生的机会非常少,从整体看,我们基本可以忽视这一操作对应用的影响;第二种操作也很少发生,并且可以在应用offline 的时间进行操作,因此它的影响也是有限的。

  更新Partition Key

  在更新记录中的Partition Key时,可能会导致该记录超出当前所在分区的范围,需要将其转移到其他对应分区上,因此要求开启ROW MOVEMENT。

  SQL代码

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->SQL> drop table test_move;

  
Table dropped.

  SQL
> create table test_move

  
2 partition by list (owner)

  
3 (partition p1 values ('SYS'),

  
4 partition p2 values ('DEMO'),

  
5 partition p3 values ('SYSTEM'),

  
6 partition def values (default))

  
7 as select * from dba_tables;

  
Table created.

  SQL
> update test_move set owner='SYS' where owner='DEMO' and table_name='T_TEST';

  
update test_move set owner='SYS' where owner='DEMO' and table_name='T_TEST'

  
*

  ERROR at line
1:

  ORA
-14402: updating partition key column would cause a partition change

  SQL
> alter table test_move enable row movement;

  
Table altered.

  SQL
> update test_move set owner='SYS' where owner='DEMO' and table_name='T_TEST';

  
1 row updated.

  这一操作产生影响的特殊之处在于这是个DML操作,是和online transaction密切相关。对于这样一个UPDATE,实际上分为3步:先从原有分区将数据删除;将原数据转移到新分区上;更新数据。其影响就在于以下几个方面:

  一个UPDATE被分解为DELET、INSERT、UPDATE三个操作,增加了性能负担。其中,DELETE的查询条件与原UPDATE的查询条件相同,新的UPDATE的查询条件是基于INSERT生成的新的ROWID;

  相应的Redo Log、Undo Log会增加;

  如果Update语句还涉及到了Local Index的字段的话,新、旧2个分区上的Local Index都要被更新。

  结论

   目前,ROW Movement真正会其作用(ROWID变化)只是在上述3种情况下,因此,需要分析其对系统会产生多大影响,就要分析上述三种操作在你的系统中出现的 频率、以及是否有应用程序依赖与ROWID实现。对于前面两种,之前说过,它们发生的概率并不高,我个人认为基本上可以忽略它们对系统的影响。而对于最后 一种,需要从应用角度进行分析——Partition Key被更新的频率有多高?如果可能,最好实施一次等量负载下更细Partition Key的压力测试,通过对比分区和非分区下其产生的性能统计数据做比较,其带来的性能负载及Waits量与分区所获取的查询性能的提高相比,哪一种方式更 有助于系统和应用的性能提高。

  此外,有一点希望不要产生误解,开启ROW Movement并不会导致发生Row Migration时修改记录的Rowid。

  还有一点,Row Movement会和域索引(Domain Index)产生冲突:如果表上定义了域索引,开启Row Movement就会失败;反之亦然。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22021749/viewspace-616034/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-07-06

  • 博文量
    43
  • 访问量
    80364