table block number与TABLE ACCESS FULL实际时间相差很大

Question

环境：Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod最近发现table block number与TABLE ACCESS FULL实际时间不成比例。有两个table HWB_SUMMARY和MWB_SUMMARY。
HWB_SUMMARY的block有197258，table scan只花了53秒；
MWB_SUMMARY的block有67422，是前者的三分之一，但table scan花了2463秒，是前者的40倍！这不是偶然现象，每次运行这个程序都是这样。
最近在看<Cost Based Oracle Fundamentals>，也没有什么启发。
大家给个思路。谢谢各位！

Answer 1

还要综合着物理读和一致性读来看的。前面vc555的一个贴里，讲到一个取记录总数的方法，其中对同一个表的selelct count，时间和路径都有差异的，时间上也有不少的差异。你可以看看这个帖。
http://topic.csdn.net/u/20090617/16/401ea743-48fa-4449-ab85-6e955fea1a01.html可能和你的问题没有太多关系，不过我觉得应该还是有些相同的地方。

Answer 2

block数在那里了，为什么和字段类型有关系？
index？已经是"table access full"了，为什么和index有关系？

Answer 3

多谢！
已经看过你说的帖子了。
那个帖子，实质是在说count()时什么时候会走FFS。
只要index所涉及的column，没有null值。oracle就会使用该index，走FFS得到count(1)的结果。我的疑问和它关系不大。
我这里的TABLE ACCESS FULL是一句delete语句的一部分。
目前对如何消除table access full没有什么思路。所有我只能退而求其次，想缩短这个很长的table access full时间。

Answer 4

如何能查看到explain plan中每一步的物理读和一致性读？
如果不能看到每一步的这两个数据，是否能查看到long ops的这两个数据值？

Answer 5

你的block是什么block？使用的还是总共的？考虑了HWM没有？可以做个10046传上来。

Answer 6

block数是从user_table中查出来的。我想用count(*)搞个TABLE ACCESS FULL，具体SQL如下
select /*+ no_index(mwb_summary i_mwb_summary_mwb i_mwb_summary_mwb_job_no i_mwb_summary_mwb_booking_no pk_mwb_summary_01 i_mwb_summary_delete) */ count(1)
from mwb_summary;
确实走了TABLE ACCESS FULL，只花了10秒就出来了！看来我只能抓10046，再请高人分析了。

Answer 7

10046完成。但我不知道如何在这里上传文件，就传到itpub上去了。
连接如下：
http://www.itpub.net/attachment.php?aid=612906
不知道各位能不能下载到。我用
tkprof event10046.trc output.prf请看DELETE MWB_SUMMARY一句。
但是没有看到这句SQL的explain plan。
以前sql_trace的时候，explain plan都是有的。难道要用tkprof的参数explain？谢谢各位

Answer 8

itpub的图片连接地址变化了。
csdn这里怎么修改帖子？
我重新贴连接吧
http://file.itpub.net/f/d25b5b6c6fc192a6c745eb4252c540ee/4a56ed89/day_090702/20090702_8bb603549f87850e7e52YD4AIH1d5XMF.gif/p/LongOps.gif
http://file.itpub.net/f/9c971a516efe075b089d06aa4b076050/4a56ed89/day_090702/20090702_591045aaa786c969f1e3iAPnKJuV3F1P.gif/p/102MWBS_DELETE.explainPlan.gif
http://file.itpub.net/f/d219e46d3869d1c6433d5858c2ecd264/4a56ed89/day_090702/20090702_0a1b2524226d953677b9mz7lvaQ7Y6JS.gif/p/008HWBS_DELETE.explainPlan.gif

Answer 9

当然要加explain才有执行计划。
你这个DELETE MWB_SUMMARY语句，等待全在db file scattered read上。效果很差。我觉得现在的主要问题是优化这条sql。你前面问题提到的两表fts时间相差很多，你说block数是从user_tables中查出来的。
那么两个表的统计信息会影响user_tables,你看的blocks列可能是旧值，表中数据可能已变，重新分析表后再看。

Answer 10

itpub的图片连接又变化了。总是变，受不了啊！
各位能否建议一个上传图片的地方？
用
tkprof event10046.trc output.prf table=sys.Plan_Table explain=username/passoword
重新处理了一下。
处理后的输出结果如下：
http://www.itpub.net/attachment.php?aid=613627从user_tables中获取，
mwb_summary的CHAIN_CNT为0。