1

在我们基于 .net framework 2.0 的应用程序中，我们使用 System.Data.Oracleclient 现在迁移到 ODP.Net，项目量太大，因此我们无法一次性完成整个迁移，结果应用程序是截至目前，使用 2 个提供商 System.Data.Oracleclient 和 ODP.Net。

现在我们正在更改我们的操作系统，从 Windows xp 32 位到 Windows 7 64 位。在这样做的同时，我们观察到以下情况，

1) 使用 System.Data.Oracleclient 和 ODP.Net 10g 64 位（Oracle.DataAccess.dll 版本 2.102.2.20）在 < 1 秒内执行查询。并且在 Oracle SQL Developer v1.5 上执行相同的查询不到 1 秒。

2）但是，使用带有 ODP.Net 11g 64 位（Oracle.DataAccess.dll 版本 2.112.3.0）的 System.Data.OracleClient 执行相同的查询需要 2-3 分钟。

我们在第 2 点发现性能显着下降），我们必须在 Windows 7 64 位操作系统上使用带有 ODP.Net 11g 64 位（Oracle.DataAccess.dll 版本 2.112.3.0）的 System.Data.OracleClient，但我们无法忍受这种性能如第 2 点所述的退化，我们无法将所有使用 System.Data.OracleClient 的代码快速转换为 ODP.Net。

那么任何人都可以帮助我们，为什么我们会看到第 2 点中提到的如此显着的性能下降，以及我们如何解决这个问题。

问候桑吉布·哈乔杜里

4

2 回答 2

2

将以下内容添加到您的配置中会将 odp.net 跟踪信息发送到日志文件：

  <oracle.dataaccess.client>
    <settings>
      <add name="TraceFileName" value="c:\temp\odpnet-tests.trc"/>
      <add name="TraceLevel" value="63"/>
    </settings>
  </oracle.dataaccess.client>

如果您能及时找到较大的时间间隔，这可能只会有帮助。很有可能行实际上正在进入，只是速度较慢。

尝试将“enlist=false”添加到您的连接字符串。我不认为这是一个解决方案，因为它有效地禁用了分布式事务，但它应该可以帮助您隔离问题。您可以从oracle forumns 帖子中获得更多信息：

从 ODP 的角度来看，我们真正能指出的是，当在底层 OCI 连接上设置 OCI_ATR_EXTERNAL_NAME 和 OCI_ATR_INTERNAL_NAME 时会发生这种行为（启用 distrib tx 支持时会发生这种情况）。

我猜您没有看到的是 odp.net 调用和 sql 开发人员调用之间的执行计划实际上是不同的（这意味着实际的性能损失实际上发生在服务器上）。让您的 dba 跟踪连接并从 odp.net 调用和直接来自 SQL Developer 的调用（或使用 enlist=false 参数）获取执行计划。

如果您确认不同的执行计划，或者如果您想在黑暗中先发制人，请更新相关表的统计信息。在我的例子中，这纠正了这个问题，表明执行计划的生成并没有真正遵循针对不同类型连接的不同规则，但是当可能涉及分布式事务时，成本分析稍微悲观一些。强制执行计划的查询提示也是一种选择，但仅作为最后的手段。

最后，可能是网络问题。如果您的 odp.net 安装使用的是新的 oracle 主目录（除非您进行了一些安装后配置，否则我会期望它），那么 tnsnames.ora 可能会有所不同。主机名可能不是完全限定的，从而造成解析服务器的更多延迟。在这种情况下，我只希望第一次尝试（而不是后续尝试）会很慢，所以我认为这不是问题，但我认为应该提到它。

于 2013-02-05T17:09:01.510 回答
1

请参考此链接，或者将 ODP.Net 64 位组件替换为 ODP.Net 32​​ 位，因为我们使用的是 asp.net，所以我们可以轻松地配置我们的应用程序以使用 Windows 7 (x64) 版本中的 32 位组件运行。

于 2013-02-08T15:00:03.390 回答