db2主键上的索引貌似失效了

客户反映系统上某个操作特别慢，要等很久
于是我去客户现场看了下，那边的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这个表
用刚才的ddl重建该表
然后用下面的命令导入刚才导出的数据：
db2 load from TABLENAME.ixf of ixf MODIFIED BY FORCEIN replace into SCHEMA.TABLENAME nonrecoverable
再去执行select count的语句的时候发现它是走index scan的，但是里面的数据确是有问题的，中文
显示的是乱码，这时候回头看导出的数据文件，发现里面的中文显示也是乱码，这时候幸好我们在处理问题
之前有对数据库做备份，那现在要把这个库恢复出来，这时客户怕了，说万一这个库恢复回去之后再出现中文乱码的问题怎么办，毕竟现在出问题的只是一张表，而假设数据库恢复回去后出问题的就是整个数据库了
客户告诉我，他们从来没有恢复过数据库，

后来，解决的办法是先在生产环境上面另外创建一个实例，然后将数据库在该实例下恢复出来，看一下数据库恢复的是否是正常，如果正常那么就可以在原来的实例下面将数据库restore回来，
在root用户下面用db2icrt创建好实例后，进到这个实例下面db2start启动实例，然后使用下面命令restore数据库：
db2 restore db OLDDB from /location/databak/all taken at 20101026161037 into NEWDB without rolling forward
这里恢复后当然一切是正常的，那就在原来的实例下面恢复数据库吧，数据库恢复完成后，怎么解决这个问题呢，我们就先再建一个同样的表，然后先把数据通过insert into select * from 这样的方式备份一下，再drop原来的表，结果发现这种方式执行速度太慢，没办法还是看能不能将表通过export和load的
方式重做一下，这个时候我发现实例下面居然没有设置DB2CODEPAGE，那就尝试设置了这个值，发现再次导出数据的时候中文显示就不是乱码了，这里DB2CODEPAGE试过两个值，忘了去看数据库的编码是什么了，应该是只要和数据库编码一致就可以了。
好，这样的话顺利将表重做，然后主键上的索引也可以使用了，看客户今天会不会再报什么问题吧！

Linux下面的LANG=zh_CN.UTF-8
SecureCRT的字符显示设置为UTF-8
但是数据库的字符编码是GBK的，对应DB2CODEPAGE就是1386，我第一次设置的是1208结果导出来的中文显示是乱码，即使再导入表里面，查询出来的仍然是乱码，只有当设置为1386的时候导出来的结果显示正确，再次导入进去后查询出来的结果也是正常。