J'ai reçu un appel de quelqu'un m'informant qu'il recevait des erreurs TNS-12519 dans son application. Effectivement, ces messages se trouvaient également dans le fichier listener.log.
TNS-12519 :TNS :aucun gestionnaire de service approprié trouvé
Pour ceux qui ne connaissent pas cette erreur, cela signifie généralement l'une des deux choses. Soit le nom du service n'est pas enregistré auprès de l'écouteur, soit la base de données a atteint son nombre maximal de processus. Pour ce dernier, ce qui se passe, c'est que l'auditeur sait que la base de données ne peut accepter aucun nouveau processus, il met donc le nom du service hors service pour ainsi dire. Un rapide "lsnrctl status" me montre que le nom du service est correctement enregistré. Ce doit donc être ce dernier. J'émets alors la requête suivante et confirme mes soupçons.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION--------------- ------------------- ---------- -----processus 299 300
Assez sur. J'ai atteint le nombre maximum de processus, défini dans mon SPFILE comme étant de 300. J'ai augmenté le paramètre à 600 et renvoyé l'instance. Nous rencontrons à nouveau l'erreur avec le double du nombre de processus. Je dois évidemment creuser davantage.
Pour un peu de contexte, et pour quelque chose qui sera important plus tard, il est important de savoir que cette base de données prend en charge nos efforts de test automatisés. Nous avons un harnais de test qui exerce notre application de production primaire. Cette suite de tests lance l'application, se connecte à la base de données, appuie sur quelques boutons et sélectionne quelques éléments de menu, puis se déconnecte.
J'ai examiné le fichier listener.log pour voir d'où provenaient les demandes de connexion. Ces requêtes provenaient d'un serveur d'applications malveillant, et non de notre suite de tests. Je savais que quelque chose n'allait pas parce que nous n'avions pas encore commencé la suite de tests et que nous obtenions des erreurs. Nous avons réparé le serveur d'application et je n'ai pas vu les erreurs revenir. Nous avons ensuite lancé la suite de tests et quelque temps plus tard, les erreurs TNS-12519 sont revenues. Hmmm… Je pensais avoir trouvé le coupable. Mais vérifions l'utilisation de nos processus.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION--------------- ------------------- ---------- -----processus 89 157
Je vois donc actuellement 89 processus avec une utilisation maximale de 157. Je suis loin de ma nouvelle limite de 600. Alors qu'est-ce que ça donne ? Il m'a fallu un certain temps pour comprendre quel était le problème. Le nom du service est correctement enregistré et je suis loin de ma limite. MOS NOTE 552765.1 explique comment l'auditeur arrive à l'erreur TNS-12519. Auparavant, je voyais la cause la plus fréquente. Max PROCESS avait été atteint. Mais pas cette fois Alors qu'est-ce que ça donne ?
Après enquête, j'ai trouvé ma réponse dans le journal de l'auditeur. Mais ce n'était pas évident comme un gros message d'erreur. La première occurrence de l'erreur TNS-12519 s'est produite à 9h38. J'ai recherché "service_update" dans le journal de l'écouteur et j'ai vu ces entrées.
25-JUN-2015 09:17:08 * service_update * orcl * 025-JUN-2015 09:17:26 * service_update * orcl * 025-JUN-2015 09:17:29 * service_update * orcl * 025- JUIN-2015 09:17:44 * service_update * orcl * 025-JUN-2015 09:17:50 * service_update * orcl * 025-JUN-2015 09:17:53 * service_update * orcl * 025-JUN-2015 09 :18:56 * service_update * orcl * 025-JUN-2015 09:18:59 * service_update * orcl * 025-JUN-2015 09:19:50 * service_update * orcl * 025-JUN-2015 09:20:11 * service_update * orcl * 025-JUN-2015 09:21:27 * service_update * orcl * 025-JUN-2015 09:22:09 * service_update * orcl * 025-JUN-2015 09:24:05 * service_update * orcl * 025- JUIN-2015 09:27:53 * service_update * orcl * 025-JUN-2015 09:29:32 * service_update * orcl * 025-JUN-2015 09:34:07 * service_update * orcl * 025-JUN-2015 09 :41:45 * service_update * orcl * 0Notez que cette mise à jour de service se produit régulièrement à 9h17 et 9h18, mais le temps entre les mises à jour de service prend de plus en plus de temps. Notez qu'il y avait 8 minutes 38 secondes entre les mises à jour de service à la fin (9h34 à 9h41). Pourquoi est-ce important ?
Il s'agit d'une base de données Oracle 11.2.0.4. Pour 11.2 et les versions antérieures, PMON est responsable du nettoyage après les processus et de la transmission des informations à l'écouteur. Au démarrage de la base de données, PMON essaie d'enregistrer les services auprès de l'écouteur. Une autre chose que PMON fait est de dire à l'auditeur combien de processus maximum peuvent être servis. Dans ce cas, PMON indique à l'écouteur qu'il peut avoir jusqu'à 600 processus. PMON fait plus, mais pour les besoins de cette discussion, cela suffit.
Un élément important à savoir est que le récepteur ne sait jamais combien de processus sont actuellement connectés. Il sait seulement combien de demandes de connexion il a aidé à négocier. Le Listener ne sait jamais si les processus se déconnectent de la base de données. Le service_update ci-dessus est l'endroit où PMON indique à l'auditeur combien de processus sont réellement utilisés. Ainsi, à 9 h 34 min 07 s, la mise à jour du service PMON indique à l'écouteur qu'il y a 145 processus en cours d'utilisation. Le Listener est maintenant à jour. Lorsqu'une nouvelle demande de connexion arrive, l'écouteur l'incrémente à 146 processus. Entre les mises à jour du service, le Listener ignore totalement qu'un ou plusieurs processus peuvent avoir été arrêtés, normalement ou anormalement. Il continue d'incrémenter son nombre de processus jusqu'à la prochaine mise à jour du service, lorsque l'écouteur obtient un compte rendu précis du nombre de processus générés.
Nous avons donc cet écart de 8,5 minutes entre les mises à jour de service. Pourquoi a-t-il fallu autant de temps à PMON pour revenir à l'auditeur ? Eh bien, l'indice pour cela se trouve également dans listener.log. J'ai tout supprimé du journal avant la mise à jour du service de 9h34 et après la mise à jour du service de 9h41. À partir de là, il était facile de rechercher "(CONNECT_DATA=" dans ce qui restait et de diriger vers "wc -l" pour obtenir le nombre de lignes.
Pendant cet intervalle de 8,5 minutes, j'ai eu plus de 450 nouvelles demandes de connexion ! Pourtant, la plupart de ces nouvelles connexions se sont terminées, comme en témoigne V$RESOURCE_LIMIT me montrant que j'avais un maximum de 150. PMON était tellement occupé à nettoyer l'application quittant ses connexions à la base de données qu'il a eu un grand décalage avant de mettre à jour l'écouteur. En ce qui concerne le Listener, les 150 connexions actuelles plus les 450 nouvelles connexions lui ont permis d'atteindre sa limite de 600.
PMON peut prendre jusqu'à 10 minutes pour revenir à l'écouteur avec sa prochaine mise à jour de service. Le nettoyage après la fermeture des sessions de l'instance a une priorité plus élevée que les mises à jour de service vers l'écouteur. Au bout de 10 minutes, PMON fait de la mise à jour du service la priorité absolue si la mise à jour du service n'a pas été effectuée auparavant dans cet intervalle de temps.
N'oubliez pas qu'il s'agit d'une base de données destinée à prendre en charge les tests automatisés. Nous devons vivre avec ces nombreuses opérations de connexion/déconnexion car nous avons un robot automatisé qui teste notre application de manière rapide. Nous ne voulons pas changer le fonctionnement de l'application car elle fonctionne très bien lorsqu'elle est exécutée par un seul utilisateur. Notre suite de tests automatisés exécute l'application différemment de ce pour quoi elle a été conçue. Mais nous voulons tester l'application telle qu'elle est écrite pour potentiellement exposer les bogues avant que les changements de code n'entrent en production.
Pour l'instant, j'ai augmenté le paramètre PROCESSES à une valeur que nous n'atteindrons jamais. Tout cela pour que le Listener ne puisse pas atteindre la limite dans son compteur interne. Plus il y a de PROCESSUS, plus il faut de mémoire dans la SGA pour prendre en charge ce nombre élevé. Mais cette base de données peut le gérer.
Si quelqu'un connaît un moyen d'obtenir la mise à jour du service dans une fenêtre de 5 minutes, veuillez me le faire savoir. Il n'y a aucun paramètre documenté pour contrôler ce comportement et je n'ai pas non plus été en mesure d'en trouver un non documenté.
Enfin, ce problème se trouve dans l'une de mes bases de données 11.2.0.4. Oracle 12c change un peu l'architecture. Le nouveau processus d'arrière-plan d'enregistrement d'écouteur (LREG) gère le travail que PMON faisait auparavant. Je n'ai pas encore de système à tester, mais je parie que LREG n'aura pas le même problème en 12c que PMON expose ici en 11g car LREG n'aura pas à gérer les tâches de nettoyage que PMON fait. La note MOS 1592184.1 indique que LREG effectuera les mises à jour de service.
Mise à jour :Depuis que j'ai écrit cet article, j'ai eu la possibilité de mettre à niveau la base de données vers 12c avec son nouveau processus LREG. Avec LREG gérant les mises à jour du service de l'auditeur, nous avons vu le problème disparaître. Même pendant les périodes de forte activité de session, en particulier la connexion et la déconnexion, LREG a effectué des mises à jour de service régulières que PMON n'aurait pas été en mesure d'effectuer aussi souvent.
