监控个空间使用率有那么难吗？-睿象云平台

监控个空间使用率有那么难吗？

本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。

监控个空间使用率有那么难吗？

数据库运维中，空间使用率监控是一种十分常规和必要的监控。不过空间使用率监控也不是件容易的事情。对于Mysql、Postgresql等数据库来说监控起来相对简单，只要监控相关的文件系统就可以了。不过如果我们使用了MYSQL的共享表空间，同时没有设置自动扩展，那么我们不仅要观察文件系统的空闲情况，还要关注共享表空间文件的使用率情况。当然如果是32位的系统，那么就更麻烦一些了，每个数据文件的大小都有限制，我们在计算空间使用率的时候还需要关注不同版本的操作系统对文件大小的限制。

对于Oracle表空间的监控，大家可能觉得比较容易，不就是通过dba_free_space去统计一下就可以完成的事情吗？事实上也不是那么简单的事情。

在11g以后，大家使用ASM的越来越多了，而且大多数使用了ORACLE管理文件（OMF）这个Oracle缺省的功能，数据文件一般都会被设置为自动扩展（在早期的Oracle 8/9时期，Oracle数据文件自动扩展存在一些性能隐患和BUG，再加上裸设备的使用，所以一般DBA都会建议关闭数据文件自动扩展，而随着存储性能的提升以及Oracle产品的提升，在ASM存储下，数据文件自动扩展已经可以放心使用了）。因此表空间使用率为100%并不一定意味着数据库表空间不足的报错，只要ASM还有足够的空间扩展文件，是不会有问题的。于是久而久之，一些用户就对表空间100%熟视无睹了，认为不需要去监控表空间使用率了，只要监控ASM空间的使用率就可以了，只要ASM有足够的空闲空间，系统就是安全的。

前阵子一个用户问我：“老白，明明我的ASM还有好几百G的空闲空间，为什么我的系统在报表空间不足，无法扩展呢？是不是我的ASM碎片化太厉害了呢？”。实际上几百G的空闲空间，碎片化是不大可能的，因为ASM都是按照固定的AU SIZE去分配空间的。最大的可能性就是客户的某个数据文件达到了最大块数，比如8K的数据文件，受到块数的限制，最大的大小就是32G，如果某个表空间的所有文件都扩展到了32G，那么这时候哪怕ASM还有几个T的容量，这个表空间都无扩展可用了，除非你再添加一个新的数据文件。

还有一个案例也是和表空间监控有关的。我们经常使用类似下面的一条SQL去监控表空间的使用率情况：

SELECT a.tablespace_name, ROUND (a.bytes_alloc 1024 1024, 2) megs_alloc,

ROUND (NVL (b.bytes_free, 0) 1024 1024, 2) megs_free,

ROUND ((a.bytes_alloc - NVL (b.bytes_free, 0)) / 1024 / 1024,

) megs_used,

ROUND ((NVL (b.bytes_free, 0) / a.bytes_alloc) * 100, 2) pct_free,

100

- ROUND ((NVL (b.bytes_free, 0) / a.bytes_alloc) * 100, 2) pct_used,

ROUND (maxbytes / 1048576, 2) MAX

FROM (SELECT f.tablespace_name, SUM (f.BYTES) bytes_alloc,

SUM (DECODE (f.autoextensible,

'YES', f.maxbytes,

'NO', f.BYTES

)

) maxbytes

FROM dba_data_files f

GROUP BY tablespace_name) a,

(SELECT f.tablespace_name, SUM (f.BYTES) bytes_free

FROM dba_free_space f

GROUP BY tablespace_name) b

WHERE a.tablespace_name = b.tablespace_name(+)

UNION

SELECT tablespace_name, ROUND (SUM (bytes_used + bytes_free) / 1048576, 2),

ROUND (SUM (bytes_free) / 1048576, 2),

ROUND (SUM (bytes_used) / 1048576, 2),

ROUND ((SUM (bytes_free) / SUM (bytes_used + bytes_free)) * 100,

) pct_free,

100

- ROUND ((SUM (bytes_free) / SUM (bytes_used + bytes_free)) * 100, 2)

pct_used,

ROUND (MAX (bytes_used + bytes_free) / 1048576, 2)

FROM SYS.v_$temp_space_header

GROUP BY tablespace_name

ORDER BY 1;

实际上这条语句需要对我们的数据文件进行一次全扫描，执行时间从几秒钟到几个小时不等。如果这个数据库很大，数据文件很多，extent数量很大，segment的数量也很多，特别是一些开启了回收站，并且不对回收站做管理的系统，经过长时间运行后，回收站中垃圾数量极多。这种情况下，执行上面的表空间查询语句的时间可能会十分长。

我就遇到过一个用户，他们的一体机监控软件中每隔1分钟扫描一次表空间使用率。有一次他们的系统变得特别慢，执行一条简单的语句都要几秒钟。我帮着分析了一下，TOP SQL居然是这条语句，平均执行时长高达60多分钟，在系统中已经积压了近百条没有执行完成的SQL。正是这条SQL占用了大量的系统IO，导致了全闪存的一体机都扛不住了。

既然这个问题存在，那么我们监控表空间使用率也不能太随意了，监控频率一定要有所控制，避免对系统造成太大影响。

实际上，数据库空间使用率的监控可以换一种思路，对于空间扩展十分快、表空间满了会严重影响业务的表空间，我们完全可以使用bigfile tablespace，并且开启文件自动扩展，这样我们就不需要考虑32G的限制问题，只需要专注于监控ASM的使用率就可以了。有时候解决一个问题，不一定非要一条道走到黑，换一个思路，问题其实是很容易解决的。