SQL执行计划问题请教

[复制链接]
查看11 | 回复9 | 2010-10-8 09:32:27 | 显示全部楼层 |阅读模式
请教一个关于执行计划的问题
发现awr报告中这条语句比较消耗资源,逻辑读也比较高。看了一下执行计划成本也不高,查询时间也不长。这是什么情况呢?谢谢
Buffer Gets
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
第五步应该是你的瓶颈,统计信息是否准确?
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
ahf000 发表于 2012-1-1 12:27
第五步应该是你的瓶颈,统计信息是否准确?

我也看了
OWNERTABLE_NAME
COLUMN_NAME
DATA_TYPETOTAL_NUMS DISTINCT_NUMSNUM_NULLS LAST_ANALYZED
---------- ------------------------- ------------------------- ---------- ---------- ------------- ---------- -------------------
UCR_ACT1 TF_B_PAYLOG
ACCT_ID
NUMBER 53092880 4360485
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
ACTION_CODE
NUMBER 53092880 312 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
ACTION_EVENT_ID NUMBER 53092880253652 49453170 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
ACT_TAG
CHAR 53092880
1
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_CHARGE_ID
NUMBER 53092880897530 52195350 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_CITY_CODE
CHAR 53092880
32 51301770 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_DEPART_ID
CHAR 53092880 676 51301770 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_EPARCHY_CODE CHAR 53092880
2 51301770 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_STAFF_ID CHAR 53092880
1969 51301770 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_TAG
CHAR 53092880
3
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CANCEL_TIME
DATE 53092880 1468632 51301770 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CHANNEL_ID
VARCHAR2 53092880
15
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CHARGE_ID
NUMBER 5309288053092880
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CITY_CODE
CHAR 53092880
31
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
CUST_ID
NUMBER 53092880 3652988
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
EPARCHY_CODE
CHAR 53092880
1
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
EXTEND_TAG
CHAR 53092880
2
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
INPUT_MODE
NUMBER 53092880
1 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
INPUT_NO
VARCHAR2 53092880
0 53092880 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
LIMIT_MONEY
NUMBER 53092880
34
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
NET_TYPE_CODE
VARCHAR2 53092880
26
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
OUTER_TRADE_ID
VARCHAR2 53092880 3275750 46583950 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PARTITION_ID
NUMBER 53092880
11
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PAYMENT_ID
NUMBER 53092880 298
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PAYMENT_OP
NUMBER 53092880
5
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PAYMENT_REASON_CODE NUMBER 53092880
6 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PAYMENT_RULE_ID NUMBER 53092880
2 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
PAY_FEE_MODE_CODE NUMBER 53092880
5
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_CITY_CODE
CHAR 53092880
35
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_DEPART_ID
CHAR 53092880
2362
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_EPARCHY_CODE CHAR 53092880
2
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_FEE
NUMBER 53092880 60135
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_STAFF_ID
CHAR 53092880
5687
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RECV_TIME
DATE 53092880 6844735
0 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
REMARK
VARCHAR2 53092880
3923 43788330 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RSRV_FEE1
NUMBER 53092880
1 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RSRV_FEE2
NUMBER 53092880
1 143510 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
RSRV_INFO1
VARCHAR2 53092880133330 52959130 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
SERIAL_NUMBER
VARCHAR2 53092880 4688663 700780 2011-12-19 23:42:38
UCR_ACT1 TF_B_PAYLOG
USER_ID
NUMBER 53092880 4712303 700780 2011-12-19 23:42:38
但是这个数据库是自动统计
select count(*) from UCR_ACT1.tf_b_paylog;
COUNT(*)
----------
55782719
增加260多万数据不知道会不会有影响
可是执行计划怎么看不出什么地方不好
难道就是没统计不准确了?
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
260w不会有那么大的影响,你这个sql每次执行大概返回多少条记录,感觉sql的执行计划应该不正确
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
ahf000 发表于 2012-1-1 14:03
260w不会有那么大的影响,你这个sql每次执行大概返回多少条记录,感觉sql的执行计划应该不正确

我这样看了一下语句但是报个绑定变量错误,还怎么看返回记录数。
我也觉得是执行计划有问题,因为awr中逻辑读很高,执行计划不准确是因为统计时间比较早了吗,
上边统计时间是12月19日。
set autotrace traceonly
SP2-0552: Bind variable "VEND_RECV_TIME" not declared.
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
SQL?
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
zhending2000 发表于 2012-1-1 14:46
SQL?

SQL> SELECT to_char(a.charge_id) charge_id,
2a.partition_id, a.eparchy_code, a.city_code, to_char(a.cust_id) cust_id,
3to_char(a.user_id) user_id, a.serial_number, a.net_type_code,
4to_char(a.acct_id) acct_id, a.channel_id, a.payment_id,
5a.pay_fee_mode_code, a.payment_op, to_char(a.recv_fee) recv_fee,
6to_char(a.limit_money) limit_money, to_char(a.recv_time, 'yyyy-mm-dd hh24:mi:ss') recv_time,
7a.recv_eparchy_code, a.recv_city_code, a.recv_depart_id, a.recv_staff_id,
8a.payment_reason_code, a.input_no, a.input_mode, a.outer_trade_id, a.act_tag,
9a.extend_tag, a.action_code, to_char(a.action_event_id) action_event_id,
10a.payment_rule_id, a.remark, a.cancel_tag, a.cancel_staff_id, a.cancel_depart_id,
11a.cancel_city_code, a.cancel_eparchy_code,
12to_char(a.cancel_time, 'yyyy-mm-dd hh24:mi:ss') cancel_time,
13to_char(a.cancel_charge_id) cancel_charge_id, to_char(a.rsrv_fee1) rsrv_fee1,
14to_char(a.rsrv_fee2) rsrv_fee2, a.rsrv_info1, b.payment, c.action_name
15 FROM UCR_ACT1.tf_b_paylog a,UCR_PARAM.td_b_payment b, UCR_PARAM.td_b_discnt_action c
16
WHERE a.partition_id >=:VBEGIN_PARTITION_ID
17
AND a.partition_id =TO_DATE(:VBEGIN_RECV_TIME, 'YYYY-MM-DD HH24:MI:SS')
20
AND a.recv_time+0<=TO_DATE(:VEND_RECV_TIME, 'YYYY-MM-DD HH24:MI:SS')
21
AND a.action_code=c.action_code(+)
22
AND a.payment_id=b.payment_id(+);
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
加我qq,帮你看
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
索引没建对
回复

使用道具 举报

千问 | 2010-10-8 09:32:27 | 显示全部楼层
执行计划是怎么取的?
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行