Row Movement 对系统的影响
[English]
作者：
fuyuncat
来源：
www.HelloDBA.com
分享到
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代码
- 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代码
- 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代码
- 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代码
- 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就会失败；反之亦然。
--- The End ---