一 现象描述
Delete是oracle数据库中的常用操作，尤其是在自动化测试中，初始化环境、前置准备都不可避免的进行增删操作，但持续一时间后，可能会碰到表空间不足这类报错现象，这就不禁纳闷儿了，明明插入数据前会有删除的，数据总量并没有呈现明显的量级变化，为什么表占用空间却在偷偷增大呢？
二 现象分析
出现上述现象的原因是Delete操作并不会释放占用的空间。在讲解原因之前，先了解下oracle中高水位线的概念，有助于理解delete操作产生的这种现象。
所谓的高水位（HWM），通俗的讲就是一个标记，用来记录已经有多少数据块（Block）分配给表，可以拿水库的历史最高水位来类比，当使用delete操作后，数据虽然被删除了，但这个高水位的标记并没有降低，就好比水库的历史最高水位不会因为水被释放了而降低。因而，原则上在没有外部干预的条件下，这个高水位标记值只会增大，不会降低。
三 实战模拟重现现象
根据上面的现象描述和分析，接下来，我会用具体的实例模拟该现象，使大家可以更直观的了解。
第1，创建一张测试表test，具体字段不需要关心，只要知道初始了存储空间为100M，如图所示：
第2，创建完成后，我们查看下数据表占用的空间，如图所示：
其中，查询前需要对表进行分析，使用命令为：ANALYZE TABLE test ESTIMATE STATISTICS;查询语句为：SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = 'TEST';
注意上面三个字段的结果：BLOCKS=0; EMPTY_BLOCKS=13312; NUM_ROWS=0，即当前表占用的块数为0，默认1 BLOCK = 8kb，预分配的块为13312，行数为0。
一切都没有问题，新创建的表，没有数据嘛，当然行数为0，占用块数为0喽。
第3，写一个语句块，循环插入1000条语句，再次对test表进行分析、查询，结果如下：
从图中可以看到，占用BLOCKS=222，NUM_ROWS=1000，合乎逻辑，插入了1000条数据，占用了空间嘛。
第4，使用Delete语句删除1000条数据，再次对test表进行分析、查询，结果却是如下：
从上图中可以清楚的看到，数据被删除后，NUM_ROWS=0了，但是BLOCKS并没有被置为0，也就是这部分数据块仍然被认为是占用的。
因此，就出现了本文一开始就提到的现象，随着不断的插入、删除数据，BLOCKS也会不断扩大，尽快delete操作后，可能表中数据量很少，但表占用的存储空间未减少。
四 解决方法
针对delete操作引起的空间不释放现象，或者，更正式一点的说法，如何降低高水位线，方法有很多种，如，shrink space；move tablespace；create table xxx as select * from xxx 重建表等。使用这些方法前，我们的原则是：
如果可以truncate，直接truncate，该操作会重置高水位线，BLOCKS会被置为0，NUM_ROWS置为0；否则，优先使用shrink space，该方法不需要重建索引。
接着上面第4步，我们使用shrink space降低高水位线，释放空间，其中，使用shrink space命令前，需要先alter table test enable row movement;开启行移动，再次对表进行分析、查询，结果如下：
从图中可以看出，此时BLOCKS已经被置为0了，但是，细心的你可能也发现， EMPTY_BLOCKS已经不是初始的13312，而是此时的40，这说明shrink space不仅会释放高水位线以下的空间，也会释放申请的空间，即高水位线上下都有操作，这也是与move、truncate的不同，它们只能释放高水位线以下的空间。
五 shrink space常用操作命令
Shrink space的常用命令如下：
六 Delete操作的潜在影响
根据上述分析，delete操作产生的潜在影响如下：
1. 全表扫描通常要读出直到HWM标记的所有属于该表的数据块，即使该表中没有任何数据；（造成查询变慢）
2. 插入操作时使用append关键字，即使HWM以下有空闲的数据库块，插入时使用HWM以上的数据块；（造成HWM自动增大）
七 总结
通过上文的现象描述和分析，随着insert的不断操作，高水位线也随着不断增加，尽管delete了数据，但高水位线并没有下降，导致表占用的空间没有释放。因此，在实际应用中，如果可能，尽量使用truncate，而且该操作高效、快速；否则要考虑下delete操作遗留的影响，使用合适的方法整理空间。
