web-dev-qa-db-fra.com

Ce qui peut provoquer des erreurs ORA-12519 intermittentes (TNS: aucun gestionnaire approprié trouvé)

Nous exécutons notre suite de tests Junit 4 contre Weblogic 9 devant une base de données Oracle 10 (utilisant Hudson comme serveur d'intégration continue) et nous obtiendrons occasionnellement un plantage ORA-12519 lors du démontage du script. Cependant, l'erreur est très intermittente:

  • Cela se produit généralement pour la même classe de test
  • Cela ne se produit pas toujours pour les mêmes cas de test (parfois ils réussissent)
  • Cela ne se produit pas pour le même nombre de cas de test (de 3 à 9)
  • Parfois ça n'arrive pas du tout, tout passe

Bien que je ne puisse pas garantir que cela ne se produise pas localement (lors de l'exécution avec la même base de données, bien sûr), j'ai exécuté la même suite de classe plusieurs fois sans aucun problème.

Des idées?

oraclejunitoracle10gora-12519
41
cynicalman

Je ne sais pas si ce sera la réponse de tout le monde, mais après quelques recherches, voici ce que nous avons trouvé.

L'erreur est évidemment causée par le fait que l'auditeur n'acceptait pas les connexions, mais pourquoi obtiendrions-nous cette erreur lorsque d'autres tests pourraient se connecter correctement (nous pourrions également nous connecter sans problème via sqlplus)? La clé du problème n'était pas que nous ne pouvions pas nous connecter, mais que c'était intermittent

Après quelques recherches, nous avons constaté qu'il y avait des données statiques créées pendant la configuration de la classe qui garderaient des connexions ouvertes pendant toute la durée de la classe de test, en créant de nouvelles au fur et à mesure. Maintenant, même si toutes les ressources ont été correctement libérées lorsque cette classe est devenue hors de portée (via un bloc finalement {}, bien sûr), il y a eu des cas pendant l'exécution où cette classe engloutissait toutes les connexions disponibles (ok, mauvais alerte de pratique - c'était un code de test unitaire qui se connectait directement plutôt que d'utiliser un pool, donc le même problème ne pouvait pas se produire en production).

Le correctif consistait à ne pas rendre cette classe statique et à l'exécuter dans la configuration de classe, mais à l'utiliser à la place dans les méthodes setUp et tearDown par méthode.

Donc, si vous obtenez cette erreur dans vos propres applications, frappez un profileur sur ce mauvais garçon et voyez si vous pourriez avoir une fuite de connexion. J'espère que ça t'as aidé.

39
cynicalman

J'ai trouvé une autre solution à une erreur similaire mais le même message d'erreur consiste à augmenter le nombre de gestionnaires de services trouvés. (Mon instance de cette erreur a été causée par un trop grand nombre de connexions dans les pools de connexions du portail Weblogic.)

  • Courir SQL*Plus et connectez-vous en tant que SYSTEM. Vous devez savoir quel mot de passe vous avez utilisé lors de l'installation d'Oracle DB XE.
  • Exécutez la commande alter system set processes=150 scope=spfile; dans SQL * Plus
  • TRÈS IMPORTANT: redémarrez la base de données.

D'ici:

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

26
edwardsmatt

J'ai aussi eu le même problème, j'ai cherché les réponses à plusieurs endroits. J'ai obtenu de nombreuses réponses similaires pour modifier le nombre de gestionnaires de processus/services. Mais j'ai pensé, et si j'avais oublié de le réinitialiser?

Ensuite, j'ai essayé d'utiliser la méthode Thread.sleep() après chacune de mes connection.close();.

Je ne sais pas comment, mais ça marche au moins pour moi.

Si quelqu'un veut l'essayer et comprendre comment cela fonctionne, alors allez-y. J'aimerais aussi le savoir car je suis un débutant dans le monde de la programmation.

3
Rahul Vishwakarma

J'ai eu ce problème dans un test unitaire qui a ouvert beaucoup de connexions à la base de données via un pool de connexions, puis a "arrêté" le pool de connexions (ManagedDataSource en fait) pour libérer les connexions à la fin de chaque test. J'ai toujours manqué de connexions à un moment donné dans la suite de tests.

Ajout d'un Thread.sleep (500) dans le démontage () de mes tests et cela a résolu le problème. Je pense que ce qui se passait, c'est que le pool de connexions stop () libère les connexions actives dans un autre thread de sorte que si le thread principal continue à exécuter les tests, le ou les threads de nettoyage ont pris tellement de retard que le serveur Oracle a manqué de connexions. L'ajout de la mise en veille permet aux threads d'arrière-plan de libérer les connexions regroupées.

C'est beaucoup moins un problème dans le monde réel car les serveurs DB sont beaucoup plus grands et il y a un mélange sain d'opérations (pas seulement des opérations de connexion/déconnexion DB sans fin).

1
Andrew McGregor

J'ai eu le même problème. Cela arrivait à chaque fois que j'exécutais un pack de tests de base de données (Spring JDBC) avec SpringJUnit4ClassRunner, j'ai donc résolu le problème en mettant @DirtiesContext annotation pour chaque test afin de nettoyer le contexte d'application et de libérer toutes les ressources ainsi chaque test pourrait s'exécuter avec une nouvelle initialisation du contexte d'application.

1
Shendor