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

[kaoziji]

环境：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>，也没有什么启发。
大家给个思路。谢谢各位！

[inthirties]

还要综合着物理读和一致性读来看的。

前面vc555的一个贴里，讲到一个取记录总数的方法，

其中对同一个表的selelct count，时间和路径都有差异的，时间上也有不少的差异。

你可以看看这个帖。
http://topic.csdn.net/u/20090617/16/401ea743-48fa-4449-ab85-6e955fea1a01.html

可能和你的问题没有太多关系，不过我觉得应该还是有些相同的地方。

[suncrafted]

这个应该和字段的类型和相关的索引有一定关系吧。

[kaoziji]

[Quote=引用 2 楼 suncrafted 的回复:]
这个应该和字段的类型和相关的索引有一定关系吧。
[/Quote]
block数在那里了，为什么和字段类型有关系？
index？已经是"table access full"了，为什么和index有关系？

[kaoziji]

[Quote=引用 1 楼 inthirties 的回复:]
还要综合着物理读和一致性读来看的。

前面vc555的一个贴里，讲到一个取记录总数的方法，

其中对同一个表的selelct count，时间和路径都有差异的，时间上也有不少的差异。

你可以看看这个帖。
http://topic.csdn.net/u/20090617/16/401ea743-48fa-4449-ab85-6e955fea1a01.html

可能和你的问题没有太多关系，不过我觉得应该还是有些相同的地方。
[/Quote]
多谢！
已经看过你说的帖子了。
那个帖子，实质是在说count()时什么时候会走FFS。
只要index所涉及的column，没有null值。oracle就会使用该index，走FFS得到count(1)的结果。

我的疑问和它关系不大。
我这里的TABLE ACCESS FULL是一句delete语句的一部分。
目前对如何消除table access full没有什么思路。所有我只能退而求其次，想缩短这个很长的table access full时间。

[kaoziji]

[Quote=引用 1 楼 inthirties 的回复:]
还要综合着物理读和一致性读来看的。
[/Quote]
如何能查看到explain plan中每一步的物理读和一致性读？
如果不能看到每一步的这两个数据，是否能查看到long ops的这两个数据值？

[kaoziji]

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，再请高人分析了。

[vc555]

你的block是什么block？使用的还是总共的？考虑了HWM没有？

可以做个10046传上来。

[kaoziji]

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？

谢谢各位

[kaoziji]

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

[vc555]

当然要加explain才有执行计划。
你这个DELETE MWB_SUMMARY语句，等待全在db file scattered read上。效果很差。

我觉得现在的主要问题是优化这条sql。

你前面问题提到的两表fts时间相差很多，你说block数是从user_tables中查出来的。
那么两个表的统计信息会影响user_tables,你看的blocks列可能是旧值，表中数据可能已变，重新分析表后再看。

[money8899]

看贴必回~！

[kaoziji]

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。

[boboyNO1]

我也碰到类似问题待解决