Randolf,
No need to apologize at all. :) I love all that I am learning on this
topic. Your blog post on this subject, and Yaskan's helpful iteraction, is
certainly good information. The confusing part for me is that we do not use
the Resource Manager - at least, not intentionally. :)
resource_manager_plan =
The documentation states "If you do not specify this parameter, the
resource manager is off by default."
I am hoping the SR engineers handling my two cases will provide some
helpful feedback soon. Right now my workaround is to use AUTO DOP and set
the parallel_degree_limit kinda high. Based on what you found out in the
blog thread, I am going to test with parallel_adaptive_multi_user=FALSE as
well.
On Fri, Jul 17, 2015 at 3:42 PM, Randolf Geist <
info@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Charles,
sorry for being late to the party, but it looks you hit a bug which Yasin
Baskan (Product Manager Parallel Execution at Oracle) described in the
comments of one my posts - it's a combination of Resource Manager and
PARALLEL_ADAPTIVE_MULTI_USER set to TRUE (which is default). Since you
constrain your CPU_COUNT you have to have Resource Manager active, so it's
pretty sure it's the bug you hit as it is related different loads mentioned
in the PX trace:
http://oracle-randolf.blogspot.com/2015/03/12c-parallel-execution-new-features.html?showComment=1425578464519#c4073220599704900139
The bug leads to unexpected downgrades, so that's what you seem to hit.
Setting PARALLEL_ADAPTIVE_MULTI_USER to FALSE works around the problem (and
is a good idea in most cases anyway).
Randolf
As mentioned before, this is a Sun T5440. So even though we have 256
"virtual" cpus, the database cpu_count is set to 3 for various reasons
--
//www.freelists.org/webpage/oracle-l
