一个Job运行失败导致数据库挂死

今天上午10点多的时候,同事接到一个电话,某数据库任何连接都连不上数据库,登录主机后发现,该数据库已经挂死,sqlplus都无法登陆,在alertlog中发现大量的“PMON failed to acquire latch, see PMON dump”。无奈之下,杀掉了oracle的进程,重启了数据库。

事后,我们来看看究竟是什么原因,造成了这次数据库的挂死。

我们看alertlog的相关报错,我们发现“PMON failed to acquire latch, see PMON dump”5月4日的10:32,而这个报错发生在之前,还有一个报错,在5月2日的4:51还有一个“>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=11”

这是一个很重要的线索,因为这个报错,我们看出为什么当时同事在处理的时候,连sqlplus都登录不上了,因为sqlplus的登录需要row cache的latch,如果获取不到,就会长时间等待,出现挂死。

那么,为什么会出现WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK,我们从alertlog中发现,当出现WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK告警的时候,oracle还dump出来一个system state:/u04/admin/IGP2TCACAC0/bdump/igp2tcacac0_mmon_811148.trc(点击这里可以下载该trace file)

system state dump里面包含很多信息,包含每个进程的情况,但是这个文件往往比较大,对于初步分析比较困难了。幸好我们还有一个ass的工具可以帮助我们看system state dump(点击这里下载windows版的ass109.awk)。

(2016-06-16 update: ass109.awk已经集成在LTOM中,LTOM中自带ass109.awk脚本。LTOM – The On-Board Monitor User Guide (Doc ID 352363.1))

我们通过ass先来看看当时的系统情况:

从Resource Holder State部分,我们看到,有一个blocker,该blocker的latch是7000000239479a0。而且是这个latcher的holder,造成了其他的process,如process 15,16,25,26等等的last wait for ‘latch: library cache’。

我们从这个system state dump的原始文件中去看latch为7000000239479a0是什么,搜索7000000239479a0+holding:

我们看到hold住latch 7000000239479a0是oracle@sg2as059 (J000)进程,也就是job的进程。也就说,由于这个j000进程的异常,hold住了7000000239479a0 的latch。

我们同时也看到job的cjq0进程有一个trace文件产生:

这里也可以看到,j000死掉之后,也无法释放掉,操作系统无法对其做procstack。

进一步的,我们看到,在类似的数据库重启前,都有一个cjq0的trace文件。我们初步判断,这个job在某些时候,会死掉且不能释放,而且,最后都是通过杀进程,重启database来解决的。

我们进一步来看看是什么job,很幸运,这个系统就只有一个job:

我们查到metalink中,这个job的用处,What is EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS dbms_job and how to Remove / Re-create it [ID 444033.1]

在这个系统中,由于我们不用dbconsole,所以我们可以移除这个job,避免问题的再次发生。

相关文章

2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据