公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-12-12 23:48:36 · 原文链接

在之前自己的一个测试环境中，因为本身磁盘空间不足，导致一个测试库数据目录溢出，最后花了点功夫，将一个2G左右的文件经过收缩的操作后，竟然收缩为7M。详情可以参考 收缩关于收缩数据文件的尝试(r5笔记第34天)

    而隔了很长一段时间后，我在线上一个环境碰到了类似的问题。

这个数据库是一个OLAP的业务库，之前的数据量还不小，大概有1.7T,但是经过业务梳理之后，有一部分业务不需要的数据就删除了，后续迁移了另外一个环境的数据过来。

    从资源的规划来看，这个库的数据增长还远远达不到目前的使用量，所以也不用考虑太多的扩容需求，但是问题来了，现在的库已经被撑大了。想要收缩就难了。当前的问题其实挺严峻，下面的磁盘分区已经超过了报警阈值。

/dev/sdb              1.7T  1.5T  127G  92% /U01

但是从DB层面来看，所能做的工作似乎很少。因为尝试resize操作，只能收缩很小的空间。

这里就涉及一个数据文件的“高水位线”问题，大体来说，就是数据文件很大，但是里面的数据分布情况是不均匀的。很可能出现较大的断层，这样一来数据空间使用不充分，但是物理空间却无法轻易释放。造成的一种比较尴尬的情况就是下面的样子。剩余空间1.1T，使用空间才300多G,空间的使用率完全没有合理释放出来。

Tablespace           STA M A Init     Total MB    Free MB     Used MB
-------------------- --- - - ---- ------------ ---------- -----------
AUDIT_TAB            OLN L S  64K            3          1           2
CMBI_MIN_DATA        OLN L S  64K    1,183,573    847,492     336,081
CMBI_MIN_INDEX       OLN L S  64K      269,454    221,167      48,287
SYSAUX               OLN L S  64K          870         68         802
SYSTEM               OLN L S  64K          700        374         326
TEMP                 OLN L U   1M       63,487     63,487           0
UNDOTBS1             OLN L S  64K       38,304     26,206      12,098
USERS                OLN L S  64K          204         11         193
                                  ------------ ---------- -----------
sum                                  1,556,594  1,158,805     397,790

所以这种情况需要改善，但是收起来容易，做起来难。

因为我很快发现问题比我想的要复杂一些。大体来说数据文件的高水线县问题有三类。

在数据文件的起始位置附近。