执行计划相同，表大小相同，但执行速度差3倍

anlinew

原帖由 zergduan 于 2010-11-18 14:54 发表


...

肯定不一样，set timing on 是在client记录时间，是从client发送命令，到最后结果在client上列印完成的时间差

这个时间包含了太多的东西，如果你相对比一个sql在两个数据库上的运行时间，绝对不应该看client上的时间。

比如对于同一个client,联接两个不同数据库的网络延时不同，怎么能从set timing on来判断到底哪个数据库性能好呢？

不一样是当然的，我说没有本质的区别，是说在楼主这个例子包含正常网络延时等的情况下，结果与后台看到的结果区别应该不会很大
当然，直接去看trace更准确
绝对不能看client上的时间就太绝对了，在很清楚其他影响所造成的影响不影响判断的情况下，有什么不可以的

[ 本帖最后由 anlinew 于 2010-11-25 10:59 编辑 ]

anlinew

原帖由 Yong Huang 于 2010-11-19 10:12 发表
blackzhang,

As many of us have often suggested, look at buffer gets or consistent gets. If you really want to look at elapsed time, run
alter system flush buffer_cache; --from 10g on; you didn't tell us your version
and then check the timing.

Also, make sure the table is big enough to get the elapsed time up to at least a few seconds. Anything below 1 second contains too much error due to unknown factors.

Yong Huang

楼主贴出的信息能看到consistent gets是相同的，都没有physical reads
因此时间的差别应该主要在cpu time和network上

如果 flush buffer_cache，这个时候时间估计更多的会在physical reads也就是IO上，与原本的意义差别就太大了

zergduan

原帖由 anlinew 于 2010-11-25 10:53 发表

不一样是当然的，我说没有本质的区别，是说在楼主这个例子包含正常网络延时等的情况下，结果与后台看到的结果区别应该不会很大
当然，直接去看trace更准确
绝对不能看client上的时间就太绝对了，在很清楚其他影响所造成的影响不影响判断的情况下，有什么不可以的

是这样，我没有针对lz的问题，我只是说从client或者autotrace看执行时间是不对的~
这里还包含了一个非常重要的误差，就是屏幕列印的时间, client上的timing on 是包含列印时间的。 你无法保证多台机器在列印相同内容的时候使用的时间是相同的，甚至不能保证同一台每次列印相同的内容所用的时间是相同的。
当然这些时间大部分可以忽略，但是就像Huang版说的，这里的时间差不到1s，那么这些误差都不能忽略的~

既然要得到SQL在数据库上运行的时间，当然是在数据库上用trace才能得到准确的时间，而不能依靠屏幕上的显示~

[ 本帖最后由 zergduan 于 2010-11-25 11:44 编辑 ]

zergduan

原帖由 anlinew 于 2010-11-25 11:05 发表

楼主贴出的信息能看到consistent gets是相同的，都没有physical reads
因此时间的差别应该主要在cpu time和network上

如果 flush buffer_cache，这个时候时间估计更多的会在physical reads也就是IO上，与原本的意义差别就太大了

这个我同意~

anlinew

原帖由 zergduan 于 2010-11-25 11:42 发表


是这样，我没有针对lz的问题，我只是说从client或者autotrace看执行时间是不对的~
这里还包含了一个非常重要的误差，就是屏幕列印的时间, client上的timing on 是包含列印时间的。 你无法保证多台机器在列印相同内容的时候使用的时间是相同的，甚至不能保证同一台每次列印相同的内容所用的时间是相同的。
当然这些时间大部分可以忽略，但是就像Huang版说的，这里的时间差不到1s，那么这些误差都不能忽略的~

既然要得到SQL在数据库上运行的时间，当然是在数据库上用trace才能得到准确的时间，而不能依靠屏幕上的显示~

楼主这个的确很不准确
列印时间，show plan带来递归的其他sql执行的时间，网络交互等等

Yong Huang

I know he already showed consistent gets, but he seems to ignore it and focus on the elapsed time as viewed on the client side. Two issues here. The two client-side elapsed times are too close to each other, prone to errors of various sources. They need to be magnified for performance measurement. If he doesn't want to increase table size (actually the index size here), he can use PL/SQL to loop many times. In addition, repeated tests in random order of the two are needed to check reproducibility.

Secondly, if elapsed time is really important, server-side v$sql.elapsed_time should be checked, preferably combined with reference to cpu_time, to judge efficiency.

Yong Huang