7月某天早晨
刚从哈尔滨培训回来，还没坐上车就接到了客户的电话：DB2宕机了，急忙赶到客户现场，12点钟开始干活。
首先了解了一下客户环境：
两台机器A和B机，两机做Q-复制，A机数据库是source，B机数据库是target。两个数据库均为多分区（DPF，8节点），数据量大概为1T。
问题：B机的日志采用TSM归档，归档日志备份到TSM的时候出现错误，导致活动日志空间满，目标端Q-apply停止。
问题处理步骤：
1. 检查db2diag.log，发现归档的时候报了一些TSM错误。
2. 查看活动日志空间，已满。
3. 确认是DB2的问题还是TSM的问题。验证的方法很简单，只需用TSM做一个备份即可，db2 backup db xx use tsm ，结果发现无法备份。这就说明TSM出问题了。
4. 找TSM工程师，工程师发现好几个带库都是offline，怀疑是硬件问题。找到ibm原厂，结果发现是链路出现了问题（最近重新划了zone）
5. 由于该系统比较重要，客户要求下周一系统必须可用。而马上面临周末，解决硬件问题，并处理TSM未必来得及。
6. 于是兵分两路。一路处理TSM及硬件，一路处理DB2和Q复制，下周一前把数据复制完毕。
7. 首先对数据库做连线备份，900G数据大概用了1个半小时。然后更改归档日志模式为共享盘(disk:/databackup/)。重启数据库。
8. 然后处理目标端的MQ队列，在事故发生时，已经堆积了大概30万个消息。有些消息要处理的事务数据特别大，我们一度以为又出故障了。这样，大概到半夜4点钟，实在顶不住了，大家回去睡觉。
9. 第二天(周六)上午10点，继续赶去客户现场处理。到了现场，很幸运，目标端累积的数据已经处理完毕。
10. 启动Q-capture的MQ队列，发现故障时，由于目标端无法处理消息，为防止源端MQ队列满，将Q-capture关闭，但仍有一些消息在MQ发送队列未处理，大概5万个消息。
11. 处理完后，启动Q-capture程序，捕获新增数据，大概50万个事务。
12. 下午4点，顺利处理完毕。
当然，中间也不是一帆风顺，陆续遇见一些问题：
1. MQ日志所属文件空间满，导致MQ无法启动
2. Q-apply性能慢，调整了Q-apply的参数和DB2 bufferpool，性能明显改善。
总结：
1. db2的日志归档尽量不要直接用TSM，否则出了问题扯皮，已经在好几个客户，包括一家大的省移动也遇到过。建议归档到文件系统，然后采用普通文件的方式通过TSM备走。
2. 故障处理时，需要胆大，心细。
3. 良好的身体素质。:-）
4. 最后一点，这么大的数据量是否有必要采用DPF值得商榷。DB2 DPF+Q复制增加了很多复杂度和维护成本。性能问题很多不是硬件能搞定，SQL的优化才是关键。
收起