How does replication latency occur?
In a perfect world, a change made to your primary database would appear on your replica at the exact same microsecond. In reality, there is always a gap. This gap is called Replication Latency (or Lag).
When latency spikes, your reporting is out of date, your "Active-Active" nodes clash, and your Disaster Recovery plan becomes a liability. Here is a breakdown of why that gap occurs and how to hunt it down.
The most obvious culprit is the physical speed of light. If your primary is in New York and your replica is in London, your data has to travel roughly 3,500 miles.
Bandwidth vs. Latency: You can have a "fat" pipe (high bandwidth), but if the "ping" (latency) is high, the acknowledgement of each packet takes time.
The Bottleneck: If your database generates redo logs faster than your network can "ship" them, the logs start to pile up on the primary server, and the lag grows.
Shipping the data is only half the battle. Once the data arrives at the destination, it has to be applied.
Serial Bottlenecks: In some setups, the source database performs 100 changes in parallel, but the replica tries to apply them one by one. If the "Applier" process (like GoldenGate's Replicat or Data Guard's Redo Apply) can’t keep up with the volume of changes, latency increases.
Resource Contention: If you are using Active Data Guard to run heavy reports on your standby, those reports are competing for CPU and I/O with the process that is trying to apply the new data. If the report wins, the data application loses.
Replication tools often work on a "Commit" basis.
The Scenario: You run a massive batch job that updates 10 million rows in a single transaction.
The Result: The replication tool might wait for that entire transaction to commit before it even starts shipping it. Even if the transfer is fast, the replica will show "zero changes" for 10 minutes, then suddenly jump forward. To a monitoring tool, this looks like a 10-minute lag.
Replication is a disk-heavy activity.
On the Source: The database has to read from the Redo Logs.
On the Target: The replica has to write to its own logs and then write the changes to the Data Files. If the disks on your standby server are slower (SATA) than the disks on your primary (NVMe), the standby will eventually fall behind during peak hours simply because it can't "write" as fast as the primary can "read."
In Oracle, you don't have to guess. You can query the heartbeat of the connection:
If you perform a bulk load with the NOLOGGING attribute to make it faster, that data will not be replicated to a Physical Standby. You won't just have latency; you'll have Data Corruption (unusable blocks) on the standby. Always ensure your database is in FORCE LOGGING mode if you rely on repliation!