Question

在我们基于.net framework 2.0的应用程序中，我们使用的是System.Data.Oracleclient，现在迁移到ODP.Net，项目量太大，所以我们不能一次完成整个迁移，因此应用程序使用2个提供程序System.Data.Oracleclient＆amp; ODP.Net截至目前。

现在我们正在改变我们的操作系统，从Windows xp 32bit到Windows 7 64bit。在这样做的同时，我们观察了以下内容，

1）在＆lt;中执行查询1秒使用System.Data.Oracleclient＆amp; ODP.Net 10g 64bit（Oracle.DataAccess.dll版本2.102.2.20）。并且在＆lt;中执行相同的查询在Oracle SQL Developer v1.5上持续1秒。

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

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

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

此致 Sanjib Harchowdhury

Answer 1

将以下内容添加到配置中会将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 post获取更多信息：

从ODP的角度来看，我们真正能够指出的是 OCI_ATR_EXTERNAL_NAME和OCI_ATR_INTERNAL_NAME时发生此行为在基础OCI连接上设置（这是在什么时候发生的 distrib tx支持已启用）。

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

如果您确认了不同的执行计划，或者您希望在黑暗中进行抢先拍摄，更新相关表格的统计信息。在我的情况下，这纠正了问题，表明执行计划生成并不真正遵循不同类型的连接的不同规则，但是当涉及分布式事务时，成本分析只是略微更加悲观。查询提示强制执行计划也是一种选择，但仅作为最后的手段。

最后，它可能是一个网络问题。如果你的odp.net安装使用了一个新的oracle home（除非你做了一些安装后的配置，我会期望），那么tnsnames.ora可能会有所不同。主机名可能不完全合格，从而导致解决服务器的延迟更多。我只期望在这种情况下第一次尝试（而不是后续的尝试）是缓慢的，所以我不认为这是问题，但我认为应该提到。

Answer 2

请参考此link，或者用ODP.Net 32bit替换ODP.Net 64位组件，因为我们使用asp.net，我们可以轻松配置我们的应用程序使用Windows 7中的32位组件运行（x64 ）版。

与.net 2.0网站一起使用的System.Data.OracleClient和ODP.Net 11g的问题

2 个答案: