oracle-12801,关于ORA-12801,ORA-27090的简单分析

从错误信息来看是由于并行进程引起的,查看了客户提供的日志，这个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                          9113INACTIVE

extract@ccbdbpr  (TNS V1-V3)                90 INACTIVE

Session_count osuser   hash_value   sql_id

1       truwl71     1443142349 bhm5y9tb096qd

4844pcmwrk01    33612736245vxmncv45jxss

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    1950821498459f3z9u4fb3u

36       truwl32      941869720 f6hcnghw27kns

5       parwrk01    1209197086 07h65fd415shy

1       truwl25     1605399126 g1p5bjdgv0wkq

32       truwl71      941869720 f6hcnghw27kns

32       truwl14      941869720 f6hcnghw27kns

449       pcmwrk01    3203606695dm03006zg6a57

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,和补丁的修复也有关系，开发还在继续排查和分析。

这个问题告诉我们，一个看似简单的问题可能是由另外一个问题导致的。问题的背后都有一定的原因，需要我们留心，可能在排查的时候就会轻松很多。