存储过程的效率问题！！（今晚在线等）

biti_rainy

!

jlandzpa

已经有了

最初由 biti_rainy 发布
[B]SQL> alter system set timed_statistics        = true;

System altered.

SQL> [/B]

biti_rainy

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse      149      0.09       0.12          0          0          0           0
Execute    167   6222.21    9069.20    8087942     741260    1168496      142202
Fetch      598      4.58      11.50       2466     358358          0         503
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      914   6226.88    9080.82    8090408    1099618    1168496      142705

建议看能否优化一下
或者可能的话 analyze

mypengchen2000

谢谢各位！！我对trace出来的东西以前都没怎么看过，不是很熟悉，请大家继续帮我看看！
还有，你用tkprof处理后，格式看起来很清晰了，tkprof是一个工具来的吗？？到那里有下的呢？？
还有，我想说明的是，同样的sql语句（sql语句没有改动过），在数据库数据文件被删之前效率是很高的（不要一个小时），但恢复之后，效率差了很多，我认为不是sql语句本身的原因，是否数据库的其他参数需要调整呢？？

wang2008

检查一下是否有disable的索引。

wang2008

tkprof是oracle自带的工具，不必下载。

jlandzpa

tkprof是oracle自带的.
差别这么大，确实很奇怪.

iamcoldwin

最初由 wang2008 发布
[B]检查一下是否有disable的索引。 [/B]

怎么查啊？

mypengchen2000

索引我检查过的，状态都是valid的，不是disable的，确实是用到了索引的！！
tkprof是oracle自带的？？在哪里的，大致怎么用啊？？谢谢

mypengchen2000

还有，我想说明的是这个session的trace是在我的存储过程没有跑完的情况下的，因为，太慢了，无法忍受，所以我把哪个session给kill掉了！（我试了好多次，都是半途把它给kill的，甚至我试过，让他跑一晚上，第二天早上看，仍然没跑完，还在存储过程中间的某一个表那里）