一个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，避免问题的再次发生。