众所周知，随着不断地进行表记录的DML操作，会不断提高表的高水位线（HWM）。DELETE操作之后尽管表的数据删除了。可是并没有降低表的高水位，除非你使用TRUNCATE操作，进行表查询的时候。Oracle会扫表高水位下面的数据块，也就是说，扫描的时间并不会有所降低。
所以DELETE删除数据以后并不会提高表的查询效率。
下面通过这个样例。用来解决高水位引起的查询变慢问题：
--样例中測试表占用表空间大小为：128M
SQL> SELECT a.bytes/1024/1024 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517';
A.BYTES/1024/1024||'M'
-----------------------------------------
128M
--查询一条记录成本为：4357。一致性读为：15730 耗时 0.53 秒
SQL> set autotrace on
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;
1
----------
1
运行计划
----------------------------------------------------------
Plan hash value: 854298875
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 175 | 2275 | 4357 (2)| 00:00:53 |
|* 1 | TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 | 175 | 2275 | 4357 (2)| 00:00:53 |
------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("A"."OBJ_ID"=17202000000001)
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
15730 consistent gets
0 physical reads
0 redo size
520 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--如今删除大部分数据。仅仅剩下一条測试数据：
SQL> DELETE FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id <> 17202000000001;
已删除1172857行。
--查询该段占用的表空间仍然为128M
SQL> set autotrace off
SQL> SELECT a.bytes/1024/1024 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517';
A.BYTES/1024/1024||'M'
-----------------------------------------
128M
SQL> COMMIT;
提交完毕。
SQL> SELECT a.bytes/1024/1024 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517';
A.BYTES/1024/1024||'M'
-----------------------------------------
128M
--查询一条记录消耗的成本为：4316，一致性读为：15730 耗时 0.52 秒
SQL> set autotrace on
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;
1
----------
1
运行计划
----------------------------------------------------------
Plan hash value: 854298875
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 4316 (1)| 00:00:52 |
|* 1 | TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 | 1 | 13 | 4316 (1)| 00:00:52 |
------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("A"."OBJ_ID"=17202000000001)
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
15730 consistent gets
0 physical reads
0 redo size
520 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--普通情况下，表的rowid是不会变的，我们通过ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT;来打开行迁移
SQL> ALTER TABLE TC_RES_PHY_EQP_PRO_MID_517 ENABLE ROW MOVEMENT;
表已更改。
--整理碎片并回收空间
--此操作相比于ALTER TABLE MOVE：
--1.不会消耗很多其它的表空间
--2.能够在线运行。不会使索引失效
--3.能够使用參数CASCADE，同一时候收缩表上的索引
--4.ALTER TABLE MOVE之后表空间的位置肯定会发生变化，而SHRINK表空间的位置没有发生变化
SQL> ALTER TABLE TC_RES_PHY_EQP_PRO_MID_517 SHRINK SPACE;
表已更改。
--查询一条记录消耗的成本为：2，一致性读为：4 耗时 0.01 秒
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;
1
----------
1
运行计划
----------------------------------------------------------
Plan hash value: 854298875
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 | 1 | 13 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("A"."OBJ_ID"=17202000000001)
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
520 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--此时占用表空间仅仅有4M
SQL> SELECT a.bytes/1024/1024 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517'; A.BYTES/1024/1024||'M' ----------------------------------------- 4M
当然ENABLE ROW MOVEMENT对系统性能也有影响，在TOM的博客中找到这个关于ROW MOVEMENT的问答：
You Asked
Hi Tom
I have seen your posting on ENABLE ROW MOVEMENT which is available in 10g. It looks a
very nice option since we can relocate and reorganize the heap tables without any outage
since it does not invalidate indexes. But is there any performance hit or any other
disadvantages for using this. I would like to use this in our new application.
Rgds
Anil
and we said...
Well, the tables have to be in an ASSM (Automatic Segment Space Managment) tablespace for
this to work (so if they are not, you have to move them there first in order to do this
over time).
It will necessarily consume processing resources on your machine while running (it will
read the table, it will delete/insert the rows at the bottom of the table to move them
up, it will generate redo, it will generate undo).
I would suggest benchmarking -- collect performance metrics about the table before and
after performing the operation. You would expect full scans to operate more efficiently
after, you would expect index range scans to either be unchanged or "better" as you have
more rows per block packed together (less data spread). You would be looking for that to
happen -- statspack or the tools available in dbconsole would be useful for measuring
that (the amount of work performed by your queries over time)
也就是说。ENABLE ROW MOVEMENT也会有副作用，由于表打开行迁移之后，假设对数据进行UPDATE操作，那么系统会对数据进行DELETE操作
之后再进行INSERT操作。导致产生很多其它的redo和undo。而且rowid也会发生变化。
附行迁移和行连接的解释：
row chain：When a row is too large to fit into any block, row chaining occurs. In this case, the Oracle devide the row into smaller chunks. each chunk is stored in a block along
with the necessary poiters to retrive and assemble the entire row.
row migration：when a row is to be updated and it cannot find the necessary free space in its block, the Oracle will move the entire row into a new block and leave a pointer from the orginal block to the new location. This process is called row migration.