Oracle slow query performance with PARALLEL optimization plan -


i have simple query

select     table     b = 'x' 

explain plan looks like

|

   0 | select statement        |                             |     2 |    16 |     4   (0)| 00:00:01 |        |      |            |  |   1 |  px coordinator         |                             |       |       |            |          |        |      |            |  |   2 |   px send qc (random)   | :tq10000                    |     2 |    16 |     4   (0)| 00:00:01 |  q1,00 | p->s | qc (rand)  |  |   3 |    px block iterator    |                             |     2 |    16 |     4   (0)| 00:00:01 |  q1,00 | pcwc |            |  |*  4 |     index fast full scan| table_unique_roles_key1     |     2 |    16 |     4   (0)| 00:00:01 |  q1,00 | pcwp |            | 

it appears me oracle tries run parallel execution plan. not have understanding why it. slows down query

and if do

select /*+ no_parallel */             table         b = 'x' 

it works fast, , plan is:

---------------------------------------------------------------------------------------------------- | id  | operation            | name                        | rows  | bytes | cost (%cpu)| time     | ---------------------------------------------------------------------------------------------------- |   0 | select statement     |                             |     2 |    16 |     4   (0)| 00:00:01 |  |*  1 |  index fast full scan| table_unique_roles_key1     |     2 |    16 |     4   (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- 

what causes parallelism in first scenario?

the degree on table set 1 degree on table_unique_roles_key1 (and other indexes on table) set 4. don't have privileges query v$parameter can't see how parallelism configured database.

table_unique_roles_key1 covering index query-- defined on columns (a, b, c, d) a column i'm selecting, b column i'm filtering on , c , d not involved in query.

the immediate cause has told oracle should use parallel query (the degree indexes has been set 4). tends make optimizer think full scanning index in parallel relatively cheap why optimizer picking plan.

you can change parallel setting on index

alter index table_unique_roles_key1 noparallel 

which should stop optimizer choosing plan (you may have set other indexes noparallel prevent optimizer picking different index full scan in parallel). i'd hesitate until understood person or process set degree on indexes 4-- if don't understand root cause, it's you'll end either breaking else or in endless battle person/ process sets indexes use parallelism , set them back.

the 2 candidates caused indexes have degree of 4 (either developer or dba) trying parallel query kick in other query or dba running (almost unnecessary) script periodically rebuilds indexes in parallel without realizing changes degree setting on index , makes parallel query kicks in. need have chat other developers and/or other dbas figure out whether setting index noparallel negatively affect them , whether there other processes changing setting on you.


Comments

Popular posts from this blog

c++ - Difference between pre and post decrement in recursive function argument -

php - Nothing but 'run(); ' when browsing to my local project, how do I fix this? -

php - How can I echo out this array? -