Issue with System.Data.OracleClient and ODP.Net 11g together used in .net 2.0 web site

允我心安 提交于 2019-11-29 17:08:40

Adding the following to your config will send odp.net tracing info to a log file:

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

This will probably only be helpful if you can find a large gap in time. Chances are rows are actually coming in, just at a slower pace.

Try adding "enlist=false" to your connection string. I don't consider this a solution since it effecitively disables distributed transactions but it should help you isolate the issue. You can get a little bit more information from an oracle forumns post:

From an ODP perspective, all we can really point out is that the behavior occurs when OCI_ATR_EXTERNAL_NAME and OCI_ATR_INTERNAL_NAME are set on the underlying OCI connection (which is what happens when distrib tx support is enabled).

I'd guess what you're not seeing is that the execution plan is actually different (meaning the actual performance hit is actually occuring on the server) between the odp.net call and the sql developer call. Have your dba trace the connection and obtain execution plans from both the odp.net call and the call straight from SQL Developer (or with the enlist=false parameter).

If you confirm different execution plans or if you want to take a preemptive shot in the dark, update the statistics on the related tables. In my case this corrected the issue, indicating that execution plan generation doesn't really follow different rules for the different types of connections but that the cost analysis is just slighly more pesimistic when a distributed transaction might be involved. Query hints to force an execution plan are also an option but only as a last resort.

Finally, it could be a network issue. If your odp.net install is using a fresh oracle home (which I would expect unless you did some post-install configuring) then the tnsnames.ora could be different. Host names might not be fully qualified, creating more delays resolving the server. I'd only expect the first attempt (and not subsequent attempts) to be slow in this case so I don't think it's the issue but I thought it should be mentioned.

please refer this link, or just replace ODP.Net 64bit component with ODP.Net 32bit, as we are using asp.net we could easily configure our application to run using the 32bit component in Windows 7 (x64) edition.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!