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