在我们基于.net框架2.0的应用程序中，我们使用System.Data.Oracleclient，现在迁移到ODP.net，项目量太大，因此我们不能一次性完成整个迁移，因此应用程序使用了两个提供程序System.Data.Oracleclient&ODP.Net截至目前。
现在我们正在更改操作系统，从WindowsXP 32位更改为Windows7 64位。在这样做的同时，我们观察到以下情况：
1） 查询在<使用System.Data.Oracleclient&ODP.Net 10g 64位（Oracle.DataAccess.dll版本2.102.20）。并且相同的查询在<在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位操作系统上使用System.Data.OracleClient和ODP.Net 11g 64位（Oracle.DataAccess.dll 2.112.3.0版本），但我们不能忍受第2）点中提到的性能下降，并且我们不能很快地将所有使用System.Data.OracleClient的代码转换为ODP.Net。
那么，有人能帮助我们吗？为什么我们会看到第2）点中提到的如此显著的性能下降，以及我们该如何解决这个问题。
问候Sanjib Harchowdhury
在配置中添加以下内容将向日志文件发送odp.net跟踪信息：
<oracle.dataaccess.client>
<settings>
<add name="TraceFileName" value="c:tempodpnet-tests.trc"/>
<add name="TraceLevel" value="63"/>
</settings>
</oracle.dataaccess.client>
只有当你能在时间上找到一个很大的差距时，这可能才会有帮助。很有可能，争吵真的开始了，只是速度变慢了。
尝试将"登记=false"添加到连接字符串。我不认为这是一个解决方案，因为它有效地禁用了分布式事务，但它应该可以帮助您隔离问题。你可以从甲骨文的帖子中获得更多信息：
从ODP的角度来看，我们真正能指出的是当OCI__EXTERNAL_NAME和OCI__INTERNAL_NAME在底层OCI连接上设置（当distrib tx支持已启用）。
我想你没有看到的是，odp.net调用和sql开发人员调用之间的执行计划实际上是不同的（意味着实际的性能命中实际上发生在服务器上）。让dba跟踪连接，并从odp.net调用和直接从SQLDeveloper（或使用listl=false参数）调用中获取执行计划。
如果您确认了不同的执行计划，或者您想在黑暗中先发制人，请更新相关表上的统计信息。在我的案例中，这纠正了这个问题，表明执行计划的生成并没有真正遵循不同类型连接的不同规则，但当可能涉及分布式事务时，成本分析只是稍微更麻烦一些。强制执行计划的查询提示也是一种选择，但这只是最后的手段。
最后，这可能是一个网络问题。如果你的odp.net安装使用的是一个新的oracle home（除非你在安装后进行了一些配置，否则我希望是这样），那么tnsnames.ora可能会有所不同。主机名可能不是完全限定的，这会造成解析服务器的更多延迟。在这种情况下，我只希望第一次尝试（而不是随后的尝试）会很慢，所以我不认为这是问题所在，但我认为应该提到这一点。
请参阅此链接，或者将ODP.Net 64位组件替换为ODP.Net 32位组件，因为我们使用的是asp.Net，所以我们可以很容易地将我们的应用程序配置为在Windows 7（x64）版本中使用32位组件运行。