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

parrotao

to  dblife
我做了你的实验的确发生了这个情况.
找了一下资料发现了下面的一段话
Note: If you want to collect statistics on both the table as a whole and on one or more
columns, be sure to generate the statistics for the table first, and then for the columns.
Otherwise, the table-only ANALYZE will overwrite the histograms generated by the
column ANALYZE. For example, issue the following statements:
ANALYZE TABLE emp ESTIMATE STATISTICS;
ANALYZE TABLE emp ESTIMATE STATISTICS FOR ALL COLUMNS;


我想你应该先做
ANALYZE TABLE emp ESTIMATE STATISTICS;
ANALYZE TABLE emp ESTIMATE STATISTICS FOR ALL indexes;

dblife

哦？还有这种问题，晕倒
oracle这个破东西，呵呵
我一直以为analyze table emp compute statistics for all indexes就一切ok了
至于estimate不过是因为表太大，分析时间过长，才采用呢

dblife

而且还有一个问题，就是estimate分析好像是有时候导致走索引有的时候也无效的
昨天晚上我清楚记得estimate了一次，结果还是table access full,今天早上又estimate一次
又开始用索引了，总之，一团糟

parrotao

最初由 parrotao 发布
[B]to  dblife

Otherwise, the table-only ANALYZE will overwrite the histograms generated by the
column ANALYZE.

但是我想这不是你出问题的原因
但我先ANALYZE TABLE
然后再ANALYZE TABLE FOR ALL INDEXES
就OK了


好奇怪呀呀呀呀呀呀呀呀呀呀呀呀

dblife

嗯，我觉得先analyze table compute or estimate
再analyze table compute or estimate for all indexes 就ok了

olive

我刚才贴了个帖子说oralce7的CBO不好，怎么不见了?

parrotao

没有删过呀!????

olive

我在metalink上面看到有人说oracle7的CBO一团糟，建议不要用它，我自己也感觉CBO难以控制，有点像碰运气。

parrotao

给个URL我也去看看

ligengocp

我曾经在做数据仓库（EXPRESS）加载的时候，也遇到过比较大，比较多的查询，整套查询执行完毕需要24小时左右，而且还总会报sga不够，cursor不够，或者一些内核错误。
后来也发过贴问过，见：
http://www.itpub.net/showthread.php?s=&threadid=2095

我把当时写的心得如下：
“如果表没有做ANAYISE，然后optimizer_mode = choose，则会选择RULE方式优化SQL，会导致SQL的执行路径需要大量的SHARE_POOL_SIZE(The RULE optimizer has generated a SQL statement that has exhausted the maximum available cursor memory area.  This usually results in an ORA-1037.  )”

后来解决方法关键是：
optimizer_mode由choose改为fire_rows，在ORACLE执行SQL之间自动强制对表进行analysis，并自动使用COST方式执行SQL；
这才得以让SQL顺利执行，但速度却没有做过多大的调整。

顺便问一下，Open_cursor所设置的cursor数，是不是使用share_poor_size的空间？