Re: Curiosity: single-column index on sparse data cannot be built in parallel

now I'm curious, too, because setting CPU_COUNT explicitly (Instance Caging) doesn't make a lot of sense if you don't enable Resource Manager, otherwise I don't think the CPU usage will actually be constrained.

See this document:

http://www.oracle.com/technetwork/database/performance/instance-caging-wp-166854.pdf

which also contains a couple of queries you could use to see if Resource Manager is active and throttles CPU in some way.

Note that if you have (default) maintenance windows defined in the Scheduler, then for the periods these windows are active the Resource Manager might become activated, which could confuse the issue even further (so depending on when you run your tests the Resource Manager might be temporarily enabled or not).

Randolf

Am 17.07.2015 um 22:59 schrieb Charles Schultz:
> 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_at_www.sqltools-plusplus.org <mailto:info_at_www.sqltools-plusplus.org>>
> 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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>
>
> --
> Charles Schultz

--
http://www.freelists.org/webpage/oracle-l