当前位置:Gxlcms > mysql > 显式激活数据库(ACTIVATEDATABASE)

显式激活数据库(ACTIVATEDATABASE)

时间:2021-07-01 10:21:17 帮助过:18人阅读

某天值班员联系我说,我负责的一套报送系统没有按时生成报文,因为此报警提前量比较大,加上系统经常发生未按时生成报文的事件,也就是没在意,然后不急不慢的到公司,打开系统页面,发现其中一个存储过程跑了将近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分钟左右完成,按推理,显示激活数据库应该不会影响到存储过程的运行,但是事实就是影响了,之后日子没有发生类似的问题。
建议对于没有长连接的数据库,如果此数据库没有运行其他软件,或者系统资源比较充足的情况下,最好显式激活数据库

人气教程排行