How to Diagnose and Fix Common Oracle Listener Errors

1. Intermittent connections when listener appears normal

Symptom: Short‑lived client connections drop intermittently.

Cause: Rapid short connections exhaust the listener's IP 1521 port resources; more than 50 connections per second usually indicate a connection storm. The listener cannot allocate new sockets.

Resolution: Reduce the connection rate (use connection pooling), monitor listener.log (e.g., tail -20f $ORACLE_HOME/network/log/listener.log) and adjust the application if a storm is detected.

2. Listener process crash (SunOS 5.10, Oracle 10.2.0.4)

Cause: IPMP (IP Multipathing) failure causes the listener to abort. After the failure the listener recovers after about 38 seconds.

Fix: Edit /etc/default/mpathd and increase IPMP_FAILURE_DETECTION_TIME from the default 10000 ms to at least 20000 ms, then restart the mpathd service.

sed -i 's/^IPMP_FAILURE_DETECTION_TIME=.*/IPMP_FAILURE_DETECTION_TIME=20000/' /etc/default/mpathd
svcadm restart mpathd

3. ORA‑12514 – TNS listener cannot recognize requested service

Cause:

Database instance is not registered with the listener (check with lsnrctl status).

Oracle process limit reached, preventing new sessions.

Fix:

Manually register the instance: alter system register; Check process limits: show process in SQL*Plus.

Identify users with many sessions:

SELECT username, COUNT(*) AS sessions FROM v$session GROUP BY username ORDER BY sessions ASC;

Most occurrences are caused by application bugs that open excessive connections.

4. 11g SCAN listener cannot register service (bug 13066936)

Cause: Known Oracle bug 13066936 prevents the SCAN listener from registering services.

Fix: Apply the Oracle patch that resolves bug 13066936 (download from My Oracle Support) or follow the vendor‑provided workaround.

5. Listener hang caused by “Too many open files”

Symptom: tnsping shows high latency; lsnrctl status returns errors; listener log contains “Too many open files”.

Analysis: The operating‑system limit for open file descriptors per process has been reached.

Resolution: Increase the file‑descriptor limits for the Oracle user and restart the database and listener.

Add the following lines to /etc/system (Solaris example):

set rlim_fd_max=65536
set rlim_fd_cur=4096

Re‑login as the Oracle user and verify the limits:

su - oracle
ulimit -Ha   # hard limits
ulimit -Sa   # soft limits

Restart the database and the listener:

sqlplus / as sysdba
shutdown immediate;
startup;
lsnrctl reload

6. Suppressing TNS‑12535 / TNS‑00505 messages

Cause: A client aborts between the listener’s connection hand‑off steps (steps 3‑4). The listener logs a timeout error, which is normal.

Fix: Disable ADR diagnostics for the listener to stop the messages.

In sqlnet.ora set DIAG_ADR_ENABLED = OFF.

In listener.ora set DIAG_ADR_ENABLED_<em>LISTENER_NAME</em> = OFF (replace LISTENER_NAME with the actual listener identifier).

After editing, restart the listener:

lsnrctl stop
lsnrctl start

7. TNS‑12547 – lost contact

Symptom: Application receives TNS‑12547 while the listener, CRS, and database appear healthy.

Root causes:

On 32‑bit platforms a listener.log larger than 2 GB triggers the error.

Incorrect permissions on binaries under ORACLE_HOME (especially on ASM installations) cause the listener to fail to spawn processes.

Resolution:

Verify that all files under $ORACLE_HOME are owned by the ASM administration group (e.g., asmadmin) and have appropriate execute permissions.

find $ORACLE_HOME -type f -exec ls -l {} \; | grep -v '^...x'

If permissions are missing, relink the binaries:

cd $ORACLE_HOME/rdbms/lib
relink all

On 32‑bit systems, rotate or truncate listener.log to keep it below 2 GB.