数据准备
--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),这里具体不做演示了