Oracle Database Error Solutions & DBA Knowledge Base

Practical, step-by-step Oracle Database troubleshooting and administration resources for DBAs, developers, Oracle E-Business Suite administrators, and IT professionals.

Explore practical guidance covering Oracle Database errors, RMAN backup and recovery, Data Guard, ASM, RAC, performance tuning, installation, patching, cloning, Oracle Linux administration, and Oracle E-Business Suite.

Our troubleshooting guides explain common causes, diagnostic steps, SQL queries, configuration checks, and recommended solutions to help database professionals understand problems and resolve them systematically.

Start with the Oracle Error Codes Guide or explore the main DBA topic areas to find detailed technical articles and practical administration resources.

ORA-03135: Connection Lost Contact – Complete Oracle DBA Troubleshooting & Resolution Guide

-

ORA-03135: Connection Lost Contact – Complete Oracle DBA Troubleshooting & Resolution Guide

🚨 Quick Production Summary

Error: ORA-03135: connection lost contact

Immediate Causes: Network timeout, idle session timeout (firewall/load balancer drop), server-side crash/process termination (OOM killer), or dead connection checker misconfiguration (`SQLNET.EXPIRE_TIME`).


The ORA-03135: connection lost contact error is one of the most frustrating and frequently encountered connectivity failures in Oracle Database environments. Whether you are managing high-transaction OLTP systems, reporting warehouses, or complex multi-tier enterprise applications like Oracle E-Business Suite (EBS), this error abruptly terminates active or idle database sessions, disrupting user workflows and failing background processes.

Unlike errors that prevent a connection from being established in the first place (such as ORA-12514 or ORA-12541), ORA-03135 occurs after a successful connection has already been established and communication is underway. Suddenly, the server or client loses contact, resulting in broken transactions, rolled-back operations, and application error logs.

This comprehensive troubleshooting guide explains why ORA-03135 happens, examines the underlying network and database architecture factors, outlines step-by-step diagnostic workflows, and provides production-tested solutions for Oracle Database 11g, 12c, 18c, 19c, 21c, and Oracle Database 23ai.

Typical Error Message & Symptoms

ORA-03135: connection lost contact
Process ID: 14829
Session ID: 3412 Serial Number: 58219

In enterprise applications, this error often manifests as:

  • Java application logs reporting java.sql.SQLException: ORA-03135: connection lost contact in connection pools (e.g., HikariCP, Apache DBCP, WebLogic, Tomcat).
  • Oracle E-Business Suite users experiencing sudden screen freezes followed by a disconnect to the login page.
  • Long-running SQL queries or heavy batch reports failing mid-execution without throwing a standard ORA-01555 or syntax error.
  • Idle database sessions disconnecting unexpectedly after a fixed period of inactivity (such as 30 minutes or 2 hours).

What is ORA-03135 and Why Does It Happen?

When an application connects to an Oracle Database, a dedicated or shared server process is spawned on the database host to handle communication via Oracle Net Services. Throughout the session lifecycle, packets are exchanged between the client and the server.

The ORA-03135 exception is raised when the Oracle server process or the client driver realizes that communication has stopped unexpectedly. The underlying trigger generally falls into one of three distinct categories:

  1. Network Inactivity & Stateful Firewall Timeouts: Intermediate firewalls, load balancers, or proxies (such as F5, Cisco ASA, AWS NAT Gateways) drop TCP connections that remain idle for too long without keeping packets active.
  2. Server-Side Process Termination: The operating system kernel (specifically the Linux OOM Killer) terminates the Oracle shadow process due to high memory consumption, or the process crashes due to a database internal bug or segmentation fault.
  3. TCP Keepalive Misconfiguration: Neither the operating system nor Oracle Net is sending regular probe packets to verify that the remote end of the connection is still alive.

Core Root Causes in Production Environments

1. Firewall, Load Balancer, or NAT Idle Timeouts

This is the #1 cause of ORA-03135 in enterprise networks. Network devices are configured to clean up state tables for idle TCP connections after a specific threshold (e.g., 30 minutes). If an application user logs in, runs a query, and leaves their session idle for 45 minutes, the firewall silently drops the TCP state without notifying either the client or the database. When the user clicks a button again, the database server attempts to reply over a dead TCP socket, and Oracle instantly throws ORA-03135.

2. Linux Out-Of-Memory (OOM) Killer

If your database server experiences memory pressure (e.g., PGA/SGA growth or memory leaks in application layers running on the same host), the Linux kernel invokes the OOM killer to protect the operating system. If the OOM killer targets and kills an individual Oracle shadow process (LOCAL=NO), all active sessions handled by that process immediately terminate with ORA-03135.

3. Dead Connection Detector (DCD) Not Configured

By default, Oracle does not actively verify if client connections are still reachable. If a client machine crashes or drops off the network abruptly, the corresponding server-side process can remain orphaned until DCD or OS keepalives clean it up.

4. Long-Running Queries Exceeding Read/Write Timeouts

If an ETL job or complex data warehouse query takes hours to execute without returning intermediate data packets, network equipment or client drivers (JDBC/ODBC) may assume the connection is dead and force a timeout.

Step-by-Step Troubleshooting Workflow

Step 1 – Inspect the Oracle Alert Log and Trace Files

Begin by checking the database alert log and trace files to determine whether the shadow process crashed internally or was disconnected externally.

-- Locate the alert log
$ORACLE_BASE/diag/rdbms/<DB_NAME>/<INSTANCE_NAME>/trace/alert_<SID>.log

Look for core dumps, segmentation faults, or accompanying errors such as ORA-07445 or ORA-00600 around the timestamp when ORA-03135 was reported.

Step 2 – Check Operating System System Logs (dmesg / /var/log/messages)

If the error affects multiple users simultaneously or coincides with high system load, check Linux kernel logs for OOM killer activity:

# Check kernel ring buffer for OOM events
dmesg -T | grep -i oom
grep -i oom /var/log/messages

Step 3 – Verify Network Inactivity Settings (SQLNET.EXPIRE_TIME)

The most effective database-level defense against idle timeout drops is enabling Oracle’s Dead Connection Detector (DCD).

Open your server-side `sqlnet.ora` file (located in `$ORACLE_HOME/network/admin/`):

# Set DCD probe interval to 10 minutes (600 seconds)
SQLNET.EXPIRE_TIME = 10

What this does: The database server sends a small probe packet to the client every 10 minutes. If the client (or intermediate firewall) is gone, the server detects the broken socket and cleans up the session cleanly, preventing silent dropouts.

Step 4 – Configure TCP Keepalive at the Operating System Level

To complement `SQLNET.EXPIRE_TIME`, configure Linux OS TCP keepalive parameters so dead network routes are detected quickly. Edit `/etc/sysctl.conf`:

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5

Apply the changes immediately using:

sysctl -p

Step 5 – Adjust Connection Pool Timeouts in Application Servers

If your application uses JDBC connection pools (such as Spring Boot, Tomcat, or WebLogic), ensure the pool validates connections before handing them to applications:

  • Configure connection validation queries (e.g., SELECT 1 FROM DUAL).
  • Set maximum connection lifetime values shorter than your network firewall timeout limits.
  • Enable test-on-borrow features to discard stale or severed sockets automatically.

Real Production Case Study

An enterprise Oracle 19c database supporting an international payroll application experienced intermittent ORA-03135 errors every morning around 11:00 AM. Users working on remote branch offices connected via an enterprise VPN and stateful firewall were randomly disconnected during lunch breaks.

The DBA reviewed the Alert Log and found no internal database crashes or ORA-07445 errors. Querying active session history confirmed that the affected sessions had been idle for exactly 30 minutes.

Resolution: The corporate firewall had a strict 30-minute TCP idle timeout rule. The DBA added SQLNET.EXPIRE_TIME = 5 in `sqlnet.ora` on the database server and reloaded the listener. The server began probing idle connections every 5 minutes, keeping the firewall state table active and eliminating ORA-03135 completely.

Frequently Asked Questions (FAQ)

Can ORA-03135 occur due to bad SQL queries?

Directly, no. However, if a badly tuned query takes an extremely long time to execute and exceeds client-side socket read timeouts, the client driver may sever the connection, resulting in ORA-03135.

Does restarting the database fix ORA-03135?

Restarting the database will clear temporary shadow process locks, but if the underlying network timeout or firewall rule is not addressed, the error will recur as soon as connections remain idle.

Is SQLNET.EXPIRE_TIME resource-intensive?

No. The heartbeat packets generated by DCD are extremely lightweight and consume negligible CPU and network bandwidth.

About the Author

Rana Abdul Wahid is an Oracle Database Consultant with more than 15 years of professional experience in Oracle Database Administration, Oracle RAC, Oracle Data Guard, RMAN Backup & Recovery, Oracle E-Business Suite, Oracle Cloud Infrastructure (OCI), Performance Tuning, and Linux/Unix system administration.

Learn more about the author →

Comments

Post a Comment