首先排查操作系统根文件系统使用率,确认当前根文件系统可用总容量不足1T,数据库表空间合计占用超过900G。因此,排出掉操作系统本身占用及db2软件(实例为循环日志模式,事务日志以及诊断日志合计不足12G),若要解决问题,只能表空间容器上下手。
实际情况为,当前系统搭建的较早,当初直接将sda的某个分区给了根,无法实现扩容。
db2 “alter tablespace tablespace_name resize (file file_name size )”
经过查询表空间的使用率,用户自定义的表空间有两个,分别为DMS_DATA和DMS_IDX,使用率都较高,而且数据下发库的表不允许清理,再考虑碎片的影响,因此容器缩容方案预估只能释放极少数空间。
理论上可行,实际验证时发现时间过长,允许的停机窗口远远不够。经过最简单的cp测试,发现当前机器连接的存储每秒读写速度低于70MB/s,而数据库大小超过900G,且没有开启归档(循环日志模式),备份时只能选择离线备份(离线备份期间数据库无法连接使用),再包含恢复时间,总时长计算下来超过了7.5小时。
DMS_IDX表空间只有100G,按当前的磁盘速度只需要大约25分钟左右,满足停机时间窗。并且如果数据库出现异常,可以通过mv回去的方式回退。
DMS_IDX为存放索引的表空间,万一发生极端情况出现损坏,可以通过rebulid index的方式恢复,最起码能保证数据不丢失。
执行:
首先将新申请的磁盘创建为pv,组成新的vg,划新的lv挂载成新的文件系统(做成vg的目的是若干年后可以直接在线扩容)。
(截图为测试环境问题复现)
关闭数据库,mv容器,并且创建软连接。
▼▼▼
db2stop force
mv /home/db2inst1/others/dms_idx01 /new_datafile/sample/
ln -s /new_datafile/sample/dms_idx01 /home/db2inst1/others/dms_idx01
db2start
重新启动数据库,检查表空间状态一切正常,走索引查询部分表数据测试正常。
此处检查容器位置,依然为mv之前的位置,对数据库无感知。
检查文件系统使用率已释放。
完成。
更多精彩干货分享
点击下方名片关注
IT那活儿
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/129907.html
摘要:新晋技术专家下面是墨天轮部分新晋的技术专家。大家可以点击往期阅读墨天轮技术专家邀请函了解详情,申请成为我们的技术专家,加入专家团队,与我们一起创建一个开放互助的数据库技术社区。新关联公众号墨天轮是一个开放互助的数据库技术社区。 引言 近期我们在DBASK小程序增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术...
阅读 1249·2023-01-11 13:20
阅读 1557·2023-01-11 13:20
阅读 1011·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1310·2023-01-11 13:20
阅读 3486·2023-01-11 13:20