非常奇怪的性能问题

星月无痕

不知道

wxx

这种情况，多半应该从Oracle角度去分析其为什么出现性能的这么大的差异。  我估计，极有可能是索引的问题，你可以检查一下索引的创建时间，什么样的索引，你的查询语句是否用上了索引，而且还应该考虑一下你所查询的库表的情况，如果这个表建得比较久，而且经常insert/update/delete这种操作，你可以考虑把这个表给重建一下，同时把索引重建，应该就没有问题了。  当然如果可能你可以适应analyze，来处理相关表和索引，已经相关的列，可以让你的查询从几分钟变成几秒钟就完成的。 当然要从总体考虑，是否应该考虑采用何种优化方式来进行处理。

炸鸡

我是把数据文件包括索引文件都拷贝过来的，应该两边的索引都一样吧？尽管如此，我也会试一下重建索引。谢谢。

您所说的“如果可能你可以适应analyze，来处理相关表和索引，已经相关的列，可以让你的查询从几分钟变成几秒钟就完成的”是怎样做的呢，我也想了解一下。

meteor06

[quote]原帖由 "zdygk"]炸鸡怎么你的名字是黑体字。妒忌！！     [/quote 发表：
     
因为他献爱心了  

炸鸡

不好意思，昨天拉了一天，手脚都软了，今天才到客户的机房，现在还有点发热，惨。典型肠炎的症状。

炸鸡

现在我首先重建放数据的LV，把它们都放到CENTER。正在复制文件中。。。。。。。。。。。     

复制完了，刚才顺便做了一个测试，从一个硬盘里把一个大文件（600MB）拷到数据盘上，两边的速度基本一样，H80还比F80要好2秒。     

没有改观，现在试把sort_area_size和sort_area_retained_size从65536改成165536。     

时间从4分40秒变成4分10秒，我再改成655360吧。
现在用了3分10秒！！！！！

我把sort_area_retained_size改回65536，留意，这并不是 sort_area_size。     

又好了一点，3分05秒！我再试加大sort_area_size到1024000吧。     

仍然是3分05秒，也就是说655360也足够了。改回655360吧。  

竟然是3分03秒，算啦，先重起所有的机器，包括终端。

steel

还是不对。
  两边台机器的sort_area_size是一样的啊？还是不能解释F80比H80快的原因。

炸鸡

F80还是65536，他就是比H80用65536快。

我也想知道原因，可惜没有时间了，我的身体又不争气。  

机器重起后是3分钟。

现在退出真的有违技术人员的风格，大家让我想想。

major1028

严重关注中！另外，对炸先生，称呼的过分亲切，我表示道歉！！