Oracle delete操作隐藏着你可能不知道的秘密

时间：2018-06-28 10:58:04 阅读：196 评论：0 收藏：0 [点我收藏+]

一现象描述

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的常用命令如下：

技术分享图片