cardinality feedback used for this statement
Posted by wukaiqiang; tagged with none
Plan hash value: 2490995645
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 465K(100)| |
| 1 | SORT AGGREGATE | | 1 | 38 | | |
| 2 | NESTED LOOPS OUTER| | 51621 | 1915K| 465K (1)| 01:33:05 |
|* 3 | TABLE ACCESS FULL| BYDD9WMS_PRINT_DATA | 51621 | 1058K| 465K (1)| 01:33:02 |
|* 4 | INDEX UNIQUE SCAN| UK_PO_DATA | 1 | 17 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("AA"."CODE_DATE" IS NULL AND "AA"."DATECODE" IS NOT NULL AND
NVL("AA"."UPDATE_NAME",'X')<>'UPCD2303210001'))
4 - access("PD"."PO"="AA"."PO" AND "PD"."LINE"="AA"."LINE")
Note
-----
- cardinality feedback used for this statement
查看执行计划发现:cardinality feedback used for this statement
11g之后的新特性, 如果cbo发现e_row和a_row的差距过多, 认为执行计划不准确,则重新生成执行计划。
检查发现对应的表的统计信息,上次分析是3年前,说明上次导入之后,连带统计信息也被导入,到目前为止,更新的次数不超过原来的10%,所以一直未更新。
所以可以在业务空闲时间重新收集统计信息,但是目前等待事件为全表扫描的io,cpu资源空闲较多,所以重新收集统计信息也无用,需要sql优化,减少全表扫描次数。才会有明显改善,检查业务逻辑发现,该动作是对一张800万的表进行全表扫描,可以预见,未来随着业务的增长,该语句的性能会越来越低,最终将无法执行下去,可能的措施是归档历史数据,或者改变表结构为分区表。减少查询扫描的范围。