How does packet loss affect database clusters?
In a database cluster, packet loss isn’t just a "network glitch"—it is a performance and stability killer. While a single-instance database might just feel "slow" when a packet drops, a cluster (like Oracle RAC, SQL Server AG, or Exadata) relies on constant, sub-millisecond communication to keep data synchronized.
When those packets go missing, the cluster enters a state of high-stakes "panic." Here is how it affects the hardware and software layers.
Most database communication happens over TCP. When a packet is lost, TCP waits for an acknowledgment that never comes.
The Stall: The sender must wait for a Retransmission Timeout (RTO) before resending the data.
The 2026 Reality: While modern Linux kernels have aggressive timers, a single lost packet can still cause a 200ms to 1s stall.
The Impact: In a high-speed database, 200ms is an eternity. During this time, the database session is "hung," holding onto critical Row Locks. This causes a "convoys" effect where hundreds of other sessions queue up behind the one waiting for the lost packet.
In clusters like Oracle RAC, nodes share data blocks via the interconnect (Cache Fusion).
The Dependency: If Node A needs a block held by Node B, and the "Grant" packet is lost, Node A cannot proceed.
Wait Events: You will see a spike in wait events like gc cr request or gc current block 2-way.
The Result: Instead of the typical 150µs (microsecond) transfer speed, the request now takes 200,000µs (200ms). Your ultra-fast NVMe-backed cluster suddenly performs slower than a 1990s hard drive.
Cluster nodes stay "married" by sending Heartbeat Packets several times per second.
The False Alarm: If packet loss is severe enough (often referred to as "Network Jitter" or "Flapping"), a healthy node might miss too many heartbeats.
The Eviction: The Clusterware (like Oracle CRS or Windows Failover Cluster) assumes the other node has crashed. To prevent "Split-Brain" (where two nodes write to the same disk and corrupt it), the cluster will evict (reboot) one of the nodes.
The Outage: You lose a perfectly good server simply because the network dropped a few "Are you alive?" packets.
Packet loss directly inflates your Recovery Time Objective (RTO).
Log Shipping: For clusters using "Data Guard" or "Always On," packet loss slows down the replication of redo logs.
The Gap: If your replication can't keep up because it's constantly retransmitting lost packets, your "Transport Lag" grows. If the primary site fails during this lag, you suffer Data Loss (RPO) because the latest transactions never made it to the standby.
| Cause | Description | Impact |
| Micro-bursts | Tiny spikes in traffic that overflow switch buffers for a millisecond. | Causes "Random" latency spikes in SQL queries. |
| PFC Pause Frames | In RoCE networks, a "congested" switch tells the NIC to stop sending. | Bypasses packet loss but causes "HoL Blocking" (the whole network stops). |
| Bad Cables/SFPs | Physical layer CRC errors. | Leads to intermittent, hard-to-diagnose cluster instability. |
| MTU Mismatch | A server sends a 9000-byte packet to a switch set for 1500 bytes. | Total failure of large data block transfers (Cache Fusion). |
"In a database cluster, 0.1% packet loss is not 'mostly working'—it is a critical failure. Because clusters are built on the assumption of synchronous reliability, even a tiny amount of loss triggers a chain reaction of lock contention, retransmission delays, and potential node evictions. The best hardware in the world cannot save a database from a flaky network."