Plus de données à lire à partir d'une erreur de socket
Nous utilisons Oracle comme base de données pour notre application Web. L'application fonctionne bien la plupart du temps, mais nous obtenons l'erreur "Plus de données à lire à partir du socket".
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
Nous utilisons spring, hibernate et j’ai les informations suivantes pour la source de données dans mon fichier de contexte d’application.
<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>
Je ne sais pas si cela est dû à des erreurs d'application, des erreurs de base de données ou des erreurs de réseau.
Nous voyons ce qui suit sur les journaux Oracle
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
Version Oracle: 11.2.0.1.0
Pour de telles erreurs, vous devez impliquer le support Oracle. Malheureusement, vous ne mentionnez pas la version d'Oracle que vous utilisez. L'erreur peut être liée à un furtif lien de l'optimiseur. Selon la version d'Oracle, différentes solutions de contournement s'appliquent.
Vous avez deux façons de résoudre ce problème:
- passer à 11.2
- définir le paramètre Oracle
_optim_peek_user_binds = false
Bien sûr, les paramètres de soulignement ne doivent être définis que sur avis du support Oracle.
Nous étions confrontés au même problème, nous l'avons résolu en augmentant la taille initialSize et maxActive du pool de connexions.
Vous pouvez vérifier ce lien
Peut-être que cela aide quelqu'un.
Autre cas: Si vous envoyez des paramètres de date à un SQL paramétré, assurez-vous d’avoir envoyé Java.sql.Timestamp et non Java.util.Date. Sinon vous obtenez
Java.sql.SQLRecoverableException: plus de données à lire depuis le socket
Exemple d'instruction: Dans notre code Java, nous utilisons org.Apache.commons.dbutils et nous avons ce qui suit:
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);
Ce qui précède a échoué jusqu'à ce que nous changions les paramètres de date en 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);
Essayez deux choses:
- Définissez dans $ Oracle_HOME/network/admin/tnsnames.ora sur le serveur Oracle server = dédié au serveur = partagé pour permettre plusieurs connexions à la fois. Redémarrez Oracle.
- Si vous utilisez Java, cela pourrait vous aider: Dans
Java/jdk1.6.0_31/jre/lib/security/Java.security, remplacezsecurerandom.source=file:/dev/urandomparsecurerandom.source=file:///dev/urandom.
J'ai eu le même problème. J'ai pu résoudre le problème du côté de l'application, dans le scénario suivant:
JDK8, framework de printemps 4.2.4.RELEASE, Apache Tomcat 7.0.63, Oracle Database 11g Édition Entreprise 11.2.0.4.0
J'ai utilisé le pool de connexions de base de données Apache Tomcat-jdbc:
Vous pouvez prendre les paramètres de configuration suivants comme référence:
<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"/>
Cette configuration était suffisante pour corriger l'erreur. Cela fonctionne bien pour moi dans le scénario mentionné ci-dessus.
Pour plus de détails sur l'installation Apache Tomcat-jdbc: https://Tomcat.Apache.org/Tomcat-7.0-doc/jdbc-pool.html
La rétrogradation de JRE de 7 à 6 a corrigé ce problème pour moi.
Il s'agit d'une exception de très faible niveau, à savoir ORA-17410.
Cela peut arriver pour plusieurs raisons:
Un problème temporaire sur la mise en réseau.
Mauvaise version du pilote JDBC.
Quelques problèmes avec une structure de données spéciale (côté base de données).
Bug de base de données.
Dans mon cas, c’était un bug que nous avons rencontré sur la base de données, qui doit être corrigé.
Dans notre cas, nous avions une requête qui chargeait plusieurs éléments avec select * from x où quelque chose dans (...) La partie était si longue pour le test de référence (17 Mo sous forme de requête de texte). La requête est valide mais le texte est long. Le raccourcissement de la requête a résolu le problème.
Oui, comme @ggkmath l'a dit, parfois, un bon vieux redémarrage est exactement ce dont vous avez besoin. Comme quand "contacter l'auteur et lui demander de réécrire l'application, attendre" n'est pas une option.
Cela se produit lorsqu'une application n'est pas (encore) écrite pour pouvoir gérer les redémarrages de la base de données sous-jacente.