佳礼资讯网

 找回密码
 注册

ADVERTISEMENT

查看: 1401|回复: 10

oracle tuning performance 的问题, 高手请进...

[复制链接]
发表于 3-8-2005 01:00 PM | 显示全部楼层 |阅读模式
select         x.subs_no, x.subs_no_reset,
sum(NVL(x.total_mobile_bill,0)-nvl(y.exclude_total_mobile_bill,0)) as total_mobile_bill from
(select a.subs_no, a.subs_no_reset,
        sum(NVL(b.amount,0)) as total_mobile_bill
from         jeff_clv_live_02 a, bill_invoice_fact b
where         to_date(b.bill_stmt_date,'DD-MON-YY') between
        to_date(add_months((last_day(sysdate)+1),-7),'DD-MON-YY') and
        to_date(add_months((last_day(sysdate)),-6),'DD-MON-YY') and
        a.subs_no = b.subs_no and
        a.subs_no_reset = b.subs_no_reset
group by a.subs_no, a.subs_no_reset) x,
(select a.subs_no, a.subs_no_reset,
        sum(NVL(b.amount,0)) as exclude_total_mobile_bill
from         jeff_clv_live_02 a, bill_invoice_fact b
where         to_date(b.bill_stmt_date,'DD-MON-YY') between
        to_date(add_months((last_day(sysdate)+1),-7),'DD-MON-YY') and
        to_date(add_months((last_day(sysdate)),-6),'DD-MON-YY') and
        a.subs_no = b.subs_no and
        a.subs_no_reset = b.subs_no_reset and
        (b.charge_type in (6) or
        (b.charge_type = 4 and subtype_code in
        (1220, 1221, 1230, 1231, 1290, 3111, 3112, 3121, 3122, 3130,
         1241, 1251)) )
group by a.subs_no, a.subs_no_reset) y
where         x.subs_no = y.subs_no (+) and
        x.subs_no_reset = y.subs_no_reset (+)
        group by x.subs_no, x.subs_no_reset

如果:
jeff_clv_live_02 有 1 million records,
bill_invoice_fact有 1 million records.

当我RUN以上的QUERY时,需时间11小时....

有什么办法 improve performance???
救救我.....

[ 本帖最后由 Barry0510 于 3-8-2005 01:05 PM 编辑 ]
回复

使用道具 举报


ADVERTISEMENT

发表于 3-8-2005 04:27 PM | 显示全部楼层
通常我会先把几个主要的 Select 在 filter 后丢进 Temp table 里面,然后才做比较复杂的计算和比较。把所有的 selections 和 conditions 用单一的 sql statement 来做会比较慢,尤其读取资料很多的 table 时。
回复

使用道具 举报

发表于 9-8-2005 09:23 AM | 显示全部楼层
建议你用create view combine inner 的 sql statement。哪么不用select 这么多 table。
回复

使用道具 举报

发表于 10-8-2005 12:32 AM | 显示全部楼层
用几个上 million records 的tables做成view也未必可以improve performance的,有是反而会更慢。。
而且,这两个tables的data会一直增加吧??
以后如果data增加到一定程度的时候再run这个view就很可能会干掉你的server了。。
回复

使用道具 举报

 楼主| 发表于 10-8-2005 12:09 PM | 显示全部楼层
原帖由 max^^ 于 10-8-2005 12:32 AM 发表
用几个上 million records 的tables做成view也未必可以improve performance的,有是反而会更慢。。
而且,这两个tables的data会一直增加吧??
以后如果data增加到一定程度的时候再run这个view就很可能会干掉你 ...


大哥,你说的对..真的会更慢...
没办法了......叹气.................
回复

使用道具 举报

发表于 21-10-2005 11:22 PM | 显示全部楼层
问题主要不在table rows 的多寡 (1 mil join 1 mil 对Oracle来说不算什么)。
而是你的query有没有善用indexes和避免full table scan。用Toad查一查query的bottleneck。

那些inner subquery的where condition尽量不要用function或derivative在左半部,这样会disable index lookup.
回复

使用道具 举报

Follow Us
发表于 22-10-2005 02:29 AM | 显示全部楼层
先声明我只会M$ SQL, 不会Oracle


我觉得你的Query的bottleneck是在这里,

to_date(b.bill_stmt_date,'DD-MON-YY') between
        to_date(add_months((last_day(sysdate)+1),-7),'DD-MON-YY') and
        to_date(add_months((last_day(sysdate)),-6),'DD-MON-YY')


我用M$ SQL 的Query来做例子,
a) Query A

select * from tbSomeTable
     Where TxnDate between DateAdd(month, -7, GetDate())
           and DateAdd(month, -6, GetDate())
   

b) Query B

declare @StartDate DateTime
declare @EndDate  DateTime

set @StartDate = DateAdd(month, -7, GetDate())
set @EndDate = DateAdd(month, -6, GetDate())

select * from tbSomeTable
     Where TxnDate between @StartDate and @EndDate   


如果你有一个大的table, Query B 会比Query A快非常多。


还有一点,为什么要不停的convert date format (DD-DOM-YY)呢?
Oracle不能象M$ SQL这样直接compare date的吗?
回复

使用道具 举报

dida_ 该用户已被删除
发表于 1-11-2005 10:53 PM | 显示全部楼层
可能是INDEX 的问题。可以看看ORACLE INDEX TUNING WIZARD(WINDOWS PLATFORM的)
上次有个人做了一个PROCEDURE,要拿6个钟头来跑,当APPLY了INDEX TUNING WIZARD 的建议的INDEX后,竟然缩短到3分钟就搞定了。。。。
回复

使用道具 举报


ADVERTISEMENT

 楼主| 发表于 2-11-2005 03:15 PM | 显示全部楼层
dida_ :
那使什么来的??能不能教教我???
回复

使用道具 举报

dida_ 该用户已被删除
发表于 13-3-2006 12:20 AM | 显示全部楼层
原帖由 Barry0510 于 2-11-2005 03:15 PM 发表
dida_ :
那使什么来的??能不能教教我???


http://www.oracle.com/technology ... g/tuning/tuning.htm


http://www.lc.leidenuniv.nl/awco ... /a86647/indxtun.htm
回复

使用道具 举报

发表于 1-12-2006 05:05 PM | 显示全部楼层

回复 #10 dida_ 的帖子

在处理 SQL tuning 的问题, 最应该看的是 execution plan. 如 dida_ 的帖子.
如有full table scan 或 索引用错, execution plan 会指出问题所在.
回复

使用道具 举报

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

本版积分规则

 

ADVERTISEMENT



ADVERTISEMENT



ADVERTISEMENT

ADVERTISEMENT


版权所有 © 1996-2023 Cari Internet Sdn Bhd (483575-W)|IPSERVERONE 提供云主机|广告刊登|关于我们|私隐权|免控|投诉|联络|脸书|佳礼资讯网

GMT+8, 12-11-2024 10:58 AM , Processed in 0.122049 second(s), 25 queries , Gzip On.

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表