有一套rac数据库，一个业务报表逻辑非常复杂，sql语句达到了600多行，表关联有20多个，采取了并行查询的方式去优化，而这个并行查询虽然速度上得到了解决，但是经常出现几个月之前的进程都不释放的状态，而且这些遗留的并行进程拖慢了系统的运行，最后经常不
有一套rac数据库，一个业务报表逻辑非常复杂，sql语句达到了600多行，表关联有20多个，采取了并行查询的方式去优化，而这个并行查询虽然速度上得到了解决，但是经常出现几个月之前的进程都不释放的状态，而且这些遗留的并行进程拖慢了系统的运行，最后经常不得不采取手动kill掉这些并行进程来释放压力。
查看了很多的文档并没有发现一个合适的说法，而这些并行进程都是在进行PX Deq:Execution Msg或者PX Deq Credit: send blkd等待，做hanganalyze也找不到问题的原因，mos上也没发现疑似的bug。
看见mos这篇文章
PX Deq Credit: Send Blkd Waits Seen after CTRL-C on a Session and Parallel Query Slaves Not Released (文档 ID 1545069.1)
Cause：
This is not a bug per Bug 1837760: PARALLEL QUERY SLAVE DOES NOT GET RELEASED AFTER CTRL-C TO CANCEL THE QUERY, which was closed as an enhancement request. Slaves will be considered "busy" until a SQL statement completes and releases the cursor. If a session is CTRL-C'd, the cursor will remain open until either (1) another SQL statement is issued in the session, or (2) the session is exited. This behavior continues through 11g and higher
Solution：
If you CTRL-C a session running in parallel, either issue another SQL statement to release the slaves, or exit the session.
这篇文章大概说的就是一个并行查询如果被终止了，这些并行进程依然还会存在，并进行一些PX Deq的等待，而解决办法是需要在当前这个session中执行另一个查询或者exited退出这个会话。
根据上面的文章小鱼手动做了这个复杂模块的查询，然后又叉掉了这个模块，过了很长的时间这个对应的并行进程并不释放，而查询这些并行进程发现对应的sql语句正是这个复杂的sql语句。
这个600多行的sql语句不采用并行执行是相当的慢，调优由于网络等因素都不方便，所以建议做的是并行，但是由于是客户操作某个模块触发的这个复杂的sql，而且有时候如果半天不响应就直接叉掉了那个模块重来，而叉掉这个模块的动作并不会清除当前这个会话，正是这个会话后台运行导致了oracle的pmon进程不会去释放一个运行的好好的进程，从而引起了太多的看似没有释放的并行进程，其实在oracle看来这些并行进程还在正常运行，根本就不需要释放，其实也就是会话后台运行引起的并行进程不释放，而为什么叉掉这个模块后，会话依然还在后台运行，这个可能跟中间件等相关，而这个中间件用的weblogic。
原文地址：会话后台运行引起并行进程释放问题, 感谢原作者分享。
