如何解决不同SQL之间的性能冲突？

olive

在没有analyze的情况下，前一个（调整了FROM中的table和条件的顺序那个）可以出结果，可以很明显地看到结果集是一部分一部分跳出来的（当tacct.body_nb有较大的变化，比如从2186985跳到2304287，就有较长时间的停顿），总共429条结果，用时1分55秒。这个结果比起analyze后的时间虽然还是有比较大的距离(analyze后的执行时间为6.2秒），但是毕竟已经有了很大的提高！
server是我一个人独占所以上述时间应该是准确的。
带有hint的那个依然最终引起temp溢出。
另外我的sqlplus没有autotrace这个set参数。我的oracle是7.3.4。
深受鼓舞！
我想等最后的优化完成以后（现在还不算最后完成吧，呵呵），斑竹可以做一下总结，说明为什么要这样调整，然后可以作为一个很好的performance tuning的范例！如果需要我做进一步的实验或需要更多的关于这个查询以及相关数据表的介绍，我会尽力提供。希望大家都能从中学到东西。

olive

我已经下载了sql expert，但是还没有开始试验，我将按照你提示的策略作相应试验，结果我也会贴出来，不过那个时间我估计不会设60分钟，而是3分钟，因为前面斑竹的调整结果已经使运行时间在没有analyze的前提下降低为2分钟了，我相信一定还有更快的结果。只是这个select涉及到七个表，又有那么多条件，排列组合的结果可能是个天文数字...
我目前只能针对这个select做优化，我说的form是最终用户的界面，那是个庞大的应用系统，涉及到几百个form以及许多程序，之间互相调用，我不想去动它了。而这个report是我们开发的specific development，可以深入研究的。

parrotao

我用的也是7.3.4
只要建立一个
create table PLAN_TABLE (
        statement_id    varchar2(30),
        timestamp       date,
        remarks         varchar2(80),
        operation       varchar2(30),
        options         varchar2(30),
        object_node     varchar2(128),
        object_owner    varchar2(30),
        object_name     varchar2(30),
        object_instance numeric,
        object_type     varchar2(30),
        optimizer       varchar2(255),
        search_columns  numeric,
        id              numeric,
        parent_id       numeric,
        position        numeric,
        cost            numeric,
        cardinality     numeric,
        bytes           numeric,
        other_tag       varchar2(255),
        other           long);
就可以用
autotrace了


如果是OLTP的话还是太慢了.

olive

要知道这只是对一个batch，其中的主要SELECT的运行时间，因为按照analyze之后运行6.2秒的结果，整个程序要运行28分钟，那如果是2分钟，整个程序运行的时间就差不多要10个小时。虽然这个report不是OLTP，但是10个小时还是太久了。所以还是需要进一步优化，但看来目前已经有曙光了。能不能从index的角度考虑呢？建一些针对这个select的index。
关于autotrace，是直接在sqlplus下输入set autotrace on吗？因为我这样做，它说unknown set option "autotrace"，建了plan_table表就可以用了？

parrotao

有结果吗?

olive

我这两天在忙别的，分不出时间。昨天那个程序又正式运行了，用了29分钟（先加上analyze运行完再删掉），我这两天先这样对付。
不知道我最后调整的结果（不用analyze）能不能达到这个效果。
我星期三开始对这个SELECT做全面测试，有什么结果我一定详细汇报。
关于autotrace我上面说的对吗？我也暂时没有时间去试。
给我点时间，给我点时间...
我这里类似的例子还有很多，如果大家有兴趣，我可以逐一为大家贴上来供大家研究，都是真实的例子，曾经搞得我很头痛，现在我已经学会了一些方法，我要开始重新对付他们，有一种跃跃欲试的感觉，呵呵...但是我一定要先把手头别的事情处理完才行。

parrotao

好运

dblife

这个问题我也碰到了
A表记录数目1000多万，原来建立了UNIQUE INDEX，SELECT * FROM A WHERE ....是走索引的
后面ANALYZE TABLE A COMPUTE STATISTICS FOR ALL INDEXES之后，就开始TABLE ACESS FULL了，ANALYZE TABLE DELETE STATISTICS之后，ANALYZE TABLE ESTAMITE也不行了。
加上/*+INDEX(A INDEX_NAME)*/也不行了，还是ACCESS FULL
我晕
看了PARROTAO给的连接 http://metalink.oracle.com/metal ... &p_id=84969.996
有点不知所措了，现在正在从新建立索引，巨慢无比。哎，有点不知所措了，看来以后分析也要小心再小心。

olive

好像你知道我在忙什么？

lunar2000

最初由 parrotao 发布
[B]好运 [/B]

呵呵，是的，ANALYZE在使用时是该慎重的，要不回适得其反的，呵呵