1. KingbaseES数据库空间管理的重要性作为一名数据库管理员我经常遇到这样的场景系统突然报警磁盘空间不足业务部门抱怨查询变慢而老板则要求你立刻给出解决方案。这时候如果对数据库的空间使用情况没有清晰掌握就会陷入被动。KingbaseES作为一款优秀的企业级数据库提供了丰富的内置函数来帮助我们精准掌控数据库和表的空间占用情况。记得去年我们公司的一个核心业务系统就出现过类似问题。当时系统运行缓慢经过排查发现是某个日志表数据量激增占用了超过80%的数据库空间。如果当时能定期监控表空间使用情况就能提前预警并采取措施。这就是为什么我们需要掌握KingbaseES的空间管理技巧。2. 查看单个数据库的空间占用2.1 使用sys_database_size函数查看单个数据库大小是最基础的操作。KingbaseES提供了sys_database_size函数可以精确返回数据库占用的字节数。使用方法非常简单kapp# select sys_database_size(kapp); sys_database_size ------------------- 1685672055 (1 行记录)这个数字看起来不太直观因为它是以字节为单位的。对于日常管理来说我们更习惯用MB或GB来表示。这时候可以配合使用sys_size_pretty函数kapp# select sys_size_pretty(sys_database_size(kapp)); sys_size_pretty ----------------- 1608 MB (1 行记录)2.2 实际应用场景在实际工作中我通常会把这两个函数结合起来使用。比如在做容量规划时先获取精确的字节数用于计算再用易读的格式生成报告给领导看。这里有个小技巧sys_size_pretty函数会自动选择最合适的单位KB、MB、GB等来显示避免了手动换算的麻烦。3. 查看所有数据库的空间占用3.1 获取全局视图管理多个数据库时我们需要一个全局视图来了解各数据库的空间占用情况。这可以通过查询sys_database系统表配合sys_database_size函数实现kapp# select sys_database.datname, sys_database_size(sys_database.datname) as size from sys_database order by size desc; datname | size ---------------------- kapp | 1685672055 test | 1284485239 kdef | 18952311 kou | 16601207 samples | 15573507 template2| 12878339 security | 12870147 template0| 12845571 template1| 12845571 (9 行记录)3.2 排序与分析技巧我习惯按大小降序排列这样一眼就能看出哪些数据库占用了最多空间。在实际运维中这个查询结果能帮助我们快速定位问题。比如发现某个测试数据库(test)大小接近生产库(kapp)这显然不正常可能需要检查是否有测试数据混入了生产环境。4. 查看单个表的空间占用4.1 基本查询方法数据库空间占用的大头通常是用户表。查看单个表的大小使用sys_relation_size函数kapp# select sys_size_pretty(sys_relation_size(art_att_dat)); sys_size_pretty ----------------- 24 kB (1 行记录)4.2 理解表空间组成需要注意的是sys_relation_size只返回表数据本身的大小。实际上一个表占用的空间还包括索引、TOAST数据等。要获取表的完整大小应该使用sys_total_relation_size函数kapp# select sys_size_pretty(sys_total_relation_size(art_att_dat)); sys_size_pretty ----------------- 48 kB (1 行记录)这个差异在实际中很重要。我曾经遇到过表数据只有100MB但总大小达到1GB的情况就是因为有大量索引。如果不看总大小可能会低估实际空间占用。5. 查看所有表空间占用5.1 获取表空间列表要查看某个模式下所有表的大小可以查询sys_stat_user_tables视图kapp# select schemaname,relname, sys_size_pretty(sys_total_relation_size(relid)) from sys_stat_user_tables where schemanamekapp order by sys_relation_size(relid) desc limit 5; schemaname | relname | sys_size_pretty ------------------------------------------------ kapp | log_data | 582 MB kapp | log_info | 384 MB kapp | form_freq_opinion | 69 MB kapp | wf_acl_entry | 1600 kB kapp | wf_his_step | 1144 kB (5 行记录)5.2 空间分析实战经验这个查询结果非常实用。在我的日常工作中会定期运行类似查询重点关注以下几点最大的几个表是否正常增长是否有表异常膨胀日志类表是否定期归档清理比如上面的log_data表占用了582MB如果发现它每天都在快速增长就需要考虑是否要调整日志保留策略或进行分区处理。6. 高级空间管理技巧6.1 定期监控方案为了更有效地管理空间我建议建立定期监控机制。可以创建一个存储过程定期收集空间使用数据并存入历史表。这样不仅能发现即时问题还能分析空间使用趋势。CREATE TABLE db_size_history ( collect_time timestamp, db_name text, size_bytes bigint ); CREATE OR REPLACE FUNCTION collect_db_sizes() RETURNS void AS $$ BEGIN INSERT INTO db_size_history SELECT now(), datname, sys_database_size(datname) FROM sys_database; END; $$ LANGUAGE plpgsql;6.2 空间回收方法当发现空间占用过高时除了扩容还可以考虑空间回收。KingbaseES提供了VACUUM命令来回收死元组占用的空间。对于大表建议使用VACUUM FULL但要注意它会锁表VACUUM FULL VERBOSE ANALYZE log_data;7. 空间异常排查流程7.1 常见问题定位当收到磁盘空间告警时我通常会按照以下步骤排查使用df -h确认磁盘使用情况查看各数据库大小找出异常增长的库在问题库中查询大表分析具体表的增长原因7.2 真实案例分享去年我们遇到一个案例生产数据库一夜之间增长了20GB。通过上述方法快速定位到一个日志表异常增长。进一步调查发现是某个批处理作业忘记关闭调试日志产生了大量冗余记录。及时发现问题后我们清理了无效数据并对日志级别进行了调整避免了更严重的后果。8. 自动化监控脚本8.1 编写监控脚本为了更高效地管理空间我开发了一个简单的shell脚本定期检查数据库空间使用情况并在超过阈值时报警#!/bin/bash DBNAMEkapp WARNING_GB50 CRITICAL_GB80 SIZE_BYTES$(ksql -U kingbase -d $DBNAME -t -c SELECT sys_database_size($DBNAME);) SIZE_GB$((SIZE_BYTES/1024/1024/1024)) if [ $SIZE_GB -ge $CRITICAL_GB ]; then echo CRITICAL: Database $DBNAME size is ${SIZE_GB}GB exit 2 elif [ $SIZE_GB -ge $WARNING_GB ]; then echo WARNING: Database $DBNAME size is ${SIZE_GB}GB exit 1 else echo OK: Database $DBNAME size is ${SIZE_GB}GB exit 0 fi8.2 集成到监控系统这个脚本可以集成到Zabbix等监控系统中实现自动告警。我还扩展了脚本功能让它不仅能检查整个数据库的大小还能监控单个表的增长情况为容量规划提供数据支持。
