ORA-03113: fin de fichier sur le canal de communication après une longue inactivité ASP.Net app.
j'ai une charge équilibrée (n'utilisant pas L'état de Session) ASP.Net 2.0 app on IIS5 tournant à nouveau vers un seul serveur Oracle 10g, en utilisant la version 10.1.0.301 de L'ODAC / ODP.Net drivers. Après une longue période d'inactivité (quelques heures), l'application, apparemment au hasard, lancera une exception Oracle:
Exception: ORA-03113: fin de fichier sur le canal de communication à Oracle.DataAccess.Client.OracleException.HandleErrorHelper (Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, objet src, procédure de chaîne de caractères) Oracle.DataAccess.Client.OracleCommand.ExecuteReader(Boolean requery, Boolean fillRequest, CommandBehavior behavior) à Oracle.DataAccess.Client.OracleCommand.Système.Données.IDbCommand.ExecuteReader ()
...La partie Oracle de la pile se termine ici...
nous sommes en train de créer de nouvelles connexions sur chaque demande, avoir l'open & close enveloppé dans un try / catch / enfin pour s'assurer fermeture de connexion appropriée, et le tout est enveloppé dans une utilisation (OracleConnection yadayada) {...} bloc. Ce problème ne semble pas lié au redémarrage de la ASP.Net application après avoir été désactivé pour inactivité.
nous n'avons pas encore reproduit le problème nous-mêmes. Pensées, prières, aide?
les Plus: vérifié, le pare-feu n'est pas configuré pour tuer les connexions entre ces serveurs.
7 réponses
ORA-03113: fin de fichier sur le canal de communication
est la base de données vous faisant savoir que la connexion réseau n'est plus. Ce pourrait être parce que:
- Un problème de réseau - connexion défectueuse, ou problème de firewall
- le processus du serveur sur la base de données qui vous sert est mort de façon inattendue.
1) (pare-feu) de recherche tahiti.oracle.com pour SQLNET.EXPIRE_TIME. C'est un sqlnet.paramètre ora qui envoie régulièrement un réseau paquet à un intervalle configurable, c'est-à-dire: paramétrer ceci fera croire au pare-feu que la connexion est en direct.
1) (réseau) parlez-en à votre administrateur réseau
pour 2) Vérifiez l'alerte.pour les erreurs, si le processus du serveur a échoué, il y aura un message d'erreur ici et un fichier de trace aura été écrit pour permettre au support d'identifier le problème. Le message d'erreur référencera le fichier de trace.
les questions de soutien peuvent être soulevées à metalink.oracle.com avec un identificateur de service à la clientèle (ISC) adéquat
Ajouter Valider Connexion=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 connection est remis dans le pool connection. L'utilisation du pool de connexion est implicite par ODP.NET. Si vous créez une nouvelle connexion vous obtenez un de la piscine. Si cette connexion est "encore ouverte"la connexion Oraclec.Ouvrir() méthode ne crée pas vraiment une nouvelle connexion. Si la connexion réelle est rompue (pour n'importe quelle raison) vous obtenez un échec sur select, update, insert ou delete.
avec la connexion validée la connexion réelle est validée dans la méthode Open ().
Vérifiez qu'il n'y a pas de pare-feu qui met fin à la connexion après un certain temps (c'était la cause d'un problème similaire que nous avions)
fin-de-fichier sur le canal de communication:
l'Un des cours de cette erreur est due à une base de données ne parviennent pas à écrire le journal lorsque son dans l'étape de l'ouverture;
solution vérifiez la base de données si elle tourne dans ARCHIVELOG ou NOARCHIVELOG
à vérifier l'utilisation de
select log_mode from v$database;
si son sur ARCHIVELOG essayez de changer en NOARCHIVELOG
en utilisant sqlplus
- startup mount
- base de données alter noarchivelog;
- alter database open;
si cela fonctionne pour ce
alors vous pouvez ajuster votre zone flashrecovery il est possible que votre zone flashrecovery soit pleine
- >puis après confirmer que votre zone flashrecovery a l'espace que vous pouvez modifier votre base de données dans le ARCHIVELOG
Ce message d'erreur peut être jeté dans les journaux d'application lorsque le problème est que le serveur de base de données oracle a manqué d'espace.
après avoir corrigé le problème d'espace, ce message d'erreur particulier a disparu.
Vous pouvez essayer ce registre hack:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000001
"KeepAliveTime"=dword:00120000
si cela fonctionne, il suffit de continuer à augmenter le KeepAliveTime. Il est actuellement fixé à 2 minutes.
l'article précédemment mentionné est bon. http://forums.oracle.com/forums/thread.jspa?threadID=191750 (comme il va)
si ce n'est pas quelque chose qui fonctionne fréquemment (ne le faites pas sur votre page d'accueil), vous pouvez désactiver la mise en commun des connexions.
Il y a un autre "piège" qui 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 sera suspendu!!!! Vous n'obtiendrez pas une condition d'erreur à gérer, juste un crochet plein alésage! La seule façon de le réparer est de désactiver la mise en commun des connexions. Une fois qu'on a fait ça, 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 bonne, pourquoi N'en font-ils pas une option pour que ODP s'en occupe pour nous????