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
Post a Comment