非索引列直方图的丢失导致sql性能急剧下降

[复制链接]
查看11 | 回复8 | 2011-2-18 11:43:34 | 显示全部楼层 |阅读模式
DB:10205
OS: AIX 5
症状:
SELECT
JUSTIN_PROJECT.PROJECT_NM,
Sum(LARGE_HOUSE.ACT_EFF_$)
FROM
JUSTIN_PROJECT,
LARGE_HOUSE,
(
SELECT DISTINCT EXTRACT_DT ,is_completed,IS_LATEST_EXTRACT_DT FROM ADMINISTRIOR
)ADMINISTRIOR,
HOUSE_TIME
WHERE
( ADMINISTRIOR.EXTRACT_DT=HOUSE_TIME.CALENDER_DT)
AND( LARGE_HOUSE.PROJECT_SK=JUSTIN_PROJECT.PROJECT_SK)
AND( HOUSE_TIME.CALENDER_DT=LARGE_HOUSE.AS_OF_DT)
AND
(
JUSTIN_PROJECT.PROJECT_NMIN( 'ABC')
AND
( ADMINISTRIOR.IS_LATEST_EXTRACT_DT=1)
)
GROUP BY
JUSTIN_PROJECT.PROJECT_NM
客户抱怨以上这条sql在pre-prod运行很快,但是在prod上则巨慢;
登陆数据库,首先查看执行计划,
--prod
--------------------------------------------------------------------------+-----------------------------------+-------------------------+---------------+
| Id| Operation
| Name
| Rows| Bytes | Cost| Time|TQ|IN-OUT|PQ Distrib | Pstart| Pstop |
--------------------------------------------------------------------------+-----------------------------------+-------------------------+---------------+
| 0 | SELECT STATEMENT
|
| | |5988 |
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 1 |HASH GROUP BY
|
| 1 |57 |5988 |00:02:48
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 2 | PX COORDINATOR
|
| | | |
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 3 |PX SEND QC (RANDOM)
| :TQ10001
| 14K |798K |5988 |00:02:48 |:Q1001| P->S |QC (RANDOM)| | |
| 4 | HASH JOIN
|
| 14K |798K |5988 |00:02:48 |:Q1001| PCWP | | | |
| 5 |BUFFER SORT
|
| | | | |:Q1001| PCWC | | | |
| 6 | PX RECEIVE
|
|12 | 120 | 6 |00:00:01 |:Q1001| PCWP | | | |
| 7 |PX SEND BROADCAST
| :TQ10000
|12 | 120 | 6 |00:00:01 || S->P |BROADCAST| | |
| 8 | VIEW
|
|12 | 120 | 6 |00:00:01
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 9 |
HASH UNIQUE
|
|12 | 168 | 6 |00:00:01
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 10| TABLE ACCESS FULL
| ADMINISTRIOR
|25 | 350 | 5 |00:00:01
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
| | |
| 11|NESTED LOOPS
|
|356K | 16M |5982 |00:02:48 |:Q1001| PCWP | | | |
| 12| NESTED LOOPS
|
|356K | 14M |5980 |00:02:48 |:Q1001| PCWP | | | |
| 13|PX BLOCK ITERATOR
|
| 8 | 184 |21 |00:00:01 |:Q1001| PCWC | | 1 | 1 |
| 14| TABLE ACCESS FULL
| JUSTIN_PROJECT| 8 | 184 |21 |00:00:01 |:Q1001| PCWP | | 1 | 1 |
| 15|PARTITION RANGE ALL
|
| 42K |676K | 32K |00:10:58 |:Q1001| PCWP | | 1 | 49|
| 16| TABLE ACCESS BY LOCAL INDEX ROWID | LARGE_HOUSE | 42K |676K | 32K |00:10:58 |:Q1001| PCWP | | 1 | 49|
| 17|
INDEX RANGE SCAN
| FACT_HOURSCURVES_IDX10| 42K | |99 |00:00:02 |:Q1001| PCWP | | 1 | 49|
| 18| INDEX UNIQUE SCAN
| HOUSE_TIME_CAL_DT | 1 | 8 | 0 | |:Q1001| PCWP | | | |
--------------------------------------------------------------------------+-----------------------------------+-------------------------+---------------+
Predicate Information:
----------------------
4 - access("ADMINISTRIOR"."EXTRACT_DT"="HOUSE_TIME"."CALENDER_DT")
10 - filter("IS_LATEST_EXTRACT_DT"=1)
14 - access(:Z>=:Z AND :Z select IS_LATEST_EXTRACT_DT,count(*) from ADMINISTRIOR group by IS_LATEST_EXTRACT_DT ;
IS_LATEST_EXTRACT_DT COUNT(*)
-------------------- ----------

1
1

0 48
Pre-prod该列收集有直方图而prod却没有,至此事情有了些许眉目:
在解析的时候ADMINISTRIOR.IS_LATEST_EXTRACT_DT=1被push到了前面的子查询中,
FPD: Considering simple filter push (pre rewrite) in SEL$2 (#0)
FPD: Current where clause predicates in SEL$2 (#0) :
"ADMINISTRIOR"."IS_LATEST_EXTRACT_DT"=1
Registered qb: SEL$1 0x10428b80 (COPY SEL$1)
pre-prod因为有了直方图且该列变量值为1,CBO解析时可以准确的预见该表只返回一行数据,而直方图的缺失让prod误以为该表要返回一半的数据,故在各表作join order的时候不能选择最优的方案,进而不能选择最高效的执行计划;
在prod上收集该列直方图
exec dbms_stats.gather_table_stats('OPAL_DW_ADMIN','ADMINISTRIOR',estimate_percent => 100, method_opt=>'FOR COLUMNS IS_LATEST_EXTRACT_DT SIZE 2');
硬解析后重新运行,此时选择了和pre-prod一样的执行计划;
将变量1替换成0,则重新选择了第一个比较差的执行计划;
小结: 直方图是反映数据分布情况的,一般来说,索引列直方图信息的丢失导致sql错误的选择全表扫描或索引扫描的案例比较常见;
但此表的相关列既没有索引(铁定要走全表扫描),且表只有49行,其直方图的缺失却能让一个sql选择逻辑读高出10几倍的执行计划,真是”差之毫厘,谬以千里”。


回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
本帖最后由 sundog315 于 2012-8-13 16:32 编辑
关联列是否有直方图也会影响到执行计划的效率,只不过一般情况下,关联列大都有索引,或者数据分布平均,所以这个问题显现不出来。
回复

使用道具 举报

千问 | 2011-2-18 11:43:34 | 显示全部楼层
本帖最后由 Yong Huang 于 2012-8-13 14:16 编辑
Thanks for the summary. Is there any root cause analysis as to why the histogram is missing in Prod?
I suggest you change ADMINISTRIOR to something else. It's a wrong spelling. But more importantly, the table name and the in-line view alias use the same name. Sometimes that will confuse the parser, or you.
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行