sur un site, je peux me connecter à la base de données Oracle avec SQL Developer, laissez-la au ralenti pendant une longue période (par exemple,> 60 minutes) et votre retour, et c'est bien. Sur un deuxième site, s'il reste du ralenti pendant plus de 5 à 10 minutes (je n'ai pas compté exactement), il laisse le développeur SQL dans un état où de nouvelles opérations tient le délai d'attente et que j'ai besoin de "déconnecter" manuellement, puis de se reconnecter dans l'ordre faire quelque chose d'utile. Cela semble être un délai de connexion sur le deuxième site, et je ne sais pas ce qui le cause (et j'aimerais savoir comment éteindre, bien que ce ne soit pas ma question principale).
Mon programme utilise les données ODP.NET et traite des données en difficulté. Toutes les 30 minutes (par souci de discussion), il obtiendra un tas de données à traiter qui impliqueront un certain nombre de connexions répétées. Il utilise également la mise en commun de la connexion. J'ai défini le pool de connexion pour utiliser une durée de vie de 5 minutes.
Ce que je vois sur le deuxième site (et pas au premier) est mon programme obtiendra des exceptions de délai de connexion (par exemple, ORA-03113) au début de chaque poussée de données. Ce que je crois, c'est que lors de la poussée de données, le pool de connexion est utilisé comme conçu. À la fin de la poussée, la "vie de la connexion" est vérifiée et la connexion n'est pas trop ancienne, elle est donc laissée dans le pool de connexion. Ensuite, 30 minutes plus tard, lorsque de nouvelles données arrivent, la connexion est sortie de la piscine (et non vérifiée pour une durée de vie ou un délai d'attente) et utilisée, et s'efforce, tout comme je le vois dans SQL Developer.
Comment puis-je éviter le délai de connexion mais profite toujours du pool de connexion pendant les poussées? Il semble de la documentation (et de mon expérience) que la connexion est uniquement vérifiée à vie lorsqu'elle entrera dans la piscine et non quand elle sort.
3 Réponses :
Vous pouvez spécifier un délai d'attente infini en paramétrage ConnectionPool est utilisé dans ce cas aussi. oraclecommand.connectionTimeout à 0.
Dans ce cas, il n'y aura pas de délai d'attente (au moins sur le côté client).
Merci Tony, mais je crois que ce paramètre dit Oracle combien de temps attendre une réponse. Le problème que je vois, c'est que la connexion entre dans un état où elle ne recevra jamais une réponse. Ce réglage éviterait donc l'exception, mais mon programme ne serait toujours jamais une réponse - donc je ne le considère pas comme une solution.
Si le réglage de 5 minutes à vie se porte bien sur le premier site, je pense que cela pourrait être causé par une personne définissant le délai d'attente de la session de veille dans un profil du côté du serveur Oracle.
Cependant, avec le réglage de la vie de 5 min, vous pourriez toujours appuyer sur le délai d'attente lorsque votre poussée devient plus grande, car lorsque vous retournez des connexions à la piscine dans la prochaine poussée, ils seront détruits. La piscine sera ensuite occupée à créer et supprimer des connexions et peut conduire à un délai de connexion lorsque la charge est vraiment grande.
C'est une question très ancienne, mais j'ai eu des problèmes similaires avec une application et je pense donc que certaines des informations pourraient aider quiconque qui fait partie de cette question.
Le résumé TL; DR est que les pilotes ODP.NET et la mise en œuvre .NET ne jouent pas bien entre eux et que votre exécution normale des paramètres de mise en commun de la connexion d'usine ne semble pas fonctionner exactement comment vous allez attendre.
idle_time défini sur une valeur dans votre profil utilisateur Oracle (et non illimité ), ces paramètres de ralenti de longs fonctionnant seront Sniped par la base de données. Cela peut finir par causer de problèmes sur le côté .NET car sauf si vous vérifiez explicitement que vos connexions sont toujours ouvertes, .NET permet de servir ces connexions snipé comme si elles sont toujours disponibles (ainsi de lancer l'erreur de délai d'expiration ci-dessus).
- Le truc autour de ce problème est de vous assurer que vous avez
Validation de données = true; dans votre chaîne de connexion. Cela garantit que .NET vérifiera la connectivité de la session avant de couvrir la connexion jusqu'à l'appel de service suivant. Lorsque cette validation voit une session Sniped Sniped, il l'enlève à partir du pool de connexions .NET.
Compte tenu de cette information, il est fort probable que le problème initial de l'OP n'apparaissait que sur le site d'une combinaison de paramètres de base de données différents et / ou de la fréquence des appels .NET à la base de données. Il aurait peut-être eu le problème dans les deux environnements, mais si les utilisateurs d'un environnement effectuaient des appels assez souvent pour Connection Lifetime Pour le faire, il ne verrait jamais ces délais d'attente dans cette base de données.
Maintenant, je n'ai toujours pas compris comment tuer une connexion inactive dans .NET avant tout oile Oracle Idle_Time Sniping, mais aussi longtemps que vous utilisez ce paramètre de données = true , vous devez espérer être capable de contourner ce problème.
Pas assez bien informé dans ces questions, mais nous avons eu un problème très similaire (Changement de centres de données). Le nouveau centre de données tuerait tout port qui a été ouvert sans activité de plus de X de plus de x minutes (nous avions exactement le même problème que vous l'avez fait dans SQL Developer et d'autres processus de longueurs longs. Nous avons chier à l'hébergement de CO. Et ils ont terminé Ne pas tuer les ports d'ora (mais ils ont brièvement recommandé de mettre en œuvre une impulsion uniquement pour les connexions ORA, qui ont été rejetées à l'étranger), mais cela nécessitait des travaux de leur part. Bonne chance!