it-swarm.com.de

Keine Daten mehr aus Socketfehler zu lesen

Wir verwenden Oracle als Datenbank für unsere Webanwendung. Die Anwendung läuft die meiste Zeit gut, aber wir erhalten den Fehler "Keine Daten mehr aus Socket lesen".

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

Wir verwenden spring, hibernate und ich habe Folgendes für die Datenquelle in meiner Anwendungskontextdatei.

<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>

Ich bin nicht sicher, ob dies auf Anwendungsfehler, Datenbankfehler oder Netzwerkfehler zurückzuführen ist. 

In den Oracle-Protokollen sehen wir Folgendes

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 Version: 11.2.0.1.0

52
Kathir

Für solche Fehler sollten Sie den Oracle-Support einbeziehen. Leider erwähnen Sie nicht, welche Oracle-Version Sie verwenden. Der Fehler kann mit dem Optimierer-Bindungsspähen zusammenhängen. Je nach Oracle-Version gelten unterschiedliche Problemumgehungen.

Sie haben zwei Möglichkeiten, dies anzusprechen:

  • upgrade auf 11.2
  • oracle-Parameter setzen _optim_peek_user_binds = false

Natürlich sollten Unterstrichparameter nur festgelegt werden, wenn sie vom Oracle-Support empfohlen werden

28
steve

Wir waren mit demselben Problem konfrontiert und haben es gelöst, indem wir die initialSize- und maxActive-Größe des Verbindungspools erhöht haben. 

Sie können diesen Link überprüfen

Vielleicht hilft das jemandem.

8
fyelci

Ein anderer Fall: Wenn Sie Datumsparameter an ein parametrisiertes SQL senden, stellen Sie sicher, dass Sie Java.sql.Timestamp und nicht Java.util.Date gesendet haben. Sonst bekommst du 

Java.sql.SQLRecoverableException: Keine Daten mehr vom Socket zu lesen

Beispielanweisung: In unserem Java-Code verwenden wir org.Apache.commons.dbutils und haben Folgendes:

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); 

Das obige ist fehlgeschlagen, bis wir die Datumsparameter in Java.sql.Timestamp geändert haben.

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); 
5
chrisl08

Versuchen Sie zwei Dinge:

  1. Auf dem Oracle-Server in $ Oracle_HOME/network/admin/tnsnames.ora festgelegt. Starten Sie Oracle neu.
  2. Wenn Sie Java verwenden, kann dies Ihnen helfen: Ändern Sie Java/jdk1.6.0_31/jre/lib/security/Java.security in securerandom.source=file:/dev/urandom in securerandom.source=file:///dev/urandom.
4
Richard

Ich hatte das gleiche Problem. Ich konnte das Problem von der Anwendung aus unter dem folgenden Szenario lösen:

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

Ich habe das Datenbankverbindungspooling Apache Tomcat-jdbc verwendet:

Sie können die folgenden Konfigurationsparameter als Referenz verwenden:

<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"/>

Diese Konfiguration reichte aus, um den Fehler zu beheben. Das funktioniert in dem oben genannten Szenario gut für mich.

Weitere Informationen zum Setup von Apache Tomcat-jdbc: https://Tomcat.Apache.org/Tomcat-7.0-doc/jdbc-pool.html

4

Durch das Herabstufen der JRE von 7 auf 6 wurde dieses Problem für mich behoben.

3
johndemic

Dies ist eine sehr niedrige Ausnahme, die ORA-17410 ist.

Es kann verschiedene Ursachen haben:

  1. Ein vorübergehendes Problem beim Networking.

  2. Falsche JDBC-Treiberversion.

  3. Einige Probleme mit spezieller Datenstruktur (auf der Datenbankseite).

  4. Datenbankfehler.

In meinem Fall war es ein Fehler, den wir in der Datenbank gefunden haben, der gepatcht werden muss.

2
devwebcl

In unserem Fall hatten wir eine Abfrage, bei der mehrere Elemente mit select * aus x geladen werden, wobei etwas in (...) Das war zum Teil so lang für den Benchmark-Test. Die Abfrage ist gültig, aber der Text ist so lang. Durch die Verkürzung der Abfrage wurde das Problem gelöst.

0
mcelikkaya

Ja, wie @ggkmath sagte, manchmal ist ein guter alter Neustart genau das, was Sie brauchen. Wie wenn "den Autor kontaktieren und ihn die App umschreiben, warten Sie" ist keine Option.

Dies geschieht, wenn eine Anwendung (noch) nicht so geschrieben wurde, dass Neustarts der zugrunde liegenden Datenbank ausgeführt werden können.

0

Ich schien meine Instanz zu reparieren, indem ich den Parameterplatzhalter für eine parametrisierte Abfrage entfernte.

Aus irgendeinem Grund funktionierten diese Platzhalter einwandfrei, und dann funktionierten sie nicht mehr und ich bekam den Fehler.

Als Problemumgehung habe ich meine Platzhalter durch Literale ersetzt, und es hat funktioniert.

Entferne das

where 
    SOME_VAR = :1

Benutze das

where 
    SOME_VAR = 'Value'
0
Kalin