ODP.NET Oracle.ManagedDataAcess случайные ошибки ORA-12570

Я пытаюсь перейти на Oracle.ManagedDataAcess с неуправляемой версии и получать случайные ошибки. ORA-12570 TNS: сбой программы чтения пакетов.

Я не знаю, почему возникает эта ошибка, но как только она запускается, каждый последующий запрос выдает такую ​​же ошибку в течение 10-30 минут, затем снова работает в течение еще 10-30 минут и так далее.

Таким образом, это случайные последующие неудачи в течение некоторого времени, а затем последующий успех

Уже много чего перепробовал, чтобы возобновить

Окружающая среда:

Oracle.ManagedDataAcess версия 12.1.2400 (4.121.2.20150926) (nuget) (на сервере не установлена ​​ссылка gac, которая могла бы переопределить версию bin)Oracle Server Oracle Database 12c Enterprise Edition, выпуск 12.1.0.2.0 - 64-разрядная версияWindows 2012 (Windows Update в порядке)

Проверено:

Брандмауэр: это не проблема брандмауэраОшибка компьютера: та же проблема возникает на моем компьютере, Azure WebApp и экземпляре AWS EC2Интерференция: нет запущенного анализатора, прозрачного прокси и т. Д.Шифрование: я не использую какой-либо вид шифрования (если по умолчанию не включено что-то, чего я не знаю)Строка соединений: та же строка соединений отлично работает с неуправляемой версией

Дополнительная информация:

Это производственная база данных, она очень стабильнаяПриложение скомпилировано в anycpu, пул приложений IIS ограничен до 64 битЯ тестирую точно один и тот же запрос каждый раз (просто обновление по get url rest ws, webapi), поэтому он не связан с форматом данных.

Конфигурация:

Сервер sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

Приложение Web.config

<connectionStrings>
<add name="XXXX" connectionString="Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.com)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=xxx)));User Id=xxxxx;Password=xxxxx;" />
</connectionStrings>

<configSections>
    <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</configSections>

<oracle.manageddataaccess.client>
    <version number="*">
      <dataSources>
        <!--<dataSource alias="SampleDataSource" descriptor="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL))) " />-->
      </dataSources>
      <settings>
        <setting name="SQLNET.AUTHENTICATION_SERVICES" value="NONE"/> <!--NTS-->
        <setting name="sqlnet.crypto_checksum_server" value="rejected"/>
        <setting name="sqlnet.crypto_checksum_client" value="rejected"/>
        <setting name="SQLNET.ENCRYPTION_SERVER" value="rejected"/>
      </settings>
    </version>
</oracle.manageddataaccess.client>

Некоторые ссылки:

https://community.oracle.com/thread/3634263?start=0&tstart=0

Управляемый драйвер ODP.net выбрасывает ORA-12570: сетевой сеанс: непредвиденная ошибка чтения пакета

Управляемый клиент Oracle с опциями расширенной безопасности Oracle

Ошибка ODP.NET в IIS: Конец файла сетевого сеанса ORA-12357

ОБНОВЛЕНИЕ 1

После того, как пул изменился (как я описал в качестве ответа здесь), я решил опубликовать версию, чтобы провести настоящий тест. Через 1 день, когда пользователи жалуются на производительность, я получил еще одну ошибку: значение не может быть нулевым. Имя параметра: byteArray

Я вернул ссылку на неуправляемую версию, и все снова было в порядке, быстрее, без ошибок байтового массива, улучшено управление пулами.

Так что пока я просто отказываюсь от управляемой версии, может быть, я попробую еще раз на Oracle в следующем выпуске.

Здесь некоторые ссылки на эту новую ошибку, как вы можете видеть, выглядят как еще одна ошибка (до сих пор без ответа).

https://community.oracle.com/thread/3676588?start=0&tstart=0

EF + ODP.NET + CLOB = Значение не может быть пустым - Имя параметра: byteArray?

Пока что причиныне использовать:

Ошибка управления пуламиCLOB ошибки null / not null bytearrayСнижение производительности, вероятно, связано с ошибкой объединения

Ответы на вопрос(5)

Ваш ответ на вопрос