博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
INITIAL参数设置导致TRUNCATE TABLE不能降低高水位线案例
阅读量:5048 次
发布时间:2019-06-12

本文共 2912 字,大约阅读时间需要 9 分钟。

在一个数据库使用下面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.

当时傻眼了,难道我搞错了, 难道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掉这个表,然后修改该参数重新创建该表。

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

转载于:https://www.cnblogs.com/kerrycode/p/4432592.html

你可能感兴趣的文章
第四天 selenium的安装及使用
查看>>
关于js的设计模式(简单工厂模式,构造函数模式,原型模式,混合模式,动态模式)...
查看>>
KMPnext数组循环节理解 HDU1358
查看>>
android调试debug快捷键
查看>>
【读书笔记】《HTTP权威指南》:Web Hosting
查看>>
Inoodb 存储引擎
查看>>
数据结构之查找算法总结笔记
查看>>
Linux内核OOM机制的详细分析
查看>>
Android TextView加上阴影效果
查看>>
Requests库的基本使用
查看>>
C#:System.Array简单使用
查看>>
「Foundation」集合
查看>>
二叉树的遍历 - 数据结构和算法46
查看>>
类模板 - C++快速入门45
查看>>
RijndaelManaged 加密
查看>>
Android 音量调节
查看>>
windows上面链接使用linux上面的docker daemon
查看>>
Redis事务
查看>>
Web框架和Django基础
查看>>
python中的逻辑操作符
查看>>