ORA-03113: fin de fichier sur le canal de communication après une longue inactivité dans l'application ASP.Net

StackOverflow https://stackoverflow.com/questions/83068

Question

J'ai une application ASP.Net 2.0 avec charge équilibrée (n'utilisant pas l'état de session) sur IIS5 et s'exécutant sur un serveur Oracle 10g unique, à l'aide de la version 10.1.0.301 des pilotes ODAC / ODP.Net. Après une longue période d'inactivité (quelques heures), l'application, apparemment aléatoire, lève une exception Oracle:

  

Exception: ORA-03113: fin de fichier sur le canal de communication à   Oracle.DataAccess.Client.OracleException.HandleErrorHelper (Int32   errCode, connexion OracleConnection, IntPtr opsErrCtx, OpoSqlValCtx *   pOpoSqlValCtx, Object src, String procedure) à l'adresse   Oracle.DataAccess.Client.OracleCommand.ExecuteReader (interrogation booléenne,   Remplissage booléen (comportement CommandBehavior) à   Oracle.DataAccess.Client.OracleCommand.System.Data.IDbCommand.ExecuteReader ()

     

... La partie Oracle de la pile se termine ici ...

Nous créons de nouvelles connexions à chaque demande, ouvrez le fichier & amp; close enveloppé dans un essai / attrapé / enfin pour assurer la fermeture correcte de la connexion, et le tout est emballé dans un bloc using (OracleConnection yadayada) {...}. Ce problème ne semble pas lié au redémarrage de l’application ASP.Net après une interruption de service pour inactivité.

Nous n'avons pas encore reproduit le problème nous-mêmes. Pensées, prières, aide?

Plus: Vérifié par le service informatique, le pare-feu n'est pas configuré pour supprimer les connexions entre ces serveurs.

Était-ce utile?

La solution

  

ORA-03113: fin de fichier sur le canal de communication

La base de données vous informe-t-elle que la connexion réseau n’est plus. Cela pourrait être parce que:

  1. Un problème de réseau - connexion défectueuse ou problème de pare-feu
  2. Le processus serveur de la base de données qui traite vous a interrompu de manière inattendue.

Pour 1) ( pare-feu ), recherchez SQLNET.EXPIRE_TIME sur tahiti.oracle.com. Ceci est un paramètre sqlnet.ora qui enverra régulièrement un paquet réseau à un intervalle configurable, c.-à-d: si vous le définissez ainsi, le pare-feu aura l’impression que la connexion est active.

Pour 1) ( réseau ), adressez-vous à votre administrateur réseau (la connexion pourrait ne pas être fiable)

Pour 2) Recherchez les erreurs dans le alert.log . Si le processus du serveur a échoué, il y aura un message d'erreur. Un fichier de trace aura également été écrit pour permettre au support d'identifier le problème. Le message d'erreur fera référence au fichier de trace.

Des problèmes d'assistance peuvent être soulevés sur metalink.oracle.com avec un identifiant de service client (CSI) approprié

Autres conseils

Ajoutez Validate Connection = true à votre chaîne de connexion.

Regardez ce blog pour en savoir plus sur.

DÉTAILS: Après OracleConnection.Close (), la connexion à la base de données réelle ne se termine pas. L'objet de connexion est remis dans le pool de connexion. L'utilisation du pool de connexions est implicite par ODP.NET. Si vous créez une nouvelle connexion, vous obtenez l'un des pools. Si cette connexion est " encore ouverte " la méthode OracleConnection.Open () ne crée pas vraiment de nouvelle connexion. Si la connexion réelle est rompue (pour une raison quelconque), vous obtenez un échec lors de la première sélection, mise à jour, insertion ou suppression.

Avec Validate Connection, la connexion réelle est validée dans la méthode Open ().

Vérifiez qu’un pare-feu ne met pas fin à la connexion après un certain temps (c’était la cause d’un problème similaire)

  

fin de fichier sur le canal de communication:

L’une des causes de cette erreur est due à l’échec de l’écriture du journal lorsqu’elle est en phase d’ouverture;

Solution vérifier la base de données si elle est exécutée dans ARCHIVELOG ou NOARCHIVELOG

pour vérifier l'utilisation 

select log_mode from v$database;

s'il est sur ARCHIVELOG , essayez de passer à NOARCHIVELOG

en utilisant sqlplus

  • montage au démarrage
  • modifier la base de données noarchivelog;
  • modifier la base de données ouverte;

si cela fonctionne pour cela

Ensuite, vous pouvez ajuster votre zone de récupération de la mémoire flash et éventuellement la saturer. - > puis après avoir vérifié que votre zone de récupération flash dispose de l’espace vous pouvez modifier votre base de données dans ARCHIVELOG

Ce message d'erreur peut être émis dans les journaux de l'application lorsque le problème réel est que le serveur de base de données Oracle n'a plus d'espace disponible.

Après avoir corrigé le problème d'espace, ce message d'erreur particulier a disparu.

Vous pouvez essayer ce hack du registre: 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000001
"KeepAliveTime"=dword:00120000

Si cela fonctionne, augmentez simplement le KeepAliveTime . Il est actuellement réglé sur 2 minutes.

L'article mentionné précédemment est bon. http://forums.oracle.com/forums/thread.jspa?threadID= 191750 (le plus loin possible)

S'il ne s'agit pas d'une opération fréquente (ne le faites pas sur votre page d'accueil), vous pouvez désactiver le regroupement de connexions.

Il y a un autre "gotcha" cela n'est pas mentionné dans l'article. Si la première chose que vous essayez de faire avec la connexion est d’appeler une procédure stockée, ODP se suspendra !!!! Vous ne récupérerez pas une condition d'erreur à gérer, mais seulement un accrochage complet! Le seul moyen de résoudre ce problème consiste à désactiver le regroupement de connexions. Une fois que nous avons fait cela, tous les problèmes ont disparu.

La mise en commun est bonne dans certaines situations, mais au prix d’une complexité accrue autour du premier énoncé de chaque connexion.

Si l'approche de gestion des erreurs est si efficace, pourquoi ne pas en faire une option pour que ODP la gère pour nous ????

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top