1、一个操作数据量不大的sql语句，能引起db2宕机吗？答案是：yes！
工作中同事曾经用到group by 中使用了多个roll up 函数，结果db2宕掉了！！！
据ibm人说需要打补丁 FIXPACK7，还有次hang命中了APAR，也需要升级到9.5的FIXPACK7
2、文件系统存储空间的监控对每个系统都是很重要的，如果监控不好，引起其他应用出了问题，原因查都不好查，上次DETACH 一个表的一个分区时，系统视图syscat.datapartitions里相关的记录竟然没删除，只是某些字段置空了。。。
找了好久原因，都没找到，后来注意到诊断日志报审计的错误，无意识的查了下审计目录下的日志文件，发现少了几个，因为我们是9分区数据库，所以应该有9个审计日志文件，没有从其他目录移动过来，我们手工移过去，detach的问题解决了、、、
原因是这样的：之前这个存储节点容量爆过，当时执行审计任务时，由于空间不够，日志文件只移动了一部分。。。但具体这两件事之间的联系仍未查明。。
3、一个表更新次数多了，表的系统信息可能就不准了，需要对表做runstates，执行runstates是可能会报错的，不过多执行几次就好了，没办法，只能在程序里控制。
1、一个操作数据量不大的sql语句，能引起db2宕机吗？答案是：yes！
工作中同事曾经用到group by 中使用了多个roll up 函数，结果db2宕掉了！！！
据ibm人说需要打补丁 FIXPACK7，还有次hang命中了APAR，也需要升级到9.5的FIXPACK7
2、文件系统存储空间的监控对每个系统都是很重要的，如果监控不好，引起其他应用出了问题，原因查都不好查，上次DETACH 一个表的一个分区时，系统视图syscat.datapartitions里相关的记录竟然没删除，只是某些字段置空了。。。
找了好久原因，都没找到，后来注意到诊断日志报审计的错误，无意识的查了下审计目录下的日志文件，发现少了几个，因为我们是9分区数据库，所以应该有9个审计日志文件，没有从其他目录移动过来，我们手工移过去，detach的问题解决了、、、
原因是这样的：之前这个存储节点容量爆过，当时执行审计任务时，由于空间不够，日志文件只移动了一部分。。。但具体这两件事之间的联系仍未查明。。
3、一个表更新次数多了，表的系统信息可能就不准了，需要对表做runstates，执行runstates是可能会报错的，不过多执行几次就好了，没办法，只能在程序里控制。