Every Oracle DBA knows how to check if a listener is running. lsnrctl status. If it’s down, start it. Problem solved, right? In a simple environment, yes. But in 2025, Oracle environments are rarely simple — they involve OCI networking layers, VCNs, Security Groups, firewalls, multiple listeners, RAC scan listeners, and PDB-specific services. The listener errors that take hours to resolve are never the ones where the listener is simply stopped. They’re the ones where the listener is running, lsnrctl status shows everything healthy, and the application still can’t connect.

This post covers the non-obvious listener problems.

ORA-12545: Connect Failed Because Target Host or Object Does Not Exist

ORA-12545 is a name resolution failure. Oracle resolved the TNS alias, attempted to connect to the host specified, and couldn’t reach it. The listener may be running perfectly. The problem is earlier in the connection chain — DNS or the tnsnames.ora entry itself.

bash

# Verify name resolution from the client
nslookup db_hostname
ping db_hostname
# Check what tnsnames.ora actually resolves to
tnsping MY_SERVICE
# Trace the full connection attempt
sqlplus -L user/password@MY_SERVICE
# The -L flag prevents retry loops, shows the error faster

Common causes I investigate:

DNS TTL lag: The database server’s IP changed (after a migration, an OCI instance replacement, or a Data Guard switchover) but DNS hasn’t propagated. The client resolves to the old IP. Everything looks correct in tnsnames.ora and DNS — but the cached DNS record is stale. Fix: flush DNS cache on client (ipconfig /flushdns on Windows, systemd-resolve --flush-caches on Linux).

tnsnames.ora and LDAP conflict: Many enterprise environments use Oracle Internet Directory (OID) or LDAP for TNS name resolution. If sqlnet.ora specifies NAMES.DIRECTORY_PATH = (LDAP, TNSNAMES), Oracle tries LDAP first. A stale LDAP entry for the same service name takes precedence over your local tnsnames.ora fix.

bash

# Check your name resolution order
cat $ORACLE_HOME/network/admin/sqlnet.ora | grep DIRECTORY_PATH
# If LDAP is listed, check what LDAP returns
ldapsearch -h ldap_host -p 389 -D "cn=orcladmin" -w password \
    -b "dc=company,dc=com" "(cn=MY_SERVICE)"

OCI-specific: On OCI, if your DB System’s hostname is a private DNS name within the VCN (e.g., db-system-1.subnet1.vcn1.oraclevcn.com), clients outside the VCN cannot resolve this name. You need either a public IP on the DB System, a DNS resolver that forwards VCN DNS queries, or a VPN/FastConnect connection with proper DNS forwarding configured.

The Listener is Running But Applications Can’t Connect

This is the scenario that generates the most confusion. lsnrctl status shows the listener up, services registered, everything green. But the application gets ORA-12541 or ORA-12545.

Check 1: Which interface is the listener actually bound to?

bash

# lsnrctl status shows the listener endpoint
lsnrctl status
# Look for: Listening Endpoints Summary
# (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<ip>)(PORT=1521)))
# If HOST shows 0.0.0.0, listener is on all interfaces (good)
# If HOST shows a specific IP, verify it's the right one

A listener bound to a specific IP address won’t accept connections on a different IP of the same server. This catches people out after NIC changes or IP reconfigurations.

Check 2: Firewall rules

The listener is running. The client can resolve the hostname. But a firewall between client and server is silently dropping packets on port 1521.

bash

# Test TCP connectivity directly (not through Oracle tooling)
# From client:
telnet db_host 1521
# Or:
nc -zv db_host 1521
# If this hangs or fails, it's a firewall/network issue, not Oracle

On OCI: check Security Lists AND Network Security Groups. Both can block traffic independently. A common mistake is opening port 1521 in the Security List but forgetting the NSG attached to the DB System, or vice versa.

Check 3: Service not registered with listener

The listener is running but the database service isn’t registered. This happens after a database restart if the listener was started after the database, or if SERVICE_NAMES parameter doesn’t match what the application is connecting to.

sql

-- Check what services are registered
-- In listener log or lsnrctl:
lsnrctl services
-- In the database:
SELECT name, network_name, creation_date FROM v$services;
-- Force service registration
ALTER SYSTEM REGISTER;
-- Wait 30 seconds, then check lsnrctl services again

Check 4: SCAN listener in RAC environments

In RAC, applications connect to the SCAN (Single Client Access Name) listener, not to individual node listeners. SCAN has its own VIP addresses (typically 3) managed by Clusterware. If SCAN listeners are down while node listeners are up, lsnrctl status on a specific node looks fine but cluster-wide connections fail.

bash

# Check SCAN listener status (run as root or grid user)
srvctl status scan_listener
srvctl status scan
# If SCAN is down:
srvctl start scan_listener
srvctl start scan

The sqlnet.ora Timeout Settings That Break Long-Running Connections

A common complaint: “the connection works initially but drops after a period of inactivity.” This is almost always sqlnet.ora timeout settings, not a listener problem.

bash

# Check sqlnet.ora timeout parameters
grep -i "timeout\|expire\|inbound_connect" $ORACLE_HOME/network/admin/sqlnet.ora

Key parameters:

SQLNET.INBOUND_CONNECT_TIMEOUT — How long Oracle waits for the client to complete authentication after the TCP connection is established. Default is 60 seconds. If set too low on a slow network or busy server, connection attempts timeout during authentication.

SQLNET.EXPIRE_TIME — Dead connection detection. Oracle sends a probe packet to verify the client is still alive. Set this (10 minutes is common) to reclaim resources from crashed clients. But be aware: some load balancers interpret the probe as activity, and some don’t — this can interact with load balancer idle timeout settings.

SQLNET.RECV_TIMEOUT — Maximum time for a receive operation. Setting this too low causes connections to drop during legitimate but slow query operations. I’ve seen this set to 30 seconds on databases where some queries legitimately take several minutes, causing mysterious connection drops mid-query.