Oracle listener

[jpcast_real]

Hello,

in our hp-ux system runs an Oracle 9i instance . Recently we have set several new proceses which are accessing to the database . Since that change I have seen how other applications present some failures and seems that the listener blocks new connections or something like that . Some applications are affected but others are not affected . I have thouhgt about setting the listener traces but I am not sure if this is going to help really.

I would appreciate your advices , with points :-)

Regards

[Stuart Abramson]

you may have some kind of port conflict. Check the ports that the listener uses (in tnsnames.ora or listener.ora, I forget.)

also check ports used while running with commands like:

more /etc/services
rpcinfo
netstat - (something, I forget exaclty)
netstat -a | grep -i listen
lsof -i TCP:1526

Just a guess... Buena Suerte !

[Sandman!]

Could be a firewall issue? Check whether there's a firewall between the Oracle DB server and the applications that are being blocked on the port that your listener is running.

regards!

[Julio Yamawaki]

Hi,

First, you need to go to listener log e watch to connection problems, which can lead you to a problem like kernel parameters (nproc, nfile, ..) or to network problems.
If this is not sufficient, you will need to setup trace level in listener.

Regards,

[jpcast_real]

Hello,

I have not any kind of firewall in my environment . There is not any kind of port conflict and I can not find of error in the operating system . I just can find this entries in the listener log file.

Could anyone give me a hint how to enable the tracing in the listener...

Thanks

06-SEP-2005 13:34:52 * service_update * lcm * 0
06-SEP-2005 13:35:26 * service_register * lcm * 0
06-SEP-2005 13:35:26 * service_died * lcm * 12537
06-SEP-2005 13:36:29 * service_register * lcm * 0
06-SEP-2005 13:36:29 * service_died * lcm * 12537
06-SEP-2005 13:37:32 * service_register * lcm * 0
06-SEP-2005 13:37:32 * service_died * lcm * 12537
06-SEP-2005 13:38:35 * service_register * lcm * 0
06-SEP-2005 13:38:35 * service_died * lcm * 12537
06-SEP-2005 13:38:36 * (CONNECT_DATA=(SERVICE_NAME=lcm)(CID=(PROGRAM=D:\oracle\ora92\bin\sqlplus.exe)(HOST=MADN081C
)(USER=terolpal))) * (ADDRESS=(PROTOCOL=tcp)(HOST=139.16.240.5)(PORT=2021)) * establish * lcm * 0
06-SEP-2005 13:38:59 * (CONNECT_DATA=(SERVICE_NAME=lcm)(CID=(PROGRAM=D:\oracle\ora92\bin\sqlplus.exe)(HOST=MADN081C
)(USER=terolpal))) * (ADDRESS=(PROTOCOL=tcp)(HOST=139.16.240.5)(PORT=2022)) * establish * lcm * 0
06-SEP-2005 13:39:38 * service_register * lcm * 0
06-SEP-2005 13:39:38 * service_died * lcm * 12537
06-SEP-2005 13:40:41 * service_register * lcm * 0
06-SEP-2005 13:40:41 * service_died * lcm * 12537
06-SEP-2005 13:41:44 * service_register * lcm * 0
06-SEP-2005 13:41:44 * service_died * lcm * 12537
06-SEP-2005 13:42:47 * service_register * lcm * 0
06-SEP-2005 13:42:47 * service_died * lcm * 12537
06-SEP-2005 13:43:50 * service_register * lcm * 0
06-SEP-2005 13:43:50 * service_died * lcm * 12537

[Eric Antunes]

Hi Javier,

I think your description of the problem is part of the solution:

"Recently we have set several new proceses which are accessing to the database . Since that change I have seen how other applications present some failures..."

How have you configured those processes access the database? SQL*Plus scripts, ...??

Best Regards,

Eric Antunes

[Eric Antunes]

Hi again,

There is bug 2454234 (A 64 bit LISTENER may refuse load updates from a 32 bit server) on versions 9.0.1.3 and 9.2.0.1: what is your RDBMS version and OS bit size??

Eric Antunes

[Indira Aramandla]

Hi Javier,

From your listener log,
SERVICE_REGISTER â means Database trying to register with the listener.

SERVICE_DIED is logged when the listener loses its connection to PMON.

In MTS environment, the database updates the listener with dispatcher and server information as there are dynamic in nature. One can change dynamically the no. of dispatchers/servers and the listener needs to know that.

SERVICE_REGISTER - Database trying to register with the listener.

SERVICE_DIED (logged when the listener loses its connection to PMON)

SERVICE_CURLOAD - Dispatchers report or ask for the current load from the listener. When a client disconnects from a pre-spawned server the pre-spawned server sends a service_curload message to the listener. This message is processed by nsgcscl() and the listener indicates the server has to timeout if there are more servers than the pool size for that particular protocol. However, nsgcscl() counts all pre-spawned servers not just those for a particular protocol. Thus, it may tell a server to timeout even though the no. of servers is less than the max. This results in the required no. of pre-spawned servers not being maintained.

SERVICE_BLOCK - Network read trying to make the outbound connection.

SERVICE_QUIT - When an instance is shutdown, the dispatcher will send service_quit command to the listener indicating the dispatcher is being brought down.

Depending on the number of dispatchers running in your MTS setup, the listener.log file can go really fast in a a brief period of time. Logging of errors for the client, server, and listener cannot be disabled. This is an essential feature that ensures all errors are recorded. You can delete the LISTENER.LOG file while the listener is running. Logging cannot be turned off. However you can try redirecting the log file by setting log_directory_listener in the listener.ora file.

Indira A

[Indira Aramandla]

Hi Javier,

The listener log file contains audit trail information that allows you to gather and analyze network usage statistics, as well as information indicating the following:

- A client connection request
- A start, stop, status, reload or service command issued by the LSNRCTL
Control Utility
- Service registers and service updates by PMON

Read the nore Note:263599.1 in Metalink for more explaination.

I hope this helps.

Indira A