db2表空间另类迁移方法

点击上方“IT那活儿”，关注后了解更多精彩内容！！！

问题描述

某日接到某银行的故障请求，Linux系统根目录使用率100%，而当前服务器上只运行了一个db2数据库，因此希望我们远程帮助释放一部分空间（至少释放到不会触发告警的使用率），并且为当前服务器已经新申请了磁盘（存储）。

首先排查操作系统根文件系统使用率，确认当前根文件系统可用总容量不足1T，数据库表空间合计占用超过900G。因此，排出掉操作系统本身占用及db2软件（实例为循环日志模式，事务日志以及诊断日志合计不足12G），若要解决问题，只能表空间容器上下手。

解决方案

思路1：

首先排查根文件系统是否为卷组。若为逻辑卷组，只需要将新申请的磁盘做成pv分配给VG，然后在线扩容lv即可。

实际情况为，当前系统搭建的较早，当初直接将sda的某个分区给了根，无法实现扩容。

思路2：

db2数据库的DMS表空间容器（类似于Oracle数据库表空间的datafile）可以实现缩容，语法：

db2 “alter tablespace tablespace_name resize (file file_name  size )”

经过查询表空间的使用率，用户自定义的表空间有两个，分别为DMS_DATA和DMS_IDX，使用率都较高，而且数据下发库的表不允许清理，再考虑碎片的影响，因此容器缩容方案预估只能释放极少数空间。

思路3：

基于db2数据库表空间的容器无法像Oracle数据库那样实现数据文件移动（甚至是12C可以在线rename），按照IBM正规的解决表空间移动的方式为备份再恢复，需要先将数据库全量备份，然后restore redirect generate script，通过手动修改恢复脚本，将表空间容器重新指定，然后执行脚本恢复即可。

理论上可行，实际验证时发现时间过长，允许的停机窗口远远不够。经过最简单的cp测试，发现当前机器连接的存储每秒读写速度低于70MB/s,而数据库大小超过900G，且没有开启归档（循环日志模式），备份时只能选择离线备份（离线备份期间数据库无法连接使用），再包含恢复时间，总时长计算下来超过了7.5小时。

思路4：

经过多方验证之后，既然无法在数据库侧解决掉此问题，那么便选择欺骗数据库，通过软连接的方式解决，即关闭数据库将表空间DMS_IDX的容器mv到新的文件系统，掉释放空间，然后创建软连接到原来的位置，此方案有以下优势：

1、DMS_IDX表空间只有100G，按当前的磁盘速度只需要大约25分钟左右，满足停机时间窗。并且如果数据库出现异常，可以通过mv回去的方式回退。

2、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之前的位置，对数据库无感知。

检查文件系统使用率已释放。

Perfect！完成！

END

更多精彩干货分享

点击下方名片关注

IT那活儿