以下语句执行计划有问题吗?有优化的余地吗?谢谢!

[复制链接]
查看11 | 回复9 | 2014-7-11 07:56:59 | 显示全部楼层 |阅读模式
SQL> select* from idep_alarm_list a; --这个是视图,视图语句见附录
112767 rows selected.
Execution Plan
----------------------------------------------------------
0SELECT STATEMENT Optimizer=CHOOSE (Cost=3702 Card=96580 Byte

s=420895640)
10 VIEW OF 'IDEP_ALARM_LIST' (Cost=3702 Card=96580 Bytes=4208

95640)
21 SORT (UNIQUE) (Cost=3702 Card=96580 Bytes=20441872)
32 UNION-ALL
43 HASH JOIN (Cost=565 Card=89619 Bytes=19536942)
54 TABLE ACCESS (FULL) OF 'IDEP_ALERT_LOG_CONFIG' (Co

st=2 Card=31 Bytes=2201)
64 HASH JOIN (Cost=561 Card=89619 Bytes=13173993)
76
TABLE ACCESS (FULL) OF 'IDEP_SCHEDULE' (Cost=2 C

ard=117 Bytes=1755)
86
HASH JOIN (Cost=557 Card=89626 Bytes=11830632)
98
TABLE ACCESS (FULL) OF 'IDEP_WORKITEM' (Cost=2
Card=18 Bytes=126)
108
HASH JOIN (Cost=553 Card=89626 Bytes=11203250)
11 10
HASH JOIN (Cost=258 Card=78782 Bytes=5199612

)
12 11
HASH JOIN (Cost=131 Card=67080 Bytes=18111

60)
13 12
TABLE ACCESS (FULL) OF 'IDEP_TASK_LOG' (

Cost=42 Card=67084 Bytes=670840)
14 12
TABLE ACCESS (FULL) OF 'IDEP_FLOW' (Cost

=38 Card=64224 Bytes=1091808)
15 11
VIEW (Cost=26 Card=78787 Bytes=3072693)
16 15
SORT (GROUP BY) (Cost=26 Card=78787 Byte

s=945444)
17 16
INDEX (FULL SCAN) OF 'UNION_IDX' (NON-

UNIQUE) (Cost=26 Card=79689 Bytes=956268)
18 10
TABLE ACCESS (FULL) OF 'IDEP_ALERT_LOG' (Cos

t=96 Card=97454 Bytes=5749786)
193 NESTED LOOPS (Cost=97 Card=6961 Bytes=904930)
20 19 TABLE ACCESS (BY INDEX ROWID) OF 'IDEP_ALERT_LOG_C

ONFIG' (Cost=1 Card=1 Bytes=71)
21 20
INDEX (UNIQUE SCAN) OF 'PK_IDEP_ALERT_LOG_CONFIG

' (UNIQUE)
22 19 TABLE ACCESS (FULL) OF 'IDEP_ALERT_LOG' (Cost=96 C

ard=6961 Bytes=410699)
Statistics
----------------------------------------------------------
225613recursive calls
10db block gets
1583117consistent gets
4778physical reads

0redo size
5874248bytes sent via SQL*Net to client
83342bytes received via SQL*Net from client
7519SQL*Net roundtrips to/from client

0sorts (memory)

2sorts (disk)
112767rows processed



由于语句太复杂了,我做了全分析
analyze table idep_alert_logcompute statistics for table for all indexes for all indexed columns;
analyze table idep_workitem_log compute statistics for table for all indexes for all indexed columns;
analyze table IDEP_TASK_LOG compute statistics for table for all indexes for all indexed columns;
analyze table idep_flow
compute statistics for table for all indexes for all indexed columns;
analyze table idep_schedule compute statistics for table for all indexes for all indexed columns;
analyze table IDEP_ALERT_LOG_CONFIG compute statistics for table for all indexes for all indexed columns;
analyze table idep_workitem compute statistics for table for all indexes for all indexed columns;

也做了全部CACHE进内存的动作
alter indexUNION_IDX storage(buffer_pool keep);
alter tableidep_alert_log storage(buffer_pool keep);
alter tableidep_workitem_log storage(buffer_pool keep);
alter tableIDEP_TASK_LOGstorage(buffer_pool keep);
alter tableidep_flow storage(buffer_pool keep);
alter tableidep_schedule storage(buffer_pool keep);
alter tableIDEP_ALERT_LOG_CONFIG storage(buffer_pool keep);
alter tableidep_workitem storage(buffer_pool keep);
alter indexPK_IDEP_ALERT_LOG_CONFIG storage(buffer_pool keep);

此外记录数也都不大
SQL> select count(*) from idep_alert_log;
COUNT(*)
----------
134997
SQL> select count(*) from idep_workitem_log;
COUNT(*)
----------
114817
SQL> select count(*) fromIDEP_TASK_LOG ;
COUNT(*)
----------
105473
SQL> select count(*) fromidep_flow
;
COUNT(*)
----------
103009
SQL> select count(*) from idep_schedule;
COUNT(*)
----------
163
SQL> select count(*) from IDEP_ALERT_LOG_CONFIG ;
COUNT(*)
----------
32
SQL> select count(*) fromidep_workitem ;
COUNT(*)
----------
18

附:
试图写法
select e.sched_name,
e.sched_id,
d.flow_inst_id,
d.start_time,
g.workitem_mod_id,
a.log_code alarm_type,
f.message alarm_type_name,
f.alert_level,
get_domainlabel('DOMAIN_ALARM_LEVEL', f.alert_level, '无') alert_level_name,
f.action,
a.generate_time,
a.message
from idep_alert_log a,
(select max(workitem_inst_id) workitem_inst_id,

max(TASK_INST_ID) TASK_INST_ID,

max(WORKITEM_ID) WORKITEM_ID

from idep_workitem_log
group by workitem_inst_id) b,
IDEP_TASK_LOG c,
idep_flow d,
idep_schedule e,
IDEP_ALERT_LOG_CONFIG f,
idep_workitem g
where a.workitem_inst_id = b.workitem_inst_id
and a.log_code = f.log_code
and b.TASK_INST_ID = c.TASK_INST_ID
and c.flow_inst_id = d.flow_inst_id
and d.sched_id = e.sched_id
and b.workitem_id = g.workitem_id
and a.log_code0
union
select '生命周期检查' sched_name,a.log_id sched_id,'999'+a.log_id flow_inst_id,a.generate_time start_time,
9 workitem_mod_id,a.log_code alarm_type,f.message alarm_type_name,
f.alert_level,get_domainlabel('DOMAIN_ALARM_LEVEL', f.alert_level, '无') alert_level_name,f.action,
a.generate_time,
a.message from idep_alert_log a,IDEP_ALERT_LOG_CONFIG f
where a.log_code=f.log_code anda.log_code=37
[ 本帖最后由 wabjtam123 于 2009-9-17 18:46 编辑 ]
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
版本可能偏低了一点
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.2.0 - 64bit Production
PL/SQL Release 9.2.0.2.0 - Production
CORE
9.2.0.2.0
Production
TNS for HPUX: Version 9.2.0.2.0 - Production
NLSRTL Version 9.2.0.2.0 - Production
SQL>
SQL> show parameter sga
NAME
TYPEVALUE
------------------------------------ ----------- ------------------------------
lock_sga
boolean FALSE
pre_page_sga
boolean FALSE
sga_max_size
big integer 3223278552
SQL> show parameter share
NAME
TYPEVALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address
integer 0
max_shared_servers
integer 20
shared_memory_address
integer 0
shared_pool_reserved_size
big integer 10066329
shared_pool_size
big integer 201326592
shared_server_sessions
integer 165
shared_servers
integer 1
SQL> show parameter cache
NAME
TYPEVALUE
------------------------------------ ----------- ------------------------------
db_16k_cache_size
big integer 0
db_2k_cache_size
big integer 0
db_32k_cache_size
big integer 0
db_4k_cache_size
big integer 0
db_8k_cache_size
big integer 0
db_cache_advice
stringON
db_cache_size
big integer 1006632960
db_keep_cache_size
big integer 234881024
db_recycle_cache_size
big integer 0
object_cache_max_size_percentinteger 10
object_cache_optimal_size
integer 102400
NAME
TYPEVALUE
------------------------------------ ----------- ------------------------------
session_cached_cursors
integer 0
SQL>
机器machinfo的信息
CPU info:
2 Intel(R) Itanium 2 9100 series processors (1.59 GHz, 18 MB)

532 MT/s bus, CPU version A1

4 logical processors (2 per socket)
Memory: 16353 MB (15.97 GB)
大家看看,我们这样的主机(主机很闲)和数据库的配置,处理上面的数据量不大的SQL查询(无非是7表关联),要耗时1分钟多,合理吗?
数据库中也做了CACHE,也做了表索引的分析了,该有的索引都有建了,怎么还能这样慢呢?
太不合理了!
[ 本帖最后由 wabjtam123 于 2009-9-17 19:38 编辑 ]
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
业务需求是怎么样的。 耗时一份钟关键是在你的业务。
看到有几个全表扫挺高的。呵呵
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
业务是否允许UNION 换成UNION ALL
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
idep_alert_log .log_code没有index....
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
应该还能再改进下你的执行计划看起好费劲哦我汗~
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
可以尝试下分离sql 建立几个视图 再通过视图来进行总体获取,性能会有较大的提升。
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
没见过这么头疼的,我现在几乎所有的关联处都建立了索引
SQL> create index idx_log_codeon idep_alert_log(log_code) nologging;
Index created
SQL> create index idx_workitem_inst_id on idep_alert_log(workitem_inst_id) nologging;
Index created
SQL>create indexidx_idep_workitem_log_inst on idep_workitem_log(workitem_inst_id) nologging;
Index created
SQL>create index idx_sche_id on idep_flow(sched_id) nologging;
Index created
SQL>create index idx_wokitem_id onidep_workitem_log(workitem_id) nologging;
Index created
然后再全分析一次
SQL> analyze table idep_alert_logcompute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table idep_workitem_log compute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table IDEP_TASK_LOG compute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table idep_flow
compute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table idep_schedule compute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table IDEP_ALERT_LOG_CONFIG compute statistics for table for all indexes for all indexed columns;
Table analyzed
SQL> analyze table idep_workitem compute statistics for table for all indexes for all indexed columns;
Table analyzed
还是老样子,好像还比以前更慢了,该全表扫描的还在全表扫描,ORACLE认定是全表效率更高了。

SQL> explain plan for
2select* from idep_alarm_list a;
Explained
SQL> select *from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
| Id| Operation
|Name
| Rows| By
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
|
| 482K|2
| 1 |VIEW
| IDEP_ALARM_LIST | 482K|2
| 2 | SORT UNIQUE
|
| 482K|
| 3 |UNION-ALL
|
| |
|*4 | HASH JOIN
|
| 463K|
| 5 |TABLE ACCESS FULL
| IDEP_SCHEDULE
| 163 |2
|*6 |HASH JOIN
|
| 463K|
| 7 | TABLE ACCESS FULL | IDEP_FLOW
| 149K|2
|*8 | HASH JOIN
|
| 463K|
| 9 |TABLE ACCESS FULL| IDEP_TASK_LOG
| 152K|1
|* 10 |HASH JOIN
|
| 463K|
|* 11 | TABLE ACCESS FULL | IDEP_ALERT_LOG_CONFIG |31 |2
|* 12 | HASH JOIN
|
| 463K|
|* 13 |
HASH JOIN
|
| 158K|6
|14 | TABLE ACCESS FULL | IDEP_WORKITEM
|18 |
|15 | VIEW
|
| 158K|6
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
|16 |
SORT GROUP BY|
| 158K|1
|17 |
INDEX FAST FULL SCAN| UNION_IDX
| 161K|1
|* 18 |
TABLE ACCESS FULL| IDEP_ALERT_LOG
| 139K|7
|19 | NESTED LOOPS
|
| 18924 |2
|20 |TABLE ACCESS BY INDEX ROWID| IDEP_ALERT_LOG_CONFIG | 1 |
|* 21 | INDEX UNIQUE SCAN | PK_IDEP_ALERT_LOG_CONFIG|32 |
|* 22 |TABLE ACCESS FULL
| IDEP_ALERT_LOG
| 18924 |1
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("D"."SCHED_ID"="E"."SCHED_ID")
6 - access("C"."FLOW_INST_ID"="D"."FLOW_INST_ID")
8 - access("B"."TASK_INST_ID"="C"."TASK_INST_ID")
10 - access("A"."LOG_CODE"="F"."LOG_CODE")
11 - filter("F"."LOG_CODE"0)
12 - access("A"."WORKITEM_INST_ID"="B"."WORKITEM_INST_ID")
13 - access("B"."WORKITEM_ID"="G"."WORKITEM_ID")
18 - filter("A"."LOG_CODE"0)
21 - access("F"."LOG_CODE"=37)
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
22 - filter("A"."LOG_CODE"=37)
Note: cpu costing is off
44 rows selected
[ 本帖最后由 wabjtam123 于 2009-9-18 08:23 编辑 ]
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
今天怪了,半天出不来,等待事件如下,出现4个
EVENT
P1TEXT

---------------------------------------------------------------- ----------------------
null event

PX qref latch
function

PX qref latch
function

PX Deq: Table Q Normal
sleeptime/senderid
回复

使用道具 举报

千问 | 2014-7-11 07:56:59 | 显示全部楼层
机器的SGA等参数给的太小,内存那么大,才给分这么点
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行