INITIAL参数设置导致TRUNCATE TABLE不能降低高水位线案例

简介:

在一个数据库使用下面SQL找出了一批需要降低高水位线的表,其中有几个表没有数据,于是我打算用TRUNCATE来降低高水位线HWM

SELECT a.owner, 
       a.segment_name, 
       a.segment_type, 
       a.tablespace_name, 
       a.blocks              "real block", 
       a.bytes / 1024 / 1024 "realSizeMB", 
       b.last_analyzed, 
       b.num_rows 
FROM   dba_segments a, 
       dba_tables b 
WHERE  a.owner = b.owner 
       AND a.segment_name = b.table_name 
       AND B.partitioned = 'NO' 
       AND b.num_rows < 5000 
       AND a.blocks > 1000 
       AND a.bytes / 1024 / 1024 > 500 
ORDER  BY 6 DESC 

我们先看看其中一个表的空间使用情况,如下所示,结果我对该表执行了TRUNCATE后,发现高水位线HWM根本没有变化

SQL> exec show_space('INV_MONTH_END_LOCATION', 'INVENTORY');
Unformatted Blocks .....................               0
FS1 Blocks (0-25)  .....................               0
FS2 Blocks (25-50) .....................               0
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................               0
Total Blocks............................         434,176
Total Bytes.............................   3,556,769,792
Total MBytes............................           3,392
Unused Blocks...........................         434,142
Unused Bytes............................   3,556,491,264
Last Used Ext FileId....................              40
Last Used Ext BlockId...................               9
Last Used Block.........................              34
 
PL/SQL procedure successfully completed.
 
SQL> exec show_space('INV_MONTH_END_LOCATION', 'INVENTORY');
Unformatted Blocks .....................               0
FS1 Blocks (0-25)  .....................               0
FS2 Blocks (25-50) .....................               0
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................               0
Total Blocks............................         434,176
Total Bytes.............................   3,556,769,792
Total MBytes............................           3,392
Unused Blocks...........................         434,142
Unused Bytes............................   3,556,491,264
Last Used Ext FileId....................              40
Last Used Ext BlockId...................               9
Last Used Block.........................              34
 
PL/SQL procedure successfully completed.

clip_image001

当时傻眼了,难道我搞错了, 难道TRUNCATE不会释放存储空间,降低高水位线?于是查了一下资料,确认TRUNCATE会释放存储空间,降低高水位线。那么问题出在哪里呢?于是我对该表重新收集了一下统计信息后发现依然如此

SQL> exec dbms_stats.gather_table_stats('INVENTORY','INV_MONTH_END_LOCATION', cascade=>true);
 
PL/SQL procedure successfully completed.

最后我生成了创建该表的SQL语句,终于发现了问题。如下截图所示。 initial与next决定创建segment及扩展segment,initial表示初始化时分配给该表的段大小为 3,556,769,792Byte。也就是3392MB。但是已经不知道当时谁建表示设定了这个参数,于是只能DROP掉这个表,然后修改该参数重新创 建该表。

clip_image002

clip_image003

另外,如果是这个情况下,使用ALTER MOVE也是不能释放表空间,降低高水位线的。切记切记。

相关文章
|
监控 Java 索引
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
|
API 索引
Elastic:索引生命周期ILM的warm,cold,delete节点中min_age设置的是增量还是累计值
结合以上分析,可以得到,我们需要在rollover的max_age设置5min,然后warm节点中因为是立即转移的,所以min_age是0min。要在warm节点待3min的话,就需要在cold节点设置min_age为3min。最后rollover6min后被删除,需要在delete节点设置min_age为6min。所以最终的答案是5 0 3 6
126 0
Elastic:索引生命周期ILM的warm,cold,delete节点中min_age设置的是增量还是累计值
|
关系型数据库 MySQL
ALTER TABLE 对 Null 值和默认值的影响
ALTER TABLE 对 Null 值和默认值的影响
244 0
|
SQL Oracle 关系型数据库
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
1284 0
|
关系型数据库 MySQL 数据库
innodb的统计信息对optimizer成本预估影响实例
mysql会依据innodb表的数据变化阈值来自动收集和计算表的统计信息(innodb_stats_auto_recalc)以供优化器使用,统计信息的收集是先通过获取一部分符合条件的索引页中的leaf page(是leaf page,不是non-leaf page)的数据,然后通过对这些采集的leaf page计算估计出不同值的数量,进而估算出的信息,信息采集的准确度除了和数据本身的构成有关,还与采集page数量有关,数量越多,采集精度越准确
innodb的统计信息对optimizer成本预估影响实例
|
SQL 关系型数据库 PostgreSQL
PostgreSQL Heap Only Tuple - HOT (降低UPDATE引入的索引写IO放大)
标签 PostgreSQL , Heap Only Tuple , HOT 背景 PostgreSQL目前默认的存储引擎在更新记录时,会在堆内产生一条新版本,旧版本在不需要使用后VACUUM回收,回收旧版本前,需要先回收所有关联这个版本的所有索引POINT。
2445 0
|
SQL MySQL 关系型数据库
MySQL Insert语句单个批次数量过多导致的CPU性能问题分析
原文:MySQL Insert语句单个批次数量过多导致的CPU性能问题分析 【问题】 最近有台服务器比较频繁的CPU报警,表现的特征有CPU sys占比偏高,大量慢查询,大量并发线程堆积。后面开发对insert的相关业务限流后,服务器性能恢复正常。
1738 0
|
SQL 存储 测试技术
SQL Server 统计信息更新时采样百分比对数据预估准确性的影响
原文:SQL Server 统计信息更新时采样百分比对数据预估准确性的影响    为什么要写统计信息   最近看到园子里有人写统计信息,楼主也来凑热闹。  话说经常做数据库的,尤其是做开发的或者优化的,统计信息造成的性能问题应该说是司空见惯。
941 0
|
数据库 SQL
查看数据库表的数据量和SIZE大小的脚本修正
原文:查看数据库表的数据量和SIZE大小的脚本修正 在使用桦仔的分享一个SQLSERVER脚本(计算数据库中各个表的数据量和每行记录所占用空间)的脚本时,遇到下面一些错误 这个是因为这些表的Schema是Maint,而不是默认的dbo,造成下面这段SQL在执行EXEC sp_spaceus...
809 0