简体   繁体   English

从SQL Server 2008R2到Oracle 11g的OpenQuery缓慢,但是在Oracle服务器上运行相同的查询速度很快

[英]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: 可能的想法:

  • Openquery is not accessing either indexes, statistics or keys when passing the query to Oracle. 将查询传递给Oracle时,Openquery不访问索引,统计信息或键。
  • The driver/connection manager is causing the issue. 驱动程序/连接管理器引起了该问题。 We tried an ODBC driver with no success. 我们尝试了ODBC驱动程序,但没有成功。
  • Some strange networking that is sending the query round the houses. 一些奇怪的网络正在房屋周围发送查询。 Can't test for this as packet sniffers are forbidden on the network. 无法测试此内容,因为网络上禁止使用数据包嗅探器。 Both boxes are housed on the same site. 两个盒子都放在同一个地方。

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: 查询和数据采用的路径是:

  1. Client sends query to SQLServer 客户端将查询发送到SQLServer
  2. SQLServer sends query to Oracle Server SQLServer将查询发送到Oracle Server
  3. Oracle Server executes query. Oracle Server执行查询。
  4. Oracle Server sends query to SQLServer Oracle Server将查询发送到SQLServer
  5. SQLServer sends query to client SQLServer将查询发送到客户端

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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM