从探究达梦8数据库的高水位实验开始~

数据准备

--drop table sales_1 purge;

CREATE TABLE sales_1( 
uu_id varCHAR(36),
city varCHAR(10),
da date,
row_n number
);

insert into sales_1 
select sys_guid(),'北京' ,sysdate,rownum from dual connect by level <= 500000;
commit;

select SUM(A.BYTES)/1014/1024 sum_byte,sysdate from DBA_SEGMENTS a where a.SEGMENT_NAME='SALES_1' ;
DELETE FROM sales_1;
COMMIT;
select SUM(A.BYTES)/1014/1024 sum_byte,sysdate from DBA_SEGMENTS a where a.SEGMENT_NAME='SALES_1' ;

以下是前期测试数据准备

观察上图的1和2可以发现，在使用delete的方式删除数据以后，其大小都是35M，因此初步结论为达梦8存在表的高水位问题；但是再观察3，会发现数据大小会减少到1M了，仿佛高水位问题会得以自动解决和降低【备注，因为是本地虚拟机测试，因此可以确定2和3之间绝对没有其他会话操作这个表】。

再仔细观察三个地方的时间点会发现，1和2仅仅相差了大约30秒，而2和3相差了近6分钟。也就是说再在DML一个时间段内，达梦8也会存在表的高水位一说，但是超过某个时间段后，数据库会自动降低表的高水位（功效类似于Oracle的alter table table_name move;）

至于这个时间段有多久，咨询达梦老司机后得知，其实是取决于数据库参数文件中的dm.ini中的参数UNDO_RETENTION的大小；

 

最后的解释一目了然，而官方文档中给出的中文解释是：

我自己的理解就是说：

当计算DBA_SEGMENTS时，其实至少包括两部分1.磁盘上实际数据表空间（例如main表空间）中的实际占用，2.undo表空间的占用（当然这个数据在回滚表空间中的保留时长是收到UNDO_RETENTION的影响）。

在超过UNDO_RETENTION的时长以后，去查UNDO的占用情况已经查不到了。因此90秒后，只能找到其在物理表空间（默认main空间）文件的大小，因此就发现“高水位降低了”。

由此可以推论，此参数会影响到闪回查询，数据库的快照查询应该只能查到90秒之内的数据（因为UNDO_RETENTION大小为90），这里具体不做演示了