ITPub博客

首页 > 数据库 > 数据库开发技术 > Bug 9290526 - Poor plan for recursive SQL used for DML involving a UNIQUE constraint [ID 9290526.8]

Bug 9290526 - Poor plan for recursive SQL used for DML involving a UNIQUE constraint [ID 9290526.8]

原创 数据库开发技术 作者:shiri512003 时间:2012-05-08 19:18:58 0 删除 编辑
[@more@]

A suboptimal plan may be seen for the specific recursive SQL:
select c.name, u.name
from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled =:1 and
c.owner# = u.user#;

This can cause inserts involving a unique constraint to show poor performance.

Workaround
Set optimizer_mode=rule for the affected DMLs.

https://supporthtml.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?_afrLoop=2093761045238000&type=DOCUMENT&id=9290526.8&displayIndex=2&_afrWindowMode=0&_adf.ctrl-state=8wo4jycn3_44

sys@test>explain plan for
2 select c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# =
3 cd.con# and cd.enabled = :v1 and c.owner# = u.user#;

Explained.

sys@test>@plan

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2222027377

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 7 | 336 | 10 (10)| 00:00:01 |
|* 1 | HASH JOIN | | 7 | 336 | 10 (10)| 00:00:01 |
|* 2 | HASH JOIN | | 7 | 203 | 8 (13)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| CDEF$ | 7 | 56 | 2 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | I_CDEF4 | 1 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL | CON$ | 3584 | 75264 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS FULL | USER$ | 33 | 627 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("C"."OWNER#"="U"."USER#")
2 - access("C"."CON#"="CD"."CON#")
4 - access("CD"."ENABLED"=TO_NUMBER(:V1))

20 rows selected.

sys@test>explain plan for
2 select /*+ rule */ c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :v1 and c.owner# = u.user#;

Explained.

sys@test>@plan

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1027684349

-------------------------------------------------
| Id | Operation | Name |
-------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | NESTED LOOPS | |
| 2 | NESTED LOOPS | |
| 3 | TABLE ACCESS BY INDEX ROWID| CDEF$ |
|* 4 | INDEX RANGE SCAN | I_CDEF4 |
| 5 | TABLE ACCESS BY INDEX ROWID| CON$ |
|* 6 | INDEX UNIQUE SCAN | I_CON2 |
| 7 | TABLE ACCESS CLUSTER | USER$ |
|* 8 | INDEX UNIQUE SCAN | I_USER# |
-------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

4 - access("CD"."ENABLED"=TO_NUMBER(:V1))
6 - access("C"."CON#"="CD"."CON#")
8 - access("C"."OWNER#"="U"."USER#")

Note
-----
- rule based optimizer used (consider using cbo)

26 rows selected.

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/7591490/viewspace-1058153/ ,如需转载,请注明出处,否则将追究法律责任。

上一篇: softer soft parse
下一篇: 预警的些想法
请登录后发表评论 登录
全部评论

注册时间:2009-02-20

  • 博文量
    86
  • 访问量
    320272