关于奇怪的并行进程分析(一)

对于等待事件SQL*Net vector data from client可以参考 Doc ID 1311281.1
说法是可以忽略。我们可以先把这个问题放一放，来通过其他的思路来分析一下。
首先数据库的负载突然提高，如果单纯是因为备库的原因，为什么不是其它时间段内，白天的时候没有任何报警。白天的负载更高，更应该出现问题才对。
所以这种情况应该还是有一定的触发条件，但是查看了crontab也没有什么发现，那么很可能就是scheduler相关的。
我们怎么来推论呢。
首先的考虑就是后台的scheduler，结果查看还是默认的晚上10点左右，所以到早上的那个时间段应该不会有直接的影响。
那么scheduler狠可能就是用户自定义的。
限定在问题时间段内，得到的信息如下
 select owner,job_name,last_start_date,end_date,NEXT_RUN_DATE from dba_scheduler_jobs where last_start_date between to_timestamp(‘2015-08-27 05:00:00‘,‘yyyy-mm-dd hh24:mi:ss‘) and to_timestamp(‘2015-08-27 08:00:00‘,‘yyyy-mm-dd hh24:mi:ss‘)
 OWNER   JOB_NAME                       LAST_START_DATE            
------- -------------- ---------------------------------------------
APP_TEST   SYN_D     27-AUG-15 07.11.00.002185 AM ASIA/SHANGHAI
APP_TEST   SYN_E      27-AUG-15 06.15.00.809059 AM ASIA/SHANGHAI
APP_TEST   SYN_F      27-AUG-15 06.12.05.312974 AM +08:00      
APP_TEST   SYN_G      27-AUG-15 05.00.40.797679 AM ASIA/SHANGHAI
可以看到确实还是有scheduler job在运行,而且时间也基本是相符的。
   LOG_ID LOG_DATE                                 OWNER      JOB_NAME                   STATUS  
---------- ---------------------------------------- ---------- -----------------------------------
    241839 27-AUG-15 07.30.00.140947 AM +08:00      TEST_APP   SYN_D                     SUCCEEDED
    241836 27-AUG-15 07.05.46.398691 AM +08:00      TEST_APP   SYN_E                     SUCCEEDED
    241840 27-AUG-15 07.30.01.319849 AM +08:00      TEST_APP   SYN_F                     SUCCEEDED
    241841 27-AUG-15 07.35.00.912152 AM +08:00      TEST_APP   SYN_G                     SUCCEEDED
从以上的信息可以猜想可能是scheduler job引发的大量并行session的情况，我们后续继续进行跟踪，揭开问题的真实面纱。

关于奇怪的并行进程分析(一)

原文：http://blog.itpub.net/23718752/viewspace-1784544/