ホームページ  >  記事  >  データベース  >  会话后台运行引起并行进程释放问题

会话后台运行引起并行进程释放问题

WBOY
WBOYオリジナル
2016-06-07 16:36:391299ブラウズ

有一套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。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。