[英]OpenQuery from SQL Server 2008R2 to Oracle 11g Slow but same query run on the Oracle server is fast
Code: 码:
WITH GTransNums
AS (
SELECT /*+ INDEX (GTRANS_DEFS_24) */ gtrans_num
FROM pro.gtrans_defs
INNER JOIN pro.loc_defs ON (
loc_defs.loc_num = gtrans_defs.gdest_num
AND loc_defs.loc_type = '' JLP ''
)
WHERE gdest_num != 99999
)
SELECT /*+ INDEX (GTRANS_ITEMS_1) */ Gtrans_items.season
,Gtrans_items.sty_num
,Gtrans_items.sty_qual
,Gtrans_items.bf_mat_char_val
FROM pro.gtrans_items
WHERE gtrans_num IN (
SELECT gtrans_num
FROM GTransNums
)
GROUP BY Gtrans_items.season
,Gtrans_items.sty_num
,Gtrans_items.sty_qual
,Gtrans_items.bf_mat_char_val
The code pasted above runs very quickly when run directly on the Oracle server but when we wrap this into an Openquery on Microsoft SQL Server it simply hangs. 直接在Oracle服务器上运行时,上面粘贴的代码运行非常迅速,但是当我们将其包装到Microsoft SQL Server上的Openquery中时,它只是挂起。 It pulls back about 40000 rows. 它拉回约40000行。
We have assessed the formatting of the Openquery when it hits the Oracle box and all appears to be exactly the same as when you run it directly. 我们评估了Openquery到达Oracle框时的格式,所有看起来都与您直接运行它时完全相同。
The Openquery is being run with pretty much god permissions on the Microsoft SQL Server and Oracle boxes. Openquery在Microsoft SQL Server和Oracle机器上具有相当大的权限运行。
Provider: Oracle Provider for OLE DB 提供程序:OLE DB的Oracle提供程序
We have created a view from the code on the Oracle box and queried the view via Openquery from Microsoft SQL Server and it was super quick. 我们已经从Oracle框中的代码创建了一个视图,并通过Microsoft SQL Server中的Openquery查询了该视图,它非常快。
Possible thoughts: 可能的想法:
I have found similar threads on this but they all appear to tail off without conclusion. 我发现与此类似的线程,但它们似乎都没有任何结论而逐渐消失。 This is frustrating as I cannot explain why exactly the same query runs remarkably at different speeds. 这令人沮丧,因为我无法解释为什么完全相同的查询以不同的速度显着运行。
Any help on this would be appreciated and if you need any more info then please just ask. 任何帮助,将不胜感激,如果您需要任何更多的信息,那么请问。
I used to do similar things with SQLServer 2008 and Oracle 8. I never got good performance out of it. 我曾经使用SQLServer 2008和Oracle 8做类似的事情。
The queries ran fine on Oracle - after all, Oracle is running them, not the driver. 查询在Oracle上运行良好-毕竟,Oracle在运行它们,而不是驱动程序。 What happens is that network round trips kill it. 发生的事情是网络往返将其杀死。 The path the query and data take is: 查询和数据采用的路径是:
I think that step 5 doesn't actually start until all the data has been received from step 4 - which makes sense when you think it may be being used in a join with SQLServer tables. 我认为,直到从步骤4接收到所有数据后,步骤5才真正开始-当您认为将其用于与SQLServer表的联接中时,这才有意义。
Anyway, you have three network trips for the data instead of one, plus the last trip not completing until the second is complete. 无论如何,您有三个数据网络行程,而不是一个,还有最后一个行程直到第二次完成才完成。
Also, if the full result set is held on SQL Server then it will be using more memory than a query usually does. 同样,如果完整的结果集保留在SQL Server上,则它将使用比查询通常更多的内存。 SQL Server will start sending data to the client as soon as it is available. SQL Server将在可用时立即开始将数据发送到客户端。 You can see this in SSMS if you run a query which takes more than a few seconds: the results get shown whilst the query timer in the status bar at bottom right is still running. 如果运行查询的时间超过几秒钟,则可以在SSMS中看到此消息:在右下方状态栏中的查询计时器仍在运行时,将显示结果。 So the SQL Server may be having to assign extra memory causing possible paging etc etc. 因此,SQL Server可能不得不分配额外的内存,从而导致可能的分页等。
It's a fairly useful feature, but I've never seen it be fast. 这是一个非常有用的功能,但我从未见过它很快。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.