我最近编写了一个复杂的SELECT语句（基于许多非常非常复杂的视图），在我的桌面上从Toad运行时需要1小时50分钟的执行时间，而使用cx_Oracle从Python脚本运行时只需要几分钟库（写入每50行刷新到磁盘）。 单个结果集的总大小约为8000行，共计5MB。 在执行期间，我的工作站没有抖动，而且CPU负载相当低。
在服务器上运行完全相同的查询花费了惊人的21秒来产生一个字节一个字节的相同的结果集。 这也是由相同的Python / cx_Oracle脚本生成的。
从服务器传输5MB结果集文件到我的工作站只需要3秒钟，所以我不认为networking带宽是直接的问题。
SQL * Net或其关联的库中的一个是罪魁祸首？ 在networking中调用查询时是否存在一些非线性内存pipe理问题？ 一个5MB的结果集很大，但在这个时代不是很大。 有没有可能会帮助一些缓冲区大小configuration设置？ 我正在使用一个香草的Oracle客户端安装。
该工作站是使用Oracle 10g客户端的Windows XP Pro SP3（仅1GB内存），使用cx_Oracle 5.0.2的Toad for Oracle Xpert 9.7.2.5和Python 2.6.2。 服务器是Red Hat 2.6.9-67.ELsmp，运行在Oracle Xeon 3.8GHz 8GB服务器上，运行Oracle 10.2.0.4，Python 2.3.4，cx_Oracle 4.4.1。
编辑：哎呀！ 该文件只有5兆字节 ，而不是GB。 很抱歉。
解决：在我提到的提取查询之前有一个人口脚本。 一旦该人口脚本重新运行，提取查询需要2小时运行，无论客户端程序的位置。 在第一次长时间之后，结果集必须被caching到某个地方，直到我有条不紊地完成了所有的组合。
要考虑两点：
你有没有先在蟾蜍执行查询，然后在python + cx_Oracle？ 第一次执行查询时，Oracle需要parsing查询，创build执行计划并执行计划：从磁盘读取到内存（缓冲区caching），执行连接等等。第二次，Oracle使用相同的执行计划（存储在SGA中），并从缓冲区caching中读取，而不是磁盘。 第二次执行相同的查询可能会less很多。
将8000行/ 5GB的数据（每行655KB）加载到TOAD中，在GUI中显示它们可能需要很长时间。 用python + cx_Oracle，你不会显示任何东西，所以你在这里节省了很多时间。
编辑 ：好，所以8000行/ 5 Mb的数据（每行655字节）不应该是TOAD显示的问题。
跟踪在oracle中的执行情况，可能你会看到你的工作站获取小块数据，并快速增加延迟。
解决scheme可能是批量获取结果，如下所示：
解决TOAD中的Oracle争用; 看看蟾蜍世界，寻找
http://www.toadworld.com/Experts/GuyHarrisonsImprovingOraclePerformance/ResolvingOracleContention/May2008OracleNetworkContention/tabid/374/Default.aspx （对不起，不能添加超链接）
我不太了解Oracle，但是以前使用其他数据库的networking协议的经验告诉我，他们完全忽略了延迟问题。 换句话说，即使没有过多的数据传输，如果您必须为每个值进行几次往返服务器，事情仍然会变得冰冷。
如果你在networking上添加了一些延迟（我知道这在Linux中是可行的，我只能想象在Windows中有一些方法），并且看看它是否会显着影响整个运行时间，那么你可以testing这个理论。
另一个select是，一些处理可能在客户端完成，可能会传输大于5 GB的中间数据来获得结果。 这可能会出现在你的桌面上的一些相当数量的负载，所以它不是所有可能的。
所有的迹象似乎都指向了networking瓶颈。 这两台计算机之间的文件传输能获得什么样的吞吐量？ 你可以尝试从另一台计算机运行相同的查询，但在networking拓扑结构中更接近？
有效的传输速率是6.2Mbps – 不好。 这是在黑暗中的一个镜头，但是…你是否忽略告诉我们你的工作站和服务器之间有一个电缆调制解调器？ 🙂
也许你的工作站是菊花链式的IP电话，你实际上连接在10Mbps？
对不起，如果我说明显，但你没有提到你的问题你的networkingconfiguration。
一个SELECT语句应该完整地发送到服务器进行parsing和执行。 pipe理客户如何返回这些结果取决于客户。 我敢打赌，问题在于客户如何获得结果。 我用TOAD已经有一段时间了，所以我不知道它是否在批量提取数据，但是这是一个可以大大提高速度的地方，就像@slovon指出的那样。
只是为了微笑，看看从工作站到服务器的traceroute报告，反之亦然。
编辑：另一件要尝试的是在服务器上运行您的python脚本，但通过服务器上的侦听器通过TNS连接。 这应该让你知道TNS软件对你的查询有什么影响，同时消除了任何干扰的networking问题。
此外，请确保您的DNS是健康的（必须能够进行反向查找），并且您没有在服务器上使用DHCP。 主机名下的下划线也是不可以的。
从TOAD和本地获得会话等待时间的跟踪。 然后比较等待事件和时间，加上执行计划。 这个计划可能是不同的。