oracle高水位线,终于知道DELETE和TRUNCATE为什么不一样了

本文详细解释了Oracle数据库中的高水位线(HWM)概念及其对查询性能的影响,并介绍了几种降低HWM的方法,包括使用TRUNCATE语句、ALTER TABLE MOVE等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载:http://blog.youkuaiyun.com/houdi2108/article/details/23916897

一、Oracle表段中的高水位线HWM
在Oracle数据的存储中,可以把存储空间想象为一个水库,数据想象为水库中的水。水库中的水的位置有一条线叫做水位线,在Oracle中,这条线被称为高水位线(High-warter mark, HWM)。在数据库表刚建立的时候,由于没有任何数据,所以这个时候水位线是空的,也就是说HWM为最低值。当插入了数据以后,高水位线就会上涨,但是这里也有一个特性,就是如果你采用delete语句删除数据的话,数据虽然被删除了,但是高水位线却没有降低,还是你刚才删除数据以前那么高的水位。也就是说,这条高水位线在日常的增删操作中只会上涨,不会下跌。
               
下面我们来谈一下Oracle中Select语句的特性。Select语句会对表中的数据进行一次扫描,但是究竟扫描多少数据存储块呢,这个并不是说数据库中有多少数据,Oracle就扫描这么大的数据块,而是Oracle会扫描高水位线以下的数据块。现在来想象一下,如果刚才是一张刚刚建立的空表,你进行了一次Select操作,那么由于高水位线HWM在最低的0位置上,所以没有数据块需要被扫描,扫描时间会极短。而如果这个时候你首先插入了一千万条数据,然后再用delete语句删除这一千万条数据。由于插入了一千万条数据,所以这个时候的高水位线就在一千万条数据这里。后来删除这一千万条数据的时候,由于delete语句不影响高水位线,所以高水位线依然在一千万条数据这里。这个时候再一次用select语句进行扫描,虽然这个时候表中没有数据,但是由于扫描是按照高水位线来的,所以需要把一千万条数据的存储空间都要扫描一次,也就是说这次扫描所需要的时间和扫描一千万条数据所需要的时间是一样多的。所以有时候有人总是经常说,怎么我的表中没有几条数据,但是还是这么慢呢,这个时候其实奥秘就是这里的高水位线了。
                 
那有没有办法让高水位线下降呢,其实有一种比较简单的方法,那就是采用TRUNCATE语句进行删除数据。采用TRUNCATE语句删除一个表的数据的时候,类似于重新建立了表,不仅把数据都删除了,还把HWM给清空恢复为0。所以如果需要把表清空,在有可能利用TRUNCATE语句来删除数据的时候就利用TRUNCATE语句来删除表,特别是那种数据量有可能很大的临时存储表。
              
在手动段空间管理(Manual Segment Space Management)中,段中只有一个HWM,但是在Oracle9iRelease1才添加的自动段空间管理(Automatic Segment Space Management)中,又有了一个低HWM的概念出来。为什么有了HWM还又有一个低HWM呢,这个是因为自动段空间管理的特性造成的。在手段段空间管理中,当数据插入以后,如果是插入到新的数据块中,数据块就会被自动格式化等待数据访问。而在自动段空间管理中,数据插入到新的数据块以后,数据块并没有被格式化,而是在第一次在第一次访问这个数据块的时候才格式化这个块。所以我们又需要一条水位线,用来标示已经被格式化的块。这条水位线就叫做低HWM。一般来说,低HWM肯定是低于等于HWM的。
                  
二、修正ORACLE表的高水位线
在ORACLE中,执行对表的删除操作不会降低该表的高水位线。而全表扫描将始终读取一个段(extent)中所有低于高水位线标记的块。如果在执行删除操作后不降低高水位线标记,则将导致查询语句的性能低下。下面的方法都可以降低高水位线标记。
1.执行表重建指令 alter table table_name move;
(在线转移表空间ALTER TABLE 。。。 MOVE TABLESPACE 。。。ALTER TABLE 。。。 MOVE 后面不跟参数也行,不跟参数表还是在原来的表空间,move后记住重建索引。如果以后还要继续向这个表增加数据,没有必要move,只是释放出来的空间,只能这个表用,其他的表或者segment无法使用该空间)
执行alter table table_name shrink space; 注意,此命令为Oracle 10g新增功能,再执行该指令之前必须允许行移动alter table table_name enable row movement;
 实质上构造一个新表(在内部表现为一系列的DML操作,即将副本插入新位置,删除原来位置的记录)靠近末尾处(右端)数据块中的记录往开始处(左端)的空闲空间处移动(DML操作),不会引起DML触发器
当所有可能的移动被完成,高水位线将会往左端移动(DDL操作)
新的高水位线右边的空闲空间被释放(DDL操作)
        
实现前提条件
必须启用行记录转移(enable row movement)
仅仅适用于堆表,且位于自动段空间管理的表空间(堆表包括:标准表,分区表,物化视图容器,物化视图日志表)

3.复制要保留的数据到临时表t,drop原表,然后rename临时表t为原表
4.emp/imp
5.alter   table  table_name  deallocate   unused  
6.尽量truncate吧

-----------高水位线实验---------------------------------------
create table HWM as select * from dba_objects;

SQL> SELECT segment_name, segment_type, blocks FROM dba_segments
     WHERE segment_name='HWM';    
     DBA_SEGMENTS.BLOCKS 表示分配给这个表的所有的数据库块的数目

SQL> ANALYZE TABLE hwm ESTIMATE STATISTICS;          

SQL> SELECT table_name,num_rows,blocks,empty_blocks
     FROM user_tables
     WHERE table_name='HWM';
     USER_TABLES.BLOCKS表示已经使用过的数据库块的数目,即水线。
     USER_TABLES.EMPTY_BLOCKS 代表分配给该表,但是在水线以上的数据库块,即从来没有使用的数据块。

SQL> SELECT COUNT (DISTINCT
     DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)||
     DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) "Used"
     FROM hwm;
     有多少块容纳数据

SQL> delete from hwm;         
SQL> commit;
SQL> ANALYZE TABLE hwm ESTIMATE STATISTICS; 
SQL> SELECT table_name,num_rows,blocks,empty_blocks
     FROM user_tables
     WHERE table_name='HWM';

SQL> TRUNCATE TABLE hwm;  
SQL> ANALYZE TABLE hwm ESTIMATE STATISTICS;                  
SQL> SELECT table_name,num_rows,blocks,empty_blocks
     FROM user_tables
     WHERE table_name='HWM';

结论:使用delete不能使高水位线降低,使用truncate可以使用高水位线降低,
      所以当删除整表数据或者分区最好是用truncate,
      当用delete删除大表数据时后,还是要重建表,这样可以降低高水位线

<think>嗯,用户询问的是Oracle数据库中DELETE操作是否会释放水位线的问题。这个问题涉及到Oracle存储管理的核心机制,需要从技术原理层面解释清楚。 用户可能是个DBA或者开发人员,遇到了表空间持续增长但实际数据量大的矛盾现象。从引用内容看,ta应该已经注意到DELETE后查询性能没有提升这个典型症状,但确定根本原因。需要帮ta理清HWM的运作机制。 先确认核心结论:DELETE降低HWM。这个结论在引用[1]里说得非常明确:"删除数据以后,水位线却没有降低"。引用[3]提到的shrink功能正好佐证了常规DELETE的局限性——需要额外操作才能回收空间。 接下来要解释为什么Oracle这样设计。主要是性能考量:频繁调整HWM会导致存储结构稳定,影响I/O效率。就像引用[1]说的,HWM"在日常增删操作中只会上涨,会下跌",这是Oracle的主动设计选择。 用户可能隐含的深层需求是如何真正释放空间。需要给出解决方案:truncate会重置HWM但丢失所有数据;move重组表需要停机;shrink是10g后的在线方案但锁表。引用[3]提到的shrink table正是针对这个痛点的功能。 还要提醒注意事项。比如引用[2]提到的实验很重要——实际测试才能确认效果。另外move/shrink会重建索引,这个衍生成本容易被忽略。 最后考虑生成相关问题。用户既然问HWM,可能后续会关心空间回收对性能的实际影响,或者如何监控HWM状态。补充分区表这个点是因为分区能局部重置HWM,是现代数据库设计的常用优化手段。</think>在Oracle数据库中,**DELETE操作会释放水位线(High Water Mark, HWM)**。这是Oracle存储机制的核心设计之一,具体原理如下: ### 关键结论与原理 1. **DELETE仅逻辑删除** `DELETE`操作仅标记行为"已删除",实际数据块仍被HWM包含。表的水位线记录**该表历史上占用过的最大数据块位置**,删除数据会重置此标记[^1][^3]。 2. **HWM对性能的影响** 全表扫描时,Oracle会读取HWM以下所有数据块(包括空块)。即使删除大量数据,若HWM未降低,查询仍需扫描相同数量的数据块,导致性能无改善[^1][^2]。 *示例:* 若表初始占用1000个块,删除999,000行后仅剩1000行,全表扫描仍读取1000个块。 3. **释放HWM的解决方案** | 方法 | 操作机制 | 优缺点 | |---------------|----------------------------|-------------------------------| | `TRUNCATE TABLE` | 直接重置HWM到初始状态 | ⚠️ 删除全表数据,可回滚 | | `ALTER TABLE ... MOVE` | 重组表数据并重置HWM | ✅ 保留数据;🔧需重建索引/授权 | | `ALTER TABLE ... SHRINK SPACE` (10g+) | 在线压缩数据并降低HWM | ✅ 最小化锁;🔧需开启行移动(`ALTER TABLE ... ENABLE ROW MOVEMENT`)[^3] | ### 实验验证(引用[2]实验) 1. 创建测试表并插入大量数据 2. `DELETE` 90%数据后,查询`DBA_SEGMENTS`视图 ```sql SELECT blocks, empty_blocks FROM dba_segments WHERE segment_name = 'TEST_TABLE'; ``` **结果:** `blocks`(HWM下总块数)**变**,`empty_blocks`(完全空块)增加 3. 执行`SHRINK SPACE`后,`blocks`值显著下降 ### 运维建议 - **频繁删除场景:** 定期使用`SHRINK SPACE`或`MOVE`重组表,避免空间浪费与性能下降 - **分区表优化:** 对分区表执行`TRUNCATE PARTITION`可直接重置分区HWM - **监控HWM:** ```sql SELECT table_name, blocks "HWM块数", empty_blocks "空块数", num_rows "实际行数" FROM dba_tables WHERE table_name = 'YOUR_TABLE'; ``` > **根本原因**:Oracle的HWM设计优先考虑**存储稳定性与写入效率**。降低HWM需要重组数据块,属于成本操作,因此随`DELETE`自动触发[^1][^3]。 --- ### 相关问题 1. **如何监控Oracle数据库中表的水位线变化?** 2. **`SHRINK SPACE`操作对数据库在线业务会产生哪些影响?如何规避风险?** 3. **除了HWM问题,Oracle表碎片化还会导致哪些性能瓶颈?** 4. **分区表相对于普通表在管理HWM方面有何优势?** [^1]: Oracle delete操作后水位线维持原理 [^2]: 水位线变更的实验验证方法 [^3]: Shrink Table技术的工作机制与版本限制
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值