客户反映系统上某个操作特别慢,要等很久
于是我去客户现场看了下,那边的db2是安装在Linux下面的v8.1版本
补丁好像不是很新,所以是没有db2top这个命令的,还好客户自己不知道从哪拷贝了db2top这个文件
发现也可以直接使用,通过这个db2top的命令看到了一些具体的情况,
当发生问题的时候,session中处于运行状态的一个agent会运行很长时间,再去查询这个agent的dynamic SQL语句时,发现就是一个简单的select count主键,还有就是bufferpool的命中率非常低
只有10%不到,后来用quest centre看这个简单的select语句的执行计划的时候发现对这个主键的count
并没有做index scan而是走的table scan, 并且代价也很大,对于同样类型的其他表也进行了相应操作
发现都是走index scan的,因而怀疑是索引这里出了问题,
解决方法,先把应用停下来,然后对整个数据库做离线全备份(后面发现这个是非常重要的,有路可退)
首先去掉这个主键,然后重建该主键,建好后发现select count语句还是没有走index scan仍然是table scan, 当然这里建完主键后还是做过runstat的。
于是就只有一种办法,那就是将这个表drop掉,然后重建表并把数据导入进来,这里首先通过下面的语句导出数据:
db2 "export to TABLENAME.ixf of ixf select * from SCHEMA.TABLENAME"
然后获得表的ddl
drop这个表<