本篇文章主要介绍了" 一次涉及到物化视图的DB2 Insert性能问题的诊断"，主要涉及到方面的内容，对于DB2感兴趣的同学可以参考一下：
一 问题描述：今天得到Devops兄弟的报告，说某个数据插入job突然间慢了很多，平时10多分钟就能完成的，跑了10个小时左右没有完成。 Devops的Lock...
- 此程序是一个CLP程序，CLP就是不是通过java,也不是通过客户端工具，而是本地local的SQL,并且可以看到程序的路径
- 此Application已经运行了很长时间从05/10/2017 17:06:56 =>05/11/2017 01:51:44, 已经运行接近9个小时，还没有结束。
- bufferpool logical reads和rows reads已经大到没有朋友了。
- 居然还有84W的sorts
其实snapshot看到的东西跟db2pd差不多，毕竟snapshot是老一代的监控工具，而db2pd属于新生代（其实也很老了）。问题的关键是问什么会有那么多读？
因为snapshot详细的给出了脚本信息（注意：不是每次都有这么好的运气）， 所以代码不看白不看。
4. 查看运行脚本
...
delete from xxx.xxx_xxx_domain;
select count from xxx.xxx_xxx_domain;
import from xxx_xxx_domain_live.csv of del insert into xxx.xxx_xxx_domain;
...
脚本如此简单，看来那么多insert语句就是import 产生的。（import的运行机制就是将文件里的数据组装成insert语句然后插入）
咱们先暂且不管此脚本为什么如此写，为什么不用load replace？ 为什么import不加commitcount？ 这是以后优化的事。毕竟对DB2不熟悉的开发人员啥都能写出来。
到此实在是想不出为什么这么多读，为什么？
5. 重新使用db2pd查看调查大量读的原因
使用db2top => T - Tables 看表的使用情况，我的天啦，原来这些行读不是发生在正在做插入的xxx.xxx_xxx_domain表上，而是xxx.users表，还好当时有截屏。
注：为了不泄漏项目信息，敏感部分已经用红框盖住。
我的乖乖，每秒钟users表上的读诗572555
6.使用db2 snapshot查看是否有其它应用使用users表。
db2 get snapshot for applications on DBNAME > ssapp.txt
对ssapp.txt进行地毯式搜索，根本就没有查到任何SQL访问users. 所以可以确定还是前面对于xxx.xxx_xxx_domain的导入造成的问题。
7. 查看是不是在xxx.xxx_xxx_domain的insert有trigger,而对于users表的访问逻辑在trigger里。
select trigschema,trigname,tabschema,tabname,create_time from syscat.triggers where tabname like 'xxx_xxx_DOMAIN%'
结果很令人失望，这个表根本就没有trigger.
为什么？为什么？此处让我这个DB2老鸟陷入沉思一个小时。
8. 通过db2look查看关于xxx.xxx_xxx_domain的所有信息。
老鸟是不会被打败的，以前的经验是当发生不可思议的事情的问题时，一定要从最简单的DDL开始检查。所以通过db2look生成全库的db2look文件。
