Discussion :

[Ikebukuro]

Bonjour,

Je constate que sur le listener de mes bases, j'ai un trou de 30 secondes à 45 secondes pour les connexions quand il y a les lignes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
28-JUN-2018 20:37:15 * service_update * BASE1 * 0
28-JUN-2018 20:37:25 * service_update * BASE2 * 0
28-JUN-2018 20:37:30 * service_update * BASE3 * 0

En clair, plus aucune connexion alors qu'avant et après j'ai plusieurs connexions par seconde.

Pouvez-vous m'expliquer à quoi servent ces lignes et, surtout, pourquoi cela bloque l'activité du listener?

Par avance merci.

[Ikebukuro]

Bon, après avoir consulté MetaLink, il apparait que ceci est tout à fait normal, c'est la base qui dit au listener qu'elle est toujours active.
En revanche, ce que je ne comprends pas, c'est pourquoi pendant 30 ou 60 secondes, le listener n'accepte aucune nouvelle connexion. J'en veux pour preuve qu'après le dernier service_update, j'ai 30 demandes de connexions qui tombent en une seconde près sur le listener,comme si elles attendaient depuis le premier service_update.

Des idées sur pourquoi le listener semble bloqué?

[pachot]

Bonjour,

En clair, plus aucune connexion alors qu'avant et après j'ai plusieurs connexions par seconde.

C'était avant qu'il y avait un problème. Une application doit rester connectée. Chaque déconnexion/connection est très coûteuse.
Cordialement,
Franck.

[Pomalaix]

Franck, je suis d'accord, une application ne devrait pas passer son temps à se connecter/déconnecter.
Mais si le comportement habituel sur cette application, c'est d'avoir plusieurs connexions par seconde, et que subitement on n'en a plus pendant 30 secondes ou une minute, c'est louche !

Pour Ikebukuro : avez-vous des plaintes des utilisateurs concernant des difficultés à se connecter ?

Vous pourriez tester (en période creuse) en créant une petite mécanique qui se connecte toutes les secondes, pour voir s'il y a effectivement des problèmes momentanés.
Et puis une table externe sur le listener.log permet de requêter dessus de manière assez pratique.
En passant, j'ai voulu utiliser une fois la vue prédéfinie v$diag_alert_ext (qui regroupe alert.log et listener.log), mais c'était affreusement lent, donc j'ai abandonné cette possibilité.

[pachot]

Table extern sur listener est une très bonne idée.
Sinon, voici ce que j'utilise pour voir vite fait le taux de connexion:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# connection rate to the listener
adrci exec='set home diag/tnslsnr ; show alert -term -p \"' "MESSAGE_TEXT like \'%establish%\' and ORIGINATING_TIMESTAMP > \'2018-06-07 00:00:00\'" '\"' | awk '/establish/{sub(/:.*/,"",$2);print "connection/hour at "$1,$2":00-"$2":59"}' | uniq -c

Cordialement,
Franck.

[Ikebukuro]

Mais si le comportement habituel sur cette application, c'est d'avoir plusieurs connexions par seconde, et que subitement on n'en a plus pendant 30 secondes ou une minute, c'est louche !
Pour Ikebukuro : avez-vous des plaintes des utilisateurs concernant des difficultés à se connecter ?

Oui, c'est bien pour ça que j'ai du prendre en charge l'incident, car le client avait des remontées des utilisateurs sur des pbs de connexion.
J'a refilé le bébé à une autre équipe car j'ai aucun droit sur le serveur Linux pour visualiser les logs (ceux que j'ai m'ont été envoyés par mail ) mais clairement il y a un souci sur le listener.

Tiens, je ne connaissais pas v$diag_alert_ext, je vais voir ça.

Une autre vue sympa sur le lsitener est V$LISTENER_NETWORK; elle permet notamment de récupérer le numéro de port si on ne peut pas se connecter au serveur Unix.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select * from V$LISTENER_NETWORK 
NETWORK	TYPE	VALUE
	LOCAL LISTENER	(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=XXXXXXX01)(PORT=1560)))
	SERVICE NAME	XXXX11
	SERVICE NAME	XXXX_BATCH