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

Ответ 1

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

У вас есть два способа решить эту проблему:

• перейти на 11.2
• установить параметр oracle _optim_peek_user_binds = false

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

Ответ 2

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

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

Может быть, это помогает кому-то.

Ответ 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); 

Ответ 4

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

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

Ответ 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

Ответ 6

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

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Кажется, я исправил свой экземпляр, удалив заполнитель параметра для параметризованного запроса.

По какой-то причине использование этих заполнителей работало нормально, а затем они перестали работать, и я получил ошибку/ошибку.

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

Удали это

where 
    SOME_VAR = :1

Использовать этот

where 
    SOME_VAR = 'Value'

Ответ 11

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