甲骨文-为什么SELECT *从Foo；这么慢？

Question

我正在用我们的web应用程序解决甲骨文的性能问题。我注意到的一件事似乎混淆了任何类型的测试，那就是返回大量结果的简单查询仍然非常缓慢。一个例子是：

select * from TPM_PROJECTWORKGROUPS;

当我运行它时，我得到：

 5825 record(s) selected [Fetch MetaData: 0ms] [Fetch Data: 59s] 

 [Executed: 9/22/2011 1:52:38 PM] [Execution: 203ms] 

如果我正确地理解了这一点，这意味着实际的查询运行了203 is，但是返回给客户机的数据花费了59秒，在本例中是"Fetch“意思吗？

我没有直接连接到数据库机器并在本地运行查询的权限，但是假设罪魁祸首是实际的网络带宽本身，安全吗？这是合理的，因为我在西雅图和服务器在纽约，但仍然一分钟5800行似乎是相当缓慢的输入。

是否有任何快速建议：( a)确认网络带宽确实是问题；( b)是否有任何“问题”或检查为什么通过有线序列化数据的速度如此缓慢？谢谢!

基于评论的几个更新：

选择计数(*)从(选择*从TPM_PROJECTWORKGROUPS) t；

结果：

 1 record(s) selected [Fetch MetaData: 0ms] [Fetch Data: 0ms] 

 [Executed: 9/22/2011 2:16:08 PM] [Execution: 219ms] 

如果我只选择一列：

从TPM_PROJECTWORKGROUPS中选择PROJECTID；

结果：

5825记录选定的提取MetaData: 0ms 执行日期:2011年9月22日2:17:20

表模式：

(编号) WORKGROUPID (编号)

Answer 1

您使用什么API与数据库(SQL*Plus、JDBC、ODBC等)进行交互？任何API都有一些函数，指定要在一次网络往返中获取多少行(或多少数据)。例如，在SQL*Plus中，它是set arraysize N。在JDBC中，它是setFetchSize。其他API将具有类似的功能。如果您在广域网上，通常希望通过增加每次网络往返获取的行数来最小化应用程序的聊天性。

按照同样的思路，通过网络移动较少的数据并将更多的逻辑推送到服务器可能会使您受益。您是否实际向用户显示了包含5800行数据的网格？或者您是否获取了该数据，然后在应用程序中执行一些处理(即对数据进行排序并显示前100行)？如果您可以将该处理推送到数据库，并减少必须在数据库上传输的数据量，那么您的情况会好得多。

Oracle可以在SQL*Net中配置SDU和TDU以及其他一些网络参数。不过，我不会开始考虑这些选项，除非您优化了获取大小，并确保了尽可能少的数据量。

Answer 2

当你在处理一个网络应用程序时，快速地拿回一些东西是很重要的。调查FIRST_ROWS提示。这对你的处境可能很有价值。

Answer 3

从表中选择几千行不需要花费几乎一分钟的时间。我的猜测是，您在系统的其他地方有一个性能问题。可能是DB中的其他活动，也可能是服务器/网络/存储中的问题。您的DB中其他查询的性能是否同样缓慢？