Нет данных для чтения из ошибки сокета

Question

Мы используем Oracle в качестве базы данных для нашего веб-приложения.Приложение работает хорошо в большинстве случаев, но мы получаем эту ошибку «Нет данных для чтения из сокета».

Caused by: java.sql.SQLRecoverableException: No more data to read from socket
    at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1142)
    at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1099)
    at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:288)
    at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
    at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)
    at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
    at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:863)
    at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1153)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1275)
    at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3576)
    at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3620)
    at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
    at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
    at org.hibernate.loader.Loader.getResultSet(Loader.java:1869)
    at org.hibernate.loader.Loader.doQuery(Loader.java:718)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
    at org.hibernate.loader.Loader.doList(Loader.java:2449)
    ... 63 more

Мы используем spring, hibernate, и у меня есть следующее для источника данных в моем контексте приложенияфайл.

<bean class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close" id="dataSource">
        <property name="driverClassName" value="${database.driverClassName}" />
        <property name="url" value="${database.url}" />
        <property name="username" value="${database.username}" />
        <property name="password" value="${database.password}" />
        <property name="defaultAutoCommit" value="false" />
        <property name="initialSize" value="10" />
        <property name="maxActive" value="30" />
        <property name="validationQuery" value="select 1 from dual" />
        <property name="testOnBorrow" value="true" />
        <property name="testOnReturn" value="true" />
        <property name="poolPreparedStatements" value="true" />
        <property name="removeAbandoned" value="true" />
        <property name="logAbandoned" value="true" />
    </bean>

Я не уверен, что это из-за ошибок приложения, ошибок базы данных или сетевых ошибок.

В журналах оракула мы видим следующее

Thu Oct 20 10:29:44 2011
Errors in file d:\oracle\diag\rdbms\ads\ads\trace\ads_ora_3836.trc  (incident=31653):
ORA-03137: TTC protocol internal error : [12333] [4] [195] [3] [] [] [] []
Incident details in: d:\oracle\diag\rdbms\ads\ads\incident\incdir_31653\ads_ora_3836_i31653.trc
Thu Oct 20 10:29:45 2011
Trace dumping is performing id=[cdmp_20111020102945]
Thu Oct 20 10:29:49 2011
Sweep [inc][31653]: completed
Sweep [inc2][31653]: completed
Thu Oct 20 10:34:20 2011
Errors in file d:\oracle\diag\rdbms\ads\ads\trace\ads_ora_860.trc  (incident=31645):
ORA-03137: TTC protocol internal error : [12333] [4] [195] [3] [] [] [] []
Incident details in: d:\oracle\diag\rdbms\ads\ads\incident\incdir_31645\ads_ora_860_i31645.trc
Thu Oct 20 10:34:21 2011

Версия Oracle: 11.2.0.1.0

Answer 1

Для таких ошибок вы должны задействовать поддержку оракула.К сожалению, вы не упоминаете, какой релиз оракула вы используете.Ошибка может быть связана с оптимизатором bind peeking.В зависимости от версии oracle применяются различные обходные пути.

Для решения этой проблемы есть два способа:

• обновить до 11.2
• установить параметр oracle_optim_peek_user_binds = false

Конечно, параметры подчеркивания следует устанавливать только по рекомендации службы поддержки оракула

Answer 2

Мы столкнулись с той же проблемой, мы решили ее, увеличив размер пула соединений initialSize и maxActive

Вы можете проверить эту ссылку

Может быть, это кому-нибудь поможет.

Answer 3

Другой случай: если вы отправляете параметры даты в параметризованный sql, убедитесь, что вы отправили java.sql.Timestamp, а не java.util.Date.В противном случае вы получите

java.sql.SQLRecoverableException: больше нет данных для чтения из сокета

Пример оператора: в нашем Java-коде мы используем org.apache.commons.dbutils и имеемследующее:

final String sqlStatement = "select x from person where date_of_birth between ? and ?";
java.util.Date dtFrom = new Date(); //<-- this will fail
java.util.Date dtTo = new Date();   //<-- this will fail
Object[] params = new Object[]{ dtFrom , dtTo };
final List mapList = (List) query.query(conn, sqlStatement, new MapListHandler(),params); 

Выше не удавалось, пока мы не изменили параметры даты на java.sql.Timestamp

java.sql.Timestamp tFrom = new java.sql.Timestamp (dtFrom.getTime()); //<-- this is OK
java.sql.Timestamp tTo = new java.sql.Timestamp(dtTo.getTime());   //<-- this is OK
Object[] params = new Object[]{ tFrom , tTo };
final List mapList = (List) query.query(conn, sqlStatement, new MapListHandler(),params); 

Answer 4

Попробуйте две вещи:

1. Установите в $ ORACLE_HOME / network / admin / tnsnames.ora на сервере oracle server = выделенный для сервера = shared, чтобы разрешить более одного подключения одновременно. Перезапустите оракула. ​​
2. Если вы используете Java, это может вам помочь: В java/jdk1.6.0_31/jre/lib/security/Java.security измените securerandom.source=file:/dev/urandom на securerandom.source=file:///dev/urandom

Answer 5

У меня была такая же проблема. Мне удалось решить проблему со стороны приложения, по следующему сценарию:

JDK8, Spring Framework 4.2.4.RELEASE, Apache Tomcat 7.0.63, Oracle Database 11g Enterprise Edition 11.2.0.4.0

Я использовал пул соединений с базой данных apache tomcat-jdbc:

В качестве эталона можно взять следующие параметры конфигурации:

<Resource name="jdbc/exampleDB"
      auth="Container"
      type="javax.sql.DataSource"
      factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
      testWhileIdle="true"
      testOnBorrow="true"
      testOnReturn="false"
      validationQuery="SELECT 1 FROM DUAL"
      validationInterval="30000"
      timeBetweenEvictionRunsMillis="30000"
      maxActive="100"
      minIdle="10"
      maxWait="10000"
      initialSize="10"
      removeAbandonedTimeout="60"
      removeAbandoned="true"
      logAbandoned="true"
      minEvictableIdleTimeMillis="30000"
      jmxEnabled="true"
      jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
        org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
      username="your-username"
      password="your-password"
      driverClassName="oracle.jdbc.driver.OracleDriver"
      url="jdbc:oracle:thin:@localhost:1521:xe"/>

Этой конфигурации было достаточно, чтобы исправить ошибку. Это хорошо работает для меня в сценарии, упомянутом выше.

Подробнее о настройке apache tomcat-jdbc: https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

Answer 6

Это исключение очень низкого уровня, которое является ORA-17410.

Это может произойти по нескольким причинам:

1. Временная проблема в сети.

2. Неправильная версия драйвера JDBC.

3. Некоторые проблемы со специальной структурой данных (на стороне базы данных).

4. Ошибка базы данных.

В моем случае это была ошибка, которую мы ударили по базе данных, которую нужно исправить.

Answer 7

Понижение JRE с 7 до 6 решило эту проблему для меня.

Answer 8

В нашем случае у нас был запрос, который загружает несколько элементов с помощью select * from x, где что-то в (...) Часть была так долго для теста производительности (17 МБ как текстовый запрос).Запрос действителен, но текст так долго.Сокращение запроса решило проблему.

Answer 9

Да, как сказал @ggkmath, иногда старый добрый перезапуск - это именно то, что вам нужно. Например, когда «свяжитесь с автором и попросите его переписать приложение, подождите» - это не вариант.

Это происходит, когда приложение не написано (пока) таким образом, чтобы оно могло обрабатывать перезапуски базовой базы данных.

Answer 10

Я получил эту ошибку, затем перезапустил мой сервер GlassFish, который содержал пулы соединений между моим клиентским приложением и базой данных, и ошибка исчезла. Поэтому попробуйте перезапустить сервер приложений, если это применимо.