某天值班员联系我说，我负责的一套报送系统没有按时生成报文，因为此报警提前量比较大，加上系统经常发生未按时生成报文的事件，也就是没在意，然后不急不慢的到公司，打开系统页面，发现其中一个存储过程跑了将近8小时还没结束。以往这个存储过程最长的运行
某天值班员联系我说，我负责的一套报送系统没有按时生成报文，因为此报警提前量比较大，加上系统经常发生未按时生成报文的事件，也就是没在意，然后不急不慢的到公司，打开系统页面，发现其中一个存储过程跑了将近8小时还没结束。以往这个存储过程最长的运行记录也就不到2小时，这肯定有问题。查看前一天的运行记录也是10个小时左右，在以前的记录就都是半小时左右了，而且接着这个存储过程运行的下一个批作业（一个JAVA程序），前一天也运行了1个小时，以往也就几分钟。为了保证业务使用，联系了项目组，咨询此存储过程可以先跳过不运行，于是force掉数据库连接，接着就运行那个JAVA程序，可是运行也相当慢，tail输出日志，发现程序每处理一条记录，都先数据库连接，并且关闭，然后再处理一下条记录（上次出现JAVA连接不能正常CLOSED，导致JAVA连接池耗尽，项目组修改了连接方式）。这种方式肯定是不高效的，但是应该也至于这么慢，10几秒才处理一条记录，肯定有问题，因为这个JAVA程序已经上线好些日子了，为什么就这两天才慢。这个时候想起各位大神经常说的问题分析方法论了，方法论之一：最近系统有没有做过改动，确实有，上周重启过服务器，并且DB2进程使用双机软件拉起的，在拉起DB2进程的时候，没有显式激活数据库，而这个系统没有前台应用，也就是说没有长连接的数据连接到数据库，数据库在无连接情况下，会释放部分资源，只保留必要的一些资源，当在再次有应用连接到数据库的时候，会重新导入相关资源，完成数据处理，这个初始化过程是一个比较耗时的操作（当执行db2start操作，如果没显式激活数据库，第一次执行db2 conncet to dbname时候是不是感觉很慢），分析到这来就立刻执行了ACTIVATE DATABASE操作，那个JAVA程序瞬间完成，至于之前的那个存储过程，重新运行也是20分钟左右完成，按推理，显示激活数据库应该不会影响到存储过程的运行，但是事实就是影响了，之后日子没有发生类似的问题。
建议对于没有长连接的数据库，如果此数据库没有运行其他软件，或者系统资源比较充足的情况下，最好显式激活数据库
