关于ORA-12801,ORA-27090的简单分析(r4笔记第58天)
关于ORA-12801,ORA-27090的简单分析(r4笔记第58天)
今天下午收到客户的邮件，说有一个job在运行的时候报错了，希望我们能帮忙看看是什么原因。
ERROR: Caught en exception: ORA-12801: error signaled in parallel query server P130
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Additional information: 128
Additional information: 1
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Additional information: 128
Additional information: 1
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Additional information: 128
Additional information: 1
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Additional information: 3
Additional information: 128
Additional information: 2113522240
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Additional information: 3
Additional information: 128
Additional information: 2113522240
从错误信息来看是由于并行进程引起的,查看了客户提供的日志，这个job是一个每天都会执行的job,每次回启用几个独立的process来并行跑，每个process里面的sql语句都走了并行，并行度是8，所以占用的session数不会太多，在100个以内是肯定的。
这个时候查看awr只能在报告头看到session的数据，得到不一些具体的session占用情况，查看ash也得不到，因为得到的都是active session的信息。
这些信息可以自己使用脚本来自动采集，也会有所侧重，得到的数据也更有意义和说服力。
我抓取了下午的报告，报告的时间在错误发生前几分钟。
可以看到session数已经用了不少了，而且绝大多数的session都在JDBC的程序上。
STATUS CNT
-------- ----------
ACTIVE 165
INACTIVE 9879
----------
sum 10044
.
PROGRAM CNT STATUS
----------------------------------- ---------- --------
JDBC Thin Client 9113 INACTIVE
extract@ccbdbpr (TNS V1-V3) 90 INACTIVE
Session_count osuser hash_value sql_id
1 truwl71 1443142349 bhm5y9tb096qd
4844 pcmwrk01 3361273624 5vxmncv45jxss
42 truwl15 941869720 f6hcnghw27kns
4 pcowrk01 3359590350 fa311gg43yjyf
15 pcmwrk01 2311663385 27uaksf4wkbst
65 parwrk01 1950821498 459f3z9u4fb3u
2 truwl74 1443142349 bhm5y9tb096qd
15 truwl35 941869720 f6hcnghw27kns
1 truwl35 3428812084 bwjxuug65z19n
30 truwl22 941869720 f6hcnghw27kns
1 truwl41 4042609743 bg0xgs3sgap2g
9 pcmwrk01 1204453754 frvwp893wp0bu
2 truwl74 4042609743 bg0xgs3sgap2g
1 truwl71 1488663547 b26tu71cbqczv
192 pcmwrk01 20635029 byd95500mprcp
1 truwl71 2397213050 26b628u7f54bu
64 pcmwrk01 2555678015 6vf0fzkc5939z
425 pcmwrk01 1950821498 459f3z9u4fb3u
36 truwl32 941869720 f6hcnghw27kns
5 parwrk01 1209197086 07h65fd415shy
1 truwl25 1605399126 g1p5bjdgv0wkq
32 truwl71 941869720 f6hcnghw27kns
32 truwl14 941869720 f6hcnghw27kns
449 pcmwrk01 3203606695 dm03006zg6a57
40 truwl65 941869720 f6hcnghw27kns
33 truwl43 941869720 f6hcnghw27kns
2 truwl53 647050378 f9mmq7sm92d4a可以很明显看到sql_id(5vxmncv45jxss)占用了相当多的session，可以断定这些session都是inactive的。这个可以通过如下的信息来验证。
STATUS CNT
-------- ----------
ACTIVE 165
INACTIVE 9879
----------
sum 10044
查看问题语句对应的系统用户竟然是另外一个模块的。根据sql_id抓取了对应的sql语句，是一个很简单的select 语句。
/* CM9_ServiceAgreement_selectServiceAgreement_1 */ SELECT xxxxx FROM SERVICE_AGREEMENT WHERE SERVICE_AGREEMENT.AGREEMENT_NO = :1 AND SERVICE_AGREEMENT.EXPI
RATION_DATE IS NULL
和开发做了确认，发现这是一个客户化的job导致的问题，已经做了修复，打了补丁到生产环境，时间是今天凌晨，所以客户就希望我们能够看看哪些占用很多的session是以前的历史session还是今天的，这个问题看似挺容易，但是却是无处可查，
v$session中的信息早就被刷掉了，要得到哪些session的登录时间来判断是很难的，除非自己做了更多细致的监控。
这个时候我是通过另外一个思路来推的。
我抓取了几个报告。
问题发生一个小时前的报告，在2点左右，session数在9000左右，pcmwrk占用的session是2000多。
然后抓取了上午11点的报告，pcmwrk占用的session在4000多。
通过这些信息还不能推论是否有大量的历史session.
我又抓取了一个问题发生1个小时后的报告，大概在5点左右，pcmwrk占用的session在15个左右。
通过这个就可以很自信的告诉客户，这些session都是今天的，至于为什么占用这么多的session,和补丁的修复也有关系，开发还在继续排查和分析。
这个问题告诉我们，一个看似简单的问题可能是由另外一个问题导致的。问题的背后都有一定的原因，需要我们留心，可能在排查的时候就会轻松很多。