Проблема с System.Data.OracleClient и ODP.Net 11g, вместе используемыми на веб-сайте.net 2.0.
В нашем приложении на основе.net framework 2.0 мы использовали System.Data.Oracleclient и теперь мигрировали в ODP.Net, объем проекта слишком велик, поэтому мы не можем выполнить всю миграцию за один раз, в результате приложение используя 2 провайдера System.Data.Oracleclient & ODP.Net на данный момент.
Сейчас мы меняем нашу ОС с Windows XP 32-битной на Windows 7 64-битной. При этом мы наблюдали следующее,
1) Запрос выполняется в течение < 1 секунды с использованием System.Data.Oracleclient & ODP.Net 10g 64bit (Oracle.DataAccess.dll версия 2.102.2.20). и тот же запрос выполняется в течение < 1 секунды в Oracle SQL Developer v1.5.
2) Однако выполнение того же запроса занимает 2-3 минуты с использованием System.Data.OracleClient с ODP.Net 11g 64bit (Oracle.DataAccess.dll версия 2.112.3.0).
мы обнаружили значительное снижение производительности в пункте 2), мы должны использовать System.Data.OracleClient с ODP.Net 11g 64 бит (Oracle.DataAccess.dll версия 2.112.3.0) в 64-битной ОС Windows 7, но мы не можем жить с производительностью ухудшение, как упомянуто в пункте 2), и мы не можем преобразовать весь код, который использует System.Data.OracleClient, в ODP.Net.
Так может кто-нибудь помочь нам, почему мы видим такое замечательное снижение производительности, как упомянуто в пункте 2), и что мы делаем для решения этой проблемы.
С уважением, Санджиб Харховдхури
2 ответа
Перейдите по этой ссылке или просто замените 64-битный компонент ODP.Net на 32-битный ODP.Net, так как мы используем asp.net, и мы легко можем настроить наше приложение для работы с использованием 32-битного компонента в версии Windows 7 (x64).
Добавление следующего в вашу конфигурацию отправит информацию трассировки 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_ATR_EXTERNAL_NAME и OCI_ATR_INTERNAL_NAME установлены на базовом соединении OCI (что происходит, когда включена поддержка Distribute TX).
Я предполагаю, что вы не видите, что план выполнения на самом деле отличается (то есть фактическое снижение производительности происходит на сервере) между вызовом odp.net и вызовом sql-разработчика. Пусть ваш dba проследит за соединением и получит планы выполнения как из вызова odp.net, так и из вызова непосредственно из SQL Developer (или с параметром enlist = false).
Если вы подтвердите различные планы выполнения или если вы хотите сделать упреждающий выстрел в темноте, обновите статистику по соответствующим таблицам. В моем случае это исправило проблему, указав, что генерация плана выполнения на самом деле не следует разным правилам для разных типов соединений, но что анализ затрат является чуть более пессимистичным, когда может быть задействована распределенная транзакция. Запросы подсказки для принудительного выполнения плана выполнения также вариант, но только в качестве крайней меры.
Наконец, это может быть проблема с сетью. Если ваша установка odp.net использует новую версию oracle (что я ожидаю, если вы не выполнили некоторые настройки после установки), тогда tnsnames.ora может отличаться. Имена хостов могут быть не полностью определены, что создает дополнительные задержки при разрешении сервера. Я только ожидал, что первая попытка (а не последующие попытки) будет медленной в этом случае, поэтому я не думаю, что это проблема, но я подумал, что об этом следует упомянуть.